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

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

Quando si crea un'istanza del server flessibile di 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'istanza del Database di Azure per PostgreSQL server flessibile nella rete virtuale di Azure usando l'iniezione 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:

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

Il diagramma precedente mostra quanto segue:

• 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 alle istanze del server flessibile di Database di Azure per PostgreSQL.
• Le applicazioni distribuite in una rete virtuale diversa (VNet-2) non hanno accesso diretto alle istanze del server flessibile di Database di Azure per PostgreSQL. È necessario eseguire il peering di reti virtuali per una zona DNS privato prima di poter accedere all'istanza del server flessibile.

Concetti relativi alla rete virtuale

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

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

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

  L'istanza del server flessibile di Database di Azure per PostgreSQL integrata nella rete virtuale deve trovarsi in una subnet delegata. Ovvero, solo le istanze del server flessibile di Database di Azure per PostgreSQL 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. 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. Questo lascia 11 indirizzi IP disponibili per un intervallo CIDR /28. Una singola istanza del server flessibile di 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 tramite 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.
  • Aggiungere una regola con l'intervallo IP di destinazione uguale all'intervallo di subnet dell'istanza del server flessibile di Database di Azure per PostgreSQL e all'hop successivo Virtual Network.

  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, Microsoft non supporta i gruppi di sicurezza di rete in cui un gruppo di sicurezza delle applicazioni fa parte della regola con le istanze del server flessibile di Database di Azure per PostgreSQL. Attualmente è consigliabile usare il filtro di origine o destinazione basato su IP in un gruppo di sicurezza di rete.

  La disponibilità elevata e altre funzionalità del server di Database di Azure per PostgreSQL richiedono la possibilità di inviare/ricevere traffico alla porta di destinazione 5432 all'interno della subnet di rete virtuale di Azure in cui viene distribuita un'istanza del server flessibile di Database di Azure per PostgreSQL e in Archiviazione di Azure per l'archiviazione dei log. Se si creano Network Security Groups (NSGs) per negare il flusso di traffico da o verso l'istanza del server flessibile di Azure Database 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 verso Archiviazione utilizzando il tag del servizio Archiviazione come destinazione. Per la disponibilità elevata, la procedura consigliata consiste nell'aggiungere un endpoint del servizio Microsoft.Storage perché garantisce il routing del traffico corretto all'account di archiviazione di Azure usato per caricare i file di log write-ahead.

  È 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 di Microsoft Entra per autenticare gli accessi all'istanza del server flessibile di Database di Azure per PostgreSQL, consentire il traffico in uscita verso Microsoft Entra ID usando un tag del servizio Microsoft Entra.

  Quando si configurano repliche in lettura in aree di Azure, l'istanza del server flessibile di Database di Azure per PostgreSQL richiede la possibilità di inviare\ricevere il traffico alla porta di destinazione 5432 sia per l'archiviazione primaria che per la replica, nonché per Archiviazione di Azure nelle aree primarie e di replica da server di primari 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 le reti virtuali. 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, è obbligatorio fornire le informazioni sulla zona DNS privato per poter eseguire la risoluzione DNS. Per creare una nuova istanza del server flessibile di Database di Azure per PostgreSQL usando l'accesso alla rete privata, è necessario usare le zone DNS private durante la configurazione delle istanze del server flessibile di Database di Azure per PostgreSQL con accesso privato.

Importante

Quando si usa una zona DNS privata in una sottoscrizione diversa, tale sottoscrizione deve avere anche il provider di risorse Microsoft.DBforPostgreSQL registrato. In caso contrario, la distribuzione di un'istanza del server flessibile di Database di Azure per PostgreSQL non verrà completata.

Per creare una nuova istanza del server flessibile di Database di Azure per PostgreSQL usando l'accesso alla rete privata con un'API, un modello di Azure Resource Manager (modello ARM), Bicep o Terraform, creare zone DNS private. Successivamente, usarle durante la configurazione delle istanze del server flessibile di Database di Azure per PostgreSQL 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 istanze del server flessibile di Database di Azure per PostgreSQL, è possibile specificare un nome di zona DNS privato creato in precedenza nella stessa sottoscrizione o in una sottoscrizione diversa oppure viene creata automaticamente una zona DNS privata predefinita nella sottoscrizione.

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

Quando si utilizza il portale di Azure, le API, l'Azure CLI o un modello ARM, è possibile anche modificare la zona DNS privata da quella fornita in fase di creazione dell'istanza del server flessibile di Azure Database per PostgreSQL a un'altra zona DNS privata esistente per la stessa sottoscrizione o una diversa.

Importante

La possibilità di modificare una zona DNS privato da quella fornita quando è stata creata l'istanza del server flessibile di Database di Azure per PostgreSQL in un'altra zona DNS privata è attualmente disabilitata per i server con la funzionalità a disponibilità elevata abilitata.

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.

Importante

Non convalidiamo più la presenza dei collegamenti di rete virtuale durante la creazione di un server per le istanze del server flessibile di Azure Database per PostgreSQL con rete privata. Quando si crea un server tramite il portale, è possibile consentire al cliente di scegliere se creare un collegamento al momento della creazione del server tramite la casella di controllo Collegare la zona DNS privato alla rete virtuale nel portale di Azure.

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 utilizza un server DNS personalizzato, è necessario usare un inoltratore DNS per risolvere il FQDN del server flessibile di 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 che usa il 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 all'istanza del server flessibile di 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 privato alla rete virtuale. Per altre informazioni, vedere Collegare la rete virtuale.

Note

Solo i nomi di zona DNS privati che terminano con postgres.database.azure.com possono essere collegati. Il nome della zona DNS non può essere uguale ai nomi delle istanze del server flessibile di Azure Database per PostgreSQL. In caso contrario, la risoluzione dei nomi ha 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. Sostituire il nome del server per il parametro <server_name> 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.

Gli spoke sono anche reti virtuali in Azure che vengono usate per isolare i singoli carichi di lavoro. Il flusso del traffico tra la sede centrale locale e Azure è connesso tramite Azure 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 sono collegati 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 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 reti virtuali hub-spoke (ed eseguire l'onboarding di reti virtuali 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 un'istanza del server flessibile di Database di Azure per PostgreSQL e un'altra con un client applicazione) che si trovano in aree diverse.

Esistono diversi modi per ottenere tale connettività, 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 delle reti virtuali, Azure gestisce automaticamente anche la pianificazione percorso. 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. La connessione da rete a rete viene stabilita 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 un utente potrebbe sceglierne uno o l'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 della rete virtuale a livello di area che possono essere forniti tramite peering di rete virtuale o nelle architetture hub-spoke tramite un'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 FQDN dell'istanza flessibile del server di Azure Database per PostgreSQL in un'altra rete virtuale (VNET2).

Per risolvere questo problema, è necessario assicurarsi che i client in VNET1 possano accedere alla zona DNS privata dell'istanza del server flessibile di Database di Azure per PostgreSQL. Aggiungere un collegamento della rete virtuale alla zona DNS privato dell'istanza del server flessibile di 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 di Database di Azure per PostgreSQL viene 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 il collegamento privato per impostazione predefinita. Per usare Private Link per la rete privata di Azure, vedere Database di Azure per PostgreSQL con Private Link.

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 blocco 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 una zona DNS privata o a un singolo set di record potrebbe interferire con la possibilità di un'istanza del server flessibile di Database di Azure per PostgreSQL di aggiornare i record DNS. Potrebbe anche causare problemi durante operazioni importanti sul DNS, ad esempio il failover a disponibilità elevata da primario a secondario. Per questi motivi, assicurarsi di non usare una zona privata DNS o blocchi di record quando si usano funzionalità ad alta disponibilità con un'istanza di server flessibile di Azure Database per PostgreSQL.

Nome host

Indipendentemente dall'opzione di rete scelta, è consigliabile usare sempre un nome di dominio completo come nome host quando ci si connette all'istanza del server flessibile di Database di Azure per PostgreSQL. Non è garantito che l'indirizzo IP del server rimanga statico. L'uso del nome di dominio completo consente di evitare di apportare modifiche alla 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
• Interfaccia della riga di comando di Azure