En introduktion til høj tilgængelighed computing: begreber og teori

Lad os fokusere mere på nogle af de større arkitektoniske principper for klyngestyring end på nogen enkelt teknologiløsning.

Vi får se nogle faktiske implementeringer senere i bogen - og du kan lære meget om, hvordan dette fungerer på Amazons AWS i min Learn Amazon Web Services i en måned med frokostbøger fra Manning. Men indtil videre, lad os først sørge for, at vi er komfortable med det grundlæggende.

At køre serveroperationer ved hjælp af klynger af enten fysiske eller virtuelle computere handler om at forbedre både pålidelighed og ydeevne ud over hvad man kunne forvente af en enkelt, kraftig server. Du tilføjer pålidelighed ved at undgå at hænge hele din infrastruktur på et enkelt fejlpunkt (dvs. en enkelt server). Og du kan øge ydeevnen gennem muligheden for meget hurtigt at tilføje computerkraft og kapacitet ved at skalere op og ud.

Dette kan ske ved intelligent spredning af dine arbejdsbelastninger blandt forskellige geografiske miljøer og efterspørgselsmiljøer (belastningsbalancering), hvilket giver

backup-servere, der hurtigt kan tages i brug i tilfælde af, at en fungerende knude fejler (failover), hvilket optimerer den måde, dit dataniveau er implementeret på, eller muliggør fejltolerance gennem løst koblede arkitekturer.

Vi kommer til alt det. For det første er der dog nogle grundlæggende definitioner:

Node : En enkelt maskine (enten fysisk eller virtuel), der kører serveroperationer uafhængigt af sit eget operativsystem. Da enhver enkelt node kan mislykkes, kræver opfyldelse af mål for tilgængelighed, at flere noder fungerer som en del af en klynge.

Klynge : To eller flere serverknudepunkter, der kører i koordination med hinanden for at udføre individuelle opgaver som en del af en større tjeneste, hvor gensidig bevidsthed tillader en eller flere noder at kompensere for tabet af en anden.

Serverfejl : Servernodens manglende evne til at reagere tilstrækkeligt på klientanmodninger. Dette kan skyldes et komplet nedbrud, forbindelsesproblemer eller fordi det er blevet overvældet af stor efterspørgsel.

Failover : Den måde, hvorpå en klynge forsøger at imødekomme behovene hos klienter, der er forældreløse, fordi en enkelt serverknude svigter ved at starte eller omdirigere andre noder for at udfylde et servicegap.

Failback : Gendannelse af ansvar over for en serverknudepunkt, når den gendanner efter en fejl.

Replikering : Oprettelse af kopier af kritiske datalagre for at tillade pålidelig synkron adgang fra flere serverknudepunkter eller klienter og for at sikre, at de overlever katastrofer. Replikering bruges også til at muliggøre pålidelig belastningsafbalancering.

Redundans : Tilvejebringelse af flere identiske fysiske eller virtuelle serverknudepunkter, som enhver kan vedtage forældreløse klienter til en anden, der fejler.

Split hjerne : En fejltilstand, hvor netværkskommunikation mellem noder eller delt lager på en eller anden måde er brudt ned, og flere individuelle noder, som hver især tror, ​​at det er den eneste node, der stadig er aktiv, fortsætter med at få adgang til og opdatere en fælles datakilde. Selvom dette ikke påvirker delte-intet design, kan det føre til klientfejl og datakorruption i delte klynger.

Hegn : For at forhindre split hjerne kan stonithd-dæmonen konfigureres til automatisk at lukke en funktionsfejl knude eller til at pålægge et virtuelt hegn mellem det og dataressourcerne for resten af ​​en klynge. Så længe der er en chance for, at noden stadig kan være aktiv, men ikke koordinerer korrekt med resten af ​​klyngen, forbliver den bag hegnet. Stonith står for ”Skyd den anden knude i hovedet”. Virkelig.

Kvorum : Du kan konfigurere hegn (eller tvungen nedlukning), der skal pålægges noder, der er faldet ud af kontakt med hinanden eller med en delt ressource. Quorum defineres ofte som mere end halvdelen af ​​alle knudepunkter i den samlede klynge. Ved hjælp af sådanne definerede konfigurationer undgår du at have to underklynger af noder, som hver især tror, ​​at den anden fungerer forkert, og forsøger at slå den anden ud.

Disaster Recover y: Din infrastruktur kan næppe betragtes som meget tilgængelig, hvis du ikke har noget automatisk backup-system på plads sammen med en integreret og testet katastrofegenoprettelsesplan. Din plan skal tage højde for omdisponering af hver af serverne i din klynge.

Aktiv / passiv klynge

Ideen bag servicefailover er, at det pludselige tab af en hvilken som helst node i en serviceklynge hurtigt ville blive kompenseret af en anden node, der indtager sin plads. For at dette skal fungere, flyttes IP-adressen automatisk til standby-noden i tilfælde af failover. Alternativt kan netværksrutingsværktøjer som belastningsbalancere bruges til at omdirigere trafik væk fra mislykkede noder. Den nøjagtige måde, failover sker på, afhænger af den måde, du har konfigureret dine noder på.

Kun en knude bliver oprindeligt konfigureret til at betjene klienter og vil fortsætte med at gøre det alene, indtil det på en eller anden måde fejler. Ansvaret for eksisterende og nye klienter skifter derefter (dvs. "failover") til den passive - eller backup - node, der indtil nu er blevet holdt passivt i reserve. Anvendelse af modellen på flere servere eller serverrumskomponenter (som strømforsyninger) giver n + 1 redundans lige nok ressourcer til den aktuelle efterspørgsel plus en enhed til at dække for en fejl.

Aktiv / aktiv klynge

En klynge, der bruger et aktivt / aktivt design, vil have to eller flere identisk konfigurerede noder, der uafhængigt betjener klienter.

Hvis en node mislykkes, vil dens klienter automatisk oprette forbindelse til den anden node og, så vidt ressourcerne tillader det, modtage fuld ressourceadgang.

Når den første node genopretter eller erstattes, vil klienterne igen blive delt mellem begge serverknudepunkter.

Den primære fordel ved at køre aktive / aktive klynger ligger i evnen til effektivt at afbalancere en arbejdsbyrde mellem noder og endda netværk. Belastningsbalanceren - som dirigerer alle anmodninger fra klienter til tilgængelige servere - er konfigureret til at overvåge node- og netværksaktivitet og bruge en forudbestemt algoritme til at dirigere trafik til de noder, der bedst kan håndtere den. Routing-politikker kan følge et round-robin-mønster, hvor klientanmodninger simpelthen veksles mellem tilgængelige noder eller med en forudindstillet vægt, hvor en node foretrækkes frem for en anden med noget forhold.

At have en passiv knude, der fungerer som standby-erstatning for sin partner i en aktiv / passiv klyngekonfiguration, giver betydelig indbygget redundans. Hvis din operation absolut kræver uafbrudt service og problemfri failover-overgange, så bør en variation af en aktiv / passiv arkitektur være dit mål.

Shared-Nothing vs. Shared-Disk Clusters

Et af de ledende principper for distribueret computing er at undgå, at din operation er afhængig af et enkelt fejlpunkt. Det vil sige, hver ressource skal enten replikeres aktivt (overflødig) eller udskiftes uafhængigt (failover), og der skal ikke være noget enkelt element, hvis fiasko kan bringe hele din service ned.

Forestil dig nu, at du kører et par dusin noder, der alle er afhængige af en enkelt databaseserver for deres funktion. Selvom svigt af et hvilket som helst antal knudepunkter ikke påvirker den fortsatte sundhed for de resterende knudepunkter, hvis databasen går ned, ville hele klyngen blive ubrugelig. Noder i en delt-intet-klynge vil dog (normalt) vedligeholde deres egne databaser, så - forudsat at de synkroniseres korrekt og konfigureres til løbende transaktionssikkerhed - ingen ekstern fejl vil påvirke dem.

Dette vil have en mere betydelig indvirkning på en belastningsafbalanceret klynge, da hver belastningsafbalanceret knude har et konstant og kritisk behov for samtidig adgang til dataene. Den passive knude på et simpelt failover-system kan dog muligvis overleve noget tid uden adgang.

Selvom en sådan opsætning måske bremser den måde, hvorpå klyngen reagerer på nogle anmodninger - dels fordi frygt for splittede hjernefejl muligvis kræver periodisk hegn gennem stonith - kan afvejen være berettiget til missionskritiske implementeringer, hvor pålidelighed er det primære overvejelse.

Tilgængelighed

Når du designer din klynge, skal du have en ret god fornemmelse af, hvor tolerant du kan være for fiasko. Eller med andre ord i betragtning af behovene hos de mennesker eller maskiner, der forbruger dine tjenester, hvor længe kan en serviceforstyrrelse vare, før mobben strømmer gennem dine forreste porte med pitchgafler og flammende fakler. Det er vigtigt at vide dette, fordi mængden af ​​redundans, du bygger ind i dit design, vil have en enorm indflydelse på de nedetid, du i sidste ende vil stå over for.

Det system, du bygger for en tjeneste, der kan gå ned i en weekend uden at nogen bemærker det, vil naturligvis være meget forskelligt fra et e-handelswebsted, hvis kunder forventer 24/7 adgang. I det mindste skal du generelt sigte mod et tilgængelighedsgennemsnit på mindst 99% - hvor nogle operationer kræver væsentligt højere resultater i den virkelige verden. 99% opetid svarer til et tab på mindre end i alt fire dage ud af hvert år.

Der er en relativt enkel formel, du kan bruge til at oprette et nyttigt skøn over tilgængelighed (A). Ideen er at opdele gennemsnitstid før fiasko med gennemsnitstid før fiasko plus middel tid til reparation.

A = MTBF / (MTBF + MTTR)

Jo tættere værdien på A kommer til 1, desto mere tilgængeligt vil din klynge være. For at opnå en realistisk værdi for MTBF bliver du sandsynligvis nødt til at bruge tid på at udsætte et ægte system for alvorlig straf og se nøje på software-, hardware- og netværksfejl. Jeg formoder, at du også kunne se de offentliggjorte livscyklusmålinger for hardwareleverandører eller store forbrugere som Backblaze for at få en idé om, hvor længe hårdt brugt hardware kan forventes at vare.

MTTR vil være et produkt af den tid, det tager din klynge at erstatte funktionaliteten af ​​en serverknude, der er mislykket (en proces, der ligner, men ikke er identisk med, katastrofegendannelse - som fokuserer på hurtigt at erstatte mislykket hardware og tilslutning). Ideelt set ville det være en værdi så tæt på nul sekunder som muligt.

Problemet er, at der i den virkelige verden normalt er alt for mange ukendte variabler til, at denne formel kan være virkelig nøjagtige, da noder, der kører forskellige softwarekonfigurationer og bygget med hardware i forskellige profiler og aldre, har en lang række forventede levealder. Ikke desto mindre kan det være et godt værktøj til at hjælpe dig med at identificere det klyngedesign, der passer bedst til dit projekt.

Med disse oplysninger kan du nemt generere et skøn over, hvor meget samlet nedetid din service sandsynligvis vil ske i løbet af et helt år.

En relateret overvejelse, hvis du distribuerer dine ressourcer til en tredjepartsplatformsudbyder som VMWare eller Amazon Web Services, er udbyderens serviceniveauaftale (SLA). Amazons EC2 garanterer for eksempel, at deres beregningsforekomster og blokeringslagerenheder leverer en månedlig oppetidsprocent på mindst 99,95% - hvilket er mindre end fem timers nedetid om året. AWS udsteder kreditter i måneder, hvor de gik glip af deres mål - dog ikke nær nok til at kompensere for de samlede forretningsomkostninger for din nedetid. Med disse oplysninger kan du arrangere et serviceniveau, der passer til dine unikke behov.

Som en tjenesteudbyder til dine egne kunder er du muligvis nødt til at offentliggøre din egen SLA baseret på dine MTBF- og MTTR-estimater.

Sessionshåndtering

For ethvert server-klientforhold skal de data, der genereres af stateful HTTP-sessioner, gemmes på en måde, der gør dem tilgængelige for fremtidige interaktioner. Klyngearkitekturer kan indføre alvorlig kompleksitet i disse forhold, da den specifikke server, som en klient eller bruger interagerer med, kan skifte mellem det ene trin og det næste.

For at illustrere, forestil dig at du er logget ind på Amazon.com, gennemse deres bøger om LPIC-træning og med jævne mellemrum tilføje en vare til din indkøbskurv (forhåbentlig flere eksemplarer af denne bog). På det tidspunkt, hvor du er klar til at indtaste dine betalingsoplysninger og tjekke ud, findes der muligvis ikke længere den server, du brugte til at gennemse. Hvordan ved din nuværende server, hvilke bøger du har besluttet at købe?

Jeg ved ikke nøjagtigt, hvordan Amazon håndterer dette, men problemet løses ofte gennem et datareplikeringsværktøj som memcached, der kører på en

ekstern node (eller noder). Målet er at give konstant adgang til en pålidelig og konsistent datakilde til enhver node, der muligvis har brug for den.

Denne artikel er tilpasset fra ” Teach Yourself Linux Virtualization and High Availability: prepare to the LPIC-3 304 certificeringseksamen ”. Tjek mine andre bøger om AWS og Linux-administration , inklusive Linux in Action og Linux in Motion  - et hybridkursus, der består af mere end to timers video og omkring 40% af teksten til Linux in Action.