Hallo, Habr! Ik presenteer onder uw aandacht een vertaling van het artikel van Andreas Beekhof.
Veel mensen geven de voorkeur aan clusters met twee knooppunten omdat deze conceptueel eenvoudiger lijken en ook 33% goedkoper zijn dan hun tegenhangers met drie knooppunten. Hoewel het heel goed mogelijk is om een goed cluster van twee knooppunten samen te stellen, zal een dergelijke configuratie in de meeste gevallen, als gevolg van ondoordachte scenario's, veel niet voor de hand liggende problemen veroorzaken.
De eerste stap bij het creëren van een systeem met hoge beschikbaarheid is het vinden en proberen te elimineren van individuele faalpunten, vaak afgekort als SPoF (enkel punt van falen).
Houd er rekening mee dat het onmogelijk is om alle mogelijke risico's van downtime in welk systeem dan ook uit te sluiten. Dit komt voort uit het feit dat een typische verdediging tegen risico's het introduceren van enige redundantie is, wat leidt tot een grotere systeemcomplexiteit en het ontstaan van nieuwe faalpunten. Daarom sluiten we in eerste instantie een compromis en concentreren we ons op gebeurtenissen die verband houden met individuele faalpunten, en niet op ketens van gerelateerde en daardoor steeds minder waarschijnlijke gebeurtenissen.
Gegeven de afwegingen zoeken we niet alleen naar SPoF, maar balanceren we ook risico’s en consequenties, waardoor de conclusie van wat kritisch is en wat niet per inzet kan verschillen.
Niet iedereen heeft behoefte aan alternatieve elektriciteitsleveranciers met onafhankelijke elektriciteitsleidingen. Hoewel de paranoia voor minstens één klant vruchten afwierp toen hun monitoring een defecte transformator ontdekte. De klant belde om het energiebedrijf te waarschuwen totdat de defecte transformator ontplofte.
Een natuurlijk uitgangspunt is om meer dan één knooppunt in het systeem te hebben. Voordat het systeem echter na een storing services naar het overgebleven knooppunt kan verplaatsen, moet het er doorgaans voor zorgen dat de services die worden verplaatst niet elders actief zijn.
Er zijn geen nadelen aan een cluster met twee knooppunten als een storing ertoe leidt dat beide knooppunten dezelfde statische website bedienen. De zaken veranderen echter als het resultaat is dat beide partijen onafhankelijk een gedeelde takenwachtrij beheren of ongecoördineerde schrijftoegang bieden tot een gerepliceerde database of een gedeeld bestandssysteem.
Om gegevenscorruptie als gevolg van een fout in een enkel knooppunt te voorkomen, vertrouwen we daarom op iets dat wordt genoemd "dissociatie" (hekwerk).
Het principe van dissociatie
De kern van het dissociatieprincipe is de vraag: kan een concurrerend knooppunt datacorruptie veroorzaken? Als datacorruptie een waarschijnlijk scenario is, zou het een goede oplossing zijn om het knooppunt te isoleren van zowel inkomende verzoeken als permanente opslag. De meest gebruikelijke benadering van disassociatie is het loskoppelen van de defecte knooppunten.
Er zijn twee categorieën dissociatiemethoden, die ik zal noemen direct и indirect, maar ze kunnen evengoed worden genoemd actief и passief. Directe methoden omvatten acties van de kant van overlevende collega's, zoals interactie met een IPMI-apparaat (Intelligent Platform Management Interface) of iLO (een mechanisme voor het beheren van servers bij afwezigheid van fysieke toegang daartoe), terwijl indirecte methoden afhankelijk zijn van de mislukte node om op de een of andere manier te herkennen dat het zich in een ongezonde toestand bevindt (of op zijn minst verhindert dat andere leden herstellen) en een signaal te geven over de noodzaak om het defecte knooppunt los te koppelen.
Quorum helpt bij het gebruik van zowel directe als indirecte methoden.
Directe dissociatie
In het geval van directe dissociatie kunnen we quorum gebruiken om dissociatieraces te voorkomen in het geval van een netwerkstoring.
Met het concept van quorum is er voldoende informatie in het systeem (zelfs zonder verbinding te maken met zijn peers) zodat knooppunten automatisch weten of ze dissociatie en/of herstel moeten initiëren.
Zonder een quorum zullen beide kanten van een netwerkkloof er terecht van uitgaan dat de andere kant dood is en zullen ze proberen de ander uit elkaar te halen. In het ergste geval slagen beide partijen erin het hele cluster stil te leggen. Een alternatief scenario is een deathmatch, een eindeloze lus van knooppunten die spawnen, hun peers niet zien, ze opnieuw opstarten en het herstel initiëren om vervolgens opnieuw op te starten wanneer hun peer dezelfde logica volgt.
Het probleem met disassociatie is dat de meest gebruikte apparaten niet meer beschikbaar zijn vanwege dezelfde foutgebeurtenissen die we voor herstel willen targeten. De meeste IPMI- en iLO-kaarten worden geïnstalleerd op de hosts die ze beheren en gebruiken standaard hetzelfde netwerk, waardoor de doelhosts denken dat andere hosts offline zijn.
Helaas wordt bij de aanschaf van apparatuur zelden rekening gehouden met de bedieningskenmerken van IPMI- en iLo-apparaten.
Indirecte dissociatie
Quorum is ook belangrijk voor het beheren van indirecte disassociatie; als het correct wordt uitgevoerd, kan het quorum overlevenden de kans geven om aan te nemen dat verloren knooppunten na een bepaalde periode naar een veilige toestand zullen overgaan.
Met deze configuratie wordt de hardware watchdog-timer elke N seconden opnieuw ingesteld als het quorum niet verloren gaat. Als de timer (meestal meerdere veelvouden van N) afloopt, voert het apparaat een onplezierige uitschakeling uit (niet uitschakeling).
Deze aanpak is zeer effectief, maar zonder quorum is er niet voldoende informatie binnen het cluster om deze te beheren. Het is niet eenvoudig om het verschil te zien tussen een netwerkstoring en een storing in een peer-node. De reden dat dit ertoe doet is dat je, zonder de mogelijkheid om onderscheid te maken tussen de twee gevallen, in beide gevallen gedwongen wordt hetzelfde gedrag te kiezen.
Het probleem met het kiezen van één modus is dat er geen actie bestaat die de beschikbaarheid maximaliseert en gegevensverlies voorkomt.
- Als u ervoor kiest om aan te nemen dat een peer-node actief is maar feitelijk faalt, stopt het cluster onnodig services die actief zouden zijn om het verlies van services van het defecte peer-knooppunt te compenseren.
- Als u besluit aan te nemen dat een knooppunt niet beschikbaar is, maar dat het slechts om een netwerkfout gaat en dat het externe knooppunt in feite nog wel functioneert, dan tekent u in het beste geval aan voor een toekomstige handmatige afstemming van de resulterende datasets.
Ongeacht welke heuristiek u gebruikt, het is triviaal om een mislukking te creëren die ervoor zorgt dat beide partijen falen of ervoor zorgt dat het cluster de overgebleven knooppunten afsluit. Het niet gebruiken van het quorum berooft het cluster werkelijk van een van de krachtigste tools in zijn arsenaal.
Als er geen ander alternatief is, is de beste aanpak het opofferen van de beschikbaarheid (hier verwijst de auteur naar de CAP-stelling). Niemand heeft baat bij een hoge beschikbaarheid van beschadigde gegevens, en het handmatig afstemmen van verschillende datasets is ook niet leuk.
Quorum
Quorum klinkt geweldig, toch?
Het enige nadeel is dat je, om het in een cluster met N leden te hebben, een verbinding nodig hebt tussen N/2+1 van je resterende knooppunten. Dat is niet mogelijk in een cluster met twee knooppunten nadat één knooppunt uitvalt.
Dat 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 op betrouwbare wijze de handelwijze te bepalen die de beschikbaarheid maximaliseert en gegevensverlies voorkomt
Zelfs in een systeem van twee knooppunten die met elkaar zijn verbonden via een crossover-kabel, is het onmogelijk om definitief onderscheid te maken tussen een netwerkstoring en een storing van het andere knooppunt. Het uitschakelen van één uiteinde (waarvan de waarschijnlijkheid uiteraard evenredig is met de afstand tussen de knooppunten) zal voldoende zijn om elke aanname te ontkrachten dat de gezondheid van de link gelijk is aan de gezondheid van het partnerknooppunt.
Een cluster met twee knooppunten laten werken
Soms kan of wil de klant geen derde node aanschaffen en zijn wij genoodzaakt op zoek te gaan naar een alternatief.
Optie 1 - Dubbele dissociatiemethode
Het iLO- of IPMI-apparaat van een knooppunt vormt een punt van falen, omdat overlevenden het, als het uitvalt, niet kunnen gebruiken om het knooppunt in een veilige staat te brengen. In een cluster van drie of meer knooppunten kunnen we dit beperken door het quorum te berekenen en een hardware-watchdog te gebruiken (een indirect disassociatiemechanisme, zoals eerder besproken). In het geval van twee knooppunten moeten we in plaats daarvan netwerkstroomdistributie-eenheden (PDU's) gebruiken.
Na een storing probeert de overlevende eerst contact te maken met het primaire disassociatieapparaat (geïntegreerde iLO of IPMI). Als dit lukt, gaat het herstel gewoon door. Alleen als het iLO/IPMI-apparaat uitvalt, wordt toegang verkregen tot de PDU; als de toegang succesvol is, kan het herstel doorgaan.
Zorg ervoor dat u de PDU op een ander netwerk plaatst dan het clusterverkeer, anders zal een enkele netwerkfout de toegang tot beide disassociatie-apparaten blokkeren en het herstel van services blokkeren.
Hier kunt u zich afvragen: is de PDU een single point of Failure? Waarop het antwoord luidt: natuurlijk is dat zo.
Als dit risico voor u aanzienlijk is, bent u niet de enige: sluit beide knooppunten aan op twee PDU's en vertel de clustersoftware om beide te gebruiken bij het in- en uitschakelen van de knooppunten. Het cluster blijft nu actief als een PDU uitvalt, en er is een tweede storing van de andere PDU of het IPMI-apparaat nodig om het herstel te blokkeren.
Optie 2 - Een scheidsrechter toevoegen
In sommige scenario's is de dubbele disassociatiemethode weliswaar technisch mogelijk, maar politiek moeilijk. Veel bedrijven willen graag enige scheiding tussen beheerders en applicatie-eigenaren, en beveiligingsbewuste netwerkbeheerders zijn niet altijd enthousiast over het delen van PDU-toegangsinstellingen met wie dan ook.
In dit geval is het aanbevolen alternatief het creëren van een neutrale derde partij die de quorumberekening kan aanvullen.
In het geval van een storing moet een knooppunt de ethergolven van zijn peer of arbiter kunnen zien om de services te kunnen herstellen. De arbiter bevat ook een ontkoppelingsfunctie als beide knooppunten de arbiter kunnen zien, maar elkaar niet kunnen zien.
Deze optie moet worden gebruikt in combinatie met een indirecte disassociatiemethode, zoals een hardware watchdog-timer, die is geconfigureerd om een machine te beëindigen als deze de verbinding met zijn peer- en arbiterknooppunt verliest. Een overlevende kan er dus redelijkerwijs van uitgaan dat zijn peer-knooppunt zich in een veilige toestand bevindt nadat de hardware-watchdog-timer is verlopen.
Het praktische verschil tussen een arbiter en een derde knooppunt is dat een arbiter veel minder middelen nodig heeft om te kunnen functioneren en mogelijk meer dan één cluster kan bedienen.
Optie 3 – Menselijke factor
De uiteindelijke aanpak is dat overlevenden doorgaan met het uitvoeren van de services die ze al gebruikten, maar geen nieuwe starten totdat het probleem zichzelf oplost (netwerkherstel, knooppunt opnieuw opstarten) of iemand de verantwoordelijkheid op zich neemt om handmatig te bevestigen dat de andere kant dood is.
Bonusoptie
Had ik al gezegd dat je een derde knooppunt kunt toevoegen?
Twee rekken
Laten we ter wille van de discussie doen alsof ik je heb overtuigd van de verdiensten van het derde knooppunt, nu moeten we rekening houden met de fysieke opstelling van de knooppunten. Als ze in hetzelfde rack zijn ondergebracht (en van stroom worden voorzien), is er ook sprake van SPoF, en dat kan niet worden opgelost door een tweede rack toe te voegen.
Als dit verrassend is, bedenk dan wat er zou gebeuren als een rack met twee knooppunten uitvalt, en hoe het overgebleven knooppunt onderscheid zou maken tussen dat en een netwerkstoring.
Het korte antwoord is dat dit niet mogelijk is, en opnieuw hebben we te maken met alle problemen in het geval van twee knooppunten. Of overlevende:
- negeert het quorum en probeert ten onrechte herstel te initiëren tijdens netwerkstoringen (de mogelijkheid om de dissociatie te voltooien is een ander verhaal en hangt af van de vraag of de PDU erbij betrokken is en of deze de stroom delen met een van de racks), of
- respecteert het quorum en verbreekt de verbinding voortijdig wanneer het peer-knooppunt uitvalt
Hoe dan ook, twee racks zijn niet beter dan één, en de knooppunten moeten óf onafhankelijke voeding krijgen, óf worden verdeeld over drie (of meer, afhankelijk van hoeveel knooppunten je hebt) racks.
Twee datacenters
Op dit punt kunnen lezers die niet langer risicomijdend zijn, een rampherstel overwegen. Wat gebeurt er als een asteroïde hetzelfde datacenter raakt met onze drie knooppunten verspreid over drie verschillende racks? Uiteraard slechte dingen, maar afhankelijk van uw behoeften is het toevoegen van een tweede datacenter wellicht niet voldoende.
Indien correct gedaan, biedt het tweede datacenter u (en redelijkerwijs) een actuele en consistente kopie van uw diensten en hun gegevens. Echter, net als in scenario's met twee knooppunten en twee racks, is er niet voldoende informatie in het systeem om maximale beschikbaarheid te garanderen en corruptie (of discrepanties in de datasets) te voorkomen. Zelfs met drie knooppunten (of racks) zorgt de distributie ervan over slechts twee datacenters ervoor dat het systeem niet op betrouwbare wijze de juiste beslissing kan nemen in het geval van een (nu veel waarschijnlijker) gebeurtenis waarbij beide partijen niet kunnen communiceren.
Dit betekent niet dat een dual datacenteroplossing nooit geschikt is. Bedrijven willen vaak dat iemand zich ervan bewust is voordat hij de buitengewone stap zet om naar een back-updatacenter te verhuizen. Houd er rekening mee dat als u de storing wilt automatiseren, u óf een derde datacenter nodig heeft om het quorum zinvol te maken (hetzij rechtstreeks, hetzij via een scheidsrechter), óf u zult een manier vinden om op betrouwbare wijze alle gegevens af te sluiten. centrum.
Bron: www.habr.com