W poprzednim blogu z tej serii omawialiśmy zalety i wady korzystania z Galera Cluster do tworzenia klastra rozproszonego geograficznie. W tym poście zaprojektujemy klaster rozproszony geograficznie oparty na Galera i pokażemy, jak możesz wdrożyć wszystkie wymagane elementy za pomocą ClusterControl.
Projektowanie rozproszonego geograficznie klastra Galera
Zaczniemy od wyjaśnienia środowiska, które chcemy zbudować. Będziemy korzystać z trzech zdalnych centrów danych, połączonych siecią rozległą (WAN). Każde centrum danych będzie otrzymywać zapisy z lokalnych serwerów aplikacji. Odczyty będą również wyłącznie lokalne. Ma to na celu uniknięcie niepotrzebnego ruchu przechodzącego przez sieć WAN.
W tej konfiguracji łączność jest na miejscu i zabezpieczona, ale nie opiszemy dokładnie, jak można to osiągnąć. Istnieje wiele metod zabezpieczania łączności, począwszy od zastrzeżonych rozwiązań sprzętowych i programowych, poprzez OpenVPN, a skończywszy na tunelach SSH.
Będziemy używać ProxySQL jako loadbalancer. ProxySQL zostanie wdrożony lokalnie w każdym centrum danych. Będzie również kierować ruch tylko do węzłów lokalnych. Zdalne węzły zawsze można dodać ręcznie, a my wyjaśnimy przypadki, w których może to być dobre rozwiązanie. Aplikację można skonfigurować tak, aby łączyła się z jednym z lokalnych węzłów ProxySQL za pomocą algorytmu round-robin. Równie dobrze możemy użyć Keepalived i Virtual IP do kierowania ruchu do pojedynczego węzła ProxySQL, o ile pojedynczy węzeł ProxySQL byłby w stanie obsłużyć cały ruch.
Innym możliwym rozwiązaniem jest kolokacja ProxySQL z węzłami aplikacji i skonfigurowanie aplikacji do łączenia się z proxy na hoście lokalnym. To podejście działa całkiem dobrze przy założeniu, że jest mało prawdopodobne, że ProxySQL nie będzie dostępny, ale aplikacja będzie działać poprawnie na tym samym węźle. Zazwyczaj widzimy albo awarię węzła, albo awarię sieci, która wpłynie jednocześnie na ProxySQL i aplikację.
Powyższy diagram przedstawia wersję środowiska, w którym znajduje się ProxySQL ten sam węzeł, co aplikacja. ProxySQL jest skonfigurowany do dystrybucji obciążenia na wszystkie węzły Galera w lokalnym centrum danych. Jeden z tych węzłów zostanie wybrany jako węzeł do wysyłania zapisów, podczas gdy polecenia SELECT zostaną rozłożone na wszystkie węzły. Posiadanie jednego dedykowanego węzła zapisującego w centrum danych pomaga zmniejszyć liczbę możliwych konfliktów certyfikacji, co zwykle prowadzi do lepszej wydajności. Aby zmniejszyć to jeszcze bardziej, musielibyśmy zacząć przesyłać ruch przez połączenie WAN, co nie jest idealne, ponieważ wykorzystanie przepustowości znacznie wzrosłoby. W tej chwili, gdy segmenty są na miejscu, tylko dwie kopie zbioru zapisu są wysyłane przez centra danych — jedna na DC.
Głównym problemem w przypadku wdrożeń rozproszonych geograficznie Galera Cluster są opóźnienia. To jest coś, co zawsze musisz przetestować przed uruchomieniem środowiska. Czy zgadzam się z czasem zobowiązania? Przy każdym zatwierdzeniu musi nastąpić certyfikacja, więc zestawy zapisów muszą być wysyłane i certyfikowane na wszystkich węzłach w klastrze, w tym zdalnych. Może się zdarzyć, że duże opóźnienie uzna konfigurację za nieodpowiednią dla Twojej aplikacji. W takim przypadku może się okazać, że bardziej odpowiednie może być wiele klastrów Galera połączonych za pomocą replikacji asynchronicznej. Byłby to jednak temat na inny wpis na blogu.
Wdrażanie rozproszonego geograficznie klastra Galera za pomocą ClusterControl
Dla wyjaśnienia, pokażemy tutaj, jak może wyglądać wdrożenie. Nie użyjemy rzeczywistej konfiguracji multi-DC, wszystko zostanie wdrożone w lokalnym laboratorium. Zakładamy, że latencja jest akceptowalna i cała konfiguracja jest opłacalna. Wspaniałą cechą ClusterControl jest to, że jest niezależny od infrastruktury. Nie ma znaczenia, czy węzły znajdują się blisko siebie, znajdują się w tym samym centrum danych, czy też węzły są rozproszone u wielu dostawców chmury. Dopóki istnieje łączność SSH z instancji ClusterControl do wszystkich węzłów, proces wdrażania wygląda dokładnie tak samo. Dlatego możemy pokazać Ci to krok po kroku, korzystając tylko z lokalnego laboratorium.
Instalowanie ClusterControl
Najpierw musisz zainstalować ClusterControl. Możesz pobrać to za darmo. Po rejestracji powinieneś wejść na stronę z przewodnikiem, jak pobrać i zainstalować ClusterControl. Jest to tak proste, jak uruchomienie skryptu powłoki. Po zainstalowaniu ClusterControl zostanie wyświetlony formularz umożliwiający utworzenie użytkownika administracyjnego:
Po wypełnieniu zostanie wyświetlony ekran powitalny i dostęp do kreatorów wdrażania:
Pójdziemy z wdrożeniem. Spowoduje to otwarcie kreatora wdrażania:
Wybierzemy MySQL Galera. Musimy przekazać szczegóły połączenia SSH - obsługiwany jest użytkownik root lub sudo. W następnym kroku mamy zdefiniować serwery w klastrze.
Zamierzamy wdrożyć trzy węzły w jednym z centrów danych. Wtedy będziemy mogli rozbudowywać klaster, konfigurując nowe węzły w różnych segmentach. Na razie wszystko, co musimy zrobić, to kliknąć „Wdróż” i obserwować, jak ClusterControl wdraża klaster Galera.
Nasze pierwsze trzy węzły już działają, możemy teraz przystąpić do dodawania dodatkowe węzły w innych centrach danych.
Możesz to zrobić z menu akcji, jak pokazano na powyższym zrzucie ekranu .
Tutaj możemy dodawać kolejne węzły, pojedynczo. Co ważne, powinieneś zmienić segment Galera na niezerowy (0 jest używane dla początkowych trzech węzłów).
Po pewnym czasie otrzymujemy wszystkie dziewięć węzłów rozłożonych na trzy segmenty.
Teraz musimy wdrożyć warstwę proxy. Wykorzystamy do tego ProxySQL. Możesz go wdrożyć w ClusterControl poprzez Zarządzaj -> Load Balancer:
Otworzy się pole wdrożenia:
Najpierw musimy zdecydować, gdzie wdrożyć ProxySQL. Wykorzystamy istniejące węzły Galera, ale możesz wpisać cokolwiek w terenie, więc doskonale jest możliwe wdrożenie ProxySQL na wierzchu węzłów aplikacji. Ponadto musisz przekazać poświadczenia dostępu dla użytkownika administracyjnego i monitorującego.
Następnie musimy wybrać jednego z istniejących użytkowników w MySQL lub go utworzyć teraz. Chcemy również upewnić się, że ProxySQL jest skonfigurowany do korzystania z węzłów Galera znajdujących się tylko w tym samym centrum danych.
Gdy masz gotowy serwer ProxySQL w centrum danych, możesz użyć go jako źródła konfiguracji:
To należy powtórzyć dla każdego serwera aplikacji we wszystkich centrach danych . Następnie należy skonfigurować aplikację tak, aby łączyła się z lokalną instancją ProxySQL, najlepiej przez gniazdo Unix. Zapewnia to najlepszą wydajność i najniższą latencję.
Po wdrożeniu ostatniego serwera ProxySQL nasze środowisko jest gotowe. Węzły aplikacji łączą się z lokalnym serwerem ProxySQL. Każdy serwer ProxySQL jest skonfigurowany do pracy z węzłami Galera w tym samym centrum danych:
Wnioski
Mamy nadzieję, że ta dwuczęściowa seria pomogła Ci zrozumieć mocne i słabe strony rozproszonych geograficznie klastrów Galera oraz sposób, w jaki ClusterControl ułatwia wdrażanie takiego klastra i zarządzanie nim.
