Architettura della connettività in Database di Azure per PostgreSQL

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

Questo articolo illustra l'architettura di connettività del Database di Azure per PostgreSQL e anche il modo in cui il traffico viene indirizzato all'istanza di database del Database di Azure per PostgreSQL dai client sia all'interno che all'esterno di Azure.

Architettura della connettività

La connessione a Database di Azure per PostgreSQL viene stabilita tramite un gateway responsabile del routing delle connessioni in ingresso alla posizione fisica del server nei cluster. Il diagramma seguente illustra il flusso del traffico.

Quando il client si connette al database, la stringa di connessione al server viene risolta nell'indirizzo IP del gateway. Il gateway è in ascolto sulla porta 5432 dell’indirizzo IP. All'interno del cluster del database il traffico viene inoltrato al Database di Azure per PostgreSQL appropriato. Pertanto, per connettersi al server, come ad esempio dalle reti aziendali, è necessario aprire il firewall lato client per consentire al traffico in uscita di raggiungere i gateway. Di seguito è riportato un elenco completo degli indirizzi IP usati dai gateway per area.

Indirizzi IP del gateway di Database di Azure per PostgreSQL

Il servizio gateway è ospitato in un gruppo di nodi di calcolo senza stato che si trovano dietro un indirizzo IP. Questo è un indirizzo che il client raggiunge per primo quando tenta di connettersi a un server di Database di Azure per PostgreSQL.

Nell’ambito della manutenzione continua dei servizi, aggiorneremo periodicamente l'hardware di calcolo che ospita i gateway per garantire l'esperienza di connettività più sicura ed efficace possibile. Quando l'hardware del gateway viene aggiornato, viene creato un nuovo anello dei nodi di calcolo. Questo nuovo anello serve il traffico per tutti i server Database di Azure per PostgreSQL appena creati e avrà un indirizzo IP diverso dagli anelli del gateway meno recenti nella stessa area per differenziare il traffico. L'hardware del gateway precedente continua a servire i server esistenti, ma verrà ritirato in futuro. Prima di dismettere l'hardware di un gateway, i clienti che gestiscono i server e si connettono agli anelli dei gateway meno recenti riceveranno una notifica tramite e-mail e nel portale di Azure, tre mesi prima del ritiro. La dismissione dei gateway può influire sulla connettività ai server se

• Gli indirizzi IP del gateway sono codificati nella stringa di connessione dell'applicazione. Non è consigliabile. È consigliabile invece usare il nome di dominio completo (FQDN) del server nel formato <servername>.postgres.database.azure.com, nella stringa di connessione per l'applicazione.
• Non si aggiornano gli indirizzi IP del gateway più recenti nel firewall lato client per consentire al traffico in uscita di raggiungere i nuovi anelli del gateway.

La tabella seguente elenca le subnet degli indirizzi IP del gateway di Database di Azure per PostgreSQL per tutte le aree dati. Nella tabella seguente vengono mantenute le informazioni più aggiornate degli indirizzi IP del gateway per ogni area. Nella tabella seguente le colonne rappresentano quanto segue:

• Nome area: questa colonna elenca il nome dell'area di Azure in cui è disponibile Database di Azure per PostgreSQL - Server singolo.
• Subnet degli indirizzi IP del gateway: questa colonna elenca le subnet degli indirizzi IP degli anelli del gateway che si trovano nell'area specifica. Quando si ritira l'hardware del gateway meno recente, è consigliabile aprire il firewall lato client per consentire il traffico in uscita verso le subnet degli indirizzi IP nell'area in cui si sta operando.

Domande frequenti

Cosa è necessario sapere su questa manutenzione pianificata?

Si tratta soltanto di una modifica DNS, che lo rende trasparente ai client. Mentre l'indirizzo IP per FQDN viene modificato nel server DNS, la cache DNS locale viene aggiornata entro 5 minuti e viene eseguita automaticamente dai sistemi operativi. Dopo l'aggiornamento DNS locale, tutte le nuove connessioni si connetteranno al nuovo indirizzo IP, tutte le connessioni esistenti rimarranno connesse all'indirizzo IP precedente senza interruzioni fino a quando gli indirizzi IP precedenti non verranno completamente dismessi. L'indirizzo IP precedente richiederà circa tre-quattro settimane prima di essere rimosso; pertanto, non deve avere nessun effetto sulle applicazioni client.

Che cosa stiamo dismettendo?

Vengono dismessi soltanto i nodi del gateway. Quando gli utenti si connettono ai server, il primo arresto della connessione è al nodo del gateway, prima che la connessione venga inoltrata al server. Stiamo dismettendo i vecchi anelli del gateway (non gli anelli tenant in cui è in esecuzione il server). Consultare l'architettura della connettività per ulteriori chiarimenti.

Come è possibile verificare se le connessioni si trovano nei nodi del gateway precedenti o nei nuovi nodi del gateway?

Effettuare il ping del nome di dominio completo del server, come ad esempio ping xxx.postgres.database.azure.com. Se l'indirizzo IP restituito è uno degli indirizzi IP elencati in Indirizzi IP del gateway (dismissione) nel documento precedente, significa che la connessione passa attraverso il gateway precedente. Contrariamente, se l'indirizzo IP restituito è uno degli indirizzi IP elencati in Indirizzi IP del gateway, significa che la connessione passa attraverso il nuovo gateway.

È anche possibile eseguire il test tramite PSPing o TCPPing del server di database dall'applicazione client con la porta 5432 e accertarsi che l'indirizzo IP restituito non sia uno degli indirizzi IP in fase di dismissione

Come faccio a sapere quando la manutenzione è finita e riceverò un'altra notifica quando vengono dismessi gli indirizzi IP precedenti?

Riceverai un'e-mail che ti informerà quando inizieremo il lavoro di manutenzione. La manutenzione può richiedere fino a un mese a seconda del numero di server di cui è necessario eseguire la migrazione in tutte le aree. Preparare il client per connettersi al server del database usando il nome di dominio completo o usando il nuovo indirizzo IP della tabella precedente.

Cosa fare se le applicazioni client si connettono ancora al server gateway precedente?

Ciò indica che le applicazioni si connettono al server usando l'indirizzo IP statico anziché il nome di dominio completo. Esaminare le stringhe di connessione e l'impostazione del pool di connessioni, l'impostazione del servizio Azure Kubernetes o persino il codice sorgente.

C'è un impatto sulle connessioni dell'applicazione?

Questa manutenzione è solo una modifica DNS, quindi è trasparente per il client. Dopo l'aggiornamento della cache DNS nel client (eseguito automaticamente dal sistema operativo), tutte le nuove connessioni si connettono al nuovo indirizzo IP e tutte le connessioni esistenti continueranno a funzionare fino a quando l'indirizzo IP precedente non verrà dismesso completamente, cosa che avverrà diverse settimane dopo. E la logica di ripetizione dei tentativi non è necessaria in questo caso, ma è utile vedere che l'applicazione ha configurato la logica di ripetizione dei tentativi. Usare il nome di dominio completo per connettersi al server del database nella stringa di connessione dell'applicazione. Questa operazione di manutenzione non comporta l'eliminazione delle connessioni esistenti. Effettua solo le nuove richieste di connessione al nuovo anello del gateway.

È possibile richiedere un intervallo di tempo specifico per la manutenzione?

Poiché la migrazione deve essere trasparente e senza alcun impatto sulla connettività del cliente, ci si aspetta che non ci sarà alcun problema per la maggior parte degli utenti. Esaminare l'applicazione in modo proattivo e accertarsi di usare il nome di dominio completo per connettersi al server del database o abilitare l'elenco dei nuovi "indirizzi IP gateway" nella stringa di connessione dell'applicazione.

Se si usa un collegamento privato, le connessioni verranno interessate?

No, si tratta di una dismissione dell'hardware del gateway e non ha nessun rapporto con il collegamento privato o con gli indirizzi IP privati; influirà soltanto sugli indirizzi IP pubblici indicati negli indirizzi IP in fase di dismissione.

Passaggi successivi

• Create and manage Azure Database for PostgreSQL firewall rules using the Azure portal (Creare e gestire regole firewall per il Database di Azure per PostgreSQL usando il portale di Azure)
• Create and manage Azure Database for PostgreSQL firewall rules using Azure CLI (Creare e gestire regole firewall del Database di Azure per PostgreSQL tramite l'interfaccia della riga di comando di Azure)