Përshëndetje, Habr! Ju prezantoj përkthimin e artikullit autor Andrew Beekhof.
Shumë njerëz preferojnë klasterët me dy node, sepse duken konceptualisht më të thjeshtë, dhe gjithashtu janë deri në 33% më të lira se homologët e tyre me tre node. Megjithatë, është krejt e mundur të krijohet një klaster i mirë me dy node, por në shumicën e rasteve, për shkak të skenarëve të papërcaktuar, kjo konfigurim do të krijojë shumë probleme të paqarta.
Hapi i parë për të krijuar çdo sistem të lartë disponueshmërie është identifikimi dhe përpjekja për të eliminuar pikat e vetme të dështimit, shpesh të shkurtra si SPoF (pikë e vetme dështimi).
Duhet të mbani parasysh se në çdo sistem është e pamundur të eliminohen të gjitha rreziqet e mundshme të ndalimit. Kjo rrjedh për të paktën nga fakti se mbrojtja tipike kundër rrezikut është krijimi i një sasi të caktuar të tepricës, e cila çon në rritjen e kompleksitetit të sistemit dhe shfaqjen e pikave të reja të dështimit. Prandaj, fillimisht shkojmë në një kompromis dhe përqendrohemi në ngjarjet që lidhen me pikat e vetme të dështimit, dhe jo në zinxhirët e ngjarjeve të lidhura që për këtë arsye bëhen gjithnjë e më pak të mundura.
Duke marrë parasysh kompromiset, ne jo vetëm që kërkojmë SPoF, por gjithashtu balancojmë rreziqet dhe pasojat, rezultati i të cilave se çfarë është kritike dhe çfarë jo mund të ndryshojë për çdo zbatim.
Jo të gjithë kanë nevojë për furnizues alternativë të energjisë me linja të pavarura të energjisë. Megjithëse paranoia ka rezultuar e dobishme për të paktën një klient, kur monitorimi i tyre zbuloi një transformator të prishur. Klienti kishte telefonuar për të paralajmëruar kompaninë e energjisë, derisa transformatori i prishur shpërtheu.
Një pikë fillimi natyrale është që sistemi të ketë më shumë se një node. Sidoqoftë, para se sistemi të mund të kalojë shërbimet në node-n që mbetet pas një dështimi, në përgjithësi, duhet të sigurohemi se shërbimet që po kalohen nuk janë aktive ndonjë ku tjetër.
Një klaster me dy node nuk ka disavantazhe, nëse si rezultat i dështimit të dy node-t shërbejnë të njëjtin website statik. Sidoqoftë, të gjitha ndryshojnë nëse të dy anët menaxhojnë pavarsisht një radhë të përbashkët të punëve ose ofrojnë qasje të pa koordinuar për të shkruar në një databazë të replikosur ose në një sistem të përbashkët skedari.
Prandaj, për të parandaluar dëmtimin e të dhënave si rezultat i dështimit të një node – ne mbështetemi në atë që quhet «ndarje» (fencing).
Principi i ndarjes
Në thelb, principi i ndarjes nënkupton: a mund të ndodhë që një node konkuruese të shkaktojë dëmtimin e të dhënave? Nëse dëmtimi i të dhënave është një skenar i mundshëm – një zgjidhje e mirë do të ishte izolimi i nodës nga kërkesat hyrëse dhe nga ruajtja e qëndrueshme. Qasja më e zakonshme për ndarjen është shkëputja e node-ve të prishura.
Ka dy kategori metodash ndarjeje, të cilat unë do t'i quaja të drejta dhe të tërthorta, por gjithashtu i quajmë aktive dhe pasive. Metodat e drejta përfshijnë veprime nga node të mbijetuar, si ndërveprimi me pajisjet IPMI (Interfejsi i Menaxhimit të Platformës Inteligjente — interface për monitorimin dhe menaxhimin qëllim për gjendjen fizike të serverit) ose iLO (mekanizmi i menaxhimit të serverëve pa akses fizik në to), ndërsa metodat e tërthorta mbështeten në nodën e dështuar për të njohur ndonjëherë se ajo ndodhet në një gjendje jo të shëndoshë (ose, të paktën, pengon anëtarët e tjerë në rikuperim) dhe për të sinjalizuar në lidhje me nevojën për të shkëputur nodën e prishur.
Kvorumi ndihmon në përdorimin e metodave si të drejta ashtu edhe të tërthorta.
Ndarja e drejtpërdrejtë
Në rastin e ndarjes së drejtpërdrejtë, ne mund të përdorim kvorumin për të parandaluar garat e ndarjes në rastin e një dështimi të rrjetit.
Me konceptin e kvorumit, sistemi ka informacion të mjaftueshëm (edhe pa u lidhur me partnerët e tij) që node-t automatikisht dinë nëse duhet të iniciat shkëputjen dhe / ose rikuperimin.
Pa kvorum, të dy anët e ndarjes së rrjetit do të supozonin drejt për drejt se ana tjetër është e vdekur, dhe do të përpiqeshin për të shkëputur tjetrin. Në skenarin më të keq, të dy anët do të arrijnë të shkëputin të gjithë klasterin. Një skenar alternativ është deathmatch, një cikël të pafund të node-ve që shfaqen, nuk shohin peer-in e tyre, i rihapin ata dhe nisin rikuperimin vetëm për të u rihapur, kur peer-i i tyre kalon përmes së njëjtës logjikë.
Problemi me ndarjen ka të bëjë me faktin se pajisat më të përdorura bëhen të paaksesueshme për shkak të të njëjtave ngjarje dështimi, në të cilat ne dëshirojmë të përqendrohemi për rikuperim. Shumica e kartave IPMI dhe iLO janë instaluar në hostet që ato kontrollojnë dhe, nga e drejta, përdorin të njëjtën rrjetë, duke bërë që node-t e synuara të supozojnë se node-t e tjera janë offline.
Fatkeqësisht, karakteristikat e funksionimit të pajisjeve IPMI dhe iLO rrallë shqyrtohen në momentin e blerjes së pajisjeve.
Ndarje e tërthortë
Kvorumi është gjithashtu i rëndësishëm për menaxhimin e ndarjeve të tërthorta; nëse gjithçka bëhet siç duhet, kvorumi mund të lejojë mbeturinat të supozojnë që node-t e humbura pas një periudhe të caktuar kalojnë në një gjendje të sigurt.
Me një konfigurim të tillë, timeri i watchdog hardware rikthehet çdo N sekonda, nëse kvorumi nuk është humbur. Nëse timeri (zakonisht disa herë N) skadon, pajisja kryen një fikje të papërshtatshme (nuk bën shutdown).
Ky qasje është shumë efektive, por pa kvorum për menaxhimin e tij, ka pak informacion brenda klasterit. Nuk është e lehtë të përcaktohet dallimi mes ndërprerjes së rrjetit dhe dështimit të node-t partner. Arsyetimi përse ky fakt ka rëndësi është se pa aftësinë për të dalluar këto dy raste, ju detyroheni të zgjidhni të njëjtën mënyrë veprimi për të dy rastet.
Problemi me zgjedhjen e një mënyre veprimi është se nuk ekziston një mënyrë veprimi që maksimizon disponueshmërinë dhe parandalon humbjen e të dhënave.
- Nëse vendosni të supozoni se node partner është aktiv, por në të vërtetë ka ndodhur një dështim, klasteri do të ndalë tepër shërbimet që duhet të ishin duke funksionuar për të kompensuar humbjen e shërbimeve të node partner të rënë.
- Nëse vendosni të supozoni se node nuk funksionon, por ishte thjesht një dështim i rrjetit dhe në të vërtetë node i largët funksionon, atëherë, në më të mirën, ju pajtoheni me një rivlerësim manual të grupeve të të dhënave që do të rezultojnë.
Pavarësisht nga heuristika që përdorni, është triviale të krijoni një dështim që ose do të bëjë që të dy palët të funksionojnë, ose do të detyrojë klasterin të çaktivizojë node-t e mbetura. Mospranimi i kvorumit vërtet i privon klasterin nga një nga mjetet më të fuqishme në arsenalin e saj.
Nëse nuk ka një alternativë tjetër, qasja më e mirë do të ishte të sakrifikoni disponueshmërinë (këtu autori referohet te teorema CAP). Disponueshmëria e lartë e të dhënave të dëmtuara nuk ndihmon askënd, dhe rivlerësimi manual i grupeve të ndryshme të të dhënave gjithashtu nuk është kënaqësues.
Kvorumi
Kvorumi tingëllon bukur, a po?
E vetmja pengesë është se për të pasur kvorum në një klaster me N anëtarë, ju nevojitet që të ketë ende një lidhje mes N / 2 + 1 të node-ve tuaj. Kjo është e pamundur në një klaster me dy node pas një dështimi të një node.
Çka na çon në problemin themelor me dy node:
kvorumi nuk ka kuptim në klasterat me dy node, dhe pa të, është e pamundur të përcaktohet me besueshmëri një kurs veprimi që maksimizon disponueshmërinë dhe parandalon humbjen e të dhënave.
Madje edhe në një sistem me dy node, të lidhura me një kabllo kryqëzimi, është e pamundur të krihet me siguri dallimi mes ndërprerjes së rrjetit dhe dështimit të një node tjetër. Ndërprerja e një skaji (probabiliteti i të cilit është ndoshta proporcional me distancën mes node-ve) do të ishte e mjaftueshme për të hedhur poshtë çdo supozim se funksionaliteti i kanalit është i barabartë me shëndetin e node partner.
Të bëjmë që klasteri i dy node-ve të funksionojë
Nganjëherë klienti nuk mund ose nuk dëshiron të blejë një node të tretë, dhe ne detyrohemi të kërkojmë një alternativë.
Zgjidhja 1 - Metoda e dyfishimit të ndarjes
Pajisja iLO ose IPMI e node-t është një pikë dështimi, sepse, në rast dështimi, ato që mbeten nuk mund ta përdorin atë për të transferuar node-n në një gjendje të sigurt. Në një klaster me 3 ose më shumë node, ne mund ta lehtësojmë këtë duke llogaritur kvorumin dhe duke përdorur watchdog hardware (mekanizem ndarjeje të tërthortë, siç u diskutua më parë). Në rastin e dy node, ne duhet të përdorim ndërrues të energjisë (pjesë të shpërndarjes së energjisë ose PDU).
Pas dështimit, ai që mbetet përpiqet fillimisht të lidhet me pajisjen kryesore të ndarjes (iLO ose IPMI të integruar). Nëse kjo është e suksesshme, rikuperimi vazhdon si zakonisht. Vetëm në rast dështimi të pajisjes iLO/IPMI, lidhemi me PDU, nëse lidhja është e suksesshme, rikuperimi mund të vazhdojë.
Sigurohuni të vendosni PDU-në në një rrjet të ndryshëm nga trafiku i grumbullit, përndryshe një dështim i vetëm në rrjet do të bllokojë aksesin si në pajisjet e ndara, ashtu edhe do të bllokojë rikuperimin e shërbimeve.
Këtu mund të pyesni – a është PDU një pikë e vetme dështimi? Përgjigjja është sigurisht që po.
Nëse ky rrezik është i rëndësishëm për ju - nuk jeni vetëm: lidhni të dy njësitë me dy PDU dhe tregoni softuerit të grumbullit të përdorë të dyja kur ndizni ose fikni njësitë. Tani grumbulli mbetet aktiv nëse një PDU dështon, dhe për të bllokuar rikuperimin është e nevojshme një dështim i dytë, qoftë nga PDU tjetër apo nga pajisja IPMI.
Mundësia 2 - Shtimi i një arbitri
Në disa skenarë, megjithëse metoda e ndarjes së dyfishtë është teknikisht e mundur, ajo është politikisht e komplikuar. Shumë kompani preferojnë të kenë një ndarje të qartë midis administratëve dhe pronarëve të aplikacioneve, dhe administratorët e rrjetit që angazhohen për sigurinë nuk janë gjithmonë entuziastë për të dhënë askujt parametrat e aksesit në PDU.
Në këtë rast, alternativa e rekomanduar është krijimi i një palë të tretë neutrale, e cila mund të plotësojë llogaritjen e kuorumit.
Në rast dështimi, njësi duhet të ketë mundësinë të shohë eterin e partnerit të saj ose të arbitrit për të rikuperuar shërbimet. Arbitri gjithashtu përfshin një funksion shkëputjeje nëse të dy njësitë mund të shohin arbitrin, por nuk shohin njëri-tjetrin.
Kjo mundësi duhet të përdoret në çift me një metodë të tërthortë ndarjeje, si një timer hardware watchdog, i cili është i vendosur për të fikur makinën nëse humbet lidhjen me njësinë e saj partnere dhe arbitrin. Në këtë mënyrë, i mbijetuar mund të supozojë me mjaft siguri se njësia e tij partnere do të jetë në një gjendje të sigurt pas skadimit të.timer-it hardware watchdog.
Dallimi praktik midis arbitrit dhe njësisë së tretë është se arbitri kërkon shumë më pak burime për të funksionuar dhe, potencialisht, mund të shërbejë më shumë se një grumbull.
Mundësia 3 - Faktori Njerëzor
Qasja e fundit është që të mbijetuarit të vazhdojnë të kryejnë çdo shërbim që ata tashmë po kryenin, por të mos fillojnë të reja, derisa ose problemi të zgjidhet vetvetiu (rikuperimi i rrjetit, ri-dizanje i njësisë), ose një njeri të marrë përsipër përgjegjësinë për të konfirmuar manualisht që pala tjetër është e vdekur.
Mundësi Bonus
A kam thënë se mund të shtoni një njësi të tretë?
Dy shtylla
Për argumentin, le të supozojmë se ju kam bindur për përfitimet e një njësie të tretë, tani ne duhet të shqyrtojmë vendndodhjen fizike të njësive. Nëse ato janë vendosur (dhe marrin energji) në të njëjtin raf, kjo gjithashtu paraqet një SPoF, dhe një të tillë që nuk mund të zgjidhet duke shtuar një raf të dytë.
Nëse kjo është befasuese, mendoni se çfarë do të ndodhte nëse raf me dy njësitë dështon, dhe si njësia mbijetuar do të dallonte këtë rast nga një dështim në rrjet.
Përgjigjja e shkurtër: është e pamundur, dhe ne përsëri kemi të gjitha problemet që vijnë me dy njësitë. Ose i mbijetuari:
- injoron kuorum dhe përpiqet gabim të iniciojë rikuperimin gjatë ndërprerjeve të rrjetit (mundësia për të përfunduar ndarjen është një histori tjetër dhe varet nëse PDU është i angazhuar dhe ndajnë energjinë me ndonjë nga rafet), ose
- respekton kuorum dhe shkëputet para kohe, kur njësia e saj partnere dështin.
Në çdo rast, dy rafet nuk janë më të mira se një, dhe njësitë duhet të marrin ose burime të pavarura energjie, ose të shpërndahen për tre (ose më shumë, varësisht nga sa njësi keni) rafet.
Dy qendra të të dhënave
Në këtë pikë, lexuesit që nuk janë më të prirur ndaj rrezikut mund të mendojnë për rikuperimin pas një katastrofe. Çfarë ndodh kur një asteroid përfundon në një qendër të dhënash me tre njësitë tona, të shpërndara në tre rafet të ndryshme? Është e qartë që Së Keqes do të ndodhin, por në varësi të nevojave tuaja, shtimi i një qendre të dytë të të dhënave mund të jetë e pamjaftueshme.
Nëse gjithçka është bërë siç duhet, qendra e dytë e të dhënave ju ofron (dhe është e arsyeshme) një kopje të azhurnuar dhe të konfirmuar të shërbimeve tuaja dhe të dhënave të tyre. Megjithatë, siç ndodh në skenarët me dy nyje dhe dy rafts, sistemi nuk ka informacion të mjaftueshëm për të garantuar disponueshmërinë maksimale dhe për të parandaluar dëmtimin (ose përçarjen e grupeve të të dhënave). Edhe me praninë e tre nyjeve (ose rafteve), shpërndarja e tyre vetëm në dy qendra të të dhënave e lë sistemin pa aftësinë për të marrë vendimin e duhur në rastin e një (ndoshta shumë më të mundshëm) ngjarjeje, të cilën të dy anët nuk mund ta lidhin.
Kjo nuk do të thotë se zgjidhja me dy qendra të të dhënave nuk është e përshtatshme. Kompanitë shpesh duan që dikush të jetë në dijeni përpara se të ndërmarrë një hap të jashtëzakonshëm për të kaluar në qendrën e dytë të rezervës. Thjesht mbani mend se nëse dëshironi të automatizoni dështimin, do t’ju nevojitet ose një qendër e tretë e të dhënave për të bërë kuorumin të ketë kuptim (drejtpërdrejt ose përmes një arbitri), ose do të duhet të gjeni një mënyrë për të shkëputur në mënyrë të sigurt të gjithë qendrën e të dhënave.
Burimi: habr.com
