Déterminer le nombre de cœurs à licencier pour SQL Server 2025

La règle de calcul : serveur physique ou machine virtuelle

Une licence « par cœur » ne se calcule ni à partir de la charge réelle de la base, ni à partir du nombre d’instances SQL Server. Un serveur qui n’utilise que 15 % de son processeur reste licencié selon sa capacité matérielle ou virtuelle attribuée. Limiter l’affinité CPU d’une instance SQL Server ne réduit donc pas, à lui seul, le nombre de licences nécessaires.

La première décision est simple : SQL Server s’exécute-t-il directement sur le système d’exploitation du serveur, ou dans une machine virtuelle ? Dans le premier cas, on dénombre les cœurs physiques de chaque processeur installé. Dans le second, on dénombre les processeurs virtuels configurés pour chaque VM exécutant SQL Server, sous réserve des règles de virtualisation de l’édition retenue.

Le terme « cœur » recouvre donc deux réalités. Sur matériel nu, il s’agit du cœur de processeur physique. Dans une VM, il s’agit du vCPU, parfois appelé cœur virtuel dans les outils d’administration. Ne mélangez jamais les deux colonnes d’un inventaire : c’est une cause fréquente de surlicence comme de sous-licence.

Choisir le bon modèle de licence avant de compter les cœurs

SQL Server existe habituellement sous deux grands modèles. Le modèle par cœur convient à SQL Server Enterprise et reste disponible pour SQL Server Standard. Il permet de donner accès au serveur à un nombre non limité d’utilisateurs ou de dispositifs, sans décompter de CAL.

L’édition Standard peut aussi être licenciée selon le modèle Server + CAL. Il faut alors une licence serveur pour l’instance et une CAL SQL Server pour chaque utilisateur ou chaque appareil qui accède au service, directement ou indirectement. C’est parfois plus économique pour une petite équipe interne stable, mais nettement moins pratique pour un portail client, une application ouverte à de nombreux partenaires ou un service Internet.

Le fait qu’une application web, un connecteur ou un logiciel métier se place entre l’utilisateur et la base ne fait pas disparaître les obligations de CAL. Ce mécanisme, appelé multiplexage, ne réduit pas le nombre d’utilisateurs ou d’appareils à couvrir. Dans ces cas, le modèle par cœur est souvent le plus lisible.

L’édition compte aussi sur le plan technique. SQL Server Standard peut convenir à une base métier modérée, mais ses capacités de calcul et certaines fonctions de disponibilité ou de performance sont encadrées. Les limites habituellement associées à l’édition Standard, notamment en nombre de sockets et de cœurs exploités par le moteur, doivent être confrontées à votre architecture cible. Acheter Enterprise uniquement parce que le serveur possède beaucoup de cœurs n’est pas nécessairement justifié ; l’inverse peut toutefois bloquer un projet de haute disponibilité ou de consolidation.

À lire aussiClé numérique ou boîte physique ? Avantages et limites des licences dématérialisées Microsoft

Calculer les licences sur un serveur SQL Server physique

Pour une installation SQL Server sur le système d’exploitation physique, relevez le nombre de processeurs installés et le nombre de cœurs physiques de chacun. La formule pratique est la suivante : additionnez, pour chaque processeur, le plus grand nombre entre ses cœurs physiques et quatre. Achetez ensuite le nombre de licences correspondant, généralement en packs de deux.

Un serveur à deux processeurs de 12 cœurs demande ainsi 24 licences cœur. Un serveur à deux processeurs de 2 cœurs n’en demande pas quatre au total, mais huit licences : le plancher de quatre s’applique à chacun des deux processeurs. Cette distinction est particulièrement importante sur les serveurs anciens, les petits nœuds d’infrastructure ou les configurations à plusieurs sockets.

L’hyperthreading ne double pas ce décompte. Un processeur de 12 cœurs physiques exposant 24 processeurs logiques reste compté comme 12 cœurs pour une installation physique. De même, un cœur inactif, une instance limitée à quelques CPU ou une base de données peu sollicitée ne permettent pas d’écarter automatiquement une partie du matériel du périmètre.

La désactivation de cœurs dans le BIOS ou via une fonction matérielle ne doit pas être considérée comme une économie automatique. Avant de bâtir un achat sur cette hypothèse, faites confirmer par écrit que la configuration désactivée est admissible au regard des droits applicables et qu’elle est durablement documentée.

Licencier SQL Server en machine virtuelle sans sous-estimer les vCPU

Lorsque SQL Server est installé dans une VM, le calcul le plus courant consiste à attribuer des licences cœur au nombre de vCPU de cette VM. Une VM de 2 vCPU exige néanmoins quatre licences, car le minimum est de quatre licences par environnement virtuel. Une VM de 5 vCPU nécessite cinq licences en droit d’usage, mais l’achat par packs de deux conduit généralement à commander six licences.

Additionnez les besoins de toutes les VM SQL Server qui fonctionnent simultanément. Trois petites VM de 2 vCPU ne requièrent pas six licences, mais douze : chacune déclenche son propre minimum de quatre. C’est pourquoi la multiplication de micro-VM peut coûter plus cher qu’une consolidation raisonnée, même si la consommation réelle de CPU reste faible.

Les vCPU à relever sont ceux alloués dans la configuration de la VM, et non ceux affichés comme consommés par l’hyperviseur à un instant donné. Une fonction d’ajout à chaud, d’augmentation automatique de capacité ou de redimensionnement peut faire évoluer le besoin. Il faut alors analyser le maximum configuré et la période de coexistence des machines, sans présumer qu’une même licence peut être déplacée librement d’une VM à l’autre.

Les conteneurs demandent la même prudence. Le fait d’isoler SQL Server dans un conteneur ne crée pas une échappatoire au modèle de licence : il faut relier chaque déploiement à un environnement licencié selon les droits applicables. Une architecture Kubernetes ou des conteneurs éphémères mérite une validation spécifique, car la mobilité et la fréquence des créations d’instances compliquent l’attribution des licences.

Comparer licence par VM et licence de l’hôte virtualisé

Dans un parc virtualisé, il existe généralement deux approches : attribuer les licences aux VM SQL Server une par une, ou, dans certains scénarios éligibles, licencier l’hôte physique pour bénéficier de droits de virtualisation plus étendus. La seconde approche est particulièrement liée à l’édition Enterprise et à une couverture de type Software Assurance ou abonnement ; elle ne doit jamais être déduite par analogie avec une autre gamme Microsoft.

Ne comparez pas uniquement le total de vCPU d’aujourd’hui avec le total de cœurs de l’hôte. Ajoutez la croissance prévue, les VM de test durables, les nœuds de reprise et les migrations entre hôtes. Une solution moins chère sur le papier peut devenir coûteuse dès que la huitième ou la dixième VM SQL Server est créée.

Les droits de déplacement constituent un autre point de contrôle. En règle générale, une licence ne se réattribue pas à volonté entre serveurs sur de courtes périodes ; une règle de 90 jours s’applique souvent, avec des exceptions encadrées, notamment en cas de panne matérielle ou selon certains droits de mobilité. Un cluster qui déplace automatiquement les VM doit donc être examiné avec l’architecte, le responsable des licences et le contrat en main.

À lire aussiComment organiser un événement dans le métavers : guide pratique

Haute disponibilité et reprise après sinistre : définir ce qui est vraiment passif

Un réplica de secours n’est pas forcément une deuxième licence à acheter, mais il n’est pas automatiquement gratuit non plus. Les droits de basculement et de serveur passif dépendent généralement d’une Software Assurance active ou d’un abonnement qualifiant, ainsi que du respect strict de la définition d’une instance passive.

Un serveur secondaire qui ne sert pas de requêtes utilisateurs et qui attend un basculement peut relever des droits de reprise applicables. En revanche, un réplica lisible utilisé pour le reporting, les extractions, les requêtes métiers ou la répartition de charge devient actif. Il doit alors être licencié à son tour selon sa capacité, même s’il reste techniquement présenté comme « secondaire ».

La sauvegarde, la supervision et les opérations de maintenance doivent être analysées en fonction des droits exacts du produit. Ne supposez pas qu’un serveur de PRA, un nœud de log shipping ou une instance dans un autre site bénéficie automatiquement du même traitement qu’un réplica passif. Documentez le rôle de chaque nœud et les services réellement rendus aux utilisateurs.

La méthode d’inventaire pour obtenir un chiffre défendable

Un calcul fiable commence par l’architecture réellement déployée, pas par le bon de commande précédent. Créez un tableau d’inventaire unique regroupant les hôtes, les VM, les instances SQL Server, les éditions, les rôles de réplication et les droits de couverture. Cet exercice révèle souvent des VM oubliées, des environnements de recette pérennes ou des serveurs de reporting distincts.

Conservez également le mode de calcul retenu. Pour chaque ligne, indiquez la formule utilisée, par exemple « VM applicative : 6 vCPU, donc 6 licences cœur » ou « hôte physique : 2 processeurs de 10 cœurs, donc 20 licences ». Cette traçabilité rend le dossier compréhensible lors d’une migration, d’un renouvellement de Software Assurance ou d’un contrôle interne.

Les erreurs qui font dérailler le budget ou la conformité

La première erreur est de compter les processeurs au lieu des cœurs. Deux processeurs de 16 cœurs ne représentent pas deux unités de licence, mais 32 cœurs à couvrir dans un déploiement physique. La deuxième consiste à confondre cœurs physiques et processeurs logiques, ce qui peut entraîner un surachat lorsque l’hyperthreading est actif.

La troisième erreur est de ne regarder que la production. Une base de recette qui tourne toute l’année, une instance SSRS séparée ou une VM de reporting peut appartenir au périmètre de licence, sauf droits de développement ou de test spécifiquement applicables. Les environnements non productifs ne sont pas tous soumis aux mêmes règles : vérifiez notamment l’éligibilité aux abonnements de développement plutôt que de supposer une gratuité.

Enfin, ne laissez pas un intégrateur ou un revendeur chiffrer uniquement à partir d’un nombre global de cœurs. Demandez un devis détaillé précisant l’édition, le modèle de licence, le nombre de packs de deux cœurs, la couverture Software Assurance ou abonnement, ainsi que les hypothèses de virtualisation et de haute disponibilité. Le bon chiffre est celui qui correspond à votre architecture et à vos droits d’usage, pas celui qui ressemble au total de CPU affiché dans une console d’administration.

Avant validation, faites relire le tableau par les équipes infrastructure, base de données, sécurité et achats. Si le parc comporte un cluster, des réplications intersites, des hôtes mutualisés ou des conteneurs, un spécialiste des licences Microsoft peut sécuriser l’interprétation contractuelle. Cette vérification coûte beaucoup moins qu’une régularisation décidée après un audit ou une évolution non anticipée de l’architecture.