W Citymobil używamy bazy danych MySQL jako głównego trwałego magazynu danych. Mamy kilka klastrów baz danych dla różnych usług i celów.

Stała dostępność mastera jest krytycznym wskaźnikiem wydajności całego systemu i jego poszczególnych części. Automatyczne odzyskiwanie klastra w przypadku awarii urządzenia głównego znacznie skraca czas reakcji na incydenty i przestoje systemu. W tym artykule przyjrzę się projektowi wysokiej dostępności (HA) dla klastra MySQL opartego na Orkiestrator MySQL i wirtualne adresy IP (VIP).

Rozwiązanie HA oparte na VIP

Na początek krótko opowiem czym jest nasz system przechowywania danych.

Używamy klasycznego schematu replikacji z jednym wzorcem dostępnym do zapisu i wieloma replikami tylko do odczytu. Klaster może zawierać pośredniego wzorca — węzeł, który jest zarówno repliką, jak i wzorcem dla innych. Klienci uzyskują dostęp do replik za pośrednictwem HAProxy, co pozwala na równomierny rozkład obciążenia i łatwe skalowanie. Korzystanie z HAProxy wynika z przyczyn historycznych i obecnie jesteśmy w trakcie migracji do ProxySQL.

Replikacja odbywa się w trybie półsynchronicznym w oparciu o GTID. Oznacza to, że co najmniej jedna replika musi zarejestrować transakcję, zanim zostanie ona uznana za udaną. Ten tryb replikacji zapewnia optymalną równowagę pomiędzy wydajnością i bezpieczeństwem danych w przypadku awarii węzła głównego. Zasadniczo wszystkie zmiany są przenoszone z mastera do replik za pomocą Row Based Replication (RBR), ale niektóre węzły mogą mieć mixed binlog format.

Orchestrator okresowo aktualizuje stan topologii klastra, analizuje otrzymane informacje i w przypadku pojawienia się problemów może uruchomić procedurę automatycznego odzyskiwania. Za samą procedurę odpowiada programista, ponieważ można ją wdrożyć na różne sposoby: w oparciu o VIP, DNS, korzystając z usług wykrywania usług lub samodzielnie napisanych mechanizmów.

Prostym sposobem na przywrócenie mastera w przypadku jego awarii jest użycie pływających adresów VIP.

Co musisz wiedzieć o tym rozwiązaniu, zanim przejdziesz dalej:

• VIP to adres IP, który nie jest powiązany z konkretnym fizycznym interfejsem sieciowym. Jeśli węzeł ulegnie awarii lub podczas zaplanowanej konserwacji, możemy przełączyć VIP na inny zasób przy minimalnym przestoju.
• Zwolnienie i wydanie wirtualnego adresu IP jest operacją tanią i szybką.
• Do pracy z VIP-em potrzebny jest dostęp do serwera poprzez SSH lub użycie specjalnych narzędzi np. keepalived.

Przyjrzyjmy się możliwym problemom z naszym kreatorem i wyobraźmy sobie, jak powinien działać mechanizm automatycznego odzyskiwania.

Zniknęła łączność sieciowa z urządzeniem głównym lub pojawił się problem na poziomie sprzętowym, a serwer jest niedostępny

1. Koordynator aktualizuje topologię klastra, każda replika zgłasza, że ​​jednostka główna jest niedostępna. Orkiestrator rozpoczyna proces wyboru repliki odpowiedniej do roli nowego wzorca i rozpoczyna odzyskiwanie.
2. Próbujemy usunąć VIP-a ze starego mistrza - bez powodzenia.
3. Replika przechodzi w rolę mastera. Topologia jest w trakcie przebudowy.
4. Dodanie nowego interfejsu sieciowego z VIP-em. Ponieważ usunięcie VIP-a nie było możliwe, okresowo zaczynamy wysyłać żądanie w tle bezpłatne ARP. Ten typ żądania/odpowiedzi umożliwia aktualizację tabeli mapowania adresów IP i MAC na podłączonych przełącznikach, powiadamiając w ten sposób o przeniesieniu naszego VIP-a. Minimalizuje to prawdopodobieństwo split brain podczas powrotu starego mistrza.
5. Wszystkie nowe połączenia są natychmiast przekierowywane do nowego mastera. Stare połączenia zawodzą i na poziomie aplikacji nawiązywane są powtarzające się wywołania do bazy danych.

Serwer działa w trybie normalnym, wystąpiła awaria na poziomie DBMS

Algorytm jest podobny do poprzedniego przypadku: aktualizacja topologii i rozpoczęcie procesu odzyskiwania. Ponieważ serwer jest dostępny, pomyślnie zwalniamy VIP-a na starym masterze, przenosimy go na nowy i wysyłamy kilka żądań ARP. Ewentualny powrót starego mastera nie powinien mieć wpływu na odbudowany klaster i działanie aplikacji.

Inne problemy

Awaria replik lub wzorców pośrednich nie prowadzi do działań automatycznych i wymaga ręcznej interwencji.

Wirtualny interfejs sieciowy jest zawsze dodawany tymczasowo, co oznacza, że ​​po ponownym uruchomieniu serwera adres VIP nie jest przypisywany automatycznie. Każda instancja bazy danych domyślnie uruchamia się w trybie tylko do odczytu, a program Orchestrator automatycznie przełącza nowego wzorca do zapisu i próbuje zainstalować read only na starego mistrza. Działania te mają na celu zmniejszenie prawdopodobieństwa split brain.

Podczas procesu odzyskiwania mogą pojawić się problemy, o których należy również powiadomić za pośrednictwem interfejsu użytkownika programu Orchestrator, oprócz standardowych narzędzi monitorowania. Rozszerzyliśmy API REST dodając tę ​​funkcję (PR obecnie w trakcie przeglądu).

Ogólny schemat rozwiązania HA przedstawiono poniżej.

Wybór nowego mistrza

Orkiestrator jest wystarczająco mądry i próbuje wybierać najbardziej odpowiednią replikę jako nowego mistrza według następujących kryteriów:

• replika pozostaje w tyle za wzorcem;
• Wersja MySQL mastera i repliki;
• typ replikacji (RBR, SBR lub mieszany);
• lokalizacja w tym samym lub różnych centrach danych;
• dostępność errant GTID — transakcje, które zostały wykonane na replice, a nie znajdują się na replice;
• brane są pod uwagę również niestandardowe reguły selekcji.

Nie każda wskazówka jest idealnym kandydatem na mistrza. Na przykład replika może służyć do tworzenia kopii zapasowych danych lub serwer ma słabszą konfigurację sprzętową. Orkiestrator obsługuje ręczne reguły, dzięki którym możesz dostosować preferencje dotyczące wyboru kandydatów od najbardziej preferowanych do ignorowanych.

Czas reakcji i odzyskiwania

W przypadku awarii ważne jest, aby zminimalizować czas przestoju systemu, dlatego zastanówmy się nad parametrami MySQL, które wpływają na tworzenie i aktualizację topologii klastra przez orkiestratora:

• slave_net_timeout — liczba sekund, podczas których replika oczekuje na przybycie nowych danych lub sygnału pulsu od urządzenia głównego, zanim połączenie zostanie rozpoznane jako utracone i ponownie nawiązane. Im niższa wartość, tym szybciej replika może stwierdzić, że komunikacja z masterem została zerwana. Ustawiamy tę wartość na 5 sekund.
• MASTER_CONNECT_RETRY — liczba sekund pomiędzy próbami ponownego połączenia. W przypadku problemów z siecią niska wartość tego parametru umożliwi szybkie ponowne połączenie i uniemożliwi rozpoczęcie procesu odzyskiwania klastra. Zalecana wartość to 1 sekunda.
• MASTER_RETRY_COUNT — maksymalna liczba prób ponownego połączenia.
• MASTER_HEARTBEAT_PERIOD — odstęp w sekundach, po którym urządzenie nadrzędne wysyła sygnał pulsu. Domyślnie połowa wartości slave_net_timeout.

Parametry Orchestratora:

• DelayMasterPromotionIfSQLThreadNotUpToDate - jeśli równe true, rola główna nie zostanie zastosowana do repliki kandydującej, dopóki wątek SQL repliki nie zakończy wszystkich niezastosowanych transakcji z dziennika przekazywania. Korzystamy z tej opcji, aby uniknąć utraty transakcji, gdy wszystkie kandydujące repliki pozostają w tyle.
• InstancePollSeconds — częstotliwość tworzenia i aktualizacji topologii.
• RecoveryPollSeconds — częstotliwość analizy topologii. W przypadku wykrycia problemu inicjowane jest przywracanie topologii. Ten stałyrówny 1 sekundzie.

Każdy węzeł klastra jest odpytywany przez koordynatora raz na jakiś czas InstancePollSeconds sekundy Po wykryciu problemu wymuszany jest stan klastra zaktualizowany, a następnie zostaje podjęta ostateczna decyzja o przeprowadzeniu odzyskiwania. Eksperymentując z różnymi parametrami bazy danych i programu Orchestrator, udało nam się skrócić czas odpowiedzi i odzyskiwania do 30 sekund.

Stanowisko badawcze

Testowanie schematu HA rozpoczęliśmy od opracowania wersji lokalnej stanowisko testowe i dalsze wdrożenie na środowiskach testowych i produkcyjnych. Stanowisko lokalne jest w pełni zautomatyzowane w oparciu o Docker i pozwala na eksperymentowanie z konfiguracją orkiestratora i sieci, skalowanie klastra od 2-3 serwerów do kilkudziesięciu oraz prowadzenie ćwiczeń w bezpiecznym środowisku.

Podczas ćwiczeń wybieramy jeden z problematycznych sposobów emulacji: natychmiastowo strzelamy do mistrza za pomocą kill -9, delikatnie zakończ proces i zatrzymaj serwer (docker-compose stop), symuluj problemy z siecią za pomocą iptables -j REJECT lub iptables -j DROP. Oczekujemy następujących wyników:

• orkiestrator wykryje problemy z masterem i zaktualizuje topologię w nie więcej niż 10 sekund;
• procedura odzyskiwania rozpocznie się automatycznie: zmieni się konfiguracja sieci, rola mastera przejdzie na replikę, topologia zostanie odbudowana;
• nowy master będzie możliwy do zapisu, aktywne repliki nie zostaną utracone podczas procesu odbudowy;
• dane zaczną być zapisywane na nowym urządzeniu głównym i replikowane;
• Całkowity czas odzyskiwania nie będzie dłuższy niż 30 sekund.

Jak wiadomo, system może zachowywać się inaczej w środowisku testowym i produkcyjnym ze względu na odmienną konfigurację sprzętu i sieci, różnice w obciążeniu syntetycznym i rzeczywistym itp. Dlatego okresowo przeprowadzamy ćwiczenia w warunkach rzeczywistych, sprawdzając, jak zachowuje się system w przypadku utraty łączności sieciowej lub degradacji poszczególnych jego elementów. W przyszłości chcemy zbudować całkowicie identyczną infrastrukturę dla obu środowisk i zautomatyzować jej testowanie.

odkrycia

Kondycja głównego węzła systemu pamięci masowej jest jednym z głównych zadań SRE i zespołu operacyjnego. Wdrożenie rozwiązania Orchestrator i HA opartego o VIP pozwoliło nam osiągnąć następujące rezultaty:

• niezawodne wykrywanie problemów z topologią klastra baz danych;
• automatyczna i szybka reakcja na incydenty związane z masterem, redukująca przestoje systemu.

Rozwiązanie to ma jednak swoje ograniczenia i wady:

• skalowanie schematu HA do kilku centrów danych będzie wymagało jednej sieci L2 pomiędzy nimi;
• Przed przypisaniem VIP-a do nowego mastera musimy go zwolnić na starym. Proces jest sekwencyjny, co wydłuża czas regeneracji;
• zwolnienie VIP-a wymaga dostępu SSH do serwera lub dowolnej innej metody wywoływania zdalnych procedur. Ponieważ na serwerze lub bazie danych występują problemy, które spowodowały proces odzyskiwania, nie możemy być pewni, że usunięcie VIP-a zakończy się pomyślnie. A to może prowadzić do pojawienia się dwóch serwerów z tym samym wirtualnym adresem IP i problemu split brain.

Unikać split brain, możesz skorzystać z tej metody STONIT („Strzelaj drugiemu węzłowi w głowę”), co całkowicie izoluje lub wyłącza problematyczny węzeł. Istnieją inne sposoby wdrożenia wysokiej dostępności klastra: połączenie VIP i DNS, usługi wykrywania usług i usług proxy, replikacja synchroniczna i inne metody, które mają swoje wady i zalety.

Mówiłem o naszym podejściu do tworzenia klastra pracy awaryjnej MySQL. Jest łatwy do wdrożenia i zapewnia akceptowalny poziom niezawodności w obecnych warunkach. W miarę rozwoju całego systemu, a zwłaszcza infrastruktury, podejście to niewątpliwie będzie ewoluować.

Źródło: www.habr.com