Witam, czytelnicy Habr! Tematem tego artykułu będzie realizacja rozwiązań związanych z odpornością na awarie w systemach magazynowania AERODISK Engine. Początkowo chcieliśmy napisać o obu rozwiązaniach: replikacji i metroklastrach w jednym artykule, ale niestety artykuł okazał się zbyt obszerny, dlatego podzieliliśmy go na dwie części. Przejdźmy od prostego do złożonego. W tym artykule skonfigurujemy i przetestujemy synchronizowaną replikację – wyłączymy jedno centrum danych oraz przerwiemy łącze komunikacyjne między centrami danych i zobaczymy, co się wydarzy.
Nasi klienci często zadają nam różne pytania dotyczące replikacji, dlatego zanim przejdziemy do konfiguracji i testowania wdrożeń replik, krótko opowiemy, czym jest replikacja w systemie magazynowania.
Trochę teorii
Replikacja w systemie magazynowania to ciągły proces zapewnienia tożsamości danych jednocześnie w kilku systemach magazynowania. Technicznie replikacja jest realizowana dwiema metodami.
Replikacja synchronizowana to kopiowanie danych z głównego systemu magazynowania do rezerwowego z obowiązkowym potwierdzeniem obu systemów, że dane zostały zapisane i potwierdzone. Dopiero po potwierdzeniu z obu stron (z obu systemów magazynowania) dane są uznawane za zapisane i mogą być używane. W ten sposób zapewniona jest gwarantowana tożsamość danych we wszystkich systemach magazynowania uczestniczących w replikacji.
Zalety tej metody:
- Dane są zawsze identyczne we wszystkich systemach magazynowania
Wady:
- Wysoki koszt rozwiązania (szybkie łącza komunikacyjne, drogie włókna optyczne, transceivery długofalowe itp.)
- Ograniczenia dotyczące odległości (w granicach kilku dziesiątek kilometrów)
- Brak ochrony przed logicznym uszkodzeniem danych (jeśli dane zostaną uszkodzone (świadomie lub przypadkowo) w głównym systemie magazynowania, to automatycznie i natychmiast staną się uszkodzone w rezerwowym, ponieważ dane są zawsze identyczne (taki paradoks))
Replikacja asynchronizowana to również kopiowanie danych z głównego systemu magazynowania do rezerwowego, ale z pewnym opóźnieniem i bez konieczności potwierdzania zapisu po stronie drugiej. Z danymi można pracować od razu po zapisie w głównym systemie magazynowania, a w rezerwowym systemie magazynowania dane będą dostępne po pewnym czasie. W tym przypadku tożsamość danych, jak wiadomo, nie jest zapewniona wcale. Dane w rezerwowym systemie magazynowania zawsze są nieco "w przeszłości".
Zalety replikacji asynchronizowanej:
- Niska cena rozwiązania (wszystkie kanały łączności, optyka opcjonalnie)
- Brak ograniczeń co do odległości
- Na zapasowym systemie przechowywania dane nie ulegają uszkodzeniu w przypadku ich uszkodzenia na głównym (przynajmniej przez pewien czas). Jeśli dane zostaną uszkodzone, zawsze można zatrzymać replikę, aby zapobiec uszkodzeniu danych na zapasowym systemie przechowywania.
Wady:
- Dane w różnych centrach danych zawsze są niedokładnie identyczne
Dlatego wybór trybu replikacji zależy od zadań biznesowych. Jeśli krytyczne jest, aby w zapasowym centrum danych były dokładnie te same dane co w głównym (tj. wymóg biznesowy dotyczący RPO=0), należy zainwestować i pogodzić się z ograniczeniami replikacji synchronicznej. A jeśli opóźnienia w stanie danych są akceptowalne lub po prostu brak pieniędzy, w zdecydowany sposób należy zastosować metodę asynchroniczną.
Osobno wyróżniamy taki tryb (dokładniej, już topologię) jak metroklaster. W trybie metroklastera stosuje się replikację synchroniczną, lecz w odróżnieniu od zwykłej repliki, metroklaster pozwala obu systemom przechowywania działać w trybie aktywnym. To znaczy, nie ma podziału na aktywne i zapasowe centra danych. Aplikacje działają jednocześnie na dwóch systemach przechowywania, które fizycznie znajdują się w różnych centrach danych. Czas przestojów w przypadku awarii w takiej topologii jest bardzo krótki (RTO, zazwyczaj minuty). W tym artykule nie będziemy omawiać naszej implementacji metroklastera, ponieważ jest to bardzo duży i obszerny temat, dlatego poświęcimy mu osobny artykuł, jako kontynuację tego.
Bardzo często, gdy mówimy o replikacji za pomocą systemów przechowywania, wiele osób zadaje słuszne pytanie: > „Wiele aplikacji ma swoje własne środki replikacji, dlaczego więc używać replikacji w systemie przechowywania? Czy to lepsze czy gorsze?”
Nie ma jednoznacznej odpowiedzi, dlatego przedstawiamy argumenty ZA i PRZECIW:
Argumenty ZA replikację systemu przechowywania:
- Prostota rozwiązania. Jednym narzędziem możesz replikować całą macierz danych, niezależnie od rodzaju obciążenia i aplikacji. Jeśli używasz replikacji od aplikacji, konieczne będzie skonfigurowanie każdej aplikacji osobno. Jeśli jest ich więcej niż 2, to jest to skrajnie czasochłonne i kosztowne (replikacja aplikacji wymaga zazwyczaj osobnej i odpłatnej licencji na każdą aplikację. Ale o tym więcej poniżej).
- Można replikować cokolwiek – dowolne aplikacje, dowolne dane – i zawsze będą one spójne. Wiele (większość) aplikacji nie ma środków do replikacji, a replikacja ze strony macierzy dyskowej to jedyny sposób na zapewnienie ochrony przed katastrofami.
- Nie trzeba przepłacać za funkcjonalność replikacji aplikacji. Zazwyczaj jest ona dość droga, podobnie jak licencje na replikację macierzy dyskowych. Jednak za licencję na replikację macierzy dyskowej trzeba zapłacić jednorazowo, podczas gdy licencję na replikację aplikacji trzeba kupować dla każdej aplikacji z osobna. Jeśli takich aplikacji jest dużo, to zaczyna to kosztować, a cena licencji na replikację macierzy dyskowych staje się kroplą w morzu.
Argumenty PRZECIW replikacji macierzy dyskowych:
- Replikacja za pomocą aplikacji ma więcej funkcjonalności z punktu widzenia samych aplikacji, aplikacja lepiej zna swoje dane (co jest oczywiste), dlatego jest więcej sposobów na ich obsługę.
- Producenci niektórych aplikacji nie gwarantują spójności swoich danych, jeśli replikacja odbywa się za pomocą zewnętrznych środków. *
* - kontrowersyjna teza. Na przykład znana firma produkująca systemy zarządzania bazami danych przez długi czas oficjalnie twierdziła, że ich system bazy danych może być prawidłowo replikowany tylko za pomocą ich środków, a pozostała replikacja (w tym z macierzy dyskowych) to „nieprawda”. Jednak życie pokazało, że tak nie jest. Najprawdopodobniej (ale niekoniecznie) była to po prostu nie najszczersza próba sprzedaży kolejnych licencji klientom.
W rezultacie w większości przypadków replikacja ze strony macierzy dyskowej jest lepsza, ponieważ jest to prostsza i tańsza opcja, ale są skomplikowane przypadki, gdy wymagana jest specyficzna funkcjonalność aplikacji i należy pracować z replikacją na poziomie aplikacji.
Teorię mamy za sobą, teraz praktyka
Będziemy konfigurować replikację w naszym laboratorium. W warunkach laboratoryjnych emulowaliśmy dwa centra danych (w rzeczywistości dwa stojaki obok siebie, które wydają się znajdować w różnych budynkach). Stanowisko składa się z dwóch macierzy dyskowych Engine N2, które są ze sobą połączone światłowodami. Do obu macierzy podłączony jest fizyczny serwer z systemem Windows Server 2016 korzystający z Ethernetu 10Gb. Stanowisko jest dość proste, ale to nie zmienia jego istoty.
Schematycznie wygląda to następująco:
Logicznie replikacja jest zorganizowana w następujący sposób:
Teraz przyjrzymy się możliwościom replikacji, które mamy w tej chwili.
Obsługiwane są dwa tryby: asynchroniczny i synchroniczny. Oczywiste jest, że tryb synchroniczny jest ograniczony odległością i kanałem komunikacyjnym. W szczególności dla trybu synchronicznego konieczne jest użycie światłowodu jako medium oraz Ethernetu 10 gigabitowego (lub wyższego).
Maksymalny zasięg dla synchronizacji replikacji wynosi 40 kilometrów, a opóźnienia kanału optycznego między centrami danych nie mogą przekraczać 2 milisekund. Generalnie będzie działać również z większymi opóźnieniami, ale wówczas mogą wystąpić znaczące opóźnienia przy zapisie (co również jest zrozumiałe). Dlatego jeśli planujesz synchronizację replikacji między centrami danych, warto sprawdzić jakość optyki i opóźnienia.
Dla asynchronicznej replikacji wymagania nie są tak rygorystyczne. A dokładniej, nie ma ich wcale. Można używać dowolnego działającego połączenia przez Ethernet.
Na chwilę obecną w macierzach AERODISK ENGINE wspierana jest replikacja dla urządzeń blokowych (LUN-ów) przez protokół Ethernet (przez miedź lub optykę). Dla projektów, gdzie konieczna jest replikacja przez SAN-fabrykę za pomocą Fibre Channel, aktualnie opracowujemy odpowiednie rozwiązanie, ale na razie nie jest ono gotowe, więc w naszym przypadku – tylko Ethernet.
Replikacja może działać pomiędzy dowolnymi macierzami z serii ENGINE (N1, N2, N4) z systemów niższych na wyższe i odwrotnie.
Funkcjonalność obu trybów replikacji jest całkowicie identyczna. Poniżej szczegóły na temat dostępnych opcji:
- Replikacja „one to one” lub „jeden do jednego”, co oznacza klasyczną opcję z dwoma centrami danych: głównym i zapasowym.
- Replikacja „one to many” lub „jeden do wielu”, tzn. jeden LUN można replikować na kilka macierzy jednocześnie.
- Aktywacja, dezaktywacja oraz „odwrócenie” replikacji, odpowiednio, dla włączenia, wyłączenia lub zmiany kierunku replikacji.
- Replikacja jest dostępna zarówno dla pul RDG (Raid Distributed Group), jak i dla DDP (Dynamic Disk Pool). Przy tym LUN puli RDG można replikować tylko do innego RDG. Z DDP podobnie.
Jest jeszcze wiele drobnych szczegółów, ale ich wymienianie nie ma większego sensu, będziemy je wspominać w miarę konfiguracji.
Konfiguracja replikacji
Proces konfiguracji jest dosyć prosty i składa się z trzech etapów.
- Konfiguracja sieci
- Konfiguracja magazynu
- Konfiguracja reguł (powiązań) i mapowania
Ważnym aspektem konfiguracji replikacji jest to, że pierwsze dwa etapy należy powtórzyć na zdalnej macierzy, trzeci etap – tylko na głównej.
Konfiguracja zasobów sieciowych
Pierwszym krokiem jest skonfigurowanie portów sieciowych, przez które będzie przesyłany ruch replikacji. W tym celu należy włączyć porty i przypisać im adresy IP w sekcji adapterów Front-end.
Następnie musimy utworzyć pulę (w naszym przypadku RDG) oraz wirtualny IP do replikacji (VIP). VIP to pływający adres IP przypisany do dwóch „fizycznych” adresów kontrolerów macierzy dyskowej (portów, które właśnie skonfigurowaliśmy). Będzie to główny interfejs replikacji. Można również operować na VLAN-ie, jeśli potrzebujesz pracować z oznaczonym ruchem.
Proces tworzenia VIP dla repliki niewiele różni się od tworzenia VIP do wejścia-wyjścia (NFS, SMB, iSCSI). VIP w tym przypadku tworzymy standardowy (bez VLAN), ale koniecznie wskazujemy, że jest on do replikacji (bez tego wskaźnika nie będziemy mogli dodać VIP do reguły w następnym kroku).
VIP musi znajdować się w tej samej podsieci co IP portów, między którymi „pływa”.
Powtarzamy te ustawienia na zdalnej macierzy, oczywiście z innym adresem IP.
VIP-y z różnych macierzy mogą znajdować się w różnych podsieciach, ważne, aby między nimi istniała routowalność. W naszym przypadku jest to właśnie taki przykład (192.168.3.XX i 192.168.2.XX)
Na tym przygotowanie części sieciowej zostało zakończone.
Konfigurujemy storage
Konfiguracja storage'u pod replikę różni się od standardowej tylko tym, że mapowanie wykonujemy przez specjalne menu „Mapowanie replikacji”. W pozostałych kwestiach wszystko pozostaje takie samo jak w standardowej konfiguracji. Teraz po kolei.
W wcześniej utworzonej puli R02 należy utworzyć LUN. Tworzymy go, nazywając LUN1.
Musimy również utworzyć identyczny LUN na zdalnej macierzy o tej samej pojemności. Tworzymy. Aby uniknąć zamieszania, zdalny LUN nazwiemy LUN1R
Gdybyśmy potrzebowali wziąć LUN, który już istnieje, to na czas konfiguracji repliki ten produkcyjny LUN należałoby odmontować od hosta, a na zdalnej macierzy po prostu utworzyć pusty LUN o tej samej pojemności.
Konfiguracja storage'u została zakończona, przechodzimy do tworzenia reguły replikacji.
Konfiguracja reguł replikacji lub powiązań replikacyjnych
Po utworzeniu LUN-ów na macierzy, która w danym momencie będzie podstawowa (Primary), konfigurujemy regułę replikacji LUN1 na macierzy1 w LUN1R na macierzy2.
Konfiguracja odbywa się w menu „Zdalna replikacja”
Tworzymy regułę. W tym celu musimy wskazać odbiorcę replikacji. Tam również podajemy nazwę połączenia i typ replikacji (synchronizacyjna lub asynchroniczna).
W polu „systemy zdalne” dodajemy naszą macierz dyskową 2. Aby dodać, należy użyć zarządzających adresów IP macierzy dyskowej (MGR) oraz nazwy zdalnego LUN, w którym będziemy przeprowadzać replikację (w naszym przypadku LUN1R). Adresy IP są potrzebne tylko na etapie dodawania połączenia, ruch replikacji nie będzie przez nie przekazywany, do tego zostanie wykorzystany wcześniej skonfigurowany VIP.
Już na tym etapie możemy dodać więcej niż jeden zdalny system do topologii „jeden do wielu”: naciskamy przycisk „dodaj węzeł”, jak na poniższym rysunku.
W naszym przypadku zdalny system jest jeden, więc ograniczamy się do tego.
Reguła gotowa. Zauważ, że dodawana jest automatycznie we wszystkich uczestnikach replikacji (w naszym przypadku jest ich dwóch). Takich reguł można stworzyć dowolną liczbę, dla dowolnej liczby LUN-ów i w obie strony. Na przykład, aby zrównoważyć obciążenie, możemy replikować część LUN-ów z macierzy dyskowej 1 na macierz dyskową 2, a inną część odwrotnie – z macierzy dyskowej 2 na macierz dyskową 1.
Macierz dyskowa 1. Tuż po utworzeniu rozpoczęła się synchronizacja.
Macierz dyskowa 2. Widzimy tę samą regułę, ale synchronizacja już się zakończyła.
LUN1 na macierzy dyskowej 1 pełni rolę Primary, co oznacza, że jest aktywny. LUN1R na macierzy dyskowej 2 pełni rolę Secondary, co oznacza, że jest w trybie gotowości na wypadek awarii macierzy dyskowej 1.
Teraz możemy podłączyć nasz LUN do hosta.
Będziemy robić podłączenie przez iSCSI, chociaż można również przez FC. Konfiguracja mapowania LUN-a iSCSI w replicie praktycznie nie różni się od standardowego scenariusza, dlatego szczegółowo tego nie omówimy. W razie czego, ten proces został opisany w artykule „».
Jedyną różnicą jest to, że mapowanie tworzymy w menu „Mapowanie replikacji”
Skonfigurowaliśmy mapowanie, przekazaliśmy LUN hostowi. Hosta zobaczył LUN.
Formatujemy go w lokalny system plików.
Wszystko, w tym miejscu konfiguracja jest zakończona. Następnie przeprowadzimy testy.
Testowanie
Będziemy testować trzy główne scenariusze.
- Standardowe przełączanie ról z Secondary > Primary. Standardowe przełączanie ról jest potrzebne na wypadek, jeśli na przykład w głównym centrum danych musimy przeprowadzić jakieś prace konserwacyjne, a w tym czasie, aby dane były dostępne, przenosimy obciążenie do zapasowego centrum danych.
- Awaryjne przełączenie ról Secondary > Primary (awaria centrum danych). To główny scenariusz, dla którego istnieje replikacja, który może pomóc przetrwać całkowitą awarię centrum danych, nie wstrzymując działalności firmy na dłuższy czas.
- Przerwanie kanałów komunikacyjnych między centrami danych. Sprawdzamy poprawne działanie dwóch systemów storage’owych w warunkach, gdy z jakiegoś powodu kanał komunikacyjny między centrami danych jest niedostępny (na przykład, gdy koparka wykopała w niewłaściwym miejscu i uszkodziła ciemną optykę).
Na początek zaczniemy pisać dane na nasz LUN (piszemy pliki z losowymi danymi). Od razu sprawdzamy, co wykorzystuje kanał komunikacyjny między systemami storage’owymi. To łatwe do zauważenia, otwierając monitorowanie obciążenia portów, które odpowiadają za replikację.
Na obu systemach storage’owych znajdują się teraz „użyteczne” dane, możemy zacząć test.
Na wszelki wypadek sprawdzimy sumy kontrolne jednego z plików i zapiszemy.
Standardowe przełączenie ról
Operację przełączenia ról (zmiany kierunku replikacji) można wykonać z dowolnego systemu storage’owego, ale i tak trzeba będzie przejść na oba, ponieważ na Primary należy wyłączyć mapowanie, a na Secondary (która stanie się Primary) włączyć je.
Możliwe, że teraz pojawia się logiczne pytanie: dlaczego tego nie zautomatyzować? Odpowiadamy: to proste, replikacja to proste narzędzie zapewnienia odporności na awarie, oparte wyłącznie na operacjach ręcznych. Dla automatyzacji tych operacji istnieje tryb metroklastra, który jest całkowicie zautomatyzowany, ale jego konfiguracja jest znacznie bardziej skomplikowana. O konfiguracji metroklastra napiszemy w następnej artykule.
Na głównym systemie storage’owym wyłączamy mapowanie, aby gwarantować zatrzymanie zapisu.
Następnie na jednym z systemów storage’owych (nie ma znaczenia, czy na głównym czy rezerwowym) w menu „Zdalna replikacja” wybieramy nasze połączenie REPL1 i klikamy „Zmień rolę”.
Po kilku sekundach LUN1R (rezerwowy system storage’owy) staje się Primary.
Robimy mapowanie LUN1R z systemem storage’owym 2.
Po tym nasz dysk E: automatycznie łączy się z hostem, tylko tym razem „przyleciał” z LUN1R.
Na wszelki wypadek porównujemy sumy kontrolne.
Identycznie. Test zaliczony.
Awaryjne przełączenie. Awaria centrum danych
W tej chwili głównym systemem storage’owym po standardowym przełączeniu jest system storage’owy 2 oraz LUN1R, odpowiednio. Aby zasymulować awarię, wyłączamy zasilanie na obu kontrolerach systemu storage’owego 2.
Dostęp do niej jest już niemożliwy.
Sprawdzamy, co dzieje się w SCD 1 (obecnie zapasowym).
Widzimy, że Primary LUN (LUN1R) jest niedostępny. W logach, na panelu informacyjnym oraz w regule replikacji pojawił się komunikat o błędzie. W związku z tym dane z hosta są teraz niedostępne.
Zmiana roli LUN1 na Primary.
Tworzymy mapowanie do hosta.
Upewniamy się, że dysk E pojawił się na hoście.
Sprawdzamy hasz.
Wszystko w porządku. Awaria centrum danych, które było aktywne, SCD przetrwała pomyślnie. Szacunkowy czas, jaki spędziliśmy na podłączeniu „przełączenia” replikacji i połączeniu LUN-a z zapasowego centrum danych wynosił około 3 minut. Oczywiście w realnej produkcji wszystko jest znacznie bardziej skomplikowane i poza działaniami związanymi z SCD należy wykonać wiele innych operacji w sieci, na hostach, w aplikacjach. W rzeczywistości ten czas będzie znacznie dłuższy.
Chciałoby się napisać, że wszystko, test zakończony pomyślnie, ale nie spieszmy się. Główne SCD „leży”, wiemy, że gdy „upadło”, było w roli Primary. Co się stanie, jeśli nagle się włączy? Będą dwie role Primary, co oznacza uszkodzenie danych? Sprawdzimy to teraz.
Idziemy nagle włączyć leżące SCD.
Uruchamia się przez kilka minut i po krótkiej synchronizacji wraca do działania, ale już w roli Secondary.
Wszystko w porządku. Nie wystąpił split-brain. Pomyśleliśmy o tym i zawsze po awarii SCD włącza się w roli Secondary, niezależnie od tego, w jakiej roli była „za życia”. Teraz można z całą pewnością stwierdzić, że test awarii centrum danych przeszedł pomyślnie.
Awaria połączeń między centrami danych
Główne zadanie tego testu to upewnienie się, że SCD nie zacznie się dziwnie zachowywać, jeśli tymczasowo znikną połączenia między dwoma SCD, a następnie pojawią się ponownie.
Zatem. Odłączamy kable między SCD (wyobraźmy sobie, że wykopał je koparka).
Na Primary widzimy, że brak połączenia z Secondary.
Na Secondary widzimy, że brak połączenia z Primary.
Wszystko działa normalnie, a my dalej zapisujemy dane na głównym SCD, to znaczy, że już się różnią od zapasowego, to znaczy „rozjechały się”.
Po kilku minutach „naprawiamy” połączenie. Gdy tylko SCD się zobaczą, automatycznie włącza się synchronizacja danych. Po stronie administratora nic nie jest wymagane.
Po pewnym czasie synchronizacja kończy się.
Połączenie zostało przywrócone, żadne nietypowe sytuacje nie spowodowały zerwania łączności, a po włączeniu automatycznie nastąpiła synchronizacja.
Wnioski
Omówiliśmy teorię – co i dlaczego jest potrzebne, gdzie znajdują się zalety, a gdzie wady. Następnie skonfigurowaliśmy synchronizację replik między dwoma macierzy dyskowymi.
Dalej przeprowadzono główne testy na normalne przełączanie, awarię centrum danych i zerwanie łączności. W każdym przypadku macierz dyskowa działała poprawnie. Brak utraty danych, operacje administracyjne zostały ograniczone do minimum w scenariuszu ręcznym.
Następnym razem skomplikujemy sytuację i pokażemy, jak cała ta logika działa w zautomatyzowanym metrokleście w trybie active-active, tzn. kiedy obie macierze dyskowe są główne, a zachowania podczas awarii są w pełni zautomatyzowane.
Prosimy o pisanie komentarzy, będziemy wdzięczni za konstruktywną krytykę i mądre rady.
Do zobaczenia.
Źródło: habr.com
