Rete con accesso privato (integrazione di rete virtuale) in Server flessibile di Database di Azure per PostgreSQL

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

Quando si crea un server flessibile Database di Azure per PostgreSQL, è necessario scegliere una delle opzioni di rete seguenti:

• Accesso privato (integrazione rete virtuale)
• Accesso pubblico (indirizzi IP consentiti) ed endpoint privato

Questo documento descrive l'opzione di rete ad accesso privato (integrazione di rete virtuale).

Accesso privato (integrazione rete virtuale)

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

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

• Connettersi dalle risorse Azure nella stessa rete virtuale al server flessibile Database di Azure per PostgreSQL usando indirizzi IP privati.
• Usare una VPN o Azure ExpressRoute per connettersi da risorse non Azure al server flessibile Database di Azure per PostgreSQL.
• Assicurarsi che il server flessibile Database di Azure per PostgreSQL non abbia un endpoint pubblico accessibile tramite Internet.

Il diagramma precedente mostra quanto segue:

• Database di Azure per PostgreSQL - Server flessibile viene distribuito 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 al server flessibile di Azure Database per PostgreSQL.
• Le applicazioni distribuite in una rete virtuale diversa (VNet-2) non hanno accesso diretto a Database di Azure per PostgreSQL server flessibile. È necessario eseguire il peering di rete virtuale per una zona DNS privato prima di poter accedere al server flessibile.

Concetti relativi alla rete virtuale

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

Acquisire familiarità con questi concetti quando si usano reti virtuali in cui le risorse sono integrate in una rete virtuale con Database di Azure per PostgreSQL server flessibile:

• Subnet delegata: una rete virtuale contiene subnet (reti secondarie). 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.

  Il server flessibile Database di Azure per PostgreSQL integrato in una rete virtuale deve trovarsi in una subnet delegata. Ovvero, solo Database di Azure per PostgreSQL server flessibile può 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. Il primo e l'ultimo indirizzo in qualsiasi rete o subnet non possono essere assegnati a un singolo host. Azure riserva cinque indirizzi IP che la rete di Azure usa internamente, che includono due indirizzi IP che non possono essere assegnati all'host, menzionati in precedenza. Questa prenotazione lascia 11 indirizzi IP disponibili per un intervallo CIDR /28. Un singolo server flessibile Database di Azure per PostgreSQL con funzionalità a disponibilità elevata usa quattro indirizzi.

  Per le connessioni di replica e Microsoft Entra, assicurarsi che le tabelle di routing non influiscano sul traffico. Un modello comune consiste nell'instradare tutto il traffico in uscita attraverso un firewall di Azure o un'appliance di filtro di rete locale personalizzata.

  Se alla subnet è associata una tabella di routing con la regola per instradare tutto il traffico a un'appliance virtuale:

  • Aggiungere una regola con il tag del servizio di destinazione AzureActiveDirectorye l'hop successivo Internet.
  • Aggiungi una regola con l'intervallo IP di destinazione uguale a quello della subnet del server flessibile di Database di Azure per PostgreSQL e l'hop successivo Rete virtuale.

  Importante

  I nomi AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet e GatewaySubnet sono riservati in Azure. Non usare alcuno di questi nomi come nome della subnet. Inoltre, le reti virtuali non devono avere spazio indirizzi sovrapposto per la creazione di repliche tra aree.

• Gruppo di sicurezza di rete (NSG): le regole di sicurezza dei gruppi di sicurezza di rete consentono di filtrare il tipo di traffico di rete consentito in ingresso e in uscita dalle subnet della rete virtuale e dalle interfacce di rete. Per altre informazioni, vedere l'articolo sulla 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. È possibile velocemente:

  • Aggiungere o rimuovere macchine virtuali a un gruppo di sicurezza delle applicazioni.
  • Applicare o rimuovere in modo dinamico le regole a tali macchine virtuali.

  Per altre informazioni, vedere l'articolo sulla panoramica del gruppo di sicurezza delle applicazioni.

  Al momento, Azure Database per PostgreSQL Server flessibile non supporta gli NSG nelle cui regole è incluso un ASG. Usare il filtro di origine o destinazione basato su IP in un NSG.

  La disponibilità elevata e altre funzionalità del server Database di Azure per PostgreSQL richiedono la possibilità di inviare e ricevere traffico alla porta di destinazione 5432 all'interno della subnet di rete virtuale Azure in cui viene distribuito un server flessibile Database di Azure per PostgreSQL Archiviazione di Azure per l'archiviazione dei log. Se si creano NSG per negare il flusso di traffico da o verso il server flessibile di Database di Azure per PostgreSQL all'interno della subnet in cui è distribuito, assicurarsi di consentire il traffico verso la porta di destinazione 5432 all'interno della subnet e anche verso Storage, usando il tag di servizio Storage 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'autenticazione Microsoft Entra per autenticare gli accessi al server flessibile Database di Azure per PostgreSQL, consentire il traffico in uscita a Microsoft Entra ID usando un tag di servizio Microsoft Entra.

  L'endpoint del servizio Microsoft.Storage viene configurato automaticamente nella subnet delegata quando viene effettuato il provisioning del primo server in tale subnet. Questa configurazione garantisce un routing affidabile del traffico verso gli account di archiviazione di Azure usati per caricare i file di log delle scritture anticipate (WAL). La rimozione di questo endpoint può compromettere la connettività e può causare conseguenze impreviste per le operazioni di base del servizio.

  Quando si configurano repliche di lettura in più aree geografiche di Azure, Database di Azure per PostgreSQL - Server flessibile richiede la possibilità di inviare o ricevere traffico tramite la porta di destinazione 5432 sia per il server primario che per il server di replica e verso Archiviazione di Azure nelle aree geografiche primaria e di replica, da entrambi i server, primario e di replica. La porta TCP di destinazione necessaria per l'archiviazione è 443.

• 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 nell'area in cui è collegata la zona DNS privato.

Usare una zona DNS privato

DNS privato di Azure 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 una rete virtuale di Azure, è necessario fornire le informazioni sulla zona DNS privato per abilitare la risoluzione DNS. Per un nuovo server flessibile Database di Azure per PostgreSQL creato usando l'accesso alla rete privata, è necessario usare le zone di DNS privato durante la configurazione di Database di Azure per PostgreSQL server flessibile con accesso privato.

Per un nuovo server flessibile di Database di Azure per PostgreSQL creato tramite l'accesso alla rete privata con API, un modello di Azure Resource Manager (modello ARM), Bicep o Terraform, creare le zone DNS private. Usarli mentre si configura Database di Azure per PostgreSQL server flessibile con accesso privato. Per altre informazioni, vedere le specifiche dell'API REST per Azure.

Se si usa il portale di Azure o l'interfaccia della riga di comando di Azure per creare Database di Azure per PostgreSQL server flessibile, è possibile specificare un nome di zona DNS privato creato in precedenza nella stessa sottoscrizione o in una sottoscrizione diversa oppure un DNS privato predefinito la zona viene creata automaticamente nella sottoscrizione.

Se si usa un'API di Azure, un modello di Azure Resource Manager, Bicep o Terraform, creare zone di DNS privato che terminano con .postgres.database.azure.com. Usare queste zone mentre si configura Database di Azure per PostgreSQL server flessibile 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 uno dei server flessibili database di Azure per PostgreSQL oppure verrà visualizzato un messaggio di errore durante il provisioning. Per altre informazioni, vedere la panoramica delle zone DNS privato.

Quando si usa il portale di Azure, le API, interfaccia della riga di comando di Azure o un modello ARM, è anche possibile modificare la zona DNS privata, sostituendo quella specificata al momento della creazione del server flessibile di Database di Azure per PostgreSQL con un’altra zona DNS privata esistente nella stessa sottoscrizione o in un’altra sottoscrizione.

Dopo aver creato una zona DNS privato in Azure, è necessario collegarvi una rete virtuale. Le risorse ospitate nella rete virtuale collegata possono quindi accedere alla zona DNS privato.

Le zone DNS privato sono resilienti alle interruzioni a livello di area perché i dati della zona sono disponibili a livello globale. I record della risorsa in una zona privata vengono replicati automaticamente tra le aree. DNS privato di Azure è 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 del server flessibile Database di Azure per PostgreSQL. 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 con l'uso del proprio server DNS.

Zona DNS privato e peering di reti virtuali

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

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

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

Usare la progettazione della rete privata hub-spoke

Hub-spoke è un modello di rete noto per la gestione efficiente dei comuni requisiti 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 rete virtuale. 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.

Usa i raggi per isolare i singoli carichi di lavoro. Connettere la sede centrale locale e Azure tramite ExpressRoute o VPN da sito a sito, connessa alla rete virtuale hub. Eseguire il peering delle reti virtuali dagli spoke all'hub e abilitare la comunicazione con le risorse locali. Implementare l'hub e ogni spoke in sottoscrizioni o gruppi di risorse separati.

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

• Le reti spoke sono direttamente connesse tra loro: creare peering tra reti virtuali o tunnel VPN 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 a una rete WAN virtuale o a una rete virtuale hub. Un'appliance instrada il traffico da uno spoke all'altro. L'appliance può essere gestita da Microsoft (come con una rete WAN virtuale) o dall'utente.
• Un gateway di rete virtuale è collegato alla rete hub e utilizza percorsi definiti dall'utente: consente la comunicazione tra gli spoke.

Usare gestione rete virtuale di Azure per creare nuove topologie di rete virtuale (e integrare reti virtuali esistenti) per la gestione centrale dei controlli di connettività e sicurezza.

Comunicazione con client in rete privata in aree diverse

Spesso, i clienti devono connettersi ai client in aree di Azure diverse. In particolare, questa domanda in genere si riduce a come connettere due reti virtuali (una delle quali ha un server flessibile Database di Azure per PostgreSQL e un altro ha un client applicazione) che si trovano in aree diverse.

È possibile ottenere tale connettività in diversi modi, tra cui:

• Peering di rete virtuale globale. Questo metodo è il più comune, perché è il modo più semplice per connettere le reti in aree diverse insieme. Il peering di rete virtuale globale crea una connessione tramite il backbone di Azure direttamente tra le due reti virtuali con peering. Tramite questo metodo è possibile ottenere una velocità effettiva di rete ottimale e latenze più basse per la connettività. Quando si esegue il peering di reti virtuali, Azure gestisce automaticamente anche il routing. Queste reti virtuali possono comunicare con tutte le risorse nella rete virtuale con peering stabilite in un gateway VPN.
• Connessione da rete a rete. Una connessione tra reti virtuali (connessione da rete a rete) è essenzialmente una VPN tra le due diverse posizioni di Azure. Stabilire la connessione da rete a rete in un gateway VPN. Il traffico comporta due hop di traffico aggiuntivi rispetto al peering di rete virtuale globale. Esiste anche 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 le appliance di rete per inoltrare il traffico tra spoke. Le appliance di rete offrono più servizi di rete, ad esempio l'analisi approfondita dei pacchetti e la segmentazione o il monitoraggio del traffico, ma possono introdurre latenza e colli di bottiglia delle prestazioni se non sono dimensionati correttamente.

Replica tra aree di Azure e reti virtuali con rete privata

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

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

La replica tra aree di Azure, con reti virtuali richiede la connettività tra i limiti di rete virtuale a livello di area che può essere fornita tramite peering di reti virtuali o architetture hub-spoke mediante appliance di rete.

Per impostazione predefinita, la risoluzione del nome DNS ha come ambito una rete virtuale. 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, assicurarsi che i client in VNET1 possano accedere alla zona DNS privata del server flessibile di Database di Azure per PostgreSQL. Aggiungere un collegamento di rete virtuale alla zona DNS privato 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 aver distribuito un server flessibile Database di Azure per PostgreSQL in una rete virtuale e in una subnet, non è possibile spostarlo in un'altra rete virtuale o subnet. Non è possibile spostare la rete virtuale in un altro gruppo di risorse o in un'altra sottoscrizione.
• Non è possibile ampliare la dimensione della subnet (spazi degli indirizzi) dopo che le risorse esistono nella subnet.
• Per impostazione predefinita, le risorse inserite nella rete virtuale non possono interagire con il collegamento privato. Per usare collegamento privato per la rete privata di Azure, vedere Database di Azure per PostgreSQL con collegamento privato.
• Le configurazioni di rete personalizzate che instradano tutto il traffico a Microsoft Archiviazione di Azure tramite un Network Virtual Appliance (NVA) non sono supportate. Ad esempio, l'uso di una route catch-all (0.0.0.0/0 → Appliance Virtuale di Rete) per forzare tutto il traffico in uscita attraverso una NVA può interferire con la connettività della piattaforma necessaria. Ciò può causare errori imprevisti nelle operazioni critiche, inclusi gli scenari a disponibilità elevata. Per impostazione predefinita, il servizio aggiunge un endpoint di servizio Micosoft.Storage quando viene effettuato il provisioning del primo server nella subnet delegata, che fornisce connettività sicura e diretta ad Archiviazione di Azure tramite la rete backbone di Azure. La rimozione di questo endpoint può causare conseguenze impreviste per le operazioni di base del servizio.

Nome host

Indipendentemente dall'opzione di rete scelta, usare sempre un nome di dominio completo (FQDN) come nome host quando ci si connette al server flessibile Database di Azure per PostgreSQL. L'indirizzo IP del server potrebbe cambiare. Usando il nome di dominio completo, non è necessario aggiornare la 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).

Contenuti correlati

• Portale di Azure
• CLI di Azure