Sveiki, Habr! Jūsų dėmesiui pristatau straipsnio vertimą pateikė Andrew Beekhofas.
Daugelis žmonių teikia pirmenybę dviejų mazgų klasteriams, nes jie atrodo konceptualiai paprastesni ir yra 33% pigesni nei jų trijų mazgų analogai. Nors visiškai įmanoma sudėti gerą dviejų mazgų klasterį, daugeliu atvejų dėl neapgalvotų scenarijų tokia konfigūracija sukels daug neaiškių problemų.
Pirmasis žingsnis kuriant bet kokią aukšto pasiekiamumo sistemą yra rasti ir pabandyti pašalinti atskirus gedimo taškus, dažnai sutrumpintus kaip SPoF (vienas gedimo taškas).
Verta nepamiršti, kad bet kurioje sistemoje neįmanoma pašalinti visų galimų prastovų pavojų. Taip yra dėl to, kad tipiška apsauga nuo rizikos yra tam tikro pertekliaus įvedimas, dėl kurio sistema tampa sudėtingesnė ir atsiranda naujų gedimų. Todėl iš pradžių darome kompromisą ir sutelkiame dėmesį į įvykius, susijusius su atskirais nesėkmės taškais, o ne į susijusių ir todėl vis mažiau tikėtinų įvykių grandines.
Atsižvelgdami į kompromisus, mes ne tik ieškome SPoF, bet ir subalansuojame rizikas ir pasekmes, todėl kiekvieno diegimo išvada, kas yra kritinė, o kas ne, gali skirtis.
Ne kiekvienam reikia alternatyvių elektros tiekėjų, turinčių nepriklausomas elektros linijas. Nors paranoja pasiteisino bent vienam klientui, kai jų stebėjimas aptiko sugedusį transformatorių. Klientas skambino telefonu, bandydamas įspėti elektros įmonę, kol sugedęs transformatorius sprogo.
Natūralus atspirties taškas yra turėti daugiau nei vieną mazgą sistemoje. Tačiau, kad po gedimo sistema galėtų perkelti paslaugas į išlikusį mazgą, ji paprastai turi užtikrinti, kad perkeliamos paslaugos nebūtų aktyvios kitur.
Dviejų mazgų klasteris neturi neigiamos pusės, jei dėl gedimo abu mazgai aptarnauja tą pačią statinę svetainę. Tačiau viskas pasikeičia, jei abi šalys savarankiškai valdo bendrinamą užduočių eilę arba suteikia nekoordinuotą rašymo prieigą prie pakartotos duomenų bazės arba bendrinamos failų sistemos.
Todėl norėdami užkirsti kelią duomenų sugadinimui dėl vieno mazgo gedimo - pasikliaujame kažkuo, vadinamu "disociacija" (tvora).
Disociacijos principas
Disociacijos principo esmė yra klausimas: ar konkuruojantis mazgas gali sukelti duomenų sugadinimą? Jei tikėtinas duomenų sugadinimo scenarijus, geras sprendimas būtų izoliuoti mazgą nuo gaunamų užklausų ir nuolatinės saugyklos. Dažniausias atsiejimo būdas yra atjungti sugedusius mazgus.
Yra dvi disociacijos metodų kategorijos, kurias aš vadinsiu tiesiai и netiesioginis, bet jie taip pat gali būti vadinami aktyvus и pasyvus. Tiesioginiai metodai apima išgyvenusių bendraamžių veiksmus, tokius kaip sąveika su IPMI (Intelligent Platform Management Interface) arba iLO (serverių valdymo mechanizmas, kai nėra fizinės prieigos prie jų) įrenginiu, o netiesioginiai metodai priklauso nuo nepavykusio. mazgas, kad kažkaip atpažintų, kad jis yra nesveikos (arba bent jau neleidžia kitiems nariams pasveikti) ir signalizuoja apie būtinybę atjungti sugedusį mazgą.
Kvorumas padeda naudoti tiek tiesioginius, tiek netiesioginius metodus.
Tiesioginė disociacija
Tiesioginės disociacijos atveju galime naudoti kvorumą, kad išvengtume disociacijos lenktynių tinklo gedimo atveju.
Taikant kvorumo koncepciją, sistemoje yra pakankamai informacijos (net ir neprisijungus prie lygiaverčių), kad mazgai automatiškai žinotų, ar jie turėtų inicijuoti atsiribojimą ir (arba) atkūrimą.
Be kvorumo abi tinklo takoskyros pusės teisingai manys, kad kita pusė yra mirusi, ir sieks atsieti kitą. Blogiausiu atveju abi pusės sugeba uždaryti visą klasterį. Alternatyvus scenarijus yra „deathmatch“, begalinis mazgų ciklas, nematantis savo bendraamžių, paleidžiamas iš naujo ir inicijuojamas atkūrimas, kad būtų paleistas iš naujo, kai jų bendraamžis vadovaujasi ta pačia logika.
Atsiejimo problema yra ta, kad dažniausiai naudojami įrenginiai tampa nepasiekiami dėl tų pačių gedimų, kuriuos norime atkurti. Dauguma IPMI ir iLO kortelių yra įdiegtos jų valdomuose pagrindiniuose kompiuteriuose ir pagal numatytuosius nustatymus naudoja tą patį tinklą, todėl tiksliniai kompiuteriai mano, kad kiti pagrindiniai kompiuteriai yra neprisijungę.
Deja, perkant įrangą retai atsižvelgiama į IPMI ir iLo įrenginių veikimo ypatybes.
Netiesioginė disociacija
Kvorumas taip pat svarbus valdant netiesioginį atsiribojimą; jei tai daroma teisingai, kvorumas gali leisti išgyvenusiems žmonėms manyti, kad prarasti mazgai po tam tikro laiko pereis į saugią būseną.
Naudojant šią konfigūraciją, aparatūros stebėjimo laikmatis iš naujo nustatomas kas N sekundžių, jei kvorumas neprarandamas. Jei laikmačio (paprastai keli N kartotiniai) galiojimo laikas baigiasi, įrenginys atlieka netinkamą maitinimo išjungimą (neišjungia).
Šis metodas yra labai veiksmingas, tačiau be kvorumo klasteryje nėra pakankamai informacijos, kad ją būtų galima valdyti. Nelengva atskirti tinklo nutrūkimą nuo lygiaverčio mazgo gedimo. Priežastis, kodėl tai svarbu, yra ta, kad nesugebėdami atskirti šių dviejų atvejų, abiem atvejais esate priversti pasirinkti tą patį elgesį.
Vieno režimo pasirinkimo problema yra ta, kad nėra jokių veiksmų, kurie padidintų pasiekiamumą ir apsaugotų nuo duomenų praradimo.
- Jei nuspręsite daryti prielaidą, kad lygiavertis mazgas yra aktyvus, bet iš tikrųjų sugenda, klasteris be reikalo sustabdys paslaugas, kurios veiktų, kad kompensuotų paslaugų praradimą iš nepavykusio lygiaverčio mazgo.
- Jei nuspręsite daryti prielaidą, kad mazgas neveikia, bet tai buvo tik tinklo gedimas, o nuotolinis mazgas iš tikrųjų veikia, geriausiu atveju prisiregistruojate, kad ateityje būtų atliktas rankinis gautų duomenų rinkinių suderinimas.
Nepriklausomai nuo to, kokią euristiką naudojate, nereikšminga sukurti gedimą, dėl kurio arba suges abi pusės, arba klasteris išjungs išlikusius mazgus. Kvorumo nenaudojimas iš tikrųjų atima vieną iš galingiausių įrankių savo arsenale.
Jei nėra kitos alternatyvos, geriausias būdas yra paaukoti prieinamumą (čia autorius remiasi BŽŪP teorema). Didelis sugadintų duomenų prieinamumas niekam nepadeda, o rankiniu būdu suderinti skirtingus duomenų rinkinius taip pat nėra smagu.
Kvorumas
Kvorumas skamba puikiai, tiesa?
Vienintelis trūkumas yra tas, kad norint turėti jį klasteryje su N narių, turite turėti ryšį tarp likusių N/2+1 mazgų. Tai neįmanoma dviejų mazgų klasteryje sugedus vienam mazgui.
Tai galiausiai atveda mus prie pagrindinės problemos, susijusios su dviem mazgais:
Kvorumas nėra prasmingas dviejose mazgų grupėse, o be jo neįmanoma patikimai nustatyti veiksmų eigos, kuri padidintų pasiekiamumą ir apsaugotų nuo duomenų praradimo
Net dviejų mazgų, sujungtų kryžminiu kabeliu, sistemoje neįmanoma galutinai atskirti tinklo nutrūkimo ir kito mazgo gedimo. Vieno galo išjungimo (kurio tikimybė, žinoma, proporcinga atstumui tarp mazgų) pakaks, kad būtų paneigta bet kokia prielaida, kad nuorodos būklė yra lygi partnerio mazgo būklei.
Dviejų mazgų klasterio veikimas
Kartais klientas negali arba nenori įsigyti trečiojo mazgo, o mes esame priversti ieškoti alternatyvos.
1 variantas – pasikartojančio disociacijos metodas
Mazgo iLO arba IPMI įrenginys yra gedimo taškas, nes jei jis sugenda, išgyvenę asmenys negali jo naudoti, kad mazgas būtų saugios būsenos. 3 ar daugiau mazgų grupėje galime tai sušvelninti apskaičiuodami kvorumą ir naudodami aparatūros stebėjimo priemonę (netiesioginio atsiejimo mechanizmą, kaip aptarta anksčiau). Dviejų mazgų atveju turime naudoti tinklo energijos paskirstymo blokus (PDU).
Po gedimo išgyvenęs asmuo pirmiausia bando susisiekti su pirminiu atjungimo įrenginiu (įterptuoju iLO arba IPMI). Jei tai pavyksta, atsigavimas tęsiamas kaip įprasta. Tik sugedus iLO/IPMI įrenginiui, pasiekiamas PDU; jei prieiga sėkminga, atkūrimas gali būti tęsiamas.
Būtinai įdėkite PDU į kitą tinklą nei klasterio srautas, nes priešingu atveju vienas tinklo gedimas užblokuos prieigą prie abiejų atsiejimo įrenginių ir užblokuos paslaugų atkūrimą.
Čia galite paklausti – ar PDU yra vienintelis gedimo taškas? Į kurį atsakymas, žinoma, yra.
Jei ši rizika jums reikšminga, nesate vieni: prijunkite abu mazgus prie dviejų PDU ir nurodykite grupavimo programinei įrangai naudoti abu, kai įjungiate ir išjungiate mazgus. Klasteris dabar išlieka aktyvus, jei vienas PDU miršta, o norint blokuoti atkūrimą, reikės antrojo kito PDU arba IPMI įrenginio gedimo.
2 variantas – arbitro pridėjimas
Kai kuriais atvejais, nors pasikartojančio atskyrimo metodas yra techniškai įmanomas, jis yra politiškai sudėtingas. Daugelis įmonių mėgsta, kad administratoriai ir programų savininkai būtų atskirti, o saugumu besirūpinantys tinklo administratoriai ne visada entuziastingai su kuo nors dalijasi PDU prieigos nustatymais.
Tokiu atveju rekomenduojama sukurti neutralią trečiąją šalį, kuri galėtų papildyti kvorumo skaičiavimą.
Gedimo atveju mazgas turi matyti savo kolegos ar arbitro eterį, kad galėtų atkurti paslaugas. Arbitras taip pat turi atjungimo funkciją, jei abu mazgai mato arbitrą, bet nemato vienas kito.
Ši parinktis turi būti naudojama kartu su netiesioginiu atsiejimo metodu, pvz., aparatūros stebėjimo laikmačiu, kuris sukonfigūruotas taip, kad užmuštų mašiną, jei ji praras ryšį su savo lygiaverčiu ir arbitro mazgu. Taigi, išgyvenęs asmuo gali pagrįstai manyti, kad jo bendraamžis mazgas bus saugios būsenos pasibaigus aparatūros stebėjimo laikmačio galiojimui.
Praktinis skirtumas tarp arbitro ir trečiojo mazgo yra tas, kad arbitrui veikti reikia daug mažiau išteklių ir jis gali aptarnauti daugiau nei vieną klasterį.
3 variantas – žmogiškasis faktorius
Paskutinis būdas yra tas, kad išgyvenę asmenys toliau veiktų bet kokias jau naudotas paslaugas, bet nepradėtų naujų, kol problema išsispręs savaime (tinklo atkūrimas, mazgo perkrovimas) arba asmuo neprisiima atsakomybės rankiniu būdu patvirtinti, kad kita pusė mirusi.
Premijos variantas
Ar minėjau, kad galite pridėti trečią mazgą?
Du stelažai
Argumentų dėlei apsimeskime, kad įtikinau jus trečiojo mazgo pranašumais, dabar turime apsvarstyti fizinį mazgų išdėstymą. Jei jie yra (ir maitinami) tame pačiame stove, tai taip pat yra SPoF, kurio negalima išspręsti pridedant antrą stovą.
Jei tai stebina, apsvarstykite, kas nutiktų, jei stovas su dviem mazgais sugestų ir kaip išlikęs mazgas atskirtų tai nuo tinklo gedimo.
Trumpas atsakymas yra toks, kad tai neįmanoma, ir mes vėl sprendžiame visas problemas dviejų mazgų atveju. Arba išgyvenęs:
- nepaiso kvorumo ir neteisingai bando inicijuoti atkūrimą per tinklo nutrūkimus (gebėjimas užbaigti atsiribojimą yra kita istorija ir priklauso nuo to, ar dalyvauja PDU ir ar jie dalijasi energija su bet kuriuo iš stovų), arba
- gerbia kvorumą ir per anksti atsijungia, kai sugenda jo lygiavertis mazgas
Bet kokiu atveju du stovai yra ne geresni už vieną, o mazgai turi gauti nepriklausomą maitinimo šaltinį arba būti paskirstyti trims (ar daugiau, atsižvelgiant į tai, kiek mazgų turite) stelažus.
Du duomenų centrai
Šiuo metu skaitytojai, kurie nebijo rizikuoti, gali norėti apsvarstyti atkūrimą po nelaimės. Kas atsitiks, kai asteroidas atsitrenks į tą patį duomenų centrą su trimis mazgais, išsidėsčiusiais per tris skirtingus stovus? Akivaizdu, kad blogi dalykai, tačiau, atsižvelgiant į jūsų poreikius, pridėti antrą duomenų centrą gali nepakakti.
Jei tai daroma teisingai, antrasis duomenų centras pateikia jums (ir pagrįstai) naujausią ir nuoseklią jūsų paslaugų ir jų duomenų kopiją. Tačiau, kaip ir dviejų mazgų, dviejų stovų scenarijuose, sistemoje nėra pakankamai informacijos, kad būtų užtikrintas maksimalus pasiekiamumas ir išvengta korupcijos (arba duomenų rinkinių neatitikimų). Net ir naudojant tris mazgus (ar stelažus), juos paskirstius tik dviejuose duomenų centruose, sistema negali patikimai priimti teisingo sprendimo įvykus (dabar daug labiau tikėtina) įvykiui, kai abi šalys negali susisiekti.
Tai nereiškia, kad dvigubo duomenų centro sprendimas niekada netinka. Įmonės dažnai nori, kad asmuo žinotų prieš imdamasis nepaprasto žingsnio ir persikeldamas į atsarginį duomenų centrą. Tiesiog atminkite, kad jei norite automatizuoti gedimą, jums reikės trečiojo duomenų centro, kad kvorumas būtų prasmingas (tiesiogiai arba per arbitrą), arba rasite būdą, kaip patikimai išjungti visus duomenis. centras.
Šaltinis: www.habr.com