Hej, Habr! Jag presenterar för din uppmärksamhet en översättning av artikeln av Andrew Beekhof.
Många människor föredrar kluster med två noder eftersom de verkar konceptuellt enklare och dessutom är 33 % billigare än sina motsvarigheter med tre noder. Även om det är fullt möjligt att sätta ihop ett bra kluster av två noder, kommer i de flesta fall, på grund av oövervägda scenarier, en sådan konfiguration att skapa många uppenbara problem.
Det första steget för att skapa ett system med hög tillgänglighet är att hitta och försöka eliminera enskilda felpunkter, ofta förkortade som SPoF (enda punkt för misslyckande).
Det är värt att komma ihåg att det är omöjligt att eliminera alla möjliga risker för driftstopp i något system. Detta beror på att ett typiskt försvar mot risk är att införa viss redundans, vilket leder till ökad systemkomplexitet och uppkomsten av nya felpunkter. Därför gör vi initialt en kompromiss och fokuserar på händelser som är förknippade med enskilda felpunkter, och inte på kedjor av relaterade och därför allt mindre sannolika händelser.
Med tanke på avvägningarna letar vi inte bara efter SPoF, utan balanserar också risker och konsekvenser, vilket gör att slutsatsen om vad som är kritiskt och vad som inte är det kan skilja sig åt för varje utplacering.
Alla behöver inte alternativa elleverantörer med fristående kraftledningar. Även om paranoian lönade sig för minst en kund när deras övervakning upptäckte en trasig transformator. Kunden ringde telefonsamtal och försökte larma elbolaget tills den trasiga transformatorn exploderade.
En naturlig utgångspunkt är att ha mer än en nod i systemet. Men innan systemet kan flytta tjänster till den överlevande noden efter ett fel, måste det i allmänhet säkerställa att tjänsterna som flyttas inte är aktiva någon annanstans.
Det finns ingen nackdel med ett kluster med två noder om ett fel resulterar i att båda noderna betjänar samma statiska webbplats. Saker och ting förändras dock om resultatet blir att båda parter oberoende hanterar en delad jobbkö eller ger okoordinerad skrivåtkomst till en replikerad databas eller delat filsystem.
Därför, för att förhindra datakorruption som ett resultat av ett enda nodfel - vi litar på något som kallas "dissociation" (fäktning).
Dissociationsprincipen
Kärnan i dissociationsprincipen är frågan: kan en konkurrerande nod orsaka datakorruption? Om datakorruption är ett troligt scenario skulle en bra lösning vara att isolera noden från både inkommande förfrågningar och beständig lagring. Det vanligaste sättet att koppla bort är att koppla bort de felaktiga noderna.
Det finns två kategorier av dissociationsmetoder, som jag kommer att kalla direkt и indirekt, men de kan lika gärna kallas aktiva и passiv. Direkta metoder inkluderar åtgärder från överlevande kamrater, såsom interaktion med en IPMI (Intelligent Platform Management Interface) eller iLO (en mekanism för att hantera servrar i avsaknad av fysisk åtkomst till dem), medan indirekta metoder förlitar sig på den misslyckade nod för att på något sätt känna igen att den är i ett ohälsosamt tillstånd (eller åtminstone hindra andra medlemmar från att återhämta sig) och signalera om behovet av att koppla bort den misslyckade noden.
Quorum hjälper när du använder både direkta och indirekta metoder.
Direkt dissociation
Vid direkt dissociation kan vi använda kvorum för att förhindra dissociationslopp i händelse av nätverksfel.
Med begreppet kvorum finns det tillräckligt med information i systemet (även utan att ansluta till sina kamrater) för att noder automatiskt ska veta om de ska initiera dissociation och/eller återhämtning.
Utan ett kvorum kommer båda sidor av en nätverksklyfta med rätta att anta att den andra är död och kommer att försöka ta bort den andra. I värsta fall lyckas båda parter stänga ner hela klustret. Ett alternativt scenario är en deathmatch, en oändlig slinga av noder som leker, inte ser sina kamrater, startar om dem och initierar återhämtning bara för att starta om när deras kamrat följer samma logik.
Problemet med disassociation är att de vanligaste enheterna blir otillgängliga på grund av samma felhändelser som vi vill rikta in oss på för återställning. De flesta IPMI- och iLO-kort är installerade på de värdar som de kontrollerar och använder som standard samma nätverk, vilket får målvärdarna att tro att andra värdar är offline.
Tyvärr beaktas sällan driftsfunktionerna för IPMI- och iLo-enheter vid köp av utrustning.
Indirekt dissociation
Quorum är också viktigt för att hantera indirekt disassociation; om det görs på rätt sätt kan kvorum tillåta överlevande att anta att förlorade noder kommer att övergå till ett säkert tillstånd efter en viss tidsperiod.
Med denna konfiguration återställs hårdvaruövervakningstimern var N:e sekund om kvorum inte förloras. Om timern (vanligtvis flera multiplar av N) löper ut, utför enheten en ful avstängning (inte avstängning).
Detta tillvägagångssätt är mycket effektivt, men utan ett kvorum finns det inte tillräckligt med information inom klustret för att hantera det. Det är inte lätt att se skillnaden mellan ett nätverksavbrott och ett fel i peer-noden. Anledningen till att detta är viktigt är att utan förmågan att skilja mellan de två fallen tvingas du välja samma beteende i båda fallen.
Problemet med att välja ett läge är att det inte finns någon handling som maximerar tillgängligheten och förhindrar dataförlust.
- Om du väljer att anta att en peer-nod är aktiv men i själva verket misslyckas, kommer klustret i onödan att stoppa tjänster som skulle köras för att kompensera för förlusten av tjänster från den misslyckade peer-noden.
- Om du bestämmer dig för att anta att en nod är nere, men det var bara ett nätverksfel och i själva verket är fjärrnoden funktionell, så registrerar du dig i bästa fall för framtida manuell avstämning av de resulterande datamängderna.
Oavsett vilken heuristik du använder är det trivialt att skapa ett fel som antingen kommer att få båda sidor att misslyckas eller få klustret att stänga av de överlevande noderna. Att inte använda kvorum berövar verkligen klustret ett av de mest kraftfulla verktygen i dess arsenal.
Om det inte finns något annat alternativ är det bästa sättet att offra tillgänglighet (här hänvisar författaren till CAP-satsen). Hög tillgänglighet av korrupta data hjälper ingen, och att manuellt stämma av olika datamängder är inte heller kul.
Kvorum
Quorum låter bra, eller hur?
Den enda nackdelen är att för att ha den i ett kluster med N medlemmar måste du ha en koppling mellan N/2+1 av dina noder kvar. Vilket inte är möjligt i ett kluster med två noder efter att en nod misslyckats.
Vilket i slutändan för oss till det grundläggande problemet med två noder:
Quorum är inte vettigt i två nodkluster, och utan det är det omöjligt att på ett tillförlitligt sätt bestämma handlingssättet som maximerar tillgängligheten och förhindrar dataförlust
Även i ett system med två noder anslutna med en korsad kabel är det omöjligt att definitivt skilja mellan ett nätverksavbrott och ett fel i den andra noden. Att inaktivera ena änden (vars sannolikhet naturligtvis är proportionell mot avståndet mellan noderna) kommer att vara tillräckligt för att ogiltigförklara alla antaganden om att länkens hälsa är lika med hälsan hos partnernoden.
Att få ett kluster med två noder att fungera
Ibland kan eller vill klienten inte köpa en tredje nod, och vi tvingas leta efter ett alternativ.
Alternativ 1 - Duplicerad dissociationsmetod
En nods iLO- eller IPMI-enhet representerar en felpunkt eftersom, om den misslyckas, kan överlevande inte använda den för att föra noden till ett säkert tillstånd. I ett kluster med 3 eller fler noder kan vi mildra detta genom att beräkna kvorum och använda en hårdvaruövervakning (en indirekt disassocieringsmekanism, som diskuterats tidigare). När det gäller två noder måste vi istället använda nätverkskraftdistributionsenheter (PDU).
Efter ett misslyckande försöker den överlevande först kontakta den primära disassocieringsenheten (inbäddad iLO eller IPMI). Om detta lyckas fortsätter återhämtningen som vanligt. Endast om iLO/IPMI-enheten misslyckas nås PDU:n; om åtkomsten lyckas kan återställningen fortsätta.
Var noga med att placera PDU:n på ett annat nätverk än klustertrafiken, annars kommer ett enskilt nätverksfel att blockera åtkomsten till båda frånkopplingsenheterna och blockera återställningen av tjänster.
Här kan du fråga dig - är PDU en enda punkt av misslyckande? Vilket svaret är, så är det naturligtvis.
Om denna risk är betydande för dig är du inte ensam: anslut båda noderna till två PDU:er och säg till klusterprogramvaran att använda både när du slår på och av noderna. Klustret förblir nu aktivt om en PDU dör, och ett andra fel på antingen den andra PDU eller IPMI-enheten kommer att krävas för att blockera återställning.
Alternativ 2 - Lägga till en skiljedomare
I vissa scenarier, medan metoden för dubbla disassociering är tekniskt möjlig, är det politiskt svårt. Många företag gillar att ha en viss åtskillnad mellan administratörer och applikationsägare, och säkerhetsmedvetna nätverksadministratörer är inte alltid entusiastiska över att dela PDU-åtkomstinställningar med någon.
I det här fallet är det rekommenderade alternativet att skapa en neutral tredje part som kan komplettera beslutförhetsberäkningen.
I händelse av ett misslyckande måste en nod kunna se etern från sin peer eller arbiter för att kunna återställa tjänster. Medlaren inkluderar också en frånkopplingsfunktion om båda noderna kan se medlaren men inte kan se varandra.
Det här alternativet måste användas tillsammans med en indirekt disassocieringsmetod, såsom en hårdvaruövervakningstimer, som är konfigurerad att döda en maskin om den tappar anslutningen till sin peer- och arbiternod. Således kan en överlevande rimligen anta att dess peer-nod kommer att vara i ett säkert tillstånd efter det att hårdvaruövervakningstimern löper ut.
Den praktiska skillnaden mellan en arbiter och en tredje nod är att en arbiter kräver mycket färre resurser för att fungera och kan potentiellt tjäna mer än ett kluster.
Alternativ 3 - Mänsklig faktor
Det slutliga tillvägagångssättet är att överlevande ska fortsätta köra vilka tjänster de redan körde, men inte starta nya förrän antingen problemet löser sig (nätverksåterställning, nodomstart) eller en person tar ansvar för att manuellt bekräfta att den andra sidan är död.
Bonusalternativ
Nämnde jag att du kan lägga till en tredje nod?
Två ställ
För argumentets skull, låt oss låtsas att jag har övertygat dig om fördelarna med den tredje noden, nu måste vi överväga det fysiska arrangemanget av noderna. Om de är inrymda (och drivs) i samma rack, utgör detta också SPoF, och en som inte kan lösas genom att lägga till ett andra rack.
Om detta är förvånande, fundera på vad som skulle hända om ett rack med två noder misslyckades, och hur den överlevande noden skulle skilja mellan det och ett nätverksfel.
Det korta svaret är att det inte är möjligt, och återigen har vi att göra med alla problem i fallet med två noder. Eller överlevande:
- ignorerar kvorum och felaktigt försöker initiera återställning under nätverksavbrott (möjligheten att slutföra dissociation är en annan historia och beror på om PDU är inblandad och om de delar ström med något av racken), eller
- respekterar kvorum och kopplar bort sig själv i förtid när dess peer-nod misslyckas
Två rack är i alla fall inte bättre än ett, och noderna måste antingen få oberoende strömförsörjning eller vara fördelade över tre (eller fler, beroende på hur många noder du har) rack.
Två datacenter
Vid det här laget kan läsare som inte längre är riskvilliga överväga katastrofåterställning. Vad händer när en asteroid träffar samma datacenter med våra tre noder spridda över tre olika rack? Uppenbarligen dåliga saker, men beroende på dina behov kanske det inte räcker att lägga till ett andra datacenter.
Om det görs på rätt sätt ger det andra datacentret dig (och rimligen) en uppdaterad och konsekvent kopia av dina tjänster och deras data. Men som i scenarier med två noder och två rack, finns det inte tillräckligt med information i systemet för att säkerställa maximal tillgänglighet och förhindra korruption (eller datauppsättningsavvikelser). Även med tre noder (eller rack), fördelning av dem över endast två datacenter gör att systemet inte på ett tillförlitligt sätt kan fatta rätt beslut i händelse av en (nu mycket mer trolig) händelse som båda parter inte kan kommunicera.
Det betyder inte att en dubbel datacenterlösning aldrig är lämplig. Företag vill ofta att en person ska vara medveten innan han tar det extraordinära steget att flytta till ett backup-datacenter. Tänk bara på att om du vill automatisera avbrottet behöver du antingen ett tredje datacenter för att kvorum ska vara vettigt (antingen direkt eller genom en skiljedomare), eller så hittar du ett sätt att på ett tillförlitligt sätt stänga av hela data Centrum.
Källa: will.com