{"id":92570,"date":"2020-08-28T19:42:21","date_gmt":"2020-08-28T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker"},"modified":"2020-08-28T19:42:21","modified_gmt":"2020-08-28T17:42:21","slug":"modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Het simuleren van fouttolerante clusters op basis van PostgreSQL en Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Inleiding<\/h1>\n

<\/p>\n

Een tijd geleden kreeg ik de taak om een failovercluster te ontwikkelen voor PostgreSQL<\/a><\/noindex>, opererend in meerdere datacenters die via glasvezel met elkaar zijn verbonden in \u00e9\u00e9n stad, en dat in staat is om de uitval (bijvoorbeeld een stroomuitval) van \u00e9\u00e9n datacenter te weerstaan. Als software die verantwoordelijk is voor de failover heb ik gekozen voor Pacemaker<\/a><\/noindex>, omdat dit de offici\u00eble oplossing van RedHat is voor het opzetten van failoverclusters. Het voordeel is dat RedHat ervoor zorgt dat het ondersteund wordt, en dat deze oplossing universeel (modulair) is. Hiermee kan niet alleen de failover voor PostgreSQL worden gegarandeerd, maar ook voor andere services, hetzij door gebruik te maken van standaardmodules, hetzij door speciaal modules te cre\u00ebren voor specifieke behoeften.<\/p>\n

<\/p>\n

Bij deze oplossing kwam een terechte vraag op: hoe failover-robust zal een failovercluster zijn? Om dit te onderzoeken, heb ik een testopstelling ontwikkeld die verschillende storingen op de clusterknopen simuleert, wacht op herstel, herstelt de uitgevallen knoop en gaat verder met de tests in een cyclus. Dit project heette oorspronkelijk hapgsql, maar na verloop van tijd begon de naam, waar slechts \u00e9\u00e9n klinker in staat, me te vervelen. Daarom ben ik de failoverdatabases (en het float IP dat naar hen verwijst) gaan noemen krogan<\/strong> (een personage uit een computer game, dat alle belangrijke organen gedupliceert heeft), en de knooppunten, clusters en het project zelf werden tuchanka<\/strong> (de planeet waar de kroganen wonen).<\/p>\n

<\/p>\n

Nu heeft het management toegestaan het project open te stellen voor de open source-gemeenschap onder de MIT-licentie<\/a><\/noindex>. De README wordt binnenkort in het Engels vertaald (omdat verwacht wordt dat de belangrijkste gebruikers ontwikkelaars van Pacemaker en PostgreSQL zullen zijn), en de oude Russische versie van de README heb ik besloten om (gedeeltelijk) in de vorm van dit artikel te presenteren.<\/p>\n

<\/p>\n

\"Het<\/p>\n

<\/a><\/noindex><\/p>\n

Clusters worden opgezet op virtuele machines VirtualBox<\/a><\/noindex>. In totaal worden er 12 virtuele machines uitgerold (in totaal 36GiB), die 4 failoverclusters vormen (verschillende varianten). De eerste twee clusters bestaan uit twee PostgreSQL-servers die zich in verschillende datacenters bevinden, en een gemeenschappelijke server witness<\/em> c quorum device<\/strong> (geplaatst op een goedkope virtuele machine in het derde datacenter), die de onduidelijkheid oplost 50%\/50%<\/strong>, door zijn stem aan \u00e9\u00e9n van de partijen te geven. Het derde cluster is verspreid over drie datacenters: \u00e9\u00e9n master, twee slaves, zonder quorum device<\/strong>. De vierde cluster bestaat uit vier PostgreSQL-servers, twee per datacenter: \u00e9\u00e9n primaire en de rest replica's, en maakt ook gebruik van witness<\/em> c quorum device<\/strong>. De vierde kan uitval van twee servers of \u00e9\u00e9n datacenter weerstaan. Deze oplossing kan indien nodig worden opgeschaald naar meer replica's.<\/p>\n

<\/p>\n

Tijdservice ntpd<\/a><\/noindex> is ook herconfigureerbaar voor fouttolerantie, maar er wordt gebruikgemaakt van de methode van ntpd<\/code> (orphan mode<\/em>). De algemene server witness<\/em> fungeert als centrale NTP-server, die zijn tijd aan alle clusters verstrekt, waardoor alle servers op elkaar worden gesynchroniseerd. Als witness<\/em> uitvalt of ge\u00efsoleerd raakt, begint een van de servers in de cluster zijn tijd te verstrekken (binnen de cluster). Een hulpk caching HTTP proxy<\/strong> is ook opgezet op witness<\/em>, waarmee de andere virtuele machines toegang hebben tot Yum-repositories. In werkelijkheid worden dergelijke services, zoals tijdservice en proxy, waarschijnlijk op speciale servers gehost, terwijl ze in de opstelling op witness<\/em> alleen voor het besparen van het aantal virtuele machines en ruimte.<\/p>\n

<\/p>\n

Versies<\/h1>\n

<\/p>\n

v0. Werkt met CentOS 7 en PostgreSQL 11 op VirtualBox 6.1.<\/p>\n

<\/p>\n

Clusterstructuur<\/h1>\n

<\/p>\n

Alle clusters zijn bedoeld om in verschillende datacenters te worden gehost, verbonden in een plat netwerk en moeten uitval of netwerkisolatie van \u00e9\u00e9n datacenter weerstaan. Daarom onmogelijk is<\/strong> wordt gebruikt om te beschermen tegen split-brain<\/strong> de standaardtechnologie Pacemaker, die STONITH<\/em> (Shoot The Other Node In The Head) of fencing<\/em>. De kern ervan is: als de knooppunten in de cluster gaan vermoeden dat er iets mis is met een bepaald knooppunt, dat niet reageert of zich onjuist gedraagt, dan schakelen ze het gedwongen uit via \u2018externe\u2019 apparaten, zoals de IPMI-beheerpunt of UPS. Maar dit werkt alleen in gevallen waarin bij een enkel falen van de server de IPMI of UPS blijft functioneren. Hier is ook bescherming gepland tegen een veel catastrofaler falen, wanneer een heel datacenter uitvalt (bijvoorbeeld geen stroom meer heeft). En bij een dergelijke storing zullen ook alle stonith<\/em>-apparaten (IPMI, UPS, enz.) niet meer werken.<\/p>\n

<\/p>\n

In plaats daarvan ligt de basis van het systeem in het idee van quorum. Alle knooppunten hebben een stem, en alleen degenen die meer dan de helft van alle knooppunten kunnen zien, kunnen functioneren. Dit aantal \u2018meer dan de helft + 1\u2019 wordt genoemd quorum<\/strong>. Als er geen quorum wordt bereikt, beslist het knooppunt dat het zich in netwerkisolatie bevindt en moet het zijn middelen uitschakelen, d.w.z. dit is zo'n bescherming tegen split-brain<\/strong>. Als de software die verantwoordelijk is voor dergelijk gedrag niet functioneert, moet de watchdog, bijvoorbeeld op basis van IPMI, worden geactiveerd.<\/p>\n

<\/p>\n

Als het aantal knooppunten even is (een cluster in twee datacenters), kan er een zogenaamde onduidelijkheid ontstaan 50%\/50%<\/strong> (vijftig-vijftig<\/em>), wanneer net isolatie het cluster precies doormidden splitst. Daarom wordt voor een even aantal knooppunten toegevoegd quorum device<\/strong> \u2014 een on-demand daemon die kan worden uitgevoerd op de goedkoopste virtuele machine in het derde datacenter. Het geeft zijn stem aan een van de segmenten (die het ziet) en lost zo de 50%\/50% onduidelijkheid op. De server waarop het quorum-device zal worden uitgevoerd, heb ik genoemd witness<\/em> (terminologie uit repmgr, ik vond het leuk).<\/p>\n

<\/p>\n

Hulpbronnen kunnen van plaats naar plaats verhuizen, bijvoorbeeld van defecte servers naar werkende of op verzoek van systeembeheerders. Om klanten te laten weten waar hun benodigde hulpbronnen zich bevinden (waar moet men verbinding mee maken?), worden gebruikt drijvende IP<\/em> (drijvend IP<\/strong>). Dit zijn IP's die Pacemaker over de knooppunten kan verplaatsen (alles bevindt zich in een plat netwerk). Iedere daarvan symboliseert een hulpbron (dienst) en zal zich bevinden waar verbinding mee moet worden gemaakt om toegang te krijgen tot deze dienst (in ons geval de DB).<\/p>\n

<\/p>\n

Tuchanka1 (schema met verdichting)<\/h2>\n

<\/p>\n

Structuur<\/h3>\n

<\/p>\n

\"Het<\/p>\n

<\/p>\n

Het idee was dat we veel kleine databases met een lage belasting hebben, waarvoor het niet rendabel is om een dedicated slave-server in hot standby modus te onderhouden voor read-only transacties (er is geen behoefte aan zo'n verspilling van middelen).<\/p>\n

<\/p>\n

In elk datacenter bevindt zich \u00e9\u00e9n server. Op elke server draaien twee instanties PostgreSQL (in de terminologie van PostgreSQL worden ze clusters genoemd, maar om verwarring te voorkomen zal ik ze instanties noemen, zoals met andere databases; clusters zal ik alleen gebruiken voor Pacemaker-clusters). E\u00e9n instantie werkt in de mastermodus en biedt alleen daar diensten aan (alleen op deze instantie wijst het float IP). De tweede instantie fungeert als slave voor het tweede datacenter en zal alleen diensten verlenen als zijn master uitvalt. Aangezien de meeste tijd slechts \u00e9\u00e9n van de twee instanties (de master) diensten aanbiedt (verzoeken uitvoert), worden alle serverresources geoptimaliseerd voor de master (zoals geheugen voor de cache shared_buffers, enz.), maar zodanig dat er ook genoeg resources zijn voor de tweede instantie (al is het voor minder optimale werking via de bestandssysteemcache) voor het geval van uitval van een van de datacenters. De slave biedt geen diensten aan (voert geen read-only verzoeken uit) tijdens de normale werking van het cluster, om oorlog om resources met de master op dezelfde machine te voorkomen.<\/p>\n

<\/p>\n

Bij twee knooppunten is failover alleen mogelijk bij asynchrone replicatie, want bij synchronisatie leidt de uitval van de slave tot de stopzetting van de master.<\/p>\n

<\/p>\n

Uitval getuige<\/h3>\n

<\/p>\n

\"Het<\/p>\n

<\/p>\n

Uitval getuige (quorum device<\/em>) zal ik alleen beschouwen voor het cluster Tuchanka1, het zal met alle andere hetzelfde verhaal zijn. Bij uitval van de getuige verandert er niets in de clusterstructuur, alles blijft werken zoals het werkte. Maar het quorum wordt 2 uit 3, en daarom zal elke volgende uitval fataal zijn voor de cluster. Het moet dringend worden gerepareerd.<\/p>\n

<\/p>\n

Uitval Tuchanka1<\/h3>\n

<\/p>\n

\"Het<\/p>\n

<\/p>\n

Uitval van een van de datacenters voor Tuchanka1. In dit geval witness<\/em> geeft zijn stem aan het tweede knooppunt in het tweede datacenter. Daar verandert de voormalige slave in de master, waardoor beide masters op \u00e9\u00e9n server draaien en beide hun float IP aanwijzen.<\/p>\n

<\/p>\n

Tuchanka2 (klassiek)<\/h2>\n

<\/p>\n

Structuur<\/h3>\n

<\/p>\n

\"Het<\/p>\n

<\/p>\n

Klassiek schema met twee knooppunten. Op de ene draait de master, op de andere de slave. Beide kunnen verzoeken uitvoeren (de slave alleen read-only), daarom wijzen beiden naar float IP: krogan2 \u2014 naar de master, krogan2s1 \u2014 naar de slave. Zowel de master als de slave zullen failover hebben.<\/p>\n

<\/p>\n

Bij twee knooppunten is failover alleen mogelijk bij asynchrone replicatie, want bij synchronisatie leidt de uitval van de slave tot de stopzetting van de master.<\/p>\n

<\/p>\n

Uitval Tuchanka2<\/h3>\n

<\/p>\n

\"Het<\/p>\n

<\/p>\n

Bij uitval van een van de datacenters witness<\/em> stemt voor de tweede. Op het enige werkende datacenter zal een master worden opgezet, en beide float IP's zullen naar deze master verwijzen: de master en de slave. Uiteraard moet de instantie zo worden ingesteld dat het voldoende middelen heeft (limieten voor verbindingen enz.) om gelijktijdig alle verbindingen en verzoeken van zowel de master als de slave float IP te verwerken. Dit betekent dat, onder normale omstandigheden, er voldoende limieten beschikbaar moeten zijn.<\/p>\n

<\/p>\n

Tuchanka4 (veel slaven)<\/h2>\n

<\/p>\n

Structuur<\/h3>\n

<\/p>\n

\"Het<\/p>\n

<\/p>\n

Alweer een andere extremiteit. Er zijn databases die veel read-only verzoeken ontvangen (een typisch geval van een zwaarbelaste site). Tuchanka4 is een situatie waarbij er drie of meer slaven kunnen zijn om deze verzoeken te verwerken, maar toch niet te veel. Bij een zeer groot aantal slaven moet er een hi\u00ebrarchisch replicatiesysteem worden uitgevonden. In het minimaalste geval (zoals op de afbeelding) zijn er in elk van de twee datacenters twee servers, elk met een PostgreSQL instantie.<\/p>\n

<\/p>\n

Een ander kenmerk van dit schema is dat hier al \u00e9\u00e9n synchrone replicatie kan worden georganiseerd. Deze is zo ingesteld dat het, indien mogelijk, naar een ander datacenter repliceert, en niet naar een replica in hetzelfde datacenter als de master. Zowel de master als elke slave verwijzen naar float IP. Idealiter moet er tussen slaven een verzoekbalancering worden gemaakt met een of andere sql proxy<\/em>, bijvoorbeeld aan de klantzijde. Verschillende soorten klanten kunnen verschillende soorten sql proxy<\/em>nodig hebben, en alleen de ontwikkelaars van de klanten weten wie wat nodig heeft. Deze functionaliteit kan worden ge\u00efmplementeerd door zowel een externe daemon als een clientbibliotheek (connection pool), enz. Dit valt echter buiten het onderwerp van een fouttolerante databasecluster (fouttolerantie SQL proxy<\/em> kan onafhankelijk worden ge\u00efmplementeerd, samen met de fouttolerantie van de client).<\/p>\n

<\/p>\n

Fout van Tuchanka4<\/h3>\n

<\/p>\n

\"Het<\/p>\n

<\/p>\n

Bij de storing van \u00e9\u00e9n datacenter (d.w.z. twee servers) stemt de getuige voor de tweede. Als gevolg hiervan zijn er in het tweede datacenter twee servers in werking: op de ene draait de master, en deze verwijst naar de master float IP (voor het ontvangen van read-write verzoeken); en op de tweede server draait een slave met synchrone replicatie, en deze verwijst naar een van de slave float IP's (voor read-only verzoeken).<\/p>\n

<\/p>\n

Het eerste dat opgemerkt moet worden: niet alle slave float IP's zullen actief zijn, maar slechts \u00e9\u00e9n. En voor een correcte werking daarmee moet ervoor gezorgd worden dat sql proxy<\/em> verzendde alle verzoeken naar het enige overgebleven float-IP; en als sql proxy<\/em> nee, dan kunnen alle float-IP's van de slaves door een komma in de URL voor verbinding worden opgesomd. In dat geval met libpq<\/em> de verbinding zal naar het eerste functionele IP gaan, zoals gedaan is in het automatiseringssysteem voor testen. Misschien werkt het niet met andere bibliotheken, zoals JDBC, en is dat nodig sql proxy<\/em>. Dit is gedaan omdat er voor de float-IP's van de slaves een verbod is ingesteld om tegelijkertijd op dezelfde server te draaien, zodat ze gelijkmatig over de slave-servers worden verspreid, als er meerdere in gebruik zijn.<\/p>\n

<\/p>\n

Ten tweede: zelfs in het geval van een storing in het datacenter blijft de synchronisatie-replicatie bestaan. En zelfs als er een secundaire storing optreedt, dat wil zeggen, als een van de twee servers in het overblijvende datacenter defect raakt, zal de cluster, hoewel hij geen diensten meer kan aanbieden, nog steeds informatie over alle toegewezen transacties behouden waarvoor hij een commit-bevestiging heeft gegeven (er zal geen verlies van informatie zijn bij een secundaire storing).<\/p>\n

<\/p>\n

Tuchanka3 (3 datacentra)<\/h2>\n

<\/p>\n

Structuur<\/h3>\n

<\/p>\n

\"Het<\/p>\n

<\/p>\n

Dit is een cluster voor situaties waarin er drie volledig functionele datacentra zijn, elk met een volledig functionele database-server. In dat geval quorum device<\/em> is niet nodig. In \u00e9\u00e9n datacenter draait de master, in de andere twee - slaves. De replicatie is synchronisch, type ANY (slave1, slave2), dat wil zeggen dat de client een commit-bevestiging ontvangt wanneer een van de slaves als eerste antwoordt dat hij de commit heeft geaccepteerd. Het aantal bronnen wordt aangeduid door \u00e9\u00e9n float-IP voor de master en twee voor de slaves. In tegenstelling tot Tuchanka4 zijn alle drie de float-IP's fouttolerant. Voor het balanceren van read-only SQL-verzoeken kan gebruik worden gemaakt van sql proxy<\/em> (met aparte fouttolerantie), of de helft van de clients een slave float-IP toewijzen en de andere helft de tweede.<\/p>\n

<\/p>\n

Fout Tuchanka3<\/h3>\n

<\/p>\n

\"Het<\/p>\n

<\/p>\n

Bij een storing in een van de datacentra blijven er twee over. In de ene draait de master en het float-IP van de master, in de andere de slave en beide slave float-IP's (de instantie moet een dubbele reserve aan middelen hebben om alle verbindingen van beide slave float-IP's te accepteren). Tussen de master en de slave is er synchronische replicatie. Bovendien behoudt de cluster de informatie over toegewezen en bevestigde transacties (er zal geen verlies van informatie zijn) in het geval van de vernietiging van twee datacentra (als ze niet tegelijkertijd worden vernietigd).<\/p>\n

<\/p>\n

Ik heb besloten om de gedetailleerde beschrijving van de bestandsstructuur en implementatie niet op te nemen. Wie wil experimenteren, kan dit alles lezen in README. Ik geef alleen de beschrijving van de geautomatiseerde testing.<\/em><\/p>\n

<\/p>\n

Geautomatiseerd testsysteem<\/h1>\n

<\/p>\n

Voor het testen van de fouttolerantie van clusters met simulaties van verschillende storingen is een geautomatiseerd testsysteem ontwikkeld. Het wordt gestart met een script. test\/failure<\/code>. Het script kan als parameters de nummers van de clusters accepteren die je wilt testen. Bijvoorbeeld, deze opdracht:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
zal alleen de tweede en derde cluster testen. Als er geen parameters zijn opgegeven, worden alle clusters getest. Alle clusters worden parallel getest, en het resultaat wordt weergegeven in het tmux-paneel. Tmux gebruikt een aparte tmux-server, dus het script kan worden uitgevoerd vanuit de standaard tmux, wat resulteert in geneste tmux. Ik raad aan een terminal te gebruiken in een groot venster met een klein lettertype. Voor het starten van de tests worden alle virtuele machines teruggezet naar hun snapshot op het moment dat het script wordt voltooid. setup<\/code>.<\/p>\n
<\/p>\n
\"Het<\/p>\n
<\/p>\n
De terminal is verdeeld in kolommen overeenkomend met het aantal te testen clusters, standaard (op de schermafbeelding) zijn dat er vier. De inhoud van de kolommen beschrijf ik aan de hand van Tuchanka2. De panelen op de schermafbeelding zijn genummerd:<\/p>\n
<\/p>\n
    \n
  1. Hier wordt statistiek over de tests weergegeven. Kolommen:\n