Hej Habr! Jeg præsenterer for din opmærksomhed oversættelsen af artiklen af Andrew Beekhof.
Mange mennesker foretrækker to-node klynger, fordi de virker konceptuelt enklere og er også 33% billigere end deres tre-node modstykker. Selvom det er ganske muligt at sammensætte en god klynge af to noder, vil en sådan konfiguration i de fleste tilfælde på grund af uovervejede scenarier skabe mange uoplagte problemer.
Det første skridt til at skabe et system med høj tilgængelighed er at finde og forsøge at eliminere individuelle fejlpunkter, ofte forkortet som SPoF (enkelt fejlpunkt).
Det er værd at huske på, at det er umuligt at eliminere alle mulige risici for nedetid i ethvert system. Dette skyldes, at et typisk forsvar mod risiko er at indføre en vis redundans, hvilket fører til øget systemkompleksitet og fremkomsten af nye fejlpunkter. Derfor indgår vi i første omgang et kompromis og fokuserer på hændelser forbundet med individuelle fejlpunkter og ikke på kæder af relaterede og derfor stadigt mindre sandsynlige hændelser.
På baggrund af afvejningerne ser vi ikke kun efter SPoF, men balancerer også risici og konsekvenser, som et resultat af, at konklusionen om, hvad der er kritisk, og hvad der ikke er, kan variere for hver implementering.
Ikke alle har brug for alternative elleverandører med selvstændige elledninger. Selvom paranoiaen betalte sig for mindst én kunde, da deres overvågning opdagede en defekt transformer. Kunden foretog telefonopkald og forsøgte at advare elselskabet, indtil den defekte transformer eksploderede.
Et naturligt udgangspunkt er at have mere end én node i systemet. Men før systemet kan flytte tjenester til den overlevende node efter en fejl, skal det generelt sikre, at de tjenester, der flyttes, ikke er aktive andre steder.
Der er ingen ulempe ved en to-node-klynge, hvis en fejl resulterer i, at begge noder betjener det samme statiske websted. Tingene ændrer sig dog, hvis resultatet er, at begge parter uafhængigt administrerer en delt jobkø eller giver ukoordineret skriveadgang til en replikeret database eller et delt filsystem.
Derfor, for at forhindre datakorruption som følge af en enkelt knudefejl - stoler vi på noget, der hedder "dissociation" (hegn).
Dissociationsprincippet
Kernen i dissociationsprincippet er spørgsmålet: kan en konkurrerende node forårsage datakorruption? Hvis datakorruption er et sandsynligt scenario, ville en god løsning være at isolere noden fra både indgående anmodninger og vedvarende lagring. Den mest almindelige tilgang til adskillelse er at afbryde de defekte noder.
Der er to kategorier af dissociationsmetoder, som jeg vil kalde direkte и indirekte, men de kan lige så godt kaldes aktiv и passiv. Direkte metoder omfatter handlinger fra overlevende jævnaldrende, såsom interaktion med en IPMI (Intelligent Platform Management Interface) eller iLO (en mekanisme til styring af servere i mangel af fysisk adgang til dem), mens indirekte metoder er afhængige af den fejlslagne node for på en eller anden måde at erkende, at den er i en usund tilstand (eller i det mindste forhindrer andre medlemmer i at komme sig) og signalere om behovet for at afbryde den mislykkede node.
Quorum hjælper, når du bruger både direkte og indirekte metoder.
Direkte dissociation
I tilfælde af direkte dissociation kan vi bruge quorum til at forhindre dissociationsløb i tilfælde af netværksfejl.
Med begrebet kvorum er der nok information i systemet (selv uden at oprette forbindelse til dets peers) til, at noder automatisk ved, om de skal igangsætte dissociation og/eller recovery.
Uden et kvorum vil begge sider af en netværkskløft med rette antage, at den anden side er død og vil søge at adskille den anden. I værste fald lykkes det begge parter at lukke hele klyngen ned. Et alternativt scenarie er en deathmatch, en endeløs sløjfe af noder, der gyder, ikke ser deres jævnaldrende, genstarter dem og starter recovery kun for at genstarte, når deres peer følger den samme logik.
Problemet med adskillelse er, at de mest almindeligt anvendte enheder bliver utilgængelige på grund af de samme fejlhændelser, som vi ønsker at målrette mod gendannelse. De fleste IPMI- og iLO-kort er installeret på de værter, de kontrollerer, og bruger som standard det samme netværk, hvilket får målværterne til at tro, at andre værter er offline.
Desværre tages driftsfunktionerne i IPMI- og iLo-enheder sjældent i betragtning ved køb af udstyr.
Indirekte dissociation
Kvorum er også vigtigt for håndtering af indirekte adskillelse; hvis det gøres korrekt, kan quorum tillade overlevende at antage, at tabte noder vil gå over til en sikker tilstand efter en vis periode.
Med denne konfiguration nulstilles hardware watchdog-timeren hvert N sekund, hvis kvorum ikke er tabt. Hvis timeren (sædvanligvis flere multipla af N) udløber, udfører enheden en upræcis nedlukning (ikke nedlukning).
Denne tilgang er meget effektiv, men uden et beslutningsdygtighed er der ikke nok information i klyngen til at administrere den. Det er ikke let at kende forskel på et netværksudfald og en peer-nodefejl. Grunden til, at dette er vigtigt, er, at uden evnen til at skelne mellem de to tilfælde, er du tvunget til at vælge den samme adfærd i begge tilfælde.
Problemet med at vælge én tilstand er, at der ikke er nogen handling, der maksimerer tilgængeligheden og forhindrer tab af data.
- Hvis du vælger at antage, at en peer-node er aktiv, men faktisk fejler, vil klyngen unødigt stoppe tjenester, der ville køre for at kompensere for tabet af tjenester fra den mislykkede peer-node.
- Hvis du beslutter dig for at antage, at en node er nede, men det var bare en netværksfejl, og faktisk er den eksterne node funktionel, så tilmelder du dig i bedste fald en fremtidig manuel afstemning af de resulterende datasæt.
Uanset hvilken heuristik du bruger, er det trivielt at skabe en fejl, der enten vil få begge sider til at fejle eller få klyngen til at lukke de overlevende noder. Ikke at bruge kvorum fratager virkelig klyngen et af de mest kraftfulde værktøjer i dets arsenal.
Hvis der ikke er noget andet alternativ, er den bedste tilgang at ofre tilgængelighed (her henviser forfatteren til CAP-sætningen). Høj tilgængelighed af korrupte data hjælper ikke nogen, og det er heller ikke sjovt at afstemme forskellige datasæt manuelt.
Kvorum
Kvorum lyder godt, ikke?
Den eneste ulempe er, at for at have det i en klynge med N medlemmer, skal du have en forbindelse mellem N/2+1 af dine noder tilbage. Hvilket ikke er muligt i en klynge med to noder, efter at en node fejler.
Hvilket i sidste ende bringer os til det grundlæggende problem med to noder:
Quorum giver ikke mening i to node-klynger, og uden det er det umuligt pålideligt at bestemme handlingsforløbet, der maksimerer tilgængeligheden og forhindrer tab af data
Selv i et system med to knudepunkter forbundet med et crossover-kabel, er det umuligt definitivt at skelne mellem et netværksudfald og en fejl i den anden knude. Deaktivering af den ene ende (hvis sandsynligheden selvfølgelig er proportional med afstanden mellem knudepunkterne) vil være nok til at ugyldiggøre enhver antagelse om, at linkets sundhed er lig med partnerknudepunktets sundhed.
Få en to-node klynge til at fungere
Nogle gange kan eller ønsker klienten ikke at købe en tredje node, og vi er tvunget til at lede efter et alternativ.
Mulighed 1 - Dublet dissociationsmetode
En nodes iLO- eller IPMI-enhed repræsenterer et fejlpunkt, fordi, hvis den fejler, kan overlevende ikke bruge den til at bringe noden til en sikker tilstand. I en klynge på 3 eller flere noder kan vi afbøde dette ved at beregne kvorum og bruge en hardware-overvågningsmekanisme (en indirekte disassocieringsmekanisme, som diskuteret tidligere). I tilfælde af to noder skal vi i stedet bruge netværksstrømfordelingsenheder (PDU'er).
Efter en fejl forsøger den overlevende først at kontakte den primære adskillelsesenhed (indlejret iLO eller IPMI). Hvis dette lykkes, fortsætter genopretningen som normalt. Kun hvis iLO/IPMI-enheden fejler, tilgås PDU'en; hvis adgangen lykkes, kan gendannelsen fortsætte.
Sørg for at placere PDU'en på et andet netværk end klyngetrafikken, ellers vil en enkelt netværksfejl blokere adgangen til både adskillelsesenhederne og blokere gendannelsen af tjenester.
Her kan du spørge - er PDU'en et enkelt fejlpunkt? Hvortil svaret er, selvfølgelig er det.
Hvis denne risiko er betydelig for dig, er du ikke alene: Forbind begge noder til to PDU'er, og bed klyngesoftwaren om at bruge både, når du tænder og slukker for noderne. Klyngen forbliver nu aktiv, hvis en PDU dør, og en anden fejl på enten den anden PDU eller IPMI-enheden vil være påkrævet for at blokere gendannelse.
Mulighed 2 - Tilføjelse af en dommer
I nogle scenarier, mens duplikatadskillelsesmetoden er teknisk mulig, er den politisk vanskelig. Mange virksomheder kan lide at have en vis adskillelse mellem administratorer og applikationsejere, og sikkerhedsbevidste netværksadministratorer er ikke altid begejstrede for at dele PDU-adgangsindstillinger med nogen.
I dette tilfælde er det anbefalede alternativ at oprette en neutral tredjepart, der kan supplere kvorumberegningen.
I tilfælde af en fejl skal en node være i stand til at se æteren fra sin peer eller dommer for at genoprette tjenester. Dommeren inkluderer også en afbrydelsesfunktion, hvis begge noder kan se dommeren, men ikke kan se hinanden.
Denne mulighed skal bruges sammen med en indirekte adskillelsesmetode, såsom en hardware watchdog timer, som er konfigureret til at dræbe en maskine, hvis den mister forbindelsen til sin peer og arbiter node. En overlevende kan således med rimelighed antage, at dens peer-node vil være i en sikker tilstand, efter at hardware watchdog-timeren udløber.
Den praktiske forskel mellem en arbiter og en tredje node er, at en arbiter kræver langt færre ressourcer for at fungere og potentielt kan betjene mere end én klynge.
Mulighed 3 - Menneskelig faktor
Den endelige tilgang er for overlevende at fortsætte med at køre de tjenester, de allerede kørte, men ikke starte nye, før enten problemet løser sig selv (netværksgendannelse, genstart af node), eller en person tager ansvar for manuelt at bekræfte, at den anden side er død.
Bonus mulighed
Fik jeg nævnt, at du kan tilføje en tredje node?
To stativer
For argumentets skyld, lad os foregive, at jeg har overbevist dig om fordelene ved den tredje knude, nu skal vi overveje det fysiske arrangement af knudepunkterne. Hvis de er anbragt (og strømforsynet) i det samme rack, udgør dette også SPoF, og en der ikke kan løses ved at tilføje et andet rack.
Hvis dette er overraskende, så overvej, hvad der ville ske, hvis et rack med to noder fejlede, og hvordan den overlevende node ville skelne mellem det og en netværksfejl.
Det korte svar er, at det ikke er muligt, og igen har vi at gøre med alle problemerne i tilfældet med to knudepunkter. Eller overlevende:
- ignorerer beslutningsdygtighed og forsøger forkert at starte gendannelse under netværksudfald (evnen til at fuldføre dissociation er en anden historie og afhænger af, om PDU'en er involveret, og om de deler strøm med nogen af rackene), eller
- respekterer kvorum og afbryder forbindelsen før tid, når dens peer-node svigter
Under alle omstændigheder er to racks ikke bedre end én, og noderne skal enten modtage uafhængige strømforsyninger eller være fordelt på tre (eller flere, alt efter hvor mange noder du har) racks.
To datacentre
På dette tidspunkt kan læsere, der ikke længere er risikovillige, overveje katastrofeopsving. Hvad sker der, når en asteroide rammer det samme datacenter med vores tre noder spredt over tre forskellige stativer? Naturligvis dårlige ting, men afhængigt af dine behov er det muligvis ikke nok at tilføje et ekstra datacenter.
Hvis det gøres korrekt, giver det andet datacenter dig (og med rimelighed) en opdateret og konsistent kopi af dine tjenester og deres data. Men som i scenarier med to noder og to rack, er der ikke nok information i systemet til at sikre maksimal tilgængelighed og forhindre korruption (eller datasæt-uoverensstemmelser). Selv med tre noder (eller racks), vil distribution af dem på tværs af kun to datacentre efterlade systemet ude af stand til pålideligt at træffe den rigtige beslutning i tilfælde af en (nu meget mere sandsynlig) hændelse, som begge parter ikke kan kommunikere.
Det betyder ikke, at en dobbelt datacenterløsning aldrig er egnet. Virksomheder ønsker ofte, at en person skal være opmærksom, før han tager det ekstraordinære skridt at flytte til et backup-datacenter. Bare husk på, at hvis du vil automatisere afbrydelsen, har du enten brug for et tredje datacenter, for at kvorum giver mening (enten direkte eller gennem en dommer), eller du vil finde en måde, hvorpå du pålideligt kan lukke alle dataene ned. centrum.
Kilde: www.habr.com