Comment optimiser ses licences Oracle
Optimiser la gestion et le coût de ses licences Oracle reste un défi pour les d’entreprises. Avec Romain Pannequin, de Digora, LeMagIT revient sur les erreurs à ne pas commettre et sur quelques astuces pour tirer parti au mieux des options de licences proposées par l’éditeur.
Digora, un intégrateur français spécialisé dans les environnements Oracle organisait récemment un séminaire de formation sur les pratiques de licence du constructeur. L’occasion pour LeMagIT de faire le point avec Romain Pannequin, l’un des spécialistes du sujet chez Digora et de voir comment les entreprises peuvent optimiser leurs licences Oracle.
Comme l’explique Romain Pannequin, le modèle de licence Oracle reste pour l’essentiel largement aligné sur les capacités physiques des serveurs. C’est un modèle de licence par processeur avec un système de multiples en fonction du nombre de cœurs des serveurs. Par exemple pour Oracle SGBD, une licence entreprise est facturée 6 x 37 000 € pour un serveur bipro-hexacoeur X86. Ce modèle est finalement assez rigide, et surtout peut s’avérer rapidement coûteux. Mais comme l’explique Romain Pannequin, il invite aussi les entreprises à être intelligentes quant à leurs besoins. Toutes les entreprises n’ont pas forcément besoin de la licence entreprise et parfois la licence standard est largement suffisante. Dans le cas de notre exemple de serveur biprocesseur hexacoeur précédent, une licence standard d’Oracle SGBD ne coûte que 25 000€.
L’édition standard ouvre de plus la possibilité d’utiliser Oracle RAC de façon gratuite (alors que c’est une option payante dans l'édition entreprise). Pour certains environnements de développement et certaines applications non critiques, Oracle Standard Edition One est aussi une bonne alternative (cette version n’ouvre toutefois pas la porte à Oracle RAC).
Quelques astuces pour optimiser ses licences Oracle
Comme l’explique Romain Pannequin, il existe aussi d’autres solutions pour optimiser le budget en s’appuyant sur les solutions intégrées d’Oracle, car ces dernières introduisent des exceptions dans la grille tarifaire qui permettent de faire de confortables économies sur les licences. Par exemple, une entreprise qui achète l’Oracle Database Appliance (ou ODA) paie le SGBD en fonction du nombre de cœurs activés par paire (l’activation des cœurs se fait au niveau physique). Cela veut dire que pour une PME qui a besoin des pleines capacités d’Oracle SGBD dans sa version entreprise, mais pas forcément la pleine puissance d’un serveur, la Database Appliance est une bonne solution pour limiter les coûts et permet d’acquérir des licences en suivant les besoins de puissance (pay-as-you-grow).
Un autre moyen de limiter les coûts est d’utiliser l’hyperviseur d’Oracle, Oracle VM, pour virtualiser la base de données. Dans ce cas, l’entreprise paie en fonction du nombre de cœurs alloués à la VM. Il est à noter toutefois, que ce licencing au cœur n’est disponible qu’avec Oracle VM et pas avec les solutions concurrentes Hyper-V ou vSphere.
Il est en revanche important de s’assurer que l’on licencie bien le bon nombre de cœurs, car chez Oracle, le mécanisme de licence est déclaratif (il n’y a pas de mécanisme de contrôle logiciel permettant de s’assurer que l’on ne dépasse pas les capacités de la licence que l’on a payé, comme par exemple avec VMware vSphere). Et en cas de contrôle, la division LMS (Licence Management Services) d’Oracle est réputée pour son caractère impitoyable.
Un progrès récent est l’intégration dans la dernière version d’Oracle Cloud Control (12c r3) d’un mécanisme permettant à un client d’inventorier ses déploiements des outils Oracle pour veiller à la conformité entre déploiement de licences. Ce mécanisme d’inventaire suppose toutefois que toutes les bases soient enregistrées dans le Cloud Control.
Il est à noter qu’Oracle a aussi étendu la facturation au cœur à certains environnements cloud. Sur le cloud de Microsoft, celui de Verizon et bien sûr celui d’Oracle, il est ainsi possible de louer des VM faisant tourner les SGBD et Middleware d’Oracle en payant au cœur utilisé.
Une alternative souvent méconnue des clients est l’utilisation d’une licence temporaire. Une entreprise, pour un projet spécifique, peut par exemple n’acheter une licence que pour un ou deux ans. Le prix est alors de 20% de la licence complète par an pour la licence limitée. En revanche, le prix du support reste facturé sur le prix complet de la licence (soit 22% du prix complet). Cela veut dire que pour un an avec support, le prix est de 42% du prix de la licence, contre 122% du prix de la licence de base pour une licence complète avec un an de support.
Quelques pièges et erreurs courantes à éviter
Selon Romain Pannequin, un piège dans lequel les clients tombent fréquemment est celui de la licence par utilisateur. Certains produits Oracle proposent un mécanisme de licence alternatif par nombre d’utilisateurs plutôt qu’au cœur CPU. Mais chez Oracle, ce mécanisme repose sur le nombre d’utilisateurs nommés et pas sur le nombre d’utilisateurs concurrents.
Un autre piège concerne les clusters VMware vSphere sur lesquels la fonction DRS (Dynamic Ressource Scheduler) est activé – DRS optimise en permanence le positionnement des VM d’un serveur à l’autre en fonction des SLA définis afin de tirer parti au mieux des ressources disponibles. Comme l’explique Romain Pannequin, si une VM faisant tourner une base de données Oracle est susceptible de bouger entre nœuds d’un cluster, il faut prendre une licence pour chacun des nœuds du cluster, ce qui peut s’avérer ruineux. Le conseil est alors de bâtir un cluster virtualisé dédié aux SGBD Oracle afin de limiter la casse.
Notons enfin que les progiciels Oracle arrivent avec des licences intégrées (embarquées ou à usage limité) des produits d’infrastructure (SGBD et Middleware). Ces licences ne couvrent toutefois ces produits que si aucun développement spécifique n’est effectué sur les progiciels. Si, en revanche, des développements spécifiques sont opérés, il faut acquérir des licences des produits d’infrastructures pour les faire tourner.
