Hej Habro! Zwracam uwagę na tłumaczenie artykułu autorstwa Andrew Beekhofa.
Wiele osób woli klastry dwuwęzłowe, ponieważ wydają się one prostsze koncepcyjnie, a także są o 33% tańsze niż ich odpowiedniki z trzema węzłami. Chociaż całkiem możliwe jest złożenie dobrego klastra dwóch węzłów, w większości przypadków, z powodu nieprzemyślanych scenariuszy, taka konfiguracja stworzy wiele nieoczywistych problemów.
Pierwszym krokiem do stworzenia dowolnego systemu wysokiej dostępności jest znalezienie i próba wyeliminowania poszczególnych punktów awarii, często określanych w skrócie jako SPoF (pojedynczy punkt awarii).
Warto mieć na uwadze, że w żadnym systemie nie da się wyeliminować wszystkich możliwych zagrożeń przestojów. Wynika to z faktu, że typową obroną przed ryzykiem jest wprowadzenie pewnej redundancji, co prowadzi do zwiększenia złożoności systemu i pojawienia się nowych punktów awarii. Dlatego początkowo idziemy na kompromis i skupiamy się na zdarzeniach związanych z pojedynczymi punktami awarii, a nie na ciągach powiązanych ze sobą i przez to coraz mniej prawdopodobnych zdarzeń.
Biorąc pod uwagę kompromisy, nie tylko szukamy SPoF, ale także bilansujemy ryzyko i konsekwencje, w wyniku czego wnioski dotyczące tego, co jest krytyczne, a co nie, mogą się różnić w przypadku każdego wdrożenia.
Nie każdy potrzebuje alternatywnych dostawców energii elektrycznej z niezależnymi liniami energetycznymi. Chociaż paranoja opłaciła się przynajmniej jednemu klientowi, gdy ich monitoring wykrył uszkodzony transformator. Klient wykonywał telefony, próbując zaalarmować firmę energetyczną, dopóki uszkodzony transformator nie eksplodował.
Naturalnym punktem wyjścia jest posiadanie więcej niż jednego węzła w systemie. Zanim jednak system będzie mógł przenieść usługi do węzła, który przetrwał awarię, zazwyczaj musi upewnić się, że przenoszone usługi nie są aktywne gdzie indziej.
Klaster składający się z dwóch węzłów nie ma żadnych wad, jeśli w wyniku awarii oba węzły obsługują tę samą statyczną witrynę internetową. Sytuacja się jednak zmienia, jeśli w rezultacie obie strony niezależnie zarządzają współdzieloną kolejką zadań lub zapewniają nieskoordynowany dostęp do zapisu w zreplikowanej bazie danych lub współdzielonym systemie plików.
Dlatego, aby zapobiec uszkodzeniu danych w wyniku awarii pojedynczego węzła - polegamy na czymś, co nazywa się "dysocjacja" (ogrodzenie).
Zasada dysocjacji
W sercu zasady dysocjacji leży pytanie: czy konkurujący węzeł może spowodować uszkodzenie danych? W przypadku prawdopodobnego scenariusza uszkodzenia danych dobrym rozwiązaniem byłoby odizolowanie węzła zarówno od żądań przychodzących, jak i od pamięci trwałej. Najczęstszym podejściem do dysocjacji jest odłączenie wadliwych węzłów.
Istnieją dwie kategorie metod dysocjacji, które będę nazywać prosto и pośredni, ale można je równie nazwać aktywny и bierny. Do metod bezpośrednich zaliczają się działania podejmowane przez pozostałych przy życiu peerów, takie jak interakcja z urządzeniem IPMI (inteligentny interfejs zarządzania platformą) lub iLO (mechanizm zarządzania serwerami w przypadku braku fizycznego dostępu do nich), natomiast metody pośrednie opierają się na nieudanym node, aby w jakiś sposób rozpoznać, że znajduje się w złym stanie (lub przynajmniej uniemożliwić innym członkom odzyskanie sprawności) i zasygnalizować o konieczności odłączenia uszkodzonego węzła.
Kworum pomaga przy stosowaniu metod bezpośrednich i pośrednich.
Dysocjacja bezpośrednia
W przypadku bezpośredniej dysocjacji możemy wykorzystać kworum, aby zapobiec wyścigowi dysocjacji w przypadku awarii sieci.
Dzięki koncepcji kworum w systemie jest wystarczająca ilość informacji (nawet bez łączenia się z urządzeniami równorzędnymi), aby węzły automatycznie wiedziały, czy powinny zainicjować dysocjację i/lub odzyskiwanie.
Bez kworum obie strony podziału sieci słusznie założą, że druga strona nie żyje, i będą dążyć do oddzielenia drugiej strony. W najgorszym przypadku obu stronom uda się zamknąć cały klaster. Alternatywnym scenariuszem jest deathmatch, czyli niekończąca się pętla pojawiających się węzłów, które nie widzą swoich równorzędnych węzłów, uruchamiają je ponownie i inicjują odzyskiwanie tylko w celu ponownego uruchomienia, gdy ich równorzędny partner postępuje zgodnie z tą samą logiką.
Problem z odłączeniem polega na tym, że najczęściej używane urządzenia stają się niedostępne z powodu tych samych awarii, które chcemy odzyskać. Większość kart IPMI i iLO jest instalowana na kontrolowanych przez nie hostach i domyślnie korzysta z tej samej sieci, co powoduje, że hosty docelowe myślą, że inne hosty są w trybie offline.
Niestety, przy zakupie sprzętu rzadko brane są pod uwagę funkcje operacyjne urządzeń IPMI i iLo.
Dysocjacja pośrednia
Kworum jest również ważne w przypadku zarządzania pośrednią dysocjacją; jeśli zostanie wykonane prawidłowo, kworum może pozwolić ocalałym założyć, że utracone węzły przejdą do stanu bezpiecznego po pewnym czasie.
W tej konfiguracji licznik czasu sprzętowego watchdoga jest resetowany co N sekund, jeśli nie doszło do utraty kworum. Jeśli licznik czasu (zwykle kilka wielokrotności N) upłynie, urządzenie wykona nieoczekiwane wyłączenie (nie wyłączenie).
Takie podejście jest bardzo skuteczne, jednak bez kworum w klastrze nie ma wystarczającej ilości informacji, aby nim zarządzać. Nie jest łatwo odróżnić awarię sieci od awarii węzła równorzędnego. Ma to znaczenie dlatego, że bez możliwości rozróżnienia pomiędzy tymi dwoma przypadkami, jesteś zmuszony wybrać to samo zachowanie w obu przypadkach.
Problem z wyborem jednego trybu polega na tym, że nie ma sposobu działania, który maksymalizowałby dostępność i zapobiegał utracie danych.
- Jeśli zdecydujesz się założyć, że węzeł równorzędny jest aktywny, ale w rzeczywistości ulegnie awarii, klaster niepotrzebnie zatrzyma usługi, które byłyby uruchomione, aby zrekompensować utratę usług z węzła równorzędnego, który uległ awarii.
- Jeśli zdecydujesz się założyć, że węzeł nie działa, ale była to po prostu awaria sieci i w rzeczywistości zdalny węzeł działa, to w najlepszym przypadku zapisujesz się na przyszłe ręczne uzgadnianie wynikowych zbiorów danych.
Bez względu na to, jakiej heurystyki użyjesz, utworzenie awarii, która albo spowoduje awarię obu stron, albo spowoduje zamknięcie klastra pozostałych węzłów, jest banalne. Niewykorzystanie kworum naprawdę pozbawia klaster jednego z najpotężniejszych narzędzi w jego arsenale.
Jeśli nie ma innej alternatywy, najlepszym podejściem jest poświęcenie dostępności (tutaj autor odwołuje się do twierdzenia CAP). Wysoka dostępność uszkodzonych danych nikomu nie pomaga, a ręczne uzgadnianie różnych zestawów danych też nie jest zabawne.
Kworum
Kworum brzmi świetnie, prawda?
Jedyną wadą jest to, że aby mieć go w klastrze z N członkami, musisz mieć połączenie między N/2 + 1 pozostałych węzłów. Co nie jest możliwe w klastrze z dwoma węzłami po awarii jednego węzła.
Co ostatecznie prowadzi nas do podstawowego problemu z dwoma węzłami:
Kworum nie ma sensu w dwóch klastrach węzłów, a bez niego nie da się wiarygodnie określić sposobu działania, który zmaksymalizuje dostępność i zapobiegnie utracie danych
Nawet w systemie dwóch węzłów połączonych kablem krosowanym nie da się definitywnie odróżnić przerwy w sieci od awarii drugiego węzła. Wyłączenie jednego końca (którego prawdopodobieństwo jest oczywiście proporcjonalne do odległości między węzłami) wystarczy, aby unieważnić wszelkie założenia, że kondycja łącza jest równa kondycji węzła partnerskiego.
Działanie klastra z dwoma węzłami
Czasem klient nie może lub nie chce dokupić trzeciego węzła i zmuszeni jesteśmy szukać alternatywy.
Opcja 1 – Metoda dysocjacji zduplikowanej
Urządzenie iLO lub IPMI węzła stanowi punkt awarii, ponieważ w przypadku jego awarii osoby, które przeżyją, nie będą mogły go użyć do doprowadzenia węzła do bezpiecznego stanu. W klastrze składającym się z 3 lub więcej węzłów możemy temu zaradzić, obliczając kworum i używając sprzętowego watchdoga (mechanizm pośredniego odłączania, jak omówiono wcześniej). W przypadku dwóch węzłów musimy zamiast tego zastosować sieciowe jednostki dystrybucji zasilania (PDU).
Po awarii osoba, która przeżyła, najpierw próbuje skontaktować się z głównym urządzeniem odłączającym (wbudowanym iLO lub IPMI). Jeśli to się powiedzie, odzyskiwanie będzie kontynuowane w zwykły sposób. Dostęp do PDU można uzyskać tylko w przypadku awarii urządzenia iLO/IPMI; jeśli dostęp się powiedzie, odzyskiwanie może być kontynuowane.
Pamiętaj, aby umieścić PDU w innej sieci niż ruch klastra, w przeciwnym razie pojedyncza awaria sieci zablokuje dostęp do obu urządzeń odłączających się i przywrócenie usług.
W tym miejscu możesz zadać pytanie - czy PDU jest pojedynczym punktem awarii? Odpowiedź brzmi: oczywiście, że tak.
Jeśli to ryzyko jest dla Ciebie istotne, nie jesteś sam: podłącz oba węzły do dwóch jednostek PDU i powiedz oprogramowaniu klastrowemu, aby korzystało z obu podczas włączania i wyłączania węzłów. Klaster pozostaje teraz aktywny w przypadku awarii jednej jednostki PDU, a do zablokowania odzyskiwania wymagana będzie druga awaria drugiej jednostki PDU lub urządzenia IPMI.
Opcja 2 – Dodanie Arbitra
W niektórych scenariuszach metoda podwójnego odłączenia jest technicznie możliwa, ale jest politycznie trudna. Wiele firm lubi pewien podział między administratorami a właścicielami aplikacji, a dbający o bezpieczeństwo administratorzy sieci nie zawsze są entuzjastycznie nastawieni do udostępniania komukolwiek ustawień dostępu do PDU.
W takim przypadku zalecaną alternatywą jest utworzenie neutralnej strony trzeciej, która może uzupełnić obliczenia kworum.
W przypadku awarii węzeł musi widzieć fale radiowe swojego partnera lub arbitra, aby przywrócić usługi. Arbiter zawiera również funkcję rozłączania, jeśli oba węzły widzą arbitra, ale nie widzą siebie nawzajem.
Opcji tej należy używać w połączeniu z pośrednią metodą odłączania, taką jak zegar sterujący sprzętem, który jest skonfigurowany tak, aby zabijał maszynę, jeśli utraci ona połączenie z węzłem równorzędnym i arbitrem. Zatem osoba, która przeżyła, może rozsądnie założyć, że jej węzeł równorzędny będzie w bezpiecznym stanie po wygaśnięciu zegara sprzętowego watchdoga.
Praktyczna różnica między arbitrem a trzecim węzłem polega na tym, że arbiter wymaga znacznie mniej zasobów do działania i może potencjalnie obsługiwać więcej niż jeden klaster.
Opcja 3 – Czynnik ludzki
Ostateczne podejście polega na tym, że ocaleni kontynuują korzystanie z usług, które już uruchomili, ale nie rozpoczynają nowych, dopóki problem nie rozwiąże się (przywrócenie sieci, ponowne uruchomienie węzła) lub osoba nie przejmie odpowiedzialności za ręczne potwierdzenie, że druga strona nie żyje.
Opcja bonusowa
Czy wspomniałem, że możesz dodać trzeci węzeł?
Dwa stojaki
Na potrzeby dyskusji załóżmy, że przekonałem Cię o zaletach trzeciego węzła, teraz musimy rozważyć fizyczne rozmieszczenie węzłów. Jeśli są umieszczone (i zasilane) w tej samej szafie, jest to również problem SPoF, którego nie można rozwiązać poprzez dodanie drugiej szafy.
Jeśli jest to zaskakujące, zastanów się, co by się stało, gdyby szafa z dwoma węzłami uległa awarii i jak węzeł, który przetrwał, odróżniłby to od awarii sieci.
Krótka odpowiedź jest taka, że nie jest to możliwe i ponownie mamy do czynienia ze wszystkimi problemami w przypadku dwóch węzłów. Lub ocalały:
- ignoruje kworum i nieprawidłowo próbuje inicjować przywracanie podczas awarii sieci (możliwość zakończenia dysocjacji to inna historia i zależy od tego, czy zaangażowana jest PDU i czy dzieli ona zasilanie z którąkolwiek z szaf), lub
- szanuje kworum i rozłącza się przedwcześnie w przypadku awarii węzła równorzędnego
W każdym razie dwie szafy nie są lepsze niż jedna, a węzły muszą albo otrzymać niezależne zasilanie, albo być rozdzielone na trzy (lub więcej, w zależności od liczby węzłów) szafy.
Dwa centra danych
W tym momencie czytelnicy, którzy nie mają już awersji do ryzyka, mogą rozważyć rozważenie odzyskiwania po awarii. Co się stanie, gdy asteroida uderzy w to samo centrum danych, a nasze trzy węzły będą rozmieszczone na trzech różnych szafach? Oczywiście Bad Things, ale w zależności od potrzeb dodanie drugiego centrum danych może nie wystarczyć.
Jeśli zrobisz to poprawnie, drugie centrum danych zapewni Ci (i jest to uzasadnione) aktualną i spójną kopię Twoich usług i ich danych. Jednakże, podobnie jak w przypadku scenariuszy z dwoma węzłami i dwiema szafami, w systemie nie ma wystarczającej ilości informacji, aby zapewnić maksymalną dostępność i zapobiec uszkodzeniom (lub rozbieżnościom w zestawach danych). Nawet w przypadku trzech węzłów (lub stojaków) rozmieszczenie ich tylko w dwóch centrach danych powoduje, że system nie jest w stanie w sposób niezawodny podjąć właściwej decyzji w przypadku (obecnie znacznie bardziej prawdopodobnego) zdarzenia, w którym obie strony nie będą mogły się porozumieć.
Nie oznacza to, że rozwiązanie z podwójnym centrum danych nigdy nie jest odpowiednie. Firmy często chcą, aby dana osoba była świadoma przed podjęciem niezwykłego kroku, jakim jest przejście do zapasowego centrum danych. Pamiętaj tylko, że jeśli chcesz zautomatyzować awarię, będziesz potrzebować trzeciego centrum danych, aby kworum miało sens (bezpośrednio lub za pośrednictwem arbitra), albo znajdziesz sposób na niezawodne zamknięcie wszystkich danych Centrum.
Źródło: www.habr.com