Strategie voor groepsgewijze verbindingen voor Azure Database for PostgreSQL - Flexible Server met behulp van PgBouncer

Artikel
08/15/2024

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

Strategische richtlijnen voor het selecteren van het mechanisme voor groepsgewijze verbindingen voor Flexibele Azure Database for PostgreSQL-server.

Inleiding

Wanneer u een flexibele Azure Database for PostgreSQL-server gebruikt, moet u een verbinding met de database tot stand brengen door een communicatiekanaal te maken tussen de clienttoepassing en de server. Dit kanaal is verantwoordelijk voor het beheren van gegevens, het uitvoeren van query's en het initiëren van transacties. Zodra de verbinding tot stand is 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 essentiële toepassingen. Telkens wanneer er een nieuwe verbinding wordt gemaakt, maakt Azure Database for PostgreSQL flexibele server een nieuw proces met behulp van het postmaster-proces, dat meer resources verbruikt.

Om dit probleem op te lossen, wordt groepsgewijze verbinding gebruikt om een cache met verbindingen te maken die opnieuw kunnen worden gebruikt in azure Database for PostgreSQL flexibele server. Wanneer een toepassing of client een verbinding aanvraagt, wordt deze gemaakt vanuit de verbindingsgroep. Nadat de sessie of transactie is voltooid, wordt de verbinding geretourneerd naar de pool voor hergebruik. Door verbindingen opnieuw te gebruiken, wordt het gebruik van resources verminderd en worden de prestaties verbeterd.

Diagram voor verbindingspoolpatronen.

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

Wat is PgBouncer?

PgBouncer is een efficiënte verbindingspooler die is ontworpen voor PostgreSQL en biedt het voordeel van het verminderen van de verwerkingstijd en het optimaliseren van resourcegebruik bij het beheren van meerdere clientverbindingen met een of meer databases. PgBouncer bevat drie verschillende poolmodus voor verbindingsrotatie:

Groepsgewijze sessies: met deze methode wordt een serververbinding toegewezen aan de clienttoepassing voor de volledige duur van de verbinding van de client. Bij het verbreken van de verbinding van de clienttoepassing retourneert PgBouncer de serververbinding onmiddellijk terug naar de pool. Het mechanisme voor groepsgewijze sessies is de standaardmodus in Open Source PgBouncer. PgBouncer-configuratie bekijken
Transactiepooling: Bij transactiepooling is een serververbinding toegewezen aan de clienttoepassing tijdens een transactie. Zodra de transactie is voltooid, brengt PgBouncer op intelligente wijze de serververbinding vrij, waardoor deze weer 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 onmiddellijk geretourneerd naar de verbindingsgroep. Het is belangrijk te weten dat transacties met meerdere instructies niet worden ondersteund in deze modus.

Het effectieve gebruik van PgBouncer kan worden gecategoriseerd in drie verschillende gebruikspatronen.

PgBouncer- en Application Colocation-implementatie
Toepassingsonafhankelijke gecentraliseerde PgBouncer-implementaties
Ingebouwde pgBouncer- en database-implementatie

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

1. PgBouncer en colocatie-implementatie van toepassingen

Bij het gebruik van deze methode wordt PgBouncer geïmplementeerd op dezelfde server waarop uw toepassing wordt gehost. De toepassing & PgBouncer kan worden geïmplementeerd op traditionele virtuele machines of binnen een architectuur op basis van microservices, zoals gemarkeerd:

i. PgBouncer geïmplementeerd in application VM

Als uw toepassing wordt uitgevoerd op een Virtuele Azure-machine, kunt u PgBouncer instellen op dezelfde VIRTUELE machine. Volg de instructies in de volgende koppeling om PgBouncer te installeren en te configureren als een proxy voor groepsgewijze verbindingen met Azure Database for PostgreSQL flexibele server.

Diagram voor co-locatie van app op vm.

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 te implementeren op dezelfde toepassings-VM, is de communicatie tussen de primaire toepassing en de verbindingspooler efficiënt vanwege de nabijheid ervan. Het implementeren van PgBouncer in application VM minimaliseert de 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.

Beperkingen:

Single point of failure: Als PgBouncer wordt geïmplementeerd als één exemplaar op de toepassingsserver, 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. Als u Single Point of Failure wilt beperken, kunt u meerdere PgBouncer-exemplaren instellen achter een load balancer voor hoge beschikbaarheid.
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.

Het is belangrijk om deze beperkingen af te wegen tegen de voordelen en te evalueren of PgBouncer de juiste keuze is voor uw specifieke toepassing en database-installatie.

II. PgBouncer geïmplementeerd als een AKS-sidecar

Het is mogelijk om PgBouncer als sidecar-container te 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 haalt zijn inspiratie op uit het concept van een sidecar die is gekoppeld aan een motorfiets, waarbij een hulpcontainer, ook wel de sidecarcontainer genoemd, is gekoppeld aan een bovenliggende toepassing. Dit patroon verrijkt de bovenliggende toepassing door de functionaliteiten uit te breiden en aanvullende ondersteuning te bieden.

Het sidecar-patroon wordt meestal gebruikt met containers die worden gecopland als een atomische containergroep. 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 werkt samen met de toepassingscontainer binnen dezelfde pod in Azure Kubernetes Service (AKS) met 1:1-toewijzing, die fungeert als een verbindingspoolproxy voor flexibele Azure Database for PostgreSQL-server.

Dit sidecar-patroon wordt meestal gebruikt met containers die worden gecopland als een atomische containergroep. Sidecar-patroon verbindt de levenscyclus van de toepassing en sidecar sterk en heeft gedeelde resources zoals hostnaam en netwerken. Door deze installatie te gebruiken, optimaliseert PgBouncer het verbindingsbeheer en vereenvoudigt de efficiënte communicatie tussen de toepassing en het flexibele serverexemplaren van Azure Database for PostgreSQL.

Microsoft heeft een PgBouncer sidecar proxy-installatiekopieën gepubliceerd in het Microsoft-containerregister.

Raadpleeg dit voor meer informatie.

Diagram voor co-locatie van app in Sidecar.

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, waardoor eenvoudiger beheer en naadloze coördinatie mogelijk is.
Hoge beschikbaarheid en verbindingstolerantie: als een toepassingscontainer is mislukt of opnieuw wordt opgestart, volgt de PgBouncer-sidecarcontainer nauw en zorgt u voor hoge beschikbaarheid. 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.

Beperkingen:

Prestatieproblemen met verbindingen: 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, kan dit leiden tot prestatieproblemen, zoals verhoogde reactietijden of zelfs serviceonderbrekingen.
Complexe implementatie: Het gebruik van het sidecar-patroon introduceert een complexiteitsniveau voor het implementatieproces, omdat er twee containers binnen dezelfde pod moeten worden uitgevoerd. Dit kan het oplossen van problemen en foutopsporingsactiviteiten bemoeilijken, waardoor er extra moeite nodig is om problemen te identificeren en op te lossen.
Uitdagingen bij schalen: het is belangrijk te weten dat het sidecar-patroon mogelijk niet de ideale keuze is voor toepassingen die een hoge schaalbaarheid vereisen. Het opnemen van een sidecar-container kan meer resourcevereisten opleggen, waardoor het aantal pods dat effectief kan worden gemaakt en beheerd, wordt beperkt.

Hoewel u rekening houdt met dit sidecar-patroon, is het van cruciaal belang om de afwegingen tussen implementatiecomplexiteit en schaalbaarheidsvereisten zorgvuldig te beoordelen om de meest geschikte benadering voor uw specifieke toepassingsscenario te bepalen.

2. Toepassingsonafhankelijk - Gecentraliseerde PgBouncer-implementatie

Bij het gebruik van deze benadering wordt PgBouncer geïmplementeerd als een gecentraliseerde service, onafhankelijk van de toepassing. De PgBouncer-service kan worden geïmplementeerd op traditionele virtuele machines of binnen een architectuur op basis van microservices, zoals gemarkeerd:

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

PgBouncer-verbindingsproxy wordt ingesteld tussen de toepassings- en databaselaag achter een Azure Load Balancer, zoals wordt weergegeven in de afbeelding. In dit patroon worden meerdere PgBouncer-exemplaren achter een load balancer als een service geïmplementeerd om single point of failure 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.

Raadpleeg de koppeling voor het installeren en instellen van pgBouncer-verbindingspoolingsproxy met flexibele Azure Database for PostgreSQL-server.

Diagram voor co-locatie van app op vm met Load Balancer.

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

Voordelen:

Single Point of Failure verwijderen: Toepassingsconnectiviteit wordt mogelijk niet beïnvloed door de fout van één PgBouncer-VM, omdat er verschillende PgBouncer-exemplaren achter Azure Load Balancer zijn.
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. door de PgBouncer in vm te implementeren, zorgt u 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 te implementeren op een virtuele machine, kunt u voorkomen dat serverparameters op azure Database for PostgreSQL flexibele server worden gewijzigd. Dit is handig als u PgBouncer wilt configureren op een flexibele serverinstantie van Azure Database for PostgreSQL. Als u bijvoorbeeld de parameter SSLMODE wijzigt in 'vereist' op een flexibele Azure Database for PostgreSQL-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.

Beperkingen:

Beheeroverhead: Aangezien PgBouncer is geïnstalleerd in de VIRTUELE machine, kan er beheeroverhead zijn om meerdere configuratiebestanden te beheren. Dit maakt het moeilijk om versie-upgrades, nieuwe releases en productupdates aan te kunnen.
Functiepariteit: Als u migreert van traditionele PostgreSQL naar azure Database for PostgreSQL flexibele server en pgBouncer gebruikt, zijn er mogelijk enkele hiaten in functies. Bijvoorbeeld, gebrek aan md5-ondersteuning in Azure Database for PostgreSQL flexibele server.

II. Gecentraliseerde PgBouncer geïmplementeerd als een service in AKS

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

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

PgBouncer sidecar proxy image gepubliceerd in Microsoft container registry kan worden gebruikt voor het maken en implementeren van een service.

Diagram voor PgBouncer as a service binnen AKS.

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

Voordelen:

Verbeterde betrouwbaarheid: Door PgBouncer als zelfstandige service te implementeren, kan configuratie op een maximaal beschikbare manier worden uitgevoerd. Dit verbetert de algehele betrouwbaarheid van de verbindingspoolinfrastructuur, waardoor continue beschikbaarheid mogelijk is, zelfs als er storingen of storingen optreden.
Optimaal resourcegebruik: als uw toepassing of de databaseserver beperkte resources heeft, kunt u kiezen voor een afzonderlijke computer die is toegewezen aan het uitvoeren van de PgBouncer-service . Door PgBouncer te implementeren op een machine met voldoende resources, kunt u optimale prestaties garanderen en conflicten met resources voorkomen.
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.

Beperkingen:

Verhoogde N/W-latentie: bij het implementeren van PgBouncer als zelfstandige service is het belangrijk om rekening te houden met de mogelijke introductie van meer latentie. Dit komt doordat verbindingen tussen de toepassing en de PgBouncer-service via het netwerk moeten worden doorgegeven. Het is van cruciaal belang om de latentievereisten van uw toepassing te evalueren en rekening te houden met de afwegingen tussen gecentraliseerd verbindingsbeheer en potentiële latentieproblemen.

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

3. Ingebouwde PgBouncer in Azure Database for PostgreSQL flexibele server

Azure Database for PostgreSQL flexibele server biedt PgBouncer als een ingebouwde oplossing voor groepsgewijze verbindingen. Dit wordt aangeboden als een optionele service die per databaseserver kan worden ingeschakeld. PgBouncer wordt uitgevoerd op dezelfde virtuele machine als het flexibele serverexemplaren van Azure Database for PostgreSQL. Naarmate het aantal verbindingen groter wordt dan enkele honderden of duizend, kan de flexibele Server van 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.

Raadpleeg de koppeling voor het inschakelen en instellen van PgBouncer-verbindingspooling in Azure Database for PostgreSQL flexibele server.

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

Voordelen:

Naadloze configuratie: Met de ingebouwde PgBouncer in Azure Database for PostgreSQL flexibele server is er geen afzonderlijke installatie of complexe installatie nodig. Het kan eenvoudig rechtstreeks vanuit de serverparameters worden geconfigureerd, zodat u probleemloos kunt werken.
Managed Service Convenience: Als beheerde service kunnen gebruikers profiteren van de voordelen van andere door Azure beheerde services. Dit 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 Azure Database for PostgreSQL flexibele server biedt ondersteuning voor zowel openbare als privéverbindingen. Hierdoor kunnen gebruikers beveiligde verbindingen tot stand brengen via particuliere netwerken of extern verbinding maken, afhankelijk van hun 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. Dit zorgt voor continue beschikbaarheid en minimaliseert onderbreking van de toepassing.
Kostenefficiënt: het is kostenefficiënt omdat de gebruikers niet hoeven 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.

Met ingebouwde PgBouncer in azure Database for PostgreSQL flexibele server kunnen gebruikers profiteren van het gemak van vereenvoudigde configuratie, de betrouwbaarheid van een beheerde service, ondersteuning voor verschillende poolmodi en naadloze hoge beschikbaarheid tijdens failoverscenario's.

Beperkingen:

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 .
Verbindingen opnieuw tot stand brengen na opnieuw opstarten: wanneer de server opnieuw wordt opgestart tijdens schaalbewerkingen, ha-failover of opnieuw opstarten, wordt de PgBouncer ook opnieuw opgestart, samen met de virtuele servermachine. Daarom moeten bestaande verbindingen opnieuw tot stand worden gebracht.

We hebben verschillende manieren besproken om PgBouncer te implementeren en de tabel bevat een overzicht van de implementatiemethode waarvoor u kiest: