Didelio prieinamumo kompiuterijos įvadas: sąvokos ir teorija

Susitelkime daugiau į kai kuriuos didesnius klasterių valdymo architektūros principus, nei į bet kurį atskirą technologinį sprendimą.

Kai kuriuos faktinius diegimus mes galime pamatyti vėliau knygoje - ir galite sužinoti daug apie tai, kaip tai veikia „Amazon“ AWS, mano „Learn Amazon Web Services“ knygoje „Pusdienių mėnuo“ iš „Manning“. Tačiau kol kas pirmiausia įsitikinkime, ar mums patiko pagrindai.

Serverio operacijų vykdymas naudojant fizinių ar virtualių kompiuterių sankaupas - tai patikimumo ir našumo pagerinimas, viršijant tai, ko galite tikėtis iš vieno didelio galingumo serverio. Pridėdami patikimumą, išvengsite visos infrastruktūros pakabinimo viename gedimo taške (ty viename serveryje). Našumą galite padidinti naudodamiesi galimybe labai greitai padidinti skaičiavimo galią ir talpą didinant ir mažinant.

Tai gali atsitikti protingai paskirstant savo darbo krūvį įvairiose geografinėse ir paklausos aplinkose (apkrovos balansavimas), teikiant

atsarginių kopijų serveriai, kuriuos galima greitai pradėti eksploatuoti tuo atveju, jei sugedęs veikiantis mazgas (perjungimas), optimizuojant duomenų paketo diegimo būdą arba leidžiant toleruoti gedimus naudojant laisvai sujungtas architektūras.

Mes prie viso to susipažinsime. Vis dėlto pirmiausia pateikiame keletą pagrindinių apibrėžimų:

Mazgas : viena mašina (fizinė ar virtuali), vykdanti serverį, veikia savarankiškai savo operacinėje sistemoje. Bet kuris vienas mazgas gali nepavykti, norint pasiekti pasiekiamumo tikslus reikia, kad keli mazgai veiktų kaip sankaupos dalis.

Klasteris : du ar daugiau serverio mazgų, veikiančių tarpusavyje derinant individualias užduotis kaip didesnės paslaugos dalį, kur abipusis supratimas leidžia vienam ar keliems mazgams kompensuoti kito praradimą.

Serverio gedimas : serverio mazgo nesugebėjimas tinkamai reaguoti į kliento užklausas. Taip gali nutikti dėl visiškos avarijos, ryšio problemų arba dėl to, kad ją užvaldė didelė paklausa.

Perkėlimas : būdas, kaip klasteris bando patenkinti klientų, kuriems našlaičiai liko dėl vieno serverio mazgo gedimo, poreikius, paleidžiant ar peradresuojant kitus mazgus, kad būtų užpildytas paslaugų trūkumas.

Perkėlimas : atsakomybės atkūrimas serverio mazge, kai jis atsistato po gedimo.

Replikacija : kritinių duomenų saugyklų kopijų kūrimas, kad būtų galima patikimai sinchroniškai pasiekti daugelį serverio mazgų ar klientų ir užtikrinti, kad jie išgyventų po nelaimių. Replikacija taip pat naudojama norint užtikrinti patikimą apkrovos balansavimą.

Perteklinis ryšys : kelių identiškų fizinių ar virtualių serverių mazgų, iš kurių bet kuris gali priimti našlaičius turinčius kito kliento klientus, nepavyksta.

Išskaidytos smegenys : klaidos būsena, kai tinklo ryšys tarp mazgų ar bendros saugyklos yra kažkaip sugedęs, o keli atskiri mazgai, manydami, kad tai vienintelis vis dar aktyvus mazgas, toliau naudojasi ir atnaujina bendrą duomenų šaltinį. Nors tai neturi įtakos „nieko nedalyvaus“ dizainams, tai gali sukelti kliento klaidų ir duomenų sugadinimą bendrose grupėse.

Tvoros : norint išvengti smegenų suskaidymo, „stonithd“ demonas gali būti sukonfigūruotas automatiškai išjungti netinkamai veikiantį mazgą arba įvesti virtualią tvorą tarp jo ir likusio klasterio duomenų išteklių. Kol yra tikimybė, kad mazgas vis tiek galėtų būti aktyvus, bet tinkamai nederina savo veiklos su likusia grupe, jis liks už tvoros. Stonith reiškia „Šaudyk kitą mazgą į galvą“. Tikrai taip.

Kvorumas : Galite sukonfigūruoti aptvarus (arba priverstinį išjungimą), kad jie būtų taikomi mazgams, kurie nebeturėjo kontakto vienas su kitu arba naudodamiesi bendrais ištekliais. Kvorumas dažnai apibrėžiamas kaip daugiau nei pusė visų mazgų visoje grupėje. Naudodamiesi tokiomis apibrėžtomis konfigūracijomis, išvengsite dviejų mazgų subklasterių, kurie tiki, kad vienas kitas veikia netinkamai, bandydami išjudinti kitą.

Nelaimė Atkurti y: Jūsų infrastruktūra vargu ar gali būti laikomi labai prieinama, jei jūs turite ne automatizuota atsarginę sistemą vietoje kartu su integruoto ir išbandyta atkūrimo planą. Jūsų plane reikės atsižvelgti į kiekvieno jūsų klasterio serverio perkėlimą.

Aktyvus / pasyvus klasteris

Paslaugos perjungimo idėja yra ta, kad staigų bet kurio vieno mazgo praradimą paslaugų klasteryje greitai kompensuotų kitas jo mazgas. Kad tai veiktų, peradresavimo atveju IP adresas automatiškai perkeliamas į budėjimo mazgą. Arba tinklo nukreipimo įrankiai, pvz., Apkrovos balansatoriai, gali būti naudojami srautui nukreipti nuo nepavykusių mazgų. Tikslus perjungimo būdas priklauso nuo to, kaip sukonfigūravote savo mazgus.

Iš pradžių tik vienas mazgas bus sukonfigūruotas aptarnauti klientus ir toliau tai darys vienas, kol jis kažkaip nepavyks. Tada atsakomybė už esamus ir naujus klientus bus perkelta į pasyvųjį arba atsarginį mazgą, kuris iki šiol buvo pasyviai saugomas. Taikant modelį keliems serveriams ar serverio kambario komponentams (pvz., Maitinimo šaltiniams), „n + 1“ atleidimas suteikia tik pakankamai išteklių dabartinei paklausai ir dar vieną įrenginį, kad padengtų gedimą.

Aktyvus / aktyvus klasteris

Klasteris, kuriame naudojamas aktyvus / aktyvus dizainas, turės du ar daugiau identiškai sukonfigūruotų mazgų, nepriklausomai aptarnaujančių klientus.

Jei vienas mazgas sugenda, jo klientai automatiškai prisijungia prie antrojo mazgo ir, kiek leidžia ištekliai, gauna visą prieigą prie išteklių.

Kai pirmasis mazgas atsigauna arba pakeičiamas, klientai vėl bus padalyti tarp abiejų serverio mazgų.

Pagrindinis aktyvių / aktyvių grupių vykdymo privalumas yra gebėjimas efektyviai subalansuoti mazgų ir net tinklų darbo krūvį. Apkrovos balansuotojas, nukreipiantis visas klientų užklausas į galimus serverius, yra sukonfigūruotas stebėti mazgų ir tinklo veiklą ir naudoti tam tikrą iš anksto nustatytą algoritmą, nukreipdamas srautą į tuos mazgus, kurie geriausiai jį tvarko. Maršrutavimo strategijos gali būti vykdomos pagal apipavidalinimo modelį, kai kliento užklausos tiesiog keičiamos tarp galimų mazgų, arba iš anksto nustatytu svoriu, kai vienas mazgas yra palankesnis už kitą tam tikru santykiu.

Pasyvus mazgas, veikiantis kaip atsarginis partnerio pakeitimas aktyvioje / pasyvioje klasterio konfigūracijoje, suteikia didelį integruotą perteklių. Jei jūsų operacijai būtinai reikalinga nenutrūkstama paslauga ir sklandūs perjungimo veiksmai, tada jūsų tikslas turėtų būti tam tikras aktyvios / pasyvios architektūros variantas.

„Shared-Nothing vs. Shared-Disk Cluster“

Vienas iš pagrindinių paskirstytojo skaičiavimo principų yra vengti, kad jūsų operacija atsiremtų į vieną gedimo tašką. Tai reiškia, kad kiekvienas išteklius turėtų būti aktyviai atkartojamas (nereikalingas) arba atskirai pakeičiamas (perjungimas), ir neturėtų būti vieno elemento, kurio gedimas galėtų sugadinti visą jūsų paslaugą.

Dabar įsivaizduokite, kad naudojate kelias dešimtis mazgų, kurie visi naudoja savo funkciją viename duomenų bazės serveryje. Nors bet kurio mazgo skaičiaus gedimas neturės įtakos tolesniam likusių mazgų sveikatai, jei duomenų bazė sumažėtų, visas klasteris taptų nenaudingas. Tačiau bendro nieko klasterio mazgai (paprastai) prižiūrės savo duomenų bazes, kad, darant prielaidą, kad jie yra tinkamai sinchronizuojami ir sukonfigūruoti, kad būtų užtikrintas nuolatinis operacijų saugumas, jokia išorinė gedimas jų nepaveiks.

Tai turės reikšmingesnį poveikį apkrovos subalansuotam klasteriui, nes kiekvienam apkrovos subalansuotam mazgui yra nuolatinis ir kritinis poreikis tuo pačiu metu pasiekti duomenis. Tačiau paprastos perjungimo sistemos pasyvusis mazgas gali išgyventi kurį laiką be prieigos.

Nors tokia sąranka gali sulėtinti klasterio atsakymą į kai kuriuos prašymus - iš dalies dėl to, kad baiminantis smegenų nesėkmių gali tekti periodiškai aptverti akmenis, kompromisas gali būti pateisinamas kritiškai svarbioms misijoms, kuriose pirmiausia reikia patikimumo.

Prieinamumas

Kurdami klasterį turėsite gana gerai suvokti, kaip tolerantiški galite būti nesėkmės. Arba, kitaip tariant, atsižvelgiant į žmonių ar mašinų, vartojančių jūsų paslaugas, poreikius, kiek laiko gali trukdyti paslaugos teikimas, kol minia išlįs pro jūsų priekinius vartus su šakėmis ir liepsnojančiais deglais. Svarbu tai žinoti, nes atleidimo iš darbo kiekis, kurį sukursite savo projekte, turės didžiulę įtaką prastovoms, su kuriomis galiausiai susidursite.

Akivaizdu, kad sistema, kurią sukuriate paslaugai, kuri gali sugesti savaitgaliui, niekam to nepastebint, labai skirsis nuo elektroninės prekybos svetainės, kurios klientai tikisi prieigos visą parą. Bent jau turėtumėte siekti bent 99% pasiekiamumo vidurkio - kai kurioms operacijoms reikia žymiai didesnių rezultatų realiame pasaulyje. 99% ilgesnis laikas reikštų, kad nuostolis būtų trumpesnis nei keturios dienos iš kiekvienų metų.

Yra gana paprasta formulė, kuria galite susikurti naudingą prieinamumo (A) įvertį. Idėja yra padalinti vidutinį laiką iki gedimo iš vidutinio laiko prieš gedimą ir vidutinį laiką, kurį reikia pataisyti.

A = MTBF / (MTBF + MTTR)

Kuo arčiau A reikšmės priartės prie 1, tuo labiau prieinamas bus jūsų klasteris. Norėdami gauti realią MTBF vertę, tikriausiai turėsite praleisti laiką, kad realiai sistemai būtų skirta rimta bausmė, ir atidžiai stebint, ar nėra programinės, aparatinės ir tinklo gedimų. Manau, kad taip pat turėtumėte sužinoti apie paskelbtą aparatūros pardavėjų ar didelių vartotojų, tokių kaip „Backblaze“, gyvavimo ciklo metriką, kad suprastumėte, kiek ilgai galima tikėtis stipriai naudojamos aparatūros.

MTTR bus laikas, kai klasteris užtruks sugedusio serverio mazgo funkcionalumą (procesas yra panašus į, nors ir ne identišką, atkūrimą po nelaimės, kurio pagrindinis tikslas yra greitai pakeisti sugedusią aparatūrą ir ryšį). Geriausia, jei tai būtų vertė, artima nuliui sekundžių.

Problema ta, kad realiame pasaulyje nežinomų kintamųjų paprastai yra per daug, kad ši formulė būtų tikrai tiksli, nes mazgai, kuriuose veikia skirtingos programinės įrangos konfigūracijos ir kurie pastatyti naudojant įvairaus profilio ir amžiaus aparatinę įrangą, gali tikėtis daugybės gyvenimo trukmės. Nepaisant to, tai gali būti gera priemonė, padedanti nustatyti klasterio dizainą, kuris geriausiai tinka jūsų projektui.

Turėdami šią informaciją galite lengvai suskaičiuoti, kiek bendro prastovos jūsų tarnyba gali tikėti per visus metus.

Susijęs svarstymas, jei jūs naudojate savo išteklius trečiosios šalies platformos teikėjui, pvz., „VMWare“ ar „Amazon Web Services“, yra tiekėjo paslaugų lygio sutartis (SLA). Pvz., „Amazon“ EC2 garantuoja, kad jų skaičiavimo egzemplioriai ir blokuoti parduotuvių saugojimo įrenginiai mėnesio darbo laiko procentą sudarys bent 99,95% - tai yra mažiau nei penkių valandų prastovos laikas per metus. AWS išduos kreditus tiems mėnesiams, per kuriuos jie nepasiekė savo tikslų - nors ir nepakankamai, kad kompensuotų visas jūsų prastovos verslo išlaidas. Turėdami šią informaciją galite susitarti dėl tokio lygio paslaugų, kuri atitiktų jūsų unikalius poreikius.

Natūralu, kad jums, kaip paslaugų teikėjui savo klientams, gali reikėti paskelbti savo SLA, remiantis jūsų MTBF ir MTTR įvertinimais.

Sesijos tvarkymas

Bet kokių serverio ir kliento santykių atveju būsenos HTTP sesijų sugeneruoti duomenys turi būti išsaugoti taip, kad jie būtų prieinami būsimai sąveikai. Klasterių architektūros gali sukelti šių ryšių sudėtingumo, nes konkretus serveris, su kuriuo klientas ar vartotojas sąveikauja, gali keistis iš vieno žingsnio į kitą.

Pavyzdžiui, įsivaizduokite, kad esate prisijungę prie „Amazon.com“, naršote jų knygas apie LPIC mokymus ir periodiškai pridedate elementą prie savo krepšelio (tikiuosi, daugiau šios knygos egzempliorių). Kai būsite pasirengę įvesti mokėjimo informaciją ir išsiregistruoti, serverio, kurį naudojote naršyti, gali net nebebūti. Kaip dabartinis jūsų serveris sužinos, kurias knygas nusprendėte įsigyti?

Aš tiksliai nežinau, kaip „Amazon“ tai elgiasi, tačiau problema dažnai sprendžiama naudojant duomenų replikavimo įrankį, pvz.,

išorinis mazgas (ar mazgai). Tikslas yra suteikti nuolatinę prieigą prie patikimo ir nuoseklaus duomenų šaltinio visiems mazgams, kuriems to gali prireikti.

Šis straipsnis pritaikytas skyrelyje Mokykite save„ Linux “virtualizavimo ir didelio prieinamumo: pasiruoškite LPIC-3 304 sertifikavimo egzaminui “. Peržiūrėkite kitas mano knygas apie AWS ir „Linux“ administravimą , įskaitant „ Linux in Action“ ir „ Linux in Motion“  - hibridinį kursą, kurį sudaro daugiau nei dviejų valandų vaizdo įrašai ir apie 40% „Linux in Action“ teksto.