Bereitstellen von mehreren Big Data-Clustern für SQL Server in derselben Active Directory-Domäne

Artikel
03/23/2023

Gilt für: SQL Server 2019 (15.x)

In diesem Artikel werden Updates für das kumulative Update 5 (CU5) für SQL Server 2019 erläutert, was die Konfiguration mehrerer Big Data-Cluster von SQL Server 2019 ermöglicht. Verschiedene Big Data-Cluster können jetzt mit derselben Active Directory-Domäne bereitgestellt und integriert werden.

Wichtig

Das Microsoft SQL Server 2019-Big Data-Cluster-Add-On wird eingestellt. Der Support für SQL Server 2019-Big Data-Clusters endet am 28. Februar 2025. Alle vorhandenen Benutzer*innen von SQL Server 2019 mit Software Assurance werden auf der Plattform vollständig unterstützt, und die Software wird bis zu diesem Zeitpunkt weiterhin über kumulative SQL Server-Updates verwaltet. Weitere Informationen finden Sie im Ankündigungsblogbeitrag und unter Big Data-Optionen auf der Microsoft SQL Server-Plattform.

Vor SQL Server 2019 CU5 haben zwei Probleme die Bereitstellung mehrerer Big Data-Cluster in AD-Domänen verhindert.

Ein Namenskonflikt in Bezug auf Dienstprinzipalnamen und die DNS-Domäne
Namen von Kontoprinzipalen in der Domäne

Was sind in Konflikt stehende Objektnamen?

Konflikt zwischen Dienstprinzipalnamen und dem DNS-Domänennamen

Der bei der Bereitstellung bereitgestellte Domänenname wird als Ihre DNS-Domäne für Active Directory (AD) genutzt. Dies bedeutet, dass die Pods im internen Netzwerk über diese DNS-Domäne eine Verbindung zueinander herstellen können. Benutzer*innen stellen auch über diese DNS-Domäne eine Verbindung mit den Endpunkten des Big Data-Clusters her. Aus diesem Grund muss für jeden Dienstprinzipalnamen (Service Principal Name, SPN), der im Big Data-Cluster für einen Dienst erstellt wird, der Name des Kubernetes-Pods, -Diensts oder -Endpunkts bei dieser AD-DNS-Domäne qualifiziert werden. Wenn ein*e Benutzer*in einen zweiten Cluster in der Domäne bereitstellt, verfügen generierte SPNs über denselben FQDN, da Podnamen und DNS-Domänennamen nicht zwischen Clustern unterscheiden. Angenommen, die AD-DNS-Domäne lautet contoso.local. Einer der SPNs, die für die Masterpool-SQL Server-Instanz in Pod master-0 generiert werden, lautet MSSQLSvc/master-0.contoso.local:1433. Im zweiten Cluster versucht der Benutzer oder die Benutzerin eine Bereitstellung durchzuführen, dabei ist der Podname für master-0 identisch. Der Benutzer oder die Benutzerin stellt dieselbe AD DNS-Domäne (contoso.local) bereit, die dieselbe SPN-Zeichenfolge ergibt. In Active Directory ist die Erstellung eines in Konflikt stehenden Dienstprinzipalnamens jedoch verboten, was zu einem Bereitstellungsfehler für den zweiten Cluster führt.

Namen von Kontoprinzipalen in der Domäne

Während einer Bereitstellung eines Big Data-Clusters in einer Active Directory-Domäne werden mehrere Kontoprinzipale für Dienste generiert, die im Big Data-Cluster ausgeführt werden. Dabei handelt es sich im Wesentlichen um AD-Benutzerkonten. Vor SQL Server 2019 CU5 waren die Namen für diese Konten zwischen Clustern nicht eindeutig. Dies führte zu dem Versuch, denselben Benutzerkontonamen für einen bestimmten Dienst im Big Data-Cluster in zwei verschiedenen Clusterinstanzen zu erstellen. Der zweite Cluster, der bereitgestellt wird, hat einen Konflikt in AD, und das Konto kann nicht erstellt werden.

Beheben von Namenskonflikten

Schritte zur Lösung von SPN- und DNS-Domänenproblemen in SQL Server 2019 CU5

SPNs müssen in Clustern eindeutig sein. Der zur Bereitstellungszeit übergebene DNS-Domänenname muss sich auch unterscheiden. Mit der neu in der Bereitstellungskonfigurationsdatei eingeführten Einstellung subdomain können Sie von nun an unterschiedliche DNS-Namen angeben. Wenn sich die Unterdomäne zwischen zwei Clustern unterscheidet und die interne Kommunikation über diese Unterdomäne erfolgen kann, enthalten die SPNs die Unterdomäne, wodurch die erforderliche Eindeutigkeit erreicht wird.

Hinweis

Der Wert, der über die Unterdomäneneinstellung übergeben wird, ist keine neue AD-Domäne, sondern eine intern verwendete DNS-Domäne.

Kehren wir zum Fall des Masterpools für den SQL Server-SPN zurück. Wenn die Unterdomäne bdc lautet, wird der betroffene SPN in MSSQLSvc/master-0.bdc.contoso.local:1433 geändert.

Der Name oder der Namespace des Big Data-Clusters wird verwendet, um den Wert der Unterdomäneneinstellung zu berechnen. Sie können optional den Wert des neu eingeführten Unterdomänenparameters in der Active Directory-Konfigurationsspezifikation anpassen. Wenn Benutzer*innen den Unterdomänennamen außer Kraft setzen möchten, können sie dies mithilfe des neuen Unterdomänenparameters in der Active Directory-Konfigurationsspezifikation tun.

So stellen Sie sicher, dass der Name des Kontos eindeutig ist

Um Kontonamen zu aktualisieren und die Eindeutigkeit zu gewährleisten, verwenden Sie Kontopräfixe. Das Kontopräfix ist ein Segment des Kontonamens, das über alle Cluster hinweg eindeutig ist. Das verbleibende Segment des Kontonamens kann konstant sein. Das neue Kontonamenformat sieht wie folgt aus: <prefix>-<name>-<podId>

Hinweis

In Active Directory sind Kontonamen auf eine Länge von 20 Zeichen beschränkt. Der Big Data-Cluster muss 8 Zeichen zum Unterscheiden von Pods und StatefulSets verwenden. So verleiben 12 Zeichen für das Kontopräfix.

Sie haben die Möglichkeit, Ihren Kontonamen anzupassen. Verwenden Sie den Parameter accountPrefix aus der Active Directory-Konfigurationsspezifikation. accountPrefix wurde mit SQL Server 2019 CU5 in die Konfigurationsspezifikation eingeführt. Der Unterdomänenname wird standardmäßig als Kontopräfix verwendet. Wenn der Unterdomänenname länger als 12 Zeichen ist, werden die ersten 12 Zeichen des Unterdomänennamens als Kontopräfix verwendet.

Die Unterdomäne gilt nur für das DNS. Daher lautet der Name des neuen LDAP-Benutzerkontos bdc-ldap@contoso.local, Der Kontoname ist nicht bdc-ldap@bdc.contoso.local.

Semantik

Die folgenden Parameter werden in SQL Server 2019 CU5 hinzugefügt, um mehrere Cluster in einer Domäne zu konfigurieren:

`subdomain`

Optionales Feld
Datentyp: String
Definition: eine eindeutige DNS-Unterdomäne, die für diesen Big Data-Cluster verwendet werden soll. Dieser Wert muss für jeden Cluster, der in der Active Directory-Domäne bereitgestellt wird, unterschiedlich sein.
Standardwert: Wenn nicht angegeben, wird der Clustername als Standardwert verwendet.
Maximale Länge: 63 Zeichen pro Bezeichnung (wobei jede durch einen Punkt getrennte Zeichenfolge als Bezeichnung gilt)
Anmerkungen: Die DNS-Namen des Endpunkts sollten die Unterdomäne in ihrem vollqualifizierten Domänennamen verwenden.

`accountPrefix`

Optionales Feld
Datentyp: String
Definition: ein eindeutiges Präfix für AD-Konten, das vom Big Data-Cluster generiert wird. Dieser Wert muss für jeden Cluster, der in der Active Directory-Domäne bereitgestellt wird, unterschiedlich sein.
Standardwert: Wenn nicht angegeben, wird die Unterdomäne als Standardwert verwendet. Wenn keine Unterdomäne bereitgestellt wird, wird der Clustername als Name der Unterdomäne verwendet. Daher wird der Clustername ebenfalls als accountPrefix geerbt. Wenn die Unterdomäne bereitgestellt wird und über einen mehrteiligen Namen verfügt (also mindestens einen Punkt enthält), muss der Benutzer accountPrefix angeben.
Maximale Länge: 12 Zeichen

Anpassungen für die AD-Domäne und den DNS-Server

Es sind keine Änderungen in der AD-Domäne oder am Domänencontroller erforderlich, um die Bereitstellung mehrerer Big Data-Cluster in derselben Active Directory-Domäne zu ermöglichen. Die DNS-Unterdomäne wird beim Registrieren externer Endpunkt-DNS-Namen automatisch auf dem DNS-Server erstellt.

Änderungen an der Bereitstellungskonfigurationsdatei

Der Abschnitt activeDirectory in der Konfigurationsdatei der Steuerungsebene control.json besitzt zwei neue optionale Parameter: subdomain und accountPrefix. Der Clustername wird für jeden dieser Parameter verwendet. Stellen Sie neue Werte für diese Einstellungen bereit, wenn Sie das Standardverhalten außer Kraft setzen möchten. Der Clustername entspricht dem Namen des Namespace.

Sie haben die Möglichkeit, einen beliebigen DNS-Endpunktnamen zu verwenden, solange er vollständig qualifiziert ist. Er darf auch nicht mit anderen Big Data-Clustern in Konflikt stehen, die in derselben Domäne bereitgestellt wurden. Sie können den Wert des Unterdomänenparameters verwenden, um sicherzustellen, dass DNS-Namen sich zwischen Clustern unterscheiden. Berücksichtigen Sie dabei den Gatewayendpunkt. Sie können den Namen gateway für den Endpunkt verwenden und ihn automatisch auf dem DNS-Server registrieren. Verwenden Sie dazu als Teil Ihrer Big Data-Clusterbereitstellung gateway.bdc1.contoso.local als den DNS-Namen. wenn die Unterdomäne bdc1 lautet und contoso.local der AD-DNS-Domänenname ist. Weitere zulässige Werte sind gateway-bdc1.contoso.local oder schlicht gateway.contoso.local.

Beispiele für eine Active Directory-Sicherheitskonfiguration

Im Folgenden finden Sie ein Beispiel für die Active Directory-Sicherheitskonfiguration, falls Sie die Unterdomäne und accountPrefix überschreiben möchten.

    "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" ] 
        } 
    }

Im Folgenden finden Sie ein Beispiel für die Endpunktspezifikation für Endpunkte der Steuerungsebene. Sie können beliebige Werte für DNS-Namen verwenden, solange diese eindeutig und vollqualifiziert sind:

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

Fragen

Ist es erforderlich, separate Organisationseinheiten für unterschiedliche Cluster zu erstellen?

Dies ist nicht verpflichtend, jedoch empfehlenswert. Separate Organisationseinheiten für separate Cluster erleichtern Ihnen die Verwaltung der generierten Benutzerkonten.

Wie kann ich das Verhalten vor CU5 in SQL Server 2019 wiederherstellen?

Möglicherweise gibt es Szenarios, in denen Sie den neu eingeführten Parameter subdomain nicht unterstützen können, beispielsweise wenn Sie ein Release vor CU5 bereitstellen müssen und die Azure Data CLI (azdata) bereits aktualisiert haben. Dies ist zwar sehr unwahrscheinlich, wenn Sie das Verhalten vor dem CU5-Release jedoch wiederherstellen müssen, können Sie im Active Directory-Abschnitt von control.json den Parameter useSubdomain auf false festlegen.

Im folgenden Beispiel wird useSubdomain in diesem Szenario auf false festgelegt.

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

Nächste Schritte

Behandeln von Problemen mit der Integration von Active Directory in SQL Server-Big Data-Clustern

Share via