Jak skonfigurować klaster Redis w CentOS 8 — część 3

Klaster Redis to wbudowana funkcja Redis, która obsługuje automatyczne dzielenie na fragmenty, replikację i wysoką dostępność, co zostało wcześniej zaimplementowane przy użyciu Sentinels. Został zaprojektowany do dwóch głównych celów: jednym jest automatyczne dzielenie zbioru danych na wiele instancji, a drugim zapewnienie pewnego stopnia dostępności podczas partycji, aby kontynuować działanie, gdy niektóre instancje (szczególnie główne) zawiodą lub nie będą w stanie komunikować się z większością węzły w klastrze.

Klaster przestaje jednak działać w przypadku większych awarii (np. gdy większość instancji master jest niedostępna). Ponadto, jeśli w tym samym czasie ulegną awarii urządzenia nadrzędnego i podrzędnego, klaster nie będzie mógł kontynuować normalnego działania (chociaż rozwiązaniem jest dodanie większej liczby węzłów lub utworzenie asymetrii w klastrze w celu automatycznej zmiany układu klastra).

Zgodnie z dokumentacją klastra Redis „klaster minimalny”, który działa zgodnie z oczekiwaniami, wymaga co najmniej 3 węzłów głównych. Jednak najbardziej odpowiednia konfiguracja zapewniająca wysoką dostępność powinna obejmować co najmniej 6 węzłów z trzema urządzeniami nadrzędnymi i trzema urządzeniami podrzędnymi, przy czym każdy element nadrzędny ma swojego podrzędnego.

Ważne: Redis Cluster ma również pewne ograniczenia, którymi jest brak obsługi środowisk NAT, a także tych, w których adresy IP lub porty TCP są ponownie mapowane instancję w Dockerze. Ponadto nie każda biblioteka kliencka ją obsługuje.

W tym artykule pokazano, jak skonfigurować klaster Redis (z wyłączonym trybem klastra) w CentOS 8. Obejmuje sposób instalacji Redis, konfigurowania węzłów klastra, tworzenia klastra i testowania przełączania awaryjnego klastra.

Uwaga: w tym przewodniku do uruchomienia trybu klastra użyjemy świeżych/pustych instancji Redis. Tryb klastra nie będzie działał z niektórymi konfiguracjami wykonanymi w pierwszych dwóch przewodnikach z naszej serii Redis, szczególnie nie działa, gdy używana jest replika parametru.

Warunki wstępne:

Serwery z instalacją CentOS 8

Konfiguracja środowiska testowego

Redis Master1: 10.42.0.247
Redis Master2: 10.42.0.197
Redis Master3: 10.42.0.132

Redis Slave1: 10.42.0.200
Redis Slave2: 10.42.0.21
Redis Slave3: 10.42.0.34

Nasza konfiguracja obejmuje 3 węzły główne do odczytu/zapisu i 3 węzły repliki tylko do odczytu, przy czym każdy główny ma jedną replikę, więc trzy fragmenty zawierają wszystkie dane klastra w każdym węźle. Klient aplikacji API lub CLI może zapisywać tylko do węzłów głównych, ale czytać z dowolnego węzła w klastrze.

Krok 1: Instalowanie Redis na wszystkich węzłach

1. Zaloguj się do wszystkich instancji przez SSH, a następnie uruchom poniższe polecenie, aby zainstalować moduł Redis przy użyciu menedżera pakietów DNF, jak pokazano.

dnf module install redis

2. Następnie uruchom usługę Redis, włącz ją, aby automatycznie uruchamiała się przy starcie systemu i sprawdź jej status, aby sprawdzić, czy działa (sprawdź usługę we wszystkich 6 instancjach ):

systemctl start redis
systemctl enable redis
systemctl status redis

Krok 2: Konfigurowanie instancji Redis na wszystkich węzłach

3. W tej sekcji opisano sposób konfigurowania węzłów klastra Redis. Pamiętaj, aby przeprowadzić tutaj konfiguracje na wszystkich węzłach.

Użyj pliku konfiguracyjnego /etc/redis.conf, aby skonfigurować serwer Redis. Zalecaną praktyką jest utworzenie kopii zapasowej oryginalnego pliku przed edycją za pomocą wybranego edytora tekstu wiersza poleceń.

cp /etc/redis.conf /etc/redis.conf.orig
vi /etc/redis.conf

4. Następnie znajdź następujące parametry konfiguracyjne i edytuj ich wartości, jak pokazano. Parametr bind ustawia interfejs serwera Redis, na którym będzie nasłuchiwać, ustaw jego wartość na adres IP instancji LAN. Usuń 127.0.0.1, ponieważ zdaliśmy sobie sprawę, że pozostawienie go tam spowalnia proces tworzenia klastra, szczególnie etap dołączania do klastra.

bind  10.42.0.247

Następnie ustaw tryb chroniony na no, aby zezwolić na połączenia z innych instancji w klastrze.

protected-mode no

Parametr port określa port, na którym serwer Redis będzie nasłuchiwał połączeń. Wartość domyślna to 6379. Jest to port danych służący do komunikacji z klientami.

port 6379

5. Następny zestaw parametrów włączy tryb klastra i ustawi niektóre jego przydatne funkcje. Parametr włączony w klastrze, gdy jest ustawiony na yes, aktywuje tryb klastra.

cluster-enabled yes

Następnie parametr cluster-config-file ustawia nazwę pliku konfiguracyjnego klastra węzła klastra (np. nodes-6379.conf). Plik jest tworzony w katalogu roboczym (domyślnie jest to /var/lib/redis zdefiniowany przy użyciu parametru dir) i nie można go edytować przez użytkownika.

cluster-config-file nodes-6379.conf

Następną przydatną opcją klastra jest limit czasu węzła klastra. Służy do ustawienia maksymalnego czasu (w milisekundach), przez jaki instancja może być niedostępna, aby można było uznać ją za znajdującą się w stanie awarii. Wartość 15000 odpowiada 15 sekundom.

cluster-node-timeout 15000

6. Musimy także włączyć trwałość Redis na dysku. Możemy skorzystać z jednego z trybów trwałości, czyli Append Only File (AOF): loguje (w utworzonym pliku appendonly.aof w katalogu roboczym) każda operacja zapisu pomyślnie odebrana przez serwer. Dane zostaną odtworzone podczas uruchamiania serwera w celu zrekonstruowania oryginalnego zestawu danych.

Aby to włączyć, ustaw parametr appendonly na yes.

appendonly yes

7. Po wprowadzeniu wszystkich zmian uruchom ponownie usługę Redis na wszystkich węzłach, aby zastosować ostatnie zmiany.

systemctl restart redis

8. W tym momencie każdy węzeł klastra powinien mieć teraz identyfikator. Możesz to sprawdzić w pliku dziennika znajdującym się pod adresem /var/log/redis/redis.log.

cat /var/log/redis/redis.log

9. Następnie otwórz porty 6397 i 16379 we wszystkich instancjach. Późniejszy port jest używany dla magistrali klastra (kanał komunikacji węzeł z węzłem wykorzystujący protokół binarny). Jest to podstawowy wymóg dla połączeń TCP klastra Redis.

firewall-cmd --zone=public --permanent --add-port=6379/tcp 
firewall-cmd --zone=public --permanent --add-port=16379/tcp 
firewall-cmd --reload

Krok 3: Tworzenie klastra Redis

10. Aby utworzyć klaster, użyj klienta wiersza poleceń redis-cli w następujący sposób. --cluster create umożliwia utworzenie klastra, a --cluster-replicas 1 oznacza utworzenie jednej repliki na master.

W przypadku naszej konfiguracji, która ma 6 węzłów, będziemy mieć 3 urządzenia główne i 3 urządzenia podrzędne.

Zwróć uwagę, że pierwszych 6 węzłów zostanie uznanych za główne (M), a kolejne trzy zostaną uznane za podrzędne (S). Pierwszy slave, tj. 10.42.0.200:6379 replikuje pierwszego mastera, tj. 10.42.0.247:6379, drugi slave replikuje drugiego mastera, w tej kolejności.

Poniższe polecenie jest sformatowane w taki sposób, że wynik będzie reprezentował naszą logiczną konfigurację powyżej.

redis-cli --cluster create 10.42.0.247:6379 10.42.0.197:6379 10.42.0.132:6379 10.42.0.200:6379 10.42.0.21:6379 10.42.0.34:6379 --cluster-replicas 1

11. Po pomyślnym utworzeniu klastra uruchom następującą komendę na dowolnym hoście (określ jego adres IP za pomocą flagi -h), aby wyświetlić listę wszystkich węzłów klastra.

redis-cli -h 10.42.0.247 -p 6379 cluster nodes

Powinieneś być w stanie zobaczyć wszystkie węzły klastra, a urządzenia podrzędne wskazują swoich mistrzów, jak pokazano na poniższym zrzucie ekranu.

Poszczególne pola są w następującej kolejności: identyfikator węzła, adres IP:port, flagi, ostatni wysłany ping, ostatni odebrany pong, epoka konfiguracji, stan łącza, sloty (dla masterów).

Krok 4: Testowanie przełączania awaryjnego klastra Redis

12. W tej sekcji pokażemy, jak przetestować przełączanie awaryjne klastra. Na początek zwróćmy uwagę na mistrzów.

redis-cli -h 10.42.0.247 -p 6379 cluster nodes  | grep master

Zwróć także uwagę na niewolników Redis.

redis-cli -h 10.42.0.247 -p 6379 cluster nodes  | grep slave

13. Następnie zatrzymajmy usługę Redis na jednym z węzłów głównych, np. 10.42.0.197 i sprawdźmy wszystkie węzły główne w klastrze.

systemctl stop redis
redis-cli -h 10.42.0.247 -p 6379 cluster nodes | grep master

Na poniższym zrzucie ekranu widać, że węzeł 10.42.0.197:6367 jest w stanie awarii, a jego urządzenie podrzędne 10.42.0.21:6379 zostało awansowane do statusu głównego.

14. Teraz ponownie uruchommy usługę Redis na uszkodzonym węźle i sprawdźmy wszystkie mastery w klastrze.

systemctl start redis
redis-cli -h 10.42.0.247 -p 6379 cluster nodes  | grep master

Sprawdź także urządzenia podrzędne klastra, aby potwierdzić, że uszkodzony moduł główny jest teraz urządzeniem podrzędnym.

redis-cli -h 10.42.0.247 -p 6379 cluster nodes  | grep slave

Krok 5: Testowanie replikacji danych w klastrze Redis

15. W ostatniej sekcji wyjaśniono, jak zweryfikować replikację danych klastra. Utworzymy klucz i wartość na jednym z masterów, a następnie spróbujemy odczytać je ze wszystkich węzłów klastra w następujący sposób. Użyj przełącznika -c, aby włączyć obsługę klastrów w narzędziu redis-cli i uzyskać dostęp do danych w trybie klastra.

redis-cli -c -h 10.42.0.247 -p 6379 set name 'TecMint.com'
redis-cli -c -h 10.42.0.247 -p 6379 get name
redis-cli -c -h 10.42.0.21 -p 6379 get name
redis-cli -c -h 10.42.0.132 -p 6379 get name
redis-cli -c -h 10.42.0.200 -p 6379 get name
redis-cli -c -h 10.42.0.197 -p 6379 get name
redis-cli -c -h 10.42.0.34 -p 6379 get name

Konkluzja jest taka, że Klaster Redis to preferowany sposób uzyskania automatycznego fragmentowania, replikacji i wysokiej dostępności. W pozostałej części pliku /etc/redis.conf znajduje się wiele innych dobrze udokumentowanych parametrów konfiguracyjnych. Więcej informacji można znaleźć w oficjalnej dokumentacji: poradnik dotyczący klastra Redis i specyfikacja klastra Redis.

To prowadzi nas do końca trzyczęściowej serii samouczków Redis. Poniższy formularz opinii umożliwia przesyłanie pytań i komentarzy.