Publicité en cours de chargement...
Licencing Oracle et virtualisation : cauchemar de la DSI ou légende urbaine ?
Comme beaucoup d’entre vous sûrement, j’ai entendu énormément de choses de la part de commerciaux ou d’intégrateurs sur ce mécanisme de facturation qui se serait soi-disant, encore durcit ses dernières années.
#LÉGENDEURBAINE
Pour une infrastructure VMWare par exemple, on m’a encore récemment soutenu qu’il fallait désormais payer des licences pour chaque serveur ESXi hôte connecté au serveur de gestion vSphere, même si un cluster avec seulement une partie des hôtes avait été paramétré pour héberger les machines virtuelles Oracle.
J’ai également vu passer sur des forums, qu’il était nécessaire de payer des licences pour chaque site distant qui se connecte au site principal hébergeant l’infrastructure.
Si c’était vraiment le cas, les hébergeurs « cloud » n’auraient plus qu’à mettre la clé sous la porte.
Ces mythes sont entretenus par quelques commerciaux affamés et une grande partie de la communauté IT qui, bernée, continue de faire vivre cette légende urbaine.
Le document à l’origine de nombreuses confusions et souvent mentionné par les « semeurs de trouble » est intitulé . Mais contrairement à ce que certains peuvent laisser entendre, ce document n’a pas de valeur contractuelle ! Il est juste censé apporter les « best practices » aux clients, et non les contraindre obligatoirement à des restrictions de mémoire, de stockage, de vCenter ou de réseau.
Alors, comment ça fonctionne réellement ce système de facturation ?
Si l’on se penche sur le , on constate qu’il y a deux méthodes de facturation : Le nombre d’utilisateurs ou le nombre de processeur. Dans une infrastructure virtualisée comme de nombreux établissements disposent, c’est le licencing au nombre de processeurs qui est généralement retenu.
Il faut donc se référer à , pour effectuer le calcul.
La plupart des processeurs équipant les serveurs qu’un établissement moyen est en mesure de s’offrir a une valeur de 0,5 par cœur.
Donc pour un cluster vSphere de 2 serveurs (comme sur le schéma vu plus haut) disposant chacun de 2 processeurs 10 cœurs, le calcul doit être le suivant :
2 serveurs X 2 processeurs X 10 cœurs par socket = 40
40 X 0,5 = 20
Il faudra payer pour 20 cœurs effectifs utilisés pour Oracle.
On est d’accord, c’est loin d’être donné, mais on est quand même loin des différents mythes véhiculés !
Avez-vous apprécié ce contenu ?
A lire également.
RGPD et cyber : l’ouverture de la chasse à la bécasse et à la galinette cendrée[1]
20 oct. 2025 - 13:47,
Tribune
-En l’espace d’une semaine, je tombe sur deux « news » de la planète RGPD/RSSI, à propos desquelles on se demande comment les organisations impliquées ont bien pu « en arriver là » – sans conséquences gravissimes, heureusement.

La plateforme de télémédecine Rofim lève 10 millions d’euros pour poursuivre sa croissance et internationaliser son activité
15 sept. 2025 - 22:03,
Actualité
- Propos recueillis par Mehdi Lebranchu et Pauline NicolasPensée par et pour des médecins en 2018, Rofim est une plateforme de télémédecine qui regroupe désormais six modules afin de permettre aux patients de recevoir le juste soin, au bon endroit, au bon moment et par le bon professionnel de santé. En cette rentrée 2025, Rofim annonce une levée de fonds d...

ESMS numérique : l’instruction du 5 septembre donne un nouveau cap pour 2025
08 sept. 2025 - 23:17,
Actualité
- DSIHUne nouvelle instruction (1) ministérielle, publiée le 5 septembre 2025, modifie en profondeur les modalités de financement du programme ESMS numérique. Elle rebat les cartes pour les établissements d’accueil, d’hébergement et d’insertion (AHI) et redistribue une enveloppe budgétaire désormais porté...

PHAST pour la mise en œuvre des terminologies LOINC et SNOMED CT
26 août 2025 - 08:46,
Actualité
- DSIH, Damien DuboisFin juillet, l’opérateur d’interopérabilité sémantique PHAST a annoncé la sélection de son consortium par l’Agence du numérique en santé pour porter le marché de la mise en œuvre des terminologies LOINC et SNOMED CT.