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

19

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.

Warner
źródło
1
Cześć - czy ustaliłeś już podejście? Byłoby interesujące usłyszeć, co postanowiłeś zrobić. Mamy ten sam problem.
Martin
Doceniam wszystkie odpowiedzi i czas każdego. Niestety, żadna z tych odpowiedzi nie odnosi się do sedna pytania, czyli w jaki sposób ludzie z powodzeniem rozwiązali to pytanie w środowisku produkcyjnym. Kiedy dojdę do konkluzji, z pewnością podzielę się moimi końcowymi przemyśleniami. Jak dotąd wydaje się to być poważnym ograniczeniem możliwości skalowania MySQL.
Warner
Może nie otrzymujesz rozwiązania zapisu, ponieważ zadajesz złe pytanie? Jakie dane musisz powielić i dlaczego? Kiedy zaczniesz zadawać te pytania, będziesz w stanie dowiedzieć się, dlaczego potrzebujesz replikacji. Rozszczepiony mózg to nie tylko problem mysql, to koncepcja klastra.
The Unix Janitor
Odpowiedź, którą tu podałem, zawiera dodatkowe informacje: serverfault.com/questions/142683 / ... Zapewnię również dalsze działania, gdy ostateczna implementacja produkcyjna będzie na miejscu.
Warner

Odpowiedzi:

9

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.

MarkR
źródło
Doceniam twój czas i przemyślenia. Bardzo dobrze opisałeś niektóre problemy, których staram się uniknąć. Idealnie, chciałbym zachować zalety aktywnego / pasywnego podwójnego wzorca dla konserwacji i szybkiego przełączania awaryjnego, minimalizując jednocześnie ryzyko uszkodzenia danych. Myślę, że ktoś tam znalazł odpowiednie rozwiązanie.
Warner
1
W rzeczy samej. Dane nie chcą być jednocześnie dwoma miejscami.
Matt Simmons,
3

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.

Matt
źródło
To była moja pierwsza myśl. Wprowadzenie warstwy 2 w takim stopniu wymagałoby podejścia odgórnego między obiema stronami. Inne role serwerów, które mają nadmiarowość przy użyciu LinuxHA, musiałyby mieć podobne implementacje, takie jak zapory ogniowe. W przeciwnym razie wystąpiłyby problemy z routingiem. Ostatecznie, nawet przy wielu łączach w górę WAN między obiema stronami, mój poziom komfortu jest znacznie niższy niż w przypadku łączy szeregowych i ethernetowych. To większe ryzyko, niż mogę tolerować. Ponadto wydaje się, że powinno istnieć bardziej idealne rozwiązanie.
Warner
3

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.

Jaskółka oknówka
źródło
1

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.

Kyle Brandt
źródło
Chodziłem tam iz powrotem. Po pierwsze, odpisałem to całkowicie jako zbyt ryzykowne. Teraz zastanawiam się. Realistycznie ryzyko uszkodzenia danych przy nawet dwóch całkowicie zróżnicowanych ścieżkach jest dość wysokie. Teraz jest na mojej krótkiej liście.
Warner
0

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.

Ronald Pottol
źródło
+1 za dawkę rzeczywistości. Możesz korzystać z dobrze zarządzanej usługi DNS, takiej jak UltraDNS i jej usługi monitorowania witryny „SiteBacker”, aby uzyskać jak najwięcej.
Martin
1
Mamy już wdrożone BGP. To jest poza zakresem mojego pytania.
Warner
2
Nie, najmniejszym blokowalnym routerem jest / 24. Właściwie nie ... Najmniejszym fizycznie routowalnym blokiem jest / 28, ale prawdopodobnie wszyscy zostaną zignorowani. Najmniejszy prefiks, który zostanie wysłuchany, to / 24.
Tom O'Connor,
0

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!

Embreau
źródło
Dane są względnie małe, zważywszy na wszystko. Kilkaset gigabajtów na potrzeby dyskusji. Prawdopodobnie trzecia strona. Jeśli to konieczne, jestem gotów pójść na kompromis architektury, aby uzyskać lepsze rozwiązanie teraz, i wrócę później na trzecią. „Wąskie gardło w zarządzaniu” lub inne obawy administracyjne nie wchodzą w zakres pytania. Nadwyżka będzie obowiązywać dla wszystkich technologii produkcji. Koncentruje się tutaj na MySQL.
Warner
0

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.

cargom98
źródło
0

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.

Geraint Jones
źródło
Ciekawy pomysł. Wcześniej korzystałem z dial-up jako przełączania awaryjnego na PtP. Chociaż nie sądzę, aby całkowicie wyeliminowałoby to zagadnienie CAP, uważam, że może to być uzupełnienie zmniejszania prawdopodobieństwa wystąpienia podziału mózgu. Trudno jest stworzyć taki sam poziom pewności, jaki tworzy bezpośrednie połączenie fizyczne o długości kilku stóp.
Warner