Partager via

Déployer plusieurs clusters Big Data SQL Server dans le même domaine Active Directory

  • Article

S’applique à : SQL Server 2019 (15.x)

Cet article explique les changements apportés à SQL Server 2019 dans le cadre de la mise à jour cumulative 5 (CU5), qui permet la configuration de plusieurs clusters Big Data SQL Server 2019. Il est maintenant possible de déployer et d’intégrer différents clusters Big Data dans le même domaine Active Directory.

Important

Le module complémentaire Clusters Big Data Microsoft SQL Server 2019 sera mis hors service. La prise en charge de la plateforme Clusters Big Data Microsoft SQL Server 2019 se terminera le 28 février 2025. Tous les utilisateurs existants de SQL Server 2019 avec Software Assurance seront entièrement pris en charge sur la plateforme, et le logiciel continuera à être maintenu par les mises à jour cumulatives SQL Server jusqu’à ce moment-là. Pour plus d’informations, consultez le billet de blog d’annonce et les Options Big Data sur la plateforme Microsoft SQL Server.

Avant SQL Server 2019 CU5, deux problèmes empêchaient le déploiement de plusieurs clusters Big Data dans les domaines Active Directory.

  • Conflit de noms entre les noms de principal de service et le domaine DNS
  • Nom du principal du compte de domaine

Que sont les collisions de noms d’objets ?

Conflit de noms entre les noms de principal du service (SPN) et le domaine DNS

Le nom de domaine fourni au moment du déploiement est utilisé comme domaine DNS Active Directory (AD). Cela signifie que les pods peuvent se connecter les uns aux autres dans le réseau interne via ce domaine DNS. Les utilisateurs utilisent également ce domaine DNS pour se connecter aux points de terminaison du cluster Big Data. Par conséquent, le nom du pod, du service ou du point de terminaison Kubernetes doit être qualifié avec ce domaine DNS AD pour tous les noms de principal de service (SPN) créés pour un service dans le cluster Big Data. Si un utilisateur déploie un deuxième cluster dans le domaine, les SPN générés ont le même nom de domaine complet (FQDN), car les noms des pods et des domaines DNS sont les mêmes entre les clusters. Prenons le cas d’un domaine DNS AD appelé contoso.local. L’un des SPN générés pour le pool principal SQL Server dans le pod master-0 est MSSQLSvc/master-0.contoso.local:1433. Dans le second cluster que l’utilisateur tente de déployer, le nom du pod pour master-0 est le même. L’utilisateur spécifie le même domaine DNS AD (contoso.local), ce qui produit la même chaîne SPN. Comme Active Directory interdit la création d’un SPN en conflit, le déploiement du deuxième cluster échoue.

Nom du principal du compte de domaine

Lors du déploiement d’un cluster Big Data avec un domaine Active Directory, plusieurs principaux de comptes sont générés pour les services qui s’exécutent dans le cluster. Il s’agit essentiellement de comptes d’utilisateur AD. Avant SQL Server 2019 CU5, les noms de ces comptes n’étaient pas uniques d’un cluster à l’autre. Cet aspect se manifeste si l’on tente de créer le même nom de compte d’utilisateur pour un service donné de clusters Big Data dans deux clusters différents. Le deuxième cluster déployé rencontre un conflit dans AD, ce qui empêche la création du compte.

Comment résoudre les collisions de noms

Étapes pour résoudre les problèmes de SPN et de domaine DNS - SQL Server 2019 CU5

Les SPN doivent être uniques dans les clusters. Le nom de domaine DNS passé au moment du déploiement doit également être différent. Vous pouvez spécifier différents noms DNS avec un nouveau paramètre introduit dans le fichier de configuration de déploiement : subdomain. Si le sous-domaine diffère entre deux clusters et que la communication interne est possible sur ce sous-domaine, les noms SPN incluent le sous-domaine, atteignant ainsi l’unicité requise.

Notes

La valeur transmise par le biais du paramètre subdomain ne constitue pas un nouveau domaine AD, mais un domaine DNS utilisé en interne.

Revenons au cas du SPN pour le pool maître SQL Server. Si le sous-domaine est bdc, le SPN en question est remplacé par MSSQLSvc/master-0.bdc.contoso.local:1433.

Le nom du cluster Big Data ou de l’espace de noms est utilisé pour calculer la valeur des paramètres du sous-domaine. Il est possible de personnaliser la valeur du nouveau paramètre subdomain dans la spécification de configuration Active Directory. Si les utilisateurs souhaitent changer le nom du sous-domaine, ils peuvent se servir du nouveau paramètre subdomain dans la spécification de configuration Active Directory.

Comment garantir l’unicité d’un nom de compte

Pour changer des noms de compte tout en garantissant leur unicité, utilisez des préfixes de compte. Le préfixe de compte est un segment du nom de compte qui est unique d’un cluster à un autre. Le segment restant du nom du compte peut être identique. Le nouveau format de nom de compte se présente ainsi : <prefix>-<name>-<podId>.

Notes

Active Directory impose que les noms de compte comportent 20 caractères au maximum. Le cluster Big Data doit en utiliser 8 pour distinguer les pods et les StatefulSet. Il reste donc 12 caractères pour le préfixe de compte.

Vous avez la possibilité de personnaliser le nom de votre compte. Utilisez le paramètre accountPrefix dans la spécification de la configuration Active Directory. SQL Server 2019 CU5 introduit accountPrefix dans la spécification de la configuration. Par défaut, c’est le nom du sous-domaine qui est utilisé comme préfixe de compte. Si ce nom dépasse 12 caractères, le préfixe de compte est constitué de la sous-chaîne composée des 12 premiers caractères.

Le sous-domaine ne s’applique qu’au DNS. Le nouveau nom de compte d’utilisateur LDAP est donc bdc-ldap@contoso.local, et pas bdc-ldap@bdc.contoso.local.

Sémantique

Les paramètres suivants ont été ajoutés dans SQL Server 2019 CU5 pour permettre la configuration de plusieurs clusters dans un domaine :

subdomain

  • Champ facultatif
  • Type de données : chaîne
  • Définition : sous-domaine DNS unique à utiliser pour ce cluster Big Data. Cette valeur doit être différente pour chacun des clusters déployés dans le domaine Active Directory.
  • Valeur par défaut : lorsque aucune valeur n’est fournie, c’est le nom du cluster qui est utilisé comme valeur par défaut.
  • Longueur maximale : 63 caractères par étiquette (à savoir chaque chaîne séparée par un point)
  • Remarques : les noms DNS de point de terminaison doivent comporter le sous-domaine dans leur nom de domaine complet.

accountPrefix

  • Champ facultatif
  • Type de données : chaîne
  • Définition : préfixe unique pour les comptes AD que le cluster Big Data génère. Cette valeur doit être différente pour chacun des clusters déployés dans le domaine Active Directory.
  • Valeur par défaut : lorsque aucune valeur n’est fournie, c’est le nom du sous-domaine qui est utilisé comme valeur par défaut. Lorsque le sous-domaine n’est pas indiqué, le nom du cluster sert de nom du sous-domaine, et donc est également hérité comme accountPrefix. Si le sous-domaine est précisé et qu’il s’agit d’un nom en plusieurs parties (avec un ou plusieurs points), l’utilisateur doit fournir un accountPrefix.
  • Longueur maximale : 12 caractères

Ajustements pour le domaine AD et le serveur DNS

Aucune modification n’est requise dans le domaine ou le contrôleur de domaine AD pour prendre en charge le déploiement de plusieurs clusters Big Data sur le même domaine Active Directory. Le sous-domaine DNS est automatiquement créé sur le serveur DNS lors de l’inscription des noms DNS des points de terminaison externes.

Modifications dans le fichier de configuration du déploiement

La section activeDirectory dans le fichier de configuration du plan de contrôle control.json comporte deux nouveaux paramètres facultatifs : subdomain et accountPrefix. Le nom du cluster est utilisé pour chacun de ces paramètres. Fournissez de nouvelles valeurs pour ces paramètres si vous souhaitez remplacer le comportement par défaut. Le nom du cluster correspond au nom de l’espace de noms.

Vous avez la possibilité d’utiliser n’importe quel nom DNS de point de terminaison, à condition qu’il s’agisse d’un nom complet. Ce nom ne doit pas non plus être en conflit avec un autre cluster Big Data déployé dans le même domaine. Vous pouvez utiliser la valeur du paramètre subdomain afin d’être sûr que les noms DNS soient différents entre les clusters. Prenons le point de terminaison de passerelle. Vous pouvez utiliser le nom gateway du point de terminaison et l’inscrire automatiquement auprès du serveur DNS. Pour faire cette inscription au moment du déploiement de votre cluster Big Data, utilisez gateway.bdc1.contoso.local comme nom DNS. bdc1 correspondant au sous-domaine et contoso.local au nom de domaine DNS AD. gateway-bdc1.contoso.local ou encore simplement gateway.contoso.local sont d’autres valeurs acceptables.

Exemples de configuration de la sécurité Active Directory

Vous trouverez ci-dessous un exemple de configuration de la sécurité Active Directory, au cas où vous souhaiteriez remplacer les paramètres subdomain et accountPrefix.

    "security": { 
        "activeDirectory": { 
            "ouDistinguishedName":"OU=contosoou,DC=contoso,DC=local", 
            "dnsIpAddresses": [ "10.10.10.10" ], 
            "domainControllerFullyQualifiedDns": [ "contoso-win2016-dc.contoso.local" ], 
            "domainDnsName":"contoso.local", 
            "subdomain": "bdc", 
            "accountPrefix": "myprefix", 
            "clusterAdmins": [ "contosoadmins" ], 
            "clusterUsers": [ "contosousers1", "contosousers2" ] 
        } 
    }

Voici un exemple de spécification de point de terminaison pour les points de terminaison du plan de contrôle. Vous pouvez utiliser n’importe quelles valeurs comme noms DNS, à condition qu’ils soient uniques et complets :

        "endpoints": [ 
            { 
                "serviceType": "NodePort", 
                "port": 30080, 
                "name": "Controller", 
                "dnsName": "control-bdc1.contoso.local" 
            }, 
            { 
                "serviceType": "NodePort", 
                "port": 30777, 
                "name": "ServiceProxy", 
                "dnsName": "monitor-bdc1.contoso.local" 
            } 
        ]

Questions

Est-il nécessaire de créer des unités d’organisation (UO) distinctes pour les différents clusters ?

Ce n’est pas obligatoire, mais recommandé. Le fait de fournir des UO distinctes pour les différents clusters facilite la gestion des comptes d’utilisateurs générés.

Comment puis-je revenir au comportement d’avant la mise à jour CU5 dans SQL Server 2019 ?

Il peut exister des cas de figure dans lesquels la prise en compte du nouveau paramètre subdomain n’est pas possible, par exemple, si vous devez déployer une version antérieure à CU5 et que vous avez déjà mis à niveau Azure Data CLI (azdata). Même si cette situation est très improbable, vous pouvez définir le paramètre useSubdomain sur false dans la section Active Directory de control.json pour rétablir le comportement d’avant CU5.

Dans l’exemple suivant, useSubdomain est défini sur false pour ce cas de figure.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.useSubdomain=false"

Étapes suivantes

Résolution des problèmes d’intégration Active Directory Clusters Big Data SQL Server