Condividi tramite

Distribuire un cluster Big Data di SQL Server in modalità Active Directory

Questo articolo descrive come distribuire un cluster Big Data di SQL Server in modalità Active Directory. I passaggi descritti in questo articolo richiedono l'accesso a un dominio di Active Directory. Prima di procedere, è necessario completare i requisiti descritti in Distribuire cluster Big Data di SQL Server in modalità Active Directory.

Important

I cluster Big Data di Microsoft SQL Server 2019 sono stati ritirati. Il supporto per i cluster Big Data di SQL Server 2019 è terminato a partire dal 28 febbraio 2025. Per altre informazioni, vedere il post di blog sull'annuncio e le opzioni per Big Data nella piattaforma Microsoft SQL Server.

Prepare deployment

Per la distribuzione di un cluster Big Data con l'integrazione di Active Directory, sono disponibili alcune informazioni aggiuntive per la creazione di oggetti correlati ai cluster Big Data in Active Directory.

Usando il profilo kubeadm-prod (o openshift-prod a partire dalla versione CU5), si hanno automaticamente i segnaposto per le informazioni necessarie alla sicurezza e quelle relative all'endpoint richieste per l'integrazione di Active Directory.

È inoltre necessario specificare le credenziali che i cluster Big Data useranno per creare gli oggetti necessari in ACTIVE Directory. Queste credenziali vengono fornite come variabili di ambiente.

Traffico e porte

Verificare che tutti i firewall o le applicazioni di terze parti consentano le porte necessarie per la comunicazione di Active Directory.

Diagramma del traffico tra cluster Big Data e Active Directory. Il controller, il servizio di supporto della sicurezza e altri servizi cluster parlano tramite LDAP/Kerberos ai controller di dominio. Il servizio proxy DNS dei cluster Big Data parla tramite DNS ai server DNS.

Le richieste vengono effettuate su questi protocolli da e verso i servizi del cluster Kubernetes nel dominio di Active Directory e pertanto devono essere permesse sia in entrata che in uscita in qualsiasi firewall o applicazione di terze parti in ascolto sulle porte richieste per TCP e UDP. I numeri di porta standard usati da Active Directory:

Service Port
DNS 53
LDAP
LDAPS		 389
636
Kerberos 88
Protocollo di Modifica Password Kerberos/AD 464
Porta del Global Catalog
via LDAP
via LDAPS
3268
3269

Impostare le variabili di ambiente di sicurezza

Le variabili di ambiente seguenti forniscono le credenziali per l'account del servizio di dominio Cluster Big Data, che verrà usato per configurare l'integrazione di ACTIVE Directory. Questo account viene usato anche dai cluster Big Data per mantenere gli oggetti di Active Directory correlati in futuro.

export DOMAIN_SERVICE_ACCOUNT_USERNAME=<AD principal account name>
export DOMAIN_SERVICE_ACCOUNT_PASSWORD=<AD principal password>

Fornire i parametri di sicurezza e degli endpoint

Oltre alle variabili di ambiente per le credenziali, è anche necessario fornire informazioni sulla sicurezza e sull'endpoint per il funzionamento dell'integrazione di ACTIVE Directory. I parametri necessari fanno automaticamente parte del kubeadm-prod/openshift-prodprofilo di distribuzione.

L'integrazione di ACTIVE Directory richiede i parametri seguenti. Aggiungere questi parametri ai file control.json e bdc.json usando i comandi config replace indicati più avanti in questo articolo. Tutti gli esempi seguenti usano il dominio contoso.localdi esempio .

  • security.activeDirectory.ouDistinguishedName: nome distinto di un'unità organizzativa in cui verranno aggiunti tutti gli account AD creati dalla distribuzione del cluster. Se il dominio viene chiamato contoso.local, il nome distinto dell'unità organizzativa è: OU=BDC,DC=contoso,DC=local.

  • security.activeDirectory.dnsIpAddresses: contiene l'elenco degli indirizzi IP dei server DNS del dominio.

  • security.activeDirectory.domainControllerFullyQualifiedDns: elenco di FQDN del controller di dominio. Il nome di dominio completo (FQDN) contiene il nome del computer/host del controller di dominio. Se sono presenti più controller di dominio, è possibile fornire un elenco qui. Esempio: HOSTNAME.CONTOSO.LOCAL.

    Important

    Quando più controller di dominio servono un dominio, usare il controller di dominio primario (PDC) come prima voce nell'elenco domainControllerFullyQualifiedDns nella configurazione di sicurezza. Per ottenere il nome PDC, digitare netdom query fsmo, al prompt dei comandi e quindi premere INVIO.

  • security.activeDirectory.realm Parametro facoltativo: nella maggior parte dei casi, l'ambito è pari al nome di dominio. Per i casi in cui non sono uguali, usare questo parametro per definire il nome dell'area di autenticazione , ad esempio CONTOSO.LOCAL. Il valore fornito per questo parametro dovrebbe essere completamente qualificato.

  • security.activeDirectory.netbiosDomainName Parametro facoltativo: nome NETBIOS del dominio di Active Directory. Nella maggior parte dei casi, questa sarà la prima etichetta del nome di dominio di Active Directory. Nei casi in cui differisce, usare questo parametro per definire il nome di dominio NETBIOS. Questo valore non deve contenere punti. In genere questo nome viene usato per qualificare gli account utente nel dominio. Ad esempio, CONTOSO\user, dove CONTOSO è il nome di dominio NETBIOS.

    Note

    Il supporto per una configurazione in cui il nome di dominio di Active Directory è diverso dal nome NETBIOS del dominio Active Directory usando security.activeDirectory.netbiosDomainName è stato abilitato a partire da SQL Server 2019 CU9.

  • security.activeDirectory.domainDnsName: nome del dominio DNS che verrà usato per il cluster , ad esempio contoso.local.

  • security.activeDirectory.clusterAdmins: questo parametro accetta un gruppo di Active Directory. L'ambito del gruppo di Active Directory deve essere universale o globale. I membri di questo gruppo avranno il ruolo del bdcAdmin cluster che consentirà loro le autorizzazioni di amministratore nel cluster. Ciò significa che dispongono sysadmin di autorizzazioni in SQL Server, superuser autorizzazioni in HDFS e autorizzazioni di amministratore quando si è connessi all'endpoint controller.

    Important

    Creare questo gruppo in ACTIVE Directory prima dell'inizio della distribuzione. Se l'ambito di questo gruppo di Active Directory è locale al dominio, la distribuzione fallisce.

  • security.activeDirectory.clusterUsers: elenco dei gruppi di Active Directory che sono utenti normali (senza autorizzazioni di amministratore) nel cluster Big Data. L'elenco può includere gruppi di Active Directory che hanno come ambito gruppi universali o globali. Non possono essere gruppi locali di dominio.

I gruppi di Active Directory in questo elenco vengono mappati al ruolo del bdcUser cluster Big Data e devono essere concessi l'accesso a SQL Server (vedere Autorizzazioni di SQL Server) o HDFS (vedere Guida alle autorizzazioni di HDFS). Quando si è connessi all'endpoint controller, questi utenti possono elencare solo gli endpoint disponibili nel cluster usando azdata bdc endpoint list il comando .

Per informazioni dettagliate su come aggiornare i gruppi di Active Directory per queste impostazioni, vedere Gestire l'accesso al cluster Big Data in modalità Active Directory.

Tip

Per abilitare l'esperienza di esplorazione HDFS quando si è connessi al master di SQL Server in Azure Data Studio, è necessario concedere a un utente con ruolo bdcUser le autorizzazioni VIEW SERVER STATE perché Azure Data Studio usa la sys.dm_cluster_endpoints DMV per ottenere l'endpoint del gateway Knox necessario per connettersi a HDFS.

Important

Creare questi gruppi in ACTIVE Directory prima dell'inizio della distribuzione. Se l'ambito per uno di questi gruppi AD è dominio locale, l'implementazione fallisce.

Important

Se gli utenti del dominio hanno un numero elevato di appartenenze ai gruppi, è necessario modificare i valori per l'impostazione del gateway (il valore predefinito è httpserver.requestHeaderBuffer) e l'impostazione 8192hadoop.security.group.mapping.ldap.search.group.hierarchy.levels HDFS (il valore predefinito è 10), usando il file di configurazione della distribuzione bdc.json personalizzato. Si tratta di una procedura consigliata per evitare timeout di connessione al gateway e/o alle risposte HTTP con un codice di stato 431 (campi di intestazione richiesta troppo grandi). Ecco una sezione del file di configurazione che mostra come definire i valori di queste impostazioni e quali sono i valori consigliati per un numero maggiore di appartenenze ai gruppi:

{
    ...
    "spec": {
        "resources": {
            ...
            "gateway": {
                "spec": {
                    "replicas": 1,
                    "endpoints": [{...}],
                    "settings": {
                        "gateway-site.gateway.httpserver.requestHeaderBuffer": "65536"
                    }
                }
            },
            ...
        },
        "services": {
            ...
            "hdfs": {
                "resources": [...],
                "settings": {
                  "core-site.hadoop.security.group.mapping.ldap.search.group.hierarchy.levels": "4"
                }
            },
            ...
        }
    }
}
  • security.activeDirectory.enableAES Optional parameter Parametro facoltativo: valore booleano che indica se AES 128 e AES 256 devono essere abilitati negli account AD generati automaticamente. Il valore predefinito è false. Quando questo parametro è impostato su true, i flag seguenti "Questo account supporta la crittografia Kerberos AES a 128 bit" e "Questo account supporta la crittografia Kerberos AES a 256 bit" verrà controllato sugli oggetti AD generati automaticamente durante la distribuzione del cluster Big Data.

Note

Il security.activeDirectory.enableAES parametro è disponibile a partire da CLUSTER Big Data di SQL Server CU13. Se il cluster Big Data è una versione precedente a CU13, sono necessari i passaggi seguenti:

  1. Eseguire il azdata bdc rotate -n <your-cluster-name> comando , questo comando ruota i keytab nel cluster, che è necessario per assicurarsi che le voci AES nei keytab siano corrette. Per altre informazioni, vedere azdata bdc. Inoltre, azdata bdc rotate ruoterà le password degli oggetti di Active Directory generati automaticamente durante la distribuzione iniziale nell'unità organizzativa specificata.
  2. Impostare i flag seguenti "Questo account supporta la crittografia Kerberos AES a 128 bit" e "Questo account supporta la crittografia Kerberos AES a 256 bit" in ogni oggetto AD generato automaticamente nell'unità organizzativa fornita durante la distribuzione iniziale del cluster Big Data. A tale scopo, è possibile eseguire lo script Get-ADUser -Filter * -SearchBase '<OU Path>' | Set-ADUser -replace @{ 'msDS-SupportedEncryptionTypes' = '24' } di PowerShell seguente nel controller di dominio che imposta i campi AES per ogni account nell'unità organizzativa specificata nel <OU Path> parametro .

Important

Creare i gruppi forniti per le impostazioni seguenti in AD prima dell'inizio della distribuzione. Se l'ambito per uno di questi gruppi AD è dominio locale, l'implementazione fallisce.

  • security.activeDirectory.appOwners Parametro facoltativo: elenco di gruppi di Active Directory che dispongono delle autorizzazioni per creare, eliminare ed eseguire qualsiasi applicazione. L'elenco può includere gruppi di Active Directory che hanno come ambito gruppi universali o globali. Non possono essere gruppi locali di dominio.

  • security.activeDirectory.appReaders Parametro facoltativo: elenco dei gruppi di Active Directory che dispongono delle autorizzazioni per eseguire qualsiasi applicazione. L'elenco può includere gruppi di Active Directory che hanno come ambito gruppi universali o globali. Non possono essere gruppi locali di dominio.

La tabella seguente illustra il modello di autorizzazione per la gestione delle applicazioni:

Authorized roles Comando Azure Data CLI (azdata)
appOwner azdata app create (crea applicazione)
appOwner azdata aggiorna applicazione
appOwner, appReader azdata elenco delle app
appOwner, appReader azdata applicazione descrivere
appOwner azdata app delete
appOwner, appReader azdata app run

  • security.activeDirectory.subdomain: parametro facoltativo Questo parametro è stato introdotto nella versione DI SQL Server 2019 CU5 per supportare la distribuzione di più cluster Big Data nello stesso dominio. Usando questa impostazione, è possibile specificare nomi DNS diversi per ogni cluster Big Data distribuito. Se il valore di questo parametro non viene specificato nella sezione active directory del control.json file, per impostazione predefinita, il nome del cluster Big Data (uguale al nome dello spazio dei nomi Kubernetes) verrà usato per calcolare il valore dell'impostazione del sottodominio.

    Note

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

    Important

    È necessario installare o aggiornare la versione più recente dell'interfaccia della riga di comando dei dati di Azure (azdata) a partire dalla versione DI SQL Server 2019 CU5 per sfruttare queste nuove funzionalità e distribuire più cluster Big Data nello stesso dominio.

    Vedere Concetto: distribuire cluster Big Data di SQL Server in modalità Active Directory per altri dettagli sulla distribuzione di più cluster Big Data nello stesso dominio di Active Directory.

  • security.activeDirectory.accountPrefix: parametro facoltativo Questo parametro è stato introdotto nella versione DI SQL Server 2019 CU5 per supportare la distribuzione di più cluster Big Data nello stesso dominio. Questa impostazione garantisce l'univocità dei nomi degli account per vari servizi cluster Big Data, che devono essere diversi tra due cluster. La personalizzazione del nome del prefisso dell'account è facoltativa. Per impostazione predefinita, il nome del sottodominio viene usato come prefisso dell'account. Se il nome del sottodominio supera i 12 caratteri, i primi 12 caratteri del nome del sottodominio vengono usati come prefisso dell'account.

    Note

    Active Directory richiede che i nomi degli account siano limitati a 20 caratteri. Il cluster Big Data deve usare 8 caratteri per distinguere pod e StatefulSet. Questo ci lascia 12 caratteri come limite per il prefisso dell'account

Controllare l'ambito del gruppo di Active Directory per determinare se è Domain Local.

Se il file di configurazione della distribuzione non è già stato inizializzato, è possibile eseguire questo comando per ottenere una copia della configurazione. Gli esempi seguenti usano il kubeadm-prod profilo, lo stesso vale per openshift-prod.

azdata bdc config init --source kubeadm-prod  --target custom-prod-kubeadm

Per impostare i parametri precedenti nel file control.json, usare i seguenti comandi della CLI (azdata) di Azure Data. I comandi sostituiscono la configurazione e forniscono valori personalizzati prima della distribuzione.

Important

Nella versione di SQL Server 2019 CU2, la struttura della sezione relativa alla configurazione di sicurezza nel profilo di distribuzione è cambiata leggermente e tutte le impostazioni correlate ad Active Directory si trovano nella nuova struttura dell'albero activeDirectorysecurity JSON nel file control.json.

Note

Oltre a fornire valori diversi per il sottodominio, come descritto in questa sezione, è necessario usare anche numeri di porta diversi per gli endpoint dei cluster Big Data durante la distribuzione di più cluster Big Data nello stesso cluster Kubernetes. Questi numeri di porta sono configurabili in fase di distribuzione tramite i profili di configurazione della distribuzione .

L'esempio seguente si basa sull'uso di SQL Server 2019 CU2. Illustra come sostituire i valori dei parametri correlati ad AD nella configurazione della distribuzione. I dettagli del dominio seguenti sono valori di esempio.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

Facoltativamente, solo a partire dalla versione CU5 di SQL Server 2019, è possibile sostituire i valori predefiniti per le impostazioni subdomain e accountPrefix.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.subdomain=[\"bdctest\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.accountPrefix=[\"bdctest\"]"

Analogamente, nelle versioni precedenti a SQL Server 2019 CU2 è possibile eseguire:

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

Oltre alle informazioni precedenti, è anche necessario fornire nomi DNS per i diversi endpoint del cluster. Le voci DNS che usano i nomi DNS specificati verranno create automaticamente nel server DNS al momento della distribuzione. Questi nomi verranno usati per la connessione ai diversi endpoint del cluster. Ad esempio, se il nome DNS per l'istanza master SQL è mastersql e considerando che il sottodominio userà il valore predefinito del nome del cluster in control.json, si userà mastersql.contoso.local,31433 o mastersql.mssql-cluster.contoso.local,31433 (a seconda dei valori specificati nei file di configurazione della distribuzione per i nomi DNS dell'endpoint) per connettersi all'istanza master dagli strumenti.

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[1].dnsName=<monitoring services DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[0].dnsName=<SQL Master Primary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[1].dnsName=<SQL Master Secondary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.gateway.spec.endpoints[0].dnsName=<Gateway (Knox) DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.appproxy.spec.endpoints[0].dnsName=<app proxy DNS name>.<Domain name. e.g. contoso.local>"

Important

È possibile usare i nomi DNS degli endpoint di propria scelta purché siano completi e non siano in conflitto tra due cluster Big Data distribuiti nello stesso dominio. Facoltativamente, è possibile usare il valore del subdomain parametro per assicurarsi che i nomi DNS siano diversi tra i cluster. For example:

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.<subdomain e.g. mssql-cluster>.contoso.local"

È possibile trovare uno script di esempio qui per la distribuzione di un cluster Big Data di SQL Server in un cluster Kubernetes a nodo singolo (kubeadm) con l'integrazione di ACTIVE Directory.

Note

Potrebbero esserci scenari in cui non è possibile contenere il parametro appena introdotto subdomain . Ad esempio, è necessario distribuire una versione precedente alla cu5 ed è già stata aggiornata l'interfaccia della riga di comando dei dati di Azure (azdata). Questo comportamento è molto improbabile, ma se è necessario ripristinare il comportamento pre-CU5, è possibile impostare useSubdomain il parametro su false nella sezione active directory di control.json. Di seguito è riportato il comando per eseguire questa operazione:

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

È ora necessario impostare tutti i parametri necessari per una distribuzione di cluster Big Data con l'integrazione di Active Directory.

È ora possibile distribuire il cluster Big Data integrato con Active Directory usando il comando dell'interfaccia della riga di comando di Azure (azdata) e il profilo di distribuzione kubeadm-prod. Per la documentazione completa su come distribuire cluster Big Data, vedere How to deploy SQL Server Big Data Clusters on Kubernetes (Come distribuire cluster Big Data di SQL Server in Kubernetes).

Verificare la voce DNS inversa per il controller di dominio

Assicurarsi che sia presente una voce DNS inversa (record PTR) per il controller di dominio stesso, registrata nel server DNS. È possibile verificarlo utilizzando nslookup per cercare l'indirizzo IP del controller di dominio e verificare che l'indirizzo IP possa essere risolto nel FQDN del controller di dominio.

Problemi noti e limitazioni

Limitazioni da tenere presente in SQL Server 2019 CU5

  • Attualmente, i dashboard di ricerca dei log e delle metriche non supportano l'autenticazione di Active Directory. Il nome utente e la password di base impostati al momento della distribuzione possono essere usati per l'autenticazione a questi dashboard. Tutti gli altri endpoint del cluster supportano l'autenticazione di Active Directory.

  • La modalità AD sicura funziona solo negli ambienti di distribuzione kubeadm e openshift, e attualmente non in AKS o ARO. I kubeadm-prod profili di distribuzione e openshift-prod includono le sezioni di sicurezza per impostazione predefinita.

  • Prima della versione di SQL Server 2019 CU5, è consentito un solo cluster Big Data per dominio (Active Directory). L'abilitazione di più cluster Big Data per dominio è disponibile a partire dalla versione CU5.

  • Nessuno dei gruppi di Active Directory specificati nelle configurazioni di sicurezza può avere ambito DomainLocal. È possibile controllare l'ambito di un gruppo di Active Directory seguendo queste istruzioni.

  • Gli account AD che possono essere usati per accedere al cluster Big Data sono consentiti dallo stesso dominio configurato per i cluster Big Data di SQL Server. L'abilitazione degli accessi da altri domini attendibili non è supportata.

Next steps

Connettere cluster Big Data di SQL Server: modalità Active Directory

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

Concetto: distribuire cluster Big Data di SQL Server in modalità Active Directory

  • Last updated on