Jak ClusterControl konfiguruje wirtualny adres IP i czego można się spodziewać podczas przełączania awaryjnego?

Wirtualny adres IP to adres IP, który nie odpowiada rzeczywistemu fizycznemu interfejsowi sieciowemu. Przepływa między wieloma interfejsami sieciowymi i tylko jeden aktywny interfejs będzie przechowywać adres IP w celu zapewnienia odporności na uszkodzenia i mobilności. ClusterControl używa Keepalive, aby zapewnić integrację wirtualnego adresu IP z systemami równoważenia obciążenia bazy danych w celu wyeliminowania pojedynczego punktu awarii (SPOF) na poziomie systemu równoważenia obciążenia.

W tym wpisie na blogu pokażemy, jak ClusterControl konfiguruje wirtualny adres IP i czego można się spodziewać po przełączeniu awaryjnym lub powrocie po awarii. Zrozumienie tego zachowania jest niezbędne, aby zminimalizować wszelkie przerwy w świadczeniu usług i usprawnić czynności konserwacyjne, które należy wykonywać od czasu do czasu.

Wymagania

Aby uruchomić Keepalived w Twojej sieci, musisz spełnić pewne wymagania:

Protokół IP 112 (protokół nadmiarowości wirtualnego routera — VRRP) musi być obsługiwany w sieci. Niektóre sieci wyłączają obsługę VRRP, zwłaszcza komunikacji między sieciami VLAN. Zweryfikuj to u administratora sieci.
Jeśli używasz multicast, sieć musi obsługiwać żądania multicast (użyj ip a | grep -i multicast). W przeciwnym razie możesz użyć unicastu przez unicast_src_ip i unicast_peer opcje. Korzystanie z multiemisji jest przydatne, gdy masz dynamiczne środowisko, takie jak środowisko w chmurze, lub gdy przypisanie adresu IP odbywa się przez DHCP.
Zestaw instancji VRRP musi używać unikalnego virtual_router_id wartość, której nie można udostępniać innym instancjom. W przeciwnym razie zobaczysz fałszywe pakiety i prawdopodobnie zepsujesz główny przełącznik zapasowy.
Jeśli pracujesz w środowisku chmury, takim jak AWS, prawdopodobnie będziesz musiał użyć zewnętrznego skryptu (wskazówka:użyj opcji „powiadom”), aby oddzielić i skojarzyć wirtualny adres IP (elastyczny adres IP), aby był rozpoznawany i kierowany przez routera.

Wdrażanie funkcji Keepalved

Aby zainstalować Keepalived przez ClusterControl, potrzebujesz dwóch lub więcej systemów równoważenia obciążenia zainstalowanych przez lub zaimportowanych do ClusterControl. Do użytku produkcyjnego zdecydowanie zalecamy, aby oprogramowanie do równoważenia obciążenia działało na samodzielnym hoście i nie znajdowało się w tym samym miejscu co węzły bazy danych.

Po uzyskaniu co najmniej dwóch równoważników obciążenia zarządzanych przez ClusterControl, aby zainstalować Keepalived i włączyć wirtualny adres IP, po prostu przejdź do ClusterControl -> wybierz klaster -> Zarządzaj -> Load Balancer -> Keepalived:

Większość pól nie wymaga wyjaśnień. Możesz wdrożyć nowy zestaw Keepalive lub zaimportować istniejące instancje Keepalive. Ważne pola obejmują rzeczywisty wirtualny adres IP i interfejs sieciowy, w którym będzie istniał wirtualny adres IP. Jeśli hosty używają dwóch różnych nazw interfejsów, określ nazwę interfejsu hosta Keepalived 1, a następnie ręcznie zmodyfikuj plik konfiguracyjny w Keepalived 2, podając później poprawną nazwę interfejsu.

Instancja VRRP

W chwili obecnej ClusterControl v1.5.1 instaluje Keepalived v1.3.5 (w zależności od systemu operacyjnego hosta), a dla instancji VRRP skonfigurowano następujące ustawienia:

vrrp_instance VI_PROXYSQL {
   interface eth0                # interface to monitor
   state MASTER
   virtual_router_id 51          # Assign one ID for this route
   priority 100
   unicast_src_ip 10.0.0.246
   unicast_peer {
      10.0.0.204
   }
   virtual_ipaddress {
       10.0.0.100                        # the virtual IP
   }
   track_script {
       chk_proxysql
   }
#    notify /usr/local/bin/notify_keepalived.sh
}

ClusterControl konfiguruje instancję VRRP do komunikacji przez unicast. W przypadku unicastu musimy zdefiniować wszystkich partnerów unicastowych innych węzłów Keepalved. Jest mniej dynamiczny, ale działa przez większość czasu. Dzięki multiemisji możesz usunąć te wiersze (unicast_*) i polegać na adresie IP multiemisji do wykrywania hostów i komunikacji równorzędnej. Jest to prostsze, ale często jest blokowane przez administratorów sieci.

Następna część to wirtualny adres IP. Możesz określić wiele wirtualnych adresów IP na instancję VRRP, oddzielonych nowym wierszem. Równoczesne równoważenie obciążenia w HAProxy/ProxySQL i Keepalived wymaga również możliwości powiązania się z adresem IP, który nie jest lokalny, co oznacza, że nie jest przypisany do urządzenia w systemie lokalnym. Dzięki temu uruchomiona instancja modułu równoważenia obciążenia może powiązać adres IP, który nie jest lokalny na potrzeby przełączania awaryjnego. W ten sposób ClusterControl konfiguruje również net.ipv4.ip_nonlocal_bind=1 wewnątrz /etc/sysctl.conf.

Następna dyrektywa to track_script , gdzie możesz określić skrypt do procesu sprawdzania kondycji, co wyjaśniono w następnej sekcji.

Kontrole stanu

ClusterControl konfiguruje Keepalived do przeprowadzania kontroli kondycji, sprawdzając kod błędu zwrócony przez track_script. W pliku konfiguracyjnym Keepalived, który domyślnie znajduje się w /etc/keepalived/keepalived.conf, powinieneś zobaczyć coś takiego:

   track_script {
       chk_proxysql
   }

Gdzie wywołuje chk_proxysql, który zawiera:

vrrp_script chk_proxysql {
   script "killall -0 proxysql"   # verify the pid existence
   interval 2                    # check every 2 seconds
   weight 2                      # add 2 points of prio if OK
}

Polecenie „killall -0” zwraca kod zakończenia 0, jeśli na hoście działa proces o nazwie „proxysql”. W przeciwnym razie instancja musiałaby się obniżyć i rozpocząć inicjowanie pracy awaryjnej, jak wyjaśniono w następnej sekcji. Zwróć uwagę, że Keepalived obsługuje również komponenty Linux Virtual Server (LVS) do przeprowadzania kontroli stanu, w których jest również zdolny do równoważenia obciążenia połączeń TCP/IP, podobnie jak HAProxy, ale to wykracza poza zakres tego wpisu na blogu.

Symulowanie przełączania awaryjnego

W przypadku komponentów VRRP Keepalived używa protokołu VRRP (protokół IP 112) do komunikacji między instancjami VRRP. Wyższa wartość priorytetu MASTER oznacza, że master zawsze będzie miał wyższe uprawnienia do przechowywania wirtualnego adresu IP, chyba że skonfigurujesz instancję z opcją „nopreempt”. Użyjmy przykładu, aby lepiej wyjaśnić przepływ pracy awaryjnej i powrotu po awarii. Rozważ następujący diagram:

Istnieją trzy instancje ProxySQL przed trzema węzłami MySQL Galera. Każdy host ProxySQL jest skonfigurowany z Keepalive jako MASTER z następującym numerem priorytetu:

ProxySQL1 — priorytet 101
ProxySQL2 — priorytet 100
ProxySQL3 — priorytet 99

Kiedy Keepalived zostanie uruchomiony jako MASTER, najpierw ogłosi numer priorytetowy członkom, a następnie powiąże się z wirtualnym adresem IP. W przeciwieństwie do instancji BACKUP, będzie tylko obserwować reklamę i przypisywać wirtualny adres IP dopiero po potwierdzeniu, że może awansować na MASTER.

Zwróć uwagę, że jeśli ręcznie zabijesz proces "proxysql" lub "haproxy" za pomocą polecenia kill, menedżer procesów systemd domyślnie spróbuje odzyskać proces, który jest niewłaściwie zatrzymywany. Ponadto, jeśli masz włączone automatyczne odzyskiwanie ClusterControl, ClusterControl zawsze będzie próbował rozpocząć proces, nawet jeśli wykonasz czyste zamknięcie przez systemd (systemctl stop proxysql). Aby jak najlepiej zasymulować awarię, sugerujemy użytkownikowi wyłączenie funkcji automatycznego odzyskiwania ClusterControl lub po prostu wyłączenie serwera ProxySQL w celu przerwania komunikacji.

Jeśli wyłączymy ProxySQL1, wirtualny adres IP zostanie przeniesiony do następnego hosta, który w danym momencie ma wyższy priorytet (czyli ProxySQL2) :

W dzienniku systemowym uszkodzonego węzła zobaczysz następujące informacje:

Feb 27 05:21:59 proxysql1 systemd: Unit proxysql.service entered failed state.
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: /usr/bin/killall -0 proxysql exited with status 1
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: VRRP_Script(chk_proxysql) failed
Feb 27 05:21:59 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Changing effective priority from 103 to 101
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Received advert with higher priority 102, ours 101
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Entering BACKUP STATE
Feb 27 05:22:00 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) removing protocol VIPs.

Na węźle drugorzędnym wydarzyły się następujące rzeczy:

Feb 27 05:22:00 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) forcing a new MASTER election
Feb 27 05:22:01 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Transition to MASTER STATE
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Entering MASTER STATE
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) setting protocol VIPs.
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 Keepalived_vrrp[7794]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:22:02 proxysql2 avahi-daemon[346]: Registering new address record for 10.0.0.100 on eth0.IPv4.

W tym przypadku przełączanie awaryjne trwało około 3 sekund, przy czym maksymalny czas przełączania wynosiłby interwał + advert_int . Za kulisami punkt końcowy bazy danych uległ zmianie, a ruch bazy danych jest kierowany przez ProxySQL2 bez zauważenia przez aplikacje.

Kiedy ProxySQL1 powróci do trybu online, wymusi nowy wybór MASTER i przejmie adres IP ze względu na wyższy priorytet:

Feb 27 05:38:34 proxysql1 Keepalived_vrrp[12589]: VRRP_Script(chk_proxysql) succeeded
Feb 27 05:38:35 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Changing effective priority from 101 to 103
Feb 27 05:38:36 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) forcing a new MASTER election
Feb 27 05:38:37 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Transition to MASTER STATE
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Entering MASTER STATE
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) setting protocol VIPs.
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: Sending gratuitous ARP on eth0 for 10.0.0.100
Feb 27 05:38:38 proxysql1 Keepalived_vrrp[12589]: VRRP_Instance(VI_PROXYSQL) Sending/queueing gratuitous ARPs on eth0 for 10.0.0.100
Feb 27 05:38:38 proxysql1 avahi-daemon[343]: Registering new address record for 10.0.0.100 on eth0.IPv4.

Jednocześnie ProxySQL2 obniża się do stanu BACKUP i usuwa wirtualny adres IP z interfejsu sieciowego:

Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Received advert with higher priority 103, ours 102
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) Entering BACKUP STATE
Feb 27 05:38:36 proxysql2 Keepalived_vrrp[7794]: VRRP_Instance(VI_PROXYSQL) removing protocol VIPs.
Feb 27 05:38:36 proxysql2 avahi-daemon[346]: Withdrawing address record for 10.0.0.100 on eth0.

W tym momencie ProxySQL1 jest ponownie w trybie online i staje się aktywnym systemem równoważenia obciążenia, który obsługuje połączenia z aplikacji i klientów. VRRP zwykle wywłaszczy serwer o niższym priorytecie, gdy serwer o wyższym priorytecie zostanie włączony do sieci. Jeśli chcesz, aby adres IP pozostał na ProxySQL2 po powrocie ProxySQL1 do trybu online, użyj opcji "nopreempt". Dzięki temu komputer o niższym priorytecie może zachować rolę nadrzędną, nawet gdy komputer o wyższym priorytecie wróci do trybu online. Jednak aby to zadziałało, początkowy stan tego wpisu musi być BACKUP. W przeciwnym razie zauważysz następujący wiersz:

Feb 27 05:50:33 proxysql2 Keepalived_vrrp[6298]: (VI_PROXYSQL): Warning - nopreempt will not work with initial state MASTER

Ponieważ ClusterControl domyślnie konfiguruje wszystkie węzły jako MASTER, należy odpowiednio skonfigurować następującą opcję konfiguracji dla odpowiedniej instancji VRRP:

vrrp_instance VI_PROXYSQL {
...
   state BACKUP
   nopreempt
...
}

Uruchom ponownie proces Keepalived, aby załadować te zmiany. Wirtualny adres IP zostanie przełączony awaryjnie do ProxySQL1 lub ProxySQL3 (w zależności od priorytetu i tego, który węzeł jest dostępny w danym momencie), jeśli kontrola stanu nie powiedzie się na ProxySQL2. W wielu przypadkach wystarczy uruchomić Keepalived na dwóch hostach.