Haai Habr! Ek bied die vertaling van die artikel aan u aandag deur Andrew Beekhof.
Baie mense verkies twee-nodus-klusters omdat dit konseptueel eenvoudiger lyk en ook 33% goedkoper is as hul drie-node-eweknieë. Alhoewel dit heel moontlik is om 'n goeie groep van twee nodusse saam te stel, sal so 'n konfigurasie in die meeste gevalle, as gevolg van ondeurdagte scenario's, baie onopvallende probleme skep.
Die eerste stap om enige hoëbeskikbaarheidstelsel te skep, is om individuele punte van mislukking te vind en te probeer uitskakel, dikwels afgekort as SPoF (enkelpunt van mislukking).
Dit is die moeite werd om in gedagte te hou dat dit onmoontlik is om alle moontlike risiko's van stilstand in enige stelsel uit te skakel. Dit spruit uit die feit dat 'n tipiese verdediging teen risiko is om 'n mate van oortolligheid in te voer, wat lei tot verhoogde stelselkompleksiteit en die opkoms van nuwe punte van mislukking. Daarom maak ons aanvanklik 'n kompromie en fokus ons op gebeure wat verband hou met individuele punte van mislukking, en nie op kettings van verwante en dus toenemend minder waarskynlike gebeure nie.
Gegewe die afwegings, soek ons nie net SPoF nie, maar balanseer ook risiko's en gevolge, waardeur die gevolgtrekking van wat krities is en wat nie vir elke ontplooiing kan verskil nie.
Nie almal het alternatiewe elektrisiteitsverskaffers met onafhanklike kraglyne nodig nie. Alhoewel die paranoia vir ten minste een kliënt vrugte afgewerp het toe hul monitering 'n foutiewe transformator opgespoor het. Die kliënt het telefoonoproepe gemaak om die kragmaatskappy te waarsku totdat die foutiewe transformator ontplof het.
'n Natuurlike beginpunt is om meer as een nodus in die stelsel te hê. Voordat die stelsel egter dienste na die oorlewende nodus kan skuif na 'n mislukking, moet dit gewoonlik verseker dat die dienste wat verskuif word nie elders aktief is nie.
Daar is geen nadeel aan 'n twee-node-kluster as 'n mislukking daartoe lei dat beide nodusse dieselfde statiese webwerf bedien nie. Dinge verander egter as die gevolg is dat beide partye onafhanklik 'n gedeelde werkwaglys bestuur of ongekoördineerde skryftoegang tot 'n gerepliseerde databasis of gedeelde lêerstelsel verskaf.
Daarom, om data korrupsie te voorkom as gevolg van 'n enkele nodus mislukking - ons staatmaak op iets genoem "dissosiasie" (omheining).
Die beginsel van dissosiasie
Die kern van die beginsel van dissosiasie is die vraag: kan 'n mededingende nodus datakorrupsie veroorsaak? In die geval dat datakorrupsie 'n waarskynlike scenario is, sal 'n goeie oplossing wees om die nodus te isoleer van beide inkomende versoeke en aanhoudende berging. Die mees algemene benadering tot disassosiasie is om die foutiewe nodusse te ontkoppel.
Daar is twee kategorieë van dissosiasiemetodes, wat ek sal noem reguit и indirekte, maar hulle kan ewe genoem word aktief и passief. Direkte metodes sluit in aksies aan die kant van oorlewende eweknieë, soos interaksie met 'n IPMI (Intelligent Platform Management Interface) of iLO ('n meganisme vir die bestuur van bedieners in die afwesigheid van fisiese toegang daartoe) toestel, terwyl indirekte metodes staatmaak op die mislukte nodus om op een of ander manier te erken dat dit in 'n ongesonde toestand is (of ten minste ander lede verhoed om te herstel) en sein oor die behoefte om die mislukte nodus te ontkoppel.
Kworum help wanneer beide direkte en indirekte metodes gebruik word.
Direkte dissosiasie
In die geval van direkte dissosiasie kan ons kworum gebruik om dissosiasie rasse te voorkom in die geval van 'n netwerk mislukking.
Met die konsep van kworum is daar genoeg inligting in die stelsel (selfs sonder om aan sy eweknieë te koppel) sodat nodusse outomaties kan weet of hulle dissosiasie en/of herstel moet inisieer.
Sonder 'n kworum sal beide kante van 'n netwerkverskil tereg aanvaar dat die ander kant dood is en sal poog om die ander te disassosieer. In die ergste geval slaag albei partye daarin om die hele groepering te sluit. 'n Alternatiewe scenario is 'n deathmatch, 'n eindelose lus van nodusse wat opduik, nie hul eweknieë sien nie, hulle herlaai en herstel net begin om te herlaai wanneer hul eweknie dieselfde logika volg.
Die probleem met disassosiasie is dat die toestelle wat die meeste gebruik word, onbeskikbaar raak as gevolg van dieselfde mislukkingsgebeurtenisse wat ons wil teiken vir herstel. Die meeste IPMI- en iLO-kaarte is geïnstalleer op die gashere wat hulle beheer en gebruik by verstek dieselfde netwerk, wat veroorsaak dat die teikengashere glo dat die ander gashere vanlyn is.
Ongelukkig word die bedryfskenmerke van IPMI- en iLo-toestelle selde oorweeg tydens die aankoop van toerusting.
Indirekte dissosiasie
Kworum is ook belangrik vir die bestuur van indirekte disassosiasie; as dit korrek gedoen word, kan kworum oorlewendes toelaat om te aanvaar dat verlore nodusse na 'n sekere tydperk na 'n veilige toestand sal oorgaan.
Met hierdie konfigurasie word die hardeware waghond timer elke N sekondes teruggestel as kworum nie verlore gaan nie. As die tydhouer (gewoonlik verskeie veelvoude van N) verval, voer die toestel 'n onprettige afskakeling uit (nie afskakel nie).
Hierdie benadering is baie effektief, maar sonder 'n kworum is daar nie genoeg inligting binne die groepering om dit te bestuur nie. Dit is nie maklik om die verskil tussen 'n netwerkonderbreking en 'n eweknie-nodusfout te onderskei nie. Die rede waarom dit saak maak, is dat sonder die vermoë om tussen die twee gevalle te onderskei, jy gedwing word om dieselfde gedrag in albei gevalle te kies.
Die probleem met die keuse van een modus is dat daar geen aksie is wat beskikbaarheid maksimeer en dataverlies voorkom nie.
- As jy kies om aan te neem dat 'n eweknie-nodus aktief is, maar in werklikheid misluk, sal die groep onnodig die dienste stop wat sou loop om te vergoed vir die verlies van dienste vanaf die mislukte eweknie-nodus.
- As jy besluit om te aanvaar dat 'n nodus af is, maar dit was net 'n netwerkfout en in werklikheid is die afgeleë nodus funksioneel, dan teken jy op sy beste in vir 'n toekomstige handrekonsiliasie van die resulterende datastelle.
Ongeag watter heuristiek jy gebruik, is dit onbenullig om 'n mislukking te skep wat óf sal veroorsaak dat beide kante misluk óf veroorsaak dat die groep die oorblywende nodusse afskakel. Om nie kworum te gebruik nie, ontneem die groep werklik van een van die kragtigste instrumente in sy arsenaal.
As daar geen ander alternatief is nie, is die beste benadering om beskikbaarheid op te offer (hier verwys die skrywer na die CAP-stelling). Hoë beskikbaarheid van korrupte data help niemand nie, en om verskillende datastelle handmatig te versoen is ook nie lekker nie.
Kworum
Kworum klink wonderlik, reg?
Die enigste nadeel is dat om dit in 'n groep met N lede te hê, moet jy 'n verbinding hê tussen N/2+1 van jou nodusse wat oorbly. Wat nie moontlik is in 'n groep met twee nodes nadat een nodus misluk het nie.
Wat ons uiteindelik by die fundamentele probleem met twee nodusse bring:
Kworum maak nie sin in twee nodus-klusters nie, en daarsonder is dit onmoontlik om die aksie betroubaar te bepaal wat beskikbaarheid maksimeer en dataverlies voorkom
Selfs in 'n stelsel van twee nodusse wat deur 'n oorkruiskabel verbind is, is dit onmoontlik om definitief te onderskei tussen 'n netwerkonderbreking en 'n mislukking van die ander nodus. Die mislukking van een kant (waarvan die waarskynlikheid natuurlik eweredig is aan die afstand tussen die nodusse) sal genoeg wees om enige aanname ongeldig te maak dat die gesondheid van die skakel gelyk is aan die gesondheid van die vennootknoop.
Om 'n twee-node-kluster te laat werk
Soms kan of wil die kliënt nie 'n derde nodus koop nie, en ons word gedwing om na 'n alternatief te soek.
Opsie 1 - Duplikaat dissosiasie metode
'n Nodus se iLO- of IPMI-toestel verteenwoordig 'n punt van mislukking, want as dit misluk, kan oorlewendes dit nie gebruik om die nodus na 'n veilige toestand te bring nie. In 'n groep van 3 of meer nodusse kan ons dit versag deur kworum te bereken en 'n hardewarewaghond te gebruik ('n indirekte disassosiasiemeganisme, soos vroeër bespreek). In die geval van twee nodusse moet ons eerder netwerkkragverspreidingseenhede (PDU's) gebruik.
Na 'n mislukking probeer die oorlewende eers om die primêre disassosiasietoestel (ingebedde iLO of IPMI) te kontak. As dit suksesvol is, gaan herstel voort soos gewoonlik. Slegs as die iLO/IPMI-toestel misluk, word toegang tot die PDU verkry; as die toegang suksesvol is, kan herstel voortgaan.
Maak seker dat jy die PDU op 'n ander netwerk as die groepverkeer plaas, anders sal 'n enkele netwerkfout toegang tot beide disassosiasietoestelle blokkeer en die herstel van dienste blokkeer.
Hier kan jy vra - is die PDU 'n enkele punt van mislukking? Waarop die antwoord is, natuurlik is dit.
As hierdie risiko vir jou beduidend is, is jy nie alleen nie: koppel albei nodusse aan twee PDU's en vertel die groeperingsagteware om beide te gebruik wanneer die nodusse aan- en afskakel. Die groep bly nou aktief as een PDU sterf, en 'n tweede mislukking van óf die ander PDU óf die IPMI-toestel sal vereis word om herstel te blokkeer.
Opsie 2 - Voeg 'n Arbiter by
In sommige scenario's, terwyl die duplikaat-disassosiasie-metode tegnies moontlik is, is dit polities moeilik. Baie maatskappye hou daarvan om 'n mate van skeiding tussen administrateurs en toepassingseienaars te hê, en sekuriteitsbewuste netwerkadministrateurs is nie altyd entoesiasties om PDU-toegangsinstellings met enigiemand te deel nie.
In hierdie geval is die aanbevole alternatief om 'n neutrale derde party te skep wat die kworumberekening kan aanvul.
In die geval van 'n mislukking moet 'n nodus die luggolwe van sy eweknie of arbiter kan sien om dienste te herstel. Die arbiter sluit ook 'n ontkoppelfunksie in as beide nodusse die arbiter kan sien maar mekaar nie kan sien nie.
Hierdie opsie moet gebruik word in samewerking met 'n indirekte disassosiasiemetode, soos 'n hardeware waghond-tydhouer, wat opgestel is om 'n masjien dood te maak as dit verbinding met sy eweknie- en arbiternodus verloor. Dus, 'n oorlewende kan redelikerwys aanvaar dat sy eweknie-nodus in 'n veilige toestand sal wees nadat die hardeware waghond-tydhouer verstryk het.
Die praktiese verskil tussen 'n arbiter en 'n derde nodus is dat 'n arbiter baie minder hulpbronne benodig om te werk en potensieel meer as een kluster kan bedien.
Opsie 3 - Menslike faktor
Die finale benadering is vir oorlewendes om voort te gaan met die gebruik van watter dienste hulle ook al gebruik het, maar nie nuwes begin nie totdat óf die probleem vanself opgelos is (netwerkherstel, nodus-herlaai) óf 'n persoon neem verantwoordelikheid om handmatig te bevestig dat die ander kant dood is.
Bonus opsie
Het ek genoem dat jy 'n derde nodus kan byvoeg?
Twee rakke
Ter wille van die argument, laat ons maak asof ek jou oortuig het van die meriete van die derde nodus, nou moet ons die fisiese rangskikking van die nodusse oorweeg. As hulle in dieselfde rek gehuisves (en aangedryf word), vorm dit ook SPoF, en een wat nie opgelos kan word deur 'n tweede rek by te voeg nie.
As dit verbasend is, oorweeg wat sal gebeur as 'n rek met twee nodusse misluk, en hoe die oorlewende nodus tussen dit en 'n netwerkfout sal onderskei.
Die kort antwoord is dat dit nie moontlik is nie, en ons het weer te doen met al die probleme in die geval van twee nodusse. Of oorlewende:
- ignoreer kworum en probeer verkeerdelik om herstel te begin tydens netwerkonderbrekings (die vermoë om dissosiasie te voltooi is 'n ander storie en hang daarvan af of die PDU betrokke is en of hulle krag met enige van die rakke deel), of
- respekteer kworum en ontkoppel homself voortydig wanneer sy eweknie-nodus misluk
In elk geval, twee rakke is nie beter as een nie, en die nodusse moet óf onafhanklike kragtoevoer ontvang óf oor drie (of meer, afhangende van hoeveel nodusse jy het) versprei word.
Twee datasentrums
Op hierdie stadium wil lesers wat nie meer risiko-sku is nie dalk rampherstel oorweeg. Wat gebeur wanneer 'n asteroïde dieselfde datasentrum tref met ons drie nodusse versprei oor drie verskillende rakke? Natuurlik slegte dinge, maar afhangende van jou behoeftes, is dit dalk nie genoeg om 'n tweede datasentrum by te voeg nie.
As dit korrek gedoen word, voorsien die tweede datasentrum aan jou (en redelikerwys) 'n bygewerkte en konsekwente kopie van jou dienste en hul data. Soos in twee-nodes, twee-rek scenario's, is daar egter nie genoeg inligting in die stelsel om maksimum beskikbaarheid te verseker en korrupsie (of datastel verskille) te voorkom nie. Selfs met drie nodusse (of rakke), laat die verspreiding daarvan oor slegs twee datasentrums die stelsel nie in staat om betroubaar die regte besluit te neem in die geval van 'n (nou baie meer waarskynlike) gebeurtenis wat beide partye nie kan kommunikeer nie.
Dit beteken nie dat 'n dubbele datasentrumoplossing nooit geskik is nie. Maatskappye wil dikwels hê dat 'n persoon bewus moet wees voordat hy die buitengewone stap neem om na 'n rugsteundatasentrum te skuif. Hou net in gedagte dat as jy die onderbreking wil outomatiseer, jy óf 'n derde datasentrum sal benodig vir kworum om sin te maak (óf direk óf deur 'n arbiter), óf jy sal 'n manier vind om die hele data betroubaar af te sluit sentrum.
Bron: will.com