{"id":75726,"date":"2020-03-28T07:42:08","date_gmt":"2020-03-28T05:42:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah"},"modified":"2020-03-28T07:42:08","modified_gmt":"2020-03-28T05:42:08","slug":"klaster-iz-dvuh-uzlov-dyavol-v-detalyah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah","title":{"rendered":"Klaster z dw\u00f3ch w\u0119z\u0142\u00f3w \u2013 diabe\u0142 tkwi w szczeg\u00f3\u0142ach","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cze\u015b\u0107, Habr! Przedstawiam wam t\u0142umaczenie artyku\u0142u \u00abDwa w\u0119z\u0142y \u2014 Diabe\u0142 tkwi w szczeg\u00f3\u0142ach\u00bb<\/a><\/noindex> autora Andrew Beekhof.<\/p>\n

Wielu ludzi preferuje klastry sk\u0142adaj\u0105ce si\u0119 z dw\u00f3ch w\u0119z\u0142\u00f3w, poniewa\u017c wydaj\u0105 si\u0119 koncepcyjnie prostsze, a tak\u017ce ta\u0144sze o 33% ni\u017c ich trzyw\u0119z\u0142owe odpowiedniki. Cho\u0107 mo\u017cna zbudowa\u0107 dobry klaster z dw\u00f3ch w\u0119z\u0142\u00f3w, w wi\u0119kszo\u015bci przypadk\u00f3w, z powodu nieprzewidzianych scenariuszy, taka konfiguracja mo\u017ce prowadzi\u0107 do wielu nieoczywistych problem\u00f3w.
\n<\/a><\/noindex>
\nPierwszym krokiem do stworzenia ka\u017cdej systemu wysokiej dost\u0119pno\u015bci jest identyfikacja i pr\u00f3ba usuni\u0119cia pojedynczych punkt\u00f3w awarii, cz\u0119sto skr\u00f3towo nazywanych SPoF<\/i> (single point of failure).<\/p>\n

Nale\u017cy pami\u0119ta\u0107, \u017ce w ka\u017cdym systemie niemo\u017cliwe jest wyeliminowanie wszystkich mo\u017cliwych ryzyk przestoj\u00f3w. Wynika to cho\u0107by z faktu, \u017ce typow\u0105 ochron\u0105 przed ryzykiem jest wprowadzenie pewnej redundancji, co prowadzi do wzrostu z\u0142o\u017cono\u015bci systemu i pojawienia si\u0119 nowych punkt\u00f3w awarii. Dlatego od pocz\u0105tku dokonujemy kompromisu i koncentrujemy si\u0119 na zdarzeniach zwi\u0105zanych z pojedynczymi punktami awarii, a nie na \u0142a\u0144cuchach zwi\u0105zanych i, co za tym idzie, coraz mniej prawdopodobnych zdarzeniach.<\/p>\n

Bior\u0105c pod uwag\u0119 kompromisy, nie tylko szukamy SPoF, ale tak\u017ce r\u00f3wnowa\u017cymy ryzyka i konsekwencje, w rezultacie wnioski dotycz\u0105ce tego, co jest krytyczne, a co nie, mog\u0105 si\u0119 r\u00f3\u017cni\u0107 dla ka\u017cdego wdro\u017cenia.<\/p>\n

Nie wszystkim potrzebni s\u0105 alternatywni dostawcy energii z niezale\u017cnymi liniami przesy\u0142owymi. Cho\u0107 paranoja si\u0119 op\u0142aci\u0142a przynajmniej dla jednego klienta, kiedy ich monitoring wykry\u0142 uszkodzony transformator. Klient dzwoni\u0142, pr\u00f3buj\u0105c ostrzec firm\u0119 energetyczn\u0105, a\u017c do momentu, gdy uszkodzony transformator wybuch\u0142.<\/p><\/blockquote>\n

\nNaturalnym punktem wyj\u015bcia jest posiadanie w systemie wi\u0119cej ni\u017c jednego w\u0119z\u0142a. Jednak zanim system b\u0119dzie m\u00f3g\u0142 przenie\u015b\u0107 us\u0142ugi na pozostaj\u0105cy przy \u017cyciu w\u0119ze\u0142 po awarii, w og\u00f3lnym przypadku nale\u017cy upewni\u0107 si\u0119, \u017ce przenoszone us\u0142ugi nie s\u0105 aktywne w innym miejscu.<\/p>\n

Dwa w\u0119z\u0142y klastra nie maj\u0105 wad, je\u015bli w wyniku awarii oba w\u0119z\u0142y obs\u0142uguj\u0105 t\u0119 sam\u0105 statyczn\u0105 stron\u0119 internetow\u0105. Jednak wszystko zmienia si\u0119, gdy obie strony niezale\u017cnie zarz\u0105dzaj\u0105 wsp\u00f3ln\u0105 kolejk\u0105 zada\u0144 lub zapewniaj\u0105 niekoordynowany dost\u0119p do zapisu do replikowanej bazy danych lub wsp\u00f3lnego systemu plik\u00f3w.<\/p>\n

Dlatego, aby zapobiec uszkodzeniu danych w wyniku awarii jednego z w\u0119z\u0142\u00f3w \u2013 polegamy na tym, co nazywa si\u0119 \u201eodgrodzeniem\u201d<\/i> (fencing).<\/p>\n

Zasada odgrodzenia<\/h2>\n

\nPodstaw\u0105 zasady odgrodzenia jest pytanie: czy konkurencyjny w\u0119ze\u0142 mo\u017ce spowodowa\u0107 uszkodzenie danych? Je\u015bli uszkodzenie danych jest prawdopodobnym scenariuszem \u2013 dobrym rozwi\u0105zaniem b\u0119dzie izolacja w\u0119z\u0142a zar\u00f3wno od przychodz\u0105cych zapyta\u0144, jak i od trwa\u0142ego sk\u0142adowania. Najpowszechniejszym podej\u015bciem do odgrodzenia jest wy\u0142\u0105czenie uszkodzonych w\u0119z\u0142\u00f3w.<\/p>\n

Istniej\u0105 dwie kategorie metod odgrodzenia, kt\u00f3re nazwa\u0142bym bezpo\u015brednimi<\/i> i po\u015brednimi<\/i>, ale w r\u00f3wnym stopniu mo\u017cna je nazwa\u0107 aktywnymi<\/i> i biernymi<\/i>. Metody bezpo\u015brednie obejmuj\u0105 dzia\u0142ania ze strony przetrwa\u0142ych w\u0119z\u0142\u00f3w peers, takie jak interakcja z urz\u0105dzeniem IPMI (Intelligent Platform Management Interface \u2013 interfejs do zdalnego monitorowania i zarz\u0105dzania fizycznym stanem serwera) lub iLO (mechanizm zarz\u0105dzania serwerami w warunkach braku dost\u0119pu fizycznego do nich), podczas gdy metody po\u015brednie polegaj\u0105 na tym, \u017ce uszkodzony w\u0119ze\u0142 w jaki\u015b spos\u00f3b rozpoznaje, \u017ce znajduje si\u0119 w z\u0142ym stanie (lub przynajmniej przeszkadza innym cz\u0142onkom w powrocie do sprawno\u015bci) i sygnalizuje hardware watchdog<\/a><\/noindex> konieczno\u015b\u0107 wy\u0142\u0105czenia uszkodzonego w\u0119z\u0142a.<\/p>\n

Kworum pomaga w przypadku stosowania zar\u00f3wno metod bezpo\u015brednich, jak i po\u015brednich.<\/p>\n

Bezpo\u015brednie odgrodzenie<\/h3>\n

\nW przypadku bezpo\u015bredniego odgrodzenia mo\u017cemy wykorzysta\u0107 kworum, aby zapobiec wy\u015bcigom odgrodzeniowym w przypadku awarii sieci.<\/p>\n

Maj\u0105c koncepcj\u0119 kworum, w systemie dost\u0119pne s\u0105 wystarczaj\u0105ce informacje (nawet bez po\u0142\u0105czenia ze swoimi partnerami), aby w\u0119z\u0142y automatycznie wiedzia\u0142y, czy powinny inicjowa\u0107 odgrodzenie i\/lub przywracanie.<\/p>\n

Bez kworum obie strony podzia\u0142u sieci s\u0142usznie zak\u0142adaj\u0105, \u017ce druga strona jest martwa, i b\u0119d\u0105 d\u0105\u017cy\u0107 do odgrodzenia drugiej. W najgorszym przypadku obie strony s\u0105 w stanie wy\u0142\u0105czy\u0107 ca\u0142y klaster. Alternatywnym scenariuszem jest deathmatch, niesko\u0144czona p\u0119tla w\u0119z\u0142\u00f3w, kt\u00f3re si\u0119 pojawiaj\u0105, nie widz\u0105 swoich partner\u00f3w, ponownie uruchamiaj\u0105 je i inicjuj\u0105 przywracanie, tylko po to, aby zrestartowa\u0107, gdy ich partner przechodzi przez t\u0119 sam\u0105 logik\u0119.<\/p>\n

Problem of fencing lies in the fact that the most commonly used devices become unavailable due to the same failure events we want to target for recovery. Most IPMI and iLO cards are installed on the hosts they control and, by default, use the same network, causing the target nodes to think that other nodes are offline.<\/p>\n

Unfortunately, the specifics of IPMI and iLO device operations are rarely considered at the time of equipment purchase.<\/p>\n

Indirect fencing<\/h3>\n

\nQuorum is also important for managing indirect fencing; if done correctly, quorum can allow the survivors to assume that the lost nodes will transition to a safe state after a certain period.<\/p>\n

In this setup, the hardware watchdog timer resets every N seconds if quorum is not lost. If the timer (usually several multiples of N) expires, the device performs an ungraceful power off (not shutdown).<\/p>\n

This approach is very effective, but without quorum for its management, there is insufficient information within the cluster. It is not easy to distinguish between a network disconnection and a partner node failure. The reason this matters is that without the ability to differentiate between the two cases, you are forced to choose the same mode of behavior in both cases.<\/p>\n

The problem with choosing one mode is that there is no course of action that maximizes availability and prevents data loss.<\/p>\n