Strategie voor connectionpooling met PgBouncer in Azure Database for PostgreSQL Flexible Server

Dit artikel bevat strategische richtlijnen voor het selecteren van een mechanisme voor groepsgewijze verbindingen voor uw Azure Database for PostgreSQL flexibele servers.

Introductie

Wanneer u een Azure Database for PostgreSQL flexibele server gebruikt, maakt u een verbinding met de database door een communicatiekanaal tot stand te brengen tussen de clienttoepassing en de server. Dit kanaal beheert gegevens, voert query's uit en initieert transacties. Nadat u de verbinding tot stand hebt gebracht, kan de clienttoepassing opdrachten verzenden naar de server en antwoorden ontvangen. Het maken van een nieuwe verbinding voor elke bewerking kan echter prestatieproblemen veroorzaken voor bedrijfskritieke toepassingen. Telkens wanneer u een nieuwe verbinding maakt, start Azure Database for PostgreSQL een nieuw proces met behulp van het postmasterproces, dat meer resources verbruikt.

U kunt dit probleem oplossen door verbindingsgroepen te gebruiken om een cache met verbindingen te maken die Azure Database for PostgreSQL opnieuw kunnen gebruiken. Wanneer een toepassing of client een verbinding aanvraagt, komt deze uit de verbindingsgroep. Nadat de sessie of transactie is voltooid, gaat de verbinding terug naar de pool voor hergebruik. Door verbindingen opnieuw te gebruiken, vermindert u het resourcegebruik en verbetert u de prestaties.

Hoewel er verschillende hulpprogramma's bestaan voor het groeperen van verbindingen, worden in deze sectie verschillende strategieën besproken voor het gebruik van verbindingspooling met behulp van PgBouncer.

Wat is PgBouncer?

PgBouncer is een efficiënte verbindingspooler die is ontworpen voor PostgreSQL. Het vermindert de verwerkingstijd en optimaliseert het resourcegebruik bij het beheren van meerdere clientverbindingen met een of meer databases. PgBouncer biedt drie verschillende poolingmodi voor verbindingsrotatie:

• Groepsgewijze sessies: met deze methode wordt een serververbinding toegewezen aan de clienttoepassing voor de volledige duur van de verbinding van de client. Wanneer de clienttoepassing de verbinding verbreekt, retourneert PgBouncer de serververbinding terug naar de pool. Sessiepooling is de standaardmodus in open source PgBouncer. Zie PgBouncer-configuratie voor meer informatie.
• Transactiepooling: Bij transactiepooling is een serververbinding toegewezen aan de clienttoepassing tijdens een transactie. Zodra de transactie is voltooid, brengt PgBouncer de serververbinding vrij, waardoor deze opnieuw beschikbaar is in de pool. Transactiepooling is de standaardmodus in de ingebouwde PgBouncer van Azure Database for PostgreSQL en biedt geen ondersteuning voor voorbereide transacties.
• Groepsgewijze instructie: In instructiegroepering wordt een serververbinding toegewezen aan de clienttoepassing voor elke afzonderlijke instructie. Wanneer de instructie is voltooid, wordt de serververbinding geretourneerd naar de verbindingsgroep. Transacties met meerdere instructies worden niet ondersteund in deze modus.

U kunt PgBouncer gebruiken in drie verschillende gebruikspatronen:

• Implementatie van PgBouncer en colocatie van toepassingen
• Toepassingsonafhankelijke gecentraliseerde PgBouncer-implementaties
• Ingebouwde PgBouncer- en database-implementatie

Elk van deze patronen heeft zijn eigen voor- en nadelen.

Implementatie van PgBouncer en colocatie van toepassingen

Wanneer u deze aanpak gebruikt, implementeert u PgBouncer op dezelfde server waarop uw toepassing wordt gehost. U kunt de toepassing en PgBouncer implementeren op traditionele virtuele machines of in een architectuur op basis van microservices, zoals gemarkeerd:

PgBouncer geïmplementeerd in toepassings-VM

Als uw toepassing wordt uitgevoerd op een Virtuele Azure-machine, kunt u PgBouncer instellen op dezelfde VIRTUELE machine. Als u PgBouncer wilt installeren en configureren als een verbindingspoolproxy met uw Azure Database for PostgreSQL flexibele server, raadpleegt u De stappen voor het installeren en instellen van pgBouncer-verbindingspoolingproxy.

Het implementeren van PgBouncer in een toepassingsserver kan verschillende voordelen bieden, met name wanneer u werkt met flexibele serverdatabases van Azure Database for PostgreSQL. Enkele van de belangrijkste voordelen en beperkingen van deze implementatiemethode zijn:

Voordelen:

• Verminderde latentie: Door PgBouncer op dezelfde toepassings-VM te implementeren, is communicatie tussen de primaire toepassing en de verbindingspooler efficiënt vanwege de nabijheid ervan. Het implementeren van PgBouncer in toepassings-VM minimaliseert latentie en zorgt voor soepele en snelle interacties.
• Verbeterde beveiliging:PgBouncer kan fungeren als een beveiligde intermediair tussen de toepassing en de database, waardoor er een extra beveiligingslaag wordt geboden. Het kan verificatie en versleuteling afdwingen, zodat alleen geautoriseerde clients toegang hebben tot de database.

Over het algemeen biedt het implementeren van PgBouncer in een toepassingsserver een efficiëntere, veilige en schaalbare benadering voor het beheren van verbindingen met flexibele Azure Database for PostgreSQL-serverdatabases, waardoor de prestaties en betrouwbaarheid van de toepassing worden verbeterd.

Limitations:

• Single point of failure: Als u PgBouncer als één exemplaar op de toepassingsserver implementeert, wordt dit een potentieel single point of failure. Als het PgBouncer-exemplaar uitvalt, kan dit de hele databaseverbindingsgroep verstoren, wat downtime voor de toepassing veroorzaakt. Om dit centrale storingspunt te beperken, configureert u meerdere PgBouncer-instanties achter een load balancer om hoge beschikbaarheid te waarborgen.
• Beperkte schaalbaarheid: PgBouncer-schaalbaarheid is afhankelijk van de capaciteit van de server waarop deze is geïmplementeerd. Als de toepassingsserver de verbindingslimiet bereikt, kan PgBouncer een knelpunt worden, waardoor de mogelijkheid om de toepassing te schalen wordt beperkt. Mogelijk moet u de verbindingsbelasting verdelen over meerdere PgBouncer-exemplaren of alternatieve oplossingen overwegen, zoals groepsgewijze verbindingen op toepassingsniveau.
• Configuratiecomplexiteit: PgBouncer configureren en verfijnen kan complex zijn, met name als u rekening houdt met factoren zoals verbindingslimieten, poolgrootte en taakverdeling. Beheerders moeten de PgBouncer-configuratie zorgvuldig afstemmen op de vereisten van de toepassing en zorgen voor optimale prestaties en stabiliteit.

Weeg deze beperkingen af tegen de voordelen en evalueer of PgBouncer de juiste keuze is voor uw specifieke toepassing en database-instelling.

PgBouncer ingezet als een AKS-sidecar

U kunt PgBouncer als sidecar-container gebruiken als uw toepassing in een container is geplaatst en wordt uitgevoerd op Azure Kubernetes Service (AKS), Azure Container Instance (ACI), Azure Container Apps (ACA) of Azure Red Hat OpenShift (ARO). Het sidecar-patroon trekt zijn inspiratie uit het concept van een sidecar die aan een motorfiets wordt bevestigd. Een hulpcontainer, ook wel de sidecarcontainer genoemd, wordt gekoppeld aan een bovenliggende toepassing. Dit patroon verrijkt de bovenliggende toepassing door de functionaliteiten uit te breiden en aanvullende ondersteuning te bieden.

Het implementeren van PgBouncer in een AKS-sidecar koppelt de levenscyclus van de toepassing en sidecar nauw en deelt resources zoals hostnaam en netwerken om efficiënt gebruik te maken van resources. De PgBouncer-sidecar draait naast de applicatiecontainer binnen dezelfde pod in Azure Kubernetes Service (AKS), in een 1:1-relatie, en fungeert als proxy voor connection pooling voor Azure Database for PostgreSQL Flexible Server.

Microsoft publiceert een PgBouncer-sidecar-proxyimage in het Microsoft-containerregister.

Raadpleeg dit voor meer informatie.

Enkele van de belangrijkste voordelen en beperkingen van deze implementatiemethode zijn:

Voordelen:

• Verminderde latentie: door PgBouncer als AKS-sidecar te implementeren, is de communicatie tussen de primaire toepassing en de verbindingspooler naadloos en efficiënt vanwege hun nabijheid. Het implementeren van PgBouncer een AKS-sidecar minimaliseert latentie en zorgt voor soepele en snelle interacties.
• Vereenvoudigd beheer en implementatie: De nauwe koppeling van PgBouncer met de toepassingscontainer vereenvoudigt het beheer- en implementatieproces. Beide onderdelen zijn nauw geïntegreerd, zodat u ze eenvoudiger kunt beheren en naadloos kunt coördineren.
• Hoge beschikbaarheid en verbindingsveerkracht: Als een toepassingscontainer uitvalt of opnieuw wordt gestart, wordt de PgBouncer-sidecarcontainer direct mee opnieuw gestart, waardoor hoge beschikbaarheid wordt gewaarborgd. Deze installatie garandeert verbindingstolerantie en onderhoudt voorspelbare prestaties, zelfs tijdens failovers, die bijdragen aan een betrouwbaar en robuust systeem.

Door PgBouncer als AKS-sidecar te beschouwen, kunt u deze voordelen gebruiken om de prestaties van uw toepassing te verbeteren, het beheer te stroomlijnen en continue beschikbaarheid van de verbindingspooler te garanderen.

Limitations:

• Prestatieproblemen met de verbinding: Grootschalige toepassingen die gebruikmaken van duizenden pods, elke actieve sidecar PgBouncer, kunnen potentiële uitdagingen ondervinden met betrekking tot uitputting van databaseverbindingen. Deze situatie kan leiden tot prestatievermindering en serviceonderbrekingen. Het implementeren van een sidecar PgBouncer voor elke pod verhoogt het aantal gelijktijdige verbindingen met de databaseserver, dat de capaciteit ervan kan overschrijden. Als gevolg hiervan kan de database moeite hebben om het grote aantal binnenkomende verbindingen te verwerken, wat leidt tot prestatieproblemen, zoals verhoogde reactietijden of zelfs servicestoringen.
• Complexe implementatie: Het gebruik van het sidecar-patroon introduceert een complexiteitsniveau voor het implementatieproces, omdat er twee containers binnen dezelfde pod moeten worden uitgevoerd. Deze complexiteit kan het oplossen van problemen en foutopsporingsactiviteiten mogelijk bemoeilijken, waardoor er extra moeite nodig is om problemen te identificeren en op te lossen.
• Uitdagingen bij schalen: Het sidecar-patroon is mogelijk niet de ideale keuze voor toepassingen die een hoge schaalbaarheid eisen. Het toevoegen van een sidecar-container kan meer resources vereisen, wat mogelijk het aantal pods beperkt dat u effectief kunt aanmaken en beheren.

Houd rekening met dit sidecar-patroon en evalueer zorgvuldig de afwegingen tussen implementatiecomplexiteit en schaalbaarheidsvereisten om de meest geschikte benadering voor uw specifieke toepassingsscenario te bepalen.

Toepassingsonafhankelijk - gecentraliseerde PgBouncer-implementatie

Wanneer u deze benadering gebruikt, implementeert u PgBouncer als een gecentraliseerde service die onafhankelijk is van de toepassing. U kunt de PgBouncer-service implementeren op traditionele virtuele machines of in een architectuur op basis van microservices, zoals is gemarkeerd in de volgende secties:

PgBouncer geïmplementeerd in ubuntu-VM achter Azure Load Balancer

Stel de PgBouncer-verbindingsproxy in tussen de toepassings- en databaselaag achter een Azure Load Balancer, zoals wordt weergegeven in de volgende afbeelding. In dit patroon zet u meerdere PgBouncer-exemplaren achter een load balancer als dienst in om één storingspunt te beperken. Dit patroon is ook geschikt in scenario's waarin de toepassing wordt uitgevoerd op een beheerde service, zoals Azure-app Services of Azure Functions, en verbinding maakt met pgBouncer-service voor eenvoudige integratie met uw bestaande infrastructuur.

Zie Stappen voor het installeren en instellen van de proxy voor verbindingspooling PgBouncer voor informatie over het installeren en instellen van de proxy voor verbindingspooling PgBouncer met Azure Database for PostgreSQL Flexible Server.

Enkele van de belangrijkste voordelen en beperkingen van deze implementatiemethode zijn:

Voordelen:

• Single Point of Failure verwijderen: Toepassingsconnectiviteit wordt niet beïnvloed door de fout van één PgBouncer-VM, omdat verschillende PgBouncer-exemplaren zich achter Azure Load Balancer bevinden.
• Naadloze integratie met Managed Services: als uw toepassing wordt gehost op een beheerd serviceplatform, zoals Azure-app Services of Azure Functions, kunt u PgBouncer implementeren op een virtuele machine, zodat u eenvoudig kunt integreren met uw bestaande infrastructuur.
• Vereenvoudigde installatie op azure-VM: als u uw toepassing al uitvoert op een Azure-VM, is het instellen van PgBouncer op dezelfde VIRTUELE machine eenvoudig. Het implementeren van PgBouncer in vm zorgt ervoor dat PgBouncer dicht bij uw toepassing wordt geïmplementeerd, waardoor de netwerklatentie wordt geminimaliseerd en de prestaties worden gemaximaliseerd.
• Niet-intrusieve configuratie: Door PgBouncer op een virtuele machine te implementeren, kunt u voorkomen dat u parameters op uw Azure Database for PostgreSQL flexibele server wijzigt. Deze configuratie is handig als u PgBouncer wilt configureren op een Azure Database for PostgreSQL flexibele server. Als u bijvoorbeeld de parameter SSLMODE wijzigt in 'vereist' op een Azure Database for PostgreSQL flexibele server, kunnen bepaalde toepassingen die afhankelijk zijn van SSLMODE=FALSE mislukken. Door PgBouncer op een afzonderlijke VIRTUELE machine te implementeren, kunt u de standaardserverconfiguratie behouden terwijl u de voordelen van PgBouncer nog steeds gebruikt.

Door rekening te houden met deze voordelen biedt de implementatie van PgBouncer op een VIRTUELE machine een handige en efficiënte oplossing voor het verbeteren van de prestaties en compatibiliteit van uw toepassing die wordt uitgevoerd in de Azure-infrastructuur.

Limitations:

• Beheeroverhead: Wanneer u PgBouncer installeert in een virtuele machine, hebt u mogelijk beheeroverhead voor het beheren van meerdere configuratiebestanden. Deze installatie maakt het moeilijk om versie-upgrades, nieuwe releases en productupdates aan te kunnen.
• Functiepariteit: Als u migreert van traditionele PostgreSQL naar een Azure Database for PostgreSQL flexibele server en PgBouncer gebruikt, zijn er mogelijk enkele functieproblemen. Bijvoorbeeld, gebrek aan md5-ondersteuning in Azure Database for PostgreSQL.

Gecentraliseerde PgBouncer geïmplementeerd als een service in AKS

Als u werkt met zeer schaalbare en grote containerimplementaties op Azure Kubernetes Service (AKS), bestaande uit honderden pods of in situaties waarin meerdere toepassingen verbinding moeten maken met een gedeelde database, gebruikt u PgBouncer als zelfstandige service in plaats van een sidecar-container.

Door PgBouncer als een afzonderlijke service te gebruiken, kunt u op een bredere schaal efficiënt verbindingspooling voor uw toepassingen beheren en afhandelen. Deze methode centraliseert de functionaliteit voor groepsgewijze verbindingen, waardoor meerdere toepassingen verbinding kunnen maken met dezelfde databaseresource, terwijl optimale prestaties en resourcegebruik behouden blijven.

Gebruik de PgBouncer-sidecar-proxyimage die is gepubliceerd in het Microsoft-containerregister om een service te maken en te implementeren.

Enkele van de belangrijkste voordelen en beperkingen van deze implementatiemethode zijn:

Voordelen:

• Verbeterde betrouwbaarheid: Door PgBouncer als zelfstandige service te implementeren, kunt u deze op een maximaal beschikbare manier configureren. Deze configuratie verbetert de algemene betrouwbaarheid van de infrastructuur voor connection pooling, waardoor continue beschikbaarheid wordt gewaarborgd, zelfs in het geval van storingen of onderbrekingen.
• Optimaal resourcegebruik: Als uw toepassing of de databaseserver beperkte resources heeft, kan een afzonderlijke computer die is toegewezen aan het uitvoeren van de PgBouncer-service voordelig zijn. Door PgBouncer op een machine met voldoende resources te implementeren, zorgt u voor optimale prestaties en voorkomt u problemen met conflicten tussen resources.
• Gecentraliseerd verbindingsbeheer: wanneer gecentraliseerd beheer van databaseverbindingen een vereiste is, biedt een zelfstandige PgBouncer-service een meer gestroomlijnde benadering. Door verbindingsbeheertaken te consolideren in een gecentraliseerde service, kunt u databaseverbindingen effectief bewaken en beheren in meerdere toepassingen, het beheer vereenvoudigen en consistentie garanderen.

Door PgBouncer als zelfstandige service in AKS te beschouwen, kunt u deze voordelen gebruiken om een verbeterde betrouwbaarheid, resource-efficiëntie en gecentraliseerd beheer van databaseverbindingen te bereiken.

Limitations:

• Verhoogde N/W-latentie: Overweeg bij het implementeren van PgBouncer als een zelfstandige service de mogelijke introductie van meer latentie. Deze latentie treedt op omdat de toepassing en de PgBouncer-service verbindingen via het netwerk moeten doorgeven. Evalueer de latentievereisten van uw toepassing en overweeg de afwegingen tussen gecentraliseerd verbindingsbeheer en mogelijke latentieproblemen.

Hoewel PgBouncer die wordt uitgevoerd als een zelfstandige service voordelen biedt, zoals gecentraliseerd beheer en resourceoptimalisatie, beoordeelt u de impact van mogelijke latentie op de prestaties van uw toepassing om ervoor te zorgen dat deze overeenkomt met uw specifieke vereisten.

Ingebouwde PgBouncer in Azure Database for PostgreSQL

Azure Database for PostgreSQL biedt PgBouncer als een ingebouwde oplossing voor groepsgewijze verbindingen. U kunt deze optionele service per databaseserver inschakelen. PgBouncer wordt uitgevoerd op dezelfde virtuele machine als de Azure Database for PostgreSQL flexibele server. Naarmate het aantal verbindingen groter is dan een paar honderd of duizend, kan Azure Database for PostgreSQL resourcebeperkingen ondervinden. In dergelijke gevallen kan ingebouwde PgBouncer een aanzienlijk voordeel bieden door het beheer van niet-actieve en kortdurende verbindingen op de databaseserver te verbeteren.

Zie PgBouncer in Azure Database for PostgreSQL flexibele server voor meer informatie over het inschakelen en instellen van PgBouncer-verbindingspooling in Azure Database for PostgreSQL.

Enkele van de belangrijkste voordelen en beperkingen van deze implementatiemethode zijn:

Voordelen:

• Naadloze configuratie: Door de ingebouwde PgBouncer in uw Azure Database for PostgreSQL flexibele server te gebruiken, hebt u geen afzonderlijke installatie of complexe installatie nodig. U kunt deze eenvoudig rechtstreeks vanuit de parameters configureren, zodat u probleemloos kunt werken.
• Managed Service Convenience: Als beheerde service kunt u profiteren van de voordelen van andere Azure beheerde services. Dit voordeel omvat automatische updates, waardoor handmatig onderhoud niet meer nodig is en ervoor zorgt dat PgBouncer up-to-date blijft met de nieuwste functies en beveiligingspatches.
• Ondersteuning voor openbare en privéverbindingen: De ingebouwde PgBouncer in uw Azure Database for PostgreSQL flexibele server biedt ondersteuning voor zowel openbare als persoonlijke verbindingen. Met deze ondersteuning kunt u beveiligde verbindingen tot stand brengen via privénetwerken of extern verbinding maken, afhankelijk van uw specifieke vereisten.
• Hoge beschikbaarheid (HA): In het geval van een failover, waarbij een stand-byserver wordt gepromoveerd tot de primaire rol, start PgBouncer naadloos opnieuw op de zojuist gepromoveerde stand-by zonder dat er wijzigingen nodig zijn voor de toepassing verbindingsreeks. Deze functie zorgt voor continue beschikbaarheid en minimaliseert onderbreking van de toepassing.
• Kostenefficiënt: Het is kostenefficiënt omdat u niet hoeft te betalen voor extra rekenkracht, zoals vm's of containers, hoewel het wel enige CPU-impact heeft omdat het een ander proces is dat op dezelfde computer wordt uitgevoerd.

Door gebruik te maken van de ingebouwde PgBouncer in een Azure Database for PostgreSQL flexibele server, kunt u genieten van het gemak van vereenvoudigde configuratie, de betrouwbaarheid van een beheerde service, ondersteuning voor verschillende poolmodi en naadloze hoge beschikbaarheid tijdens failoverscenario's.

Limitations:

• Niet ondersteund met Burstable:PgBouncer wordt momenteel niet ondersteund met de rekenlaag Burstable-server. Als u de rekenlaag wijzigt van de laag Algemeen gebruik of Geoptimaliseerd voor geheugen naar Burstable, verliest u de PgBouncer-mogelijkheid .
• Maak opnieuw verbinding nadat het opnieuw is opgestart: Wanneer de server opnieuw wordt opgestart tijdens schaalbewerkingen, ha-failover of opnieuw opstarten, wordt pgBouncer opnieuw opgestart samen met de virtuele servermachine. Daarom moeten bestaande verbindingen opnieuw tot stand worden gebracht.

In dit artikel worden verschillende manieren besproken om PgBouncer te implementeren. De volgende tabel bevat een overzicht van de implementatiemethode waarvoor u kiest:

Selectiecriteria	PgBouncer op App VM	PgBouncer op VM met BEHULP van ALB*	PgBouncer op AKS Sidecar	PgBouncer as a Service	PgBouncer ingebouwd in Azure Database voor PostgreSQL
Vereenvoudigd beheer
HA
In containers geplaatste apps
Minder netwerkoverhead en latentie
Fijnmazige controle over bewaking en foutopsporing

Legenda

Moeilijkheidsgraad	Symbool
Easy
Gemiddeld
Moeilijk

*ALB: Azure Load Balancer.

Verwante onderwerpen

• PgBouncer in Azure Database for PostgreSQL Flexible Server
• Verbindingsbibliotheken