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 gestita di SQL tramite tre tipi di endpoint. Questi endpoint servono scenari diversi e presentano proprietà e comportamenti di rete distinti.

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. Si tratta di un nome di dominio sotto forma di <mi_name>.<dns_zone>.database.windows.net che viene risolto in un indirizzo IP dal pool di indirizzi della subnet; quindi VNet-local o un endpoint locale per la rete virtuale. L'endpoint locale della rete virtuale può essere usato per connettere un'istanza gestita di SQL in tutti gli scenari di connettività standard.

Gli endpoint locali della rete virtuale supportano entrambi i tipi di connessione di proxy e reindirizzamento.

Quando ci si connette all'endpoint locale della rete virtuale, usare sempre il nome di dominio come l'indirizzo IP sottostante può occasionalmente cambiare.

Endpoint pubblico

L'endpoint pubblico è un nome di dominio facoltativo sotto forma di <mi_name>.public.<dns_zone>.database.windows.net che si risolve in un indirizzo IP pubblico raggiungibile da Internet. L'endpoint pubblico consente al traffico TDS di raggiungere solo Istanza gestita di SQL sulla porta 3342 e non può essere usato per scenari di integrazione, ad esempio gruppi di failover, Istanza gestita collegamento e tecnologie simili.

Quando ci si connette all'endpoint pubblico, usare sempre il relativo nome di dominio perché l'indirizzo IP sottostante può occasionalmente cambiare.

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

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 consentono al traffico TDS di raggiungere solo Istanza gestita di SQL sulla porta 1433 e non possono essere usati per scenari di integrazione, ad esempio gruppi di failover, Istanza gestita collegamento e altre tecnologie simili.

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.

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

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

La subnet in cui viene distribuita l’Istanza gestita di SQL deve rispettare i seguenti requisiti:

  • 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.
  • Traffico di replica: il traffico di replica per i gruppi di failover tra due istanze gestite deve essere diretto e non indirizzato attraverso una rete hub.
  • Server DNS personalizzato: se la rete virtuale include un DNS personalizzato, il server DNS personalizzato deve poter risolvere 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.

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

  • 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.

Con Istanza gestita di SQL non sono attualmente supportate le funzionalità della rete virtuale seguenti:

  • 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 reti virtuali: globale: la connettività peering di reti virtuali tra aree di Azure non funziona per le istanze di Istanza gestita di SQL inserite nelle subnet e 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.
  • Tag AzurePlatformDNS: l'uso del tag del servizio AzurePlatformDNS per bloccare la risoluzione DNS della piattaforma potrebbe rendere non disponibile Istanza gestita di SQL. Sebbene Istanza gestita di SQL supporti un server DNS definito dal cliente per la risoluzione DNS all'interno del motore, esiste una dipendenza dal DNS della piattaforma per le operazioni della piattaforma.
  • 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.
  • Record DNS per i servizi Microsoft riservati: i nomi di dominio seguenti sono riservati e la relativa risoluzione, come definito in DNS di Azure, non deve essere sottoposta a override in una rete virtuale che ospita istanze gestite di hosting: 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.net, e vault.azure.net. La distribuzione di Istanza gestita di SQL in una rete virtuale in cui viene eseguito l'override di uno o più nomi di dominio, tramite zone private di DNS di Azure o da un server DNS personalizzato, avrà esito negativo. L'override della risoluzione di questi domini in una rete virtuale che contiene un'istanza gestita esegue il rendering dell'istanza gestita non disponibile. Per informazioni su come configurare i record DNS di collegamento privato all'interno di una rete virtuale che contiene istanze gestite, vedere Configurazione DNS dell'endpoint privato di Azure.

Contenuto correlato