Condividi tramite

Connettività di rete per le Istanza gestita di SQL abilitate per Azure Arc

  • Articolo

I servizi dati abilitati per Azure Arc supportano due modalità di connettività diverse. Le modalità connesse direttamente e indirettamente distribuiscono un Istanza gestita di SQL abilitato per Azure Arc in esecuzione nei cluster Kubernetes abilitati per Azure Arc con un piano di controllo di Azure Arc.

I componenti dei servizi dati abilitati per Arc sono:

  • Controller dei dati di Azure Arc
  • Connettore Di Azure Arc Active Directory
  • Istanza gestita di SQL abilitata per Azure Arc

Questi componenti comunicano con gli endpoint di Azure Arc, i controller di dominio Active Directory e i server DNS (Domain Name System) in esecuzione in locale e in altri ambienti cloud.

Questo articolo descrive l'architettura di rete, le considerazioni sulla progettazione e le raccomandazioni sulla progettazione per la connessione al piano di controllo di Azure dall'infrastruttura locale o da un'altra infrastruttura cloud. Si apprenderà come gestire e gestire i servizi dati abilitati per Arc e un Istanza gestita di SQL abilitato per Arc in esecuzione nei cluster Kubernetes abilitati per Arc in ambienti locali e in altri ambienti cloud.

Architettura

Il diagramma seguente illustra un'architettura di rete di servizi dati abilitata per Arc che supporta le modalità di rete connesse direttamente e indirettamente.

Diagramma che illustra l'architettura di rete dei servizi dati abilitata per Azure Arc.

Il diagramma dello scenario seguente illustra un esempio di vari servizi consumer che accedono in modo sicuro alle Istanza gestita di SQL abilitate per Arc.

Diagramma che illustra l'architettura di rete dell'accesso sicuro ai servizi dati abilitati per Azure Arc.

Considerazioni relative alla progettazione

  • Esaminare l'area di progettazione della topologia di rete e della connettività delle zone di destinazione di Azure per allineare la connettività di rete dei servizi dati abilitata per Arc con la progettazione della zona di destinazione adottata dall'organizzazione.

  • Esaminare La connettività di rete per Kubernetes abilitata per Azure Arc per comprendere l'architettura di rete e i consigli per prendere decisioni di progettazione corrette per la distribuzione e l'uso di servizi dati abilitati per Arc nel cluster Kubernetes abilitato per Arc. I servizi dati abilitati per Arc usano la connettività di rete Kubernetes abilitata per Azure Arc per la distribuzione e le operazioni del servizio.

  • Esaminare la disponibilità delle funzionalità dei servizi dati abilitati per Arc in base alla modalità di connettività e ai requisiti di rete per i servizi dati abilitati per Azure Arc. Decidere se la modalità connessa direttamente o indirettamente si allinea meglio ai criteri di sicurezza di rete dell'organizzazione della rete locale o di altri provider di servizi cloud.

  • La modalità direttamente connessa richiede una connessione diretta ad Azure e offre altri vantaggi per natura di questa connettività. Prendere in considerazione i compromessi necessari per abilitare questa connessione diretta in base ai requisiti di sicurezza e conformità dell'organizzazione.

  • A seconda della posizione in cui viene eseguito il cluster Kubernetes abilitato per Arc, è consigliabile usare un tipo LoadBalancer oNodePort kubernetes. Questi servizi espongono servizi dati abilitati per Arc, ad esempio il titolare del trattamento dei dati e Istanza gestita di SQL. Un servizio di bilanciamento del carico mantiene lo stesso numero di porta tra più istanze, mentre la porta del nodo richiede numeri di porta diversi per ogni Istanza gestita di SQL abilitata per Arc.

  • Per il servizio di Istanza gestita di SQL abilitato per Arc, è consigliabile distribuire tipi di bilanciamento del carico software, ad esempio MetalLB in ambienti locali e servizi di bilanciamento del carico interni in ambienti basati sul cloud. I servizi di bilanciamento del carico forniscono indirizzi IP coerenti e porte di SQL Server, ad esempio 1433 o porte personalizzate e bilanciano il carico dei nodi nel cluster Kubernetes. Gli indirizzi IP dei nodi cambiano nei cluster con scalabilità automatica. Non offrono disponibilità elevata quando i pod passano da un nodo di lavoro Kubernetes a un altro. Ad esempio, durante il failover, gli aggiornamenti e la manutenzione di cluster Kubernetes, controller dei dati e Istanza gestita di SQL abilitati per Arc.

  • Prendere in considerazione l'uso delle porte TLS (Transport Layer Security), ad esempio 636 e 3269 rispetto alle porte non TLS 389 e 3268 con Active Directory Domain Services. Le porte TLS mantengono protette le connessioni quando si usa l'autenticazione di ACTIVE Directory in un Istanza gestita di SQL abilitato per Azure Arc.

  • Quando si usa Azure Key Vault per proteggere i segreti Kubernetes dei Istanza gestita di SQL abilitati per Arc per l'autenticazione di AD, è consigliabile usare Azure Key Vault endpoint privati per mantenere private le connessioni. Vedere Estensione del provider di segreti di Azure Key Vault per informazioni su come recuperare i segreti nei cluster Kubernetes abilitati per Azure Arc e per altre informazioni sull'uso di Azure Key Vault con cluster Kubernetes abilitati per Arc.

  • Valutare gli endpoint pubblici e privati quando si usa il BLOB di archiviazione dell'account di archiviazione di Azure per conservare i file di backup del database abilitati Istanza gestita di SQL per Arc per la conservazione a lungo termine.

Suggerimenti per la progettazione

  • Esaminare le raccomandazioni per la progettazione di reti Kubernetes abilitate per Azure Arc come Istanza gestita di SQL distribuite in un cluster Kubernetes abilitato per Arc esistente.

  • Usare la modalità connettività diretta anziché la distribuzione della modalità di connettività indiretta dei servizi dati abilitati per Arc e dei Istanza gestita di SQL abilitati per Arc per ottenere i vantaggi della distribuzione in modalità direttamente connessa.

  • Scegliere il tipo di servizio LoadBalancer kubernetes sopra il tipo di servizio NodePort per i servizi dati abilitati per Arc, ad esempio controller dati, dashboard e Istanza gestita di SQL abilitati per Arc. Il tipo LoadBalancer offre resilienza tra gli errori dei nodi Kubernetes, i riavvii dei nodi e la rimozione dei nodi durante l'aggiornamento e la manutenzione dei cluster Kubernetes.

  • Usare i servizi di bilanciamento del carico interni sui servizi di bilanciamento del carico esterni quando si usa l'infrastruttura cloud pubblica per la distribuzione dei servizi dati abilitati per Arc. Il servizio di bilanciamento del carico interno assegna indirizzi IP privati dalla rete virtuale e mantiene privato il traffico del database alla rete interna.

  • Per la distribuzione locale, usare un servizio di bilanciamento del carico in contenitori, ad esempio MetalLB , per supportare il tipo di servizio di bilanciamento del carico. Un servizio di bilanciamento del carico in contenitori semplifica le regole del firewall usando la porta SQL standard 1433. È più facile ricordare rispetto all'uso di porte casuali con il tipo di servizio NodePort . Assicurarsi di allocare una dimensione CIDR della subnet per supportare il numero di istanze gestite di SQL abilitate per Arc distribuite nel cluster Kubernetes abilitato per Azure Arc.

  • Quando si usa l'autenticazione di Active Directory per le Istanza gestita di SQL abilitate per Arc in modalità di tabulazione della chiave gestita dal sistema o gestita dal cliente, assicurarsi di automatizzare la registrazione DNS per gli endpoint di Istanza gestita di SQL abilitati per Arc. L'automazione consente di individuare i servizi usando server DNS locali o altri. Elimina anche il sovraccarico delle operazioni e aggiorna automaticamente gli indirizzi IP quando cambiano o quando si elimina un'istanza del servizio.

  • Usare le regole del firewall per limitare l'accesso di rete agli endpoint di Istanza gestita di SQL, controller dati e dashboard abilitati per Arc per impedire l'accesso da origini non attendibili. Le regole del firewall riducono la superficie di attacco della Istanza gestita di SQL abilitata per Arc e impediscono l'esfiltrazione dei dati.

  • Quando si usano gli endpoint privati di Azure per Registro artefatti Microsoft (noto anche come Registro Azure Container o MCR), Azure Key Vault, Azure Log Analytics e account di archiviazione, configurare i server DNS locali per inoltrare query DNS al server d'inoltro DNS in Azure. Questo approccio consente l'individuazione automatica di questi endpoint privati usando nomi DNS ed elimina la necessità di usare le voci host o la registrazione delle voci DNS nei server DNS locali.

  • L'autenticazione di Active Directory per le Istanza gestita di SQL abilitate per Arc richiede una connessione a Active Directory Domain Services. Configurare la connettività ai controller di dominio nei siti di ripristino di emergenza e primari per la disponibilità elevata. Poiché molte aziende distribuiscono foreste di ripristino del sito tra aree geografiche, usare il sito più vicino per ridurre la latenza di rete ai controller di dominio. Per altre indicazioni, vedere La continuità aziendale e il ripristino di emergenza abilitati Istanza gestita di SQL per Arc.

Passaggi successivi

Per altre informazioni sul cloud ibrido e sul percorso multicloud, vedere gli articoli seguenti: