Une désinformation dangereuse autour du sujet
J’ai très récemment trouvé, sur un site communautaire professionnel un article qui évoquait certains aspects du licensing Oracle sur VMWare comme étant une « légende urbaine ».
L’auteur expliquait qu’installer Oracle sur VMWare n’impliquait pas du tout de licencier tous les processeurs tous les serveurs ESX de l’entreprise : Ce serait une légende urbaine colportée par des commerciaux au mieux ignorants et au pire malhonnêtes.
J’écris donc ces quelques mots pour clarifier ce point : Les règles de licensing Oracle sont très précises en citant ce qui est autorisé. Elles ne citent donc pas ce qui est interdit puisque cela se déduit directement. Pour autant, je vous propose une visite guidée adaptée à notre sujet.
Le partitionnement, la virtualisation selon Oracle
En premier lieu, Oracle définit le « partitionnement » d’un système : C’est la capacité à le découper en sous-système notamment en répartissant les processeurs. Ainsi, un serveur à huit cœurs peut être « découpé » en deux machines de 6 et 2 cœurs. Deux types de partitionnements existent : le logique et le physique. Le physique permet de ne licencier que les cœurs affectés à une « partition ». Le logique quant à lui… ne le permet pas. Il faut licencier tous les cœurs.
Mais comment différencie-t-on un système de partitionnement physique d’un logique ? Simple : Oracle le fait pour vous en dressant unilatéralement la liste dans son document de référence « Oracle Partitioning Policy« . Évidemment, seuls les systèmes dans lesquels l’éditeur a « entière confiance » sont sélectionnés. Et ces systèmes n’incluent pas VMWare… tout simplement.
Le « système » et le vMotion
En second lieu, il se pose donc la question de « ce qu’on partitionne ».
Avec le logiciel VWWare, vous partitionnez en machines virtuelles (VM) un ensemble de serveurs ESXi regroupés dans ce qu’on pourrait appeler une « ferme » ou un « cluster » VMWare. Le « système » est considéré comme composé de tous les serveurs du cluster puisqu’une VM peut migrer vers n’importe quel serveurs du cluster grâce à la technologie vMotion. Oracle considère donc que tous les serveurs ESXi d’un cluster contenant une VM hébergeant Oracle doivent être intégralement licenciés.
Quand le système devient… tout l’univers
En dernier lieu, il reste le point le plus polémique.
Comme écrit précédemment, un cluster regroupe l’ensemble des serveurs vers lesquels une migration vMotion (déplacement à chaud d’une VM) est possible. Dans les versions plus anciennes, une migration vMotion requérait que les machines aient du stockage partagé. On devait donc licencier totalement les serveurs ESXi reliés par du stockage afin d’héberger de l’Oracle. C’est l’époque des « fermes dédiées à Oracle » créés par certains clients. Ils y regroupaient leurs VM Oracle, dans un « coin à part ».
Seulement voilà, VMWare ne cesse de s’améliorer… et les machines virtuelles sont devenues capables de faire du vMotion de plus en plus « loin ».
- Jusqu’en version 5.0, on ne basculait qu’au sein d’un cluster ESXi partageant exactement le même stockage (datastore) : C’était, comme déjà dit, « gérable ».
- En version 5.1 et 5.5, le vMotion est devenu possible entre deux cluster ne partageant pas de stockage mais étant sous le même VCenter. On est donc passé à l’échelle du Datacenter et à une situation bien moins gérable.
- Depuis la version 6.0, VMWare fait des merveilles : Il est possible de faire du VMotion en différents VCenter, stockage, vSphere etc. dès lors qu’ils peuvent communiquer. Même si des câbles, des ports et des routes sont absents, on considère qu’ils peuvent s’ajouter à volonté. Oracle peut donc tourner « n’importe où dans l’entreprise ». Il faut donc alors licencier tous les cœurs de tous les serveurs ESXi de l’entreprise dans le monde.
En conclusion, selon la version de VMWare, faire tourner Oracle sur cette plateforme avec un mode de licence « classique » est difficile voire impossible.
La douleur est moindre en Standard Edition
Le niveau de risque et les impacts varient selon quelle édition vous utilisez.
Si vous utilisez une Standard Edition, vous devez toujours avoir des licences pour chaque nœud ESX. Elles ont en revanche l’avantage d’être bien moins chères et surtout calculées au CPU physique et non au cœur.
Attention toutefois : il est impératif que tous vos serveurs soient équipés au maximum de deux CPU(sockets) physiques. En respectant ces règles, vous pouvez avoir autant de serveurs ESX que vous le souhaitez.
Alors, « bien » ou « pas bien » ? « vrai » ou « faux » ?
Entendons nous bien, il ne s’agit pas ici de justifier ni de critiquer le mode de licencing Oracle. L’objectif est de vous exposer la démarche intellectuelle.
D’ailleurs je me dois de vous parler de ceux qui réfutent cette logique. VMWare a évidemment pris position contre ces règles, et c’est clairement exposé dans leur document « understanding Oracle certification, support and licensing for VMWare environments« . Vous y trouverez beaucoup d’arguments développés très légitimement ainsi qu’une référence à un procès entre Mars et Oracle en 2015. Ces documents pointent les failles du discours qui vous ont sans doute fait lever les sourcils durant cette lecture.
La réalité du risque (et sa gestion ?)
Le problème est donc bien quasiment rhétorique. Pour autant, après de nombreuses missions d’assistance à des clients sur des points de licensing, je peux vous garantir qu’Oracle s’appuie sur les règles que j’ai citées. Dans un cas d’audit de compliance, il vous sera donc demandé un redressement correspondant à l’achat de licence pour tous les cœurs de toute votre entreprise.
Un exemple :
Une machine virtuelle est installée chez vous sur une ferme ESXi de deux serveurs à deux cœurs.
Vous possédez donc deux licences « processor » Oracle (grâce au « core factor » de 0.5).
D’autre part, vous possédez une ferme ESX sur un réseau physique à part et dédié, comportant dix machines à 8 cœurs.
En cas d’audit, vous êtes exposés à un redressement de quatre-vingts cœurs Oracle « prix public », soit 80*0.5*47500= 1 900 000 €. Il faudrait ajouter les trois ans de support rétroactifs également imputés, mais je vous épargne le calcul qui rajoute 70% environ.
Une fois tout cela dit, la question qui reste est donc de savoir : devant de telles conditions, suis je prêt pour aller contester les règles Oracle et surtout leur interprétation ? Vous êtes en droit, tout comme Mars, de voir différemment les choses. Mais aurez vous la force et les moyens de vous faire entendre ?
Quelles solutions se présentent ?
Notre positionnement est donc que face au risque, il vaut mieux accepter les règles du jeu en même temps qu’on accepte d’acheter un logiciel Oracle.
Cette règle VMWare est la plus fortement récriminée. Mais il en existe beaucoup d’autres qui exposent énormément beaucoup de clients. Notre mission est généralement de détecter ces « violations », les expositions et surtout de proposer des remédiations afin de sécuriser ce point « Licensing ». Comme nous disons souvent : une architecture hébergeant de l’Oracle se définit d’abord en fonction des couts et des risques Oracle.
Pour terminer, si vous cherchez des pistes de solution et donc d’optimisme, sachez qu’il en existe.
On peut par exemple souscrire des accords de licences particuliers comme les « Unlimited Licence Agreements« . Il est également possible maintenant de recourir à des systèmes de virtualisation « physique » comme OLVM, basé sur KVM. Il faut également penser au Cloud ou à l’hybride exaCC qui, étrangement, s’avèrent être les meilleures manières de reprendre possession de vos couts de supports, voire de les diminuer à termes.
Il est également possible de se prendre une « assurance conformité » via des logiciels, comme celui d’Aspera, qui surveillent vos assets. C’est particulièrement important pour les options Oracle qui représente un risque très délicat à contrôler. Je leur dédierai d’ailleurs un article prochainement.
N’hésitez pas à me contacter si vous souhaitez plus d’information : Nous avons notamment des opportunités à saisir sur les logiciels de conformité en cette fin d’année 2020.
