Hei, Habr! Jeg presenterer for din oppmerksomhet en oversettelse av artikkelen av Andrew Beekhof.
Mange foretrekker to-node-klynger fordi de virker konseptuelt enklere og er også 33 % billigere enn sine tre-node-motparter. Selv om det er fullt mulig å sette sammen en god klynge av to noder, vil en slik konfigurasjon i de fleste tilfeller, på grunn av uoverveide scenarier, skape mange uopplagte problemer.
Det første trinnet for å lage et system med høy tilgjengelighet er å finne og forsøke å eliminere individuelle feilpunkter, ofte forkortet som SPoF (single point of failure).
Det er verdt å huske på at det er umulig å eliminere alle mulige risikoer for nedetid i ethvert system. Dette stammer fra det faktum at et typisk forsvar mot risiko er å innføre noe redundans, noe som fører til økt systemkompleksitet og fremveksten av nye feilpunkter. Derfor inngår vi først et kompromiss og fokuserer på hendelser knyttet til individuelle feilpunkter, og ikke på kjeder av relaterte og derfor stadig mindre sannsynlige hendelser.
Gitt avveiningene ser vi ikke bare etter SPoF, men balanserer også risikoer og konsekvenser, som et resultat av at konklusjonen om hva som er kritisk og hva som ikke er det kan variere for hver distribusjon.
Ikke alle trenger alternative strømleverandører med uavhengige kraftledninger. Selv om paranoiaen lønnet seg for minst én kunde da overvåkingen deres oppdaget en defekt transformator. Kunden ringte for å varsle kraftselskapet til den defekte transformatoren eksploderte.
Et naturlig utgangspunkt er å ha mer enn én node i systemet. Men før systemet kan flytte tjenester til den overlevende noden etter en feil, må det generelt sørge for at tjenestene som flyttes ikke er aktive andre steder.
Det er ingen ulemper med en to-node-klynge hvis en feil resulterer i at begge nodene betjener det samme statiske nettstedet. Ting endres imidlertid hvis resultatet er at begge parter uavhengig administrerer en delt jobbkø eller gir ukoordinert skrivetilgang til en replikert database eller delt filsystem.
Derfor, for å forhindre datakorrupsjon som følge av en enkelt nodefeil - stoler vi på noe som heter "dissosiasjon" (gjerde).
Dissosiasjonsprinsippet
I hjertet av dissosiasjonsprinsippet er spørsmålet: kan en konkurrerende node forårsake datakorrupsjon? I tilfelle datakorrupsjon er et sannsynlig scenario, vil en god løsning være å isolere noden fra både innkommende forespørsler og vedvarende lagring. Den vanligste tilnærmingen til frakobling er å koble fra de defekte nodene.
Det er to kategorier av dissosiasjonsmetoder, som jeg vil kalle rett и indirekte, men de kan også kalles aktiv и passiv. Direkte metoder inkluderer handlinger fra overlevende jevnaldrende, for eksempel interaksjon med en IPMI (Intelligent Platform Management Interface) eller iLO (en mekanisme for å administrere servere i fravær av fysisk tilgang til dem), mens indirekte metoder er avhengige av den mislykkede node for på en eller annen måte å gjenkjenne at den er i en usunn tilstand (eller i det minste hindre andre medlemmer i å komme seg) og signalisere om behovet for å koble fra den mislykkede noden.
Quorum hjelper når du bruker både direkte og indirekte metoder.
Direkte dissosiasjon
Ved direkte dissosiasjon kan vi bruke quorum for å forhindre dissosiasjonsløp ved nettverkssvikt.
Med quorum-konseptet er det nok informasjon i systemet (selv uten å koble til dets likemenn) til at noder automatisk kan vite om de skal sette i gang dissosiasjon og/eller gjenoppretting.
Uten et quorum vil begge sider av et nettverksskille med rette anta at den andre siden er død og vil forsøke å skille den andre fra hverandre. I verste fall klarer begge parter å stenge ned hele klyngen. Et alternativt scenario er en deathmatch, en endeløs løkke av noder som gyter, ikke ser sine jevnaldrende, starter dem på nytt og starter gjenoppretting bare for å starte på nytt når jevnaldrende følger samme logikk.
Problemet med frakobling er at de mest brukte enhetene blir utilgjengelige på grunn av de samme feilhendelsene som vi ønsker å målrette for gjenoppretting. De fleste IPMI- og iLO-kort er installert på vertene de kontrollerer og bruker som standard det samme nettverket, noe som får målvertene til å tro at andre verter er frakoblet.
Dessverre blir driftsfunksjonene til IPMI- og iLo-enheter sjelden vurdert på tidspunktet for utstyrskjøp.
Indirekte dissosiasjon
Quorum er også viktig for å håndtere indirekte disassosiasjon; hvis det gjøres riktig, kan quorum tillate overlevende å anta at tapte noder vil gå over til en sikker tilstand etter en viss tidsperiode.
Med denne konfigurasjonen tilbakestilles maskinvarens overvåkningstidtaker hvert N sekund hvis quorumet ikke går tapt. Hvis tidtakeren (vanligvis flere multipler av N) utløper, utfører enheten en usmakelig avslåing (ikke avstengning).
Denne tilnærmingen er veldig effektiv, men uten et quorum er det ikke nok informasjon i klyngen til å administrere den. Det er ikke lett å se forskjellen mellom et nettverksbrudd og en nodefeil. Grunnen til at dette er viktig er at uten evne til å skille mellom de to tilfellene, er du tvunget til å velge samme oppførsel i begge tilfeller.
Problemet med å velge én modus er at det ikke er noen handling som maksimerer tilgjengeligheten og forhindrer tap av data.
- Hvis du velger å anta at en node node er aktiv, men faktisk mislykkes, vil klyngen unødvendig stoppe tjenester som kjører for å kompensere for tap av tjenester fra den mislykkede noden.
- Hvis du bestemmer deg for å anta at en node er nede, men det var bare en nettverksfeil og faktisk den eksterne noden er funksjonell, så registrerer du deg i beste fall for en fremtidig manuell avstemming av de resulterende datasettene.
Uansett hvilken heuristikk du bruker, er det trivielt å lage en feil som enten vil føre til at begge sider mislykkes eller få klyngen til å stenge de overlevende nodene. Å ikke bruke quorum fratar virkelig klyngen et av de kraftigste verktøyene i arsenalet.
Hvis det ikke er noe annet alternativ, er den beste tilnærmingen å ofre tilgjengelighet (her refererer forfatteren til CAP-teoremet). Høy tilgjengelighet av ødelagte data hjelper ingen, og det er heller ikke gøy å avstemme ulike datasett manuelt.
Quorum
Quorum høres bra ut, ikke sant?
Den eneste ulempen er at for å ha den i en klynge med N medlemmer, må du ha en forbindelse mellom N/2+1 av nodene dine igjen. Noe som ikke er mulig i en klynge med to noder etter at en node svikter.
Som til slutt bringer oss til det grunnleggende problemet med to noder:
Quorum gir ikke mening i to nodeklynger, og uten det er det umulig å pålitelig bestemme handlingsforløpet som maksimerer tilgjengeligheten og forhindrer tap av data
Selv i et system med to noder koblet sammen med en krysskabel, er det umulig å definitivt skille mellom et nettverksbrudd og en feil i den andre noden. Å deaktivere den ene enden (sannsynligheten for som selvfølgelig er proporsjonal med avstanden mellom nodene) vil være nok til å ugyldiggjøre enhver antakelse om at helsen til koblingen er lik helsen til partnernoden.
Få en to-node-klynge til å fungere
Noen ganger kan eller ønsker ikke klienten å kjøpe en tredje node, og vi blir tvunget til å se etter et alternativ.
Alternativ 1 - Duplisert dissosiasjonsmetode
En nodes iLO- eller IPMI-enhet representerer et feilpunkt fordi, hvis den svikter, kan overlevende ikke bruke den til å bringe noden til en sikker tilstand. I en klynge med 3 eller flere noder kan vi redusere dette ved å beregne quorum og bruke en maskinvarevakthund (en indirekte disassosiasjonsmekanisme, som diskutert tidligere). Når det gjelder to noder, må vi bruke nettverkskraftfordelingsenheter (PDUer) i stedet.
Etter en feil prøver den overlevende først å kontakte den primære disassosiasjonsenheten (innebygd iLO eller IPMI). Hvis dette lykkes, fortsetter utvinningen som vanlig. Bare hvis iLO/IPMI-enheten svikter får man tilgang til PDUen; hvis tilgangen er vellykket, kan gjenopprettingen fortsette.
Sørg for å plassere PDU-en på et annet nettverk enn klyngetrafikken, ellers vil en enkelt nettverksfeil blokkere tilgangen til begge frakoblingsenhetene og blokkere gjenopprettingen av tjenester.
Her kan du spørre - er PDU et enkelt feilpunkt? Hvilket svaret er, selvfølgelig er det.
Hvis denne risikoen er betydelig for deg, er du ikke alene: koble begge nodene til to PDUer og be om at klyngeprogramvaren skal bruke både når du slår nodene på og av. Klyngen forblir nå aktiv hvis en PDU dør, og en andre feil på enten den andre PDU-en eller IPMI-enheten vil være nødvendig for å blokkere gjenoppretting.
Alternativ 2 - Legge til en dommer
I noen scenarier, mens duplikatdisassosiasjonsmetoden er teknisk mulig, er den politisk vanskelig. Mange selskaper liker å ha et visst skille mellom administratorer og applikasjonseiere, og sikkerhetsbevisste nettverksadministratorer er ikke alltid begeistret for å dele PDU-tilgangsinnstillinger med noen.
I dette tilfellet er det anbefalte alternativet å opprette en nøytral tredjepart som kan supplere beslutningsdyktighetsberegningen.
I tilfelle en feil må en node være i stand til å se eteren til sin peer eller arbiter for å gjenopprette tjenester. Arbiteren inkluderer også en frakoblingsfunksjon hvis begge nodene kan se arbiteren, men ikke kan se hverandre.
Dette alternativet må brukes sammen med en indirekte adskillelsesmetode, for eksempel en maskinvare-watchdog-timer, som er konfigurert til å drepe en maskin hvis den mister forbindelsen til sin node og arbiter-node. Dermed kan en overlevende med rimelighet anta at dens peer-node vil være i en sikker tilstand etter at maskinvarens watchdog-timer utløper.
Den praktiske forskjellen mellom en arbiter og en tredje node er at en arbiter krever langt færre ressurser for å operere og kan potensielt betjene mer enn én klynge.
Alternativ 3 - Menneskelig faktor
Den endelige tilnærmingen er at overlevende skal fortsette å kjøre hvilke tjenester de allerede kjørte, men ikke starte nye før enten problemet løser seg selv (nettverksgjenoppretting, nodeomstart) eller en person tar ansvar for manuelt å bekrefte at den andre siden er død.
Bonusalternativ
Nevnte jeg at du kan legge til en tredje node?
To stativer
For argumentets skyld, la oss late som om jeg har overbevist deg om fordelene til den tredje noden, nå må vi vurdere det fysiske arrangementet av nodene. Hvis de er plassert (og drevet) i samme stativ, utgjør dette også SPoF, og en som ikke kan løses ved å legge til et ekstra stativ.
Hvis dette er overraskende, bør du vurdere hva som ville skje hvis et rack med to noder feilet, og hvordan den overlevende noden ville skille mellom det og en nettverksfeil.
Det korte svaret er at det ikke er mulig, og igjen har vi å gjøre med alle problemene i to-node-saken. Eller overlevende:
- ignorerer quorum og forsøker feilaktig å starte gjenoppretting under nettverksbrudd (muligheten til å fullføre dissosiasjon er en annen historie og avhenger av om PDU er involvert og om de deler strøm med noen av stativene), eller
- respekterer quorum og kobler fra seg selv for tidlig når dens node svikter
I alle fall er ikke to rack bedre enn ett, og nodene må enten motta uavhengige strømforsyninger eller fordeles på tre (eller flere, avhengig av hvor mange noder du har) rack.
To datasentre
På dette tidspunktet kan lesere som ikke lenger er risikovillige vurdere katastrofegjenoppretting. Hva skjer når en asteroide treffer det samme datasenteret med våre tre noder spredt over tre forskjellige stativer? Åpenbart dårlige ting, men avhengig av dine behov, kan det ikke være nok å legge til et ekstra datasenter.
Hvis det gjøres riktig, gir det andre datasenteret deg (og rimeligvis) en oppdatert og konsistent kopi av tjenestene dine og deres data. Men som i scenarier med to noder og to stativer, er det ikke nok informasjon i systemet til å sikre maksimal tilgjengelighet og forhindre korrupsjon (eller datasettavvik). Selv med tre noder (eller rack), vil distribusjon av dem over bare to datasentre gjøre at systemet ikke kan ta den riktige avgjørelsen på en pålitelig måte i tilfelle en (nå mye mer sannsynlig) hendelse som begge parter ikke kan kommunisere.
Dette betyr ikke at en dobbel datasenterløsning aldri er egnet. Bedrifter vil ofte at en person skal være oppmerksom før han tar det ekstraordinære skrittet å flytte til et backup-datasenter. Bare husk at hvis du vil automatisere strømbruddet, vil du enten trenge et tredje datasenter for at quorum skal gi mening (enten direkte eller gjennom en voldgiftsdommer), eller du vil finne en måte å pålitelig stenge ned alle dataene på senter.
Kilde: www.habr.com