Distribuire più cluster Big Data di SQL Server nello stesso dominio di Active Directory

Articolo
03/18/2023

Si applica a: SQL Server 2019 (15.x)

Questo articolo illustra gli aggiornamenti a SQL Server 2019 aggiornamento cumulativo 5 (CU5), che consente la configurazione di più cluster Big Data di SQL Server 2019. È ora possibile distribuire e integrare vari cluster Big Data con lo stesso Dominio di Active Directory.

Importante

Il componente aggiuntivo per i cluster Big Data di Microsoft SQL Server 2019 verrà ritirato. Il supporto per i cluster Big Data di SQL Server 2019 terminerà il 28 febbraio 2025. Tutti gli utenti esistenti di SQL Server 2019 con Software Assurance saranno completamente supportati nella piattaforma e fino a quel momento il software continuerà a ricevere aggiornamenti cumulativi di SQL Server. Per altre informazioni, vedere il post di blog relativo all'annuncio e Opzioni per i Big Data nella piattaforma Microsoft SQL Server.

Prima di SQL Server 2019 CU5, due problemi impedivano la distribuzione di più cluster Big Data nei domini di Active Directory.

Conflitto di denominazione per i nomi dell'entità servizio e il dominio DNS
Nomi di entità account di dominio

Cosa sono i conflitti dei nomi di oggetto?

Conflitto di denominazione per i nomi di entità servizio e il dominio DNS

Il nome di dominio specificato in fase di distribuzione viene utilizzato come dominio DNS di Active Directory (AD). Ciò significa che i pod possono connettersi tra loro nella rete interna tramite il dominio DNS. Anche gli utenti si connettono agli endpoint dei cluster Big Data tramite tale dominio DNS. Di conseguenza, qualsiasi nome dell'entità servizio (SPN) creato per un servizio all'interno dei cluster Big Data, ha il nome del pod, servizio o endpoint Kubernetes qualificato con questo dominio DNS di Active Directory. Se un utente distribuisce un secondo cluster nel dominio, i nomi SPN generati hanno lo stesso nome di dominio completo poiché i nomi dei pod e i nomi di dominio DNS non sono diversi tra i cluster. Si consideri il caso in cui il dominio DNS di Active Directory è contoso.local. Uno dei nomi SPN generati per il server SQL Server del pool master nel pod master-0 è MSSQLSvc/master-0.contoso.local:1433. Nel secondo cluster in cui l'utente tenta di eseguire la distribuzione, il nome del pod per master-0 è lo stesso. L'utente fornisce lo stesso dominio DNS di Active Directory (contoso.local) che restituisce la stessa stringa SPN. Active Directory impedisce la creazione di un nome SPN in conflitto, provocando un errore di distribuzione per il secondo cluster.

Nomi di entità account di dominio

Durante una distribuzione di cluster Big Data con un dominio di Active Directory, vengono generate più entità di sicurezza account per i servizi in esecuzione nel cluster Big Data. Si tratta essenzialmente di account utente di Active Directory. Prima di SQL 2019 CU5, i nomi per questi account non erano univoci tra i cluster. Ciò si manifesta nel tentativo di creare lo stesso nome di account utente per un particolare servizio nel cluster Big Data in due cluster diversi. Nel secondo cluster in fase di distribuzione si verifica un conflitto in AD e l'account non può essere creato.

Come risolvere i conflitti tra i nomi

Passaggi per risolvere i problemi di dominio SPN e DNS - SQL Server 2019 CU5

I nomi SPN devono essere univoci nei cluster. Il nome di dominio DNS passato in fase di distribuzione deve essere diverso. È possibile specificare nomi DNS diversi con l'impostazione introdotta nel file di configurazione della distribuzione: subdomain. Se il sottodominio è diverso tra due cluster e la comunicazione interna può essere eseguita su questo sottodominio, i nomi SPN includeranno il sottodominio che soddisfa il requisito di univocità.

Nota

Il valore passato tramite l'impostazione del sottodominio non è un nuovo dominio di Active Directory, ma un dominio DNS usato internamente.

Si torni al caso del nome SPN di SQL Server nel pool master. Se il sottodominio è bdc, il nome SPN discusso viene modificato in MSSQLSvc/master-0.bdc.contoso.local:1433.

Il nome del cluster Big Data o il nome dello spazio dei nomi viene usato per calcolare il valore delle impostazioni del sottodominio. Facoltativamente, è possibile personalizzare il valore del parametro del sottodominio introdotto nella specifica di configurazione di Active Directory. Quando gli utenti desiderano eseguire l'override del nome del sottodominio, possono farlo usando il nuovo parametro del sottodominio nella specifica di configurazione di Active Directory.

Come garantire l'univocità dei nomi degli account

Per aggiornare i nomi degli account e garantirne l'univocità, usare i prefissi. Il prefisso è un segmento del nome account univoca tra due cluster. Il segmento rimanente del nome account può essere costante. Il nuovo formato del nome account è simile al seguente: <prefix>-<name>-<podId>.

Nota

In Active Directory la lunghezza del nome account non può superare i 20 caratteri. Il cluster Big Data deve usare 8 dei caratteri per distinguere pod e StatefulSet. Rimangono disponibili 12 caratteri per il prefisso dell'account.

È possibile personalizzare il nome dell'account. Usare il parametro accountPrefix nella configurazione di Active Directory spec. SQL Server 2019 CU5 introduce accountPrefix nella specifica di configurazione. Per impostazione predefinita, il nome del sottodominio viene usato come prefisso dell'account. Se il nome del sottodominio supera i 12 caratteri, come prefisso dell'account viene usata la substring di 12 caratteri iniziale del nome del sottodominio.

Il sottodominio si applica solo al DNS. Il nuovo nome dell'account utente LDAP è quindi bdc-ldap@contoso.local Il nome dell'account non è bdc-ldap@bdc.contoso.local.

semantica

Di seguito sono riportati i parametri aggiunti in SQL Server CU5 2019 per la configurazione di più cluster in un dominio:

`subdomain`

Campo facoltativo
Tipo di dati: string
Definizione: sottodominio DNS univoco da usare per il cluster Big Data. Questo valore deve essere diverso per ogni cluster distribuito nel dominio di Active Directory.
Valore predefinito: se non specificato, come valore predefinito verrà usato il nome del cluster.
Lunghezza massima: 63 caratteri per etichetta (ogni stringa separata da un punto).
Commenti: i nomi DNS degli endpoint devono usare il sottodominio nel relativo FQDN.

`accountPrefix`

Campo facoltativo
Tipo di dati: string
Definizione: prefisso univoco per gli account AD che verranno generati dal cluster Big Data. Questo valore deve essere diverso per ogni cluster distribuito nel dominio di Active Directory.
Valore predefinito: se non specificato, come valore predefinito verrà usato il nome del sottodominio. Quando il sottodominio non è specificato, come nome di sottodominio verrà usato il nome del cluster e, di conseguenza, il nome del cluster verrà ereditato anche come prefisso di account. Se invece il sottodominio è specificato ed è un nome costituito da più parti (contiene uno o più punti), l'utente deve definire un prefisso di account.
Lunghezza massima: 12 caratteri

Modifiche al dominio AD e al server DNS

Non sono necessarie modifiche nel controller di dominio o nel dominio AD per gestire la distribuzione di più cluster Big Data rispetto allo stesso dominio di Active Directory. Il sottodominio DNS verrà creato automaticamente nel server DNS durante la registrazione dei nomi DNS degli endpoint esterni.

Modifiche al file di configurazione della distribuzione

Nella sezione activeDirectory nella configurazione del piano di controllo control.json sono presenti due nuovi parametri facoltativi: subdomain e accountPrefix. Il nome del cluster viene usato per ciascuno di questi parametri. Specificare nuovi valori per queste impostazioni se si desidera eseguire l'override del comportamento predefinito. Il nome del cluster coincide con quello dello spazio dei nomi.

È possibile usare qualsiasi nome DNS dell'endpoint, purché sia completo. Il nome non può essere in conflitto con altri cluster Big Data distribuiti nello stesso dominio. È possibile usare il valore del parametro del sottodominio per garantire che i nomi DNS siano diversi tra i cluster. Si consideri l'endpoint del gateway. È possibile usare il nome gateway per l'endpoint e registrarlo automaticamente nel server DNS. A tale scopo, come parte della distribuzione del cluster Big Data, usare gateway.bdc1.contoso.local come nome DNS. se bdc1 è il sottodominio e contoso.local è il nome di dominio DNS di Active Directory. Altri valori accettabili sono gateway-bdc1.contoso.local o semplicemente gateway.contoso.local.

Alcuni esempi di configurazione della sicurezza in Active Directory

Di seguito è riportato un esempio di configurazione della sicurezza di Active Directory nel caso in cui si voglia eseguire l'override del sottodominio e del prefisso di account.

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

Di seguito è riportato un esempio di specifica degli endpoint del piano di controllo. È possibile usare qualsiasi valore per i nomi DNS, purché siano univoci e completi:

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

Domande

È necessario creare unità organizzative separate per diversi cluster?

Anche se non è necessario, è consigliabile farlo. Specificando unità organizzative separate per cluster distinti è possibile gestire più facilmente gli account utente generati.

Come ripristinare il comportamento precedente alla versione CU5 di SQL 2019?

Il nuovo parametro subdomain introdotto con l'aggiornamento potrebbe non essere utilizzabile in alcuni scenari, ad esempio quando è necessario distribuire una versione precedente alla CU5 ed è già stata aggiornata l'interfaccia della riga di comando Azure Data (azdata). Questo scenario è altamente improbabile, ma se è necessario ripristinare il comportamento precedente alla versione CU5, è possibile impostare il parametro useSubdomain su false nella sezione relativa ad Active Directory di control.json.

L'esempio seguente imposta useSubdomain su false per questo scenario.

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

Passaggi successivi

Risolvere i problemi di integrazione di Active Directory di cluster Big Data di SQL Server

Condividi tramite