Condividi tramite

Architettura della connettività per Istanza gestita di SQL di Azure

  • Articolo

Si applica a:Istanza gestita di SQL di Azure

Questo articolo descrive l’architettura di connettività in Istanza gestita di SQL di Azure e il modo in cui i diversi componenti dirigono il traffico di comunicazione per un’istanza gestita.

Panoramica

In istanza gestita di SQL, è inserita un’istanza nella rete virtuale di Azure e nella subnet dedicata alle istanze gestite. Questa distribuzione fornisce:

  • Indirizzo IP locale di rete virtuale sicuro (VNet-local).
  • La possibilità di connettere una rete locale a un'istanza gestita di SQL.
  • La possibilità di connettere un'istanza gestita di SQL a un server collegato o a un altro archivio dati locale.
  • La possibilità di connettere un'istanza gestita di SQL a risorse di Azure.

Architettura generale della connettività

Istanza gestita di SQL è costituito da componenti del servizio ospitati in un set dedicato di macchine virtuali isolate raggruppate in base a attributi di configurazione simili e unite a un cluster virtuale. Alcuni componenti del servizio vengono distribuiti all'interno della subnet della rete virtuale del cliente, mentre altri servizi operano all'interno di un ambiente di rete protetto gestito da Microsoft.

Diagramma che mostra l'architettura di connettività generale per un'Istanza gestita di SQL di Azure dopo novembre 2022.

Le applicazioni dei clienti possono connettersi a istanze gestite di SQL ed eseguire query su un database e aggiornarlo in una rete virtuale, in una rete virtuale con peering o in una rete connessa tramite VPN o Azure ExpressRoute.

Nel diagramma seguente vengono illustrate le entità che si connettono a un'istanza gestita di SQL. Inoltre, mostra anche le risorse che devono comunicare con un'istanza gestita. Il processo di comunicazione raffigurato nella parte inferiore del diagramma rappresenta gli strumenti e le applicazioni dei clienti che si connettono all'istanza gestita di SQL come origine dati.

Diagramma che mostra le entità nell'architettura di connettività per un'Istanza gestita di SQL di Azure dopo novembre 2022.

Istanza gestita di SQL è una piattaforma distribuita come servizio a tenant singolo che opera in due piani: un piano dati e un piano di controllo.

Il piano dati viene distribuito all'interno della subnet del cliente per compatibilità, connettività e isolamento della rete. Il piano dati dipende da servizi di Azure come Archiviazione di Azure, ID Microsoft Entra (in precedenza Azure Active Directory) per l'autenticazione e servizi di raccolta dei dati di telemetria. Si noterà che il traffico ha origine nelle subnet che contengono Istanza gestita di SQL che passano a tali servizi.

Il piano di controllo include le funzioni di distribuzione, gestione e manutenzione dei servizi di base tramite agenti automatizzati. Questi agenti hanno accesso esclusivo alle risorse di calcolo che gestiscono il servizio. Non è possibile usare ssh o Remote Desktop Protocol per accedere a tali host. Tutte le comunicazioni del piano di controllo vengono crittografate e firmate mediante certificati. Per verificare l'affidabilità delle parti che comunicano, le istanze gestite di SQL controllano costantemente questi certificati rispetto agli elenchi di revoche dei certificati.

Panoramica delle comunicazioni

Le applicazioni possono connettersi a Istanza SQL gestita tramite tre tipi di endpoint: endpoint della rete virtuale locale, endpoint pubblicoe endpoint privati. Questi endpoint presentano proprietà e comportamenti distinti adatti per diversi scenari.

Diagramma che mostra l'ambito di visibilità per gli endpoint locali, pubblici e privati della rete virtuale a un'Istanza gestita di SQL di Azure.

Endpoint locale della rete virtuale

L'endpoint locale della rete virtuale è il modo predefinito per connettersi a Istanza gestita di SQL. È un nome di dominio sotto forma di <mi_name>.<dns_zone>.database.windows.net. Questo nome di dominio viene risolto in un indirizzo IP dall'intervallo degli indirizzi della sottorete. L'endpoint locale della rete virtuale può essere usato per connettere un'istanza gestita di SQL in tutti gli scenari di connettività standard. La porta dell'endpoint locale della rete virtuale è 1433.

L'endpoint locale della rete virtuale supporta tipi di connessione proxy e reindirizzamento.

Quando ci si connette all'endpoint locale della rete virtuale, assicurarsi di usare sempre il suo nome di dominio e consentire il traffico in ingresso sulle porte necessarie nell'intero intervallo di subnet, poiché l'indirizzo IP sottostante potrebbe occasionalmente cambiare.

Endpoint pubblico

L'endpoint pubblico è un nome di dominio nel formato di <mi_name>.public.<dns_zone>.database.windows.net. Questo nome di dominio viene risolto in un indirizzo IP pubblico raggiungibile da Internet. L'endpoint pubblico è adatto per gli scenari in cui un'istanza gestita deve essere accessibile tramite internet pubblico, ad esempio quando ci si connette da una rete virtuale diversa quando il peering o gli endpoint privati non sono disponibili. Gli endpoint pubblici trasportano solo il traffico client e non possono essere usati per la replica dei dati tra due istanze, ad esempio gruppi di failover o collegamento a Istanza gestita. La porta del punto finale pubblico è 3342.

L'endpoint pubblico usa sempre il tipo di connessione proxy indipendentemente dall'impostazione del tipo di connessione.

Quando ci si connette all'endpoint pubblico, usare sempre il nome di dominio e consentire il traffico in ingresso sulla porta 3342 per l'intera gamma di subnet, poiché l'indirizzo IP sottostante può occasionalmente cambiare.

Informazioni su come configurare un endpoint pubblico in Come configurare un endpoint pubblico in Istanza gestita di SQL di Azure.

Endpoint privati

Un endpoint privato è un indirizzo IP fisso facoltativo in un'altra rete virtuale che esegue il traffico verso l'istanza gestita di SQL. Una Istanza gestita di SQL di Azure può avere più endpoint privati in più reti virtuali. Gli endpoint privati trasportano solo il traffico client e non possono essere usati per la replica dei dati tra due istanze, come ad esempio nei gruppi di failover o nel collegamento a Istanza Gestita. La porta dell'endpoint privato è 1143.

Gli endpoint privati usano sempre il tipo di connessione proxy indipendentemente dall'impostazione del tipo di connessione.

Quando ci si connette a un endpoint privato, usare sempre il nome di dominio perché la connessione a Istanza gestita di SQL di Azure tramite il relativo indirizzo IP non è ancora supportata. L'indirizzo IP di un endpoint privato, tuttavia, non cambia.

Per altre informazioni sugli endpoint privati e su come configurarli, vedere collegamento privato di Azure per Istanza gestita di SQL di Azure.

Architettura della connettività del cluster virtuale

Il diagramma seguente illustra il layout concettuale dell’architettura del cluster virtuale:

Diagramma che mostra l'architettura della connettività del cluster virtuale per un'Istanza gestita di SQL di Azure.

Il nome di dominio dell'endpoint locale della rete virtuale viene risolto nell'indirizzo IP privato di un servizio di bilanciamento del carico interno. Anche se questo nome di dominio è registrato in una zona DNS (Domain Name System) pubblico ed è risolvibile pubblicamente, il relativo indirizzo IP appartiene all'intervallo di indirizzi della subnet e può essere raggiunto solo dall'interno della rete virtuale per impostazione predefinita.

Il load balancer indirizza il traffico al gateway dell'istanza gestita. Poiché possono essere eseguite più istanze gestite nello stesso cluster, il gateway usa il nome host dell'istanza gestita SQL come visto nella stringa di connessione per reindirizzare il traffico al servizio del motore SQL corretto.

Quando viene creato il cluster, viene automaticamente generato il valore per dns-zone. Se un nuovo cluster ospita un'istanza gestita secondaria, ne condivide l'ID zona con il cluster principale.

Requisiti di rete

Istanza gestita di SQL di Azure richiede una specifica configurazione di alcuni aspetti della subnet delegata, che è possibile ottenere usando la configurazione della subnet con supporto del servizio. Oltre a ciò che richiede il servizio, gli utenti hanno il pieno controllo della configurazione di rete della subnet e possono ad esempio:

  • Consentire o bloccare il traffico su alcune porte o su tutte
  • Aggiungere voci alla tabella di route per instradare il traffico attraverso appliance di rete virtuale o un gateway
  • Configurare la risoluzione DNS personalizzata o
  • Configurare il peering o di una VPN

Per soddisfare i criteri di "Configurazione di rete conforme" nel Contratto di servizio per Microsoft Online Services, la rete virtuale e la subnet in cui viene distribuita Istanza gestita di SQL devono soddisfare i requisiti seguenti:

  • Subnet dedicata: la subnet Istanza gestita di SQL usa può essere delegata solo al servizio Istanza gestita di SQL. La subnet non può essere una subnet del gateway ed è possibile distribuire solo Istanza gestita di SQL risorse nella subnet.
  • Delega di subnet: La subnet dell'istanza gestita di SQL deve essere delegata al provider di risorse Microsoft.Sql/managedInstances.
  • Gruppo di sicurezza di rete: è necessario associare un gruppo di sicurezza di rete alla subnet di Istanza gestita di SQL. È possibile usare un gruppo di sicurezza di rete per controllare l'accesso all'endpoint dati di Istanza gestita di SQL filtrando il traffico sulla porta 1433 e sulle porte 11000-11999 quando Istanza gestita di SQL è configurata per le connessioni di reindirizzamento. Il servizio eseguirà automaticamente il provisioning delle regole e le manterrà per consentire un flusso ininterrotto del traffico di gestione.
  • Tabella di route: una tabella di route deve essere associata alla subnet Istanza gestita di SQL. È possibile aggiungere voci a questa tabella di route, ad esempio per instradare il traffico in locale tramite un gateway di rete virtuale o per aggiungere la route predefinita 0.0.0.0/0 indirizzando tutto il traffico attraverso un'appliance di rete virtuale, ad esempio un firewall. Istanza gestita di SQL di Azure effettua automaticamente il provisioning e gestisce le voci necessarie nella tabella di route.
  • Indirizzi IP sufficienti: la subnet dell'istanza gestita di SQL deve contenere almeno 32 indirizzi IP. Per altre informazioni, vedere Determinare le dimensioni della subnet per le istanze gestite di SQL. È possibile distribuire le istanze gestite nella rete esistente dopo averla configurata per soddisfare i requisiti di rete per le istanze gestite di SQL. In caso contrario, creare una nuova rete e una nuova subnet.
  • Consentito dai criteri di Azure: se si usano i Criteri di Azure per impedire la creazione o la modifica delle risorse in un ambito che include una subnet o una rete virtuale Istanza gestita di SQL, i criteri non devono impedire Istanza gestita di SQL di gestire le risorse interne. Le risorse seguenti devono essere escluse dagli effetti di negazione dei criteri per il normale funzionamento:
    • Risorse di tipo Microsoft.Network/serviceEndpointPolicies, quando il nome della risorsa inizia con \_e41f87a2\_
    • Tutti i tipi di risorsa Microsoft.Network/networkIntentPolicies
    • Tutti i tipi di risorsa Microsoft.Network/virtualNetworks/subnets/contextualServiceEndpointPolicies
  • Blocchi nelle reti virtuali: i blocchi nella rete virtuale della subnet dedicata, nel gruppo di risorse padre o nella sottoscrizione possono occasionalmente interferire con le operazioni di gestione e manutenzione di Istanza gestita di SQL. Prestare particolare attenzione quando si usano i blocchi della risorsa.
  • record DNS pubblici risolvibili: Se la rete virtuale è configurata per l'uso di un server DNS personalizzato, il server DNS deve essere in grado di risolvere i record DNS pubblici. L'uso di funzionalità come l'autenticazione di Microsoft Entra potrebbe richiedere la risoluzione di più di nomi di dominio completi (FQDN). Per altre informazioni, vedere Risoluzione dei nomi DNS privati in Istanza gestita di SQL di Azure.
  • Record DNS necessari: le istanze gestite dipendono dalla corretta risoluzione di determinati nomi di dominio. Tali nomi di dominio non devono essere sottoposti a override nelle reti virtuali, tramite zone private dns di Azure o da un server DNS personalizzato. In caso contrario, le istanze gestite non riusciranno a distribuirsi o potrebbero non essere disponibili. Non è necessario eseguire l'override dei domini seguenti: windows.net, database.windows.net, core.windows.net, blob.core.windows.net, table.core.windows.net, management.core.windows.net, monitoring.core.windows.net, queue.core.windows.net, graph.windows.net, login.microsoftonline.com, login.windows.net, servicebus.windows.nete vault.azure.net. Si noti, tuttavia, che è comunque possibile creare endpoint privati all'interno della rete virtuale di un'istanza gestita, anche alle risorse nei domini precedenti. Gli endpoint privati usano un meccanismo DNS che non richiede che un server DNS locale diventi autorevole per un'intera zona.
  • Tag AzurePlatformDNS: l'uso del tag del servizio AzurePlatformDNS per bloccare la risoluzione DNS della piattaforma potrebbe rendere non disponibile Istanza gestita di SQL. Anche se l'istanza gestita di SQL supporta il DNS definito dal cliente per la risoluzione DNS all'interno del motore, esiste una dipendenza dal DNS di Azure per le operazioni della piattaforma.

Configurazione della subnet con il supporto del servizio

Per migliorare la sicurezza, la gestibilità e la disponibilità del servizio, Istanza gestita di SQL usa la configurazione della subnet con supporto del servizio e i criteri di finalità della rete nell'infrastruttura di rete virtuale di Azure per configurare la rete, i componenti associati e la tabella di route per garantire che siano soddisfatti i requisiti minimi per Istanza gestita di SQL.

La sicurezza di rete e le regole della tabella di route configurate automaticamente sono visibili al cliente e annotate con uno di questi prefissi:

  • Microsoft.Sql-managedInstances_UseOnly_mi- per le regole e i percorsi obbligatori
  • Microsoft.Sql-managedInstances_UseOnly_mi-optional- per le regole e i percorsi facoltativi

Per altri dettagli, vedere Configurazione della subnet con supporto del servizio.

Per altre informazioni sull'architettura di connettività e sul traffico di gestione, vedere Architettura di connettività di alto livello.

Vincoli di rete

I vincoli seguenti sulle funzionalità della rete virtuale e sul traffico sono effettivi:

  • Subnet private: l'implementazione di istanze gestite in subnet private (in cui l'accesso in uscita predefinito è disabilitato) non è attualmente supportato.
  • Posta elettronica database a inoltro SMTP esterno sulla porta 25: l'invio di posta elettronica del database tramite la porta 25 ai servizi di posta elettronica esterni è disponibile solo per determinati tipi di sottoscrizione in Microsoft Azure. Le istanze in altri tipi di sottoscrizione devono usare una porta diversa (ad esempio, 587) per contattare gli inoltri SMTP esterni. In caso contrario, le istanze potrebbero non recapitare la posta elettronica del database. Per altre informazioni, vedere Risolvere i problemi di connettività SMTP in uscita in Azure.
  • Peering di Microsoft: l’abilitazione della funzione di peering Microsoft in circuiti ExpressRoute con peering diretto o transitivo con la rete virtuale in cui si trova Istanza gestita di SQL influisce sul flusso del traffico tra i componenti di Istanza gestita all'interno della rete virtuale e i servizi da cui dipende. Risultato dei problemi di disponibilità. Le distribuzioni di Istanza gestita di SQL in una rete virtuale con il peering Microsoft già abilitato hanno in genere esito negativo.
  • peering di rete virtuale globale. La connettività del peering di rete virtuale tra le aree di Azure non funziona per le istanze di Istanza Gestita di SQL posizionate nelle subnet create prima del 9 settembre 2020.
  • Peering di reti virtuali: configurazione: quando si stabilisce il peering di reti virtuali tra reti virtuali che contengono subnet con Istanza gestita di SQL, tali subnet devono usare tabelle di route e gruppi di sicurezza di rete diversi. Il riutilizzo della tabella di route e del gruppo di sicurezza di rete in due o più subnet che partecipano al peering di reti virtuali causerà problemi di connettività in tutte le subnet che usano tali tabelle di route o NSG e causeranno l'esito negativo delle operazioni di gestione di Istanza gestita di SQL.
  • Gateway NAT: l'uso del NAT di rete virtuale di Azure per controllare la connettività in uscita con un indirizzo IP pubblico specifico rende l'Istanza gestita di SQL non disponibile. Il servizio Istanza gestita di SQL è attualmente limitato all'uso di un servizio di bilanciamento del carico di base, che non prevede la coesistenza di flussi in ingresso o in uscita con NAT di rete virtuale di Azure.
  • IPv6 per rete virtuale di Azure : la distribuzione di Istanza gestita di SQL in reti virtuali IPv4/IPv6 dual stack avrà esito negativo. Associare un gruppo di sicurezza di rete o una tabella di route con route definite dall'utente (UDR) che contiene prefissi di indirizzi IPv6 a una subnet Istanza gestita di SQL rende Istanza gestita di SQL non disponibile. Inoltre, l'aggiunta di prefissi di indirizzi IPv6 a un gruppo di sicurezza di rete o una route definita dall'utente già associata a una subnet dell'istanza gestita esegue il rendering Istanza gestita di SQL non disponibile. Le distribuzioni di un'istanza gestita di SQL in una subnet con un gruppo di sicurezza di rete o una tabella di route definita dall'utente che dispongono già di prefissi IPv6 hanno esito negativo.
  • TLS 1.2 viene applicato sulle connessioni in uscita: a partire da gennaio 2020, Microsoft ha applicato in tutti i servizi di Azure il protocollo TLS 1.2 per il traffico interno al servizio. Per l’istanza gestita di SQL, è stato quindi applicato il protocollo TLS 1.2 sia per le connessioni in uscita usate per la replica sia per le connessioni del server collegato a SQL Server. Se si usa una versione di SQL Server precedente alla versione 2016 con Istanza gestita di SQL, assicurarsi di applicare gli aggiornamenti specifici di TLS 1.2.
  • fallback interno alDNS di Azure: le istanze gestite dipendono dalla risoluzione DNS funzionante nelle reti virtuali. Se la rete virtuale di un'istanza gestita è configurata per l'uso di server DNS personalizzati e una richiesta DNS inviata a server DNS personalizzati non viene completata entro un determinato intervallo (da 1 a 2 secondi), l'istanza gestita ripeterà la richiesta in dns di Azure in tale rete virtuale.

Contenuto correlato