Redis Sentinel vs Clustering

Rozumiem, że redis sentinel to sposób konfigurowania HA (wysoka dostępność) między wieloma instancjami redis. Jak widzę, w danym momencie istnieje jedna instancja redis aktywnie obsługująca żądania klientów. Istnieją dwa dodatkowe serwery w stanie gotowości (czekają na awarię, więc jeden z nich może znowu działać).

• Czy to marnowanie zasobów?
• Czy istnieje lepszy sposób na pełne wykorzystanie dostępnych zasobów?
• Czy klastrowanie Redis jest alternatywą dla Redis Sentinel?

Sprawdziłem już dokumentację redis dotyczącą wartownika i grupowania , czy ktoś z doświadczeniem może to wyjaśnić.

AKTUALIZACJA

DOBRZE. W moim prawdziwym scenariuszu wdrożenia mam dwa serwery dedykowane dla redis. Mam inny serwer, na którym działa mój serwer Jboss. Aplikacja działająca w Jboss jest skonfigurowana do łączenia się z serwerem głównym redis (M).

Scenariusz pracy awaryjnej

Idealnie, myślę, że kiedy serwer pamięci podręcznej Master ulegnie awarii (nastąpi awaria procesu Redis lub awaria komputera), aplikacja w Jboss musi połączyć się z serwerem pamięci podręcznej Slave. Jak skonfigurowałbym serwery redis, aby to osiągnąć?

+--------+          +--------+
| Master  |---------| Slave  |
|         |         |        |
+--------+          +--------+

Configuration: quorum = 1

Najpierw porozmawiajmy wartowniku.

Sentinel zarządza przełączaniem awaryjnym, nie konfiguruje Redis dla HA. To ważne rozróżnienie. Po drugie, opublikowany diagram jest w rzeczywistości złą konfiguracją - nie chcesz uruchamiać Sentinela na tym samym węźle, co węzły Redis, którymi zarządza. Kiedy tracisz tego hosta, tracisz jedno i drugie.

Jeśli chodzi o pytanie „Czy to marnowanie zasobów?” to zależy od twojego przypadku użycia. Nie potrzebujesz trzech węzłów Redis w tej konfiguracji, potrzebujesz tylko dwóch. Trzy zwiększa twoją redundancję, ale nie jest to wymagane. Jeśli potrzebujesz dodatkowej redundancji, nie jest to marnowanie zasobów. Jeśli nie potrzebujesz nadmiarowości, po prostu uruchom jedną instancję Redis i nazwij ją dobrą - ponieważ uruchamianie większej ilości byłoby „zmarnowane”.

Innym powodem prowadzenia dwóch niewolników byłoby podzielenie odczytów. Ponownie, jeśli tego potrzebujesz, nie byłoby to marnotrawstwem.

Jeśli chodzi o pytanie „Czy istnieje lepszy sposób na pełne wykorzystanie dostępnych zasobów?” nie możemy na to odpowiedzieć, ponieważ jest to zbyt zależne od konkretnego scenariusza i kodu. To powiedziawszy, jeśli ilość danych do przechowywania jest „mała”, a szybkość poleceń nie jest zbyt wysoka, pamiętaj, że nie musisz poświęcać hosta dla Redis.

Teraz pytanie „Czy tworzenie klastrów Redis jest alternatywą dla wartownika Redis?”. To naprawdę zależy całkowicie od twojego przypadku użycia. Klaster Redis nie jest rozwiązaniem wysokiej dostępności - jest to rozwiązanie z wieloma modułami zapisującymi / większe niż pamięć RAM. Jeśli Twoim celem jest tylko HA, prawdopodobnie nie będzie dla Ciebie odpowiedni. Klaster Redis ma pewne ograniczenia, zwłaszcza dotyczące operacji z wieloma kluczami, więc niekoniecznie jest to prosta operacja „po prostu użyj klastra”.

Jeśli uważasz, że posiadanie trzech hostów z systemem Redis (i trzech działających wartownikiem) jest marnotrawstwem, prawdopodobnie będziesz utrzymywać Cluster jeszcze bardziej, ponieważ wymaga więcej zasobów.

Pytania, które zadałeś, są prawdopodobnie zbyt szerokie i oparte na opiniach, aby przetrwać tak, jak zostały napisane. Jeśli masz konkretny przypadek / problem, nad którym pracujesz, zaktualizuj go, abyśmy mogli zapewnić konkretną pomoc i informacje.

Zaktualizuj szczegółowe informacje:

Dla prawidłowego zarządzania przełączaniem awaryjnym w twoim scenariuszu wybrałbym 3 wartowników, z których jeden działa na serwerze JBoss. Jeśli masz 3 węzły JBoss, użyj po jednym na każdym. Miałbym pod Redis (master + slave) na oddzielnych węzłach i pozwoliłbym strażnikowi zarządzać przełączaniem awaryjnym.

Stamtąd jest kwestia podłączenia JBoss / Jedis do korzystania z Sentinel do zarządzania informacjami i połączeniami. Ponieważ nie używam ich, szybko wyszukuję, że Jedis ma do tego wsparcie, wystarczy je poprawnie skonfigurować. Kilka przykładów, które znalazłem, to Poszukiwanie przykładu Jedis z Sentinelem i https://github.com/xetorthio/jedis/issues/725, które mówią oJedisSentinelPool byciu drogą do korzystania z puli.

Kiedy Sentinel wykona przełączenie awaryjne, klienci zostaną odłączeni, a Jedis (powinien?) Zająć się ponownym połączeniem, pytając Strażników, kto jest obecnym panem.

Wszędzie zaleca się rozpoczęcie od nieparzystej liczby wystąpień, a nie dwóch lub wielokrotności dwóch. To zostało poprawione, ale poprawmy kilka innych punktów.

Po pierwsze, stwierdzenie, że Sentinel zapewnia przełączanie awaryjne bez HA, jest fałszywe. W przypadku przełączania awaryjnego masz wysoką dostępność z dodatkową korzyścią wynikającą z replikacji stanu aplikacji. Różnica polega na tym, że można mieć HA w systemie bez replikacji (jest to HA, ale nie jest odporny na błędy).

Po drugie, uruchomienie wartownika na tej samej maszynie, co jej docelowa instancja redis nie jest „złą konfiguracją”: jeśli stracisz wartownika, instancję redis lub całą maszynę, wyniki będą takie same. Prawdopodobnie dlatego każdy przykład takich konfiguracji pokazuje, że obie działają na tej samej maszynie.

To nie jest bezpośrednia odpowiedź na twoje pytanie, ale pomyśl, to pomocna informacja dla początkujących użytkowników Redis, takich jak ja. Również to pytanie pojawia się jako pierwszy link w google podczas wyszukiwania „Redis cluster vs sentinel”.

Redis Sentinel to nazwa rozwiązania Redis o wysokiej dostępności ... Nie ma ono nic wspólnego z Redis Cluster i jest przeznaczone do użytku przez osoby, które nie potrzebują klastra Redis, ale po prostu sposób na automatyczne przełączanie awaryjne, gdy master wystąpienie nie działa poprawnie.

Zaczerpnięte z wersji roboczej projektu Redis Sentinel 1.3

Nie jest to oczywiste, gdy jesteś nowy w Redis i wdrażasz rozwiązanie awaryjne. Oficjalne dokumentacje o wartowniku i klastrach nie są ze sobą porównywalne, więc trudno jest wybrać właściwą drogę bez czytania wielu dokumentów.

To jest moje zrozumienie po uderzeniu głową w całą dokumentację.

Sentinel to rodzaj rozwiązania typu hot standby, w którym niewolnicy są replikowani i gotowi do awansu w dowolnym momencie. Jednak nie będzie obsługiwać żadnych zapisów w wielu węzłach. Slave można skonfigurować do operacji odczytu. NIE jest prawdą, że Sentinel nie zapewni HA, ma wszystkie cechy typowego klastra aktywno-pasywnego (choć nie jest to właściwy termin do użycia w tym miejscu).

Klaster Redis to mniej więcej rozwiązanie rozproszone, działające na fragmentach. Każdy fragment danych jest dystrybuowany między węzłami nadrzędnymi i podrzędnymi. Minimalny współczynnik replikacji wynoszący 2 zapewnia, że ​​masz dostępne dwa aktywne fragmenty między serwerem master i slave. Jeśli znasz sharding w Mongo lub Elasticsearch, łatwo będzie nadrobić zaległości.

Redis może działać w podzielonym na partycje klastrze (z wieloma nadrzędnymi i podrzędnymi urządzeniami nadrzędnymi) lub w trybie pojedynczej instancji (jeden serwer główny z replikami podrzędnymi). Link tutaj mówi:

W przypadku korzystania z Redis w trybie pojedynczego wystąpienia, w którym jeden serwer Redis zarządza całą niepartycjonowaną bazą danych, Redis Sentinel jest używany do zarządzania jej dostępnością

Mówi również:

Klaster Redis, w którym dane są podzielone na wiele wystąpień podstawowych, sam zarządza dostępnością i nie wymaga dodatkowych składników.

Tak więc HA można zapewnić w 2 wspomnianych scenariuszach. Mam nadzieję, że to wyjaśnia wątpliwości. Klaster Redis i wartownicy nie są dla siebie alternatywą. Są one używane tylko do zapewnienia wysokiej dostępności w różnych przypadkach partycjonowanego lub niepartycjonowanego mastera.

Redis Sentinel wykonuje repliki promujące przełączanie awaryjne, gdy widzą, że master nie działa. Zwykle potrzebujesz nieparzystej liczby węzłów wartowniczych. Na przykład jednego wzorca i jednej repliki należy użyć 3 wartowników, aby uzyskać konsensus w sprawie decyzji. Idealnie, trzeci wartownik znajduje się na trzecim serwerze, więc decyzja nie jest wypaczona (w zależności od niepowodzenia). Sentinel dba o zmianę ustawień konfiguracji master / replica w twoich węzłach, tak aby promocja i synchronizacja odbywały się we właściwej kolejności i nie nadpisywał danych, wprowadzając stary uszkodzony wzorzec, który teraz zawiera starsze dane.

Po skonfigurowaniu węzłów wartowniczych do wykonywania przełączeń awaryjnych należy upewnić się, że wskazujesz właściwą instancję. Zobacz przykład konfiguracji HAProxy . HAProxy przeprowadza testy kondycji i w przypadku awarii wskaże nowy wzorzec.

Tworzenie klastrów umożliwia skalowanie w poziomie i może pomóc w obsłudze dużych obciążeń. Konfiguracja i konfiguracja z góry zajmuje trochę pracy.

W Redis istnieje rozwidlenie typu open source, „KeyDB”, które wyeliminowało potrzebę węzłów wartowniczych z opcją aktywnej repliki. Dzięki temu węzeł repliki może akceptować odczyty i zapisy. Gdy nastąpi przełączenie awaryjne, HAProxy zatrzymuje odczyty / zapisy z uszkodzonym węzłem i po prostu wykorzystuje pozostały aktywny węzeł, który jest już zsynchronizowany. Znacznik czasu umożliwia automatyczne ponowne dołączenie węzłów, które uległy awarii, i ponowną synchronizację bez utraty danych, gdy powrócą do trybu online. Konfiguracja jest prosta, a dla większego ruchu nie potrzebujesz specjalnej konfiguracji z góry, aby kierować odczyty do węzła repliki i odczytywać / zapisywać do mastera. Zobacz przykład aktywnej replikacji tutaj . KeyDB jest również wielowątkowy, co dla niektórych aplikacji może być alternatywą dla klastrowania, ale tak naprawdę zależy od Twoich potrzeb.

Istnieje również przykład ręcznego konfigurowania klastrowania za pomocą narzędzia do tworzenia klastrów . To są te same kroki, jeśli używasz Redis (zamień „keydb” na „redis” w instrukcji)

Dodatkowe informacje do powyższych odpowiedzi

Klaster Redis

• Jednym z głównych celów klastra Redis jest równomierne / równomierne rozłożenie obciążenia danych przez fragmentowanie

• Klaster Redis nie używa spójnego haszowania, ale inną formę dzielenia na fragmenty, w której każdy klucz jest koncepcyjnie częścią tego, co nazywa się miejscem skrótu

• W klastrze Redis jest 16384 gniazd na skróty, każdy węzeł w klastrze Redis jest odpowiedzialny za podzbiór gniazd na skróty, więc na przykład możesz mieć klaster z 3 węzłami, gdzie:

  Węzeł A zawiera sloty hash od 0 do 5500, Node B zawiera sloty hash od 5501 do 11000, Node C zawiera sloty hash od 11001 do 16383

Dzięki temu możemy łatwo dodawać i usuwać węzły w klastrze. Na przykład, jeśli chcemy dodać nowy węzeł D, musimy przenieść część haszowania z węzłów A, B, C do D

• Klaster Redis obsługuje strukturę master-slave, możesz tworzyć slave'y A1, B1, C2 wraz z master A, B, C podczas tworzenia klastra, więc gdy master B ulegnie awarii, slave B1 zostanie promowany jako master

Nie potrzebujesz dodatkowej obsługi przełączania awaryjnego podczas korzystania z klastra Redis i zdecydowanie nie powinieneś wskazywać instancji Sentinel na żadnym z węzłów klastra.

A więc w praktyce, co zyskujesz dzięki Redis Cluster?

1. możliwość automatycznego dzielenia zbioru danych na wiele węzłów.

2. Możliwość kontynuowania operacji, gdy podzbiór węzłów ma awarie lub nie może komunikować się z resztą klastra.

Redis Sentinel

• Redis obsługuje wiele urządzeń podrzędnych replikujących dane z węzła głównego.
• Zapewnia to kopię zapasową danych w węźle głównym.
• Redis Sentinel to system przeznaczony do zarządzania urządzeniami typu master i slave. Działa jako oddzielny program. Minimalna liczba wartowników wymagana w idealnym systemie to 3. Komunikują się między sobą i upewniają się, że Mistrz żyje, jeśli nie żyje, promują jednego z niewolników na pana, więc później, gdy martwy węzeł się obróci, będzie działając jako niewolnik nowego pana
• Kworum jest konfigurowalne. Zasadniczo jest to liczba wartowników, którzy muszą się zgodzić, gdy kapitan upadnie. N / 2 +1 powinien się zgodzić. N to liczba węzłów w pod (uwaga: ta konfiguracja nazywa się kapsułą i nie jest klastrem)

A więc w praktyce, co zyskujesz dzięki Redis Sentinel?

Zapewni to, że Mistrz jest zawsze dostępny (jeśli mistrz upadnie, niewolnik zostanie promowany jako mistrz)

Odniesienie :

https://fnordig.de/2015/06/01/redis-sentinel-and-redis-cluster/

https://redis.io/topics/cluster-tutorial