Strategi för anslutningspooler för Azure Database for PostgreSQL – flexibel server med PgBouncer

GÄLLER FÖR: Azure Database for PostgreSQL – flexibel server

Strategisk vägledning för att välja mekanism för anslutningspooler för flexibel Azure Database for PostgreSQL-server.

Introduktion

När du använder en flexibel Azure Database for PostgreSQL-server måste du skapa en kommunikationskanal mellan klientprogrammet och servern för att upprätta en anslutning till databasen. Den här kanalen ansvarar för att hantera data, köra frågor och initiera transaktioner. När anslutningen har upprättats kan klientprogrammet skicka kommandon till servern och ta emot svar. Att skapa en ny anslutning för varje åtgärd kan dock orsaka prestandaproblem för verksamhetskritiska program. Varje gång en ny anslutning skapas skapar Azure Database for PostgreSQL flexibel server en ny process med postmaster-processen, som förbrukar mer resurser.

För att undvika det här problemet används anslutningspooler för att skapa en cache med anslutningar som kan återanvändas i en flexibel Azure Database for PostgreSQL-server. När ett program eller en klient begär en anslutning skapas den från anslutningspoolen. När sessionen eller transaktionen har slutförts returneras anslutningen till poolen för återanvändning. Genom att återanvända anslutningar minskas resursanvändningen och prestandan förbättras.

Även om det finns olika verktyg för anslutningspooler diskuterar vi i det här avsnittet olika strategier för att använda anslutningspooler med hjälp av PgBouncer.

Vad är PgBouncer?

PgBouncer är en effektiv anslutningspool som utformats för PostgreSQL och erbjuder fördelen med att minska bearbetningstiden och optimera resursanvändningen vid hantering av flera klientanslutningar till en eller flera databaser. PgBouncer innehåller tre distinkta poollägen för anslutningsrotation:

• Sessionspool: Den här metoden tilldelar en serveranslutning till klientprogrammet under hela varaktigheten för klientens anslutning. Vid frånkoppling av klientprogrammet returnerar PgBouncer omedelbart serveranslutningen tillbaka till poolen. Mekanismen för sessionspooler är standardläget i PgBouncer med öppen källkod. Se PgBouncer-konfiguration
• Transaktionspool: Med transaktionspooler är en serveranslutning dedikerad till klientprogrammet under en transaktion. När transaktionen har slutförts släpper PgBouncer på ett intelligent sätt serveranslutningen, vilket gör den tillgänglig igen i poolen. Transaktionspooler är standardläget i Azure Database for PostgreSQL– flexibel servers inbyggda PgBouncer och stöder inte förberedda transaktioner.
• Instruktionspool: I instruktionspooler allokeras en serveranslutning till klientprogrammet för varje enskild instruktion. När instruktionen är klar returneras serveranslutningen omedelbart till anslutningspoolen. Observera att transaktioner med flera instruktioner inte stöds i det här läget.

Den effektiva användningen av PgBouncer kan kategoriseras i tre distinkta användningsmönster.

• Distribution av PgBouncer och Application Colocation
• Programoberoende centraliserade PgBouncer-distributioner
• Inbyggd PgBouncer- och databasdistribution

Var och en av dessa mönster har sina egna fördelar och nackdelar.

1. Distribution av PgBouncer och programsamlokalisering

När du använder den här metoden distribueras PgBouncer på samma server där programmet finns. Programmet och PgBouncer kan distribueras antingen på traditionella virtuella datorer eller inom en mikrotjänstbaserad arkitektur enligt beskrivningen:

I. PgBouncer distribuerad i en virtuell programdator

Om ditt program körs på en virtuell Azure-dator kan du konfigurera PgBouncer på samma virtuella dator. Om du vill installera och konfigurera PgBouncer som en anslutningspoolproxy med flexibel Azure Database for PostgreSQL-server följer du anvisningarna i följande länk.

Att distribuera PgBouncer på en programserver kan ge flera fördelar, särskilt när du arbetar med flexibla serverdatabaser i Azure Database for PostgreSQL. Några av de viktigaste fördelarna och begränsningarna med den här distributionsmetoden är:

Fördelar:

• Kortare svarstid: Genom att distribuera PgBouncer på samma virtuella programdator är kommunikationen mellan det primära programmet och anslutningspoolen effektiv på grund av deras närhet. Distribution av PgBouncer på den virtuella programdatorn minimerar svarstiden och säkerställer smidiga och snabba interaktioner.
• Förbättrad säkerhet: PgBouncer kan fungera som en säker mellanhand mellan programmet och databasen, vilket ger ett extra säkerhetslager. Det kan framtvinga autentisering och kryptering, vilket säkerställer att endast auktoriserade klienter kan komma åt databasen.

Att distribuera PgBouncer på en programserver ger en mer effektiv, säker och skalbar metod för att hantera anslutningar till Azure Database for PostgreSQL– flexibla serverdatabaser, vilket förbättrar programmets prestanda och tillförlitlighet.

Begränsningar:

• Enskild felpunkt: Om PgBouncer distribueras som en enda instans på programservern blir det en potentiell felpunkt. Om PgBouncer-instansen slutar fungera kan den störa hela databasanslutningspoolen, vilket orsakar driftstopp för programmet. För att undvika en enskild felpunkt kan du konfigurera flera PgBouncer-instanser bakom en lastbalanserare för hög tillgänglighet.
• Begränsad skalbarhet: PgBouncer-skalbarhet beror på kapaciteten på den server där den distribueras. Om programservern når anslutningsgränsen kan PgBouncer bli en flaskhals, vilket begränsar möjligheten att skala programmet. Du kan behöva distribuera anslutningsbelastningen över flera PgBouncer-instanser eller överväga alternativa lösningar som anslutningspooler på programnivå.
• Konfigurationskomplexitet: Konfiguration och finjustering av PgBouncer kan vara komplext, särskilt när du överväger faktorer som anslutningsgränser, poolstorlek och belastningsutjämning. Administratörer måste noggrant justera PgBouncer-konfigurationen för att matcha programmets krav och säkerställa optimal prestanda och stabilitet.

Det är viktigt att väga dessa begränsningar mot fördelarna och utvärdera om PgBouncer är rätt val för din specifika program- och databaskonfiguration.

II. PgBouncer distribueras som en AKS-sidovagn

Det är möjligt att använda PgBouncer som en sidovagnscontainer om ditt program är containerbaserat och körs på Azure Kubernetes Service (AKS), Azure Container Instance (ACI), Azure Container Apps (ACA) eller Azure Red Hat OpenShift (ARO). Sidecar-mönstret hämtar sin inspiration från konceptet med en sidovagn som är kopplad till en motorcykel, där en extra container, känd som sidovagnscontainern, är kopplad till ett överordnat program. Det här mönstret berikar det överordnade programmet genom att utöka dess funktioner och leverera kompletterande support.

Sidovagnsmönstret används vanligtvis med containrar som samplaneras som en atomisk containergrupp. Distributionen av PgBouncer i en AKS-sidovagn kopplar tätt ihop program- och sidovagnslivscyklerna och delar resurser som värdnamn och nätverk för att effektivt använda resurser. PgBouncer-sidovagnen fungerar tillsammans med programcontainern i samma podd i Azure Kubernetes Service (AKS) med 1:1-mappning som fungerar som en anslutningspoolproxy för Azure Database for PostgreSQL – flexibel server.

Det här sidovagnsmönstret används vanligtvis med containrar som samplaneras som en atomisk containergrupp. sidecar-mönstret binder starkt programmet och sidovagnens livscykel och har delade resurser som värdnamn och nätverk. Med den här konfigurationen optimerar PgBouncer anslutningshantering och underlättar effektiv kommunikation mellan programmet och Azure Database for PostgreSQL– flexibel serverinstans.

Microsoft har publicerat en PgBouncer-sidovagnsproxyavbildning i Microsoft Container Registry.

Mer information finns i det här avsnittet.

Några av de viktigaste fördelarna och begränsningarna med den här distributionsmetoden är:

Fördelar:

• Kortare svarstid: Genom att distribuera PgBouncer som en AKS-sidovagn är kommunikationen mellan det primära programmet och anslutningspoolen sömlös och effektiv på grund av deras närhet. Att distribuera PgBouncer en AKS-sidovagn minimerar svarstiden och säkerställer smidiga och snabba interaktioner.
• Förenklad hantering och distribution: Den snäva kopplingen mellan PgBouncer och programcontainern förenklar hanterings- och distributionsprocessen. Båda komponenterna är tätt integrerade, vilket möjliggör enklare administration och sömlös samordning.
• Hög tillgänglighet och anslutningsåterhämtning: Om ett programcontainer misslyckas eller startas om följer PgBouncer-sidovagnscontainern noggrant, vilket säkerställer hög tillgänglighet. Den här konfigurationen garanterar anslutningsåterhämtning och bibehåller förutsägbara prestanda även under redundansväxlingar, vilket bidrar till ett tillförlitligt och robust system.

Genom att betrakta PgBouncer som en AKS-sidovagn kan du använda dessa fördelar för att förbättra programmets prestanda, effektivisera hanteringen och säkerställa kontinuerlig tillgänglighet för anslutningspoolen.

Begränsningar:

• Problem med anslutningsprestanda: Storskaliga program som använder tusentals poddar, var och en kör sidovagnen PgBouncer, kan stöta på potentiella utmaningar som rör överbelastning av databasanslutningar. Den här situationen kan leda till prestandaförsämring och avbrott i tjänsten. Om du distribuerar en sidvagns-PgBouncer för varje podd ökar antalet samtidiga anslutningar till databasservern, vilket kan överskrida dess kapacitet. Därför kan databasen ha svårt att hantera den stora mängden inkommande anslutningar, vilket kan leda till prestandaproblem som ökade svarstider eller till och med avbrott i tjänsten.
• Komplex distribution: Användningen av sidovagnsmönstret ger en komplexitetsnivå i distributionsprocessen, eftersom det innebär att två containrar körs i samma podd. Detta kan potentiellt komplicera felsöknings- och felsökningsaktiviteter, vilket kräver extra arbete för att identifiera och lösa problem.
• Skalningsutmaningar: Det är viktigt att observera att sidovagnsmönstret kanske inte är det perfekta valet för program som kräver hög skalbarhet. Införandet av en sidovagnscontainer kan medföra fler resurskrav, vilket potentiellt begränsar antalet poddar som effektivt kan skapas och hanteras.

Med tanke på det här sidovagnsmönstret är det viktigt att noggrant utvärdera kompromisserna mellan kraven på distributionskomplexitet och skalbarhet för att fastställa den lämpligaste metoden för ditt specifika programscenario.

2. Programoberoende – Centraliserad PgBouncer-distribution

När du använder den här metoden distribueras PgBouncer som en centraliserad tjänst, oberoende av programmet. PgBouncer-tjänsten kan distribueras antingen på traditionella virtuella datorer eller inom en mikrotjänstbaserad arkitektur enligt beskrivningen:

I. PgBouncer distribuerad i en virtuell ubuntu-dator bakom Azure Load Balancer

PgBouncer-anslutningsproxyn konfigureras mellan program- och databasskiktet bakom en Azure Load Balancer enligt bilden. I det här mönstret distribueras flera PgBouncer-instanser bakom en lastbalanserare som en tjänst för att minimera en enskild felpunkt. Det här mönstret är också lämpligt i scenarier där programmet körs på en hanterad tjänst som Azure App Services eller Azure Functions och ansluter till PgBouncer-tjänsten för enkel integrering med din befintliga infrastruktur.

Se länken för att installera och konfigurera PgBouncer-anslutningspoolproxy med Azure Database for PostgreSQL – flexibel server.

Några av de viktigaste fördelarna och begränsningarna med den här distributionsmetoden är:

Fördelar:

• Tar bort en enskild felpunkt: Programanslutningen kanske inte påverkas av felet för en enda virtuell PgBouncer-dator, eftersom det finns flera PgBouncer-instanser bakom Azure Load Balancer.
• Sömlös integrering med Managed Services: Om ditt program finns på en hanterad tjänstplattform, till exempel Azure App Services eller Azure Functions, kan du enkelt integrera PgBouncer på en virtuell dator med din befintliga infrastruktur.
• Förenklad installation på en virtuell Azure-dator: Om du redan kör programmet på en virtuell Azure-dator är det enkelt att konfigurera PgBouncer på samma virtuella dator. Om du distribuerar PgBouncer på den virtuella datorn ser du till att PgBouncer distribueras nära ditt program, vilket minimerar nätverksfördröjningen och maximerar prestandan.
• Icke-påträngande konfiguration: Genom att distribuera PgBouncer på en virtuell dator kan du undvika att ändra serverparametrar på en flexibel Azure Database for PostgreSQL-server. Detta är användbart när du vill konfigurera PgBouncer på en flexibel Azure Database for PostgreSQL-serverinstans. Om du till exempel ändrar SSLMODE-parametern till "obligatorisk" på Azure Database for PostgreSQL flexibel server kan vissa program som förlitar sig på SSLMODE=FALSE misslyckas. När du distribuerar PgBouncer på en separat virtuell dator kan du behålla standardserverkonfigurationen medan du fortfarande använder PgBouncer-fördelarna.

Genom att överväga dessa fördelar erbjuder distribution av PgBouncer på en virtuell dator en bekväm och effektiv lösning för att förbättra prestanda och kompatibilitet för ditt program som körs i Azure-infrastrukturen.

Begränsningar:

• Hanteringskostnader: Eftersom PgBouncer är installerat på en virtuell dator kan det finnas hanteringskostnader för att hantera flera konfigurationsfiler. Detta gör det svårt att hantera versionsuppgraderingar, nya versioner och produktuppdateringar.
• Funktionsparitet: Om du migrerar från traditionell PostgreSQL till en flexibel Azure Database for PostgreSQL-server och använder PgBouncer kan det finnas vissa funktionsluckor. Till exempel brist på md5-stöd i Azure Database for PostgreSQL – flexibel server.

II. Centraliserad PgBouncer distribuerad som en tjänst i AKS

Om du arbetar med mycket skalbara och stora containerbaserade distributioner i Azure Kubernetes Service (AKS), bestående av hundratals poddar eller i situationer där flera program behöver ansluta till en delad databas, kan PgBouncer användas som en fristående tjänst i stället för en sidovagnscontainer .

Genom att använda PgBouncer som en separat tjänst kan du effektivt hantera anslutningspooler för dina program i större skala. Med den här metoden kan du centralisera funktionerna för anslutningspooler, så att flera program kan ansluta till samma databasresurs samtidigt som optimal prestanda och resursanvändning bibehålls.

PgBouncer-proxyavbildning på sidovagn som publicerats i Microsoft Container Registry kan användas för att skapa och distribuera en tjänst.

Några av de viktigaste fördelarna och begränsningarna med den här distributionsmetoden är:

Fördelar:

• Förbättrad tillförlitlighet: Distribution av PgBouncer som en fristående tjänst möjliggör konfiguration på ett sätt med hög tillgänglighet. Detta förbättrar den övergripande tillförlitligheten för infrastrukturen för anslutningspooler, vilket säkerställer kontinuerlig tillgänglighet även vid fel eller störningar.
• Optimal resursanvändning: Om programmet eller databasservern har begränsade resurser kan det vara fördelaktigt att välja en separat dator som är dedikerad för att köra PgBouncer-tjänsten . Genom att distribuera PgBouncer på en dator med gott om resurser kan du säkerställa optimala prestanda och förhindra problem med resurskonkurrens.
• Centraliserad anslutningshantering: När centraliserad hantering av databasanslutningar är ett krav ger en fristående PgBouncer-tjänst en mer effektiv metod. Genom att konsolidera uppgifter för anslutningshantering i en centraliserad tjänst kan du effektivt övervaka och kontrollera databasanslutningar i flera program, förenkla administrationen och säkerställa konsekvens.

Genom att betrakta PgBouncer som en fristående tjänst i AKS kan du använda dessa fördelar för att få bättre tillförlitlighet, resurseffektivitet och centraliserad hantering av databasanslutningar.

Begränsningar:

• Ökad N/W-svarstid: När du distribuerar PgBouncer som en fristående tjänst är det viktigt att överväga den potentiella introduktionen av mer svarstid. Detta beror på behovet av att anslutningar skickas mellan programmet och PgBouncer-tjänsten via nätverket. Det är viktigt att utvärdera svarstidskraven för ditt program och överväga kompromisserna mellan centraliserad anslutningshantering och potentiella svarstidsproblem.

Även om PgBouncer som körs som en fristående tjänst erbjuder fördelar som centraliserad hantering och resursoptimering, är det viktigt att utvärdera effekten av potentiella svarstider på programmets prestanda för att säkerställa att den överensstämmer med dina specifika krav.

3. Inbyggd PgBouncer i Azure Database for PostgreSQL – flexibel server

Azure Database for PostgreSQL – flexibel server erbjuder PgBouncer som en inbyggd lösning för anslutningspooler. Detta erbjuds som en valfri tjänst som kan aktiveras per databasserver. PgBouncer körs på samma virtuella dator som azure database for PostgreSQL– flexibel serverinstans. När antalet anslutningar ökar över några hundra eller tusen kan Azure Database for PostgreSQL– flexibel server stöta på resursbegränsningar. I sådana fall kan inbyggda PgBouncer ge en betydande fördel genom att förbättra hanteringen av inaktiva och kortvariga anslutningar på databasservern.

Se länken för att aktivera och konfigurera PgBouncer-anslutningspooler i Azure Database for PostgreSQL – flexibel server.

Några av de viktigaste fördelarna och begränsningarna med den här distributionsmetoden är:

Fördelar:

• Sömlös konfiguration: Med den inbyggda PgBouncer i Azure Database for PostgreSQL – flexibel server behövs ingen separat installation eller komplex installation. Det kan enkelt konfigureras direkt från serverparametrarna, vilket ger en problemfri upplevelse.
• Hanterad tjänst bekvämlighet: Som en hanterad tjänst kan användarna dra nytta av fördelarna med andra Azure-hanterade tjänster. Detta inkluderar automatiska uppdateringar, vilket eliminerar behovet av manuellt underhåll och säkerställer att PgBouncer håller sig uppdaterad med de senaste funktionerna och säkerhetskorrigeringarna.
• Stöd för offentlig och privat anslutning: Den inbyggda PgBouncer i Azure Database for PostgreSQL – flexibel server ger stöd för både offentliga och privata anslutningar. Detta gör det möjligt för användare att upprätta säkra anslutningar via privata nätverk eller ansluta externt, beroende på deras specifika krav.
• Hög tillgänglighet (HA): I händelse av en redundansväxling, där en väntelägesserver befordras till den primära rollen, startar PgBouncer sömlöst om i det nyligen upphöjda vänteläget utan några ändringar som krävs för programmet anslutningssträng. Detta säkerställer kontinuerlig tillgänglighet och minimerar avbrott i programmet.
• Kostnadseffektivt: Det är kostnadseffektivt eftersom användarna inte behöver betala för extra beräkning som virtuell dator eller containrar, även om det har viss CPU-inverkan eftersom det är en annan process som körs på samma dator.

Med inbyggd PgBouncer i Azure Database for PostgreSQL – flexibel server kan användarna njuta av bekvämligheten med förenklad konfiguration, tillförlitligheten hos en hanterad tjänst, stöd för olika poollägen och sömlös hög tillgänglighet under redundansscenarier.

Begränsningar:

• Stöds inte med Burstable: PgBouncer stöds för närvarande inte med burstbar serverberäkningsnivå. Om du ändrar beräkningsnivån från Generell användning eller Minnesoptimerad till burstbar nivå förlorar du PgBouncer-funktionen.
• Återupprätta anslutningar efter omstarter: När servern startas om under skalningsåtgärder, ha-redundans eller en omstart startas PgBouncer också om tillsammans med den virtuella serverdatorn. Befintliga anslutningar måste därför återupprättas.

Vi har diskuterat olika sätt att implementera PgBouncer och tabellen sammanfattar vilken distributionsmetod som ska väljas:

Urvalskriterier	PgBouncer på en virtuell appdator	PgBouncer på virtuell dator med ALB*	PgBouncer på AKS-sidovagn	PgBouncer som en tjänst	Azure Database for PostgreSQL – flexibel server inbyggd PgBouncer
Förenklad hantering
HA
Containerbaserade appar
Minskad nätverksbelastning och svarstid
Detaljerad kontroll vid övervakning och felsökning

Förklaring

Svårighetsgrad	Symbol
Enkelt
Medium
Svårt

*ALB: Azure Load Balancer.