Tere Habr! Esitan teie tähelepanu artikli tõlkele autor Andrew Beekhof.
Paljud inimesed eelistavad kahe sõlmega klastreid, kuna need tunduvad põhimõtteliselt lihtsamad ja on ka 33% odavamad kui nende kolme sõlmega analoogid. Kuigi kahest sõlmest on täiesti võimalik kokku panna hea klaster, tekitab selline konfiguratsioon enamikul juhtudel läbimõtlematute stsenaariumide tõttu palju ilmselgeid probleeme.
Esimene samm kõrge kättesaadavusega süsteemi loomisel on leida ja püüda kõrvaldada üksikud tõrkepunktid, mida sageli lühendatakse kui SPoF (üks tõrkepunkt).
Tasub meeles pidada, et kõiki võimalikke seisaku riske on võimatu üheski süsteemis kõrvaldada. See tuleneb tõsiasjast, et tüüpiline kaitse riskide vastu on koondada, mis suurendab süsteemi keerukust ja uute tõrkepunktide ilmnemist. Seetõttu teeme esialgu kompromissi ja keskendume sündmustele, mis on seotud üksikute ebaõnnestumispunktidega, mitte seotud ja seetõttu üha vähem tõenäolisemate sündmuste ahelatega.
Arvestades kompromisse, ei otsi me mitte ainult SPoF-i, vaid tasakaalustame ka riske ja tagajärgi, mille tulemusena võib järeldused selle kohta, mis on kriitiline ja mis mitte, iga kasutuselevõtu puhul erineda.
Mitte igaüks ei vaja sõltumatute elektriliinidega alternatiivseid elektritarnijaid. Kuigi paranoia tasus end ära vähemalt ühe kliendi jaoks, kui nende jälgimine tuvastas vigase trafo. Klient helistas, püüdes elektrifirmat hoiatada, kuni vigane trafo plahvatas.
Loomulik lähtepunkt on see, et süsteemis on rohkem kui üks sõlm. Kuid enne kui süsteem saab pärast riket teenuseid allesjäänud sõlme teisaldada, peab see üldiselt tagama, et teisaldatavad teenused ei oleks mujal aktiivsed.
Kahe sõlmega klastril pole varjukülgi, kui rikke tõttu teenindavad mõlemad sõlmed sama staatilist veebisaiti. Asjad aga muutuvad, kui tulemuseks on see, et mõlemad osapooled haldavad iseseisvalt jagatud tööjärjekorda või annavad kooskõlastamata kirjutusjuurdepääsu kopeeritud andmebaasile või jagatud failisüsteemile.
Seetõttu, et vältida andmete riknemist ühe sõlme tõrke tagajärjel - tugineme millelegi, mida nimetatakse "dissotsiatsioon" (vehklemine).
Dissotsiatsiooni põhimõte
Dissotsiatsioonipõhimõtte keskmes on küsimus: kas konkureeriv sõlm võib põhjustada andmete rikkumist? Kui andmete rikkumine on tõenäoline, oleks hea lahendus isoleerida sõlm nii sissetulevatest päringutest kui ka püsivast salvestusruumist. Kõige tavalisem lahtiühendamisviis on vigaste sõlmede lahtiühendamine.
Dissotsiatsioonimeetoditel on kaks kategooriat, mida ma nimetan sirge и kaudne, kuid neid võib võrdselt nimetada aktiivne и passiivne. Otsesed meetodid hõlmavad ellujäänud kaaslaste tegevusi, näiteks interaktsiooni IPMI (intelligentse platvormi haldusliides) või iLO (serverite haldamise mehhanism neile füüsilise juurdepääsu puudumisel) seadmega, samas kui kaudsed meetodid tuginevad ebaõnnestunud seadmetele. sõlme, et kuidagi ära tunda, et see on ebatervislikus seisundis (või vähemalt takistab teistel liikmetel taastumast) ja annab märku ebaõnnestunud sõlme lahtiühendamise vajaduse kohta.
Kvoorum aitab nii otseste kui kaudsete meetodite kasutamisel.
Otsene dissotsiatsioon
Otsese dissotsiatsiooni korral saame kasutada kvoorumit, et vältida dissotsiatsioonivõistlusi võrgu rikke korral.
Kvoorumi kontseptsiooni puhul on süsteemis piisavalt teavet (isegi ilma kaaslastega ühenduse loomiseta), et sõlmed teaksid automaatselt, kas nad peaksid algatama dissotsiatsiooni ja/või taastamise.
Ilma kvoorumita eeldavad võrgulõhe mõlemad pooled õigustatult, et teine pool on surnud, ja püüavad teineteist lahutada. Halvimal juhul õnnestub mõlemal osapoolel kogu klaster kinni panna. Alternatiivne stsenaarium on surmamatš, lõputu sõlmede silmus, mis ei näe oma eakaaslasi, taaskäivitab neid ja käivitab taastamise ainult taaskäivitamiseks, kui nende kolleeg järgib sama loogikat.
Lahutamise probleem seisneb selles, et kõige sagedamini kasutatavad seadmed muutuvad kättesaamatuks samade tõrkesündmuste tõttu, mida tahame taastamiseks sihtida. Enamik IPMI- ja iLO-kaarte on installitud nende jälgitavatesse hostidesse ja kasutavad vaikimisi sama võrku, mis paneb sihthostid uskuma, et teised hostid on võrguühenduseta.
Kahjuks arvestatakse IPMI ja iLo seadmete tööomadusi seadmete ostmisel harva.
Kaudne dissotsiatsioon
Kvoorum on oluline ka kaudse disassotsiatsiooni haldamiseks; kui see on õigesti tehtud, võib kvoorum lubada ellujäänutel eeldada, et kaotatud sõlmed lähevad teatud aja möödudes ohutusse olekusse.
Selle konfiguratsiooni korral lähtestatakse riistvaravalve taimer iga N sekundi järel, kui kvoorum ei kao. Kui taimer (tavaliselt mitu korda N) aegub, teostab seade ebagraatsilise väljalülitamise (mitte väljalülitamise).
See lähenemisviis on väga tõhus, kuid ilma kvoorumita pole klastris piisavalt teavet selle haldamiseks. Võrgukatkestuse ja partnersõlme rikke vahel pole lihtne vahet teha. Põhjus, miks see on oluline, on see, et kui te ei suuda neid kahte juhtumit eristada, olete sunnitud valima mõlemal juhul sama käitumise.
Ühe režiimi valimise probleem seisneb selles, et puudub tegevussuund, mis maksimeerib kättesaadavust ja hoiab ära andmete kadumise.
- Kui otsustate eeldada, et partnersõlm on aktiivne, kuid tegelikult ebaõnnestub, peatab klaster asjatult teenused, mis töötaksid, et kompenseerida ebaõnnestunud partnersõlme teenuste kadumist.
- Kui otsustate eeldada, et sõlm on maas, kuid see oli lihtsalt võrgutõrge ja tegelikult kaugsõlm töötab, siis parimal juhul registreerute saadud andmekogumite edaspidiseks käsitsi vastavusseviimiseks.
Olenemata sellest, millist heuristikat te kasutate, on triviaalne tekitada rike, mis põhjustab mõlema poole ebaõnnestumise või põhjustab klastri ellujäänud sõlmede sulgemise. Kvoorumi mittekasutamine jätab klastri tõeliselt ilma ühest võimsaimast tööriistast selle arsenalis.
Kui muud alternatiivi pole, on parim lähenemine ohverdada kättesaadavus (siin viitab autor CAP teoreemile). Rikutud andmete kõrge kättesaadavus ei aita kedagi ja ka erinevate andmekogumite käsitsi kokkusobitamine pole lõbus.
Kvoorum
Kvoorum kõlab suurepäraselt, eks?
Ainus negatiivne külg on see, et selleks, et see oleks N liikmega klastris, peab teil olema ühendus allesjäänud sõlmede N/2+1 vahel. Mis pole võimalik kahe sõlme klastris pärast ühe sõlme rikkeid.
Mis lõpuks viib meid kahe sõlmega põhiprobleemi juurde:
Kvoorumil pole kahes sõlmeklastris mõtet ja ilma selleta on võimatu usaldusväärselt kindlaks määrata toimimisviisi, mis maksimeerib saadavuse ja hoiab ära andmete kadumise
Isegi kahest ristkaabliga ühendatud sõlmest koosnevas süsteemis on võimatu lõplikult eristada võrgukatkestust teise sõlme rikkest. Ühe otsa keelamisest (mille tõenäosus on loomulikult võrdeline sõlmede vahelise kaugusega) piisab, et tühistada kõik eeldused, et lingi seisund on võrdne partnersõlme tervisega.
Kahe sõlmega klastri toimimine
Mõnikord ei saa või ei taha klient kolmandat sõlme osta ja oleme sunnitud otsima alternatiivi.
1. võimalus – dissotsiatsioonimeetodi dubleerimine
Sõlme iLO- või IPMI-seade kujutab endast tõrkepunkti, sest tõrke korral ei saa ellujääjad seda kasutada sõlme ohutusse olekusse viimiseks. Kolmest või enamast sõlmest koosnevas klastris saame seda leevendada, arvutades kvoorumi ja kasutades riistvaralist valvekoera (kaudne disassotsiatsioonimehhanism, nagu varem mainitud). Kahe sõlme puhul peame selle asemel kasutama võrgu toitejaotusseadmeid (PDU).
Pärast ebaõnnestumist proovib ellujäänu esmalt ühendust võtta esmase disassotsiatsiooniseadmega (sisseehitatud iLO või IPMI). Kui see õnnestub, jätkub taastumine nagu tavaliselt. PDU-le pääseb juurde ainult siis, kui iLO/IPMI seade ebaõnnestub; kui juurdepääs õnnestub, saab taastamist jätkata.
Asetage PDU kindlasti klastri liiklusest erinevasse võrku, vastasel juhul blokeerib üks võrgutõrge juurdepääsu mõlemale eraldamisseadmele ja blokeerib teenuste taastamise.
Siin võite küsida – kas PDU on üksainus tõrkepunkt? Millele vastus on, loomulikult on.
Kui see risk on teie jaoks oluline, pole te üksi: ühendage mõlemad sõlmed kahe PDU-ga ja öelge rühmitustarkvarale, et sõlmede sisse- ja väljalülitamisel kasutataks mõlemat. Klaster jääb nüüd aktiivseks, kui üks PDU sureb, ja taastamise blokeerimiseks on vaja kas teise PDU või IPMI-seadme teist tõrget.
2. võimalus – vahekohtuniku lisamine
Mõne stsenaariumi korral, kuigi dubleeritud disassotsiatsioonimeetod on tehniliselt võimalik, on see poliitiliselt keeruline. Paljudele ettevõtetele meeldib, kui administraatorid ja rakenduste omanikud on üksteisest eraldatud, ning turvateadlikud võrguadministraatorid ei ole alati entusiastlikud PDU juurdepääsuseadete jagamisest kellegagi.
Sel juhul on soovitatav alternatiiviks luua neutraalne kolmas osapool, kes saaks kvoorumi arvutust täiendada.
Rikke korral peab sõlm teenuste taastamiseks nägema oma partneri või vahekohtuniku laineid. Vahekohtunik sisaldab ka lahtiühendamise funktsiooni, kui mõlemad sõlmed näevad vahekohtunikku, kuid ei näe üksteist.
Seda suvandit tuleb kasutada koos kaudse disassotsiatsioonimeetodiga, nagu riistvaravalve taimer, mis on konfigureeritud tapma masin, kui see kaotab ühenduse oma kaaslase ja vahekohtuniku sõlmega. Seega võib ellujäänu mõistlikult eeldada, et tema partnersõlm on pärast riistvaravalve taimeri aegumist turvalises olekus.
Praktiline erinevus vahekohtuniku ja kolmanda sõlme vahel seisneb selles, et vahekohtunik vajab töötamiseks palju vähem ressursse ja võib potentsiaalselt teenindada rohkem kui ühte klastrit.
3. võimalus – inimfaktor
Viimane lähenemine on see, et ellujäänud jätkavad teenuste kasutamist, mida nad juba kasutasid, kuid ei käivita uusi enne, kui probleem laheneb iseenesest (võrgu taastamine, sõlme taaskäivitamine) või inimene võtab vastutuse teise poole surnud olemise käsitsi kinnitamise eest.
Boonusvõimalus
Kas ma mainisin, et saate lisada kolmanda sõlme?
Kaks riiulit
Vaidluse huvides oletame, et olen teid veennud kolmanda sõlme eelistes, nüüd peame kaaluma sõlmede füüsilist paigutust. Kui need on paigutatud (ja toiteallikaga) samasse riiulisse, on see ka SPoF ja seda ei saa lahendada teise riiuli lisamisega.
Kui see on üllatav, mõelge, mis juhtuks, kui kahe sõlmega rack peaks rikki minema ja kuidas ellujäänud sõlm eristaks seda võrgutõrkest.
Lühike vastus on, et see pole võimalik, ja jällegi tegeleme kõigi probleemidega kahe sõlme puhul. Või ellujäänu:
- ignoreerib kvoorumit ja üritab valesti algatada taastamist võrgukatkestuste ajal (dissotsiatsiooni lõpuleviimise võimalus on erinev lugu ja sõltub sellest, kas PDU on kaasatud ja kas nad jagavad toidet mõne riiuliga) või
- austab kvoorumit ja katkestab end enneaegselt, kui tema partnersõlm ebaõnnestub
Igal juhul ei ole kaks riiulit paremad kui üks ja sõlmed peavad saama sõltumatud toiteallikad või olema jagatud kolme (või enama, sõltuvalt teie sõlmede arvust) vahel.
Kaks andmekeskust
Siinkohal võivad lugejad, kes ei ole enam riskikartlikud, kaaluda katastroofi taastamist. Mis juhtub, kui asteroid tabab sama andmekeskust, mille kolm sõlme on jaotatud kolme erineva riiuli vahel? Ilmselgelt halvad asjad, kuid sõltuvalt teie vajadustest ei pruugi teise andmekeskuse lisamisest piisata.
Kui see on õigesti tehtud, annab teine andmekeskus teile (ja mõistlikult) teie teenuste ja nende andmete ajakohase ja järjepideva koopia. Kuid nagu kahe sõlme ja kahe riiuliga stsenaariumide puhul, ei ole süsteemis piisavalt teavet, et tagada maksimaalne kättesaadavus ja vältida korruptsiooni (või andmekogumi lahknevusi). Isegi kolme sõlme (või püstiku) korral ei saa nende jaotamine ainult kahe andmekeskuse vahel süsteemil usaldusväärselt õiget otsust teha (nüüd palju tõenäolisema) sündmuse korral, mille puhul mõlemad pooled ei saa suhelda.
See ei tähenda, et kahe andmekeskuse lahendus kunagi ei sobiks. Ettevõtted soovivad sageli, et inimene oleks teadlik enne erakorralise sammu astumist varuandmekeskusesse kolimiseks. Pidage lihtsalt meeles, et kui soovite katkestuse automatiseerida, on teil vaja kolmandat andmekeskust, et kvoorum oleks mõttekas (kas otse või vahekohtuniku kaudu) või leiate viisi kogu andmete usaldusväärseks sulgemiseks. Keskus.
Allikas: www.habr.com