Kaks sõlme klaster - detailides peitub kurat

Tere, Habr! Esitlen teile tõlget artiklist «Kaks sõlme — Üksikasjades peitub kurat» autor Andrew Beekhof.

Paljud inimesed eelistavad kaht sõlme koosnevaid klaste, sest need näivad olevat kontseptuaalselt lihtsamad ning lisaks on need 33% odavamad kui nende kolm sõlme. Kuigi on täiesti võimalik luua hea kahe sõlmega klaster, toob see enamasti, arvestamata teatud stsenaariume, kaasa palju nähtamatuid probleeme.

Iga kõrge saadavuse süsteemi loomise esimene samm on tuvastada ja proovida kõrvaldada üksikute rikkepunkte, mida sageli lühendatult nimetatakse SPoF (üksik rikkepunkt).

Tuleb meeles pidada, et ükski süsteem ei suuda kõrvaldada kõiki võimalikke seiskumise riske. See tuleneb vähemalt sellest, et tüüpiliseks kaitseks riskide eest on teatava ülejäägi loomine, mis toob kaasa süsteemi keerukuse suurenemise ja uute rikkepunktide tekkimise. Seega teeme algusest peale kompromissi ja keskendume üksikute rikkepunktide seondumisega seotud sündmustele, mitte seotud ja seega üha vähem tõenäolistele sündmustele.

Kompromisse arvesse võttes ei otsi me mitte ainult SPoF-e, vaid tasakaalustame ka riske ja tagajärgi, millest järeldus, mis on kriitiline ja mis mitte, võib igas rakenduses erineda.

Kõigile ei ole vaja alternatiivsetele elektri tarnijatele, kellel on sõltumatud elektrijooned. Kuigi paranoiad on vähemalt ühe kliendi jaoks ennast õigustanud, kui nende jälgimine tuvastas defektiivse trafo. Klient helistas telefoniga, üritades teavitada energiaettevõtet, kuni defektiivne trafo plahvatas.

Loomulik alguspunkt on süsteemis rohkem kui üks sõlm. Siiski, enne kui süsteem saab teenused üle viia elujõulisele sõlmele pärast riket, tuleb üldjuhul veenduda, et üle kantavad teenused ei ole aktiivsed kuskil mujal.

Kaks sõlme klastril pole puudusi, kui mõlemad sõlmed hooldavad sama staatilist veebisaiti. Kuid kõik muutub, kui mõlemad pooled haldavad sõltumatult ühist tööde järjekorda või pakuvad koordineerimata kirjutamise juurdepääsu repliikeeritud andmebaasile või ühisfaili süsteemile.

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

Piiramise põhimõte

Piiramise põhimõtte aluseks on küsimus: kas konkurentsivõimeline sõlm võib põhjustada andmete kahjustamist? Kui andmete kahjustamine on tõenäoline stsenaarium, on heaks lahenduseks sõlme isoleerimine nii sissetulevatest päringutest kui ka pidevast salvestamisest. Tüüpiline lähenemine piiramisele on rikketeenuste sõlmede kõrvaldamine.

On olemas kaks kategooriat piiramismeetodeid, mida ma nimetan otsesed ja kaudsed, kuid neid võib nimetada ka aktiivseteks ja passiivseteks. Otsesed meetodid hõlmavad ellujäänud võrdselt sõlmedelt tegevusi, nagu suhtlemine IPMI (Intelligent Platform Management Interface - füüsilise serveri seisundi kaugmonitorimise ja haldamise liides) või iLO (serverite haldamise mehhanism füüsilise juurdepääsuta) seadmetega, samas kui kaudsed meetodid tuginevad rikke tõttu sõlmele millegipärast ära tunda, et see on ebasoodne (või vähemalt takistab teisi liikmeid ellu jäämast) ja signaalida hardware watchdog rikkuva sõlme väljalülitamise vajadusest.

Kvoorum aitab mõlema meetodi - otseste ja kaudsete - kasutamisel.

Otsene piiramine

Otsese piiramise korral saame kasutada kvoorumit, et vältida piiramisvõistlusi võrgu rikke korral.

Kvoorumi mõiste alusel on süsteemis piisavalt teavet (isegi ilma partneritega ühendamata), et sõlmed automaatselt teaksid, kas nad peaksid käivitama piiramise ja/või taastamise.

Ilma kvoorumita eeldavad mõlemad võrgu jagamise pooled õigustatult, et teine pool on surnud, ja püüdlevad teise piiramiseks. Halvimal juhul õnnestub mõlemal osapoolel välja lülitada kogu klaster. Alternatiivne stsenaarium on deathmatch, lõputu tsükkel sõlmedest, kes ilmuvad, ei näe oma kaaslasi, taaskäivitatakse ja lähevad taastamisele, vaid taaskäivituvad, kui nende kaaslane järgib sama loogikat.

Probleem, mis seondub eraldamisega, seisneb selles, et enimkasutatavad seadmed muutuvad kergesti kättesaamatuks samade rikke tõttu, millele me taastumise ajal tugineda soovime. Enamiku IPMI ja iLO kaardid on installitud hostidele, mida nad haldavad, ja vaikimisi kasutavad nad sama võrku, mistõttu siht sõlmed arvavad, et teised sõlmed on offline.

Kahjuks harva arvestatakse IPMI ja iLo seadmete töö eripära riistvara ostmise hetkel.

Kaudne eraldamine

Kvoorum on samuti oluline kaudsete eraldamiste haldamiseks. Kui kõik on õigesti tehtud, võib kvoorum võimaldada ellujäänud sõlmedel oletada, et kadunud sõlmed lähevad teatud aja pärast turvalisse olekusse.

Antud seadistusega lähtestatakse riistvara watch-dog taimer iga N sekundi järel, kui kvoorum ei ole kadunud. Kui taimer (tavaliselt mitme N kordsena) aegub, siis seade sooritab ebakorrapärase väljalülitamise (mitte shutdown).

See lähenemine on väga efektiivne, kuid ilma kvoorumita selle haldamiseks pole klastris piisavalt teavet. Võrgu katkestamise ja partner-sõlme rikke vahelise erinevuse tuvastamine pole lihtne. Sellel on tähtsus, kuna kui ei saa eristada kahte juhtu, tuleb valida sama käitumismood mõlemal juhul.

Probleem ühe režiimi valimisega on see, et ei ole ühtegi tegevusviisi, mis maksimaalselt suurendaks kättesaadavust ja takistaks andmete kadu.

• Kui otsustate oletada, et partner-sõlm on aktiivne, kuid tegelikult on juhtunud rike, siis klaster lõpetab üleliigsed teenused, mis peaksid töötama kukkunud partner-sõlme teenuste kaotuse kompenseerimiseks.
• Kui arvate, et sõlm ei tööta, kuid see oli lihtsalt võrgu rike ja tegelikult kaugsõlm töötab, siis parimal juhul leppite tulevikus mingisse käsitsi sünkroniseeritud andmekogude komplekti.

Ükskõik, millist heuristikat te kasutate, on triviaalne tekitada rike, mis kas sunnib mõlemaid poole töötama või sunnib klastrit välja lülitama ellujäänud sõlmed. Kvoorumi mittesaatmine jätab klastrilt ühe tema võimsama tööriista.

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

Kvoorum

Kvoorum kõlab suurepäraselt, eks?

Ainuke puudus on see, et N liikmega klastris peab N / 2 + 1 teie sõlmedest ühenduses olema. See on võimatu kahel sõlmelise klastriga, kui üks sõlm ebaõnnestub.

See viib meid lõpuks kahe sõlme põhiküsimuseni:
kvoorum ei oma mõtet kahe sõlmega klastrites ja ilma selleta ei ole usaldusväärselt võimalik määrata tegevussuunda, mis maksimeerib kättesaadavust ja ennetab andmete kadumist.
Isegi kahek-sõlmelises süsteemis, mis on ühendatud ristkaabliga, pole võimalik lõplikult eristada võrgu väljalülitamist ja teise sõlme tõrget. Ühe otsa väljalülitamine (mille tõenäosus on kindlasti proportsionaalne sõlmede vahelise kaugusega) on piisav, et kehtetuks muuda igasugune eeldus, et kanali töövõime on sama, mis partner-sõlme tervis.

Kaks sõlme töötama pannud klaster

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

Variant 1 - Dubleerimisvõistluse meetod

Sõlme iLO või IPMI seade on tõrkepunkt, kuna ebaõnnestumise korral ei saa elusolevad seda kasutada sõlme turvalisse olekusse viimiseks. Kolm või enam sõlme sisaldavas klastris saame seda pehmendada kvoorumi arvutamise ja riistvara vahekäigu (hardware watchdog) kasutamisega, nagu varem arutatud. Kahe sõlme puhul peame selle asemel kasutama võrgu toitejuhtmeid (power distribution units või PDUs).

Pärast riket püüab ellu jäänud esmalt ühendust võtta põhiseadmest, vahekäigust (sisseehitatud iLO või IPMI). Kui see õnnestub, jätkub taastamine tavapäraselt. Ainult iLO/IPMI seadme tõrke korral pöördutakse PDU poole, kusjuures kui ühendus õnnestub, võib taastamine jätkuda.

Veenduge, et PDU on ühendatud võrguga, mis on eraldi klastritrafikust, vastasel juhul blokeerib üksik võrguhäire juurdepääsu nii varustuse eraldajatele kui ka teenuste taastamise.

Siin saate küsida – kas PDU-seade ei ole ainus rikkepunkt? Vastus on – loomulikult on.

Kui see risk on teie jaoks oluline – te ei ole üksi: ühendage mõlemad sõlmed kahe PDU-ga ja määrake klastritarkvarale, et see kasutaks mõlemat sõlme sisselülitamisel ja väljalülitamisel. Nüüd jääb klaster aktiivseks, kui üks PDU sureb, ja taastamise blokeerimiseks on vajalik teise PDU või IPMI seadme rike.

Variant 2 – Arbitraari lisamine

Mõnedes stsenaariumides, kuigi tehnikaliselt on võimalik dubleeriva eraldamise meetod, on see poliitiliselt keeruline. Paljud ettevõtted soovivad, et administraatorite ja rakenduste omanike vahel oleks teatud eraldatus, ja võrguadministraatorid, kes hoolivad turvalisusest, ei pruugi alati olla innukad kellegile PDU-juurdepääsu parameetreid andma.

Sellisel juhul on soovitatav alternatiiv luua neutraalne kolmas osapool, mis suudab täiendada kvoori arvutust.

Rikke korral peab sõlm olema võimeline nägema oma partneri või arbitraari eeteret, et taastada teenused. Arbitraar sisaldab ka ühenduse katkestamise funktsiooni, kui mõlemad sõlmed saavad näha arbitraari, kuid ei näe üksteist.

Seda valikut tuleks kasutada koos kaudse eraldamise meetodiga, nagu riistvaralise vahtkonna taimer, mis on seadistatud masin välja lülitama, kui see kaotab ühenduse oma partneri ja arbitraariga. Nii võib ellujäänud usaldusväärselt eeldada, et tema partnerisõlm on riistvaravahtkonna taimeri aegumise pärast ohutusolukorras.

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

Variant 3 – Inimfaktor

Viimane lähenemine on see, et ellujäänud jätkavad kõigi varasemate teenuste täitmist, kuid uusi ei käivitata, kuni kas probleem lahendab end ise (võrgu taastamine, sõlme taaskäivitamine) või inimene võtab vastutuse kinnitamiseks, et teine pool on surnud.

Boonuse valik

Kas ma juba mainisin, et saate lisada kolmanda sõlme?

Kaks riiulit

Argumentide nimel oletame, et ma veenin teid kolmanda sõlme eeliste osas, nüüd peame vaatama sõlmede füüsilist asukohta. Kui need asuvad (ja saavad toidet) samas riiulis, esindab see samuti SPoF-i, millest ei saa üle, lisades teise riiuli.

Kui see on üllatav, mõelge sellele, mis juhtub, kui kahe sõlmega riiul rikki läheb, ja kuidas ellujäänud sõlm seda juhtumit ja võrgu tõrke eristab.

Lühike vastus: see on võimatu, ja me seisame taas silmitsi kõikide probleemidega, mis kaasnevad kahete sõlmega. Kas ellujäänud:

• ignoreerib kvoorumit ja valehäirega püüab algatada taastumist võrgu katkemise ajal (võimalus eraldumise lõpetamiseks on eraldi teema ja sõltub sellest, kas PDU on kaasatud ja kas nad jagavad toidet mõne riiuliga), või
• arvestab kvoorumiga ja katkestab end enne tähtaega, kui tema partner sõlm ebaõnnestub.

Igatahes, kaks riiulit ei ole paremad kui üks, ja sõlmed peavad kas saama sõltumatud toiteseadmed või olema jaotatud kolmele (või rohkem, sõltuvalt sellest, kui palju teil sõlmi on) riiulile.

Kaks and keskpunkti

Selleks hetkeks võivad lugejad, kes ei ole enam riskialti, hakata mõtlema hädaolukorra taastamisele. Mis juhtub, kui asteroid tabab ühte andmekeskust, kus meie kolm sõlme on jaotatud kolme erineva riiuli vahel? Ilmselgelt halvasti, kuid sõltuvalt 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 ühtse koopia teie teenustest ja nende andmetest. Siiski, nagu kahe sõlme ja kahe riiuli stsenaariumide puhul, ei ole süsteemis piisavalt teavet, et tagada maksimaalne saadavus ja vältida kahjustusi (või andme kogumite lahknevusi). Isegi kui kolm sõlme (või riiulit) kasutatakse, jätab nende jaotamine ainult kahe andmekeskuse vahel süsteemi kindlusetuks, et langetada õige otsus juhtudel, mis võib olla (nüüd palju tõenäolisem) sündmus, mille mõlemad pooled ei suuda seostada.

See ei tähenda, et kahe andmekeskuse lahendus ei sobi kunagi. Ettevõtted soovivad sageli, et inimene oleks teadlik, enne kui astuda erakorraline samm üleminekul varuandmekeskusele. Lihtsalt pidage meeles, et kui soovite tõrkeautomaatikat, on teil vaja kas kolmandat andmekeskust, et kvoorum oleks mõistlik (otse või vahendaja kaudu), või peate leidma viisi, kuidas usaldusväärselt kogu andmekeskus välja lülitada.

Allikas: habr.com