Załóżmy scenariusz, w którym masz tylko jedną instancję Redis w swojej produkcji, która z jakiegoś powodu ulegnie awarii. Twoja aplikacja buforuje dane w magazynie danych Redis i teraz jedyne źródło danych nie działa. Jednym ze sposobów kontrolowania tego rodzaju scenariuszy jest utrzymanie architektury master-slave, w której jednostki podrzędne mogą replikować węzeł główny, dopóki nie wróci. Klastry Redis obsługują do pewnego stopnia wysoką dostępność dzięki podejściu master-replika. Redis Sentinel to kolejne podejście, które zapewnia bardziej niezawodny sposób na utrzymanie wysokiej dostępności instancji Redis. Monitoruje węzeł główny Redis pod kątem awarii i natychmiast uruchamia proces przełączania awaryjnego, który promuje istniejący węzeł podrzędny do zupełnie nowego węzła głównego.
Ponadto Redis Sentinel działa jako pośrednik, z którym klienci łączą się i pytają o najnowszy adres IP węzła głównego. Tak więc podłączony wartownik natychmiast dostarcza adres węzła głównego.
Ponadto awaria węzła nadrzędnego jest potwierdzana, jeśli wielu strażników zgodziło się, że dany węzeł nadrzędny jest nieosiągalny lub dostępny. To kończy fazę wykrywania awarii i natychmiast rozpoczyna się proces przełączania awaryjnego. Dlatego wartownik Redis może być postrzegany jako system rozproszony o określonych właściwościach.
Zgoda strażników opiera się na wartości kworum, która zostanie omówiona w następnej sekcji.
czyja wartość
Wartość Kworum to maksymalna liczba strażników, którą należy uzgodnić, gdy węzeł główny nie działa. Ta wartość jest używana tylko do identyfikacji awarii w węźle głównym. Proces przełączania awaryjnego rozpoczyna się od autoryzacji wielu dostępnych węzłów wartowniczych do kontynuowania działania wybranego wartownika jako lidera.
Funkcje Redis Sentinel
Wartownik znany jest z zapewniania mechanizmu wysokiej dostępności dla magazynu danych Redis. Oprócz tego można wymienić kilka innych możliwości.
- Sentinel stale monitoruje stan węzłów głównych i podrzędnych w systemie Redis.
- Za każdym razem, gdy wystąpi awaria lub coś nie tak z twoimi instancjami Redis, strażnik jest w stanie powiadomić administratora lub połączone aplikacje za pomocą sentinel API.
- Faza przełączania awaryjnego jest kierowana przez wartownika, promując replikę jako nowego mastera. Pozostałe repliki skonfigurowane do korzystania z nowego wzorca. Na koniec, odpowiedni klienci zostaną powiadomieni o nowym adresie węzła głównego.
- Ponadto strażnik Redis jest dostawcą konfiguracji dla podłączonych klientów, gdzie klienci mogą poprosić o adres aktualnie dostępnej instancji głównej, a jeśli nastąpi nagłe załamanie, strażnik jest zobowiązany do natychmiastowego wypchnięcia nowego adresu węzła głównego.
W następnej sekcji będziemy konfigurować Sentinel Redis z instancjami master-replica i używać Sentinel API do monitorowania węzłów.
Konfiguracja Sentinel
Najpierw tworzymy dwie instancje Redis na portach 7000 i 7001. Port 7000 będzie węzłem głównym, a drugi będzie replikował węzeł nadrzędny. Obie instancje używają odpowiednio następujących plików konfiguracyjnych:
Konfiguracja węzła głównego
Port 7000z obsługą klastra nie
plik konfiguracyjny klastra nodes.conf
limit czasu węzła klastra 5000
tylko dołączyć tak
Konfiguracja węzła podrzędnego
Port 7001z obsługą klastra nie
plik konfiguracyjny klastra nodes.conf
limit czasu węzła klastra 5000
tylko dołączyć tak
Obie instancje rozpoczną się od dostarczenia pliku konfiguracyjnego skojarzonego z każdym. Możemy użyć następującego polecenia, aby osobno uruchomić instancje Redis:
redis-server redis.conf
Połączmy się z instancją Redis uruchomioną na porcie 7001 w następujący sposób:
redis-cli -p 7001
Teraz możemy uczynić tę instancję repliką mastera działającego na porcie 7000. Polecenie REPLICAOF może być użyte w następujący sposób:
replika 127.0.0.1 7000
Zgodnie z oczekiwaniami instancja działająca na porcie 7001 stała się węzłem repliki mastera działającego na porcie 7000.
Teraz jesteśmy gotowi do skonfigurowania trzech strażników Redis do monitorowania powyższej głównej instancji. Potrzebujemy trzech plików konfiguracyjnych, aby utworzyć trzy instancje wartownika na portach 5000, 5001 i 5002, jak pokazano poniżej.
Każdy wartownik.conf plik wygląda tak, jak poniżej, z tą różnicą, że zmieni się numer portu:
Port 5000Węzeł główny monitora wartownika 127.0.0.1 7000 dwa
wartownik wyłączony po milisekundach masternode 5000
masternode sentinel z limitem czasu pracy awaryjnej 60000
Teraz nadszedł czas na kierowanie trzema strażnikami. Możesz użyć pliku wykonywalnego redis-sentinel wraz ze ścieżką do: wartownik.conf plik konfiguracyjny, aby utworzyć instancję wartowniczą. W przeciwnym razie nadal możemy wywołać plik wykonywalny serwera redis, określając ścieżkę do wartownik.conf i flaga -strażnik .
Zacznijmy każdego wartownika za pomocą następującego polecenia:
redis-server sentinel.conf --strażnik
Pierwszy wartownik został uruchomiony na porcie 5000. Podobnie możesz uruchomić również pozostałe dwie instancje.
Teraz nasza konfiguracja strażnika Redis działa, jak pokazano na poniższej ilustracji:
W następnej sekcji będziemy odkrywać więcej o Sentinel API i jak możemy go wykorzystać do pobierania informacji związanych z węzłem głównym Redis.
Sentinel API
Redis zapewnia osobny interfejs wartownika do monitorowania powiązanych masterów i replik, subskrybowania powiadomień i modyfikowania ustawień wartownika. Ponadto poniżej wymieniono kilka zastosowań.
- Sprawdź stan monitorowanych instancji Redis master i slave
- Szczegóły dotyczące innych strażników
- Otrzymuj powiadomienia push od strażników w przypadku awarii
Komenda SENTINEL może być używana wraz z powiązanymi z nią podkomendami do wysyłania zapytań, aktualizacji lub ustawiania strażników Redis i monitorowanych węzłów.
Sprawdź stan węzła głównego
Bardzo ważne jest, aby od czasu do czasu monitorować lub sprawdzać stan węzła głównego. Następujące polecenie API sentinel może być użyte do pobrania szczegółów mastera:
MISTRZ STRAŻNIKA < monitorowane_nazwa_mastera >
monitorowana_nazwa_mastera: Nazwa węzła głównego określona w pliku konfiguracyjnym wartownika, który utworzyliśmy we wcześniejszym kroku.
Użyjmy tego polecenia, aby zapytać o status główny w naszej konfiguracji. W naszym przypadku nazwa węzła głównego to „masternode”.
Masternode SENTINEL MASTER
Odzyskano kilka informacji, a kilka z nich jest ważnych, takich jak num-slaves, flagi i num-other-stentinels.
The flagi właściwość jest ustawiona na gospodarz co oznacza, że mistrz jest w dobrym zdrowiu. Za każdym razem, gdy węzeł główny jest wyłączony, s_w dół lub o_w dół zostanie wyświetlona flaga. Własność liczni-inni-strażnicy jest ustawiony na 2, co oznacza, że wartownik Redis już rozpoznał dwóch pozostałych wartowników dla węzła głównego. Ponadto liczba-niewolników wyświetla dostępne repliki dla węzła głównego. W tym przypadku jest ustawiony na 1, ponieważ mamy tylko jedną replikę.
Uzyskaj informacje o połączonych replikach
Repliki połączone z węzłem głównym możemy sprawdzić za pomocą podkomendy SENTINEL:
REPLIKI WARTOWNIKÓW < monitorowane_nazwa_mastera >
W tym przykładzie nazwa główna to „masternode”.
SENTINEL repliki masternode
Zgodnie z oczekiwaniami Sentinel wykrył węzeł podrzędny działający na porcie 7001.
Uzyskaj informacje o powiązanych strażnikach
Podobnie możemy zapytać o szczegóły związane z innymi strażnikami powiązanymi z bieżącym węzłem głównym za pomocą następującej komendy SENTINEL:
WARTOWNICY WARTOWNICY < master_node_name >
W takim przypadku będziemy pobierać informacje związane z węzłem głównym o nazwie „masternode”.
SENTINEL Sentinel masternode
Uzyskaj adres węzła głównego
Jak wspomniano we wcześniejszej sekcji, Redis sentinel jest dostawcą konfiguracji dla podłączonych klientów. Dzięki temu jest w stanie dostarczyć żądanym klientom adres IP i port aktualnie działającego węzła głównego. Do pobrania wymienionych informacji można użyć następującej podkomendy Sentinel API.
STRAŻNIK GET-MASTER-ADDR-BY-NAME < master_node_name >
Wykonajmy powyższe polecenie dla naszego scenariusza w następujący sposób:
sentinel get-master-addr-by-name masternode
Omówiliśmy tylko kilka poleceń Sentinel API. Dostępnych jest kilka innych podkomend, takich jak sentinel-failover, sentinel info-cache, masters sentinel itp. Co więcej, wiele poleceń jest dostępnych również do celów administracyjnych. W następnej sekcji skupimy się na procesie przełączania awaryjnego Sentinel Redis.
Proces przełączania awaryjnego Sentinel
Ponieważ nasz wartownik jest skonfigurowany, możemy przetestować fazę przełączania awaryjnego. Uśpijmy nasz węzeł główny na 300 sekund, co symuluje awarię węzła głównego.
odpluskwić spać 300
Węzeł główny działający na porcie 7000 powinien być teraz niedostępny. Tak więc powiązani strażnicy zauważą, że mistrz jest niedostępny z +strzał wydarzenie. Następnie zostanie ustawiony na +odown gdzie 2 strażników potwierdza, że węzeł główny nie działa zgodnie z wartością kworum. Na koniec rozpocznie się faza przełączania awaryjnego i najlepiej byłoby, gdyby replika została awansowana do nowego mastera.
Sprawdźmy ponownie adres IP węzła głównego i port.
sentinel get-master-addr-by-name masternode
Zgodnie z oczekiwaniami, poprzednia replika została awansowana do nowego mastera, co oznacza, że proces przełączania awaryjnego wartownika zakończył się pomyślnie. Na tym kończy się wdrażanie i testowanie naszych trzech konfiguracji wartowniczych dla pojedynczej pary master-replika.
Wniosek
Redis sentinel to najbardziej niezawodne podejście do zapewnienia wysokiej dostępności danej instancji repliki głównej Redis. Strażnik jest w stanie monitorować, powiadamiać i inicjować automatyczne przełączanie awaryjne bez interwencji człowieka. Ponadto wielu strażników zgadza się, że węzeł główny jest nieosiągalny, a wartość kworum jest używana jako maksymalna liczba strażników, którą należy uzgodnić podczas sprawdzania dostępności instancji głównej. Redis sentinel oferuje łatwy w użyciu interfejs API do pobierania informacji o kondycji węzła głównego i powiązanych replik oraz wykonywania zadań administracyjnych.