Hej Habr! Predstavljam vam prevod članka avtorja Andrew Beekhof.
Veliko ljudi ima raje gruče z dvema vozliščema, ker se zdijo konceptualno enostavnejše in tudi 33 % cenejše od svojih sorodnikov s tremi vozlišči. Čeprav je mogoče sestaviti dobro gručo z dvema vozliščema, bo v večini primerov zaradi neupoštevanih scenarijev ta konfiguracija povzročila številne neočitne težave.
Prvi korak pri ustvarjanju katerega koli sistema visoke razpoložljivosti je najti in poskusiti odpraviti posamezne točke napake, ki jih pogosto imenujemo SPoF (ena točka odpovedi).
Upoštevati je treba, da v nobenem sistemu ni mogoče odpraviti vseh možnih tveganj izpadov. To izhaja vsaj iz dejstva, da je tipična obramba pred tveganjem uvedba nekaj redundance, kar povzroči večanje kompleksnosti sistema in pojav novih točk odpovedi. Zato sprva sklepamo kompromise in se osredotočamo na dogodke, povezane s posameznimi točkami odpovedi, in ne na verige povezanih in zato vse manj verjetnih dogodkov.
Glede na kompromise ne iščemo samo SPoF, temveč tudi ravnovesje med tveganji in posledicami, kar ima za posledico sklep, kaj je kritično in kaj ne, se lahko razlikuje za vsako uvedbo.
Ne potrebujejo vsi alternativnih ponudnikov električne energije z neodvisnimi daljnovodi. Čeprav se je vsaj eni stranki paranoja obrestovala, ko je njihov nadzor odkril pokvarjen transformator. Stranka je telefonirala in poskušala opozoriti elektropodjetje, dokler ni eksplodiral pokvarjeni transformator.
Naravno izhodišče je imeti več kot eno vozlišče v sistemu. Preden lahko sistem premakne storitve v preživelo vozlišče, je treba na splošno zagotoviti, da storitve, ki se premikajo, niso aktivne drugam.
Groča z dvema vozliščema nima nobene slabosti, če obe vozlišči služita istemu statičnemu spletnemu mestu zaradi okvare. Vendar se stvari spremenijo, če obe strani na koncu neodvisno upravljata čakalno vrsto opravil v skupni rabi ali odobrita neusklajen dostop za pisanje v podvojeno bazo podatkov ali datotečni sistem v skupni rabi.
Da bi torej preprečili poškodbe podatkov, ki so posledica okvare enega samega vozlišča, se zanašamo na nekaj, kar se imenuje "razmejitev" (ograjevanje).
Načelo distanciranja
Načelo omejevanja temelji na vprašanju: ali lahko konkurenčno vozlišče povzroči poškodbo podatkov? Če je verjeten scenarij poškodbe podatkov, je izolacija vozlišča od dohodnih zahtev in trajnega shranjevanja dobra rešitev. Najpogostejši pristop k ograjevanju je zaustavitev okvarjenih vozlišč.
Obstajata dve kategoriji metod distanciranja, ki ju bom poimenoval naravnost и posredno, vendar se lahko enako imenujejo aktivno и pasivno. Neposredne metode vključujejo dejanja preživelih vrstnikov, kot je interakcija z IPMI (Intelligent Platform Management Interface – vmesnik za daljinsko spremljanje in upravljanje fizičnega stanja strežnika) ali iLO (mehanizem za upravljanje strežnikov, če do njih ni fizičnega dostopa). ), medtem ko se posredne metode zanašajo na to, da okvarjeno vozlišče nekako prepozna, da je v nezdravem stanju (ali vsaj prepreči preostalim članom, da si opomorejo) in signalizira o potrebi po zaustavitvi okvarjenega vozlišča.
Quorum pomaga v primeru uporabe neposrednih in posrednih metod.
Direktno oddaljevanje
V primeru neposrednega ograjevanja lahko uporabimo kvorum, da preprečimo tekmovanje v ograjevanju v primeru izpada omrežja.
Z vzpostavljenim konceptom kvoruma je v sistemu dovolj informacij (tudi brez povezave z enakimi), da vozlišča samodejno vedo, ali naj sprožijo prekinitev povezave in/ali obnovitev.
Brez sklepčnosti obe strani omrežne delitve upravičeno domnevata, da je druga stran mrtva in bosta poskušali ločiti drugo stran. V najslabšem primeru obema stranema uspe ugasniti celoten grozd. Alternativni scenarij je deathmatch, neskončna zanka vozlišč, ki se prikažejo, ne vidijo svojih vrstnikov, jih znova zaženejo in sprožijo obnovitev samo, da se znova zaženejo, ko gre njihov vrstnik skozi isto logiko.
Težava pri omejevanju je v tem, da najpogosteje uporabljene naprave postanejo nedosegljive zaradi istih okvar, ki jih želimo obnoviti. Večina kartic IPMI in iLO je nameščenih na gostiteljih, ki jih nadzorujejo, in privzeto uporabljajo isto omrežje, zaradi česar ciljni gostitelji domnevajo, da so ostali gostitelji brez povezave.
Na žalost se lastnosti naprav IPMI in iLo le redko upoštevajo pri nakupu opreme.
Posredna distanca
Sklepčnost je prav tako pomembna za upravljanje posrednega ograjevanja; če je izvedeno pravilno, lahko sklepčnost omogoči preživelim domnevo, da bodo izgubljena vozlišča po določenem času prešla v varno stanje.
S to nastavitvijo se časovnik nadzornika strojne opreme ponastavi vsakih N sekund, razen če je kvorum izgubljen. Če časovnik (običajno nekajkratnik N) poteče, potem naprava izvede neljubo izklop (ne zaustavitev).
Ta pristop je zelo učinkovit, vendar brez kvoruma v gruči ni dovolj informacij za upravljanje. Razlike med izpadom omrežja in odpovedjo vozlišča ni enostavno. Razlog, zakaj je to pomembno, je, da ste brez sposobnosti razlikovanja med obema primeroma prisiljeni izbrati isto vedenje v obeh primerih.
Težava pri izbiri enega načina je, da ni nobenega načina ukrepanja, ki bi povečal razpoložljivost in preprečil izgubo podatkov.
- Če se odločite za domnevo, da partnersko vozlišče deluje, vendar dejansko ni uspelo, bo gruča po nepotrebnem ustavila storitve, ki bi se morale izvajati, da bi nadomestile izgubo storitev iz padlega partnerskega vozlišča.
- Če se odločite, da domnevate, da vozlišče ne deluje, vendar je šlo le za izpad omrežja in dejansko oddaljeno vozlišče deluje, potem se v najboljšem primeru naročite na prihodnje ročno usklajevanje nizov rezultatov.
Ne glede na to, katero hevristiko uporabljate, je nepomembno ustvariti napako, zaradi katere bosta obe strani delovali ali prisilili gručo, da zaustavi preživela vozlišča. Neuporaba kvoruma res prikrajša gručo za eno najmočnejših orodij v njenem arzenalu.
Če ni druge možnosti, je najboljši pristop žrtvovanje dostopnosti (tukaj se avtor sklicuje na izrek CAP). Visoka razpoložljivost poškodovanih podatkov ne pomaga nikomur in tudi ročno usklajevanje različnih naborov podatkov ni zabavno.
Sklepčnost
Sklepčnost se sliši odlično, kajne?
Edina pomanjkljivost je, da morate imeti povezavo med N / 2 + 1 vašimi vozlišči, da bi ga imeli v gruči z N člani. Kar ni mogoče v gruči z dvema vozliščema, potem ko eno vozlišče odpove.
Kar nas na koncu pripelje do temeljnega problema dveh vozlišč:
Kvorum je nesmiseln v dveh gručih vozlišč in brez njega ni mogoče zanesljivo določiti poteka dejanj, ki poveča razpoložljivost in prepreči izgubo podatkov
Tudi v sistemu dveh vozlišč, povezanih s križnim kablom, ni mogoče dokončno razlikovati med izpadom omrežja in drugo okvaro vozlišča. Zaustavitev enega konca (katerega verjetnost je zagotovo sorazmerna z razdaljo med vozlišči) bo zadostovala, da ovrže vsako domnevo, da je zdravje povezave enako zdravju partnerskega vozlišča.
Naredimo gručo dveh vozlišč
Včasih stranka ne more ali noče kupiti tretjega vozlišča in smo prisiljeni iskati alternativo.
Možnost 1 - Dvojna metoda razmejitve
Naprava iLO ali IPMI vozlišča predstavlja točko okvare, ker v primeru okvare preživeli z njo ne morejo spraviti vozlišča v varno stanje. V gruči s 3 ali več vozlišči lahko to ublažimo z izračunom kvoruma in uporabo nadzornika strojne opreme (posrednega mehanizma ograjevanja, kot smo že omenili). V primeru dveh vozlišč bi morali namesto tega uporabiti omrežna napajalna stikala (napajalne razdelilne enote ali PDU).
Po neuspehu preživeli najprej poskuša komunicirati s primarno ograjevalno napravo (vgrajenim iLO ali IPMI). Če je uspešno, se okrevanje nadaljuje kot običajno. Samo če naprava iLO / IPMI odpove, se dostopa do PDU, če je dostop uspešen, se lahko obnovitev nadaljuje.
Poskrbite, da boste PDU postavili v omrežje, ki je ločeno od prometa gruče, sicer bo ena sama okvara omrežja blokirala dostop do obeh omejevalnih naprav in bo blokirala obnovitev storitve.
Na tej točki se morda sprašujete - ali ni PDU ena sama točka odpovedi? Na kar je odgovor seveda.
Če je to tveganje za vas pomembno, niste sami: povežite obe vozlišči z dvema PDU-jema in povejte programski opremi gruče, naj uporablja oba pri vklopu in izklopu vozlišč. Grozd zdaj ostane aktiven, če en PDU umre in bi bila za blokiranje obnovitve potrebna druga okvara drugega PDU ali naprave IPMI.
2. možnost – dodajanje razsodnika
Čeprav je tehnika redundantnega distanciranja v nekaterih scenarijih tehnično izvedljiva, je politično težka. Mnoga podjetja želijo imeti določeno ločitev med skrbniki in lastniki aplikacij, skrbniki omrežja, ki se zavedajo varnosti, pa niso vedno navdušeni nad predajo parametrov dostopa do PDU komurkoli.
V tem primeru je priporočena alternativa ustvariti nevtralno tretjo osebo, ki lahko dopolni izračun kvoruma.
V primeru okvare mora biti vozlišče sposobno videti zrak svojega vrstnika ali razsodnika, da lahko obnovi storitve. Razsodnik vključuje tudi funkcijo za prekinitev povezave, če obe vozlišči vidita razsodnika, ne vidita pa drug drugega.
To možnost je treba uporabiti v povezavi s posredno metodo omejevanja, kot je časovnik nadzornika strojne opreme, ki je konfiguriran za zaustavitev stroja, če ta izgubi povezavo z enakovrednim vozliščem in razsodnikom. Tako lahko preživeli z razumno gotovostjo domneva, da bo njegovo enakovredno vozlišče v varnem stanju po izteku časovnika nadzornika strojne opreme.
Praktična razlika med razsodnikom in tretjim vozliščem je v tem, da razsodnik za delovanje potrebuje veliko manj sredstev in potencialno lahko služi več kot eni gruči.
Možnost 3 - človeški dejavnik
Zadnji pristop je, da preživeli nadaljujejo z izvajanjem vseh storitev, ki so jih že izvajali, vendar ne zaženejo novih, dokler se težava ne odpravi sama (obnovitev omrežja, ponovni zagon vozlišča) ali dokler oseba ne prevzame odgovornosti za ročno potrditev, da druga stran je mrtev.
Možnost bonusa
Sem omenil, da lahko dodate tretje vozlišče?
dva stojala
Zavoljo argumenta se pretvarjajmo, da sem vas prepričal o prednostih tretjega vozlišča, zdaj pa moramo razmisliti o fizični postavitvi vozlišč. Če so nameščeni (in napajani) v isti omarici, je tudi to SPoF in ga ni mogoče rešiti z dodajanjem druge omarice.
Če je to presenetljivo, pomislite, kaj bi se zgodilo, če bi omara z dvema vozliščema odpovedala in kako bi preživelo vozlišče razlikovalo med tem primerom in napako omrežja.
Kratek odgovor je, da to ni mogoče in spet imamo opravka z vsemi težavami v primeru dveh vozlišč. Ali preživeli:
- ignorira kvorum in nepravilno poskuša začeti obnovitev med izpadi omrežja (zmožnost dokončanja ograjevanja je druga zgodba in je odvisna od tega, ali je PDU vključen in ali si deli napajanje s katerim koli omaro) ali
- upošteva kvorum in se predčasno izklopi, ko odpove enakovredno vozlišče
V vsakem primeru dve omari nista boljši od ene in vozlišča morajo prejemati neodvisne napajalnike ali pa biti razporejena po treh (ali več, odvisno od tega, koliko vozlišč imate) omarah.
Dva podatkovna centra
Do te točke lahko bralci, ki niso več naklonjeni tveganju, razmislijo o obnovitvi po katastrofi. Kaj se zgodi, ko asteroid zadene isti podatkovni center z našimi tremi vozlišči, razporejenimi po treh različnih stojalih? Očitno slabe stvari, vendar glede na vaše potrebe dodajanje drugega podatkovnega centra morda ne bo dovolj.
Če je opravljeno pravilno, vam drugi podatkovni center zagotovi (in to je razumno) posodobljeno in dosledno kopijo vaših storitev in njihovih podatkov. Vendar, tako kot v scenarijih z XNUMX vozliščema in XNUMX omaricami, v sistemu ni dovolj informacij, da bi zagotovili največjo razpoložljivost in preprečili poškodbe (ali razhajanja nabora podatkov). Tudi s tremi vozlišči (ali omaricami) njihova porazdelitev v samo dva podatkovna centra onemogoča sistem, da bi zanesljivo sprejel pravo odločitev v primeru (zdaj veliko bolj verjetnega) dogodka, o katerem obe strani ne moreta komunicirati.
To ne pomeni, da rešitev z dvema podatkovnima centroma nikoli ni dobra ideja. Podjetja pogosto želijo, da je oseba seznanjena, preden se odloči za izjemen korak selitve v rezervni podatkovni center. Zavedajte se le, da če želite avtomatizirati napako, boste potrebovali tretji podatkovni center, da bo sklepčnost smiselna (neposredno ali prek razsodnika), ali pa boste našli način za zanesljivo zaustavitev celotnega podatkovnega centra.
Vir: www.habr.com