SQL Server pour charges entreprise

Calculez le nombre de cœurs à couvrir avant de choisir la quantité de packs

Commencez par définir le périmètre du déploiement, plutôt que par la taille de la base de données ou le nombre de salariés. Pour un déploiement physique de SQL Server Enterprise sous licence par cœur physique, comptez tous les cœurs physiques du serveur, en respectant le minimum de quatre licences cœur par processeur physique imposé par Microsoft. Un pack de deux cœurs fournit deux licences cœur ; il ne couvre pas un processeur ou un serveur entier. Avec ce mode de licence, l’Hyper-Threading ne double pas le nombre de cœurs physiques, et les cœurs physiques inutilisés doivent aussi être comptabilisés.

Distinguez l’activation du logiciel du droit légal d’exécuter la configuration prévue. Une clé de produit fonctionnelle ne suffit pas, à elle seule, à justifier les droits d’utilisation de l’édition, le nombre de cœurs couverts, la couverture Software Assurance ou l’éligibilité au transfert de licence. Avant l’achat, obtenez des documents précisant la version, l’édition, le canal de distribution des licences et le nombre de licences cœur fournies. SQL Server sous licence par cœur ne nécessite pas de CAL SQL Server, mais les licences Windows Server et les éventuelles licences d’accès Windows Server restent des obligations distinctes.

• Inventoriez les processeurs physiques et le nombre de cœurs par processeur.
• Appliquez le minimum de quatre cœurs séparément à chaque processeur.
• Divisez le nombre de licences cœur nécessaires par deux pour calculer le nombre de packs de deux cœurs.
• Vérifiez les justificatifs des droits de licence au lieu de vous fier uniquement à l’activation.
• Prévoyez un budget distinct pour le système d’exploitation sous-jacent.

Choisissez un modèle de virtualisation adapté à vos hôtes et à vos projets de migration

Selon les règles de licence actuelles de SQL Server, l’attribution de licences à des machines virtuelles individuelles nécessite des licences par abonnement ou des licences couvertes par une Software Assurance active. Avec ce modèle, comptez les cœurs virtuels attribués à chaque VM SQL Server, avec un minimum de quatre licences cœur par VM. Une petite VM de base de données dotée de deux vCPU ne réduit donc pas le besoin en licences en dessous de quatre. Vérifiez les Conditions d’utilisation des produits Microsoft applicables à votre contrat et à votre version, en particulier si vous évaluez d’anciennes licences perpétuelles ou prévoyez une mise à niveau.

Pour une consolidation à forte densité, une autre option est la virtualisation illimitée avec Enterprise : couvrez tous les cœurs physiques d’un hôte avec des licences cœur Enterprise assorties d’une Software Assurance active, en respectant les minimums par processeur physique. Cela permet d’exécuter un nombre illimité d’instances SQL Server dans un nombre illimité d’environnements de système d’exploitation virtuels sur ce serveur sous licence. Ce droit ne couvre pas automatiquement les hôtes voisins. Avant d’activer la migration automatique des VM, recensez toutes les destinations possibles et vérifiez leur couverture ou les droits de mobilité des licences applicables.

• Relevez le nombre de cœurs virtuels attribués à chaque VM SQL Server.
• Ne supposez pas qu’une clé de licence perpétuelle inclut les droits de licence par VM individuelle.
• Comparez les licences par VM à la couverture complète de chaque hôte prévu.
• Incluez les hôtes de maintenance et de basculement dans le plan de placement des VM.
• Examinez les restrictions de réaffectation avant de déplacer des licences entre serveurs.

Déterminez si chaque réplica de disponibilité est passif ou doit disposer de ses propres licences

Un groupe de disponibilité est une architecture de résilience, et non une exemption générale de licence pour ses serveurs secondaires. Dans le cadre des avantages Microsoft liés à une Software Assurance ou à un abonnement éligible, certaines instances de basculement passives peuvent fonctionner sans licences SQL Server distinctes, sous réserve des Conditions d’utilisation des produits applicables. Un serveur secondaire qui traite des requêtes de reporting ou d’autres charges de travail SQL Server actives doit généralement disposer de sa propre couverture de licence. Classez les réplicas selon leur utilisation réelle, plutôt que selon leur désignation comme primaire ou secondaire dans le schéma d’architecture.

Documentez l’emplacement, le rôle et les opérations autorisées de chaque réplica avant d’acheter des licences. Les droits de basculement Microsoft distinguent la haute disponibilité de la reprise après sinistre et imposent des conditions concernant les instances passives, la capacité et le fonctionnement simultané. Certaines opérations de maintenance sont autorisées sur les instances passives éligibles, mais cela ne doit pas être interprété comme un droit d’utilisation illimitée en production. Si un réplica doit traiter des requêtes de business intelligence, des charges de test ou du trafic applicatif, évaluez-le comme un déploiement actif au lieu de supposer que les droits accordés aux instances passives s’appliquent.

• Recensez les connexions de reporting et les connexions applicatives à chaque réplica secondaire.
• Vérifiez précisément les droits relatifs aux instances passives associés à vos licences.
• Vérifiez les activités de sauvegarde et de maintenance autorisées au regard des conditions Microsoft.
• Documentez l’impact des tests de basculement prévus sur les besoins en licences.
• Réévaluez la couverture lorsque vous modifiez les rôles des réplicas ou ajoutez le routage en lecture seule.

Validez séparément le chiffrement et la restauration pour la mise en production

Traitez le chiffrement du stockage, le chiffrement des connexions et la protection contre les accès privilégiés à la base de données comme des exigences distinctes. Transparent Data Encryption protège les fichiers de données et les journaux de la base de données au repos ; il n’empêche pas les requêtes SQL autorisées de lire les données en clair. TLS protège les connexions réseau lorsqu’il est correctement configuré. Always Encrypted protège les valeurs de colonnes sélectionnées au moyen de pilotes clients compatibles, avec des clés gérées en dehors du moteur de base de données. Ses propriétés de sécurité et ses capacités de requête dépendent de la configuration, notamment de l’utilisation ou non d’enclaves sécurisées.

Élaborez une procédure de restauration avant de mettre en production des données soumises à des exigences réglementaires. Pour TDE reposant sur un certificat, sauvegardez le certificat qui protège la clé de chiffrement de la base de données ainsi que sa clé privée, puis conservez les éléments nécessaires à la restauration dans un emplacement sécurisé, en dehors du serveur de base de données. La restauration d’une base de données chiffrée sur un autre serveur nécessite l’accès à l’élément de protection correspondant. Testez la restauration sur une cible isolée, puis vérifiez la connectivité des applications, les identifiants de connexion, les travaux planifiés et les dépendances externes. La réplication ou un groupe de disponibilité ne remplace pas des sauvegardes indépendantes pour se protéger contre la suppression, la corruption des données ou les rançongiciels.

• Définissez séparément les données nécessitant une protection au repos, en transit et au niveau des colonnes.
• Vérifiez la compatibilité des pilotes avant d’adopter Always Encrypted.
• Exigez la validation des certificats lors de la configuration des connexions clientes chiffrées.
• Incluez la récupération des clés de chiffrement dans chaque exercice de restauration.
• Mesurez le temps de restauration et la perte de données acceptable au moyen de tests.

Exemples de packs de deux cœurs SQL Server Enterprise. Les exemples de déploiement physique couvrent le serveur entier ; les exemples par VM individuelle nécessitent des licences par abonnement éligibles ou une Software Assurance active. Les licences du système d’exploitation et les serveurs supplémentaires ne sont pas inclus.