W SitiMobil używamy bazy danych MySQL jako głównego magazynu danych trwałych. Posiadamy kilka klastrów baz danych do różnych usług i celów.

Ciągła dostępność głównego węzła jest krytycznym wskaźnikiem wydajności całego systemu i jego poszczególnych części. Automatyczne przywracanie klastra w przypadku awarii głównego węzła znacznie skraca czas reakcji na incydent oraz czas przestojów systemu. W tym artykule omówię schemat zapewnienia wysokiej dostępności (HA) klastra MySQL oparty na MySQL Orchestrator i wirtualnych adresach IP (VIP).

Rozwiązanie HA oparte na VIP

Najpierw krótko opowiem o tym, czym jest nasz system przechowywania danych.

Używamy klasycznego schematu replikacji z jednym głównym, dostępnym do zapisu, i wieloma replikami, które są używane tylko do odczytu. Klaster może zawierać pośredniego głównego — węzeł, który jednocześnie jest repliką i głównym dla innych. Klienci łączą się z replikami przez HAProxy, co pozwala na równomierne rozłożenie obciążenia i łatwe skalowanie. Użycie HAProxy ma swoje historyczne uzasadnienie i obecnie jesteśmy w trakcie migracji na ProxySQL.

Replikacja odbywa się w trybie półsynchronicznym w oparciu o GTID. Oznacza to, że co najmniej jedna replika musi zapisać transakcję w dzienniku, zanim zostanie uznana za udaną. Taki tryb replikacji zapewnia optymalną równowagę między wydajnością a integralnością danych w przypadku awarii węzła głównego. Główne zmiany przekazywane są z głównego węzła do replik za pomocą Row Based Replication (RBR), jednak niektóre węzły mogą mieć mixed binlog format.

Orkiestrator okresowo aktualizuje stan topologii klastra, analizuje uzyskane informacje i w przypadku wystąpienia problemów może uruchomić procedurę automatycznego przywracania. Za samą procedurę odpowiada programista, ponieważ można ją wdrożyć na różne sposoby: na podstawie VIP, DNS, z użyciem usług wykrywania serwisów (service discovery) lub własnych mechanizmów.

Jednym z prostych sposobów przywracania głównego węzła w przypadku jego awarii jest użycie pływających adresów VIP.

Co trzeba wiedzieć o tym rozwiązaniu, zanim przejdziemy dalej:

VIP to adres IP, który nie jest przypisany do konkretnego fizycznego interfejsu sieciowego. W przypadku awarii węzła lub podczas prac konserwacyjnych możemy przełączyć VIP na inne zasoby w minimalnym czasie przestoju.
Zwolenie i przyznawanie wirtualnego adresu IP to tanie i szybkie operacje.
Aby pracować z VIP, wymagany jest dostęp do serwera przez SSH lub wykorzystanie specjalnych narzędzi, takich jak keepalived.

Przeanalizujmy możliwe problemy z naszym mistrzem i przedstawmy, jak powinien działać mechanizm automatycznego przywracania.

Utracono łączność sieciową z mistrzem lub pojawił się problem na poziomie 'sprzętu', a serwer jest niedostępny.

Orkiestrator aktualizuje topologię klastra, każda replika informuje o niedostępności mistrza. Orkiestrator uruchamia proces wyboru repliki, która może pełnić rolę nowego mistrza, i rozpoczyna przywracanie.
Próbujemy usunąć VIP ze starego mistrza — bezskutecznie.
Replika przełącza się w rolę mistrza. Topologia zostaje przekształcona.
Dodajemy nowy interfejs sieciowy z VIP. Ponieważ nie udało się usunąć VIP, w tle uruchamiamy okresowe wysyłanie zapytania gratuitous ARP. Ten typ zapytania/odpowiedzi pozwala zaktualizować na podłączonych przełącznikach tabelę przyporządkowania adresów IP do MAC, informując tym samym o przeprowadzce naszego VIP. Minimalizuje to ryzyko split brain w przypadku powrotu starego mistrza.
Wszystkie nowe połączenia natychmiast kierowane są do nowego mistrza. Stare połączenia kończą się niepowodzeniem, następują ponowne próby na poziomie aplikacji.

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

Algorytm jest podobny do poprzedniego przypadku: aktualizacja topologii i uruchomienie procesu przywracania. Ponieważ serwer jest dostępny, skutecznie zwalniamy VIP na starym mistrzu, przenosimy go na nowy i wysyłamy kilka zapytań ARP. Potencjalny powrót starego mistrza nie powinien mieć wpływu na przekształcony klaster i działanie aplikacji.

Inne problemy

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

Wirtualny interfejs sieciowy jest zawsze dodawany tymczasowo, to znaczy po ponownym uruchomieniu serwera VIP nie jest automatycznie przydzielany. Każdy egzemplarz bazy danych domyślnie działa w trybie tylko do odczytu, a orkiestrator automatycznie przełącza nowego mastera na zapis i stara się ustawić tylko do odczytu na starym masterze. Działania te mają na celu zmniejszenie prawdopodobieństwa split brain.

W procesie przywracania mogą wystąpić problemy, o których również warto informować przez UI orkiestratora oprócz standardowych środków monitorujących. Rozszerzyliśmy REST API, dodając taką możliwość (PR jest aktualnie rozważane).

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

Wybór nowego mastera

Orkiestrator jest wystarczająco inteligentny i stara się wybrać najbardziej odpowiednią replikę jako nowego mastera według następujących kryteriów:

opóźnienie repliki w stosunku do mastera;
wersja MySQL mastera i repliki;
typ replikacji (RBR, SBR lub mixed);
lokalizacja w jednym lub różnych centrach danych;
obecność errant GTID — transakcje, które zostały wykonane na replikach i brakują na masterze;
także brane są pod uwagę zasady wyboru użytkownika.

Nie każda replika jest idealnym kandydatem na rolę mastera. Na przykład, replika może być używana do tworzenia kopii zapasowych danych lub serwer może mieć słabszą konfigurację „sprzętu”. Orkiestrator wspiera ręczne zasady, za pomocą których można dostosować swoje preferencje dotyczące wyboru kandydata od najbardziej preferowanych do ignorowanych.

Czas reakcji i przywracania

W przypadku incydentu ważne jest, aby zminimalizować czas przestoju systemu, dlatego rozważymy parametry MySQL, które wpływają na budowanie i aktualizację topologii klastra przez orkiestratora:

slave_net_timeout — liczba sekund, w ciągu których replika oczekuje na nowe dane lub sygnał heartbeat od mastera, zanim połączenie zostanie uznane za utracone i nastąpi ponowne połączenie. Im mniejsza wartość, tym szybciej replika może określić, że połączenie z masterem zostało przerwane. Ustalamy 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 zapobiegnie uruchomieniu procesu przywracania klastra. Zalecana wartość to 1 sekunda.
MASTER_RETRY_COUNT — maksymalna liczba prób ponownego połączenia.
MASTER_HEARTBEAT_PERIOD — interwał w sekundach, po którym mistrz wysyła sygnał heartbeat. Domyślnie wynosi połowę wartości slave_net_timeout.

Parametry orkiestratora:

DelayMasterPromotionIfSQLThreadNotUpToDate — jeśli jest równy true, to rola mistrza nie zostanie zastosowana na replikacie-kandydacie, dopóki wątek SQL repliki nie wykona wszystkich niewykonanych transakcji z Relay Log. Używamy tej opcji, aby nie utracić transakcji w warunkach opóźnienia wszystkich replik-kandydatów.
InstancePollSeconds — częstotliwość budowania i aktualizowania topologii.
RecoveryPollSeconds — częstotliwość analizy topologii. W przypadku wykrycia problemu uruchamiane jest przywracanie topologii. To stała, równa 1 sekundzie.

Każdy węzeł klastra jest sprawdzany przez orkiestratora raz na InstancePollSeconds sekund. Po wykryciu problemu stan klastra jest przymusowo aktualizowany, a następnie podejmowana jest ostateczna decyzja o przeprowadzeniu przywracania. Eksperymentując z różnymi parametrami Bazy Danych i orkiestratora, udało nam się skrócić czas reakcji i przywracania do 30 sekund.

Stojak testowy

Testowanie schematu HA rozpoczęliśmy od opracowania lokalnego stołu testowego i dalszej implementacji w środowiskach testowych i produkcyjnych. Lokalny stół jest całkowicie zautomatyzowany na bazie Dockera i pozwala na eksperymentowanie z konfiguracją orkiestratora i sieci, skalowanie klastra z 2-3 serwerów do kilkudziesięciu i przeprowadzanie ćwiczeń w bezpiecznym środowisku.

Podczas ćwiczeń wybieramy jedną z metod symulacji problemu: natychmiastowe zabicie mistrza za pomocą kill -9, delikatne zamknięcie procesu i zatrzymanie serwera (docker-compose stop), symulowanie problemów z siecią za pomocą iptables -j REJECT lub iptables -j DROP.Oczekujemy takich wyników:

orkiestrator wykryje problemy z mistrzem i zaktualizuje topologię w mniej niż 10 sekund;
procedura przywracania uruchomi się automatycznie: zmieni się konfiguracja sieciowa, rola mistrza przejdzie do repliki, topologia zostanie przebudowana;
Nowy master będzie dostępny do zapisów, a bieżące repliki nie zostaną utracone podczas przebudowy;
Dane zaczną być zapisywane na nowym masterze i replikowane;
Łączny czas przywracania nie przekroczy 30 sekund.

Jak wiemy, system może działać różnie w środowisku testowym i produkcyjnym z powodu różnej konfiguracji sprzętu oraz sieci, różnic w obciążeniu syntetycznym i rzeczywistym itd. Dlatego okresowo przeprowadzamy ćwiczenia w realnych warunkach, sprawdzając, jak system zachowuje się w przypadku utraty łączności sieciowej lub degradacji jego poszczególnych części. W przyszłości chcemy zbudować całkowicie identyczną infrastrukturę dla obu środowisk i zautomatyzować jej testowanie.

Wnioski

Sprawność głównego węzła systemu przechowywania danych jest jednym z głównych zadań zespołu SRE i operacyjnego. Wdrożenie orkiestratora oraz rozwiązania HA opartego na VIP pozwoliło osiągnąć następujące rezultaty:

Niezawodne wykrywanie problemów z topologią klastra bazy danych;
Automatyczna i szybka reakcja na incydenty związane z masterem, co zmniejsza czas przestojów systemu.

Jednak rozwiązanie ma swoje ograniczenia i wady:

Skalowanie schematu HA na kilka centrów danych wymaga posiadania jednolitej sieci L2 między nimi;
Przed przypisaniem VIP do nowego mastera musimy zwolnić go na starym. Proces jest sekwencyjny, co wydłuża czas przywracania;
Zwolnienie VIP wymaga dostępu SSH do serwera lub innego sposobu wywołania zdalnych procedur. Ponieważ serwer lub baza danych napotyka problemy prowadzące do procesu przywracania, nie możemy być pewni, że zwolnienie VIP zakończy się powodzeniem. Może to prowadzić do powstania dwóch serwerów z tym samym wirtualnym adresem IP i związanych z tym problemów. split brain.

Aby uniknąć split brain, można zastosować metodę STONITH ('Shoot The Other Node In The Head'), która całkowicie izoluje lub wyłącza problemowy węzeł. Istnieją także inne sposoby wdrażania wysokiej dostępności klastra: kombinacja VIP i DNS, wykrywanie usług i serwisy proxy, synchronizowana replikacja oraz inne metody, które mają swoje wady i zalety.

Opowiedziałem o naszym podejściu do tworzenia odpornego klastra MySQL. Jest ono proste w realizacji i zapewnia akceptowalny poziom niezawodności w obecnych warunkach. W miarę rozwoju całego systemu oraz infrastruktury, to podejście z pewnością będzie ewoluować.

Źródło: habr.com