Hej, Habr! Jeg præsenterer for jer oversættelsen af artiklen forfatter Andrew Beekhof.
Mange mennesker foretrækker klynger bestående af to noder, fordi de virker konceptuelt mere enkle, og de er også 33% billigere end deres tre-node søskende. Selvom det er muligt at samle en god klynge af to noder, vil det i de fleste tilfælde skabe mange uventede problemer på grund af ikke-overvejede scenarier.
Det første skridt mod at skabe et system med høj tilgængelighed er at finde og forsøge at fjerne enkeltpunkter for fejl, ofte forkortet som SPoF (single point of failure).
Det er værd at bemærke, at det i ethvert system er umuligt at eliminere alle mulige nedetidsrisici. Dette skyldes i det mindste det faktum, at den typiske løsning på risiko er at indføre en vis redundans, hvilket fører til øget kompleksitet i systemet og skabelsen af nye fejlmuligheder. Derfor går vi oprindeligt ind på et kompromis og fokuserer på begivenheder relateret til enkeltpunkter for fejl fremfor kæder af relaterede og derfor færre sandsynlige begivenheder.
I betragtning af kompromiserne søger vi ikke kun SPoF, men afvejer også risici og konsekvenser, hvilket resulterer i, at hvad der er kritisk, og hvad der ikke er, kan variere for hver implementering.
Ikke alle har brug for alternative energileverandører med uafhængige strømlinjeforbindelser. Selvom paranoiaen betalte sig for i det mindste én kunde, da deres overvågning opdagede en defekt transformer. Kunden ringede for at advare energiselskabet, indtil den defekte transformer eksploderede.
Et naturligt udgangspunkt er at have mere end én node i systemet. Men før systemet kan flytte tjenesterne til den overlevende node efter et nedbrud, er det generelt nødvendigt at sikre, at de flyttede tjenester ikke er aktive et andet sted.
En to-node klynge har ikke ulemper, hvis begge noder servicerer den samme statiske hjemmeside som følge af en nedbrud. Men alt ændrer sig, hvis begge sider uafhængigt håndterer en delt jobkø eller giver ukontrolleret skriveadgang til en replikeret database eller et delt filsystem.
For at forhindre datatab som følge af én nodes svigt, stoler vi på noget, der kaldes »afspærring« (fencing).
Afspærringsprincip
I bunden af afspærringsprincippet ligger spørgsmålet: Kan en konkurrerende node forårsage datatab? I tilfælde af, at datatab er et sandsynligt scenarie, vil en god løsning være at isolere noden fra både indkommende forespørgsler og det permanente lager. Den mest almindelige tilgang til afspærring er at slukke for de defekte noder.
Der er to kategorier af afspærringsmetoder, som jeg vil kalde direkte og indirekte, men de kan ligesåvel kaldes aktive og passive. Direkte metoder involverer handlinger fra de overlevende peer-noder, såsom interaktion med en IPMI-enhed (Intelligent Platform Management Interface – interface til fjernovervågning og -styring af serverens fysiske tilstand) eller iLO (styringsmekanisme for servere uden fysisk adgang til dem), mens indirekte metoder er afhængige af den mislykkede node til på en eller anden måde at registrere, at den er i en usund tilstand (eller i det mindste forstyrrer de andre medlemmer i deres genopretning) og signalere om nødvendigheden af at slukke for den mislykkede node.
Kvote hjælper i tilfælde af brug af både direkte og indirekte metoder.
Direkte afspærring
I tilfældet med direkte afspærring kan vi bruge kvote til at forhindre afspærringslænge i tilfælde af netværkssvigt.
Ved hjælp af konceptet kvote har systemet tilstrækkelig information (selv uden forbindelse til sine partnere) til, at noder automatisk kan vide, om de skal igangsætte afspærring og/eller genopretning.
Uden kvote antager begge sider af netværksopdelingen med rette, at den anden side er død, og vil stræbe efter at afspærre den anden. I værste fald formår begge sider at slukke hele klyngen. Et alternativt scenarie er deathmatch, en uendelig cyklus af noder, der genstarter, ikke ser deres peers, genstarter dem og igangsætter genopretning, kun for at genstarte, når deres peer følger den samme logik.
Problemet med afgrænsning er, at de mest brugte enheder ofte bliver utilgængelige på grund af de samme fejl, som vi ønsker at basere genopretningen på. De fleste IPMI- og iLO-kort er installeret på de værter, de kontrollerer, og som standard bruger de det samme netværk, hvilket får de målrettede noder til at tro, at de andre noder er offline.
Desværre bliver egenskaberne ved IPMI- og iLo-enheder sjældent overvejet i købsøjeblikket.
Indirect afgrænsning
Kvorum er også vigtigt for styringen af indirekte afgrænsninger; hvis alt gøres korrekt, kan kvorum give de overlevende mulighed for at antage, at de tabte noder vil gå i en sikker tilstand efter en vis periode.
I denne opsætning nulstilles hardware watchdog timeren hvert N-sekund, hvis kvorummet ikke er mistet. Hvis timeren (normalt nogle gange N) udløber, udfører enheden en ukorrekt strømafbrydelse (ikke shutdown).
Denne tilgang er meget effektiv, men uden kvorum til at styre den er der ikke nok information i klyngen. Det er ikke let at skelne mellem netværksafbrydelse og fejl på partnernoden. Årsagen til, at dette er vigtigt, er, at uden evnen til at skelne mellem de to tilfælde er du nødt til at vælge den samme adfærd i begge situationer.
Problemet med at vælge én tilstand er, at der ikke findes en handlingsplan, der maksimalt øger tilgængeligheden og forhindrer tab af data.
- Hvis du beslutter dig for at antage, at partnernoden er aktiv, men der faktisk er sket en fejl, vil klyngen unødigt stoppe de tjenester, der skulle have kørt for at kompensere for tabet af tjenesteydelserne fra den nede partnernode.
- Hvis du beslutter dig for at antage, at noden ikke fungerer, men det kun var en netværksfejl, og den fjerne node faktisk fungerer, så tilmelder du dig i bedste fald en fremtidig manuel sammenligning af de resulterende datasæt.
Uanset hvilken heuristik du bruger, er det trivielt at skabe en fejl, der enten får begge parter til at fungere eller får klyngen til at afbryde de overlevende noder. Manglende anvendelse af kvorum fratager virkelig klyngen et af de mest kraftfulde værktøjer i dets arsenal.
Hvis der ikke er nogen anden mulighed, vil den bedste tilgang være at ofre tilgængelighed (her henviser forfatteren til CAP-teoremet). Høj tilgængelighed af beskadigede data hjælper ingen, og manuel validering af forskellige datasæt er heller ikke fornøjeligt.
Kvote
Kvote lyder godt, ikke?
Den eneste ulempe er, at for at have det i en klynge med N medlemmer, skal der være forbindelse mellem N / 2 + 1 af dine noder. Det er umuligt i en klynge med to noder efter en fejlfunktion af en node.
Dette bringer os til det fundamentale problem med to noder:
kvote giver ikke mening i klynger med to noder, og uden det er det umuligt at afgøre, hvilken handling der maksimalt øger tilgængeligheden og forhindrer datatab
Selv i et system af to noder forbundet med et krydskabel, er det umuligt at skelne klart mellem netværksafbrydelse og fejlfunktion af den anden node. Afbrydelse af den ene ende (hvis sandsynligheden for dette bestemt er proportional med afstanden mellem noderne) vil være tilstrækkeligt til at modbevise enhver antagelse om, at kanalen fungerer ligesom sundheden af partnernoden.
Får klyngen af to noder til at fungere
Nogle gange kan kunden ikke eller ønsker ikke at købe en tredje node, og vi er nødt til at lede efter et alternativ.
Mulighed 1 — Den duplikerende metode til omgåelse
iLO- eller IPMI-enheden på noden udgør et fejlpunkts, da resten ikke kan bruge den til at bringe noden i en sikker tilstand i tilfælde af fejlfunktion. I en klynge med 3 eller flere noder kan vi afbøde dette ved at beregne kvoten og bruge en hardware watchdog (indirekte omgåelsesmekanisme, som tidligere diskuteret). I tilfælde af to noder må vi i stedet bruge netværksstrømafbrydere (power distribution units eller PDUs).
Efter en fejlfunktion forsøger den overlevende først at kontakte det primære omgåelsesapparat (indbygget iLO eller IPMI). Hvis det lykkes, fortsætter genoprettelsen som vanligt. Kun hvis iLO / IPMI-enheden fejler, henvender man sig til PDU, og hvis henvendelsen er succesfuld, kan genoprettelsen fortsætte.
Sørg for at placere PDUen i et netværk adskilt fra clustertrafikken, da en enkelt netværksfejl ellers vil blokere adgangen til både udledningsenhederne og forhindre genopretning af tjenester.
Her kan du spørge - er PDU'en ikke et enkelt punkt af svigt? Svaret er - det er det bestemt.
Hvis denne risiko er betydelig for dig - er du ikke alene: tilslut begge noder til to PDU'er og angiv cluster-softwaren til at bruge begge ved opstart og nedlukning af noder. Nu forbliver clusteren aktiv, hvis en PDU svigter, og for at blokere genopretning kræves der et andet svigt, enten af den anden PDU eller IPMI-enheden.
Mulighed 2 - Tilføjelse af en dommer
I nogle scenarier, selvom en duplicerende udledningsmetode teknisk set er mulig, er den politisk kompleks. Mange virksomheder kan lide at have et klart skel mellem administratorer og applikationsejere, og sikkerhedsorienterede netværksadministratorer er ikke altid entusiastiske omkring at overdrage adgangen til PDU'en til nogen.
I dette tilfælde er den anbefalede alternativ at oprette en neutral tredje part, der kan supplere kvoteopgørelsen.
I tilfælde af svigt skal noden kunne se sin partner eller dommer for at genoprette tjenesterne. Dommeren inkluderer også en forbindelsesteknik, hvis begge noder kan se dommeren, men ikke ser hinanden.
Denne mulighed skal bruges sammen med en indirekte udledningsmetode, såsom en hardware watchdog-timer, der er indstillet til at slukke maskinen, hvis den mister forbindelsen til sin partner og dommer. På den måde kan den overlevende med rimelighed antage, at dens partner er i en sikker tilstand efter hardware watchdog-timerens udløb.
Den praktiske forskel mellem en dommer og en tredje node ligger i, at dommeren kræver væsentligt færre ressourcer for sin funktion og kan potentielt betjene mere end én cluster.
Mulighed 3 - Menneskelig faktor
Den sidste tilgang indebærer, at de overlevende fortsætter med at udføre enhver service, de allerede har udført, men ikke starter nye, indtil enten problemet løser sig selv (netværksgendannelse, genstart af noden), eller en person påtager sig ansvaret for manuelt at bekræfte, at den anden side er død.
Bonusmulighed
Har jeg allerede nævnt, at du kan tilføje en tredje node?
To skabe
For argumentets skyld, lad os forestille os, at jeg har overbevist dig om fordelene ved en tredje node. Nu skal vi overveje den fysiske placering af noderne. Hvis de er placeret (og får strøm) i samme skab, udgør det også en SPoF, og en som ikke kan løses ved at tilføje et andet skab.
Hvis det virker overraskende, så tænk over, hvad der vil ske, hvis skabet med to noder fejler, og hvordan den overlevende node vil skelne mellem denne situation og et netværksudfald.
Det korte svar: Det er umuligt, og vi har igen alle de problemer, der følger med to noder. Enten overlever:
- ignorerer kvorum og forsøger forkert at starte gendannelse under netværksafbrydelser (muligheden for at afslutte afskærmning er en anden historie og afhænger af, om PDU er involveret og deler strøm med nogen af skabene), eller
- respekterer kvorum og slukker for tidligt sig selv, når dens partner-node fejler.
I begge tilfælde er to skabe ikke bedre end ét, og noderne skal enten have uafhængige strømkilder eller fordeles over tre (eller flere, afhængigt af hvor mange noder du har) skabe.
To datacentre
Ved dette tidspunkt kan læsere, der ikke længere er tilbøjelige til risiko, begynde at tænke på katastrofegenopretning. Hvad sker der, når en asteroid rammer et datacenter med vores tre noder fordelt over tre forskellige skabe? Åbenlyst dårlige ting, men afhængigt af dine behov kan tilføjelsen af et andet datacenter vise sig at være utilstrækkelig.
Hvis alt er gjort korrekt, giver det andet datacenter dig (og det er fornuftigt) en aktuel og konsistent kopi af dine tjenester og deres data. Men som i scenarier med to noder og to stativer, har systemet ikke nok information til at sikre maksimal tilgængelighed og forhindre skade eller uoverensstemmelser i datasæt. Selv med tre noder (eller stativer) efterlader deres fordeling kun på to datacentre systemet ude af stand til pålideligt at træffe den rigtige beslutning i tilfælde af en hændelse (som nu er langt mere sandsynlig), som begge sider ikke kan forbinde.
Det betyder ikke, at en løsning med to datacentre aldrig er passende. Virksomheder ønsker ofte, at en person er opmærksom, før de tager det ekstraordinære skridt at skifte til et backup-datacenter. Bare husk, at hvis du ønsker at automatisere nedbrud, skal du enten have et tredje datacenter, så quorum giver mening (direkte eller via en mægler), eller finde en måde at afbryde hele datacentret på pålideligt.
Kilde: habr.com
