Po pierwsze, Sentinel nie jest systemem równoważenia obciążenia ani serwerem proxy dla Redis.
Po drugie, nie wszystkie niepowodzenia są śmiercią gospodarza. Czasami serwer zawiesza się na chwilę, czasami kabel sieciowy zostaje odłączony itp. Z tego powodu uruchamianie Sentinel na tych samych hostach, co instancja Redis, nie jest dobrą praktyką. Jeśli używasz Sentinel do zarządzania przełączaniem awaryjnym, cokolwiek mniej niż trzech strażników działających na węzłach innych niż twój główny i podrzędny Redis prosi o kłopoty.
Sentinel używa mechanizmu kworum do głosowania na przełączenie awaryjne i urządzenie podrzędne. Mając mniej niż dwóch strażników, ryzykujesz rozszczepienie mózgu, gdy dwa lub więcej serwerów Redis uważa, że są mistrzami.
Wyobraź sobie scenariusz, w którym uruchamiasz dwa serwery i na każdym z nich uruchamiasz wartownika. Jeśli go zgubisz, stracisz niezawodną zdolność przełączania awaryjnego.
Klienci łączą się z Sentinel tylko w celu poznania informacji o bieżącym połączeniu głównym. Za każdym razem, gdy klient traci łączność, powtarza ten proces. Sentinel nie jest serwerem proxy dla Redis — polecenia dla Redis trafiają bezpośrednio do Redis.
Jedynym wiarygodnym powodem uruchomienia Sentinel z mniej niż trzema czujnikami jest wykrywanie usług, co oznacza nieużywanie go do zarządzania przełączaniem awaryjnym.
Rozważ scenariusz z dwoma hostami:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis slave + sentinel 2 (Quorum 1)
Jeśli host B tymczasowo utraci łączność sieciową z hostem A, w tym scenariuszu HostB awansuje na mastera. Teraz masz:
Host A: redis master + sentinel 1 (Quorum 1)
Host B: redis master + sentinel 2 (Quorum 1)
Każdy klient, który połączy się z Sentinel 2, zostanie poinformowany, że Host B jest masterem, podczas gdy klienci, którzy łączą się z Sentinel 1, otrzymają informację, że Host A jest masterem (co, jeśli masz Sentinel za systemem równoważenia obciążenia, oznacza połowę klientów).
Dlatego to, co musisz uruchomić, aby uzyskać minimalne akceptowalne niezawodne zarządzanie przełączaniem awaryjnym, to:
Host A: Redis master
Host B: Redis Slave
Host C: Sentinel 1
Host D: Sentinel 2
Host E: Sentinel 2
Twoi klienci łączą się ze strażnikami i uzyskują aktualny master dla instancji Redis (po nazwie), a następnie łączą się z nim. Jeśli master umrze, połączenie powinno zostać przerwane przez klienta, po czym klient połączy się/powinien ponownie połączyć się z Sentinelem i uzyskać nowe informacje.
To, jak dobrze każda biblioteka klienta to obsługuje, zależy od biblioteki.
Idealnie hosty C, D i E znajdują się na tych samych hostach, z których łączysz się z Redis (tj. na hoście klienta). lub reprezentują dobre pobieranie próbek. Głównym celem jest upewnienie się, że sprawdzasz, skąd chcesz połączyć się z Redis. Niepowodzenie powoduje umieszczenie ich w tym samym DC/Rack/Region co klienci.
Jeśli chcesz, aby Twoi klienci rozmawiali z load balancerem, spróbuj umieścić Sentinels na tych węzłach LB, jeśli to możliwe, dodając dodatkowe hosty nie-LB w razie potrzeby, aby uzyskać nieparzystą liczbę strażników> 2. Wyjątkiem od tego jest sytuacja, gdy hosty klienckie są dynamiczne, ponieważ ich liczba jest niespójna (na przykład skalują się w górę dla ruchu, w dół dla wolnych okresów). W tym scenariuszu musisz uruchomić Sentinels na hostach niebędących klientami i serwerami redis.
Zauważ, że jeśli to zrobisz, będziesz musiał napisać demona, który monitoruje kanał Sentinel PUBSUB pod kątem zdarzenia przełącznika głównego, aby zaktualizować LB, który musisz skonfigurować tak, aby rozmawiał tylko z bieżącym masterem (nigdy nie próbuj rozmawiać z obydwoma). Jest to bardziej pracochłonne, ale sprawia, że Sentinel jest przezroczysty dla klienta - który wie, że ma rozmawiać tylko z adresem IP/portem LB.
