Kahe sõlme klaster – detailides peitub oht

Tere, Habr! Esitan teile artikli tõlke «Two Nodes — The Devil is in the Details» autor Andrew Beekhof.

Paljud inimesed eelistavad kahe sõlmega klastreid, sest need näivad kontseptuaalselt lihtsamad ning on ka 33% odavamad kui nende kolme sõlmega kolleegid. Kuigi on täiesti võimalik luua hea kahe sõlmega klaster, võib see enamikul juhtudel, arvestamata mõningaid stsenaariume, tekitada palju vähem ilmseid probleeme.

Esimene samm iga kõrgparemuse süsteemi loomisel on otsida ja püüda kõrvaldada üksikuid tõrkeerime, mida sageli lühendatakse kui SPoF (üksik tõrkepunkt).

Oluline on meeles pidada, et üheski süsteemis ei ole võimalik kõrvaldada kõiki võimalikke seiskamise riske. See tuleneb vähemalt tõsiasjast, et tüüpiline kaitse riski vastu on teatud üleliigsuse loomine, mis suurendab süsteemi keerukust ja toob kaasa uusi tõrkepunkte. Seega teeme alguses kompromissi ning keskendume sündmustele, mis on seotud üksikute tõrkepunktidega, mitte omavahel seotud ja seega järjest vähem tõenäoliste sündmusteahelatega.

Kompromisse arvesse võttes ei otsi me mitte ainult SPoF'e, vaid kaalume ka riske ja tagajärgi, mistõttu kriitilise ja mitte kriitilise vahel võib eraldumine iga juurutuse puhul erineda.

Kõigil pole vaja alternatiivseid elektritootjaid sõltumatute elektriliinidega. Kuigi paranoia tasus end ära vähemalt ühel kliendil, kui nende jälgimisseade tuvastas defektse trafo. Klient helistas, üritades hoiatada elektrifirmat, kuni defektne trafo plahvatas.

Looduslikuks lähtepunktiks on süsteemis vähemalt ühe sõlme olemasolu. Siiski, enne kui süsteem suudab teenuseid üle viia ellujäänud sõlmele pärast riket, tuleb tavaliselt kinnitada, et üle kantavad teenused ei ole aktiivsed mingis muus kohas.

Kaksisõlmelisel klastril ei ole puudusi, kui mõlemad sõlmed teenindavad sama statilist veebisaiti tõrke korral. Kuid kõik muutub, kui mõlemal poolel on sõltumatu juurdepääs ühisele töökohustuste järjekorrale või kui nad pakuvad koordineerimata kirjutamisjuurdepääsu replikatsiooniga andmebaasile või ühisele failisüsteemile.

Seetõttu, et vältida andmete kahjustamist ühe sõlme tõrke tõttu – toetume sellele, mida nimetatakse „piiramise“ (fencing).

Piiramisprintsiip

Piiramisprintsiibi aluseks on küsimus: kas konkurent sõlm võib põhjustada andmete kahjustamist? Kui andmete kahjustamine on võimalik stsenaarium – oleks hea lahendus sõlme isoleerimine nii sise- kui ka püsivast salvestamisest. Kõige levinum lähenemine piiramisele on vigaste sõlmede väljalülitamine.

On kaks kategooriat piiramismeetodeid, mida ma nimetaksin otse ja kaudseks, kuid neid võib samuti nimetada aktiivseteks ja passiivseteks. Otsesed meetodid hõlmavad tegevusi ellujäänud võrguühendusega sõlmedelt, nagu IPMI (Intelligent Platform Management Interface — serveri füüsilise oleku kaugmonitorimise ja haldamise liides) või iLO (serverite haldamise mehhanism füüsilise juurdepääsu puudumisel), samas kui kaudsed meetodid tuginevad ebaõnnestunud sõlmele, et mingil moel ära tunda, et see on ebatervislik seisund (või vähemalt segab teisi liikmeid taastumast) ja annab signaali hardware watchdog ebaõnnestunud sõlme välja lülitamise vajadusest.

Kvoorum aitab nii otseste kui ka kaudsete meetodite kasutamisel.

Otsene lahutamine

Otsese lahutamise korral saame kvoorumit kasutada üldiselt, et vältida lahutamisvõistlusi võrgu tõrke korral.

Kvoorumi kontseptsiooniga süsteemis on piisavalt teavet (isegi ilma oma partneritega ühendamiseta), et sõlmed automaatselt teaksid, kas nad peaksid käivitama lahutamise ja / või taastamise.

Ilma kvoorumit mõlemad võrgu eraldumise osapooled eeldavad õigesti, et teine osapool on surnud, ja püüavad eraldada teist. Halvimal juhul suudavad mõlemad osapooled kogu klastri välja lülitada. Alternatiivne stsenaarium on surmav matš, lõputu sõlmede tsükkel, mis ilmuvad, ei näe oma peerusid, taaskäivitavad need ja käivitavad taastamise ainult selleks, et taaskäivitada, kui nende peer järgib sama loogikat.

Eraldamise probleem on see, et kõige sagedamini kasutatavad seadmed muutuvad kättesaamatuks sama rikke tõttu, millele me taastumise jaoks keskendume. Enamik IPMI ja iLO kaarte on paigaldatud hostidesse, mida nad kontrollivad, ja nende vaikimisi kasutatav sama võrk paneb sihitud sõlmed uskumma, et ülejäänud sõlmed on välja lülitatud.

Kahjuks käsitletakse IPMI ja iLO seadmete tööd harva seadmete ostmise hetkel.

Kaudne eraldamine

Kvoorum on samuti oluline kaudsete eraldamiste haldamiseks; kui kõik on õigesti tehtud, võib kvoorum lubada ellujäänutel eeldada, et kadunud sõlmed lähevad teatud aja pärast turvalisse olekusse.

Sellise seadistuse puhul lähtestatakse riistvaravalve taimer iga N sekundi järel, kui kvoorum ei ole kadunud. Kui taimer (tavaliselt mitu korda N) aegub, toimub seadme ebaviisakas toite väljalülitamine (mitte shutdown).

See lähenemine on väga tõhus, kuid kvoorumita selle haldamiseks pole klastris piisavalt teavet. Raskeks osutub erinevuse määramine võrgu katkestamise ja partner-sõlme rikke vahel. See on oluline, sest ilma võimeta nende kahe olukorra vahel eristada, peate valima mõlemal juhul sama käitumismudeli.

Üksiku režiimi valimise probleem seisneb põhimõttes, et puudub tegevus, mis maksimaalselt suurendaks kättesaadavust ja takistaks andmete kadumist.

• Kui otsustate eeldada, et partnernode on aktiivne, kuid tegelikult on toimunud rike, siis klaster peatab liialt teenused, mis pidanuks töötama kukkunud partnernode'i teenuste kadumise kompenseerimiseks.
• Kui otsustate eeldada, et node ei tööta, kuid see oli lihtsalt võrgu rike ning tegelikult kaugnode toimib, siis parimal juhul liitute te tulevaste käsitsi andmekogumite kontrollimisega.

Olenemata sellest, millist heuristikat te kasutate, on triviaalne tekitada rike, mis kas sunnib mõlemat poolt töötama või sundib klastrit ellujäänud node'id välja lülitama. Kvoorumi mittekasutamine annab tõeliselt klastrile üht kõige võimsamat tööriista.

Kui pole muid alternatiive, on parim lähenemine ohverdada kättesaadavus (siin viitab autor CAP-teoreemile). Kõrge kättesaadavus kahjustatud andmete puhul ei aita kedagi ning erinevate andmekogumite käsitsi kontrollimine ei paku ka kellelegi rõõmu.

Kvoorum

Kvoorum kõlab suurepäraselt, eks?

Ainus puudus on see, et N liiget sisaldava klusteri jaoks peab ühendus olema olemas vähemalt N / 2 + 1 teie sõlmede vahel. See on võimatu kahe sõlmiga klusteris pärast ühe sõlme nurjumist.

See viib meid lõpuks kahe sõlme põhiprobleemi juurde:
kvoorum ei oma mõtet kahe sõlmega klusterites, ja ilma selleta ei saa usaldusväärselt määrata tegevussuunda, mis maksimeerib kättesaadavust ja takistab andmete kaotust.
Isegi kahe sõlmega süsteemis, mis on ühendatud risti-kaabliga, on võimatu lõplikult eristada võrgu katkestust ja teise sõlme nurjumist. Ühe otsa katkestamine (mille tõenäosus on kindlasti proportsionaalne sõlmede vahemaa pikkusele) on piisav, et ümber lükata iga oletus, et kanali töökindlus on võrdne partner-sõlme tervisega.

Küllaltki keeruline on kahe sõlmega klusterit tööle panna.

Mõnikord ei saa klient või ei soovi osta kolmandat sõlme ning me peame otsima alternatiivi.

Variant 1 — Duplitseeriv isolatsiooni meetod

iLO või IPMI seadme rike võib olla tõrkeallikas, kuna rikke korral ei saa ülejäänud elujõulised sõlmed seda kasutada sõlme turvalisse olekusse viimiseks. Kolmest või enamast sõlmest koosnevas klastris saame seda leevendada koosoleku arvutamise ja hardware watchdog'i kasutamisega (indirektne kuvand, nagu eelnevalt arutatud). Kahe sõlmega juhul peame kasutama toitejaotusseadmeid (power distribution units või PDUs).

Pärast riket proovib ellujäänud esmalt ühendust võtta peamise omavahelise seadmega (sisseehitatud iLO või IPMI). Kui see õnnestub, jätkub taastamine nagu tavaliselt. Ainult iLO/IPMI seadme rikke korral pöördutakse PDU poole, ja kui selle poole pöördumine on edukas, võib taastamine jätkuda.

Veenduge, et PDU oleks ühendatud võrgus, mis erineb klastrisse suunatud liiklusest; vastasel juhul takistab üksik rike pääsu nii omavahelistele seadmetele kui ka teenuste taastamisele.

Siin võite küsida – kas PDU seade ei ole ainus tõrkeallikas? Vastus on – on küll.

Kui see risk on teie jaoks murettekitav, siis te pole üksi: ühendage mõlemad sõlmed kahe PDU-ga ja öelge klastritarkvarale, et kasutada mõlemat sõlme sisse- ja väljalülitamisel. Nüüd püsib klaster aktiivne, isegi kui üks PDU sureb, ja taastumisklüsopahn tuleb teise tõrke tõttu, olgu see siis PDU või IPMI seade.

Variant 2 — Arbitraari lisamine

Mõnes olukorras, kuigi tehniliselt on võimalik kasutada kahekordset isoleerimist, on see poliitiliselt keeruline. Paljudele ettevõtetele meeldib, et administraatorite ja rakenduste omanike vahel on selge eraldatus, ning turvalisuse eest vastutavad võrguadministraatorid ei pruugi alati olla entusiastlikud PDU-juurdepääsu parameetrite edastamise suhtes kellelegi.

Sellisel juhul on soovitatav alternatiiv luua neutraalne kolmas osapool, mis võib olukorrast kohaselt kvoraumi arvestuse täiustada.

Tõrke korral peab sõlm suutma näha oma partneri või arbitraari signaali, et teenuseid taastada. Arbitraar sisaldab ka valmisolekut katkestada ühendust, kui mõlemad sõlmed saavad arbitraari näha, kuid ei näe üksteist.

See valikut peab kasutama koos kaudse piiramise meetodiga, näiteks riistvaralise jälgimismehhanismi, mis on seadistatud masina väljalülitamiseks, kui see kaotab ühenduse oma partneri sõlme ja vahekohtu vahel. Nii saab ellujäänu piisava usaldusväärsusega eeldada, et tema partneri sõlm on pärast riistvaralise jälgimismehhanismi välja lülitamist turvalises olekus.

Praktiline vahe vahekohtu ja kolmanda sõlme vahel on see, et vahekoht vajab oma tööks palju vähem ressursse ja võib potentsiaalselt teenindada rohkem kui ühte klastrit.

Variatsioon 3 — Inimfaktor

Viimane lähenemine tähendab seda, et ellujääjad jätkavad kõikide teenuste täitmist, mida nad juba täidavad, kuid ei alustata uusi teenuseid, kuni kas probleem ei lahene iseenesest (võrgu taastamine, sõlme taaskäivitamine) või inimene ei võta vastutust selle käsitsi kinnitamiseks, et teine ​​pool on surnud.

Boonusvõimalus

Kas ma olen juba öelnud, et saate lisada kolmanda sõlme?

Kaks seisst

Arutelu huvides kujutage ette, et ma veensin teid kolmanda sõlme eelistes, nüüd peame arvestama sõlmede füüsilist asukohta. Kui need on paigutatud (ja toidetud) samasse rack'i, esindab see samuti SPoF-i ning sellist, mida ei saa lahendada teise rack'i lisamisega.

Kui see on hämmastav, mõelge, mis juhtub, kui kahest sõlmest koosnev rack ebaõnnestub, ja kuidas ellujäänud sõlm selle olukorra ja võrgu tõrke eristab.

Lühike vastus: see pole võimalik, ja meil on taas kõik probleemid, millega silmitsi seisame kahel sõlmest. Kas ellujäänud:

• ignoreerib kvoorumit ja üritab valehäire ajal vale taastamist algatada (katkestuse lõpetamise tõenäosus on eraldi lugu ja sõltub, kas PDU on kaasatud ja kui nad jagavad toite mõne rack'iga), või
• au kvoorumile ja väljub enne tähtaega, kui tema partner-sõlm ebaõnnestub.

Igal juhul ei ole kaks rack'i parem kui üks, ning sõlmed peavad saama kas sõltumatud toiteallikad või olema jaotatud kolmele (või enamale, olenevalt sellest, kui palju sõlmi teil on) rack'ile.

Kaks andmekeskust

Selles punktis võivad lugejad, kes ei ole enam riskialti, hakata mõtlema äparduse taastamisele. Mis juhtub, kui asteroid tabab ühte andmekeskust, kus meie kolm sõlme on jaotatud kolmele erinevale rack'ile? Selgelt halvad asjad, kuid olenevalt teie vajadustest, võib teise andmekeskuse lisamine olla ebapiisav.

Kui kõik on õigesti tehtud, annab teine andmekeskus teile (ja see on mõistlik) ajakohase ja kooskõlastatud koopia teie teenustest ja nende andmetest. Siiski, nagu ka kahe sõlmega ja kahe riiuliga stsenaariumide puhul, puudub süsteemis piisavalt teavet maksimaalse kättesaadavuse tagamiseks ja andmekogumite kahjustamise (või lahknevuse) vältimiseks. Isegi kolmes sõlmes (või riiulis) on nende jaotamine ainult kahe andmekeskuse vahel selline, et süsteem ei suuda usaldusväärselt teha õiget otsust olukorras, mis on nüüd palju tõenäolisem, et mõlemad pooled ei suuda seda seostada.

See ei tähenda, et kahe andmekeskuse lahendus ei sobi kunagi. Ettevõtted soovivad tihti, et inimesed oleksid teadlikud, enne kui nad teevad erakordse sammu varuandmekeskusesse siirdumisel. Lihtsalt pidage meeles, et kui soovite ebaõnnestumist automatiseerida, vajate kas kolmandat andmekeskust, nii et kvoorumil oleks mõte (otseselt või läbi kohtuniku), või leiate viisi, kuidas andmekeskuse täielikult usaldusväärselt välja lülitada.

Allikas: habr.com