W naszym poprzednim blogu omówiliśmy ClusterControl CMON HA for Distributed Database High Availability napisane przez Krzysztofa Książka w dwóch osobnych postach. Na tym blogu omówimy dystrybucję węzłów lokalnie i w chmurze publicznej (przy użyciu Google Cloud Platform (GCP)).
Powodem, dla którego napisaliśmy ten blog, jest to, że otrzymaliśmy pytania o to, jak zaimplementować instancję ClusterControl o wysokiej dostępności z węzłami CMON działającymi lokalnie i innymi węzłami CMON działającymi na inne centrum danych (np. chmura publiczna). W naszym poprzednim blogu ClusterControl CMON HA for Distributed Database High Availability używaliśmy węzłów Galera Cluster, ale tym razem użyjemy MySQL Replication przy użyciu Percona Server 5.7. Idealną konfiguracją do tego jest zawsze enkapsulacja komunikacji węzłów z lokalizacji lokalnej i węzłów znajdujących się w chmurze publicznej za pośrednictwem sieci VPN lub bezpiecznego kanału.
ClusterControl CMON HA jest na wczesnym etapie, do którego naszym zdaniem nie jest jeszcze wystarczająco dojrzały. Jednak nasz CMON HA jest w stanie zapewnić Ci poczucie funkcjonalności do wdrożenia ClusterControl, aby zapewnić wysoką dostępność. Przejdźmy dalej, jak możesz wdrożyć i skonfigurować dystrybucję węzłów lokalnie za pośrednictwem chmury publicznej.
Co to jest CMON?
Zanim przejdziemy do głównego tematu, pozwól, że przedstawimy Ci czym jest CMON. CMON to skrót od ClusterControl Controller, który jest „głównym mózgiem” ClusterControl. Usługa backendu realizująca automatyzację, zarządzanie, monitorowanie zadań harmonogramowania, a także dostępność HA. Zbierane dane są przechowywane w bazie danych CMON, dla której jako magazynu danych używamy baz danych kompatybilnych z MySQL.
Konfiguracja architektoniczna
Niektórzy z was mogli nie znać możliwości ClusterControl, które może on wykonywać i być skonfigurowany pod kątem wysokiej dostępności. Jeśli masz uruchomionych wiele węzłów ClusterControl (lub CMON), jest to możliwe bez żadnych kosztów. Możesz być w stanie uruchomić mnóstwo węzłów ClusterControl, kiedy tylko zajdzie taka potrzeba.
W tej konfiguracji będziemy mieć węzły ClusterControl nad ClusterControl w celu tworzenia lub wdrażania węzłów bazy danych i zarządzania automatycznym przełączaniem awaryjnym, gdy na przykład wystąpi awaria. Chociaż możesz użyć MHA, Orchestrator lub Maxscale do zarządzania automatycznym przełączaniem awaryjnym, ale dla wydajności i szybkości użyję ClusterControl do wykonywania specjalnych rzeczy, których nie mają inne wymienione przeze mnie narzędzia.
Rzućmy więc okiem na diagram dla tej konfiguracji:
Instalacja oparta na tym diagramie pokazuje, że na górze trzywęzłowego CMON , nad nimi znajduje się działający CMON (ClusterControl), który będzie monitorować automatyczne przełączanie awaryjne. Następnie HAProxy będzie w stanie równoważyć obciążenie między monitorowanymi trzema węzłami CMON, przy czym jeden węzeł znajduje się w oddzielnym regionie hostowanym w GCP na potrzeby tego bloga. Możesz zauważyć, że nie uwzględniliśmy Keepalived, ponieważ nie możemy umieścić VIP w GCP, ponieważ znajduje się on w innej sieci.
Jak mogłeś zauważyć, umieszczamy w sumie trzy węzły. CMON HA wymaga, abyśmy potrzebowali co najmniej 3 węzłów w celu przeprowadzenia procesu głosowania lub tzw. kworum. Tak więc w przypadku tej konfiguracji wymagamy, abyś miał co najmniej 3 węzły, aby mieć wyższą dostępność.
Wdrażanie lokalnych węzłów ClusterControl
W tej sekcji oczekujemy, że masz już skonfigurowany lub zainstalowany interfejs użytkownika ClusterControl, którego użyjemy do wdrożenia trzywęzłowego klastra replikacji MySQL przy użyciu serwera Percona Server.
Najpierw utwórzmy klaster, wdrażając nową replikację MySQL, jak pokazano poniżej.
Pamiętaj, że używam tutaj Percona Server 5.7, dla którego domyślna konfiguracja przez ClusterControl działa wydajnie.
Następnie zdefiniuj nazwę hosta lub adres IP swoich węzłów,
W tym momencie spodziewamy się, że masz już skonfigurowane dwa węzły Replikacja Master/Slave, która jest hostowana lub uruchomiona lokalnie. Poniższy zrzut ekranu powinien pokazać, jak będą wyglądać Twoje węzły:
Skonfiguruj i zainstaluj ClusterControl oraz włącz CMON HA na pierwszym węźle
Z poprzedniego bloga ClusterControl CMON HA for Distributed Database High Availability pokrótce przedstawiliśmy, jak to zrobić. Zejdźmy jeszcze raz i wykonaj kroki, jak podano, ale dla tej konkretnej konfiguracji replikacji Master/Slave.
Najpierw wybierz jeden węzeł, który chcesz zainstalować jako pierwszy ClusterControl (w tej konfiguracji instaluję najpierw na węźle 192.168.70.80) i wykonaj poniższe czynności.
Krok pierwszy
Zainstaluj ClusterControl
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootPamiętaj, że gdy zostaniesz poproszony o wykrycie aktualnej instancji mysql, musisz pozwolić ClusterControl na użycie istniejącego mysqld, ponieważ jest to jeden z naszych celów tutaj dla CMON HA i aby ta konfiguracja używała już skonfigurowałeś MySQL.
Krok drugi
Powiąż CMON nie tylko, aby zezwolić przez host lokalny, ale także na konkretnym adresie IP (ponieważ włączymy HA)
## edit /etc/default/CMON and modify the line just like below or add the line if it doesn't exist
RPC_BIND_ADDRESSES="127.0.0.1,192.168.70.80"Krok trzeci
Następnie uruchom ponownie CMON,
service CMON restartKrok czwarty
Zainstaluj narzędzia CLI s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shPodczas tej instalacji narzędzie s9s skonfiguruje użytkownika administratora, którego można używać podczas obsługi polecenia s9s, podobnie jak włączanie CMON HA.
Krok piąty
Włącz HA CMON
$ s9s controller --enable-CMON-haKrok szósty
Na koniec zmodyfikuj /etc/my.cnf i dodaj,
slave-skip-errors = 1062w sekcji [mysqld]. Po dodaniu nie zapomnij ponownie uruchomić mysql jako,
service mysql restartlub
systemctl restart mysqlObecnie jest to ograniczenie, z jakim mamy do czynienia w przypadku CMON HA, ponieważ próbuje on wstawiać wpisy dziennika do urządzenia podrzędnego, ale na razie może to być w porządku.
Skonfiguruj, zainstaluj ClusterControl i włącz CMON HA na drugim węźle
Proste jak w przypadku pierwszego węzła. Teraz w drugim węźle (192.168.70.70) musimy wykonać te same kroki, ale zamiast tego musimy wprowadzić pewne poprawki w krokach, aby umożliwić to HA.
Krok pierwszy
Skopiuj konfigurację do drugiego węzła (192.168.70.70) z pierwszego węzła (192.168.70.80)
$ scp -r /etc/CMON* 192.168.70.70:/etc/Krok drugi
W drugim węźle edytuj plik /etc/CMON.cnf i upewnij się, że host jest poprawnie skonfigurowany. np.
vi /etc/CMON.cnfNastępnie przypisz parametr nazwy hosta jako,
nazwa hosta=192.168.70.70
Krok trzeci
Zainstaluj ClusterControl,
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootJednakże pomiń instalację CMON (lub ClusterControl Controller) po napotkaniu tego wiersza,
=> An existing Controller installation detected!
=> A re-installation of the Controller will overwrite the /etc/CMON.cnf file
=> Install the Controller? (y/N):Resztę, po prostu wykonaj to, co zrobiłeś na pierwszym węźle, na przykład ustaw nazwę hosta, użyj istniejącej uruchomionej instancji mysqld, podając hasło MySQL i hasło do CMON, które muszą być oba mają to samo hasło z pierwszym węzłem.
Krok czwarty
Zainstaluj narzędzia CLI s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shKrok piąty
Skopiuj pozostałą konfigurację z pierwszego węzła do drugiego węzła.
$ scp -r ~/.s9s/ 192.168.70.70:/root/
$ scp /etc/s9s.conf 192.168.70.70:/etc/
$ scp /var/www/html/clustercontrol/bootstrap.php 192.168.70.70:/var/www/html/clustercontrol/Krok szósty
Zainstaluj pakiet clustercontrol-controller,
Dla Ubuntu/Debiana
$ apt install -y clustercontrol-controllerW przypadku RHEL/CentOS/Fedory
$ yum install -y clustercontrol-controllerKrok siódmy
Skopiuj plik /etc/default/CMON i zmodyfikuj adres IP dla adresu powiązania RPC
scp /etc/default/CMON 192.168.70.70:/etc/default
RPC_BIND_ADDRESSES="127.0.0.1,10.0.0.103"Następnie uruchom ponownie CMON w następujący sposób,
service CMON restartKrok ósmy
Zmodyfikuj /etc/my.cnf i dodaj,
slave-skip-errors = 1062w sekcji [mysqld]. Po dodaniu nie zapomnij ponownie uruchomić mysql jako,
service mysql restartlub
systemctl restart mysqlObecnie jest to ograniczenie, z jakim mamy do czynienia w przypadku CMON HA, ponieważ próbuje on wstawiać wpisy dziennika do urządzenia podrzędnego, ale na razie może to być w porządku.
Krok dziewiąty
Na koniec sprawdź, jak wyglądają węzły CMON HA,
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
Total: 2 controller(s)Wdrażanie węzła ClusterControl w chmurze
Jak wspomnieliśmy wcześniej, idealną konfiguracją komunikacji jest enkapsulacja pakietów przez VPN lub inne środki bezpiecznego kanału. Jeśli masz wątpliwości, jak to zrobić, zapoznaj się z naszym poprzednim blogiem Multi-DC PostgreSQL:Konfigurowanie węzła gotowości w innej lokalizacji geograficznej przez VPN, dla którego omówiliśmy, jak stworzyć prostą konfigurację VPN za pomocą OpenVPN.
Tak więc w tej sekcji spodziewamy się, że masz już skonfigurowane połączenie VPN. Teraz zamierzamy dodać urządzenie podrzędne, które mamy dystrybuować dostępność CMON do Google Cloud Platform. Aby to zrobić, po prostu przejdź do Add Replication Slave, który można znaleźć, klikając ikonę klastra w prawym rogu. Zobacz jak to wygląda poniżej:
Teraz tak otrzymamy:
Teraz, ponieważ dodaliśmy nowe urządzenie podrzędne hostowane pod GCP, być może będziesz musiał powtórzyć to, co zrobiliśmy wcześniej na drugim węźle. Przekażę ci wykonanie tych kroków i postępuj zgodnie z instrukcjami, jak zrobiliśmy na drugim węźle.
Gdy masz to poprawnie, otrzymasz następujący wynik:
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
f 1.7.5.3735 system admins 10.142.0.39 10.142.0.39 9501 Accepting heartbeats.gdzie w węzłach
- 192.168.70.80 – (węzeł 8) i znajduje się w mojej siedzibie
- 192.168.70.70 - (node7) i znajduje się w mojej siedzibie
- 10.142.0.39 - (gnode1) jest hostowany w GCP i w innym regionie
CMON HA w akcji
Mój kolega Krzysztof Książek dostarczył już konfigurację HA przy użyciu HAProxy tutaj na tym blogu ClusterControl CMON HA for Distributed Database High Availability — część druga (konfiguracja dostępu GUI).
Aby postępować zgodnie z procedurą podaną na blogu, upewnij się, że masz pakiety xinetd i pathlib. Możesz zainstalować xinetd i pathlib w następujący sposób,
$ sudo yum install -y xinetd python-pathlib.noarchUpewnij się również, że masz CMONhachk zdefiniowany w /etc/services tak jak poniżej:
[[email protected] ~]# grep 'CMONhachk' /etc/services
CMONhachk 9201/tcpi zapewnij zmiany i zrestartuj xinetd,
service xinetd restartPominę procedury Keepalive i HAProxy i spodziewam się, że odpowiednio je skonfigurowałeś. Jedną z rzeczy, którą musisz wziąć pod uwagę w tej konfiguracji, jest to, że korzystanie z Keepalived nie może mieć zastosowania, jeśli rozdzielasz VIP z lokalnej sieci do publicznej sieci chmurowej, ponieważ są to zupełnie inne sieci.
Teraz zobaczmy, jak CMON HA reaguje, gdy węzły nie działają. Jak pokazano wcześniej, węzeł 192.168.70.80 (węzeł 8) działał jako lider, tak jak pokazano poniżej:
Gdy baza danych węzła głównego pokazuje również węzeł 8 jako główny z widoku topologii ClusterControl . Spróbujmy zabić node8 i zobaczmy, jak działa CMON HA,
Jak widać, gnode1 (węzeł GCP) przejmuje rolę lidera gdy node8 spada. Sprawdzając wyniki HAProxy w następujący sposób,
a nasze węzły ClusterControl pokazują, że węzeł 8 jest wyłączony, podczas gdy węzeł GCP zabiera jako mistrz,
Na koniec dostęp do mojego węzła HAProxy, który działa na hoście 192.168.10.100 pod adresem port 81 pokazuje następujący interfejs użytkownika,
Wnioski
Nasz ClusterControl CMON HA istnieje od wersji 1.7.2, ale był również dla nas wyzwaniem, ponieważ pojawiły się różne pytania i preferencje dotyczące wdrażania tego rozwiązania, na przykład przy użyciu replikacji MySQL w klastrze Galera.
Nasz CMON HA nie jest jeszcze dojrzały, ale jest teraz gotowy do zaspokojenia Twoich potrzeb związanych z wysoką dostępnością. Różne podejścia mogą mieć zastosowanie, o ile kontrole określą właściwy węzeł, który jest uruchomiony.
Zachęcamy do konfiguracji i wdrażania przy użyciu CMON HA i daj nam znać, jak dobrze odpowiada Twoim potrzebom lub jeśli problem będzie się powtarzał, poinformuj nas, jak pomóc Ci zaspokoić potrzeby związane z wysoką dostępnością.
