Distribuire cluster Big Data di SQL Server in modalità AD nei servizi Azure Kubernetes (AKS)
I cluster Big Data di SQL Server supportano la modalità di distribuzione Active Directory (AD) per la gestione delle identità e degli accessi (IAM). La gestione delle identità e degli accessi per il servizio Azure Kubernetes si è rilevata complicata perché i protocolli standard del settore come OAuth 2.0 e OpenID Connect, ampiamente supportati dalla piattaforma per la gestione delle identità Microsoft, non sono supportati da SQL Server.
Questo articolo descrive come distribuire un cluster Big Data in modalità Active Directory durante la distribuzione nel servizio Azure Kubernetes.
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.
Topologie di architettura
Il servizio Active Directory Domain Services (AD DS) viene eseguito in una macchina virtuale di Azure nello stesso modo in cui viene eseguito in molte istanze locali. Dopo aver alzato di livello i nuovi controller di dominio in Azure, impostare i server DNS primario e secondario per la rete virtuale. Gli eventuali server DNS locali verranno abbassati al livello terziario o inferiore. L'autenticazione di AD consente ai client aggiunti a un dominio in Linux di eseguire l'autenticazione per SQL Server usando le proprie credenziali di dominio e il protocollo Kerberos.
Esistono diversi modi per distribuire un cluster Big Data in modalità Active Directory nel servizio Azure Kubernetes. Questo articolo presenta due metodi, che sono più facili da implementare e integrare con le architetture di livello aziendale esistenti:
Estendere il dominio di Active Directory locale ad Azure. Questo metodo consente all'ambiente Active Directory di fornire servizi di autenticazione distribuiti usando Active Directory Domain Services (AD DS) in Azure. È possibile replicare l'istanza locale del servizio Active Directory Domain Services (AD DS) per ridurre la latenza causata dall'invio di richieste di autenticazione dal cloud al servizio AD DS locale. Un caso d'uso tipico per questa soluzione è quando l'applicazione è ospitata in parte in locale e in parte in Azure e le richieste di autenticazione devono essere trasferite avanti e indietro.
Estendere la foresta di risorse di Active Directory Domain Services (AD DS) ad Azure. In questa architettura viene creato un nuovo dominio in Azure considerato attendibile dalla foresta di Active Directory locale. Questa architettura mostra una relazione di trust unidirezionale dal dominio in Azure alla foresta locale.
Le architetture di riferimento descritte in precedenza consentono di creare una zona di destinazione che dispone di tutte le risorse da distribuire da zero o di eventuali soluzioni aggiuntive basate sull'architettura esistente. Oltre a queste architetture di riferimento, è necessario distribuire il cluster Big Data in un cluster del servizio Azure Kubernetes in una subnet separata che si trova nella rete virtuale di destinazione o in una rete virtuale con peering.
L'immagine seguente rappresenta un'architettura tipica:
Consigli
I consigli seguenti si applicano alla maggior parte delle distribuzioni di cluster Big Data in modalità Active Directory nel servizio Azure Kubernetes. Le opzioni disponibili verranno indicate in ogni componente per fornire indicazioni per una migliore integrazione con l'architettura di livello aziendale.
Raccomandazioni di rete
È possibile usare alcuni componenti chiave per connettere l'ambiente locale ad Azure:
- Gateway VPN di Azure: un gateway VPN è un tipo specifico di gateway di rete virtuale usato per inviare traffico crittografato tra una rete virtuale di Azure e una posizione locale attraverso la rete Internet pubblica. Verranno usati sia il gateway di rete virtuale di Azure sia il gateway di rete virtuale locale. Per informazioni su come configurarli, vedere Che cos'è un Gateway VPN?.
- Azure ExpressRoute: le connessioni ExpressRoute non sfruttano la rete Internet pubblica e offrono un livello di sicurezza superiore, maggiore affidabilità, velocità più elevate e minori latenze rispetto alle connessioni Internet tradizionali. La scelta dell'opzione di connettività influirà sulla latenza, sulle prestazioni e sul livello di SLA della soluzione a seconda degli SKU. Per informazioni specifiche, vedere Informazioni sui gateway di rete virtuale per ExpressRoute.
Per accedere ad altre infrastrutture di Azure, la maggior parte dei clienti usa una JumpBox o Azure Bastion. Il collegamento privato di Azure consente di accedere in modo sicuro ai servizi PaaS, di Azure, incluso il servizio Azure Kubernetes in questo scenario, oltre ad altri servizi ospitati di Azure tramite un endpoint privato nella rete virtuale. Il traffico tra la rete virtuale e il servizio attraversa la rete backbone Microsoft, impedendone l'esposizione alla rete Internet pubblica. È anche possibile creare un servizio collegamento privato personale nella rete virtuale e distribuirlo privatamente ai clienti.
Consigli per Active Directory e Azure
Il servizio AD DS locale archivia le informazioni sugli account utente e consente ad altri utenti autorizzati nella stessa rete di accedere a tali informazioni autenticando le identità associate a utenti, computer, applicazioni o altre risorse incluse in un limite di sicurezza. Nella maggior parte degli scenari ibridi, l'autenticazione utente viene eseguita tramite un gateway VPN o una connessione ExpressRoute all'ambiente AD DS locale.
Per la distribuzione di un cluster Big Data in modalità Active Directory, la soluzione per integrare Active Directory locale con Azure deve soddisfare i prerequisiti seguenti:
- Un account di AD con autorizzazioni specifiche per creare account utente, di gruppo e computer all'interno dell'unità organizzativa (OU) specificata nell'istanza di Active Directory locale.
- Un server DNS per risolvere le voci DNS interne. Deve contenere sia record A (ricerca diretta) che record PTR (ricerca inversa) nel server DNS con nomi in questo dominio. Specificare le impostazioni DNS del dominio nel profilo di distribuzione del cluster Big Data.