Bienvenue sur le Blog d'EASYTEAM (ex ArKZoYd)

le 14/01/2015
Frédéric Cessy
FinOps, Page d'accueil

Tarification des licences Oracle – Named User PLus : Episode 4

Les logiciels Oracle Technology sont actuellement vendus selon deux unités de tarification (communément dit « metrics ») :

Le « Processor » pour couvrir l’usage du logiciel pour une machine quel que soit le nombre d’utilisateurs.
Le « Named User Plus » pour couvrir l’usage du logiciel pour un individu quel que soit le nombre de machines.

La définition de ces unités de tarification détermine aussi bien la façon dont doit être utilisé le logiciel (périmètre et/ou limite de la licence, …) que la façon dont son usage doit être mesuré et quantifié.

Ces définitions peuvent paraitre compliquées et leur portée parfois mal maitrisée peut engendrer des situations de non-conformité d’une ampleur significative.
Cet article explique en détail comment doit être interprétée la définition du NUP, quel en est le périmètre, quelles en sont les limites et où sont les risques inhérents à l’usage des licences NUP.
Pour plus de précision, le sujet est découpé en 6 points d’attention édités en 4 épisodes dont voici le dernier.
Point d’attention n°6 – le NUP implique de savoir compter le nombre de licences Processeur
« Il vous incombe de garantir que le nombre minimum d’Utilisateurs Nommés Plus par processeur est maintenu pour les logiciels figurant dans le tableau des minimums… »
Cette partie de la définition renvoie au tableau suivant, précédé de la mention « Si vous achetez des Licences Utilisateurs Nommés Plus pour les logiciels ci-dessous, vous devez maintenir les nombres d’utilisateurs minimum et maximum suivants » :

Logiciel	Minimum Utilisateurs Nommés Plus
Oracle Database Enterprise Edition	25 Utilisateurs Nommés Plus par Processeur
…	…

Note, ce tableau fait référence au « Processeur » tel que défini au contrat et non pas tel que l’on pourrait l’entendre en langage courant.
La première étape pour mesurer le nombre de licences NUP nécessaires sur un environnement donné consiste donc à mesurer le nombre de licences Processeur nécessaires pour cet environnement afin de déterminer le nombre de licences NUP minimum requis par la puissance de celui-ci.
Attention : les environnements virtualisés /partitionnés.
Exemple souvent rencontré : soucieux d’économiser ses licences pour l’usage de Database Enterprise Edition sans prendre de risque, une entreprise choisi d’affecter des licences Processeur pour ses applications de production et d’affecter 30 licences NUP pour toutes les applications de non-production.
Les 30 utilisateurs de ces dernières sont parfaitement identifiés et leur nombre est parfaitement vérifiable.
Les environnements de production et non-production se trouvent sur un cluster VMWare avec 10 serveurs disposant 4 cpu Intel Xeon Octo-core dont une machine virtuelle de 2 cœurs est dédiée aux applications de non-production.
Une évaluation rapide pourrait indiquer que le 30 NUP suffisent aux 30 personnes utilisant les applications de non-production et appliquer la règle des minima sur la machine virtuelle (2 cœurs de la VM X coefficient* de 0.5 X 25 = 25 NUP mini) tendrait à le confirmer.
Mais, la technologie VMware n’étant pas reconnue par Oracle comme un partitionnement « Physique » permettant de limiter effectivement la puissance globale d’un serveur*, tous les Processeurs de tous les serveurs composant le cluster doivent être pris en compte pour le comptage des licences.
Dans le cas présent, couvrir l’usage en non-production pour les 30 personnes demanderait 4000 NUP ! (4cpu X 8 coeurs X coefficient de 0.5 X 10 serveurs X minima 25).

Conclusion :
La complexité grandissante des environnements applicatifs rend l’affectation de licences NUP Oracle de plus en plus difficile : les interactions entre applications de différents services renvoient souvent l’origine du flux de données à un nombre de personnes non-quantifiable et/ou non identifiables.
Ne serait-ce que pour cette raison, un client n’ayant aujourd’hui que des licences NUP pour son usage en production présente des risques très forts de non-conformité aux conséquences souvent très significatives.
Easyteam par son service de Software Asset Management dispose de l’expertise nécessaire pour aider ses clients à maîtriser ce risque et en contrôler parfaitement les impacts.