Twee knooppunt cluster - de duivel zit in de details

Hallo, Habr! Ik presenteer u de vertaling van het artikel ‘Twee Knopen - De Duivel Zit in de Details’ van Andrew Beekhof.

Veel mensen geven de voorkeur aan clusters met twee knooppunten, omdat ze conceptueel eenvoudiger lijken en bovendien 33% goedkoper zijn dan hun drie-knopige tegenhangers. Hoewel het heel goed mogelijk is om een goed cluster met twee knooppunten samen te stellen, zal deze configuratie in veel gevallen door onvoorziene scenario's een aantal niet voor de hand liggende problemen creëren.

De eerste stap bij het creëren van elk systeem met hoge beschikbaarheid is het identificeren en proberen te elimineren van enkele punten van falen, vaak afgekort tot SPoF (single point of failure).

Het is belangrijk om in gedachten te houden dat het in elk systeem onmogelijk is om alle mogelijke stilstandrisico's te elimineren. Dit komt onder andere doordat de typische bescherming tegen risico's het invoeren van wat redundantie vereist, wat leidt tot een toegenomen complexiteit van het systeem en nieuwe punten van falen creëert. Daarom gaan we aanvankelijk een compromis aan en richten we ons op gebeurtenissen die verband houden met enkelvoudige punten van falen, in plaats van op ketens van gerelateerde en dus steeds minder waarschijnlijke gebeurtenissen.

Gezien de compromissen zoeken we niet alleen naar SPoF, maar wegen we ook de risico's en gevolgen af, waardoor de conclusie dat wat kritisch is, kan verschillen per implementatie.

Niet iedereen heeft alternatieve stroomaanbieders met onafhankelijke elektriciteitslijnen nodig. Hoewel paranoia ten minste voor één klant heeft betaald toen hun monitoring een defecte transformator ontdekte. De klant belde achtereenvolgens, in een poging de energieleverancier te waarschuwen, totdat de defecte transformator ontplofte.

Een natuurlijke startpunt is om meer dan één knooppunt in het systeem te hebben. Echter, voordat het systeem diensten kan verplaatsen naar het overgebleven knooppunt na een storing, moet in het algemeen worden verzekerd dat de te verplaatsen diensten niet ergens anders actief zijn.

Een twee-knooppuntcluster heeft geen nadelen als beide knooppunten als gevolg van een storing dezelfde statische website bedienen. Maar alles verandert als beide partijen onafhankelijk toegang hebben tot een gezamenlijke wachtrij van taken of ongecoördineerde schrijfrechten tot een gerepliceerde database of gedeeld bestandssysteem.

Daarom, om te voorkomen dat gegevens beschadigd raken als gevolg van een storing van één knooppunt, vertrouwen we op wat we noemen «afscherming» (fencing).

Het principe van afscherming

Het principe van afscherming draait om de vraag: kan een concurrerend knooppunt gegevens beschadigen? Als gegevensbeschadiging een waarschijnlijke scenario is, is isolatie van het knooppunt van zowel binnenkomende verzoeken als van permanente opslag een goede oplossing. De meest voorkomende benadering voor afscherming is het uitschakelen van defecte knooppunten.

Er zijn twee categorieën afschermingsmethoden die ik zal noemen directe en indirecte, maar ze kunnen evenzeer actief worden genoemd. passief. en Directe methoden omvatten acties van de overlevende gelijke knooppunten, zoals interactie met een IPMI-apparaat (Intelligent Platform Management Interface — interface voor afstandsmonitoring en beheer van de fysieke toestand van de server) of iLO (serverbeheermechanisme zonder fysiek toegang), terwijl indirecte methoden afhankelijk zijn van het defecte knooppunt om op de een of andere manier te herkennen dat het zich in een ongezonde toestand bevindt (of op zijn minst andere leden belemmert om te herstellen) en signalerenhardware watchdog de noodzaak om het defecte knooppunt uit te schakelen. Kwartet helpt bij het gebruik van zowel directe als indirecte methoden.

Directe afscherming

Bij directe afscherming kunnen we een kwartet gebruiken om race-ongelijkheden te voorkomen bij een netwerkstoring.

Met het concept van kwartet heeft het systeem voldoende informatie (zelfs zonder verbinding met zijn partners) om automatisch te weten of knooppunten afscherming en/of herstel moeten initiëren.

Met de concept van quorum beschikt het systeem over voldoende informatie (zelfs zonder verbinding met partners) zodat knooppunten automatisch weten of ze een splitsing en/of herstelling moeten initiëren.

Zonder quorum nemen beide zijden van de netwerksplit terecht aan dat de andere zijde dood is en zullen ze proberen de ander af te scheiden. In het ergste geval slaagt het beide partijen erin om het hele cluster uit te schakelen. Een alternatief scenario is een deathmatch, een eindeloze cyclus van knooppunten die opmerken dat ze hun peers niet zien, opnieuw starten en herstelinitiatieven ondernemen, maar opnieuw opstarten als hun peer dezelfde logica volgt.

Het probleem met scheiding is dat de meest gebruikte apparaten onbereikbaar worden door dezelfde storingen waar we op willen anticiperen voor herstel. De meeste IPMI- en iLO-kaarten zijn geïnstalleerd op de hosts die ze controleren en gebruiken standaard hetzelfde netwerk, waardoor de doelknooppunten aannemen dat de andere knooppunten offline zijn.

Helaas worden de eigenschappen van IPMI- en iLO-apparaten zelden in overweging genomen op het moment van de aankoop van de apparatuur.

Indirecte scheiding

Quorum is ook belangrijk voor het beheer van indirecte scheidingen; als alles goed gedaan is, kan quorum de overlevenden toestaan aan te nemen dat de verloren knooppunten na een bepaalde tijd in een veilige toestand zullen overgaan.

Met deze configuratie wordt de hardware watchdog-timer elke N seconden gereset, zolang het quorum niet verloren is. Als de timer (meestal een veelvoud van N) verstrijkt, voert het apparaat een onbewuste uitschakeling uit (geen shutdown).

Deze aanpak is zeer effectief, maar zonder quorum voor het beheer is er onvoldoende informatie binnen het cluster. Het is moeilijk om het verschil te bepalen tussen een netwerkaus en het falen van een partnernode. De reden dat dit belangrijk is, is dat als je niet in staat bent om beide gevallen te onderscheiden, je gedwongen bent om hetzelfde gedragsmode in beide gevallen te kiezen.

Het probleem met het kiezen van één modus is dat er geen handelingswijze is die de beschikbaarheid maximaal vergroot en gegevensverlies voorkomt.

• Als je besluit aan te nemen dat de partnernode actief is, terwijl deze eigenlijk is mislukt, zal het cluster onterecht de diensten stopzetten die actief zouden moeten zijn om de verlies van diensten van de uitgevallen partnernode te compenseren.
• Als je zou besluiten aan te nemen dat een knooppunt niet werkt, maar het eigenlijk een netwerkstoring was en het externe knooppunt functioneert, dan meld je je in het beste geval aan voor enige toekomstige handmatige controle van de resulterende datasets.

Ongeacht welke heuristiek je gebruikt, is het triviaal om een storing te creëren die ofwel beide partijen laat werken, of het cluster dwingt om de overgebleven knooppunten af te sluiten. Het niet gebruiken van quorum ontnemt het cluster echt een van de krachtigste tools in zijn arsenaal.

Als er geen andere optie is, is de beste aanpak om de beschikbaarheid op te offeren (hier verwijst de auteur naar de CAP-theorema). Hoge beschikbaarheid van beschadigde gegevens helpt niemand, en het handmatig controleren van verschillende datasets levert ook niet veel plezier op.

Quorum

Quorum klinkt geweldig, nietwaar?

Het enige nadeel is dat, om het in een cluster met N leden te hebben, je een verbinding moet behouden tussen N / 2 + 1 van je knooppunten. Dit is onmogelijk in een cluster met twee knooppunten na de storing van een knooppunt.

Dit brengt ons uiteindelijk bij het fundamentele probleem met twee knooppunten:
quorum heeft geen zin in clusters met twee knooppunten, en zonder dit is het onmogelijk om betrouwbaar de acties te bepalen die de beschikbaarheid maximaliseren en gegevensverlies voorkomen.
Zelfs in een systeem van twee knooppunten, verbonden met een crossover-kabel, is het onmogelijk om definitief het verschil aan te geven tussen netwerkafsluiting en de storing van een ander knooppunt. Het afsluiten van één kant (de kans hiervan is uiteraard evenredig met de afstand tussen de knooppunten) is voldoende om enige veronderstelling dat de werking van het kanaal gelijk is aan de gezondheid van het partnerknooppunt te ontkrachten.

Een cluster van twee knooppunten aan de praat krijgen

Soms kan of wil de klant geen derde knooppunt kopen, en moeten we naar een alternatief zoeken.

Optie 1 – Dubbel methodisch aanspreken

Het iLO- of IPMI-apparaat van de node vormt een single point of failure, omdat we het in geval van een storing niet kunnen gebruiken om de node in een veilige staat te brengen. In een cluster van 3 of meer nodes kunnen we dit mitigeren door een quorum te berekenen en gebruik te maken van een hardware watchdog (de indirecte isolatiemechanisme zoals eerder besproken). In het geval van twee nodes moeten we in plaats daarvan gebruikmaken van power distribution units (PDU's).

Na een storing probeert de overgebleven node eerst contact te maken met het primaire isolatie-apparaat (de ingebouwde iLO of IPMI). Als dit lukt, gaat het herstel zoals gewoonlijk door. Alleen als het iLO- of IPMI-apparaat faalt, wordt er met de PDU contact opgenomen; als dat lukt, kan het herstel doorgaan.

Zorg ervoor dat de PDU in een netwerk is geplaatst dat verschilt van het clusterverkeer, anders blokkeert een enkele netwerkfout de toegang tot zowel de isolatie-apparaten als het herstel van de services.

Hier kunt u zich afvragen – is de PDU niet een single point of failure? Het antwoord is natuurlijk wel.

Als dit risico voor u significant is – u bent niet alleen: verbind beide nodes met twee PDU's en geef aan de clustersoftware door om beide te gebruiken bij het in- en uitschakelen van nodes. Nu blijft het cluster actief als één PDU uitvalt, en is voor het blokkeren van herstel een tweede storing van een andere PDU of het IPMI-apparaat vereist.

Optie 2 – Een arbiter toevoegen

In sommige scenario's, hoewel technisch een methode voor dubbele isolatie mogelijk is, is deze politiek moeilijk. Veel bedrijven geven er de voorkeur aan een bepaalde scheiding te hebben tussen beheerders en applicatie-eigenaren, en netwerkbeheerders die zich zorgen maken over de beveiliging staan niet altijd te popelen om iemand toegang te geven tot de PDU-instellingen.

In dit geval is de aanbevolen alternatieve oplossing om een neutrale derde partij op te richten die kan helpen bij het berekenen van het quorum.

In het geval van een storing moet de node in staat zijn het signaal van zijn partner of arbiter te zien om de services te herstellen. De arbiter heeft ook een ontkoppelingsfunctie, zodat als beide nodes de arbiter kunnen zien maar elkaar niet kunnen zien, de verbinding verbroken wordt.

Deze optie moet worden gebruikt in combinatie met een indirecte afscheidingsmethode, zoals een hardware watchdog timer, die is ingesteld om de machine uit te schakelen als deze de verbinding met zijn partnerknooppunt en arbiter verliest. Op deze manier kan de overlevende met voldoende vertrouwen aannemen dat zijn partnerknooppunt in een veilige toestand zal zijn na het verstrijken van de hardware watchdog timer.

Het praktische verschil tussen de arbiter en een derde knooppunt is dat de arbiter veel minder middelen vereist voor zijn werking en potentieel meerdere clusters kan bedienen.

Optie 3 — Menselijke factor

De laatste aanpak houdt in dat de overlevenden doorgaan met het uitvoeren van alle diensten die ze al deden, maar geen nieuwe starten totdat ofwel het probleem vanzelf wordt opgelost (netwerkherstel, herstarten van het knooppunt), of iemand de verantwoordelijkheid op zich neemt om handmatig te bevestigen dat de andere partij dood is.

Bonusoptie

Heb ik al gezegd dat je een derde knooppunt kunt toevoegen?

Twee rekken

Ter illustratie, laten we aannemen dat ik je heb overtuigd van de voordelen van een derde knooppunt; nu moeten we de fysieke locatie van de knooppunten overwegen. Als ze zijn geplaatst (en van stroom worden voorzien) in hetzelfde rek, vormt dit ook een SPoF, en eentje die niet kan worden opgelost door het toevoegen van een tweede rek.

Als dit verbazingwekkend is, denk dan aan wat er zou gebeuren als het rek met twee knooppunten uitvalt, en hoe de overlevende knooppunt deze situatie zal onderscheiden van een netwerklatency.

Kort antwoord: het is onmogelijk en we hebben opnieuw alle problemen waar we met twee knooppunten mee te maken hebben. Ofwel de overlevende:

• negeert de quorum en probeert onterecht herstel te initiëren tijdens netwerkonderbrekingen (de mogelijkheid om te scheiden is een apart verhaal en hangt af van of de PDU is ingeschakeld en of zij de stroom delen met een van de rekken), of
• respecteert de quorum en schakelt zichzelf voortijdig uit wanneer zijn partnerknooppunt faalt.

In elk geval zijn twee rekken niet beter dan één, en knooppunten moeten ofwel onafhankelijk van stroom worden voorzien of verdeeld worden over drie (of meer, afhankelijk van het aantal knooppunten dat je hebt) rekken.

Twee datacentra

Op dit moment kunnen lezers die minder risicovol zijn, nadenken over disaster recovery. Wat gebeurt er als een asteroïde een datacenter raakt met onze drie knooppunten, verspreid over drie verschillende racks? Het is duidelijk dat er slechte dingen gebeuren, maar afhankelijk van uw behoeften kan het toevoegen van een tweede datacenter onvoldoende zijn.

Als alles goed is gedaan, biedt het tweede datacenter u (en dat is redelijk) een actuele en consistente kopie van uw services en hun gegevens. Echter, zoals in scenario's met twee knooppunten en twee racks, is er in het systeem niet genoeg informatie om maximale beschikbaarheid te waarborgen en schade (of discrepantie in datasets) te voorkomen. Zelfs met drie knooppunten (of racks) laat hun spreiding over slechts twee datacenters het systeem niet in staat om betrouwbaar de juiste beslissing te nemen in het geval van een (nu veel waarschijnlijker) voorval dat beide zijden niet kunnen koppelen.

Dit betekent niet dat een oplossing met twee datacenters nooit geschikt is. Bedrijven willen vaak dat iemand op de hoogte is voordat ze de uitzonderlijke stap zetten om over te schakelen naar een back-up datacenter. Houd er gewoon rekening mee dat als u falen wilt automatiseren, u ofwel een derde datacenter nodig heeft zodat quorum zinvol is (direct of via een arbiter), of u vindt een manier om het hele datacenter betrouwbaar uit te schakelen.

Bron: habr.com