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.

Nota

La tornata di funzionalità di novembre 2022 ha introdotto modifiche alla struttura di connettività predefinita di Istanza gestita di SQL. Questo articolo fornisce informazioni sull'architettura corrente e sull'architettura delle istanze non ancora registrate nella tornata di funzionalità. Per altre informazioni, vedere Tornata di funzionalità di novembre 2022.

Tornata di funzionalità, novembre 2022

La tornata di funzionalità di novembre 2022 ha introdotto le modifiche seguenti all'architettura di connettività Istanza gestita di SQL:

  • È stato rimosso l'endpoint di gestione.
  • Le regole del gruppo di sicurezza di rete obbligatorie sono state semplificate (è stata rimossa una regola obbligatoria).
  • Le regole dei gruppi di sicurezza di rete obbligatorie sono state modificate in modo da non includere più il traffico in uscita in AzureCloud sulla porta 443.
  • La tabella di route è stata semplificata (percorsi obbligatori ridotti da 13 a 5).

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 il tipo di connessione di 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 opera sempre nel tipo di connessione proxy.

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 operano sempre nel tipo di connessione proxy.

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

In questa sezione viene fornita un'analisi più attenta dell'architettura di connettività del cluster virtuale di Istanza gestita di SQL. Il diagramma seguente illustra il layout concettuale del cluster virtuale:

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.

Configurazione della subnet con il supporto del servizio

Per migliorare la sicurezza, la gestibilità e la disponibilità dei servizi, Istanza gestita di SQL applica criteri di finalità di rete in alcuni elementi dell'infrastruttura di rete virtuale di Azure. I criteri configurano la subnet, il gruppo di sicurezza di rete associato e la tabella di route per assicurarsi che vengano soddisfatti i requisiti minimi per Istanza gestita di SQL. Questo meccanismo della piattaforma consente di comunicare i requisiti di rete agli utenti in modo trasparente. Il principale obiettivo dei criteri è quello di impedire un'errata configurazione della rete e garantire il normale funzionamento delle istanze gestite SQL e l’impegno del contratto di servizio. Quando si elimina un'istanza gestita, vengono rimossi anche i criteri relativi alle finalità di rete.

Una configurazione della subnet assistita dal servizio si basa sulla funzionalità di delega della subnet rete virtuale per fornire la gestione automatica della configurazione di rete e abilitare gli endpoint di servizio.

Gli endpoint di servizio possono essere usati per configurare le regole del firewall della rete virtuale negli account di archiviazione che conservano i backup e i log di controllo. Anche con gli endpoint di servizio abilitati, i clienti sono invitati a usare collegamento privato di Azure per accedere agli account di archiviazione. collegamento privato offre più isolamento rispetto agli endpoint di servizio.

Importante

A causa delle specifiche della configurazione del piano di controllo, una configurazione della subnet con supporto del servizio non abilita gli endpoint di servizio nei cloud nazionali.

Requisiti di rete

La subnet in cui viene distribuita l’Istanza gestita di SQL deve avere le caratteristiche 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.
  • 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.

Regole di sicurezza obbligatorie con la configurazione della subnet con il supporto del servizio

Per garantire il flusso del traffico di gestione in ingresso, sono necessarie le regole descritte nella tabella seguente. Le regole vengono applicate dai criteri di finalità di rete e non devono essere distribuite dal cliente. Per altre informazioni sull'architettura di connettività e sul traffico di gestione, vedere Architettura di connettività di alto livello.

Nome Porta Protocollo Source (Sorgente) Destination Azione
healthprobe-in Qualsiasi Qualsiasi AzureLoadBalancer subnet Consenti
internal-in Qualsiasi Qualsiasi subnet subnet Consenti

Per garantire il flusso del traffico di gestione in uscita, sono necessarie le regole descritte nella tabella seguente. Per altre informazioni sull'architettura di connettività e sul traffico di gestione, vedere Architettura di connettività di alto livello.

Nome Porta Protocollo Source (Sorgente) Destination Azione
AAD-out 443 TCP subnet AzureActiveDirectory Consenti
OneDsCollector-out 443 TCP subnet OneDsCollector Consenti
internal-out Qualsiasi Qualsiasi subnet subnet Consenti
StorageP-out 443 Qualsiasi subnet Storage.primaryRegion Consenti
StorageS-out 443 Qualsiasi subnet Storage.secondaryRegion Consenti

Route obbligatorie con configurazione della subnet con il supporto del servizio

Le route descritte nella tabella seguente sono necessarie per garantire che il traffico di gestione venga instradato direttamente a una destinazione. Le route vengono applicate dai criteri di finalità di rete e non devono essere distribuite dal cliente. Per altre informazioni sull'architettura della connettività e sul traffico di gestione, vedere Architettura di connettività di alto livello.

Nome Prefisso indirizzo Hop successivo
AzureActiveDirectory AzureActiveDirectory Internet*
OneDsCollector OneDsCollector Internet*
Storage.primaryRegion Storage.primaryRegion Internet*
Storage.secondaryRegion Storage.secondaryRegion Internet*
subnet-to-vnetlocal subnet Rete virtuale

Nota

* Il valore Internet nella colonna Hop successivo indica al gateway di instradare il traffico all'esterno della rete virtuale. Tuttavia, se l'indirizzo di destinazione è per un servizio di Azure, Azure instrada il traffico direttamente al servizio tramite la rete di Azure anziché all'esterno del cloud di Azure. Il traffico tra i servizi di Azure non attraversa Internet, indipendentemente dall'area di Azure in cui si trova la rete virtuale o in cui viene distribuita un'istanza del servizio di Azure. Per altre informazioni, vedere Routing del traffico di rete virtuale.

È possibile aggiungere voci alla tabella di route per indirizzare il traffico con intervalli IP privati locali come destinazione tramite un gateway di rete virtuale o un'appliance di rete virtuale.

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:

  • 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.
  • AzurePlatformDNS: l'uso del tag di servizio AzurePlatformDNS per bloccare la risoluzione DNS della piattaforma renderebbe 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.
  • Zone private di DNS di Azure con un nome riservato per servizi Microsoft: i nomi di dominio seguenti sono nomi riservati: 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 con una zona privata di DNS di Azure associata che usa un nome riservato per servizi Microsoft ha esito negativo. L'associazione di una zona DNS privato di Azure con un nome riservato a una rete virtuale contenente un'istanza gestita rende Istanza gestita di SQL non disponibile. Per altre informazioni sulla configurazione del Collegamento privato, vedere Configurazione DNS dell'endpoint privato di Azure.

Passaggi successivi