Architektura wysoce dostępnego MySQL z automatycznym przełączaniem awaryjnym w fizycznie zróżnicowanych lokalizacjach

Badałem rozwiązania wysokiej dostępności (HA) dla MySQL między centrami danych.

W przypadku serwerów znajdujących się w tym samym środowisku fizycznym wolałem dual master z pulsem (pływający VIP), stosując aktywne pasywne podejście. Bicie serca dotyczy zarówno połączenia szeregowego, jak i połączenia Ethernet.

Ostatecznie moim celem jest utrzymanie tego samego poziomu dostępności, ale między centrami danych. Chcę dynamicznie przełączać awaryjnie między dwoma centrami danych bez ręcznej interwencji i nadal zachować integralność danych.

Na górze będzie BGP. Klastry internetowe w obu lokalizacjach, które mogłyby potencjalnie prowadzić do baz danych między obiema stronami. Jeśli połączenie internetowe zostanie przerwane w witrynie 1, klienci przekierowują stronę 2 do klastra internetowego, a następnie do bazy danych w witrynie 1, jeśli połączenie między tymi witrynami będzie nadal aktywne.

W tym scenariuszu, z powodu braku fizycznego połączenia (szeregowego), istnieje większe prawdopodobieństwo podzielenia mózgu. Gdyby sieć WAN uległa awarii między obiema stronami, VIP znalazłby się na obu stronach, gdzie różne nieprzyjemne scenariusze mogłyby wprowadzić desynchronizację.

Innym potencjalnym problemem, jaki widzę, jest trudność skalowania tej infrastruktury do trzeciego centrum danych w przyszłości.

Warstwa sieciowa nie jest skupiona. Na tym etapie architektura jest elastyczna. Ponownie, moim celem jest rozwiązanie do zachowania integralności danych, a także automatycznego przełączania awaryjnego z bazami danych MySQL. Prawdopodobnie zaprojektowałbym resztę wokół tego.

Czy możesz polecić sprawdzone rozwiązanie dla MySQL HA między dwoma fizycznie zróżnicowanymi witrynami?

Dziękujemy za poświęcenie czasu na przeczytanie tego. Z niecierpliwością czekam na twoje rekomendacje.

Staniesz przed problemem twierdzenia „CAP”. Nie można jednocześnie mieć spójności, dostępności i tolerancji partycji.

DRBD / MySQL HA polega na synchronicznej replikacji na poziomie urządzenia blokowego. Jest to w porządku, gdy oba węzły są dostępne lub jeśli ktoś cierpi na tymczasową usterkę, zostanie ponownie uruchomiony itp., A następnie wróci. Problemy zaczynają się po otrzymaniu partycji sieciowej.

Partycje sieciowe są bardzo prawdopodobne, jeśli pracujesz w dwóch centrach danych. Zasadniczo żadna ze stron nie może odróżnić partycji od awarii drugiego węzła. Drugi węzeł nie wie, czy powinien przejąć (podstawowy zawiódł), czy nie (łącze zniknęło).

Podczas gdy twoje maszyny znajdują się w tej samej lokalizacji, możesz dodać dodatkowy kanał komunikacji (zwykle kabel szeregowy lub ethernet crossover), aby obejść ten problem - więc ten drugi wie, kiedy podstawowy jest naprawdę WYŁĄCZONY i nie jest to partycja sieciowa .

Kolejnym problemem jest wydajność. Chociaż DRBD może zapewnić przyzwoitą ** wydajność, gdy twoje komputery mają połączenie o niskim opóźnieniu (np. Gigabit Ethernet - ale niektóre osoby używają dedykowanych szybkich sieci), im więcej opóźnień ma sieć, tym dłużej trwa transakcja *** . Jest tak, ponieważ musi poczekać, aż serwer pomocniczy (gdy będzie w trybie online), aby potwierdzić wszystkie zapisy, zanim powie aplikacji „OK”, aby zapewnić trwałość zapisów.

Jeśli robisz to w różnych centrach danych, zwykle masz kilka kolejnych milisekund opóźnienia, nawet jeśli są one w pobliżu.

** Nadal znacznie wolniej niż przyzwoity lokalny kontroler IO

*** Nie można używać MyISAM do systemu DRBD o wysokiej dostępności, ponieważ nie odzyskuje on prawidłowo / automatycznie po nieczystym zamknięciu, które jest wymagane podczas przełączania awaryjnego.

Co powiesz na użycie sieci VLAN do powiązania wszystkich serwerów w dwóch (lub więcej) centrach danych. Następnie możesz użyć CARP do automatycznego przełączania awaryjnego. Użyj replikacji bazy danych, aby wszystko zsynchronizować.

Jeśli jesteś właścicielem centrów danych, możesz upewnić się, że każde centrum danych ma wiele łączy w górę WAN.

Pierwszym etapem powinno być uaktualnienie obecnego rozwiązania HA do takiego, które korzysta z OpenAIS jako warstwy członkostwa w klastrze: zapewni to dużą elastyczność, a biorąc pod uwagę łącza o niskim opóźnieniu między witrynami, może być w stanie się z nimi skontaktować. Obsługują to PaceMaker i RHEL Clustering.

Do automatycznego przełączania awaryjnego centrum danych naprawdę potrzebna jest trzecia lokacja, która będzie działać jako remis, w przeciwnym razie witryny nie będą w stanie odróżnić problemów z routingiem między lokalizacjami od awarii zdalnej witryny. Microsoft ma zaskakująco dobre publikacje internetowe obejmujące ten obszar:

Klastrowanie wielu witryn w systemie Windows Server 2008

Oczywiście dokładna technologia nie jest mapowana na domenę Linux, ale pojęcia są takie same.

Przepraszam, że to kolejna sieć, ale myśl na przyszłość ...

W scenariuszu podzielonego mózgu, o którym wspomniałeś, możesz mieć zbędne linki między dwiema stronami, aby zmniejszyć ryzyko takiego zdarzenia.

Zauważ, że prawdopodobnie nie możesz użyć BGP, ponieważ najmniejszym blokowalnym routerem jest 4k, a / 22, powodzenia zdobywając jeden. Prawdopodobnie potrzebne jest rozwiązanie oparte na DNS.

Udzielenie prawidłowej odpowiedzi może być trudne w zależności od ilości posiadanych danych, liczby serwerów, w których chcesz to zmieścić itp. To powiedziawszy, moja odpowiedź może nie być jedna lub przynajmniej ta, której szukasz.

Nie ma sprawdzonego rozwiązania dla wielu witryn z MySQL. Ale istnieje rozwiązanie, które działa. Jak niektórzy zauważyli, tak DRDB działa dobrze, ale ma swój limit lub możliwy problem w zależności od konfiguracji.

Czy kiedykolwiek będziesz potrzebować trzeciej witryny (innego centrum danych)? Jeśli tak, ile czasu i pieniędzy będziesz musiał to zrobić?

Biorąc pod uwagę za każdym razem, gdy dodajesz serwer master / slave / dns, kopie zapasowe, ... dodajesz siebie do zarządzania, jaka jest twoja zdolność zarządzania pod względem liczby serwerów? Jeśli potrafisz zdefiniować ten numer, być może będziesz musiał odrzucić kilka możliwych rozwiązań i pracować nad tymi, które będą pasować do twoich liczb, aby zarządzanie nie stało się wąskim gardłem.

Biorąc pod uwagę, że centra danych nie ulegają częstym awariom, wiele witryn oznacza równoważenie obciążenia i hakowanie DNS, czy będzie to miało miejsce w tym samym centrum danych? Jeśli tak, jeśli jedno centrum danych ulegnie awarii z jakiegokolwiek powodu, wystąpią problemy, ponieważ znaczna część Twojego DNS i równoważenia obciążenia będzie w tym centrum danych.

Być może będziesz musiał zaplanować tę podzieloną sytuację mózgu. W przypadku każdej możliwej konfiguracji dla jałmużny sposób rozwiązania sytuacji w mózgu plwociny jest inny. Ponadto każde rozwiązanie zajmuje X czasu.
Od samego początku może być znacznie łatwiej zaplanować korzystanie z 3 centrum danych. Nie jestem ekspertem od MySQL, ale słyszałem, że w produkcji łatwiej było mieć 3 Mastery niż 2, jeśli kiedykolwiek pojawią się problemy.

Jedną rzeczą, która może ci pomóc, jest usługa równoważenia obciążenia oferowana przez niektórych dostawców sieci, takich jak Zeus, spójrz tutaj. Prawdopodobnie jest o wiele więcej takich usług. Jestem pewien, że ma swoją cenę, ale czasem pozwala ci ograniczyć inne rzeczy.

Powodzenia!

DRBD nie jest zalecanym rozwiązaniem dla zdalnych centrów danych, ponieważ wymaga przepustowości, która może wpłynąć na szybkość bazy danych i replikacji. Zalecanym rozwiązaniem jest Master - Master Replication. Jedynym problemem jest to, że pola automatycznego przyrostu muszą być rozłożone.

Jeśli potrzebujesz prawdziwie HA rozwiązania dla MySQL, musisz skorzystać z MySQL Cluster, ponieważ DRBD nie może zapewnić integralności danych w przypadku awarii.

Znalazłem posty na blogu o opcjach dostępnych w MySQL oraz jego zaletach i wadach. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

Przezwyciężenie braku kabla szeregowego jest naprawdę bardzo proste, używasz czegoś z czasów ciemnych zwanego modemem - masz jeden na każdym końcu, a następnie uruchamiasz Heartbeat przez łącze PPP. Możesz także użyć przekaźnika ramki. Obie metody rozwiążą wszelkie obawy związane z redundantnymi ścieżkami warstwy 1/2.

Jednak powiedziano to - DRBD działające na dowolnym łączu z opóźnieniem znacznie większym niż około 300µs (zauważ, że 0,3ms) bardzo szybko staje się śmieszne.

Lepiej byłoby skorzystać ze standardowej replikacji MySQL, a LinuxHA zamiast PPP i eth do przełączania awaryjnego.

Przynajmniej tak robiłem dla klientów w przeszłości.