Condividi tramite

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

  • Articolo

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

Questo articolo descrive i concetti di connettività e rete per il Database di Azure per PostgreSQL - Server fliessibile.

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 del Database di Azure per PostgreSQL nella rete virtuale Azure utilizzando 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 al server flessibile di Database di Azure per PostgreSQL usando indirizzi IP privati.
  • Usare una VPN o Azure ExpressRoute per connettersi da risorse non Azure al server flessibile di Database di Azure per PostgreSQL.
  • Assicurarsi che il server flessibile di Database di Azure per PostgreSQL non abbia un endpoint pubblico accessibile tramite Internet.

Diagramma che illustra il funzionamento del peering tra reti virtuali, una delle quali include il server flessibile di Database di Azure per PostgreSQL.

Nel diagramma precedente:

  • Il server flessibile di Database di Azure per PostgreSQL viene inserito nella subnet 10.0.1.0/24 della rete virtuale VNet-1.
  • Le applicazioni implementate in subnet diverse all'interno della stessa rete virtuale possono accedere direttamente al server flessibile di Database di Azure per PostgreSQL.
  • Le applicazioni implementate in una rete virtuale diversa (VNet-2) non hanno accesso diretto al server flessibile di Database di Azure per PostgreSQL. È necessario eseguire il peering di reti virtuali 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 di indirizzi IP privati configurato per essere usato dall'utente. La rete virtuale deve trovarsi nella stessa area di Azure 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 nella rete virtuale con il server flessibile di Database di Azure per PostgreSQL:

  • Subnet delegata: una rete virtuale contiene subnet (subnetwork). 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 di Database di Azure per PostgreSQL integrato nella rete virtuale deve trovarsi in una subnet delegata. Ovvero, solo i server flessibili 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 è /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 da utilizzare internamente per la rete di Azure, che includono due IP che non possono essere assegnati all'host, menzionati in precedenza. Questo 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 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 AzureActiveDirectory del servizio di destinazione e l'hop Internetsuccessivo.
    • Aggiungere una regola con l'intervallo IP di destinazione uguale all'intervallo di subnet di Database di Azure per PostgreSQL - Aserver flessibile e l'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 degli NSG 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. Puoi velocemente:

    • Aggiungere o rimuovere macchine virtuali da un ASG.
    • 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 NSG in cui un ASG 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.

    La disponibilità elevata e altre funzionalità di Database di Azure per PostgreSQL - Server flessibile richiedono la capacità di inviare/ricevere traffico alla porta di destinazione 5432 all'interno della subnet della rete virtuale Azure in cui è distribuito Database di Azure per PostgreSQL - Server flessibile e all’archiviazione di Azure per l'archiviazione dei log. Se si creano NSG per negare il flusso del traffico verso o dal server flessibile di Database di Azure per PostgreSQL all'interno della subnet in cui è stato distribuito, assicurarsi di consentire il traffico alla porta di destinazione 5432 all'interno della subnet e 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'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 il tag del servizio Microsoft Entra.

    Quando si configurano repliche in lettura tra le aree di Azure, Database di Azure per PostgreSQL - Server flessibile richiede la possibilità di inviare\ricevere il traffico alla porta di destinazione 5432 sia per l'archiviazione primaria che per la replica, nonché per l'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 la creazione di nuovi server flessibili di Database di Azure per PostgreSQL utilizzando un accesso di rete privato, è necessario utilizzare le zone DNS private durante la configurazione dei server flessibili di Database di Azure per PostgreSQL con accesso privato.

Importante

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

Per la creazione di nuovi server flessibili di Database di Azure per PostgreSQL utilizzando l'accesso alla rete privata con un'API, un modello Azure Resource Manager (modello ARM) o Terraform, creare zone DNS private. Quindi, usarle durante la configurazione delle istanze dei server flessibili di Database di Azure per PostgreSQL con accesso privato. Per altre informazioni, vedere le specifiche dell'API REST per Microsoft Azure.

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

Se si usa un'API di Azure, un modello di ARM o Terraform, creare zone DNS privato che terminano con .postgres.database.azure.com. Usare queste zone durante la configurazione dei server flessibili 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 i server flessibili di Database di Azure per PostgreSQL, altrimenti verrà visualizzato un messaggio di errore durante il provisioning. Per altre informazioni, vedere le informazioni generali delle zone DNS private.

Quando si usano il portale Azure, le API, la CLI Azure o un modello di ARM, è anche possibile cambiare la zona DNS privato da quella fornita al momento della creazione del server flessibile di Database di Azure per PostgreSQL a un'altra zona DNS privata esistente nella stessa sottoscrizione o in una sottoscrizione diversa.

Importante

La possibilità di cambiare una zona DNS privato da quella fornita al momento della creazione del server flessibile di 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 privato in Azure, è necessario collegarvi una rete virtuale. Le risorse ospitate in tale rete virtuale possono quindi accedere alla zona DNS privato.

Importante

La presenza del collegamento della rete virtuale non viene più verificata al momento della creazione del server per Database di Azure per PostgreSQL - Server flessibile con rete privata. Quando si crea un server tramite il portale, consentiamo al cliente di scegliere di creare un collegamento alla creazione del server tramite la casella di controllo Collegare la zona DNS privato alla rete virtuale nel portale 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 usa il server DNS personalizzato, è necessario usare un forwarder DNS per risolvere l'FQDN 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.

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 ci si vuole connettere al 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.

Nota

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 a quello dei server flessibili di Database di Azure 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-and-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 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 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 la 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.

Diagramma che mostra l'architettura hub-and-spoke di base con connettività ibrida tramite l'hub Express.

Usare Gestione rete virtuale di Azure per creare nuove topologie di reti virtuali hub-and-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 Database di Azure per PostgreSQL - Server flessibile e un’altra ha un client dell'applicazione) che si trovano in aree diverse.

Esistono diversi modi per ottenere tale connettività, tra cui:

  • Peering di rete virtuale globale. Questo è il metodo 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. Questo metodo consente una produttività 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-and-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, ma 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 - Server flessibile 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 le aree di Azure, con reti virtuali separate in ciascuna area, richiede la connettività attraverso i limiti delle reti virtuali a livello di area, che possono essere forniti tramite peering di reti virtuali o in architetture hub-and-spoke tramite 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 l'FQDN ddi Database di Azure per PostgreSQL - Server flessibile in un'altra rete virtuale (VNET2).

Per risolvere questo problema, è necessario assicurarsi che i client in VNET1 possano accedere alla zona DNS privato di Database di Azure per PostgreSQL - Server flessibile. Aggiungere un collegamento della rete virtuale alla zona DNS privato 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 aver distribuito un server flessibile di 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.
  • 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 il collegamento privato per la rete privata, vedere l'articolo sulla rete di Database di Azure per PostgreSQL - 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 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 un tipo qualsiasi a una zona DNS privato o a un singolo set di record potrebbe interferire con la possibilità di Database di Azure per PostgreSQL - Server flessibile 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 la zona privata DNS o i blocchi di record quando si usano le funzionalità di disponibilità elevata con Database di Azure per PostgreSQL - Server flessibile.

Nome host

Indipendentemente dall'opzione di rete scelta, è consigliabile usare sempre un FQDN come nome host durante la connessione al 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).

Contenuto correlato