Sissejuhatus kõrge kättesaadavusega arvutustesse: mõisted ja teooria

Keskendume rohkem mõnele klastrihalduse suuremale arhitektuuriprintsiibile kui ühele üksikule tehnoloogilisele lahendusele.

Mõningaid tegelikke rakendusi näeme hiljem raamatus - ja selle kohta, kuidas see Amazoni AWS-is töötab, saate palju teada saada Mannoni raamatust Learn Amazon Web Services. Kuid praegu veendume kõigepealt, et põhitõed oleksid meile mugavad.

Serveritoimingute käitamine kas füüsiliste või virtuaalsete arvutite klastrite abil on nii usaldusväärsuse kui ka jõudluse parandamine lisaks sellele, mida võiksite oodata ühelt suure võimsusega serverilt. Usaldusväärsust lisate, vältides kogu infrastruktuuri riputamist ühte rikkepunkti (st ühte serverisse). Ja saate suurendada jõudlust tänu võimalusele kiiresti ja kiiresti suurendada arvutusvõimsust ja -võimsust.

See võib juhtuda, kui jaotate oma töökoormused arukalt erinevate geograafiliste ja nõudluskeskkondade vahel (koormuse tasakaalustamine)

varuserverid, mida saab kiiresti kasutusele võtta juhul, kui töötav sõlm ebaõnnestub (tõrkeotsing), optimeerides teie andmetasandi juurutamist või võimaldades tõrketaluvust lõdvalt ühendatud arhitektuuride kaudu.

Me jõuame selle kõigeni. Esiteks on siin mõned põhimõisted:

Sõlm : üks masin (kas füüsiline või virtuaalne), mis töötab serveris, töötab iseseisvalt oma opsüsteemis. Kuna ükski sõlm võib ebaõnnestuda, nõuab kättesaadavuseesmärkide täitmine, et klastri osana toimiks mitu sõlme.

Klaster : kaks või enam serverisõlme, mis töötavad üksteisega kooskõlastatult üksikute ülesannete täitmiseks suurema teenuse osana, kus vastastikune teadlikkus võimaldab ühel või mitmel sõlmel kompenseerida teise kaotust.

Serveri tõrge : serverisõlme võimetus kliendi päringutele piisavalt reageerida. Selle põhjuseks võib olla täielik krahh, ühenduvusprobleemid või see, et seda on valdav suur nõudlus.

Tõrkesiirde : viis, kuidas klaster püüab rahuldada klientide vajadusi, mis on jäänud ühe serverisõlme tõrke tõttu orvuks, käivitades või suunates muud sõlmed teeninduslünga täitmiseks.

Tagasitulek : vastutuse taastamine serverisõlmele, kui see taastub tõrkest.

Replikatsioon : kriitiliste andmehoidlate koopiate loomine, et võimaldada usaldusväärset sünkroonset juurdepääsu mitmelt serverisõlmelt või kliendilt ja tagada nende katastroofide üleelamine. Replikatsiooni kasutatakse ka koormuse usaldusväärse tasakaalustamise võimaldamiseks.

Koondamine : mitmete identsete füüsiliste või virtuaalserverite sõlmede pakkumine, millest igaüks võib vastu võtta teise nurjunud kliendi.

Jagatud aju : veaolek, kus võrguside sõlmede või jagatud salvestusruumide vahel on kuidagi katki läinud ja mitu üksikut sõlme, mis usuvad, et see on ainus aktiivne sõlm, jätkavad juurdepääsu ühisele andmeallikale ja ajakohastavad seda. Ehkki see ei mõjuta jagatud mitte millegi kujundusi, võib see põhjustada ühiste klastrite klientide vigu ja andmete rikkumist.

Vehklemine : Et vältida split ajus stonithd deemon saab seadistada automaatselt sulgeda rikkis sõlme või kehtestada virtuaalne tara vahel seda ja andmete ressursside ülejäänud kogumile. Niikaua kui on võimalus, et sõlm võiks endiselt olla aktiivne, kuid ei koordineeri ülejäänud klastriga korralikult, jääb see aia taha. Stonith tähistab “Tulista teine ​​sõlm pähe”. Tõesti.

Kvoorum : saate konfigureerida tara (või sundseiskamise), mis kehtestatakse sõlmedele, mis on omavahel või mõne jagatud ressursiga kontaktist välja kukkunud. Kvoorum on sageli määratletud kui üle poole kogu klastri kõigist sõlmedest. Selliste määratletud konfiguratsioonide kasutamisel väldite kahte sõlmede alamklastrit, kumbki usub, et teine ​​ei tööta korralikult, püüdes teist välja lüüa.

Katastroofi taastamine : teie infrastruktuuri ei saa vaevalt pidada ülimalt kättesaadavaks, kui teil pole ühtegi automaatset varundamissüsteemi koos integreeritud ja testitud katastroofide taastamise kavaga. Teie plaan peab arvestama kõigi teie klastri serverite ümberpaigutamisega.

Aktiivne / passiivne klaster

Teenuse tõrkeotsingu idee seisneb selles, et teenuseklastri ühe sõlme ootamatu kadumise korvaks kiiresti teine ​​selle asemele astuv sõlm. Selle toimimiseks teisaldatakse tõrkeotsingu korral IP-aadress automaatselt ootesõlme. Teise võimalusena saab liikluse ümbersuunamiseks ebaõnnestunud sõlmedest kasutada võrgu marsruutimisvahendeid, näiteks koormuse tasakaalustajaid. Tõrkesiire täpne viis sõltub sõlmede konfigureerimisest.

Esialgu konfigureeritakse ainult üks sõlm klientide teenindamiseks ja jätkab seda üksi, kuni see kuidagi ebaõnnestub. Seejärel nihkub vastutus olemasolevate ja uute klientide eest (st "failover") passiivsele või varundussõlmele, mida seni on passiivselt reservis hoitud. Rakendades mudelit mitmele serverile või serveriruumi komponendile (näiteks toiteplokid), annab n + 1 koondamine praeguse nõudluse jaoks lihtsalt piisavalt ressursse ja veel ühe seadme, et katta rike.

Aktiivne / aktiivne klaster

Aktiivset / aktiivset kujundust kasutaval klastril on kaks või enam identse konfiguratsiooniga sõlme, mis teenindavad kliente iseseisvalt.

Kui üks sõlm ebaõnnestub, loovad selle kliendid automaatselt ühenduse teise sõlmega ja saavad ressurssidele täieliku juurdepääsu, kui ressursid seda võimaldavad.

Kui esimene sõlm on taastunud või asendatud, jagatakse kliendid taas mõlema serverisõlme vahel.

Aktiivsete / aktiivsete klastrite käitamise peamine eelis seisneb võimes sõlmede ja isegi võrkude töökoormust tõhusalt tasakaalustada. Koormuse tasakaalustaja - mis suunab kõik klientide päringud saadaolevatesse serveritesse - on konfigureeritud jälgima sõlmede ja võrgu tegevust ning kasutama mõnda etteantud algoritmi liikluse suunamiseks nendesse sõlmedesse, mis seda kõige paremini suudavad. Marsruutimispõhimõtted võivad järgida ringjoone mustrit, kus kliendi taotlused vahelduvad lihtsalt saadaolevate sõlmede vahel või eelseadistatud kaaluga, kus ühte sõlme eelistatakse teise suhtes mõne suhtega.

Kui passiivne sõlm toimib aktiivse / passiivse klastri konfiguratsioonis oma partneri jaoks ooterežiimina, annab see sisseehitatud märkimisväärse koondamise. Kui teie operatsioon nõuab tingimata katkematut teenust ja tõrgeteta tõrkeülekandeid, peaks teie eesmärk olema aktiivse / passiivse arhitektuuri variatsioon.

Jagatud-miski vs jagatud-ketta klastrid

Hajutatud arvutustehnika üks juhtpõhimõtteid on vältida seda, et teie operatsioon toetuks ühele rikkepunktile. See tähendab, et iga ressurss peaks olema kas aktiivselt paljundatud (üleliigne) või iseseisvalt asendatav (tõrkeotsing) ning ei tohiks olla ühtegi elementi, mille tõrge võiks kogu teie teenuse alla tuua.

Kujutage nüüd ette, et teil töötab mõnikümmend sõlme, mis kõik toetuvad oma funktsioonide jaoks ühele andmebaasiserverile. Kuigi ükskõik millise arvu sõlmede tõrge ei mõjuta nende sõlmede tervist, kui andmebaas peaks langema, muutub kogu klaster kasutuks. Jagatud-mitte-klastri sõlmed hoiavad (tavaliselt) oma andmebaase nii, et eeldades, et need on korralikult sünkroonitud ja konfigureeritud jooksva tehingute ohutuse huvides, ei mõjuta neid ükski väline rike.

Sellel on koormuse tasakaalustatud klastrile olulisem mõju, kuna igal koormuse tasakaalustatud sõlmel on pidev ja kriitiline vajadus andmetele üheaegse juurdepääsu järele. Lihtsa tõrkeülekandesüsteemi passiivne sõlm võib siiski mõnda aega ilma juurdepääsuta üle elada.

Kuigi selline seadistamine võib aeglustada klastri reageerimist mõnele taotlusele - osaliselt seetõttu, et hirm aju jagunemiste pärast võib vajada perioodilist tara kivide kaudu -, võib kompromiss olla õigustatud missioonikriitiliste juurutamiste puhul, kus esmatähtis on usaldusväärsus.

Saadavus

Klastri kujundamisel peate mõistma üsna hästi, kui tolerantne võite olla ebaõnnestumiste suhtes. Või teisisõnu, kui võtta arvesse teie teenuseid tarbivate inimeste või masinate vajadusi, siis kui kaua võib teenuse katkestus kesta enne, kui rahvahulk tuleb teie kahvlite ja leegitsevate tõrvikutega teie esiväravatest läbi. Seda on oluline teada, sest teie disaini sisseehitatud koondamiste arv mõjutab tohutult seisakuid, millega te lõpuks kokku puutute.

Ilmselt erineb süsteem, mille ehitate teenuse jaoks, mis võib nädalavahetuseks käia, ilma et keegi seda märkaks, väga erinev e-kaubanduse saidist, mille kliendid ootavad juurdepääsu ööpäevaringselt ööpäevaringselt. Vähemalt peaksite üldiselt püüdma kättesaadavuse keskmisele vähemalt 99% -le - mõned toimingud nõuavad reaalses maailmas oluliselt kõrgemaid tulemusi. 99% ületamise aeg tähendaks kaotust vähem kui neli päeva aastas.

Saadavaloleku (A) kasuliku hinnangu koostamiseks on suhteliselt lihtne valem. Idee on jagada keskmine aeg enne ebaõnnestumist keskmise ajaga enne ebaõnnestumist pluss keskmine aeg parandamiseks.

A = MTBF / (MTBF + MTTR)

Mida lähemale jõuab A väärtus väärtusele 1, seda paremini saadaval on teie klaster. MTBF-i jaoks realistliku väärtuse saamiseks peate tõenäoliselt veetma aega, paljastades reaalsele süsteemile tõsise karistuse ja jälgides seda hoolikalt tarkvara, riistvara ja võrgutõrgete suhtes. Oletan, et võiksite uurida ka riistvaramüüjate või selliste suuremahuliste tarbijate nagu Backblaze avaldatud olelusringi mõõdikuid, et saada ülevaade sellest, kui kaua eeldatavasti tugevalt kasutatud riistvara kestab.

MTTR on selle toote tulemus, mis kulub teie klastril ebaõnnestunud serverisõlme funktsionaalsuse asendamiseks (protsess sarnaneb, ehkki pole identne katastroofi taastamisega - mis keskendub ebaõnnestunud riistvara ja ühenduvuse kiirele asendamisele). Ideaalis oleks see väärtus nullilähedane kui võimalik.

Probleem on selles, et reaalses maailmas on selle valemi tõeliselt täpseks tegemiseks liiga palju tundmatuid muutujaid, kuna erinevatel tarkvarakonfiguratsioonidel töötavatel ning erineva profiili ja vanusega riistvaraga ehitatud sõlmedel on eeldatav eluiga lai. Sellest hoolimata võib see olla hea tööriist, mis aitab teil tuvastada teie projektile sobivaima klastri kujunduse.

Selle teabe abil saate hõlpsalt koostada hinnangu selle kohta, kui suur on teie teenuse seisakuid kogu aasta jooksul tõenäoline.

Seotud kaalutlus, kui paigutate oma ressursse kolmanda osapoole platvormi pakkujale, näiteks VMWare või Amazon Web Services, on pakkuja teenustaseme leping (SLA). Näiteks garanteerib Amazoni EC2, et nende arvutuseksemplarid ja plokkide salvestusseadmed tagavad igakuise kasutusaja protsendi vähemalt 99,95% - see on vähem kui viie tunni tööaeg aastas. AWS väljastab krediiti kuude jooksul, mille jooksul nad oma eesmärke ei täitnud, ehkki mitte peaaegu nii palju, et kompenseerida teie seisakuid. Selle teabe abil saate korraldada teenuse koondamise taseme, mis sobib teie ainulaadsete vajadustega.

Loomulikult peate oma klientide teenusepakkujana võib-olla oma MTBF-i ja MTTR-i hinnangute põhjal avaldama oma SLA.

Seansside haldamine

Mis tahes serveri ja kliendi suhte puhul tuleb olekuliste HTTP-seansside abil genereeritud andmed salvestada viisil, mis muudab need edaspidisteks interaktsioonideks kättesaadavaks. Klastriarhitektuurid võivad neid suhteid tõsiselt keerukamaks muuta, kuna konkreetne server, millega klient või kasutaja suhtleb, võib ühe ja teise vahel muutuda.

Näiteks illustreerige, et olete sisse loginud saidile Amazon.com, sirvite nende LPIC-koolituse raamatuid ja lisate perioodiliselt üksuse oma ostukorvi (loodetavasti rohkem selle raamatu eksemplare). Selleks ajaks, kui olete oma makseteabe sisestamiseks ja väljaregistreerimiseks valmis, ei pruugi serverit, mida sirvisite, enam isegi olemas olla. Kuidas saab teie praegune server teada, milliseid raamatuid otsustasite osta?

Ma ei tea täpselt, kuidas Amazon sellega tegeleb, kuid probleemi lahendatakse sageli andmete replikatsiooni tööriista kaudu, näiteks

väline sõlm (või sõlmed). Eesmärk on pakkuda pidevat juurdepääsu usaldusväärsele ja järjepidevale andmeallikale igale sõlmele, kes seda võib vajada.

See artikkel on kohandatud jaotisest Õpeta ise Linuxi virtualiseerimine ja kõrge kättesaadavus: valmistuge LPIC-3 304 sertifitseerimise eksamiks “. Vaadake minu teisi raamatuid AWS-i ja Linuxi administreerimise kohta , sealhulgas Linux in Action ja Linux in Motion  - hübriidkursus, mis koosneb rohkem kui kahest tunnist videot ja umbes 40% Linux in Actioni tekstist.