Hej, Habr! Jag presenterar översättningen av artikeln författaren Andrew Beekhof.
Många människor föredrar kluster som består av två noder, eftersom de verkar konceptuellt enklare, dessutom är de 33% billigare än deras tre-nods syskon. Även om det är fullt möjligt att bygga ett bra kluster med två noder, skapar en sådan konfiguration i många fall en mängd oklara problem på grund av oövervägda scenarier.
Det första steget i att skapa vilket hög tillgänglighetssystem som helst är att identifiera och försöka åtgärda enskilda felpunkter, ofta förkortat till SPoF (single point of failure).
Det är viktigt att ha i åtanke att det i något system är omöjligt att eliminera alla potentiella driftavbrott. Detta beror åtminstone på att typisk för att skydda mot risker är att införa viss redundans, vilket leder till ökad systemkomplexitet och nya felpunkter. Därför gör vi från början en kompromiss och fokuserar på händelser kopplade till enskilda felpunkter, snarare än på kedjor av relaterade och därmed allt mindre sannolika händelser.
Med hänsyn till kompromisserna letar vi inte bara efter SPoF, utan balanserar också risker och konsekvenser, vilket innebär att slutsatsen om vad som är kritiskt och vad som inte är det kan variera för varje distribution.
Inte alla behöver alternativa el-leverantörer med oberoende kraftledningar. Även om paranoia har lönat sig åtminstone för en kund, när deras övervakning upptäckte en trasig transformer. Kunden ringde för att försöka varna energibolaget tills den trasiga transformern 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 generellt sett säkerställas att de flyttade tjänsterna inte är aktiva på något annat ställe.
Ett tvånoders kluster har inga nackdelar om båda noderna i händelse av ett avbrott hanterar samma statiska webbplats. Men allt ändras om båda sidorna oberoende hanterar en gemensam kö av uppgifter eller erbjuder icke-synkroniserad skrivåtkomst till en replikerad databas eller ett gemensamt filsystem.
Därför, för att förhindra dataskador till följd av ett nodes misslyckande – förlitar vi oss på det som kallas »avgränsning« (fencing).
Principen för avgränsning
Vid basen av avgränsningsprincipen ligger frågan: kan en konkurrerande nod orsaka dataskador? Om dataskador är ett troligt scenario – är en bra lösning att isolera noden från både inkommande förfrågningar och permanent lagring. Den mest använda metoden för avgränsning är att stänga av defekta noder.
Det finns två kategorier av avgränsningsmetoder som jag kommer att kalla direkta och indirekta, men de kan också kallas aktiva och passiva. Direkta metoder omfattar åtgärder från kvarstående likvärdiga noder, såsom interaktion med en IPMI-enhet (Intelligent Platform Management Interface – gränssnitt för fjärrövervakning och hantering av en servers fysiska tillstånd) eller iLO (en serverhanteringsmekanism i frånvaro av fysisk åtkomst), medan indirekta metoder förlitar sig på den misslyckade noden att på något sätt känna igen att den är i ett ohälsosamt tillstånd (eller åtminstone hindrar andra noder från att återhämta sig) och signalera om behovet av att stänga av den misslyckade noden.
Kvorum hjälper vid användning av både direkta och indirekta metoder.
Direkt avgränsning
Vid direkt avgränsning kan vi använda kvorum för att förhindra avgränsningskappningar i händelse av nätverksfel.
Med kvorumkonceptet har systemet tillräcklig information (även utan att vara anslutet till sina partners) för att noder automatiskt ska veta om de ska initiera avgränsning och / eller återställning.
Utan kvorum antar båda sidor av nätverksuppdelningen rättvist att den andra sidan är död och kommer att sträva efter att avgränsa den andra. I värsta fall lyckas båda sidor att stänga av hela klustret. Ett alternativt scenario – deathmatch, en oändlig cykel av noder som dyker upp, som inte ser sina grannar, omstartar dem och initierar återställningar bara för att starta om när deras granne följer samma logik.
Problemet med att särskilja består i att de mest använda enheterna ofta blir otillgängliga på grund av samma felhändelser som vi vill återhämta oss från. De flesta IPMI- och iLO-kort är installerade på de värdar de övervakar och använder som standard samma nätverk, vilket gör att de målinriktade noderna tror att de andra noderna är offline.
Tyvärr beaktas sällan egenskaperna hos IPMI- och iLo-enheter vid köp av utrustning.
Indirekt särskiljande
Kvorum är också viktigt för att hantera indirekta särskiljanden; om allt görs korrekt kan kvorumet låta överlevande anta att de förlorade noderna efter en viss tid går in i ett säkert tillstånd.
Med denna inställning återställs hårdvaruövervakningens timer var N:e sekund, om kvorumet inte har förlorats. Om timern (vanligtvis något multipel av N) går ut, gör enheten en oönskad avstängning (inte shutdown).
Denna metod är mycket effektiv, men utan kvorum för att styra den, finns det inte tillräckligt med information inom klustret. Det är inte lätt att avgöra skillnaden mellan att nätverket stängs av och att en partnernod har fallerat. Anledningen till att detta är viktigt är att om du inte kan särskilja de två fallen, tvingas du välja samma beteendemönster i båda fallen.
Problemet med att välja ett enda läge är att det inte finns något handlingssätt som maximalt ökar tillgängligheten och förhindrar dataloss.
- Om du beslutar att anta att partnernoden är aktiv, men det faktiskt har inträffat ett fel, kommer klustret att avbryta tjänster i onödan som borde ha varit aktiva för att kompensera för förlusten av tjänster från den fallna partnernoden.
- Om du beslutar att anta att noden inte fungerar, men det faktiskt bara var ett nätverksfel och den fjärrnodet fungerar, då i bästa fall måste du räkna med att göra en manuell synkronisering av de resulterande datamängderna i framtiden.
Oavsett vilken heuristik du använder, är det enkelt att åstadkomma ett fel som antingen får båda sidor att fungera eller får klustret att stänga av de överlevande noderna. Att inte använda kvorum berövar faktiskt klustret ett av de mäktigaste verktygen i dess arsenal.
Om det inte finns något annat alternativ, är den bästa metoden att offra tillgänglighet (här refererar författaren till CAP-teoremet). Hög tillgänglighet av korrupt data hjälper ingen, och att manuellt kontrollera olika datamängder är inte heller trevligt.
Kvorum
Kvorum låter bra, eller hur?
Den enda nackdelen är att för att ha det i en kluster med N medlemmar, måste du ha en anslutning kvar mellan N / 2 + 1 av dina noder. Detta är omöjligt i en kluster med två noder efter att en nod har misslyckats.
Vad som så småningom leder oss till det fundamentala problemet med två noder:
kvorum är meningslöst i kluster med två noder, och utan det är det omöjligt att pålitligt avgöra en handlingsplan som maximerar tillgängligheten och förhindrar dataloss.
Även i ett system med två noder, anslutna med korskablar, är det omöjligt att definitivt särskilja mellan nätverksavbrott och ett misslyckande av den andra noden. Avbrott av ena änden (vars sannolikhet visserligen är proportionell mot avståndet mellan noder) skulle vara tillräckligt för att motbevisa varje antagande om att kanalens funktionalitet är lika med hälsan hos partnernoden.
Få tvånoderklustret att fungera
Ibland kan kunden inte eller vill inte köpa en tredje nod, och vi måste leta efter ett alternativ.
Alternativ 1 - Dubbel metod för avskiljning
En iLO- eller IPMI-enhet för noden är en punkt för fel, eftersom de överlevande, vid misslyckande, inte kan använda den för att sätta noden i ett säkert tillstånd. I ett kluster med 3 eller fler noder kan vi mildra detta genom att räkna kvorum och använda en hårdvaruövervakare (en mekanism för indirekt avskiljning, som diskuterats tidigare). I fallet med två noder måste vi i stället använda nätverkspöningsanordningar (power distribution units eller PDUs).
Efter ett misslyckande försöker den överlevande först att kontakta den primära avskiljningsanordningen (inbyggd iLO eller IPMI). Om det lyckas, fortsätter återställningen som vanligt. Endast i fallet med misslyckande av enheten iLO / IPMI sker kontakt med PDU, och om det är framgångsrikt kan återställningen fortsätta.
Se försäkra er om att placera PDU på ett nätverk som skiljer sig från trafiken för klustret, annars kan ett enstaka nätverksfel blockera tillgången både till avstängningsenheterna och till återställningen av tjänster.
Här kan ni fråga er – är inte PDU-enheten en enda felpunkt? Svaret är – naturligtvis är den det.
Om denna risk är betydande för er – ni är inte ensamma: anslut båda noder till två PDU:er och ange klusterprogramvaran att använda båda vid på- och avstängning av noder. Nu förblir klustret aktivt om en PDU dör, och för att blockera återställning krävs en andra felpunkt, antingen från den andra PDU:en eller IPMI-enheten.
Alternativ 2 – Tillsätt en skiljedomare
I vissa scenarier, även om metoden för dubbel avstängning tekniskt är möjlig, är den politiskt komplicerad. Många företag föredrar att ha en tydlig åtskillnad mellan administratörer och applikationsägare, och säkerhetsmedvetna nätverksadministratörer är inte alltid entusiastiska när det kommer till att ge någon som helst åtkomst till PDU.
I detta fall är det rekommenderade alternativet att skapa en neutral tredje part som kan komplettera kvorumberäkningen.
Vid fel ska noden kunna se sin partners eller skiljedomsarens signal för att återställa tjänster. Skiljedomaren inkluderar också en funktionen för att bryta anslutningen, om båda noderna kan se skiljedomaren men inte varandra.
Detta alternativ bör användas tillsammans med en indirekt avstängningsmetod, till exempel en hårdvaru-watchdog-timer som är inställd på att stänga av maskinen om den mister anslutningen till sin partnernod och skiljedomaren. På så sätt kan överlevande med tillräcklig säkerhet förutsäga att deras partnernod kommer att vara i ett säkert tillstånd efter att hårdvaru-watchdog-timern har löpt ut.
Det praktiska skillnaden mellan en skiljedomare och en tredje nod är att skiljedomaren kräver betydligt mindre resurser för att fungera och kan potentiellt betjäna mer än ett kluster.
Alternativ 3 – Den mänskliga faktorn
Den sista metoden handlar om att de överlevande fortsätter att utföra eventuella tjänster de redan har kört, men inte starta några nya, förrän antingen problemet löser sig självt (nätverksåterställning, omstart av nod) eller någon tar ansvar för att manuellt bekräfta att den andra sidan är död.
Bonusalternativ
Har jag redan nämnt att du kan lägga till en tredje nod?
Två rack
För argumentets skull, låt oss anta att jag övertygade dig om fördelarna med en tredje nod, nu måste vi överväga den fysiska placeringen av noderna. Om de är placerade (och får ström) i samma rack, utgör det också ett SPoF, och en sådan som inte kan lösas genom att lägga till ett andra rack.
Om detta är överraskande, tänk på vad som skulle hända om racken med två noder går ner, och hur den överlevande noden skulle särskilja detta fall och nätverksfelet.
Det korta svaret: det är omöjligt, och vi har återigen att hantera alla problem som är involverade med två noder. Antingen överlever:
- ignorerar kvorum och försöker felaktigt initiera återställning under nätverksavbrott (möjligheten till avbrott är en separat historia och beror på huruvida PDU:n är involverad och om de delar ström med något av racken), eller
- respekterar kvorum och stänger sig själv för tidigt när dess partnernod misslyckas.
I vilket fall som helst, två rack är inte bättre än ett, och noderna måste antingen få oberoende strömkällor eller spridas ö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 benägna att ta risker överväga katastrofåterställning. Vad händer när en asteroid träffar ett datacenter med våra tre noder distribuerade över tre olika rack? Uppenbarligen dåliga saker, men beroende på dina behov kan tillägg av ett andra datacenter vara otillräckligt.
Om allt görs korrekt, ger det andra datacentret dig (och detta är rimligt) en aktuell och konsekvent kopia av dina tjänster och deras data. Men precis som i scenarier med två noder och två rack, har systemet inte tillräckligt med information för att säkerställa maximal tillgänglighet och förhindra skador (eller avvikelser i datamängder). Även med tre noder (eller rack) lämnar deras fördelning över endast två datacenter systemet oförmöget att pålitligt fatta rätt beslut vid en händelse (nu mycket mer sannolikt) som båda sidor inte kan koppla till.
Detta betyder inte att en lösning med två datacenter aldrig är lämplig. Företag vill ofta att någon ska vara medveten innan man vidtar en extraordinär åtgärd för att övergå till ett reservdatacenter. Tänk bara på att om du vill automatisera ett fel behöver du antingen ett tredje datacenter så att kvorum är meningsfullt (direkt eller genom en domare), eller så måste du hitta ett sätt att pålitligt stänga av hela datacentret.
Källa: habr.com
