Condividi tramite

Architettura della connettività per Istanza gestita di SQL di Azure

Si applica a:Istanza gestita di SQL di Azure

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

Panoramica

In Istanza gestita di SQL un'istanza viene inserita all'interno della rete virtuale di Azure e all'interno della subnet dedicata alle istanze gestite di SQL. 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 è costituita da componenti del servizio ospitati in un set dedicato di macchine virtuali isolate raggruppate in base a attributi di configurazione simili e uniti 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 sicuro 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. Mostra anche le risorse che devono comunicare con un'istanza gestita di SQL. 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 Azure Storage, Microsoft Entra ID (in precedenza Azure Active Directory) per l'autenticazione e i servizi di raccolta telemetrica. 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. Il nome di dominio dell'endpoint locale della rete virtuale è 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. Usare l'endpoint locale della rete virtuale per connettersi a un'istanza gestita di SQL in tutti gli scenari di connettività standard. L'endpoint locale della rete virtuale accetta connessioni sulla porta 1433.

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

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

Per trovare il nome di dominio dell'endpoint locale della rete virtuale per un'istanza:

  • Portale di Azure: nel riquadro Panoramica , nella sezione Informazioni di base, il valore Host mostra il nome di dominio dell'endpoint locale della rete virtuale.
  • PowerShell: Get-AzSqlInstance -ResourceGroupName <resource-group> -Name <mi-name> mostra il nome di dominio dell'endpoint locale VNet come fullyQualifiedDomainName proprietà.
  • Interfaccia della riga di comando di Azure: az sql mi show -g <resource-group> -n <mi-name> mostra il nome di dominio dell'endpoint locale della rete virtuale come fullyQualifiedDomainName proprietà.

Per una maggiore sicurezza, specificare una connessione crittografata e non considerare attendibile il certificato. Per altre informazioni, vedi Panoramica sulla sicurezza.

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 di SQL deve essere accessibile tramite la rete Internet pubblica. 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. L'endpoint pubblico accetta connessioni sulla porta 3342.

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

Il nome di dominio dell'endpoint pubblico di un'istanza è uguale al nome dell'endpoint locale della rete virtuale con l'etichetta public inserita tra il nome host e il resto del dominio: <mi-name>.public.<dns-zone>.database.windows.net.

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, ad esempio gruppi di failover o collegamento a Istanza gestita. L'endpoint privato accetta connessioni sulla porta 1433.

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

Il nome di dominio dell'endpoint privato di un'istanza è uguale al nome di dominio locale della rete virtuale, a meno che l'endpoint non sia stato configurato in modo diverso. Questo è il caso in cui sia l'endpoint privato che l'endpoint locale della rete virtuale si trovano nella stessa rete virtuale. Per altre informazioni, vedere Configurare la risoluzione dei nomi di dominio per l'endpoint privato.

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é più istanze gestite di SQL possono essere eseguite all'interno dello stesso cluster, il gateway usa il nome host di Istanza gestita di SQL come illustrato 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 cluster appena creato ospita un'istanza gestita di SQL secondaria, condivide l'ID zona con il cluster primario.

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 o tutte le porte.
  • Aggiunta di voci alla tabella di routing per indirizzare il traffico attraverso dispositivi di rete virtuali o gateway.
  • Configurazione della risoluzione DNS personalizzata.
  • Configurazione del peering o di una VPN.

Per soddisfare i criteri di configurazione di rete conformi 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 in ingresso sulla porta 1433. 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 istanze gestite di SQL all'interno di una rete esistente dopo averla configurata per soddisfare i requisiti di rete per Istanza gestita 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 nella rete virtuale: i blocchi nella rete virtuale della subnet dedicata, nel relativo 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 di SQL 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 di SQL non verranno distribuite 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. È comunque possibile creare endpoint privati all'interno della rete virtuale di un'istanza gestita di SQL, anche per le risorse nei domini indicati in precedenza. 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 assistita dal 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: la distribuzione di istanze gestite di SQL in subnet private (in cui l'accesso in uscita predefinito è disabilitato) non è attualmente supportato.
  • La crittografia VNet: la distribuzione e il funzionamento delle istanze di SQL gestite nelle reti virtuali in cui è attualmente abilitata la crittografia della rete virtuale di Azure non è supportata.
  • 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à di peering di rete virtuale tra aree di Azure non funziona per le istanze gestite di SQL inserite nelle subnet create prima del 9 settembre 2020.
  • Peering di rete virtuale – configurazione: quando si stabilisce il peering di rete virtuale tra reti virtuali che contengono subnet con istanze gestite di SQL, tali subnet devono usare tabelle di route e gruppi di sicurezza di rete diversi tra loro. 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 di NAT della rete virtuale di Azure per controllare la connettività in uscita con un indirizzo IP pubblico specifico non è attualmente supportato.
  • 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 a una UDR già associata a una subnet di un'istanza gestita di SQL rende l'istanza 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.
  • Ripiego interno su DNS di Azure: Le istanze gestite di SQL richiedono una risoluzione DNS funzionale nelle loro reti virtuali. Se la rete virtuale di un'istanza gestita di SQL è configurata per l'uso di server DNS personalizzati e una richiesta DNS inviata ai server DNS personalizzati non viene completata entro un determinato intervallo (1-2 secondi), l'istanza gestita di SQL ripeterà la richiesta sul DNS di Azure in tale rete virtuale.

Contenuto correlato

  • Last updated on