Cześć, Habr! Przedstawiam wam tłumaczenie artykułu autora Andrew Beekhof.
Wielu ludzi preferuje klastry składające się z dwóch węzłów, ponieważ wydają się koncepcyjnie prostsze, a także tańsze o 33% niż ich trzywęzłowe odpowiedniki. Choć można zbudować dobry klaster z dwóch węzłów, w większości przypadków, z powodu nieprzewidzianych scenariuszy, taka konfiguracja może prowadzić do wielu nieoczywistych problemów.
Pierwszym krokiem do stworzenia każdej systemu wysokiej dostępności jest identyfikacja i próba usunięcia pojedynczych punktów awarii, często skrótowo nazywanych SPoF (single point of failure).
Należy pamiętać, że w każdym systemie niemożliwe jest wyeliminowanie wszystkich możliwych ryzyk przestojów. Wynika to choćby z faktu, że typową ochroną przed ryzykiem jest wprowadzenie pewnej redundancji, co prowadzi do wzrostu złożoności systemu i pojawienia się nowych punktów awarii. Dlatego od początku dokonujemy kompromisu i koncentrujemy się na zdarzeniach związanych z pojedynczymi punktami awarii, a nie na łańcuchach związanych i, co za tym idzie, coraz mniej prawdopodobnych zdarzeniach.
Biorąc pod uwagę kompromisy, nie tylko szukamy SPoF, ale także równoważymy ryzyka i konsekwencje, w rezultacie wnioski dotyczące tego, co jest krytyczne, a co nie, mogą się różnić dla każdego wdrożenia.
Nie wszystkim potrzebni są alternatywni dostawcy energii z niezależnymi liniami przesyłowymi. Choć paranoja się opłaciła przynajmniej dla jednego klienta, kiedy ich monitoring wykrył uszkodzony transformator. Klient dzwonił, próbując ostrzec firmę energetyczną, aż do momentu, gdy uszkodzony transformator wybuchł.
Naturalnym punktem wyjścia jest posiadanie w systemie więcej niż jednego węzła. Jednak zanim system będzie mógł przenieść usługi na pozostający przy życiu węzeł po awarii, w ogólnym przypadku należy upewnić się, że przenoszone usługi nie są aktywne w innym miejscu.
Dwa węzły klastra nie mają wad, jeśli w wyniku awarii oba węzły obsługują tę samą statyczną stronę internetową. Jednak wszystko zmienia się, gdy obie strony niezależnie zarządzają wspólną kolejką zadań lub zapewniają niekoordynowany dostęp do zapisu do replikowanej bazy danych lub wspólnego systemu plików.
Dlatego, aby zapobiec uszkodzeniu danych w wyniku awarii jednego z węzłów – polegamy na tym, co nazywa się „odgrodzeniem” (fencing).
Zasada odgrodzenia
Podstawą zasady odgrodzenia jest pytanie: czy konkurencyjny węzeł może spowodować uszkodzenie danych? Jeśli uszkodzenie danych jest prawdopodobnym scenariuszem – dobrym rozwiązaniem będzie izolacja węzła zarówno od przychodzących zapytań, jak i od trwałego składowania. Najpowszechniejszym podejściem do odgrodzenia jest wyłączenie uszkodzonych węzłów.
Istnieją dwie kategorie metod odgrodzenia, które nazwałbym bezpośrednimi i pośrednimi, ale w równym stopniu można je nazwać aktywnymi i biernymi. Metody bezpośrednie obejmują działania ze strony przetrwałych węzłów peers, takie jak interakcja z urządzeniem IPMI (Intelligent Platform Management Interface – interfejs do zdalnego monitorowania i zarządzania fizycznym stanem serwera) lub iLO (mechanizm zarządzania serwerami w warunkach braku dostępu fizycznego do nich), podczas gdy metody pośrednie polegają na tym, że uszkodzony węzeł w jakiś sposób rozpoznaje, że znajduje się w złym stanie (lub przynajmniej przeszkadza innym członkom w powrocie do sprawności) i sygnalizuje konieczność wyłączenia uszkodzonego węzła.
Kworum pomaga w przypadku stosowania zarówno metod bezpośrednich, jak i pośrednich.
Bezpośrednie odgrodzenie
W przypadku bezpośredniego odgrodzenia możemy wykorzystać kworum, aby zapobiec wyścigom odgrodzeniowym w przypadku awarii sieci.
Mając koncepcję kworum, w systemie dostępne są wystarczające informacje (nawet bez połączenia ze swoimi partnerami), aby węzły automatycznie wiedziały, czy powinny inicjować odgrodzenie i/lub przywracanie.
Bez kworum obie strony podziału sieci słusznie zakładają, że druga strona jest martwa, i będą dążyć do odgrodzenia drugiej. W najgorszym przypadku obie strony są w stanie wyłączyć cały klaster. Alternatywnym scenariuszem jest deathmatch, nieskończona pętla węzłów, które się pojawiają, nie widzą swoich partnerów, ponownie uruchamiają je i inicjują przywracanie, tylko po to, aby zrestartować, gdy ich partner przechodzi przez tę samą logikę.
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.
Unfortunately, the specifics of IPMI and iLO device operations are rarely considered at the time of equipment purchase.
Indirect fencing
Quorum 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.
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).
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.
The problem with choosing one mode is that there is no course of action that maximizes availability and prevents data loss.
- If you decide to assume that the partner node is active, but it has actually failed, the cluster unnecessarily stops services that should have been running to compensate for the loss of the failed partner node's services.
- If you decide to assume that the node is not working, but it was just a network failure and the remote node is actually functioning, then at best, you are committing to some future manual reconciliation of the resulting data sets.
Regardless of which heuristic you use, it is trivial to create a failure that either forces both sides to work or causes the cluster to shut down the surviving nodes. Not using quorum really deprives the cluster of one of its most powerful tools.
Jeśli nie ma innej alternatywy, najlepszym podejściem będzie poświęcenie dostępności (autor odnosi się tutaj do teorii CAP). Wysoka dostępność uszkodzonych danych nikomu nie pomaga, a ręczne porównywanie różnych zestawów danych również nie jest przyjemne.
Kworam
Kworam brzmi świetnie, prawda?
Jedyną wadą jest to, że aby mieć go w klastrze z N członkami, musisz utrzymać połączenie między N / 2 + 1 z twoich węzłów. Co jest niemożliwe w klastrze z dwoma węzłami po awarii jednego z nich.
To prowadzi nas do zasadniczego problemu z dwoma węzłami:
kworam nie ma sensu w klastrach dwuwęzłowych, a bez niego nie można wiarygodnie określić kursu działań, który maksymalizuje dostępność i zapobiega utracie danych.
Nawet w systemie z dwoma węzłami połączonymi kablem cross, nie można ostatecznie rozróżnić między awarią sieci a awarią drugiego węzła. Odłączenie jednego końca (czyje wystąpienie jest zdecydowanie proporcjonalne do odległości między węzłami) wystarczy, aby obalić wszelkie założenia, że funkcjonalność kanału jest równa zdrowiu węzła-partnera.
Włączamy klaster z dwóch węzłów
Czasami klient nie może lub nie chce zakupić trzeciego węzła, a my musimy szukać alternatywy.
Opcja 1 — Metoda dublowania
Urządzenie iLO lub IPMI węzła stanowi punkt awarii, ponieważ w przypadku awarii pozostali żywi nie mogą go użyć do wyprowadzenia węzła w bezpieczny stan. W klastrze z 3 lub więcej węzłami możemy złagodzić to, obliczając kworam i używając hardware watchdog (mechanizm pośredniego odłączania, jak omówiono wcześniej). W przypadku dwóch węzłów musimy zamiast tego używać przełączników zasilania (power distribution units lub PDUs).
Po awarii przeżyły węzły najpierw próbują skontaktować się z głównym urządzeniem odłączającym (wbudowanym iLO lub IPMI). Jeśli im się uda, przywracanie trwa jak zwykle. Tylko w przypadku awarii urządzenia iLO / IPMI następuje kontakt z PDU, jeśli kontakt się powiedzie, przywracanie może być kontynuowane.
Koniecznie umieść PDU w innym sieci niż ruch klastra, w przeciwnym razie awaria jednego z połączeń zablokuje dostęp do urządzeń segmentacyjnych oraz zablokuje odzyskiwanie usług.
Możesz zapytać – czy urządzenie PDU nie jest jedynym punktem awarii? Odpowiedź brzmi – oczywiście, że jest.
Jeśli to ryzyko jest dla Ciebie istotne – nie jesteś sam: podłącz oba węzły do dwóch PDU i skonfiguruj oprogramowanie klastra, aby używało obu podczas włączania i wyłączania węzłów. Teraz klaster pozostaje aktywny, jeśli jeden PDU zawiedzie, a do zablokowania odzyskania potrzebna będzie kolejna awaria – albo innego PDU, albo urządzenia IPMI.
Opcja 2 – Dodanie arbitra
W pewnych scenariuszach, chociaż technicznie możliwy jest sposób podwójnego segmentowania, jest on politycznie skomplikowany. Wiele firm preferuje określony podział między administratorami a właścicielami aplikacji, a sieciowi administratorzy dbający o bezpieczeństwo nie zawsze są entuzjastycznie nastawieni do przekazywania komukolwiek danych dostępu do PDU.
W takim przypadku zalecaną alternatywą jest stworzenie neutralnej strony trzeciej, która może uzupełnić obliczenie kworum.
W przypadku awarii węzeł powinien mieć możliwość dostrzegania eteru swojego partnera lub arbitra, aby odzyskać usługi. Arbiter również zawiera funkcję rozłączenia, jeśli oba węzły mogą widzieć arbitra, ale nie widzą się nawzajem.
Ta opcja powinna być używana w parze z pośrednią metodą segmentacji, taką jak sprzętowy zegar monitorujący, który jest skonfigurowany na wyłączenie maszyny, jeśli traci połączenie ze swoim węzłem-partnerem i arbitrem. W ten sposób przeżywający może z wystarczającą pewnością założyć, że jego węzeł-partner będzie w bezpiecznym stanie po upływie czasu sprzętowego zegara monitorującego.
Praktyczna różnica między arbitrem a trzecim węzłem polega na tym, że arbiter wymaga znacznie mniej zasobów do swojej pracy i potencjalnie może obsługiwać więcej niż jeden klaster.
Opcja 3 – Czynnik ludzki
Ostatnie podejście polega na tym, aby przetrwali kontynuowali wykonywanie wszelkich usług, które już świadczą, ale nie uruchamiali nowych, dopóki problem nie rozwiąże się sam (przywrócenie sieci, ponowne uruchomienie węzła), albo człowiek nie weźmie na siebie odpowiedzialności za ręczne potwierdzenie, że druga strona jest martwa.
Opcja bonusowa
Czy już mówiłem, że możesz dodać trzeci węzeł?
Dwie szafy serwerowe
Dla argumentu załóżmy, że przekonałem cię do zalet trzeciego węzła, teraz musimy rozważyć fizyczne rozmieszczenie węzłów. Jeśli są umieszczone (i zasilane) w tej samej szafie, stanowi to również SPoF, a to, co nie może być rozwiązane przez dodanie drugiej szafy.
Jeśli to jest zaskakujące, pomyśl, co się stanie, gdy szafa z dwoma węzłami ulegnie awarii, a jak przetrwały węzeł będzie rozróżniał ten przypadek i awarię sieci.
Krótka odpowiedź: to niemożliwe i ponownie mamy do czynienia z wszystkimi problemami w przypadku dwóch węzłów. Albo przetrwały:
- ignoruje kworum i niepoprawnie próbuje zainicjować przywracanie podczas zakłóceń w pracy sieci (możliwość zakończenia odłączenia to osobna historia i zależy od zaangażowania PDU oraz tego, czy dzielą one moc z którakolwiek z szaf), albo
- szanuje kworum i przedwcześnie odłącza się, gdy jego partner węzeł zawodzi
W każdym przypadku dwie szafy serwerowe nie są lepsze niż jedna i węzły muszą mieć albo niezależne źródła zasilania, albo być rozłożone na trzy (lub więcej, w zależności od tego, ile masz węzłów) szafy.
Dwa centra danych
Na tym etapie czytelnicy, którzy już nie są skłonni do ryzyka, mogą pomyśleć o odzyskiwaniu po awarii. Co się stanie, gdy asteroida uderzy w jedno centrum danych z naszymi trzema węzłami, rozłożonymi na trzech różnych szafach? Oczywiście, że złe rzeczy, ale w zależności od twoich potrzeb dodanie drugiego centrum danych może być niewystarczające.
Jeśli wszystko zostało zrobione prawidłowo, drugie centrum danych dostarcza Ci (i to rozsądne) aktualną i spójną kopię Twoich usług i ich danych. Jednak, podobnie jak w przypadku scenariuszy z dwoma węzłami i dwoma stojakami, w systemie brakuje wystarczających informacji, aby zapewnić maksymalną dostępność i zapobiec uszkodzeniu (lub rozbieżności zestawów danych). Nawet przy trzech węzłach (lub stojakach) ich rozkład tylko w dwóch centrach danych sprawia, że system nie jest w stanie wiarygodnie podjąć właściwej decyzji w przypadku (teraz znacznie bardziej prawdopodobnego) zdarzenia, które obie strony nie mogą powiązać.
To nie oznacza, że rozwiązanie z dwoma centrami danych nigdy nie jest odpowiednie. Firmy często chcą, aby osoba była świadoma, zanim podejmie nadzwyczajny krok w kierunku przejścia na zapasowe centrum danych. Po prostu miej na uwadze, że jeśli chcesz zautomatyzować awarię, będziesz potrzebować trzeciego centrum danych, aby kworum miało sens (bezpośrednio lub przez arbitra), albo musisz znaleźć sposób na niezawodne wyłączenie całego centrum danych.
Źródło: habr.com
