Klaster o wysokiej dostępności

Klastry o wysokiej dostępności (znane również jako klastry HA , klastry przełączania awaryjnego ) to grupy komputerów obsługujące aplikacje serwerowe , które można niezawodnie wykorzystywać przy minimalnym czasie przestojów . Działają za pomocą oprogramowania o wysokiej dostępności, aby wykorzystać nadmiarowe komputery w grupach lub klastrach które zapewniają nieprzerwaną obsługę w przypadku awarii elementów systemu. Bez klastrowania, jeśli serwer, na którym działa określona aplikacja, ulegnie awarii, aplikacja będzie niedostępna do czasu naprawienia awarii serwera. Klastrowanie HA rozwiązuje tę sytuację poprzez wykrywanie błędów sprzętu/oprogramowania i natychmiastowe ponowne uruchamianie aplikacji w innym systemie bez konieczności interwencji administracyjnej, co jest procesem znanym jako przełączanie awaryjne . W ramach tego procesu oprogramowanie klastrowe może skonfigurować węzeł przed uruchomieniem na nim aplikacji. Na przykład może być konieczne zaimportowanie i zamontowanie odpowiednich systemów plików, skonfigurowanie sprzętu sieciowego, a także uruchomienie niektórych aplikacji pomocniczych.

Klastry HA są często używane w krytycznych bazach danych , udostępnianiu plików w sieci, aplikacjach biznesowych i usługach dla klientów, takich jak witryny handlu elektronicznego . Implementacje klastra HA próbują wbudować redundancję w klaster w celu wyeliminowania pojedynczych punktów awarii, w tym wielu połączeń sieciowych i przechowywania danych, które są redundantnie połączone za pośrednictwem sieci obszaru pamięci masowej .

Klastry HA zwykle używają połączenia sieci prywatnej pulsu , które jest używane do monitorowania kondycji i stanu każdego węzła w klastrze. Jednym subtelnym, ale poważnym warunkiem, z którym musi sobie poradzić każde oprogramowanie klastrowe, jest split-brain , który występuje, gdy wszystkie prywatne łącza przestają działać jednocześnie, ale węzły klastra nadal działają. Jeśli tak się stanie, każdy węzeł w klastrze może błędnie stwierdzić, że co drugi węzeł przestał działać i podjąć próbę uruchomienia usług, które nadal działają w innych węzłach. Zduplikowane wystąpienia usług mogą spowodować uszkodzenie danych w magazynie współdzielonym.

, klastry HA często używają również magazynu świadków kworum (lokalnego lub w chmurze). Urządzenie monitorujące nie może być współużytkowane przez dwie połowy podzielonego klastra, więc w przypadku, gdy wszyscy członkowie klastra nie mogą się ze sobą komunikować (np. awaria pulsu), jeśli członek nie może uzyskać dostępu do monitora, nie może on stać się aktywny.

Wymagania projektowe aplikacji

Nie każda aplikacja może działać w środowisku klastrowym o wysokiej dostępności, a niezbędne decyzje projektowe należy podejmować na wczesnym etapie projektowania oprogramowania. Aby aplikacja działała w środowisku klastrowym o wysokiej dostępności, musi spełniać co najmniej następujące wymagania techniczne, z których dwa ostatnie są krytyczne dla jej niezawodnego działania w klastrze i najtrudniejsze do pełnego spełnienia:

  • Musi istnieć stosunkowo łatwy sposób uruchamiania, zatrzymywania, wymuszania zatrzymania i sprawdzania stanu aplikacji. W praktyce oznacza to, że aplikacja musi mieć interfejs wiersza poleceń lub skrypty do sterowania aplikacją, w tym obsługę wielu instancji aplikacji.
  • Aplikacja musi mieć możliwość korzystania z pamięci współdzielonej ( NAS / SAN ).
  • Co najważniejsze, aplikacja musi przechowywać jak najwięcej informacji o swoim stanie na nieulotnej współdzielonej pamięci masowej. Równie ważna jest możliwość ponownego uruchomienia na innym węźle w ostatnim stanie przed awarią przy użyciu stanu zapisanego ze współdzielonego magazynu.
  • Aplikacja nie może uszkodzić danych w przypadku awarii lub ponownego uruchomienia ze stanu zapisanego.
  • Wiele z tych ograniczeń można zminimalizować, korzystając ze środowisk serwerów wirtualnych, w których sam hiperwizor obsługuje klastry i zapewnia bezproblemową migrację maszyn wirtualnych (w tym stanu uruchomionej pamięci) między hostami fizycznymi — patrz Microsoft Server 2012 i 2016 Failover Clusters .
    • Kluczowa różnica między tym podejściem a uruchamianiem aplikacji obsługujących klastry polega na tym, że te ostatnie mogą radzić sobie z awariami aplikacji serwera i obsługiwać „ciągłe” aktualizacje oprogramowania przy jednoczesnym zachowaniu dostępu klienta do usługi (np. bazy danych), dzięki temu, że jedna instancja świadczy usługę, a druga jest modernizowany lub naprawiany. Wymaga to komunikacji między instancjami klastra, opróżniania pamięci podręcznej i koordynowania dostępu do plików podczas przekazywania. Klaster pracy awaryjnej podlega planowaniu, tworzeniu i konfigurowaniu, a także rozwiązywaniu problemów.

Konfiguracje węzłów

Diagram sieci klastra o wysokiej dostępności z 2 węzłami

Najbardziej powszechnym rozmiarem klastra HA jest klaster z dwoma węzłami, ponieważ jest to minimum wymagane do zapewnienia redundancji, ale wiele klastrów składa się z znacznie większej liczby, czasem kilkudziesięciu węzłów.

Załączony diagram jest dobrym omówieniem klasycznego klastra HA, z zastrzeżeniem, że nie zawiera żadnej wzmianki o funkcjonalności kworum/świadka (patrz wyżej).

Takie konfiguracje można czasem podzielić na jeden z następujących modeli:

  • Aktywny/aktywny — ruch przeznaczony dla uszkodzonego węzła jest przekazywany do istniejącego węzła lub równoważony jest obciążenie pozostałych węzłów. Jest to zwykle możliwe tylko wtedy, gdy węzły używają jednorodnej konfiguracji oprogramowania.
  • Aktywny/pasywny — zapewnia w pełni nadmiarową instancję każdego węzła, która jest włączana tylko wtedy, gdy powiązany z nim węzeł podstawowy ulegnie awarii. Ta konfiguracja zazwyczaj wymaga najbardziej dodatkowego sprzętu.
  • N+1 — Zapewnia pojedynczy dodatkowy węzeł, który zostaje włączony, aby przejąć rolę węzła, który uległ awarii. W przypadku heterogenicznej konfiguracji oprogramowania na każdym węźle głównym, dodatkowy węzeł musi mieć uniwersalną zdolność do przejmowania dowolnej roli węzłów głównych, za które jest odpowiedzialny. Zwykle odnosi się to do klastrów, w których jednocześnie działa wiele usług; w przypadku pojedynczej usługi degeneruje się to do aktywnego/pasywnego.
  • N+M — w przypadkach, gdy pojedynczy klaster zarządza wieloma usługami, posiadanie tylko jednego dedykowanego węzła przełączania awaryjnego może nie zapewniać wystarczającej nadmiarowości. W takich przypadkach dostępnych jest więcej niż jeden (M) serwerów rezerwowych. Liczba serwerów rezerwowych to kompromis między kosztami a wymaganiami dotyczącymi niezawodności.
  • N-to-1 — umożliwia tymczasowy węzeł rezerwowy przełączania awaryjnego, aby stał się aktywnym do czasu przywrócenia pierwotnego węzła lub przywrócenia go do trybu online, kiedy to usługi lub instancje muszą zostać przywrócone do niego po awarii w celu przywrócenia wysokiej dostępności .
  • N-do-N — połączenie klastrów aktywnych/aktywnych i N+M, klastrów N do N redystrybuuje usługi, instancje lub połączenia z uszkodzonego węzła między pozostałe aktywne węzły, eliminując w ten sposób (podobnie jak w przypadku aktywnych/aktywnych) potrzebę dla węzła „rezerwowego”, ale wprowadzając potrzebę dodatkowej przepustowości we wszystkich węzłach aktywnych.

Terminy host logiczny lub host logiczny klastra są używane do opisania adresu sieciowego używanego do uzyskiwania dostępu do usług świadczonych przez klaster. Ta logiczna tożsamość hosta nie jest powiązana z pojedynczym węzłem klastra. W rzeczywistości jest to adres sieciowy/nazwa hosta powiązana z usługami świadczonymi przez klaster. Jeśli węzeł klastra z uruchomioną bazą danych ulegnie awarii, baza danych zostanie ponownie uruchomiona w innym węźle klastra.

Niezawodność węzła

Klastry HA zwykle wykorzystują wszystkie dostępne techniki, aby poszczególne systemy i współdzielona infrastruktura były jak najbardziej niezawodne. Obejmują one:

Funkcje te pomagają zminimalizować prawdopodobieństwo konieczności przełączania awaryjnego klastrów między systemami. Podczas takiego przełączania awaryjnego świadczona usługa jest niedostępna przynajmniej przez chwilę, dlatego preferowane są środki zapobiegające przełączaniu awaryjnemu.

Strategie przełączania awaryjnego

Systemy obsługujące awarie w przetwarzaniu rozproszonym mają różne strategie naprawy awarii. Na przykład Apache Cassandra API Hector definiuje trzy sposoby konfiguracji przełączania awaryjnego:

  • Fail Fast , skryptowany jako „FAIL_FAST”, oznacza, że ​​próba wyleczenia awarii kończy się niepowodzeniem, jeśli nie można osiągnąć pierwszego węzła.
  • W przypadku niepowodzenia wypróbuj jeden — następny dostępny , zapisany jako „ON_FAIL_TRY_ONE_NEXT_AVAILABLE”, oznacza, że ​​system próbuje użyć jednego hosta, najbardziej dostępnego lub dostępnego, zanim się podda.
  • On Fail, Try All , skrypt jako „ON_FAIL_TRY_ALL_AVAILABLE”, oznacza, że ​​system próbuje wszystkich istniejących, dostępnych węzłów, zanim się podda.

Zobacz też

Dalsza lektura

  •   Greg Pfister: W poszukiwaniu klastrów , Prentice Hall, ISBN 0-13-899709-8
  •   Evan Marcus, Hal Stern: Plany wysokiej dostępności: projektowanie odpornych systemów rozproszonych , John Wiley & Sons, ISBN 0-471-35601-8
  •   Chee-Wei Ang, Chen-Khong Tham: Analiza i optymalizacja dostępności usług w klastrze HA z dostępnością maszyn zależnych od obciążenia , IEEE Transactions on Parallel and Distributed Systems, tom 18, wydanie 9 (wrzesień 2007), strony 1307-1319, ISSN 1045-9219 [1]
Pobrano z „ https://en.wikipedia.org/w/index.php?title=High-availability_cluster&oldid=1138360695 ”