Panoramica della rete per Database di Azure per PostgreSQL - Server flessibile con accesso privato (integrazione rete virtuale)

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

Questo articolo descrive i concetti di connettività e rete per Database di Azure per PostgreSQL server flessibile.

Quando si crea un'istanza del server flessibile Database di Azure per PostgreSQL, è necessario scegliere una delle opzioni di rete seguenti: Accesso privato (integrazione rete virtuale) o Accesso pubblico (indirizzi IP consentiti) ed Endpoint privato. Questo documento descrive l'opzione di rete Accesso privato (integrazione rete virtuale).

Accesso privato (integrazione rete virtuale)

È possibile distribuire un'istanza del server flessibile Database di Azure per PostgreSQL nella rete virtuale di Azure usando l'inserimento della rete virtuale. Le reti virtuali di Azure forniscono comunicazioni private e sicure. Le risorse in una rete virtuale possono comunicare tramite indirizzi IP privati assegnati in questa rete.

Scegliere questa opzione di rete se si desiderano le funzionalità seguenti:

• Connessione dalle risorse di Azure nella stessa rete virtuale all'istanza del server flessibile Database di Azure per PostgreSQL usando indirizzi IP privati.
• Usare VPN o Azure ExpressRoute per connettersi da risorse non di Azure all'istanza del server flessibile Database di Azure per PostgreSQL.
• Assicurarsi che l'istanza del server flessibile Database di Azure per PostgreSQL non disponga di un endpoint pubblico accessibile tramite Internet.

Nel diagramma precedente:

• Le istanze del server flessibile di Database di Azure per PostgreSQL vengono inserite nella subnet 10.0.1.0/24 della rete virtuale VNet-1.
• Le applicazioni distribuite in subnet diverse all'interno della stessa rete virtuale possono accedere direttamente Database di Azure per PostgreSQL istanze del server flessibili.
• Le applicazioni distribuite in una rete virtuale diversa (VNet-2) non hanno accesso diretto alle istanze del server flessibile Database di Azure per PostgreSQL. È necessario eseguire il peering di rete virtuale per una zona DNS privata prima di poter accedere al server flessibile.

Concetti relativi alla rete virtuale

Una rete virtuale di Azure contiene uno spazio di indirizzi IP privato configurato per l'uso. La rete virtuale deve trovarsi nella stessa area di Azure dell'istanza del server flessibile Database di Azure per PostgreSQL. Per altre informazioni sulle reti virtuali, vedere panoramica di Azure Rete virtuale.

Ecco alcuni concetti da conoscere quando si usano reti virtuali in cui le risorse sono integrate nella rete virtuale con istanze di server flessibili Database di Azure per PostgreSQL:

• Subnet delegata. Una rete virtuale contiene subnet (subnetworks). Le subnet consentono di segmentare la rete virtuale in spazi indirizzi più piccoli. Le risorse di Azure vengono distribuite in subnet specifiche all'interno di una rete virtuale.

  La rete virtuale integrata Database di Azure per PostgreSQL'istanza del server flessibile deve trovarsi in una subnet delegata. Ovvero, solo Database di Azure per PostgreSQL istanze di server flessibili possono usare tale subnet. Gli altri tipi di risorsa di Azure non possono trovarsi nella subnet delegata. Delegare una subnet assegnando la relativa proprietà di delega come Microsoft.DBforPostgreSQL/flexibleServers. L'intervallo CIDR più piccolo che è possibile specificare per la subnet è /28, che fornisce 16 indirizzi IP, ma il primo e l'ultimo indirizzo in qualsiasi rete o subnet non possono essere assegnati a un singolo host. Azure riserva cinque indirizzi IP da usare internamente dalla rete di Azure, che includono due indirizzi IP che non possono essere assegnati all'host, menzionati in precedenza. Ciò lascia 11 indirizzi IP disponibili per l'intervallo CIDR /28, mentre una singola istanza del server flessibile Database di Azure per PostgreSQL con funzionalità a disponibilità elevata utilizza quattro indirizzi. Per le connessioni Replication e Microsoft Entra, assicurarsi che le tabelle di route non influiscano sul traffico. Un modello comune viene instradato tutto il traffico in uscita tramite un Firewall di Azure o un'appliance di filtro di rete locale personalizzata. Se alla subnet è associata una tabella di route per instradare tutto il traffico a un'appliance virtuale:

  • Aggiungere una regola con tag del servizio di destinazione "AzureActiveDirectory" e hop successivo "Internet"
  • Aggiungere una regola con intervallo IP di destinazione uguale all'intervallo di subnet del server flessibile Database di Azure per PostgreSQL e all'hop successivo "Rete virtuale"

  Importante

  I nomi AzureFirewallSubnet, AzureFirewallManagementSubnetAzureBastionSubnet, e GatewaySubnet sono riservati all'interno di Azure. Non usare nessuno di questi come nome della subnet.

• Gruppo di sicurezza di rete. Le regole di sicurezza nei gruppi di sicurezza di rete consentono di filtrare il tipo di traffico di rete in grado di scorrere da e verso subnet di rete virtuali e interfacce di rete. Per altre informazioni, vedere panoramica del gruppo di sicurezza di rete.

  I gruppi di sicurezza delle applicazioni semplificano il controllo della sicurezza di livello 4 usando gruppi di sicurezza di rete per reti flat. Puoi velocemente:

  • Aggiungere macchine virtuali a un gruppo di sicurezza di azure o rimuovere macchine virtuali da un gruppo di sicurezza di azure.
  • Applicare dinamicamente le regole a tali macchine virtuali o rimuovere regole da tali macchine virtuali.

  Per altre informazioni, vedere panoramica del gruppo di sicurezza di Azure.

  Al momento, non sono supportati gruppi di sicurezza di rete in cui un gruppo di sicurezza di rete fa parte della regola con Database di Azure per PostgreSQL server flessibile. Attualmente è consigliabile usare il filtro di origine o destinazione basato su IP in un gruppo di sicurezza di rete.

  Importante

  Disponibilità elevata e altre funzionalità di Database di Azure per PostgreSQL server flessibile richiedono la possibilità di inviare/ricevere traffico alla porta di destinazione 5432 all'interno della subnet di rete virtuale di Azure in cui viene distribuito Database di Azure per PostgreSQL server flessibile, nonché all'archiviazione di Azure per l'archiviazione dei log. Se si creano gruppi di sicurezza di rete (NSG) per negare il flusso del traffico verso o dall'istanza del server flessibile Database di Azure per PostgreSQL all'interno della subnet in cui è distribuita, assicurarsi di consentire il traffico verso la porta di destinazione 5432 all'interno della subnet e anche all'archiviazione di Azure usando il tag del servizio Archiviazione di Azure come destinazione. È possibile filtrare ulteriormente questa regola di eccezione aggiungendo l'area di Azure all'etichetta come us-east.storage. Inoltre, se si sceglie di usare l'autenticazionedi Microsoft Entra per autenticare gli account di accesso all'istanza del server flessibile Database di Azure per PostgreSQL, consentire il traffico in uscita verso Microsoft Entra ID usando il tag del servizio Microsoft Entra. Quando si configurano repliche in lettura tra aree di Azure, Database di Azure per PostgreSQL server flessibile richiede la possibilità di inviare/ricevere traffico alla porta di destinazione 5432 sia per la replica primaria che per quella di Azure, nonché per l'archiviazione di Azure in aree primarie e di replica da server primario e di replica.

• integrazione della zona DNS privato. L'integrazione della zona DNS privato di Azure consente di risolvere il DNS privato all'interno della rete virtuale corrente o di qualsiasi rete virtuale con peering in un'area in cui è collegata la zona DNS privata.

Uso di una zona DNS privata

Azure DNS privato offre un servizio DNS affidabile e sicuro per la rete virtuale. DNS privato di Azure gestisce e risolve i nomi di dominio nella rete virtuale senza la necessità di configurare una soluzione DNS personalizzata.

Quando si usa l'accesso alla rete privata con la rete virtuale di Azure, fornire le informazioni sulla zona DNS privata è obbligatorio per poter eseguire la risoluzione DNS. Per la creazione di nuove istanze di server flessibili Database di Azure per PostgreSQL usando l'accesso alla rete privata, è necessario usare le zone DNS private durante la configurazione di Database di Azure per PostgreSQL istanze di server flessibili con accesso privato. Per la creazione di nuove istanze del server flessibili Database di Azure per PostgreSQL usando l'accesso alla rete privata con API, ARM o Terraform, creare zone DNS private e usarle durante la configurazione Database di Azure per PostgreSQL istanze di server flessibili con accesso privato. Vedere altre informazioni sulle specifiche dell'API REST per Microsoft Azure. Se si usa la portale di Azure o l'interfaccia della riga di comando di Azure per creare Database di Azure per PostgreSQL istanze di server flessibili, è possibile specificare un nome di zona DNS privato creato in precedenza nella stessa sottoscrizione o in una sottoscrizione diversa o nella sottoscrizione viene creata automaticamente una zona DNS privata predefinita.

Se si usa un'API di Azure, un modello di Azure Resource Manager (modello arm) o Terraform, creare zone DNS private che terminano con .postgres.database.azure.com. Usare queste zone durante la configurazione di Database di Azure per PostgreSQL istanze di server flessibili con accesso privato. Ad esempio, usare il modulo [name1].[name2].postgres.database.azure.com o [name].postgres.database.azure.com. Se si sceglie di usare il modulo [name].postgres.database.azure.com, il nome non può essere il nome usato per una delle istanze del server flessibile di Database di Azure per PostgreSQL o verrà visualizzato un messaggio di errore durante il provisioning. Per altre informazioni, vedere la panoramica delle zone DNS private.

Usando portale di Azure, API, interfaccia della riga di comando o ARM, è anche possibile modificare la zona DNS privata da quella fornita durante la creazione dell'istanza del server flessibile Database di Azure per PostgreSQL a un'altra zona DNS privata che esiste nella stessa sottoscrizione o in una sottoscrizione diversa.

Importante

La possibilità di modificare la zona DNS privata da quella fornita durante la creazione dell'istanza del server flessibile Database di Azure per PostgreSQL a un'altra zona DNS privata è attualmente disabilitata per i server con funzionalità a disponibilità elevata abilitata.

Dopo aver creato una zona DNS privata in Azure, è necessario collegarvi una rete virtuale. Una volta collegate, le risorse ospitate in tale rete virtuale possono accedere alla zona DNS privata.

Importante

Non è più possibile convalidare la presenza dei collegamenti di rete virtuale nella creazione del server per Database di Azure per PostgreSQL server flessibile con rete privata. Quando si crea un server tramite il portale, è possibile creare un collegamento alla creazione del server tramite la casella di controllo "Collega DNS privato Zona alla rete virtuale" nella portale di Azure.

Le zone private DNS sono resilienti alle interruzioni a livello di area perché i dati della zona sono disponibili a livello globale. I record di risorse in una zona privata vengono replicati automaticamente tra aree. Azure DNS privato è un servizio di base della zona di disponibilità, con ridondanza della zona. Per altre informazioni, vedere Servizi di Azure con supporto per la zona di disponibilità.

Integrazione con un server DNS personalizzato

Se si usa un server DNS personalizzato, è necessario usare un server d'inoltro DNS per risolvere il nome di dominio completo di Database di Azure per PostgreSQL server flessibile. L'indirizzo IP del server d'inoltro deve essere 168.63.129.16.

Il server DNS personalizzato deve trovarsi all'interno della rete virtuale o raggiungibile tramite l'impostazione del server DNS della rete virtuale. Per altre informazioni, vedere Risoluzione dei nomi che usa il proprio server DNS.

DNS privato zona e peering di rete virtuale

DNS privato le impostazioni della zona e il peering di rete virtuale sono indipendenti l'uno dall'altro. Se si vuole connettersi all'istanza del server flessibile Database di Azure per PostgreSQL da un client di cui è stato effettuato il provisioning in un'altra rete virtuale dalla stessa area o da un'area diversa, è necessario collegare la zona DNS privata alla rete virtuale. Per altre informazioni, vedere Collegare la rete virtuale.

Nota

È possibile collegare solo i nomi di zona DNS privati che terminano con "postgres.database.azure.com". Il nome della zona DNS non può essere uguale a quello delle istanze del server flessibile Database di Azure per PostgreSQL altrimenti la risoluzione dei nomi avrà esito negativo.

Per eseguire il mapping di un nome server al record DNS, è possibile eseguire il comando nslookup in Azure Cloud Shell usando Azure PowerShell o Bash, sostituendo il nome del server per <server_name> parametro nell'esempio seguente:

nslookup -debug <server_name>.postgres.database.azure.com | grep 'canonical name'

Uso della progettazione di rete privata Hub e Spoke

Hub e spoke è un modello di rete diffuso per gestire in modo efficiente i requisiti comuni di comunicazione o sicurezza.

L'hub è una rete virtuale che funge da posizione centrale per la gestione della connettività esterna e l'hosting dei servizi usati da più carichi di lavoro. L'hub coordina tutte le comunicazioni da e verso gli spoke. Le regole o i processi IT come la sicurezza possono ispezionare, instradare e gestire centralmente il traffico. Gli spoke sono reti virtuali che ospitano i carichi di lavoro e si connettono all'hub centrale tramite il peering di reti virtuali. I servizi condivisi sono ospitati nelle rispettive subnet per la condivisione con gli spoke. Una subnet della rete perimetrale funge poi da appliance di sicurezza.

Gli spoke sono anche reti virtuali in Azure usate per isolare i singoli carichi di lavoro. Il flusso del traffico tra la sede centrale locale e Azure è connesso tramite ExpressRoute o VPN da sito a sito, connesso alla rete virtuale hub. Le reti virtuali dagli spoke all'hub vengono associate tramite peering e abilitano la comunicazione con le risorse locali. È possibile implementare l'hub e ogni spoke in sottoscrizioni o gruppi di risorse distinti.

Esistono tre modelli principali per connettere le reti virtuali spoke tra loro:

• Gli spoke si connettono direttamente l'uno all'altro. I peering di rete virtuale o i tunnel VPN vengono creati tra le reti virtuali spoke per fornire connettività diretta senza attraversare la rete virtuale hub.
• Gli spoke comunicano tramite un'appliance di rete. Ogni rete virtuale spoke ha un peering per rete WAN virtuale o per una rete virtuale hub. Un'appliance instrada il traffico dallo spoke allo spoke. L'appliance può essere gestita da Microsoft (come con rete WAN virtuale) o dall'utente.
• Rete virtuale Gateway collegato alla rete hub e usare route definite dall'utente (UDR) per abilitare la comunicazione tra gli spoke.

Usare Azure Rete virtuale Manager (AVNM) per creare topologie di rete virtuale hub e spoke nuovi (ed eseguire l'onboarding di topologie di rete virtuale esistenti) per la gestione centrale dei controlli di connettività e sicurezza.

Comunicazione con client in rete privata in aree diverse

I clienti hanno spesso la necessità di connettersi ai client in aree di Azure diverse. In particolare, questa domanda si riduce in genere a come connettere due reti virtuali (una delle quali ha Database di Azure per PostgreSQL - Server flessibile e un altro client applicazione) che si trovano in aree diverse. Esistono diversi modi per ottenere tale connettività, alcuni dei quali:

• Peering reti virtuali globali. Metodologia più comune, perché è il modo più semplice per connettere le reti in aree diverse insieme. Il peering reti virtuali globali crea una connessione tramite il backbone di Azure direttamente tra le due reti virtuali con peering. In questo modo è possibile ottenere una velocità effettiva di rete ottimale e latenze più basse per la connettività tramite questo metodo. Quando si esegue il peering delle reti virtuali, Azure gestirà automaticamente il routing, queste reti virtuali possono comunicare con tutte le risorse nella rete virtuale con peering, stabilite in un gateway VPN.
• Connessione da rete virtuale a rete virtuale. Una connessione da rete virtuale a rete virtuale è essenzialmente una VPN tra le due diverse posizioni di Azure. La connessione da rete virtuale a rete virtuale viene stabilita in un gateway VPN. Ciò significa che il traffico comporta due hop di traffico aggiuntivi rispetto al peering reti virtuali globali. Esiste anche una latenza aggiuntiva e una larghezza di banda inferiore rispetto a tale metodo.
• Comunicazione tramite appliance di rete nell'architettura hub-spoke. Invece di connettere le reti virtuali spoke direttamente tra loro, è possibile usare appliance di rete per inoltrare il traffico tra spoke. Le appliance di rete offrono più servizi di rete, ad esempio l'ispezione approfondita dei pacchetti e la segmentazione o il monitoraggio del traffico, ma possono introdurre colli di bottiglia della latenza e delle prestazioni se non sono dimensionati correttamente.

Replica tra aree di Azure e reti virtuali con rete privata

La replica del database è il processo di copia dei dati da un server centrale o primario a più server noti come repliche. Il server primario accetta operazioni di lettura e scrittura, mentre le repliche servono transazioni di sola lettura. Il server primario e le repliche formano collettivamente un cluster di database. L'obiettivo della replica del database è garantire ridondanza, coerenza, disponibilità elevata e accessibilità dei dati, in particolare in applicazioni cruciali e ad alto traffico.

Database di Azure per PostgreSQL server flessibile offre due metodi per le repliche: fisiche (ad esempio lo streaming) tramite la funzionalità replica in lettura predefinita e la replica logica. Entrambi sono ideali per casi d'uso diversi e un utente può scegliere uno rispetto all'altro a seconda dell'obiettivo finale.

La replica tra aree di Azure, con reti virtuali separate in ogni area, richiede la connettività tra i limiti di rete virtuale a livello di area che possono essere forniti tramite peering di rete virtuale o nelle architetture hub-spoke tramite appliance di rete.

Per impostazione predefinita , la risoluzione dei nomi DNS ha come ambito una rete virtuale. Ciò significa che qualsiasi client in una rete virtuale (VNET1) non è in grado di risolvere il nome di dominio completo del server flessibile Database di Azure per PostgreSQL in un'altra rete virtuale (VNET2).

Per risolvere questo problema, è necessario assicurarsi che i client in VNET1 possano accedere al server flessibile Database di Azure per PostgreSQL DNS privato Zona. A tale scopo, è possibile aggiungere un collegamento di rete virtuale alla zona DNS privato dell'istanza del server flessibile Database di Azure per PostgreSQL.

Scenari di rete virtuale non supportati

Ecco alcune limitazioni per l'uso delle reti virtuali create tramite l'integrazione della rete virtuale:

• Dopo che un'istanza del server flessibile Database di Azure per PostgreSQL è stata distribuita in una rete virtuale e in una subnet, non è possibile spostarla in un'altra rete virtuale o subnet. Non è possibile spostare la rete virtuale in un altro gruppo di risorse o in un'altra sottoscrizione.
• Dopo la creazione di risorse, non è possibile aumentare le dimensioni della subnet (spazi indirizzi).
• Le risorse inserite nella rete virtuale non possono interagire con collegamento privato per impostazione predefinita. Per usare collegamento privato per la rete privata, vedere Database di Azure per PostgreSQL rete server flessibile con collegamento privato

Importante

Azure Resource Manager supporta la possibilità di bloccare le risorse, come controllo di sicurezza. I blocchi vengono applicati alla risorsa e sono effettivi per tutti gli utenti e i ruoli. Esistono due tipi di blocchi delle risorse: CanNotDelete e ReadOnly. Questi tipi di blocco possono essere applicati a una zona DNS privato o a un singolo set di record. L'applicazione di un blocco di entrambi i tipi a DNS privato zona o a un singolo set di record può interferire con la possibilità di Database di Azure per PostgreSQL server flessibile di aggiornare i record DNS e causare problemi durante operazioni importanti sul DNS, ad esempio il failover a disponibilità elevata dal server primario al secondario. Per questi motivi, assicurarsi di non usare la zona privata DNS o i blocchi di record quando si usano le funzionalità a disponibilità elevata con Database di Azure per PostgreSQL server flessibile.

Nome host

Indipendentemente dall'opzione di rete scelta, è consigliabile usare sempre un nome di dominio completo come nome host per la connessione all'istanza del server flessibile Database di Azure per PostgreSQL. L'indirizzo IP del server non è garantito che rimanga statico. L'uso del nome di dominio completo consente di evitare di apportare modifiche al stringa di connessione.

Un esempio che usa un FQDN come nome host è hostname = servername.postgres.database.azure.com. Se possibile, evitare di usare hostname = 10.0.0.4 (un indirizzo privato) o hostname = 40.2.45.67 (un indirizzo pubblico).

Passaggi successivi

• Informazioni su come creare un'istanza del server flessibile Database di Azure per PostgreSQL usando l'opzione Accesso privato (integrazione rete virtuale) nella portale di Azure o nell'interfaccia della riga di comando di Azure.