Wybór topologii HA
Istnieje wiele sposobów zachowania wysokiej dostępności w bazach danych. Możesz użyć wirtualnych adresów IP (VRRP) do zarządzania dostępnością hosta, możesz użyć menedżerów zasobów, takich jak Zookeeper i Etcd, do (re)konfiguracji aplikacji lub użyć systemów równoważenia obciążenia/serwerów proxy, aby rozłożyć obciążenie na wszystkie dostępne hosty.
Wirtualne adresy IP wymagają albo aplikacji do zarządzania nimi (MHA, Orchestrator), niektórych skryptów (Keepalived, Pacemaker/Corosync) albo inżyniera do ręcznego przełączania awaryjnego, a podejmowanie decyzji w procesie może stać się skomplikowane. Przełączanie awaryjne wirtualnego adresu IP to prosty i prosty proces polegający na usunięciu adresu IP z jednego hosta, przypisaniu go do drugiego i użyciu arpingu do wysłania nieuzasadnionej odpowiedzi ARP. Teoretycznie wirtualny adres IP można przenieść w ciągu sekundy, ale minie kilka sekund, zanim aplikacja do zarządzania pracą awaryjną upewni się, że host uległ awarii i podejmie odpowiednie działania. W rzeczywistości powinno to być od 10 do 30 sekund. Innym ograniczeniem wirtualnych adresów IP jest to, że niektórzy dostawcy usług w chmurze nie pozwalają na zarządzanie własnymi wirtualnymi adresami IP ani w ogóle ich przypisywanie. Np. Google nie zezwala na to w swoich węzłach obliczeniowych.
Menedżerowie zasobów, tacy jak Zookeeper i Etcd, mogą monitorować bazy danych i (re)konfigurować aplikacje, gdy host ulegnie awarii lub slave zostanie awansowany na master. Ogólnie jest to dobry pomysł, ale wdrożenie kontroli za pomocą Zookeeper i Etcd jest złożonym zadaniem.
System równoważenia obciążenia lub serwer proxy będzie znajdować się między aplikacją a hostem bazy danych i będzie działać transparentnie, tak jakby klient łączył się bezpośrednio z hostem bazy danych. Podobnie jak w przypadku wirtualnego adresu IP i menedżerów zasobów, systemy równoważenia obciążenia i proxy muszą również monitorować hosty i przekierowywać ruch, jeśli jeden host nie działa. ClusterControl obsługuje dwa proxy:HAProxy i ProxySQL i oba są obsługiwane dla replikacji MySQL master-slave i klastra Galera. HAProxy i ProxySQL mają swoje własne przypadki użycia, opiszemy je również w tym poście.
Dlaczego potrzebujesz systemu równoważenia obciążenia?
Teoretycznie nie potrzebujesz load balancera, ale w praktyce wolisz taki. Wyjaśnimy dlaczego.
Jeśli masz skonfigurowane wirtualne adresy IP, wszystko, co musisz zrobić, to wskazać swojej aplikacji poprawny (wirtualny) adres IP i wszystko powinno być w porządku, jeśli chodzi o połączenie. Ale załóżmy, że skalowałeś liczbę replik do odczytu, możesz chcieć zapewnić wirtualne adresy IP dla każdej z tych replik do odczytu ze względu na konserwację lub dostępność. Może to stać się bardzo dużą pulą wirtualnych adresów IP, którymi musisz zarządzać. Jeśli jedna z tych replik do odczytu uległa awarii, musisz ponownie przypisać wirtualny adres IP do innego hosta, w przeciwnym razie aplikacja połączy się z hostem, który nie działa, lub w najgorszym przypadku z opóźnionym serwerem ze starymi danymi. Dlatego konieczne jest utrzymywanie stanu replikacji w aplikacji zarządzającej wirtualnymi adresami IP.
Również w przypadku Galery jest podobne wyzwanie:teoretycznie możesz dodać dowolną liczbę hostów do konfiguracji aplikacji i wybrać jeden losowo. Ten sam problem pojawia się, gdy ten host nie działa:możesz połączyć się z niedostępnym hostem. Również używanie wszystkich hostów zarówno do odczytu, jak i zapisu może również powodować wycofanie z powodu optymistycznego blokowania w Galera. Jeśli dwa połączenia spróbują jednocześnie pisać w tym samym wierszu, jedno z nich otrzyma wycofanie. Jeśli Twoje obciążenie ma takie współbieżne aktualizacje, zaleca się używanie tylko jednego węzła w Galera do zapisu. Dlatego potrzebujesz menedżera, który śledzi wewnętrzny stan klastra bazy danych.
Zarówno HAProxy, jak i ProxySQL oferują funkcję monitorowania hostów bazy danych MySQL/MariaDB oraz utrzymywania stanu klastra i jego topologii. W przypadku konfiguracji replikacji, w przypadku awarii repliki podrzędnej, zarówno HAProxy, jak i ProxySQL mogą redystrybuować połączenia do innego hosta. Ale jeśli master replikacji nie działa, HAProxy odmówi połączenia, a ProxySQL zwróci klientowi prawidłowy błąd. W przypadku konfiguracji Galera oba systemy równoważenia obciążenia mogą wybrać węzeł główny z klastra Galera i wysyłać operacje zapisu tylko do tego konkretnego węzła.
Na pozór HAProxy i ProxySQL mogą wydawać się podobnymi rozwiązaniami, ale różnią się znacznie funkcjami i sposobem dystrybucji połączeń i zapytań. HAProxy obsługuje szereg algorytmów równoważących, takich jak najmniej połączeń, źródło, losowe i round-robin, podczas gdy ProxySQL dystrybuuje połączenia przy użyciu algorytmu round-robin opartego na wadze (równa waga oznacza równą dystrybucję). Ponieważ ProxySQL jest inteligentnym serwerem proxy, obsługuje bazę danych i jest w stanie analizować zapytania. ProxySQL jest w stanie dokonać podziału odczytu/zapisu w oparciu o reguły zapytań, w których możesz przekazywać zapytania do wyznaczonych urządzeń podrzędnych lub głównych w klastrze. ProxySQL zawiera dodatkowe funkcje, takie jak przepisywanie zapytań, buforowanie i zapora zapytań z dogłębnym generowaniem statystyk w czasie rzeczywistym na temat obciążenia.
To powinno wystarczyć na ten temat, więc zobaczmy, jak wdrożyć oba systemy równoważenia obciążenia dla replikacji MySQL i topologii Galera.
Wdrażanie HAProxy
Użycie ClusterControl do wdrożenia HAProxy w klastrze Galera jest łatwe:przejdź do odpowiedniego klastra i wybierz „Dodaj Load Balancer”:
Będziesz mógł wdrożyć instancję HAProxy, dodając adres hosta i wybierając instancje serwera, które chcesz uwzględnić w konfiguracji:
Domyślnie instancja HAProxy zostanie skonfigurowana do wysyłania połączeń do instancji serwera otrzymujących najmniejszą liczbę połączeń, ale możesz zmienić tę politykę na round robin lub source.
W ustawieniach zaawansowanych możesz ustawić limity czasu, maksymalną liczbę połączeń, a nawet zabezpieczyć serwer proxy, umieszczając na białej liście zakres adresów IP dla połączeń.
Na karcie węzłów tego klastra pojawi się węzeł HAProxy:
Teraz Twój klaster Galera jest również dostępny za pośrednictwem nowo wdrożonego węzła HAProxy na porcie 3307. Nie zapomnij przyznać aplikacji dostępu z adresu IP HAProxy, ponieważ teraz ruch będzie przychodzić z serwera proxy, a nie z hostów aplikacji. Pamiętaj również, aby skierować połączenie aplikacji do węzła HAProxy.
Załóżmy teraz, że jedna instancja serwera przestanie działać, HAProxy zauważy to w ciągu kilku sekund i przestanie wysyłać ruch do tej instancji:
Dwa pozostałe węzły nadal działają poprawnie i będą nadal otrzymywać ruch. Dzięki temu klaster zachowuje wysoką dostępność, a klient nawet nie zauważa różnicy.
Wdrażanie dodatkowego węzła HAProxy
Teraz, gdy przenieśliśmy odpowiedzialność za utrzymywanie wysokiej dostępności w połączeniach z bazą danych z klienta na HAProxy, co się stanie, jeśli węzeł proxy umrze? Odpowiedzią jest utworzenie kolejnej instancji HAProxy i użycie wirtualnego adresu IP kontrolowanego przez Keepalived, jak pokazano na tym diagramie:
Zaletą w porównaniu z używaniem wirtualnych adresów IP w węzłach bazy danych jest to, że logika MySQL jest na poziomie proxy, a przełączanie awaryjne serwerów proxy jest proste.
Wdróżmy więc dodatkowy węzeł HAProxy:
Po wdrożeniu dodatkowego węzła HAProxy musimy dodać Keepalved:
A po dodaniu Keepalived przegląd węzłów będzie wyglądał następująco:
Więc teraz zamiast kierować połączenia aplikacji bezpośrednio do węzła HAProxy, musisz zamiast tego wskazać im wirtualny adres IP.
W tym przykładzie użyliśmy oddzielnych hostów do uruchomienia HAProxy, ale można je łatwo dodać również do istniejących instancji serwera. HAProxy nie powoduje dużych obciążeń, chociaż należy pamiętać, że w przypadku awarii serwera utracisz zarówno węzeł bazy danych, jak i serwer proxy.
Wdrażanie ProxySQL
Wdrażanie ProxySQL w klastrze odbywa się w podobny sposób do HAProxy:„Dodaj Load Balancer” na liście klastrów w zakładce ProxySQL.
W kreatorze wdrażania określ, gdzie ProxySQL zostanie zainstalowany, użytkownika administracyjnego/hasło, użytkownika/hasło monitorujące, aby połączyć się z backendami MySQL. Z ClusterControl możesz utworzyć nowego użytkownika do użycia przez aplikację (użytkownik zostanie utworzony zarówno na MySQL, jak i ProxySQL) lub użyć istniejących użytkowników bazy danych (użytkownik zostanie utworzony tylko na ProxySQL). Określ, czy używasz transakcji niejawnych, czy nie. Zasadniczo, jeśli nie użyjesz SET autocommit=0 do utworzenia nowej transakcji, ClusterControl skonfiguruje podział odczytu/zapisu.
Po wdrożeniu ProxySQL będzie dostępny w zakładce Węzły:
Otwarcie przeglądu węzłów ProxySQL spowoduje wyświetlenie interfejsu monitorowania i zarządzania ProxySQL, więc nie ma już powodu, aby logować się do ProxySQL w węźle. ClusterControl obejmuje większość ważnych statystyk ProxySQL, takich jak wykorzystanie pamięci, pamięć podręczna zapytań, procesor zapytań itd., a także inne metryki, takie jak grupy hostów, serwery zaplecza, trafienia reguł zapytań, najczęstsze zapytania i zmienne ProxySQL. W aspekcie zarządzania ProxySQL możesz zarządzać regułami zapytań, serwerami zaplecza, użytkownikami, konfiguracją i harmonogramem bezpośrednio z interfejsu użytkownika.
Sprawdź naszą stronę samouczka ProxySQL, która obszernie omawia, jak wykonać równoważenie obciążenia bazy danych dla MySQL i MariaDB za pomocą ProxySQL.
Wdrażanie Garbda
Galera implementuje algorytm oparty na kworum, aby wybrać główny składnik, za pomocą którego wymusza spójność. Główny składnik musi mieć większość głosów (50% + 1 węzeł), więc w systemie z 2 węzłami nie byłoby większości skutkującej podziałem mózgu. Na szczęście możliwe jest dodanie garbd (Galera Arbitrator Daemon), który jest lekkim bezstanowym demonem, który może działać jako nieparzysty węzeł. Dodatkową korzyścią wynikającą z dodania Arbitra Galera jest to, że możesz teraz robić tylko dwa węzły w swoim klastrze.
Jeśli ClusterControl wykryje, że Twój klaster Galera składa się z parzystej liczby węzłów, otrzymasz od ClusterControl ostrzeżenie/poradę dotyczącą rozszerzenia klastra do nieparzystej liczby węzłów:
Wybierz mądrze hosta, na którym chcesz wdrożyć garbd, ponieważ otrzyma on wszystkie zreplikowane dane. Upewnij się, że sieć może obsłużyć ruch i jest wystarczająco bezpieczna. Możesz wybrać jeden z hostów HAProxy lub ProxySQL do wdrożenia garbd, jak w poniższym przykładzie:
Zwróć uwagę, że począwszy od ClusterControl 1.5.1, garbd nie może być zainstalowany na tym samym hoście co ClusterControl ze względu na ryzyko konfliktów pakietów.
Po zainstalowaniu garbd zobaczysz go obok swoich dwóch węzłów Galera:
Ostateczne myśli
Pokazaliśmy, jak sprawić, by konfiguracje klastrów MySQL master-slave i Galera były bardziej niezawodne i zachować wysoką dostępność przy użyciu HAProxy i ProxySQL. Garbd jest również fajnym demonem, który może zapisać dodatkowy trzeci węzeł w klastrze Galera.
To kończy wdrażanie ClusterControl. W naszym następnym blogu pokażemy, jak zintegrować ClusterControl w Twojej organizacji, używając grup i przypisując określone role użytkownikom.
