Introductie

Enige tijd geleden kreeg ik de opdracht om een ​​failover cluster voor te ontwikkelen PostgreSQL, opererend in verschillende datacenters die met glasvezel zijn verbonden binnen één stad, en in staat zijn een storing (bijvoorbeeld een black-out) van één datacenter te weerstaan. Als software die verantwoordelijk is voor fouttolerantie heb ik gekozen Pacemakeromdat dit de officiële oplossing van RedHat is voor het maken van failoverclusters. Het is goed omdat RedHat er ondersteuning voor biedt, en omdat deze oplossing universeel (modulair) is. Met zijn hulp zal het mogelijk zijn om fouttolerantie te garanderen, niet alleen van PostgreSQL, maar ook van andere diensten, door standaardmodules te gebruiken of deze voor specifieke behoeften te creëren.

Deze beslissing riep een redelijke vraag op: hoe fouttolerant zal een failovercluster zijn? Om dit te onderzoeken heb ik een testbank ontwikkeld die verschillende fouten op de clusterknooppunten simuleert, wacht tot de service is hersteld, het defecte knooppunt herstelt en in een lus doorgaat met testen. Dit project heette oorspronkelijk hapgsql, maar na verloop van tijd raakte ik verveeld door de naam, die maar één klinker had. Daarom begon ik fouttolerante databases aan te roepen (en zwevende IP-adressen naar hen te verwijzen) Krogan (een personage uit een computerspel waarin alle belangrijke organen worden gedupliceerd), en knooppunten, clusters en het project zelf Toechanka (de planeet waar de Krogans leven).

Nu heeft het management toestemming gegeven open het project voor de open source-gemeenschap onder de MIT-licentie. De README zal binnenkort in het Engels worden vertaald (omdat verwacht wordt dat de belangrijkste consumenten Pacemaker- en PostgreSQL-ontwikkelaars zullen zijn), en ik besloot de oude Russische versie van de README (gedeeltelijk) in de vorm van dit artikel te presenteren.

Clusters worden geïmplementeerd op virtuele machines VirtualBox. Er zullen in totaal 12 virtuele machines (36GiB in totaal) worden ingezet, die 4 fouttolerante clusters vormen (verschillende opties). De eerste twee clusters bestaan ​​uit twee PostgreSQL-servers, die zich in verschillende datacenters bevinden, en een gemeenschappelijke server Getuige c quorum-apparaat (gehost op een goedkope virtuele machine in een derde datacenter), wat onzekerheid wegneemt 50% / 50%, waarbij u uw stem geeft aan een van de partijen. Derde cluster in drie datacenters: één master, twee slaves, nee quorum-apparaat. Het vierde cluster bestaat uit vier PostgreSQL-servers, twee per datacenter: één master, de rest replica's en ook gebruikt Getuige c quorum-apparaat. De vierde is bestand tegen het uitvallen van twee servers of één datacenter. Deze oplossing kan indien nodig worden geschaald naar een groter aantal replica's.

Nauwkeurige tijdservice ntpd ook opnieuw geconfigureerd voor fouttolerantie, maar het gebruikt de methode zelf ntpd (weesmodus). Gedeelde server Getuige fungeert als een centrale NTP-server en verdeelt zijn tijd over alle clusters, waardoor alle servers met elkaar worden gesynchroniseerd. Als Getuige uitvalt of geïsoleerd raakt, zal een van de clusterservers (binnen het cluster) zijn tijd gaan verdelen. Extra caching HTTP-proxy ook verhoogd naar GetuigeMet zijn hulp hebben andere virtuele machines toegang tot Yum-repository's. In werkelijkheid zullen diensten zoals nauwkeurige tijd en proxy's hoogstwaarschijnlijk worden gehost op speciale servers, maar in de cabine worden ze gehost op Getuige alleen om het aantal virtuele machines en ruimte te besparen.

Versies

v0. Werkt met CentOS 7 en PostgreSQL 11 op VirtualBox 6.1.

Clusterstructuur

Alle clusters zijn ontworpen om zich in meerdere datacenters te bevinden, gecombineerd in één plat netwerk en moeten bestand zijn tegen storingen of netwerkisolatie van één datacenter. Daarom onmogelijk gebruiken ter bescherming tegen gespleten brein standaard Pacemaker-technologie genoemd STONITH (Schiet op het andere knooppunt in het hoofd) of schermen. De essentie ervan: als de knooppunten in het cluster beginnen te vermoeden dat er iets mis is met een bepaald knooppunt, het niet reageert of zich niet correct gedraagt, dan schakelen ze het met geweld uit via "externe" apparaten, bijvoorbeeld een IPMI- of UPS-controlekaart . Maar dit werkt alleen in gevallen waarin, in het geval van een enkele storing, de IPMI- of UPS-server blijft werken. Hier zijn we van plan bescherming te bieden tegen een veel catastrofalere storing, wanneer het hele datacenter uitvalt (bijvoorbeeld stroom uitvalt). En met zo'n weigering, alles steen-apparaten (IPMI, UPS, enz.) zullen ook niet werken.

In plaats daarvan is het systeem gebaseerd op het idee van quorum. Alle knooppunten hebben een stem, en alleen degenen die meer dan de helft van alle knooppunten kunnen zien, kunnen werken. Deze hoeveelheid van “half + 1” wordt genoemd quorum. Als het quorum niet wordt bereikt, besluit het knooppunt dat het zich in netwerkisolatie bevindt en zijn bronnen moet uitschakelen. dit is wat het is bescherming tegen gespleten hersenen. Als de software die verantwoordelijk is voor dit gedrag niet werkt, zal er bijvoorbeeld een waakhond op basis van IPMI aan de slag moeten.

Als het aantal knooppunten even is (een cluster in twee datacenters), kan er zogenaamde onzekerheid ontstaan 50% / 50% (half om half) wanneer netwerkisolatie het cluster precies in tweeën deelt. Daarom voegen we voor een even aantal knooppunten toe quorum-apparaat is een niet veeleisende daemon die kan worden gelanceerd op de goedkoopste virtuele machine in een derde datacenter. Hij geeft zijn stem aan een van de segmenten (die hij ziet) en lost daarmee de 50%/50% onzekerheid op. Ik heb de server genoemd waarop het quorumapparaat wordt gelanceerd Getuige (terminologie van repmgr, ik vond het leuk).

Bronnen kunnen van plaats naar plaats worden verplaatst, bijvoorbeeld van defecte servers naar gezonde servers, of op bevel van systeembeheerders. Zodat klanten weten waar de bronnen die ze nodig hebben zich bevinden (waar moeten ze verbinding maken?), zwevend IP-adres (zwevend IP-adres). Dit zijn IP's die Pacemaker rond knooppunten kan verplaatsen (alles bevindt zich op een plat netwerk). Elk van hen symboliseert een bron (dienst) en bevindt zich op de plaats waar u verbinding moet maken om toegang te krijgen tot deze dienst (in ons geval een database).

Tuchanka1 (circuit met verdichting)

Structuur

Het idee was dat we veel kleine databases hebben met een lage belasting, waarvoor het niet rendabel is om een ​​speciale slave-server in de standby-modus te houden voor alleen-lezen transacties (een dergelijke verspilling van middelen is niet nodig).

Elk datacenter heeft één server. Elke server heeft twee PostgreSQL-instanties (in PostgreSQL-terminologie worden ze clusters genoemd, maar om verwarring te voorkomen zal ik ze instanties noemen (naar analogie met andere databases), en ik zal alleen Pacemaker-clusters clusters noemen). Eén exemplaar werkt in de mastermodus en alleen deze levert services (alleen zwevende IP-adressen leiden ernaar). De tweede instantie werkt als slaaf voor het tweede datacenter en zal alleen diensten leveren als de master uitvalt. Omdat meestal slechts één op de twee instances (de master) diensten zal leveren (verzoeken uitvoeren), worden alle serverbronnen geoptimaliseerd voor de master (geheugen wordt toegewezen voor de shared_buffers cache, enz.), maar zodat de tweede instance heeft ook voldoende bronnen (zij het voor een suboptimale werking via de cache van het bestandssysteem) in geval van een storing in een van de datacentra. De slave levert geen services (voert geen alleen-lezen-verzoeken uit) tijdens de normale werking van het cluster, zodat er geen oorlog om bronnen ontstaat met de master op dezelfde machine.

In het geval van twee knooppunten is fouttolerantie alleen mogelijk bij asynchrone replicatie, aangezien bij synchrone replicatie het falen van een slaaf zal leiden tot het stoppen van de master.

Het niet getuigen

Het niet getuigen (quorum-apparaat) Ik zal alleen voor het Tuchanka1-cluster overwegen, met alle anderen zal het hetzelfde verhaal zijn. Als de getuige faalt, verandert er niets aan de clusterstructuur, alles blijft op dezelfde manier werken als voorheen. Maar het quorum zal 2 op 3 worden, en daarom zal elke daaropvolgende mislukking fataal zijn voor het cluster. Het zal nog dringend gerepareerd moeten worden.

Tuchanka1 weigering

Falen van een van de datacenters voor Tuchanka1. In dit geval Getuige brengt zijn stem uit op een tweede knooppunt in een tweede datacenter. Daar verandert de voormalige slaaf in een master, waardoor beide masters op dezelfde server werken en beide float-IP's naar hen verwijzen.

Tuchanka2 (klassiek)

Structuur

Klassiek schema van twee knooppunten. De master werkt aan de ene, de slave aan de tweede. Beide kunnen verzoeken uitvoeren (de slaaf is alleen-lezen), dus naar beide wordt verwezen door float IP: krogan2 is de master, krogan2s1 is de slaaf. Zowel de master als de slave hebben een fouttolerantie.

In het geval van twee knooppunten is fouttolerantie alleen mogelijk bij asynchrone replicatie, omdat bij synchrone replicatie het falen van de slave zal leiden tot het stoppen van de master.

Tuchanka2 weigering

Als een van de datacenters uitvalt Getuige stemmen voor de tweede. Op het enige werkende datacenter zal de master worden verhoogd en beide zwevende IP's zullen ernaar verwijzen: de master en de slave. Uiteraard moet de instantie zo worden geconfigureerd dat deze over voldoende middelen beschikt (verbindingslimieten, enz.) om tegelijkertijd alle verbindingen en verzoeken van het master- en slave-float-IP te accepteren. Dat wil zeggen dat het tijdens normaal gebruik voldoende limieten moet hebben.

Tuchanka4 (veel slaven)

Structuur

Alweer een extreem. Er zijn databases die veel alleen-lezen-verzoeken ontvangen (een typisch geval van een site met hoge belasting). Tuchanka4 is een situatie waarin er drie of meer slaven kunnen zijn om dergelijke verzoeken af ​​te handelen, maar nog steeds niet te veel. Bij een zeer groot aantal slaven zal het nodig zijn een hiërarchisch replicatiesysteem uit te vinden. In het minimale geval (in de afbeelding) beschikt elk van de twee datacenters over twee servers, elk met een PostgreSQL-instantie.

Een ander kenmerk van dit schema is dat het al mogelijk is om één synchrone replicatie te organiseren. Het is geconfigureerd om, indien mogelijk, te repliceren naar een ander datacenter, in plaats van naar een replica in hetzelfde datacenter als de master. Er wordt naar de master en elke slave verwezen via een float IP. Gelukkig zal het tussen slaven nodig zijn om op de een of andere manier verzoeken in evenwicht te brengen sql-proxybijvoorbeeld aan de klantzijde. Verschillende soorten klanten kunnen verschillende typen nodig hebben sql-proxy, en alleen clientontwikkelaars weten wie wat nodig heeft. Deze functionaliteit kan worden geïmplementeerd door een externe daemon of door een clientbibliotheek (verbindingspool), enz. Dit alles gaat verder dan het onderwerp van een failover-databasecluster (failover SQL-proxy kan onafhankelijk worden geïmplementeerd, samen met klantfouttolerantie).

Tuchanka4 weigering

Als één datacenter (dat wil zeggen twee servers) uitvalt, stemt de getuige voor het tweede. Als gevolg hiervan draaien er twee servers in het tweede datacenter: de ene draait een master, en de master float IP verwijst ernaar (voor het ontvangen van lees-schrijfverzoeken); en op de tweede server draait een slaaf met synchrone replicatie, en een van de slave-float-IP's verwijst ernaar (voor alleen-lezen-verzoeken).

Het eerste om op te merken is dat niet alle slave float IP’s werkers zullen zijn, maar slechts één. En om er correct mee te kunnen werken, is dat nodig sql-proxy alle verzoeken omgeleid naar het enige overgebleven float-IP; en als sql-proxy nee, dan kunt u alle zwevende IP-slaves vermelden, gescheiden door komma's in de verbindings-URL. In dit geval met libpq de verbinding zal plaatsvinden met het eerste werkende IP, dit gebeurt in het automatische testsysteem. Misschien werkt dit in andere bibliotheken, bijvoorbeeld JDBC, niet en is het noodzakelijk sql-proxy. Dit wordt gedaan omdat het verboden is om float IP's voor slaves tegelijkertijd op één server te verhogen, zodat ze gelijkmatig over de slaveservers worden verdeeld als er meerdere actief zijn.

Ten tweede: zelfs in het geval van een datacenterstoring blijft de synchrone replicatie behouden. En zelfs als er zich een secundaire storing voordoet, dat wil zeggen dat een van de twee servers in het resterende datacenter uitvalt, zal het cluster, hoewel het stopt met het leveren van diensten, nog steeds informatie bewaren over alle vastgelegde transacties waarvoor het een bevestiging van de vastlegging heeft gegeven. (er zal geen verliesinformatie zijn in geval van een secundaire storing).

Tuchanka3 (3 datacenters)

Structuur

Dit is een cluster voor een situatie waarin er drie volledig functionerende datacenters zijn, die elk een volledig functionerende databaseserver hebben. In dit geval quorum-apparaat niet nodig. Eén datacenter wordt bemand door een master, de andere twee worden bemand door slaves. Replicatie is synchroon, type ANY (slave1, slave2), dat wil zeggen dat de client een commitbevestiging ontvangt wanneer een van de slaves als eerste antwoordt dat hij de commit heeft geaccepteerd. Bronnen worden aangegeven met één zwevend IP-adres voor de master en twee voor slaves. In tegenstelling tot Tuchanka4 zijn alle drie de float-IP's fouttolerant. Om alleen-lezen SQL-query's in evenwicht te brengen, kunt u deze gebruiken sql-proxy (met afzonderlijke fouttolerantie), of wijs één slave float IP toe aan de helft van de clients en de andere helft aan de tweede.

Tuchanka3 weigering

Als een van de datacenters uitvalt, blijven er twee over. In de ene worden de master en float IP van de master verhoogd, in de tweede - de slave en beide slave float IP's (de instantie moet een dubbele reserve aan bronnen hebben om alle verbindingen van beide slave float IP's te accepteren). Synchrone replicatie tussen masters en slaves. Ook zal het cluster informatie opslaan over vastgelegde en bevestigde transacties (er zal geen informatie verloren gaan) in het geval van de vernietiging van twee datacenters (als deze niet tegelijkertijd worden vernietigd).

Ik heb besloten geen gedetailleerde beschrijving van de bestandsstructuur en de implementatie op te nemen. Iedereen die wil spelen, kan het allemaal lezen in de README. Ik geef alleen een beschrijving van geautomatiseerd testen.

Automatisch testsysteem

Om de fouttolerantie van clusters te testen door verschillende fouten te simuleren, is een automatisch testsysteem gecreëerd. Gelanceerd via script test/failure. Het script kan als parameters het aantal clusters gebruiken dat u wilt testen. Bijvoorbeeld dit commando:

test/failure 2 3

zal alleen het 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 speciale tmux-server, zodat het script kan worden uitgevoerd onder de standaard tmux, wat resulteert in een geneste tmux. Ik raad aan om de terminal in een groot venster en met een klein lettertype te gebruiken. Voordat het testen begint, worden alle virtuele machines teruggedraaid naar een momentopname op het moment dat het script is voltooid setup.

De terminal is verdeeld in kolommen op basis van het aantal clusters dat wordt getest; standaard (in de schermafbeelding) zijn er vier. Ik zal de inhoud van de kolommen beschrijven aan de hand van het voorbeeld van Tuchanka2. De panelen in de schermafbeelding zijn genummerd:

1. Hier worden teststatistieken weergegeven. Kolommen:
   • storing — de naam van de test (functie in het script) die de fout emuleert.
   • reactie — rekenkundig gemiddelde tijd in seconden gedurende welke het cluster zijn functionaliteit herstelde. Het wordt gemeten vanaf het begin van het script dat een fout emuleert tot het moment waarop het cluster zijn functionaliteit herstelt en diensten kan blijven leveren. Als de tijd erg kort is, bijvoorbeeld zes seconden (dit gebeurt in clusters met meerdere slaves (Tuchanka3 en Tuchanka4)), betekent dit dat de fout bij de asynchrone slave lag en de prestaties op geen enkele manier beïnvloedde; er waren geen clusterstatusschakelaars.
   • afwijking — toont de spreiding (nauwkeurigheid) van de waarde reactie met behulp van de standaarddeviatiemethode.
   • tellen — hoe vaak deze test is uitgevoerd.
2. Met een kort logboek kunt u evalueren wat het cluster momenteel doet. Het iteratienummer (testnummer), de tijdstempel en de naam van de bewerking worden weergegeven. Te lang hardlopen (> 5 minuten) duidt op een probleem.
3. hart- (hart) - huidige tijd. Voor visuele beoordeling van prestaties meester De huidige tijd wordt voortdurend naar de tabel geschreven met behulp van de float IP-master. Indien succesvol, wordt het resultaat in dit paneel weergegeven.
4. overtreffen (puls) - "huidige tijd", die eerder door het script was opgenomen hart- onder de knie krijgen, lees nu voor slaaf via zijn float IP. Hiermee kunt u de prestaties van de slave en replicatie visueel beoordelen. In Tuchanka1 zijn er geen slaven met float IP (geen slaven die diensten verlenen), maar er zijn twee instanties (DB's), dus deze wordt hier niet weergegeven overtreffenEn hart- tweede exemplaar.
5. Bewaken van de clusterstatus met behulp van het hulpprogramma pcs mon. Toont de structuur, verdeling van bronnen over knooppunten en andere nuttige informatie.
6. Systeemmonitoring van elke virtuele machine in het cluster wordt hier weergegeven. Er kunnen meer van dergelijke panelen zijn, afhankelijk van het aantal virtuele machines dat het cluster heeft. Twee grafieken CPU-belasting (virtuele machines hebben twee processors), naam van de virtuele machine, Systeembelasting (genaamd Load Average omdat het gemiddeld wordt over 5, 10 en 15 minuten), procesgegevens en geheugentoewijzing.
7. Tracering van het script dat tests uitvoert. In het geval van een storing – een plotselinge bedrijfsonderbreking of een eindeloze wachtcyclus – kunt u hier de reden voor dit gedrag zien.

Het testen wordt in twee fasen uitgevoerd. Eerst doorloopt het script alle soorten tests, waarbij willekeurig een virtuele machine wordt geselecteerd waarop deze test moet worden toegepast. Vervolgens wordt een eindeloze testcyclus uitgevoerd, waarbij de virtuele machines en de fout elke keer willekeurig worden geselecteerd. Plotselinge beëindiging van het testscript (onderste paneel) of een eindeloze lus van wachten op iets (> 5 minuten uitvoeringstijd voor één bewerking, dit is te zien in de trace) geeft aan dat sommige tests op dit cluster zijn mislukt.

Elke test bestaat uit de volgende handelingen:

1. Start een functie die een fout emuleert.
2. Klaar? — wachten tot het cluster is hersteld (wanneer alle services zijn geleverd).
3. Toont de time-out voor clusterherstel (reactie).
4. Bepalen — het cluster wordt ‘gerepareerd’. Daarna zou het terug moeten keren naar een volledig operationele staat en klaar zijn voor de volgende storing.

Hier is een lijst met tests met een beschrijving van wat ze doen:

• VorkBom: Creëert "Onvoldoende geheugen" met behulp van een vorkbom.
• Geen ruimte meer: De harde schijf is vol. Maar de test is nogal symbolisch; met de onbeduidende belasting die tijdens het testen ontstaat, faalt PostgreSQL meestal niet als de harde schijf vol is.
• Postgres-KILL: doodt PostgreSQL met het commando killall -KILL postgres.
• Postgres-STOP: loopt de PostgreSQL-opdracht vast killall -STOP postgres.
• Uitschakelen: “schakelt de virtuele machine uit” met het commando VBoxManage controlvm "виртуалка" poweroff.
• Reset: overbelast de virtuele machine met de opdracht VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: schort de SBD-demon op met het commando killall -STOP sbd.
• Afsluiten: stuurt een commando naar de virtuele machine via SSH systemctl poweroff, wordt het systeem netjes afgesloten.
• unlink: netwerkisolatie, opdracht VBoxManage controlvm "виртуалка" setlinkstate1 off.

Het testen voltooien met behulp van het standaard tmux-commando "kill-window" Ctrl-b &, of de opdracht "detach-client". Ctrl-bd: op dit punt eindigt het testen, wordt tmux gesloten en worden virtuele machines uitgeschakeld.

Problemen die tijdens het testen zijn vastgesteld

• Op dit moment waakhond demon sbd werkt aan het stoppen van waargenomen daemons, maar bevriest ze niet. En als gevolg daarvan fouten die alleen tot bevriezing leiden Corosync и Pacemaker, maar niet hangend SBD. Ter controle Corosync heeft al PR # 83 (op GitHub op SBD), geaccepteerd voor de draad meester. Ze beloofden (in PR#83) dat er iets soortgelijks zou komen voor Pacemaker, ik hoop dat dat zo blijft Rode Hoed 8 zal ik doen. Maar dergelijke “storingen” zijn speculatief en kunnen eenvoudig kunstmatig worden gesimuleerd met behulp van bijvoorbeeld killall -STOP corosync, maar ontmoet elkaar nooit in het echt.

• У Pacemaker in de versie voor 7 CentOS verkeerd ingesteld synchronisatietime-out у quorum-apparaat, als gevolg als één knooppunt uitviel, werd met enige waarschijnlijkheid ook het tweede knooppunt opnieuw opgestart, waarnaar de meester zou verhuizen. Genezen door uitbreiding synchronisatietime-out у quorum-apparaat tijdens de implementatie (in script setup/setup1). Dit amendement werd niet aanvaard door de ontwikkelaars Pacemaker, in plaats daarvan beloofden ze de infrastructuur zo te herontwerpen (in een niet nader gespecificeerde toekomst) dat deze time-out automatisch zou worden berekend.

• Als de databaseconfiguratie dat specificeert LC_MESSAGES (tekstberichten) Unicode kan worden gebruikt, b.v. ru_RU.UTF-8en vervolgens bij het opstarten postgres in een omgeving waar de landinstelling niet UTF-8 is, bijvoorbeeld in een lege omgeving (hier gangmaker+pgsqlms(paf) loopt postgres) dan het logboek bevat vraagtekens in plaats van UTF-8-letters. De PostgreSQL-ontwikkelaars zijn het er niet over eens wat ze in dit geval moeten doen. Het kost, je moet installeren LC_MESSAGES=en_US.UTF-8 bij het configureren (maken) van een database-instantie.

• Als wal_receiver_timeout is ingesteld (standaard is dit 60s), dan tijdens de PostgreSQL-STOP-test op de master in de tuchanka3- en tuchanka4-clusters replicatie maakt geen verbinding met de nieuwe master. De replicatie is daar synchroon, dus niet alleen de slave stopt, maar ook de nieuwe master. Werkt omzeild door wal_receiver_timeout=0 in te stellen bij het configureren van PostgreSQL.

• Af en toe merkte ik dat de replicatie vastliep in PostgreSQL tijdens de ForkBomb-test (geheugenoverloop). Na ForkBomb kunnen slaven soms niet opnieuw verbinding maken met de nieuwe master. Ik ben dit alleen tegengekomen in de clusters tuchanka3 en tuchanka4, waar de master vastliep vanwege synchrone replicatie. Het probleem verdween na een lange tijd (ongeveer twee uur) vanzelf. Om dit te corrigeren is meer onderzoek nodig. De symptomen zijn vergelijkbaar met de vorige bug, die om een ​​andere reden wordt veroorzaakt, maar met dezelfde gevolgen.

Krogan-foto genomen van deviant Art met toestemming van de auteur:

Bron: www.habr.com