Strategia di pool di connessioni con PgBouncer nel server flessibile di Database di Azure per PostgreSQL

Questo articolo fornisce indicazioni strategiche per la selezione di un meccanismo di pool di connessioni per i server flessibili Database di Azure per PostgreSQL.

Introduzione

Quando si usa un server flessibile Database di Azure per PostgreSQL, si crea una connessione al database stabilendo un canale di comunicazione tra l'applicazione client e il server. Questo canale gestisce i dati, esegue query e avvia le transazioni. Dopo aver stabilito la connessione, l'applicazione client può inviare comandi al server e ricevere risposte. Tuttavia, la creazione di una nuova connessione per ogni operazione può causare problemi di prestazioni per le applicazioni cruciali. Ogni volta che si crea una nuova connessione, Database di Azure per PostgreSQL avvia un nuovo processo usando il processo postmaster, che utilizza più risorse.

Per risolvere questo problema, usare il pool di connessioni per creare una cache di connessioni che Database di Azure per PostgreSQL possono riutilizzare. Quando un'applicazione o un client richiede una connessione, proviene dal pool di connessioni. Al termine della sessione o della transazione, la connessione torna al pool per il riutilizzo. Riutilizzando le connessioni, si riduce l'utilizzo delle risorse e si migliorano le prestazioni.

Sebbene esistano strumenti diversi per il pool di connessioni, questa sezione illustra diverse strategie per l'uso del pool di connessioni tramite PgBouncer.

Che cos'è PgBouncer?

PgBouncer è un pooler di connessioni efficiente progettato per PostgreSQL. Riduce il tempo di elaborazione e ottimizza l'utilizzo delle risorse quando si gestiscono più connessioni client a uno o più database. PgBouncer offre tre modalità di pooling distinte per la rotazione delle connessioni:

• Pooling di sessioni: questo metodo assegna una connessione server all'applicazione client per l'intera durata della connessione del client. Quando l'applicazione client si disconnette, PgBouncer restituisce prontamente la connessione server al pool. Il pooling di sessioni è la modalità predefinita in PgBouncer open source. Per altre informazioni, vedere Configurazione di PgBouncer.
• Pool di transazioni: con il pool di transazioni, una connessione server è dedicata all'applicazione client durante una transazione. Al termine della transazione, PgBouncer rilascia la connessione al server, rendendola nuovamente disponibile all'interno del pool. Il pooling delle transazioni è la modalità predefinita nel PgBouncer integrato di Database di Azure per PostgreSQL e non supporta le transazioni preparate.
• Pooling dell'istruzione: nel pooling dell'istruzione, viene allocata una connessione server all'applicazione client per ogni singola istruzione. Al termine dell'istruzione, la connessione al server viene restituita al pool di connessioni. Le transazioni con istruzioni multiple non sono supportate in questa modalità.

È possibile usare PgBouncer in tre modelli di utilizzo distinti:

• Distribuzione di PgBouncer e co-locazione dell'applicazione
• Distribuzioni di PgBouncer centralizzate indipendenti dall'applicazione
• Distribuzione predefinita di PgBouncer e database

Ognuno di questi modelli presenta vantaggi e svantaggi specifici.

Distribuzione di corilevazione delle applicazioni e PgBouncer

Quando si usa questo approccio, si distribuisce PgBouncer nello stesso server in cui è ospitata l'applicazione. È possibile distribuire l'applicazione e PgBouncer in macchine virtuali tradizionali o all'interno di un'architettura basata su microservizi, come evidenziato:

PgBouncer distribuito nella macchina virtuale dell'applicazione

Se l'applicazione viene eseguita in una macchina virtuale di Azure, è possibile configurare PgBouncer nella stessa macchina virtuale. Per installare e configurare PgBouncer come proxy di pool di connessioni con il server flessibile Database di Azure per PostgreSQL, vedere Passaggi per installare e configurare il proxy di pool di connessioni PgBouncer.

La distribuzione di PgBouncer in un server applicazioni può offrire diversi vantaggi, in particolare quando si lavora con i database del server flessibile di Database di Azure per PostgreSQL. Alcuni dei principali vantaggi e limitazioni di questo metodo di distribuzione sono:

Vantaggi:

• Riduzione della latenza: Distribuendo PgBouncer nella stessa macchina virtuale dell'applicazione, la comunicazione tra l'applicazione primaria e il pooler di connessioni è efficiente a causa della prossimità. La distribuzione di PgBouncer nella macchina virtuale dell'applicazione riduce al minimo la latenza e garantisce interazioni fluide e rapide.
• Maggiore sicurezza:PgBouncer può fungere da intermediario sicuro tra l'applicazione e il database, fornendo un ulteriore livello di sicurezza. Può applicare l'autenticazione e la crittografia, garantendo l'accesso al database solo ai client autorizzati.

In generale, la distribuzione di PgBouncer in un server applicazioni offre un approccio più efficiente, sicuro e scalabile alla gestione delle connessioni a Database di Azure per PostgreSQL - Server flessibile, migliorando le prestazioni e l'affidabilità dell'applicazione.

Limitations:

• Singolo punto di guasto: Se si distribuisce PgBouncer come singola istanza nel server applicazioni, diventa un singolo punto di errore. Se l'istanza di PgBouncer diventa inattiva, può interrompere l'intero pool di connessioni di database, causando tempi di inattività per l'applicazione. Per attenuare questo singolo punto di guasto, configurare più istanze di PgBouncer dietro un bilanciamento del carico per garantire l'alta disponibilità.
• Scalabilità limitata: la scalabilità di PgBouncer dipende dalla capacità del server in cui è distribuito. Se il server applicazioni raggiunge il limite di connessione, PgBouncer potrebbe diventare un collo di bottiglia, limitando la possibilità di ridimensionare l'applicazione. Potrebbe essere necessario distribuire il carico di connessione tra più istanze di PgBouncer o prendere in considerazione soluzioni alternative come il pool di connessioni a livello di applicazione.
• Complessità della configurazione: la configurazione e l'ottimizzazione di PgBouncer possono essere operazioni complesse, soprattutto quando si considerano fattori come limiti di connessione, dimensionamento del pool e bilanciamento del carico. Gli amministratori devono ottimizzare attentamente la configurazione di PgBouncer per soddisfare i requisiti dell'applicazione e garantire stabilità e prestazioni ottimali.

Valutare queste limitazioni rispetto ai vantaggi e valutare se PgBouncer è la scelta giusta per l'applicazione e la configurazione del database specifica.

PgBouncer distribuito come sidecar del servizio Azure Kubernetes

È possibile usare PgBouncer come contenitore sidecar se l'applicazione è containerizzata ed è in esecuzione su Servizio Azure Kubernetes (AKS), Azure Container Instance (ACI), App contenitore di Azure (ACA) o Azure Red Hat OpenShift (ARO). Il modello sidecar trae ispirazione dal concetto di sidecar che si collega a una moto. Un contenitore ausiliario, noto come sidecar container, è associato a un'applicazione principale. Questo modello arricchisce l'applicazione padre estendendone le funzionalità e fornendo un supporto aggiuntivo.

La distribuzione di PgBouncer in un sidecar dell'AKS associa strettamente i cicli di vita dell'applicazione e del sidecar e condivide risorse come nome host e rete per un uso efficiente delle risorse. Il sidecar PgBouncer viene eseguito accanto al contenitore dell'applicazione all'interno dello stesso pod in Servizio Azure Kubernetes (AKS), in un rapporto 1:1, e funge da proxy per il pooling delle connessioni per i server flessibili di Database di Azure per PostgreSQL.

Microsoft pubblica un'immagine del proxy sidecar PgBouncer in Registro Container.

Per altri dettagli, vedere questo articolo.

Alcuni dei principali vantaggi e limitazioni di questo metodo di distribuzione sono:

Vantaggi:

• Latenza ridotta: distribuendo PgBouncer come sidecar del servizio Azure Kubernetes, la comunicazione tra l'applicazione primaria e il pooler di connessioni è efficiente e non presenta problemi grazie alla loro prossimità. La distribuzione di PgBouncer come sidecar del servizio Azure Kubernetes riduce al minimo la latenza e garantisce interazioni rapide e senza ostacoli.
• Gestione e distribuzione semplificate: la stretta associazione tra PgBouncer e il contenitore dell'applicazione semplifica il processo di gestione e distribuzione. Entrambi i componenti sono strettamente integrati, in modo da poterli amministrare più facilmente e coordinarli senza problemi.
• Alta disponibilità e resilienza delle connessioni: Se si verifica un guasto o un riavvio del contenitore dell'applicazione, il contenitore sidecar PgBouncer si riavvia a sua volta, garantendo alta disponibilità e resilienza delle connessioni. Questa configurazione garantisce la resilienza della connessione e mantiene prestazioni prevedibili anche durante i failover, contribuendo a creare un sistema solido e affidabile.

Considerando PgBouncer come sidecar del servizio Azure Kubernetes, è possibile usare questi vantaggi per migliorare le prestazioni dell'applicazione, semplificare la gestione e garantire la disponibilità continua del pooler di connessioni.

Limitations:

• Problemi di prestazioni della connessione: Le applicazioni su larga scala che utilizzano migliaia di pod, ciascuno dei quali esegue un sidecar PgBouncer, potrebbero incontrare difficoltà legate al possibile esaurimento delle connessioni al database. Questa situazione può comportare una riduzione del livello delle prestazioni e interruzioni del servizio. La distribuzione di un PgBouncer sidecar per ogni pod aumenta il numero di connessioni simultanee al server di database, che può superare la sua capacità. Di conseguenza, il database potrebbe avere difficoltà a gestire il volume elevato di connessioni in ingresso, causando problemi di prestazioni, ad esempio tempi di risposta maggiori o persino interruzioni del servizio.
• Distribuzione complessa: l'utilizzo del modello sidecar introduce un livello di complessità per il processo di distribuzione, poiché prevede l'esecuzione di due contenitori all'interno dello stesso pod. Questa complessità può potenzialmente complicare la risoluzione dei problemi e le attività di debug, richiedendo ulteriori sforzi per identificare e risolvere i problemi.
• Problemi di ridimensionamento: Il modello sidecar potrebbe non essere la scelta ideale per le applicazioni che richiedono scalabilità elevata. L'inclusione di un contenitore sidecar può imporre più requisiti di risorse, limitando potenzialmente il numero di pod che è possibile creare e gestire in modo efficace.

Considerando questo modello sidecar, valutare attentamente i compromessi tra la complessità della distribuzione e i requisiti di scalabilità per determinare l'approccio più appropriato per lo scenario di applicazione specifico.

Indipendente dall'applicazione - Distribuzione centralizzata di PgBouncer

Quando si usa questo approccio, si distribuisce PgBouncer come servizio centralizzato indipendente dall'applicazione. È possibile distribuire il servizio PgBouncer in macchine virtuali tradizionali o all'interno di un'architettura basata su microservizi, come evidenziato nelle sezioni seguenti:

PgBouncer distribuito in una macchina virtuale Ubuntu dietro Azure Load Balancer

Configurare il proxy di connessione PgBouncer tra l'applicazione e il livello di database dietro un Azure Load Balancer, come illustrato nell'immagine seguente. In questo schema, si distribuiscono più istanze di PgBouncer dietro un bilanciatore del carico per mitigare un singolo punto di guasto. Questo modello è adatto anche negli scenari in cui l'applicazione è in esecuzione in un servizio gestito, ad esempio Servizi app di Azure o Funzioni di Azure, e si connette al servizio PgBouncer per semplificare l'integrazione con l'infrastruttura esistente.

Per installare e configurare il proxy per il pooling delle connessioni PgBouncer con il server flessibile di Database di Azure per PostgreSQL, consulta Passaggi per installare e configurare il proxy per il pooling delle connessioni PgBouncer.

Alcuni dei principali vantaggi e limitazioni di questo metodo di distribuzione sono:

Vantaggi:

• Rimozione di un singolo punto di errore: La connettività dell'applicazione non è interessata dall'errore di una singola macchina virtuale PgBouncer, perché diverse istanze di PgBouncer si trovano dietro Azure Load Balancer.
• Integrazione semplice con i servizi gestiti: se l'applicazione è ospitata in una piattaforma di servizi gestiti, ad esempio Servizi app di Azure o Funzioni di Azure, la distribuzione di PgBouncer su una macchina virtuale consente una facile integrazione con l'infrastruttura esistente.
• Configurazione semplificata nella macchina virtuale di Azure: se l'applicazione è già in esecuzione su una macchina virtuale di Azure, configurare PgBouncer nella stessa macchina virtuale è semplice. La distribuzione di PgBouncer nella macchina virtuale garantisce che PgBouncer venga distribuito in prossimità dell'applicazione, riducendo al minimo la latenza di rete e ottimizzando le prestazioni.
• Configurazione non intrusiva: Distribuendo PgBouncer in una macchina virtuale, è possibile evitare di modificare i parametri nel server flessibile Database di Azure per PostgreSQL. Questa configurazione è utile quando si vuole configurare PgBouncer in un server flessibile Database di Azure per PostgreSQL. Ad esempio, la modifica del parametro SSLMODE su "required" in un server flessibile Database di Azure per PostgreSQL potrebbe causare l'esito negativo di alcune applicazioni che si basano su SSLMODE=FALSE. La distribuzione di PgBouncer in una macchina virtuale separata consente di mantenere la configurazione del server predefinita, pur sfruttando i vantaggi di PgBouncer.

Considerando questi vantaggi, la distribuzione di PgBouncer su una macchina virtuale offre una soluzione conveniente ed efficiente per migliorare le prestazioni e la compatibilità dell'applicazione in esecuzione nell'infrastruttura di Azure.

Limitations:

• Overhead di gestione: Durante l'installazione di PgBouncer in una macchina virtuale, potrebbe verificarsi un sovraccarico di gestione per gestire più file di configurazione. Questa configurazione rende difficile gestire gli aggiornamenti delle versioni, le nuove versioni e gli aggiornamenti del prodotto.
• Parità di funzionalità: Se si esegue la migrazione da PostgreSQL tradizionale a un server flessibile Database di Azure per PostgreSQL e si usa PgBouncer, potrebbero esistere alcuni gap di funzionalità. Ad esempio, mancanza di supporto md5 in Database di Azure per PostgreSQL.

PgBouncer centralizzato distribuito come servizio all'interno del servizio Azure Kubernetes

Se si usano distribuzioni altamente scalabili e di grandi dimensioni in contenitori in Servizio Azure Kubernetes (AKS), costituite da centinaia di pod o in situazioni in cui più applicazioni devono connettersi a un database condiviso, usare PgBouncer come servizio autonomo anziché come contenitore sidecar.

Usando PgBouncer come servizio separato, è possibile gestire in modo efficiente il pool di connessioni per le applicazioni su scala più ampia. Questo approccio centralizza la funzionalità di pool di connessioni, consentendo a più applicazioni di connettersi alla stessa risorsa di database mantenendo al contempo prestazioni ottimali e l'utilizzo delle risorse.

Usare l'immagine del proxy sidecar PgBouncer pubblicata in Microsoft Container Registry per creare e distribuire un servizio.

Alcuni dei principali vantaggi e limitazioni di questo metodo di distribuzione sono:

Vantaggi:

• Affidabilità avanzata: La distribuzione di PgBouncer come servizio autonomo consente di configurarla in modo a disponibilità elevata. Questa configurazione migliora l'affidabilità complessiva dell'infrastruttura di pool di connessioni, garantendo la disponibilità continua anche in caso di errori o interruzioni.
• Utilizzo ottimale delle risorse: Se l'applicazione o il server di database dispone di risorse limitate, un computer separato dedicato all'esecuzione del servizio PgBouncer può essere vantaggioso. Distribuendo PgBouncer in un computer con risorse ampie, si garantiscono prestazioni ottimali e si evitano problemi di contesa delle risorse.
• Gestione centralizzata della connessione: Quando è richiesta la gestione centralizzata delle connessioni alle banche dati, un servizio PgBouncer autonomo offre un approccio più semplificato. Consolidando le attività di gestione delle connessioni in un servizio centralizzato, è possibile monitorare e controllare in modo efficace le connessioni ai database tra più applicazioni, semplificando l'amministrazione e garantendo coerenza.

Considerando PgBouncer come servizio autonomo all'interno del servizio Azure Kubernetes, è possibile usare questi vantaggi per ottenere un miglioramento dell'affidabilità, dell'efficienza delle risorse e della gestione centralizzata delle connessioni ai database.

Limitations:

• Maggiore latenza N/W: Quando si distribuisce PgBouncer come servizio autonomo, prendere in considerazione la potenziale introduzione di una maggiore latenza. Questa latenza si verifica perché l'applicazione e il servizio PgBouncer devono passare le connessioni attraverso la rete. Valutare i requisiti di latenza dell'applicazione e considerare i compromessi tra la gestione centralizzata delle connessioni e i potenziali problemi di latenza.

Mentre PgBouncer in esecuzione come servizio autonomo offre vantaggi come la gestione centralizzata e l'ottimizzazione delle risorse, valutare l'impatto della potenziale latenza sulle prestazioni dell'applicazione per garantire che sia allineato ai requisiti specifici.

PgBouncer integrato del database di Azure per PostgreSQL

Database di Azure per PostgreSQL offre PgBouncer come soluzione di pool di connessioni predefinita. È possibile abilitare questo servizio facoltativo in base al server di database. PgBouncer viene eseguito nella stessa macchina virtuale del server flessibile Database di Azure per PostgreSQL. Man mano che il numero di connessioni aumenta oltre alcune centinaia o migliaia, Database di Azure per PostgreSQL potrebbero riscontrare limitazioni delle risorse. In questi casi, PgBouncer predefinito può offrire un vantaggio significativo migliorando la gestione delle connessioni inattive e di breve durata nel server di database.

Per informazioni su come abilitare e configurare il pool di connessioni PgBouncer in Database di Azure per PostgreSQL, vedere PgBouncer in Database di Azure per PostgreSQL server flessibile.

Alcuni dei principali vantaggi e limitazioni di questo metodo di distribuzione sono:

Vantaggi:

• Configurazione facile: Usando il PgBouncer predefinito nel server flessibile Database di Azure per PostgreSQL, non è necessaria un'installazione separata o una configurazione complessa. È possibile configurarlo direttamente dai parametri, garantendo un'esperienza senza problemi.
• Comodità del servizio gestito: Come servizio gestito, è possibile usufruire dei vantaggi di altri servizi gestiti Azure. Questo vantaggio include aggiornamenti automatici, eliminando la necessità di manutenzione manuale e garantendo che PgBouncer rimanga aggiornato con le funzionalità e le patch di sicurezza più recenti.
• Supporto delle connessioni pubbliche e private: Il pgBouncer predefinito nel server flessibile Database di Azure per PostgreSQL offre supporto per le connessioni pubbliche e private. Questo supporto consente di stabilire connessioni sicure su reti private o connettersi esternamente, a seconda dei requisiti specifici.
• Disponibilità elevata: in caso di failover, in cui a un server di standby viene assegnato ruolo primario, PgBouncer si riavvia senza problemi al momento dello standby appena avviato senza dover modificare la stringa di connessione dell'applicazione. Questa funzionalità garantisce la disponibilità continua e riduce al minimo le interruzioni dell'applicazione.
• Conveniente: È conveniente perché non è necessario pagare per un calcolo aggiuntivo, ad esempio vm o contenitori, anche se ha un impatto sulla CPU perché si tratta di un altro processo in esecuzione nello stesso computer.

Usando pgBouncer integrato in un server flessibile Database di Azure per PostgreSQL, è possibile usufruire della praticità della configurazione semplificata, dell'affidabilità di un servizio gestito, del supporto per varie modalità di pooling e della massima disponibilità elevata durante gli scenari di failover.

Limitations:

• Non supportato con Burstable:PgBouncer non è attualmente supportato con il livello di calcolo del server burstable. Se si modifica il livello di calcolo da Utilizzo generico o Ottimizzato per la memoria a Con possibilità di burst, si perde la funzionalità di PgBouncer.
• Ripristinare le connessioni dopo i riavvii: Ogni volta che il server viene riavviato durante operazioni di scalabilità, un failover ad alta disponibilità o altri riavvii, PgBouncer viene riavviato insieme alla macchina virtuale del server. Di conseguenza, le connessioni esistenti devono essere ristabilite.

Questo articolo illustra diversi modi per implementare PgBouncer. La tabella seguente riepiloga il metodo di distribuzione da scegliere:

Criteri di selezione	PgBouncer nella macchina virtuale dell'app	PgBouncer nella macchina virtuale con ALB*	PgBouncer su sidecar del servizio Azure Kubernetes	PgBouncer come servizio	PgBouncer integrato del database di Azure per PostgreSQL
Gestione semplificata
DISPONIBILITÀ ELEVATA
App in contenitori
Sovraccarico e latenza di rete ridotto
Controllo con granularità fine sul monitoraggio e sul debug

Legenda

Livello di difficoltà	Simbolo
Easy
Intermedio
Difficile

*ALB: Azure Load Balancer.

Contenuti correlati

• PgBouncer nel database flessibile di Azure per PostgreSQL
• Librerie di connessione