Środowiska hybrydowe, w których część infrastruktury bazodanowej jest zlokalizowana lokalnie, a część w chmurze publicznej, nie są rzadkością. Mogą istnieć różne powody korzystania z takiej konfiguracji – skalowalność, elastyczność, wysoka dostępność, odtwarzanie po awarii. Jak poprawnie zaimplementować tę konfigurację? Może to być trudne, ponieważ musisz rozważyć kilka elementów układanki, które muszą do siebie pasować. Ten blog ma na celu dać ci wgląd w to, jak taka konfiguracja może wyglądać.
Łączność
Nie będziemy tutaj wchodzić w szczegóły, ponieważ istnieje wiele sposobów na skonfigurowanie łączności między konfiguracją lokalną a chmurą publiczną. Będzie to zależeć od posiadanej infrastruktury, chmury publicznej, z której chcesz korzystać i wielu innych czynników. Zakres opcji może zacząć się od routerów obsługujących BGP, poprzez sprzętowy VPN, oprogramowanie VPN kończąc na tunelach SSH jako sposób na tymczasowe połączenie sieci z instancjami w chmurze publicznej. Co ważne, cokolwiek zamierzasz zrobić, ostatecznym wynikiem powinna być pełna i przejrzysta łączność z sieci lokalnej do instancji znajdujących się w chmurze publicznej.
Uwagi dotyczące wysokiej dostępności
Replikacja MySQL to świetny sposób na budowanie systemów o wysokiej dostępności, ale wiąże się ze znacznymi ograniczeniami. Najważniejszą rzeczą do rozważenia jest pisarz - możesz mieć tylko jedno miejsce, do którego możesz wysłać swoje teksty - mistrz. Bez względu na to, jak chcesz zaprojektować całe otoczenie, musisz dokładnie przemyśleć umiejscowienie mistrza. Najprawdopodobniej chcesz, aby była częścią środowiska, które zawiera hosty aplikacji. Rozważmy następującą konfigurację:
Mamy konfigurację lokalną z trzema węzłami MySQL i dwoma dodatkowymi urządzeniami podrzędnymi znajduje się w chmurze publicznej, pełniąc dla firmy funkcję odzyskiwania po awarii, jest całkiem jasne, że zapisywalny węzeł powinien być ulokowany z hostami aplikacji w prywatnej części chmury. Chcemy, aby opóźnienie było jak najmniejsze dla połączeń, które mają największe znaczenie.
Ten rodzaj projektowania skupia się na dostępności baz danych - jeśli węzły zlokalizowane w prem nie będą dostępne, hosty aplikacji mogą być w stanie połączyć się ze zdalną częścią instalacji - węzły bazy danych zlokalizowane w chmurze publicznej. Najlepiej byłoby użyć do tego jakiegoś serwera proxy — ProxySQL jest jednym z rozwiązań, które może śledzić topologię i w razie potrzeby zmieniać konfigurację w oparciu o istniejący łańcuch replikacji.
Jeśli chcesz rozważyć bardziej konfigurację aktywny-aktywny, w której masz węzły aplikacji zarówno prywatne, jak i publiczne, musisz dokonać pewnych kompromisów, ponieważ zapisy będą musiały zostać przesłane przez WAN, z chmury publicznej do chmury prywatnej (lub odwrotnie, jeśli Twoja główna lokalizacja, w której działasz w chmurze publicznej).
Ponownie ProxySQL jest preferowanym serwerem proxy. Co jest świetne, ProxySQL można skonfigurować jako klaster ProxySQL, zapewniając, że zmiany konfiguracji wprowadzone w jednym węźle będą replikowane w pozostałych węzłach ProxySQL.
Obsługa awarii
Rozważmy kilka scenariuszy niepowodzeń. Przede wszystkim musimy pamiętać, że asynchroniczna replikacja MySQL nie obsługuje klastrów, dlatego podział sieci jest czymś, co należy obsługiwać ręcznie - decyzja i przełączenie przełącznika w celu promowania jednego z nich będzie należało do użytkownika. niewolnicy w dostępnym środowisku. Od użytkownika zależy również, czy środowisko, które utraciło łączność sieciową, będzie zachowywać się tak, jak powinno i nie będzie dalej działać.
Jeśli prywatna część chmury stanie się niedostępna, jak wspomnieliśmy wcześniej, konieczne będzie ręczne działanie, aby awansować jednego z niewolników na nowego głównego. Wtedy wszystkie pozostałe serwery aplikacji webowych znajdujące się w chmurze publicznej, korzystające z lokalnego ProxySQL, będą miały swój ruch przekierowany do nowego mastera i wszystkich pozostałych slave'ów. Z drugiej strony, biorąc pod uwagę, że straciliśmy trzy z pięciu węzłów MySQL, chcemy przeskalować konfigurację chmury publicznej – ClusterControl może pomóc w efektywnym dodawaniu dodatkowych węzłów do klastra.
Innym scenariuszem może być awaria nagrywarki, podczas gdy łączność między naszą lokalną konfiguracją a chmurą publiczną działa bez zarzutu.
W takim scenariuszu chcemy awansować jednego z niewolników na nowego pana. W zależności od wymagań możemy również chcieć, aby nowy master był promowany między węzłami w danej części środowiska. ClusterControl ma możliwość umieszczania na białej lub czarnej liście węzłów do przełączenia awaryjnego, zapewniając pełną kontrolę nad procesem przełączania awaryjnego i możliwość wybrania, które węzły powinny być uważane za kandydatów do nowego mastera i w jakiej kolejności.
Mamy nadzieję, że ten blog dał Ci pewne pojęcie o tym, jak działa konfiguracja chmury hybrydowej dla replikacji MySQL i jak może Cię chronić w przypadku awarii bazy danych lub sieci.
