Cześć, czytelnicy Habra! W poprzednim artykule opowiedzieliśmy o prostym narzędziu odporności na awarie w systemach przechowywania AERODISK ENGINE – o replikacji. W tym artykule zagłębimy się w bardziej złożony i interesujący temat – metroklaster, czyli zautomatyzowane narzędzie ochrony przed katastrofami dla dwóch centr danych, które umożliwia centrów danych pracę w trybie active-active. Opowiemy, pokażemy, złamiemy i naprawimy.
Jak zwykle, na początku teoria
Metroklaster to klaster rozproszony na kilku lokalizacjach w obrębie miasta lub regionu. Słowo 'klaster' jasno sugeruje, że kompleks jest zautomatyzowany, czyli przełączanie węzłów klastra w przypadku awarii (failover) odbywa się automatycznie.
W tym tkwi zasadnicza różnica między metroklasterem a zwykłą replikacją. Automatyzacja operacji. Oznacza to, że w przypadku różnych zdarzeń (awaria centr danych, przerwanie łączy itp.) system przechowywania samodzielnie podejmie niezbędne kroki, aby zapewnić dostępność danych. W przypadku zwykłych replik te działania są wykonywane w pełni lub częściowo ręcznie przez administratora.
Po co to potrzebne?
Głównym celem, który stawiają sobie klienci korzystający z różnych realizacji metroklastra, jest minimalizacja RTO (Recovery Time Objective). Oznacza to minimalizację czasu przywracania usług IT po awarii. Korzystając z tradycyjnej replikacji, czas przywracania będzie zawsze dłuższy niż czas przywracania w przypadku metroklastra. Dlaczego? To proste. Administrator musi być w pracy i ręcznie przełączyć replikację, a metroklaster robi to automatycznie.
Jeśli nie masz dedykowanego administratora dyżurnego, który nie śpi, nie je, nie pali i nie choruje, a przez 24 godziny na dobę monitoruje stan systemu przechowywania, to niemożliwe jest zapewnienie, że administrator będzie dostępny do ręcznego przełączania w czasie awarii.
Odpowiednio RTO w przypadku braku metroklastra lub nieśmiertelnego administratora 99 poziomu dyżurnego zespołu administratorów będzie równe sumie czasu przełączania wszystkich systemów i maksymalnemu okresowi czasu, po którym administrator gwarantowanie zacznie pracować z systemem przechowywania i pokrewnymi systemami.
W ten sposób dochodzimy do oczywistego wniosku, że metroklast należy stosować, gdy wymagania dotyczące RTO to minuty, a nie godziny lub dni. Oznacza to, że w przypadku najgorszego możliwego upadku centrum danych, dział IT musi zapewnić biznesowi czas na przywrócenie dostępu do usług IT w ciągu minut, a nawet sekund.
Jak to działa?
Na dolnym poziomie metroklast wykorzystuje mechanizm synchronnej replikacji danych, który opisaliśmy w poprzednim artykule (zob. ). Ponieważ replikacja jest synchronna, wymogi dotyczące niej są odpowiednie, a dokładniej:
- światłowód jako fizyczny nośnik, Ethernet 10 gigabitowy (lub wyższy);
- odległość między centrami danych nie przekracza 40 kilometrów;
- opóźnienie między centrami danych (między macierzami) do 5 milisekund (optymalnie 2).
Wszystkie te wymagania mają charakter zalecający, to znaczy metroklast będzie działał, nawet jeśli nie będą one spełnione, ale należy rozumieć, że konsekwencje ich niespełnienia będą równe spowolnieniu pracy obu macierzy w metroklaście.
Tak więc do przesyłania danych między macierzami używana jest synchronna replikacja, a w jaki sposób repliki są automatycznie przełączane, a co najważniejsze, jak uniknąć split-brain? W tym celu na wyższym poziomie używana jest dodatkowa jednostka — arbiter.
Jak działa arbiter i jakie ma zadanie?
Arbiter jest małą maszyną wirtualną lub klastrem sprzętowym, który należy uruchomić na trzecim miejscu (na przykład w biurze) i zapewnić dostęp do macierzy przez ICMP i SSH. Po uruchomieniu arbiter powinien ustawić adres IP, a następnie ze strony macierzy wskazać jego adres oraz adresy zdalnych kontrolerów uczestniczących w metroklaście. Po tym arbiter jest gotowy do pracy.
Arbiter monitoruje wszystkie macierze w metroklaście i w przypadku niedostępności którejkolwiek z systemów pamięci, po potwierdzeniu niedostępności przez innego uczestnika klastra (jedną z 'aktywnych' macierzy), podejmuje decyzję o uruchomieniu procedury przełączania zasad replikacji i mapowania.
Bardzo ważny moment. Arbiter zawsze musi znajdować się w miejscu innym niż te, w których znajdują się macierze, to znaczy ani w Centrum Danych 1, gdzie znajduje się macierz 1, ani w Centrum Danych 2, gdzie zainstalowana jest macierz 2.
Dlaczego? Ponieważ tylko w ten sposób arbiter za pomocą jednego z przetrwałych systemów pamięci masowej może jednoznacznie i bezbłędnie określić awarię dowolnej z dwóch lokalizacji, w których zainstalowane są systemy pamięci masowej. Jakiekolwiek inne sposoby umieszczania arbitra mogą prowadzić do split-brain.
Teraz zanurzmy się w szczegóły działania arbitra
Na arbitrze działa kilka usług, które nieprzerwanie sprawdzają wszystkie kontrolery systemów pamięci masowej. Jeśli wynik sprawdzenia różni się od poprzedniego (dostępny/niedostępny), jest zapisywany w małej bazie danych, która działa także na arbitra.
Przyjrzyjmy się bliżej logice pracy arbitra.
Krok 1. Określenie niedostępności. Wydarzeniem-sygnałem awarii systemu pamięci masowej jest brak pingów z obu kontrolerów jednego systemu pamięci masowej przez 5 sekund.
Krok 2. Uruchomienie procedury przełączania. Po tym, jak arbiter zrozumie, że jeden z systemów pamięci masowej jest niedostępny, wysyła zapytanie do „żywego” systemu pamięci masowej, aby upewnić się, że „martwy” system pamięci masowej rzeczywiście nie działa.
Po otrzymaniu takiego polecenia od arbitra, drugi (żywy) system pamięci masowej dodatkowo sprawdza dostępność pierwszego systemu pamięci masowej, który uległ awarii, a jeśli go nie ma, przesyła arbitrze potwierdzenie swojej hipotezy. System pamięci masowej jest rzeczywiście niedostępny.
Po otrzymaniu takiego potwierdzenia arbiter uruchamia zdalną procedurę przełączania replikacji i uruchamiania mapowania na tych replikach, które były aktywne (primary) w upadłym systemie pamięci masowej, i wysyła polecenie do drugiego systemu pamięci masowej, aby przekształcił te repliki z secondary w primary i uruchomił mapowanie. A drugi system pamięci masowej wykonuje odpowiednie procedury, po czym zapewnia dostęp do utraconych LUN-ów z siebie.
Po co dodatkowe sprawdzenie? Dla kworum. To znaczy, że większość z ogólnej nieparzystej liczby (3) uczestników klastra musi potwierdzić awarię jednego z węzłów klastra. Tylko wtedy ta decyzja będzie dokładnie poprawna. Jest to potrzebne, aby uniknąć błędnego przełączania i, co za tym idzie, split-brain.
Krok 2 zajmuje około 5 – 10 sekund, w związku z tym, uwzględniając czas potrzebny na określenie niedostępności (5 sekund), w ciągu 10 – 15 sekund po awarii LUN-y z upadłym systemem pamięci masowej będą automatycznie dostępne do pracy z żywym systemem pamięci masowej.
Oczywiście, aby uniknąć zerwania połączenia z hostami, należy również zadbać o odpowiednie ustawienie timeoutów na hostach. Zalecany timeout wynosi co najmniej 30 sekund. To zapewni, że host nie rozłączy połączenia z macierzą dyskową podczas zmiany obciążenia w przypadku awarii i zagwarantuje brak przerwy w wejściu-wyjściu.
Chwileczkę, więc jeśli z metroklastrem wszystko jest tak dobrze, to po co w ogóle potrzebna jest zwykła replikacja?
W rzeczywistości wcale nie jest to takie proste.
Rozważmy zalety i wady metroklastra
Zrozumieliśmy, że oczywistymi zaletami metroklastra w porównaniu do zwykłej replikacji są:
- Całkowita automatyzacja, zapewniająca minimalny czas przywracania w przypadku katastrofy;
- I to wszystko :-).
A teraz, uwaga, wady:
- Koszt rozwiązania. Chociaż metroklaustr w systemach Airodisk nie wymaga dodatkowego licencjonowania (używana jest ta sama licencja, co na replikę), koszt rozwiązania będzie i tak wyższy niż przy użyciu replikacji synchronizacyjnej. Należy spełnić wszystkie wymagania dla replikacji synchronizacyjnej, plus wymagania dla metroklastra związane z dodatkowym przełączaniem i dodatkową lokalizacją (zob. planowanie metroklastra);
- Złożoność rozwiązania. Metroklaustr jest znacznie bardziej skomplikowany niż zwykła replika i wymaga znacznie większej uwagi oraz pracochłonności na etapie planowania, ustawiania i dokumentowania.
W rezultacie. Metroklaustr to z pewnością bardzo technologiczne i dobre rozwiązanie, kiedy naprawdę trzeba zapewnić RTO w sekundach lub minutach. Jednak jeśli takie zadanie nie istnieje, a RTO w godzinach jest akceptowalne dla biznesu, to nie ma sensu strzelać z armaty do wróbli. Wystarczy zwykła pracownicza replikacja, ponieważ metroklaustr spowoduje dodatkowe koszty i skomplikowanie infrastruktury IT.
Planowanie metroklastra
Ta sekcja nie ma na celu przedstawienia wyczerpującego poradnika po projektowaniu metroklastra, ale jedynie pokazuje główne kierunki, które należy przemyśleć, jeśli zdecydowałeś się zbudować taki system. Dlatego przy rzeczywistej implementacji metroklastra koniecznie angażuj producenta macierzy dyskowej (czyli nas) oraz innych systemów pokrewnych do konsultacji.
Lokalizacje
Jak wskazano powyżej, dla metroklastra wymagana jest co najmniej trójka lokalizacji. Dwa centra danych, w których będą działać macierze dyskowe i systemy pokrewne oraz trzecia lokalizacja, w której będzie działał arbiter.
Zalecana odległość między centrami danych wynosi nie więcej niż 40 kilometrów. Większa odległość z dużym prawdopodobieństwem spowoduje dodatkowe opóźnienia, które w przypadku metroklastra są niezwykle niepożądane. Przypominamy, że opóźnienia powinny wynosić do 5 milisekund, chociaż lepiej zmieścić się w 2.
Opóźnienia zaleca się również sprawdzać w toku planowania. Każdy większy lub mniej doświadczony dostawca, który oferuje światłowód między centrami danych, może szybko zorganizować wysokiej jakości testy.
Jeśli chodzi o opóźnienia do arbitra (czyli między trzecią lokalizacją a dwiema pierwszymi), zalecany próg opóźnień wynosi do 200 milisekund, co oznacza, że standardowe połączenie VPN w firmie nadawałoby się w tej sytuacji.
Komutacja i sieć
W przeciwieństwie do schematu replikacji, gdzie wystarczy połączyć ze sobą macierze dyskowe z różnych lokalizacji, schemat metroklastra wymaga połączenia hostów z obiema macierzami na różnych lokalizacjach. Aby było jaśniej, w czym tkwi różnica, obie schematy przedstawiono poniżej.
Jak widać z diagramu, hosty lokalizacji 1 mają dostęp zarówno do macierzy 1, jak i 2. Podobnie, hosty lokalizacji 2 mają dostęp zarówno do macierzy 2, jak i 1. Oznacza to, że każdy host widzi obie macierze. To warunek konieczny do działania metroklastra.
Oczywiście nie ma potrzeby ciągnięcia każdego hosta za pomocą optycznego kabla do innego centrum danych, żadne porty i kable by się nie zmieściły. Wszystkie te połączenia muszą być realizowane za pośrednictwem przełączników Ethernet 10G+ lub Fibre Channel 8G+ (FC tylko do połączeń hostów z macierzami w celu IO, kanał replikacji jest dostępny tylko przez IP (Ethernet 10G+).
Teraz kilka słów o topologii sieci. Ważnym aspektem jest poprawna konfiguracja podsieci. Należy od razu określić kilka podsieci dla następujących typów ruchu:
- Podsieć do replikacji, przez którą będą synchronizowane dane między macierzami. Może ich być kilka, w tym przypadku nie ma to znaczenia, wszystko zależy od obecnej (już zaimplementowanej) topologii sieci. Jeśli jest ich dwie, to oczywiście należy skonfigurować routowanie między nimi.
- Podsieci do przechowywania danych, przez które hosty będą miały dostęp do zasobów SŁD (jeśli to iSCSI). Takie podsieci powinny być po jednej w każdym centrum danych;
- Podsieci zarządzające, czyli trzy trasowane podsieci w trzech lokalizacjach, z których zarządza się SŁD, a także gdzie znajduje się arbiter.
Podsieci do dostępu do zasobów hostów nie są tutaj rozważane, ponieważ mocno zależą od zadań.
Podział różnego ruchu na różne podsieci jest niezwykle ważny (szczególnie istotne jest oddzielenie replikacji od wejścia-wyjścia), ponieważ jeśli cały ruch zostanie zmieszany w jedną «grubą» podsieć, jego zarządzanie stanie się niemożliwe, a w warunkach dwóch centrów danych może to spowodować różne rodzaje kolizji sieciowych. W tej kwestii nie będziemy się zbytnio zagłębiać w tym artykule, ponieważ o planowaniu rozciągniętej między centrum danych sieci można przeczytać w zasobach producentów sprzętu sieciowego, gdzie jest to bardzo szczegółowo opisane.
Konfiguracja arbitra
Arbiter musi zapewnić dostęp do wszystkich interfejsów zarządzających SŁD przez protokoły ICMP i SSH. Należy również rozważyć awaryjność arbitra. Istnieje tu pewien szczegół.
Awaryjność arbitra jest bardzo pożądana, ale nieobowiązkowa. Co się stanie, jeśli arbiter zawiedzie w niewłaściwym momencie?
- Praca metroklastra w normalnym trybie nie ulegnie zmianie, ponieważ arbiter nie wpływa na pracę metroklastra w normalnym trybie (jego zadaniem jest na czas przełączyć obciążenie między centrami danych)
- W przypadku, gdy arbiter z jakiegokolwiek powodu upadnie i «prześpi» awarię w centrum danych, nie dojdzie do żadnego przełączenia, ponieważ nie ma nikogo, kto wydałby potrzebne polecenia i zorganizował quorum. W tym przypadku metroklauster przemieni się w zwykły schemat replikacji, który podczas katastrofy będzie trzeba przełączać ręcznie, co wpłynie na RTO.
Co z tego wynika? Jeżeli rzeczywiście trzeba zapewnić minimalny wskaźnik RTO, należy zapewnić awaryjność arbitra. W tym celu są dwa warianty:
- Uruchomienie wirtualnej maszyny z arbitrem na awaryjnym hyperwizorze, ponieważ wszystkie dojrzałe hyperwizory obsługują awaryjność;
- Jeśli na trzecim miejscu (w hipotetycznym biurze) nie chce się instalować prawidłowego klastra z hiperlokalizatorami, to przewidzieliśmy sprzętową wersję arbitra, która znajduje się w obudowie 2U, w której pracują dwa standardowe serwery x86 i która może przeżyć lokalną awarię.
Zalecamy zdecydowanie zapewnienie odporności na awarie arbitra, mimo że w standardowym trybie nie jest on potrzebny w metrokleście. Ale jak pokazuje teoria i praktyka, jeśli chcemy zbudować naprawdę niezawodną infrastrukturę odporną na katastrofy, lepiej dmuchać na zimne. Lepiej chronić siebie i biznes przed "prawem podłości", czyli przed jednoczesnym uszkodzeniem arbitra i jednej z lokalizacji, gdzie znajduje się macierz dyskowa.
Architektura rozwiązania
Biorąc pod uwagę powyższe wymagania, otrzymujemy następującą ogólną architekturę rozwiązania.
LUN-y należy równomiernie rozłożyć pomiędzy dwoma lokalizacjami, aby uniknąć silnego obciążenia. Przy tym przy planowaniu w obu centrach danych należy uwzględnić nie tylko podwójną pojemność (która jest niezbędna do jednoczesnego przechowywania danych na dwóch macierzach dyskowych), ale także podwójną wydajność w IOPS i MB/s, aby nie dopuścić do degradacji aplikacji w warunkach awarii jednego z centrów danych.
Osobno zauważamy, że przy właściwym podejściu do planowania (to znaczy pod warunkiem, że uwzględniliśmy odpowiednie górne granice IOPS i MB/s, a także niezbędne zasoby CPU i RAM) w przypadku awarii jednej z macierzy dyskowych w metrokleście nie będzie znacznego spadku wydajności przy tymczasowej pracy na jednej macierzy.
Wyjaśnia się to tym, że w warunkach jednoczesnej pracy dwóch lokalizacji, działająca synchrona replikacja 'zjada' połowę wydajności przy zapisie, ponieważ każdą transakcję trzeba zarejestrować na dwóch macierzach (podobnie jak RAID-1/10). Tak więc, przy awarii jednej z macierzy, wpływ replikacji tymczasowo (dopóki nie wznowi się działająca macierz) znika, a my zyskujemy dwukrotny wzrost wydajności zapisu. Po tym, jak LUN-y awaryjnej macierzy zostaną wznowione na działającej macierzy, ten dwukrotny wzrost znika z powodu obciążenia z LUN-ów drugiej macierzy, wracamy do tego samego poziomu wydajności, jaki mieliśmy przed 'spadkiem', ale tylko w ramach już jednej lokalizacji.
Dzięki odpowiedniemu dobraniu wielkości można stworzyć warunki, w których użytkownicy nie odczują całkowitego braku działania macierzy. Jednak po raz kolejny podkreślamy, że wymaga to bardzo uważnego dobrania wielkości, do którego można się do nas zgłosić bezpłatnie :-).
Konfiguracja metroklastera
Konfiguracja metroklastera jest bardzo podobna do ustawienia zwykłej replikacji, którą opisaliśmy w . Dlatego skoncentrujmy się tylko na różnicach. Ustawiliśmy w laboratorium stanowisko oparte na wyżej opisanej architekturze, tylko w minimalnej wersji: dwie macierze połączone między sobą przez 10G Ethernet, dwa przełączniki 10G i jeden host, który łączy się z oboma macierzami przez porty 10G. Arbiter działa na maszynie wirtualnej.
Podczas konfigurowania wirtualnych adresów IP (VIP) dla repliki należy wybrać typ VIP – dla metroklastera.
Utworzyliśmy dwa połączenia replikacyjne dla dwóch LUN-ów i rozdzieliliśmy je między dwoma macierzami: LUN TEST Primary na macierzy1 (połączenie METRO), LUN TEST2 Primary dla macierzy2 (połączenie METRO2).
Dla nich skonfigurowaliśmy dwa identyczne cele (w naszym przypadku iSCSI, ale wspierany jest również FC, logika konfiguracji jest ta sama).
Macierz1:
Macierz2:
Dla połączeń replikacyjnych wykonaliśmy mapowania na każdej macierzy.
Macierz1:
Macierz2:
Skonfigurowaliśmy multipath i udostępniliśmy na hoście.
Konfigurujemy arbitra
Z samym arbtirem nie trzeba robić wiele, należy go po prostu włączyć na trzecim obszarze, przypisać mu IP i skonfigurować dostęp przez ICMP oraz SSH. Sama konfiguracja odbywa się z poziomu macierzy. Przy tym konfigurację arbitra wystarczy wykonać jeden raz na dowolnym z kontrolerów macierzy w metroklasterze, a ustawienia te zostaną automatycznie rozpropagowane na wszystkie kontrolery.
W sekcji Replikacja zdalna>> Metroklaster (na dowolnym kontrolerze)>> przycisk „Skonfiguruj”.
Wprowadzamy IP arbitra oraz interfejsy sterujące dwóch kontrolerów zdalnej macierzy.
Następnie należy włączyć wszystkie usługi (przycisk „Zrestartuj wszystko”). W przypadku przyszłej rekonfiguracji usługi należy koniecznie ponownie uruchomić, aby ustawienia weszły w życie.
Sprawdzamy, czy wszystkie usługi są uruchomione.
Na tym konfiguracja metroklastera jest zakończona.
Test awaryjny
Test awaryjny w naszym przypadku będzie wystarczająco prosty i szybki, ponieważ funkcjonalność replikacji (przełączanie, spójność itd.) została już omówiona w . Dlatego do przetestowania niezawodności metroklastra wystarczy sprawdzić automatyzację wykrywania awarii, przełączenia oraz brak utraty danych podczas zapisu (zatrzymania wejścia-wyjścia).
W tym celu emulujemy całkowitą awarię jednej z macierzy, fizycznie wyłączając oba jej kontrolery, uruchamiając wcześniej kopiowanie dużego pliku na LUN, który powinien zostać aktywowany na innej macierzy.
Wyłączamy jedną macierz. Na drugiej macierzy widzimy alarmy i komunikaty w logach informujące o utracie połączenia z sąsiednim systemem. Jeśli są skonfigurowane powiadomienia za pomocą SMTP lub monitoringu SNMP, administrator otrzyma odpowiednie powiadomienia.
Dokładnie po 10 sekundach (co widać na obu zrzutach ekranu) połączenie replikacyjne METRO (to, które było Primary na uszkodzonej macierzy) automatycznie stało się Primary na działającej macierzy. Dzięki istniejącemu mapowaniu, LUN TEST pozostał dostępny dla hosta, zapis lekko spadł (w granicach obiecanych 10 procent), ale nie został przerwany.
Test zakończony pomyślnie.
Podsumowując
Aktualna realizacja metroklastra w systemach pamięci AERODISK Engine serii N w pełni pozwala rozwiązywać zadania, w których wymagane jest wykluczenie lub minimalizacja czasu przestoju usług IT oraz zapewnienie ich działania w trybie 24/7/365 przy minimalnych nakładach pracy.
Można oczywiście powiedzieć, że to wszystko teoria, idealne warunki laboratoryjne i tak dalej… ALE mamy szereg zrealizowanych projektów, w których wdrożyliśmy funkcjonalność odporności na katastrofy, i systemy działają świetnie. Jeden z naszych dość znanych klientów, który wykorzystuje właśnie dwie macierze w konfiguracji odpornej na katastrofy, już wyraził zgodę na publikację informacji o projekcie, dlatego w następnej części opowiemy o wdrożeniu w warunkach rzeczywistych.
Dziękujemy, czekamy na owocną dyskusję.
Źródło: habr.com
