Kaixo, Habr! Artikuluaren itzulpena aurkezten dizuet Egilea: Andrew Beekhof.
Jende askok nahiago ditu bi nodoko klusterrak, kontzeptualki sinpleagoak diruditelako eta hiru nodokoek baino %33 merkeagoak direlako. Nahiz eta nahiko posible den bi nodoko multzo on bat osatzea, kasu gehienetan, kontuan hartu gabeko eszenatokiak direla eta, horrelako konfigurazio batek begi-bistako arazo asko sortuko ditu.
Erabilgarritasun handiko edozein sistema sortzeko lehen urratsa hutsegite puntu indibidualak aurkitzea eta kentzen saiatzea da, sarritan laburtuta. SPoF (huts-puntu bakarra).
Kontuan izan behar da ezinezkoa dela edozein sistematan geldialdirako arrisku posible guztiak kentzea. Arriskuaren aurkako defentsa tipiko bat erredundantziaren bat sartzea dela eta horrek sistemaren konplexutasuna areagotzea eta hutsegite puntu berriak agertzea dakar. Hori dela eta, hasiera batean konpromisoa hartzen dugu eta hutsegite puntu indibidualekin lotutako gertakarietan zentratzen gara, eta ez erlazionatutako eta, beraz, gero eta probabilitate gutxiagoko gertakarien kateetan.
Konpromisoak kontuan hartuta, SPoF bilatzen ez ezik, arriskuak eta ondorioak ere orekatzen ditugu, eta ondorioz, zer den kritikoa eta zer ez denaren ondorioa desberdina izan daiteke hedapen bakoitzean.
Denek ez dute elektrizitate hornitzaile alternatiborik behar linea elektriko independenteak dituztenak. Nahiz eta paranoiak ordaina eman zion bezero bati gutxienez, haien monitorizazioak transformadore akastun bat detektatu zuenean. Bezeroak telefono-deiak egin zituen elektrizitate-konpainia abisatu nahian, transformadore akastuna lehertu zen arte.
Abiapuntu naturala sisteman nodo bat baino gehiago izatea da. Hala ere, sistemak hutsegite baten ondoren bizirik dauden nodora zerbitzuak mugitu aurretik, oro har, mugitzen ari diren zerbitzuak beste nonbait aktibo ez daudela ziurtatu behar du.
Ez dago bi nodoko kluster batek hutsegite batek bi nodoek webgune estatiko bera hornitzen badute. Hala ere, gauzak aldatu egiten dira, ondorioz, bi alderdiek modu independentean kudeatzen badute partekatutako lan-ilara bat edo koordinatu gabeko idazketa-sarbidea ematen badute erreplikatutako datu-base edo partekatutako fitxategi-sistema batera.
Hori dela eta, nodo bakarreko hutsegite baten ondorioz datuak usteltzea saihesteko - izeneko zerbaitetan oinarritzen gara "disoziazioa" (esgrima).
Disoziazioaren printzipioa
Disoziazioaren printzipioaren muinean galdera dago: lehian dauden nodo batek eragin dezake datuen ustelkeria? Datuen ustelkeria agertoki posiblea bada, irtenbide ona izango litzateke nodoa sarrerako eskaeretatik eta biltegiratze iraunkorretatik isolatzea. Desasoziaziorako ohikoena nodo akastunak deskonektatzea da.
Disoziazio metodoen bi kategoria daude, deituko ditudanak zuzeneko ΠΈ zeharkakoa, baina berdin dei daitezke aktiboa ΠΈ pasiboa. Metodo zuzenek bizirik dauden kideen ekintzak barne hartzen dituzte, hala nola IPMI (Intelligent Platform Management Interface) edo iLO (zerbitzariak sarbide fisikorik ez dagoenean zerbitzariak kudeatzeko mekanismoa) gailu batekin elkarrekintza, zeharkako metodoek huts egin dutenean oinarritzen diren bitartean. nodoa nolabait osasungaitz egoeran dagoela aitortzeko (edo, gutxienez, beste kide batzuk berreskuratzea eragozten) eta seinale huts egin duen nodoa deskonektatu beharrari buruz.
Quorumak metodo zuzenak zein zeharkakoak erabiltzen laguntzen du.
Zuzeneko disoziazioa
Zuzeneko disoziazioaren kasuan, quoruma erabil dezakegu disoziazio lasterketak saihesteko sarearen hutsegiterik gertatuz gero.
Quorum kontzeptuarekin, sisteman informazio nahikoa dago (bere kideekin konektatu gabe ere) nodoek automatikoki jakin dezaten disoziazioa eta/edo berreskurapena hasi behar duten ala ez.
Quorumik gabe, sare-zatiketaren bi aldeek arrazoiz suposatuko dute beste aldea hilda dagoela eta bestea deskonektatzea bilatuko dute. Kasurik txarrenean, bi aldeek kluster osoa ixtea lortzen dute. Eszenatoki alternatibo bat deathmatch bat da, nodoen begizta amaigabea sortzen da, haien parekoak ez ikusi, berrabiarazi eta berreskurapena abiaraztea bere kideek logika bera jarraitzen duenean bakarrik berrabiarazi.
Desasoziazioaren arazoa da gehien erabiltzen diren gailuak erabilgarri gelditzen direla berreskuratzera bideratu nahi ditugun hutsegite-gertaera berdinengatik. IPMI eta iLO txartel gehienak kontrolatzen dituzten ostalarietan instalatuta daude eta, lehenespenez, sare bera erabiltzen dute, eta horrek helburuko ostalariek beste ostalari batzuk lineaz kanpo daudela uste dute.
Zoritxarrez, IPMI eta iLo gailuen funtzionamendu-ezaugarriak oso gutxitan hartzen dira kontuan ekipamendua erosteko unean.
Zeharkako disoziazioa
Quoruma ere garrantzitsua da zeharkako desasoziazioa kudeatzeko; behar bezala egiten bada, quorum-ek bizirik irauten dutenek denbora-tarte jakin baten ondoren galdutako nodoak egoera seguru batera igaroko direla pentsa dezakete.
Konfigurazio honekin, hardware-zaintzako tenporizadorea berrezartzen da N segundoro quoruma galtzen ez bada. Tenporizadorea (normalean N-ren hainbat multiplo) iraungitzen bada, gailuak itzali gabeko itzali egiten du (ez itzaltzen).
Ikuspegi hau oso eraginkorra da, baina quorumik gabe ez dago klusterraren barruan informazio nahikorik hura kudeatzeko. Ez da erraza sarearen etenaren eta pareko nodoen hutsegitearen arteko aldea esatea. Horrek axola duen arrazoia da bi kasuak bereizteko gaitasunik gabe jokabide bera aukeratzera behartuta zaudela bi kasuetan.
Modu bat aukeratzearen arazoa da ez dagoela erabilgarritasuna maximizatzen duen eta datuak galtzea saihesten duen ekintza-biderik.
- Nodo parekide bat aktibo dagoela baina benetan huts egiten duela suposatzea aukeratzen baduzu, klusterrak alferrik geldituko ditu exekutatuko liratekeen zerbitzuak, huts egin duen nodo pareko zerbitzuen galera konpentsatzeko.
- Nodo bat erorita dagoela suposatzea erabakitzen baduzu, baina sarearen hutsegite bat besterik ez da izan eta, hain zuzen ere, urruneko nodoa funtzionala bada, orduan, onenean, etorkizuneko datu-multzoen eskuzko bateratze baterako sinatzen ari zara.
Erabiltzen duzun heuristika edozein dela ere, hutsala da bi aldeek huts egingo duten edo klusterrak bizirik dauden nodoak ixtea eragingo duen hutsegite bat sortzea. Quoruma ez erabiltzeak benetan kentzen dio multzoari bere armategiko tresnarik indartsuenetako bat.
Beste alternatibarik ez badago, hurbilketarik onena erabilgarritasuna sakrifikatzea da (hemen egileak CAP teoremara aipatzen du). Hondatutako datuen erabilgarritasun handiak ez dio inori laguntzen, eta datu multzo desberdinak eskuz bateratzea ere ez da dibertigarria.
Quoruma
Quoruma oso ona da, ezta?
Alde txar bakarra da N kide dituen kluster batean edukitzeko, geratzen diren nodoen N/2+1 arteko konexioa izan behar duzula. Hori ez da posible bi nodoen kluster batean, nodo batek huts egin ondoren.
Horrek, azken batean, bi nodoren oinarrizko arazora eramaten gaitu:
Quorumak ez du zentzurik bi nodo-klusteretan, eta hori gabe ezinezkoa da erabilgarritasuna maximizatzen duen eta datu-galera saihesten duen ekintza-bidea fidagarritasunez zehaztea.
Kable gurutzatuaren bidez konektatutako bi nodoko sisteman ere, ezinezkoa da behin betiko bereiztea sarearen eten bat eta beste nodoaren hutsegite bat. Mutur bat desgaitzea (horren probabilitatea, noski, nodoen arteko distantziarekiko proportzionala da) nahikoa izango da loturaren osasuna bazkide nodoaren osasunaren berdina den edozein suposizio baliogabetzeko.
Bi nodoko kluster bat funtzionatzea
Batzuetan bezeroak ezin du hirugarren nodo bat erosi edo ez du nahi, eta alternatiba bilatzera behartuta gaude.
1. aukera - Bikoiztutako disoziazio metodoa
Nodo baten iLO edo IPMI gailuak hutsegite puntu bat adierazten du, izan ere, huts egiten badu, bizirik daudenek ezin dute erabili nodoa egoera segurura eramateko. 3 nodo edo gehiagoko kluster batean, hori arindu dezakegu quoruma kalkulatuz eta hardwarearen zaintzaile bat erabiliz (zeharkako desasoziazio mekanismoa, lehen aipatu bezala). Bi nodoren kasuan, sareko potentzia banatzeko unitateak (PDU) erabili behar ditugu horren ordez.
Hutsegite baten ondoren, bizirik ateratakoa lehenik eta behin desasoziazio-gailu nagusiarekin harremanetan jartzen saiatzen da (iLO edo IPMI txertatua). Hau arrakastatsua bada, berreskuratzeak ohi bezala jarraitzen du. iLO/IPMI gailuak huts egiten badu soilik atzitzen da PDUra; sarbidea arrakastatsua bada, berreskuratzeak jarraitu ahal izango du.
Ziurtatu PDU klusterreko trafikoa ez den beste sare batean jartzen duzula, bestela sareko hutsegite bakarrak bi desasoziazio gailuetarako sarbidea blokeatuko du eta zerbitzuen berrezarpena blokeatuko du.
Hemen galdetu dezakezu: PDU hutsegite puntu bakarra al da? Zein da erantzuna, noski.
Arrisku hau garrantzitsua bada zuretzat, ez zaude bakarrik: konektatu bi nodoak bi PDUtara eta esan clustering softwareari biak erabiltzeko nodoak piztean eta itzaltzean. Orain klusterrak aktibo jarraitzen du PDU bat hiltzen bada, eta beste PDUren edo IPMI gailuaren bigarren hutsegite bat beharko da berreskurapena blokeatzeko.
2. aukera - Arbitro bat gehitzea
Eszenatoki batzuetan, bikoiztutako desasoziazio metodoa teknikoki posible den arren, politikoki zaila da. Enpresa askok administratzaileen eta aplikazioen jabeen artean nolabaiteko bereizketa izatea gustatzen zaie, eta segurtasuna duten sare-administratzaileak ez dira beti gogotsu egoten PDU sarbide-ezarpenak inorekin partekatzeko.
Kasu honetan, gomendatutako alternatiba hirugarren neutral bat sortzea da, quorumaren kalkulua osatzeko.
Hutsegite bat gertatuz gero, nodo batek bere pareko edo arbitroaren uhinak ikusteko gai izan behar du zerbitzuak leheneratzeko. Arbitroak deskonektatzeko funtzio bat ere barne hartzen du bi nodoek arbitroa ikusten badute baina elkar ikusi ezin badute.
Aukera hau zeharkako desasoziazio-metodo batekin batera erabili behar da, esate baterako, hardware-zaintzako tenporizadore batekin, makina bat hiltzeko konfiguratuta dagoena bere pareko eta arbitro-nodoarekin konexioa galtzen badu. Horrela, bizirik irauten duen batek zentzuz pentsa dezake bere pareko nodoa egoera seguruan egongo dela hardware-zaintzako tenporizadorea iraungi ondoren.
Arbitro baten eta hirugarren nodo baten arteko desberdintasun praktikoa da arbitro batek askoz baliabide gutxiago behar dituela funtzionatzeko eta potentzialki kluster bat baino gehiago balio dezakeela.
3. aukera - Giza faktorea
Azken planteamendua bizirik daudenek lehendik exekutatzen zituzten zerbitzuak exekutatzen jarraitzea da, baina berririk ez abiatzea arazoa bera konpondu arte (sarea berrezartzea, nodoa berrabiarazi) edo pertsona batek beste aldea hilda dagoela eskuz berresteko ardura hartzen duen arte.
Bonus aukera
Hirugarren nodo bat gehi dezakezula aipatu dut?
Bi rack
Argudioaren mesedetan, demagun hirugarren nodoaren merituez konbentzitu zaitudala, orain nodoen antolaketa fisikoa kontuan hartu behar dugu. Rack berean kokatuta (eta elikatuta) badaude, honek SPoF ere osatzen du, eta bigarren rack bat gehituz konpondu ezin dena.
Hau harrigarria bada, kontuan hartu zer gertatuko litzatekeen bi nodo dituen rack batek huts egingo balu, eta bizirik dagoen nodoak nola bereiziko lukeen hori eta sareko hutsegite bat.
Erantzun laburra hau ez dela posible da, eta bi nodoen kasuan arazo guztiekin ari gara berriro. Edo bizirik atera:
- Quorum-a alde batera uzten du eta sarearen etenaldietan berrezarkuntza abiarazten saiatzen da (disoziazioa osatzeko gaitasuna beste istorio bat da eta PDUk parte hartzen duen ala ez eta boterea rackren batekin partekatzen duen ala ez) edo
- quoruma errespetatzen du eta bere burua lehenago deskonektatzen du bere pareko nodoak huts egiten duenean
Nolanahi ere, bi rack ez dira bat baino hobeak, eta nodoek elikadura-iturri independenteak jaso behar dituzte edo hiru (edo gehiago, zenbat nodo dituzun) racketan banatuta egon behar dute.
Bi datu-zentro
Puntu honetan, arriskurik ez duten irakurleek hondamendien berreskurapena kontuan hartu nahi dute. Zer gertatzen da asteroide batek datu-zentro bera jotzen duenean gure hiru nodoak hiru bastidor ezberdinetan banatuta? Gauza txarrak noski, baina zure beharren arabera, baliteke bigarren datu-zentro bat gehitzea nahikoa ez izatea.
Ondo egiten bada, bigarren datu-zentroak zure zerbitzuen eta haien datuen kopia eguneratua eta koherentea eskaintzen dizu (eta arrazoiz). Hala ere, bi nodo eta bi rack agertokietan bezala, ez dago sisteman informazio nahikorik erabilgarritasun handiena bermatzeko eta ustelkeria (edo datu multzoen desadostasunak) saihesteko. Nahiz eta hiru nodo (edo rack) izan, bi datu-zentrotan bakarrik banatzeak sistemak ezin du erabaki egokia modu fidagarrian hartu bi alderdiek komunikatu ezin duten gertaera bat gertatuz gero (orain askoz ere litekeena da).
Horrek ez du esan nahi datu-zentro bikoitzeko irtenbidea inoiz egokia denik. Enpresek sarritan nahi dute pertsona bat jakitun izatea babeskopiko datu-zentro batera eramateko aparteko urratsa eman aurretik. Kontuan izan etenaldia automatizatu nahi baduzu, hirugarren datu-zentro bat beharko duzula quoruma zentzua izan dezan (zuzenean edo arbitro baten bidez), edo datu guztiak modu fidagarrian ixteko modu bat aurkituko duzula. zentroa.
Iturria: www.habr.com