Certyfikaty Multi-Domain

W pierwszej kolejności wyjaśnijmy czym jest certyfikat typu multi-domain, ponieważ to za jego pomocą jesteśmy w stanie z poziomu jednego certyfikatu chronić wiele różnych domen. Certyfikat typu multi-domain (certyfikat wielodomenowy) zabezpiecza unikalne nazwy domen lub subdomen wymienione w polu SAN, dzięki czemu daje pełną kontrolę nad wartościami tego rozszerzenia. Taki certyfikat pozwala także na obsługę wielu nazw wieloznacznych wraz z pojedynczymi nazwami domen (umożliwiają zabezpieczenie tylu subdomen, ile potrzebujesz w wielu domenach, a wszystko to w ramach jednego certyfikatu SSL).

W tym drugim przypadku możemy się spotkać z tzw. wielodomenowym certyfikatem nazw wieloznacznych (ang. Multi-Domain Wildcard Certificate). Moim zdaniem jest to po prostu certyfikat typu multi-domain, w którym obok standardowych nazw domen możemy umieścić nazwy wieloznaczne.

Główną różnicą między certyfikatami typu multi-domain a certyfikatami typu wildcard (certyfikat wieloznaczny) jest to, że ten drugi zabezpiecza tylko subdomeny w obrębie domeny głównej.

Poniższa grafika przedstawia różnice:

Więcej na temat tego obu typów certyfikatów przeczytasz w artykule What Is the Difference Between Multi-Domain and Wildcard Certificates?.

Maksymalna ilość domen w rozszerzeniu SAN

Przyjmijmy, że dostałeś zlecenie wygenerowania CSR dla 500 domen. Jak myślisz, czy w ogóle jest możliwa ochrona takiej ich liczby za pomocą jednego certyfikatu? Teoretycznie, idąc za RFC 5280 - 4.2.1.6. Subject Alternative Name ^[IETF], nie ma jasno określonego limitu ilości domen:

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

Organ standaryzacyjny nie zdefiniował górnej wartości, co zostało dodatkowo opisane w tym samym RFC w części Appendix B. ASN.1 Notes ^[IETF]:

The SIZE (1..MAX) construct constrains the sequence to have at least one entry. MAX indicates that the upper bound is unspecified. Implementations are free to choose an upper bound that suits their environment.

Spójrzmy zatem jak to wygląda z poziomu biblioteki OpenSSL. Podczas procesu uzgadniania serwer może wysłać łańcuch certyfikatów (składający się maksymalnie z 10 certyfikatów), przy czym standard TLS/SSL nie podaje żadnego maksymalnego rozmiaru tego łańcucha. Biblioteka obsługuje dane przychodzące przez dynamicznie przydzielany bufor i wykorzystuje tylko pamięć faktycznie wymaganą. Jednak aby zapobiec powiększaniu się tego bufora bez ograniczeń, został ustawiony maksymalny rozmiar łańcucha certyfikatów, który wynosi 100 KB (typowe certyfikaty bez specjalnych rozszerzeń mają rozmiar ok. 1,5 KB więc przy łańcuchu składającym się z 3 certyfikatów rozmiar wyniesie ok, 4,5 KB).

Jeśli maksymalny dozwolony rozmiar łańcucha certyfikatów zostanie przekroczony, uzgadnianie zakończy się niepowodzeniem z błędem SSL_R_EXCESSIVE_MESSAGE_SIZE.

Z drugiej strony dostawcy certyfikatów nakładają własne ograniczenia (głównie ze względu na implementacje). Organizacja Let’s Encrypt ustaliła limit na 100 domen na certyfikat (patrz: Let’s Encrypt - Rate Limit), podobnie GoDaddy czy GlobalSign. Jeszcze inni dostawcy pozwalają na wskazanie nawet do 250 domen (Digicert) natomiast Comodo/Sectigo pozwala na wygenerowanie certyfikatu obsługującego do 1000 domen za pomocą Positive Multi Domain SSL Certificate (co ciekawe Sectigo reklamuje możliwość obsługi 2000 domen).

Innymi ograniczeniami są także ograniczenia konstrukcyjne. Wymiana certyfikatów jest podstawą uzgadniania TLS i jest zwykle obsługiwana przez izolowane fragmenty kodu, aby zminimalizować powierzchnię ataku. Ze względu na swój niskopoziomowy charakter bufory zwykle nie są przydzielane dynamicznie, ale są stałe. W ten sposób nie możemy po prostu założyć, że klient może obsłużyć certyfikat o nieograniczonej wielkości.

Na przykład przeglądarka Chrome odrzuci certyfikat większy niż 64 KB (cert_issuer_source_aia.cc). Z kolei urząd certyfikacji działający w systemie Windows Server może obsłużyć certyfikaty o rozmiarze do 4096 bajtów, w których umieszczane są alternatywne nazwy podmiotu (SAN). Jest to związane z całkowitym rozmiarem dowolnego zakodowanego rozszerzenia, który jest ograniczony właśnie do 4 KB, ponieważ jest to maksymalny rozmiar pola bazy danych zgodnie z definicją schematu bazy danych urzędu certyfikacji. Każde żądanie, które przekracza ten limit, zostanie odrzucone i żaden certyfikat nie zostanie wydany.

Co ciekawe, przeglądarki Chrome oraz Firefox w pełni poprawnie obsługuję certyfikaty posiadające aż 1000 nazw domen. Z poziomu narzędzia openssl jesteśmy oczywiście w stanie wyłuskać wszystkie domeny oraz ich liczbę:

echo | openssl s_client -connect 1000-sans.badssl.com:443 2>&1 | \
openssl x509 -noout -text | \
perl -l -0777 -ne '@names=/\bDNS:([^\s,]+)/g; print join("\n", sort @names);' | wc -l
1000

Możemy także sprawdzić rozmiar w bajtach wszystkich certyfikatów w łańcuchu:

echo | openssl s_client -showcerts -connect 1000-sans.badssl.com:443 2>&1 | \
sed -n -e '/-.BEGIN/,/-.END/ p' | wc -c
40413

A także certyfikatu serwera:

echo | openssl s_client -connect 1000-sans.badssl.com:443 2>&1 | \
sed -n -e '/-.BEGIN/,/-.END/ p' | wc -c
38766

Natomiast to, ile bajtów mają wszystkie domeny umieszczone w rozszerzeniu SAN, możemy sprawdzić za pomocą:

echo | openssl s_client -connect 1000-sans.badssl.com:443 2>&1 | \
openssl x509 -noout -text | grep "DNS:" | wc -c
30905

W powyższym przykładzie widać, że ok. 40 KB danych zostało przesłanych tylko po to, aby nawiązać bezpieczne połączenie, z czego ok. 30 KB pochodzi z certyfikatu serwera dla rozszerzenia SAN. W ramach ciekawostki możesz sprawdzić, jak wygląda certyfikat serwera, wykonując poniższą komendę:

echo | openssl s_client -connect 1000-sans.badssl.com:443 2>&1 | \
openssl x509 -text | sed -n -e '/-.BEGIN/,/-.END/ p'

Z kolei LibreSSL nie wyświetla wszystkich domen z pola SAN, jedynie pierwszą z nich (być może należy podać odpowiedni parametr).

Poniżej znajduje się dokładny przykład takiej komunikacji, którą możesz zresztą samemu wygenerować, wchodząc na stronę 1000-sans.badssl.com i podsłuchując ruch narzędziem Wireshark:

W powyższym zrzucie warto zwrócić uwagę na kilka rzeczy. Certyfikat posiadający 1000 alternatywnych nazw domen, jest dzielony na fragmenty. Wydawać by się mogło, że limitem powinien być rozmiar rekordu TLS wynoszący najczęściej 16 KB, jednak ze względu na fragmentację TLS (jeśli certyfikat jest za duży, musisz objąć wiele pakietów) istnieje możliwość przesyłania certyfikatów o większych rozmiarach. W tym przykładzie widzimy dwa fragmenty o rozmiarach 16384 bajtów oraz 13390 bajtów co daje łącznie 29774 bajtów. Natomiast same certyfikaty przesłane przez serwer (łańcuch certyfikatów), mają rozmiar 29767 bajtów, gdzie certyfikat z 1000 nazw domen ma rozmiar 29767 bajtów.

Co ciekawe, serwis badssl.com udostępnia domenę, której certyfikat zawiera 10000 nazw zawartych w rozszerzeniu SAN! Testowa domena jest dostępna pod adresem 10000-sans.badssl.com jednak gdy próbowałem przetestować ją z poziomu większości popularnych przeglądarek, za każdym razem otrzymałem błąd. Narzędzie openssl także zwróciło błąd komunikacji:

echo | openssl s_client -connect 10000-sans.badssl.com:443
CONNECTED(00000005)
140449241773824:error:14160098:SSL routines:read_state_machine:excessive message size:ssl/statem/statem.c:600:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 16459 bytes and written 330 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1643497429
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

Idąc za powyższym zrzutem komunikacji i błędem, fragment odpowiedzialny za zwrócenie wyjątku wygląda jak poniżej:

if (s->s3->tmp.message_size > max_message_size(s)) {
    SSLfatal(s, SSL_AD_ILLEGAL_PARAMETER, SSL_F_READ_STATE_MACHINE,
             SSL_R_EXCESSIVE_MESSAGE_SIZE);
    return SUB_STATE_ERROR;
}

Rozmiar pola SAN a wydajność

Podczas procesu uzgadniania TLS serwer dołącza swój certyfikat, który jest następnie weryfikowany przez klienta przed kontynuowaniem. W tej wymianie certyfikatów serwer najczęściej przedstawia łańcuch certyfikatów, za pomocą którego można go zweryfikować. Po tej wymianie ustanawiane są dodatkowe klucze do szyfrowania komunikacji. Jednak długość i rozmiar certyfikatu może negatywnie wpłynąć na wydajność samej negocjacji, a w niektórych przypadkach spowodować awarię bibliotek klienta.

W związku z tym co przed chwilą powiedzieliśmy, należy pamiętać o wydajności i o tym, że certyfikaty są największą częścią podczas uścisku dłoni protokołu TLS. Na wydajność uzgadniania TLS ma wpływ wiele czynników. Należą do nich rozmiar rekordu RTT, TLS i rozmiar certyfikatu TLS. Podczas gdy RTT ma największy wpływ na uzgadnianie TLS, drugim największym czynnikiem wpływającym na wydajność protokołu TLS jest rozmiar certyfikatów a najczęściej rozmiar certyfikatu serwera.

Im więcej nazw w rozszerzeniu SAN, tym większy certyfikat. Przetwarzanie tych nazw podczas weryfikacji powoduje pogorszenie wydajności, jednak co należy wyraźnie podkreślić, wydajność rozmiaru certyfikatu nie dotyczy narzutu TCP, a raczej wydajności przetwarzania po stronie klienta. Optymalizacją na pewno jest ograniczenie liczby nazw domen do minimum, dzięki czemu zmniejszymy liczbę podróży w obie strony powodując szybsze negocjacje TLS.

Posiadanie wielu domen w certyfikacie zwiększy rozmiar certyfikatu, który będzie musiał być dostarczany dla każdej nowej sesji użytkownika, przez co negocjacje TLS będą musiały obejmować wiele pakietów i wiele podróży w obie strony, co może skutkować spadkiem wydajności całej komunikacji (serwery mają też tendencję do wysyłania pełnego łańcucha certyfikatów do klienta). Co ważne, wszystkie pakiety muszą zostać odebrane i ponownie złożone przed wysłaniem jakiegokolwiek żądania HTTP co wprowadza kolejne opóźnienia. Dodatkowo należy liczyć się z możliwością utraty pakietów, co wprowadzi kolejne opóźnienia.

Możesz zadać teraz pytanie: w takim razie ,jaka jest optymalna ilość nazw w rozszerzeniu SAN, tak aby nie odczuć spadku wydajności? Moim zdaniem ciężko powiedzieć. Zakładając wspólny 1500-bajtowy rozmiar MTU, pozostawia to ok. 1400 bajtów dla rekordu TLS dostarczonego przez IPv4 (patrz: NGINX: Optymalizacja sesji SSL/TLS). Gdy mamy 1000 domen obsługiwanych przez certyfikat, w typowym scenariuszu tylko 1-2% z nich zostanie wysłanych w pierwszym pakiecie. Biorąc pod uwagę, dodatkowe rozszerzenia oraz pozostałe aspekty, rozmiary certyfikatów będą się różnić, stąd ciężko jest podać wskazówki dotyczące dokładnej liczby nazw, które powinny być zawarte w certyfikacie.

W kontekście wydajności warto wspomnieć jeszcze o sieciach CDN i usługodawcach takich jak Cloudflare, Fastly czy Akamai, którzy równoważą potrzebę wdrożenia współdzielonych certyfikatów i wydajności. Większość z nich ogranicza liczbę nazw w polu SAN między 100 a 150, jednak ten limit oczywiście najczęściej wynika z ograniczeń dostawców certyfikatów. To z kolei umożliwia niektórym dostawcom CDN na przekroczenie pewnych limitów, tworząc ponad 800 domen na jednym certyfikacie.

Rozszerzenie SAN a bezpieczeństwo

Na koniec warto wspomnieć jeszcze o jednej kwestii, mianowicie bezpieczeństwie. Może się zdarzyć, że będziemy chcieli za pomocą jednego certyfikatu obsłużyć np. wiele domen dla wielu klientów albo dla wielu klientów jednego klienta. W takim przypadku certyfikat może zawierać dziesiątki innych nazw domen objętych tym samym certyfikatem.

Musisz się zastanowić czy jest to pożądane rozwiązanie oraz mieć świadomość możliwości łatwej enumeracji pola SAN przez atakującego. Dla przykładu serwis StackOverflow.com przedstawia się certyfikatem zawierającym poniższe domeny w rozszerzeniu SAN:

Badanie nazw alternatywnych jest rutynową technikom pozyskiwania informacji oraz jedną z podstawowych części enumeracji. Rozszerzenie SAN pomaga znaleźć powiązane domeny i usługi, często hostowane w tej samej sieci lub na tym samym serwerze. Bardzo często wskazują na nieaktualne lub nieistniejące już domeny, które mogą być lub zostały przejęte przez innych. Oczywiście jeden certyfikat dla wielu domen to niewątpliwie ogromna wygoda, ponieważ musimy się martwić tylko o aktualizację jednego certyfikatu dla różnych domen.

Czym jest nagłówek Referer?

Nagłówek Referer jest opcjonalnym nagłówkiem żądania protokołu HTTP przechowującym adres poprzedniej (ostatnio przeglądanej) strony internetowej, która jest połączona z bieżącą witryną lub żądanym zasobem. Został on zdefiniowany w RFC 2616 Hypertext Transfer Protocol – HTTP/1.1 - 14.36 Referer ^IETF oraz RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content ^IETF.

Nagłówek Referer określa miejsce pochodzenia klienta a jego wartością jest adres URL poprzedniej strony, która łączyła się z nowo żądaną stroną. Co ciekawe, jest on w rzeczywistości błędną pisownią słowa „referrer”, ponieważ w samym RFC z 1996 roku nazwa „referer” została wprowadzona w pierwotnej propozycji przez Phillipa Hallama-Bakera, co nie zostało zmienione w późniejszych specyfikacjach.

Idąc za RFC 2616, składnia tego nagłówka jest następująca:

Referer = "Referer" ":" ( absoluteURI | relativeURI )

Mówiąc prościej, jego forma wygląda najczęściej tak (Referer: <url>):

Referer: https://www.google.com/

Nagłówek ten zawiera adres strony wysyłającej żądanie (wskazuje źródło lub adres URL strony internetowej, z której wykonano żądanie). Jeśli przechodzisz z jednej strony na drugą, nagłówek ten będzie zawierał adres pierwszej strony. Na przykład, gdy jedna witryna internetowa łączy się z inną witryną, pierwsza z nich odsyła użytkownika do drugiej. Zazwyczaj ta informacja jest przechwytywana właśnie w nagłówku Referer. Dzięki temu, po sprawdzeniu strony odsyłającej, nowa strona może zobaczyć, skąd pochodzi żądanie. Widzimy, że nagłówek ten umożliwia serwerom identyfikację źródła żądania (a tym samym skąd klienci odwiedzają strony, na które wchodzą).

Zgodnie z Mozilla Web technology for developers, gdy podążasz za linkiem, nagłówek ten przechowywać będzie adres URL strony zawierającej łącze. Gdy wyślesz żądania AJAX do innej domeny, nagłówek Referer będzie zawierał adres URL Twojej strony. W najczęstszej sytuacji oznacza to, że gdy użytkownik kliknie hiperłącze w przeglądarce internetowej, przeglądarka wysyła żądanie do serwera, na którym znajduje się docelowa strona internetowa. Żądanie może zawierać nagłówek Referer, który wskazuje ostatnią stronę, na której znajdował się użytkownik (tę, na której kliknął link).

Spójrzmy na poniższy przykład:

Kiedy użytkownik wejdzie na odnośnik w sekcji archiwa, w rzeczywistości do żądania wysłanego przez przeglądarkę dołączona zostanie informacja dotycząca miejsca, z którego przyszedł klient. W tym przypadku Referer jest ustawiony na http://192.168.78.157, ponieważ użytkownik znajduje się obecnie na tym adresie.

Następnie klient zostanie przeniesiony pod nowy zasób. Teraz gdy znajduje się on na stronie „Archives”, jeśli kliknie jakiekolwiek łącze na tej stronie, nagłówek Referer zostanie ustawiony na adres URL zasobu „Archives” — czyli przyjmie wartość http://192.168.78.157/index.php/2019/12/.

Przejdźmy w takim razie dalej. Wiemy już czym jest nagłówek Referer, wiemy też, jak działa. Jednak możemy zadać pytanie czy ma on jakieś istotne zastosowania? Nagłówek ten jest wysyłany z przeglądarki do serwera, aby poinformować Cię, na której stronie znajdował się klient przed przejściem do Twojej witryny. Informacje te mogą być wykorzystywane do dostarczania specjalnych ofert ukierunkowanych na odwiedzających, przekierowywania klientów w specjalnie przygotowane miejsca lub grupowania odwiedzających według określonych kryteriów.

Ponadto wykorzystanie tego nagłówka może przydać się w celach statystycznych, ponieważ właściciel witryny ma możliwość dowiedzenia się, jakie zapytania i jak często są wykonywane przez użytkowników serwisu.

Czy użycie tego nagłówka jest bezpieczne?

Dochodzimy do głównego problemu. Chociaż nagłówek Referer ma wiele niewinnych zastosowań, jego użycie zwiększa ryzyko naruszenia prywatności i bezpieczeństwa w kontekście danej strony.

Na przykład, jeśli zezwolisz witrynie foo.bar.com na pobieranie zasobów z domeny example.com, użytkownicy będą mogli kliknąć łącze example.com w witrynie foo.bar.com i przejść do tej strony. Niestety, bez odpowiednich reguł filtrujących każdy będzie mógł połączyć się z Twoją stroną. Jeśli atakujący umieści na spreparowanej stronie znajdującej się pod domeną examplle.com odwołania do static.example.com, która jest domeną na pliki statyczne dla example.com, będzie w stanie serwować wszystkie statyczne zasoby z Twojej domeny.

Inną problematyczną sytuacją jest tzw. spam odsyłający (ang. referer spam) nazywany inaczej spamem dzienników, którego głównym celem jest generowanie ruchu internetowego. Takie ataki mogą pojawiać się falami, a żądania generowane są zwykle dziesiątki lub setki razy. W specyficznych warunkach ten typ spamu może generować wiele żądań na sekundę, co pozwala wysycić łącza o niskiej przepustowości. Drugim problemem jest to, że każdy spam odsyłający jest prawie zawsze zapisywany w dziennikach serwera. Ponadto może dostać się do systemu analitycznego, żerując na Twoich rankingach.

Należy pamiętać, że sfabrykowanie żądania z odpowiednią wartością pola nagłówka Referer jest dość łatwe. Istnieją jednak bardziej problematyczne zastosowania, takie jak śledzenie lub kradzież informacji, a nawet nieumyślne ujawnienie poufnych danych. Problemy nasilają się, kiedy pełny adres URL zawierający ścieżkę i ciąg zapytania jest wysyłany między źródłami. Może to stanowić niezwykle poważne zagrożenie dla bezpieczeństwa, co zostało przedstawione na poniższej grafice:

Fałszowanie często umożliwia dostęp do zawartości witryny, w przypadku której serwer sieciowy jest jedynie skonfigurowany do blokowania przeglądarek, które nie wysyłają nagłówków odsyłaczy. Blokowanie nagłówka Referer pozwala zabronić tzw. hotlinkowania, co oznacza wyświetlania głównie obrazków na stronie internetowej poprzez połączenie z witryną, na której znajduje się pobierany obiekt (link pobiera dane źródłowe obrazu za każdym razem, gdy jest to potrzebne). Co ciekawe, niektóre serwery HTTP analizują obiekt odsyłający przed wyświetleniem obrazków i nie wyświetlają ich, jeśli żądanie pochodzi z innej witryny niż te dozwolone.

W przypadku elementów takich jak obrazki lub reklamy, punktem odniesienia jest zazwyczaj strona, która wywołuje te elementy. Jeśli klient pobierze obiekt statyczny z serwera taki jak obrazek, który jest prezentowany na stronie, strona odsyłająca będzie zawierała adres tej strony.

Dobrym przykładem jest język PHP, który przechowuje informacje o adresie źródłowym w zmiennej systemowej HTTP_REFERER. Co istotne, jak już wspomniałem wyżej, używanie tej zmiennej (lub jakiejkolwiek innej, które ma podobne zastosowanie) nie jest niezawodne, ponieważ w łatwy sposób można spreparować przechowywaną przez nią wartość. Jest to spowodowane tym, że jest ona zależna właśnie od nagłówka Referer wysłanego przez przeglądarkę lub aplikację kliencką do serwera.

Idąc za dokumentem Mozilla - Referer header: privacy and security concerns poważne problemy mogą pojawić się w przypadku stron umożliwiających „resetowania hasła” z linkiem do mediów społecznościowych w stopce. Jeśli skorzystano z odsyłacza, w zależności od tego, w jaki sposób udostępniono informacje, witryna mediów społecznościowych może otrzymać adres URL resetowania hasła i nadal może korzystać z udostępnionych informacji, potencjalnie narażając bezpieczeństwo użytkownika. Zgodnie z tą samą logiką obraz przechowywany na stronie trzeciej, ale osadzony na Twojej stronie może spowodować ujawnienie poufnych informacji stronie trzeciej. Nawet jeśli bezpieczeństwo nie jest zagrożone, informacje mogą nie być czymś, co użytkownik chce udostępniać.

Ponadto według rekomendacji OWASP, wykorzystanie nagłówka Referer np. do uwierzytelnienia lub autoryzacji może być potraktowane jako luka w zabezpieczeniach. Dzieje się tak, ponieważ w żądaniach HTTP można łatwo modyfikować wartość tego nagłówka i jako taki nie jest prawidłowym sposobem sprawdzania integralności wiadomości.

Kolejnym niezwykle ciekawym podejściem do wykorzystania wartości tego nagłówka są złośliwe żądania wysyłane za pośrednictwem ładunku XSS. Mają one często nieoczekiwany nagłówek Referer, który generalnie nie ma sensu w normalnym przepływie pracy aplikacji. Niestety zdarzają się aplikacje, które nie weryfikują jego wartości w ramach kontroli bezpieczeństwa potencjalnie otwierając drzwi do luki w zabezpieczeniach.

W jaki sposób poprawić bezpieczeństwo?

Główną ideą powinno być masowe blokowanie żądań, co jesteśmy w stanie wykonać z poziomu serwera NGINX, wykorzystując do tego moduł ngx_http_referer_module. Służy on do blokowania dostępu do witryny dla żądań z nieprawidłowymi wartościami w polu nagłówka Referer.

Konfiguracja wygląda jak poniżej i moim zdaniem dobrze jest umieścić ją w kontekście server {...} tak, aby chronić wszystkie zdefiniowane lokalizacje (choć zależy to oczywiście od konkretnego przypadku):

server_name static.example.com;

valid_referers none blocked server_names example.com *.example.com monitoring.foo.bar external-shop.eu;

if ($invalid_referer) {
  return 403;
}

Wyjaśnijmy teraz po kolei cały blok konfiguracji. Otóż dyrektywa server_name przechowuje nazwy obsługiwanych hostów wirtualnych. W naszym przykładzie jest to domena static.example.com obsługująca zasoby statyczne głównie dla domeny example.com.

Dyrektywa valid_referers określa politykę obsługi nagłówka Referer, a jej celem jest sprawdzenie tego nagłówka w żądaniu klienta i ewentualna odmowa dostępu na podstawie jego wartości. Zgodnie z dokumentacją modułu, określa ona wartości pola nagłówka żądania Referer. Jeśli weryfikowany nagłówek przyjmie jedną z określonych wartości, będzie ona miała przypisany pusty ciąg (wartość 0), w przeciwnym razie dla zmiennej zostanie ustawiona wartość 1. Co ważne, to w wyszukiwaniu dopasowania nie jest rozróżniana wielkość liter.

Przejdźmy teraz do opisu wartości tej dyrektywy. W naszym bloku pojawiają się trzy parametry:

• none - w żądaniu brakuje nagłówka Referer

• blocked - nagłówek jest obecny w żądaniu, ale jego wartość została usunięta lub zmieniona na ciągi, które nie zaczynają się od typu protokołów takich jak HTTP czy HTTPS

• server_names - nagłówek zawiera jedną z nazw wirtualnych hostów określoną z poziomu dyrektywy server_name

Następnymi parametrami są dowolne ciągi, tj. domeny z symbolami wieloznacznymi (*.example.com) lub wyrażenia regularne (~example.com). W przypadku tych drugich należy uważać, ponieważ zadeklarowanie wartości z symbolem ~ może powodować pewne negatywne konsekwencje. Na przykład, jeśli pozwolimy, aby żądania mogły pochodzić z domeny ~example.com, atakujący będzie mógł wykorzystać domenę aaaexample.com, która zostanie uznana za prawidłową.

Na koniec tego bloku widzimy sprawdzanie warunku, który jeśli zostanie spełniony, tj. przyjmie wartość 1, zwróci klientowi odpowiedź z kodem 403 Forbidden. Myślę, że można pokusić się o zwrócenie błędu 400 Bad Request, co będzie oznaczało, że serwer nie przetworzy żądania z powodu błędu klienta lub błędu 444 Connection Closed Without Response zamykając połączenie wewnątrz NGINX bez zwracania żadnej informacji do klienta.

Może się wydawać, że brak nagłówka Referer jest czymś niepożądanym i także należałoby go blokować. Otóż nie. Brak tego nagłówka występuje na przykład gdy:

• wprowadzono adres URL witryny w samym pasku adresu przeglądarki
• odwiedzono witrynę za pomocą zakładki obsługiwanej przez przeglądarkę
• odwiedzono witrynę jako pierwszą stronę w oknie/karcie
• kliknięto łącze w zewnętrznej aplikacji
• przełączono protokół z HTTPS na HTTP
• klient znajduje się za serwerami proxy, które mogą usuwać ten nagłówek ze wszystkich żądań
• wyłączono taką możliwość z poziomu klienta (np. curl)
• roboty skanują Twoją witrynę

Należy również wziąć pod uwagę, że zwykłe przeglądarki mogą nie wysyłać tego nagłówka (blokują go głównie ze względu na ochronę prywatności) a jeszcze inne ograniczają dostęp, aby nie zezwalać na przekazywanie HTTP_REFERER. Podobnie podczas wpisania adresu w pasku adresu nie spowoduje to przekazania HTTP_REFERER. Tak samo otwarcie nowego okna przeglądarki spowoduje przypisanie tej zmiennej wartości NULL.

Pamiętajmy, aby zawsze zweryfikować to, jak działają wprowadzone przez nas dyrektywy, np. dodając do konfiguracji poniższy blok:

server {

  server_name static.example.com;

  valid_referers none blocked server_names "testing.example.com";

  set $foo valid;
  if ($invalid_referer) {
    set $foo invalid;
  }

  location / {

    echo "referer: $foo '$invalid_referer'";

  }

  ...

}

Po wykonaniu kilku żądań z odpowiednio ustawionym nagłówkiem Referer w odpowiedzi otrzymamy następujące wyniki:

Widzimy, że zachowanie jest w miarę przewidywalne, jednak niepokój mogą budzić dwie sytuacje, tj. kiedy refererem są wartości testing.examplle.com oraz foo.example.com. Wszystko przez parametr blocked, dzięki któremu NGINX zinterpretował wartość nagłówka jako usunięty przez mechanizmy pośredniczące znajdujące się między klientem a serwerem docelowym. Zgodnie z dokumentacją, są to wszystkie wartości, które nie zaczynają się od schematów protokołu, tj. http:// lub https://, co ma miejsce w naszym przykładzie. Aby temu zapobiec, należy zmodyfikować dyrektywę invalid_referers usuwając z niej wartość blocked.

Pojawia się jeszcze jeden problem, o którym należy wspomnieć. Otóż może się zdarzyć, że gdzieś w konfiguracji ustawiłeś poniższy blok, wykorzystując moduł map, w celu blokowania niepożądanych refererów:

map $http_referer $invalid_referer {
  hostnames;

  default         0;
  "~*.fake\.com"  1;
}

Zdefiniowanie go w konfiguracji spowoduje, że z każdym żądaniem do zmiennej invalid_referer zostanie przypisana odpowiednia wartość, tj. 1, jeśli nagłówek Referer zawiera np. ciąg foo.fake.com lub 0 jeśli znajduje się w nim wszystko to, co nie zostało rozpoznane jako wyrażenie ~*.fake\.com.

Jeżeli pewnego dnia zechcesz stosować dyrektywę valid_referers, to zacznie ona działać w sposób nieprzewidywalny (nie zacznie działać zgodnie z przeznaczeniem). Stanie się tak, ponieważ wykorzystujemy już w konfiguracji zmienną invalid_referer, która też przechowuje wyniki ustawione na podstawie dyrektywy valid_referers. Moduł map będzie miał zawsze wyższy priorytet, więc zawsze przyjmie wartość 0, jeśli zmienna http_referer nie będzie przechowywać wartości podanej jako wyrażenie regularne.

Może to rodzić negatywne konsekwencje w wyniku czego dyrektywa valid_referers w ogóle nie zadziała, co spowoduje brak możliwości filtrowania nagłówka Referer. Najprostszym rozwiązaniem jest po prostu nie używanie tej zmiennej w innych miejscach konfiguracji.

Poniżej znajdują się jeszcze inne możliwości blokowania niechcianych refererów. Możemy np. wykorzystać bardziej statyczną konfigurację. Spójrz na poniższy przykład:

if ($http_referer ~* (seo|referrer|redirect|link=|url=|url?|path=|dku=|video|webcam)) {
  return 403;
}

Jeszcze innym rozwiązaniem jest wykorzystanie wspomnianego wcześniej modułu map:

map $http_referer $bad_referer {
  hostnames;

  default                           0;
  "~social-buttons.com"             1;
  "~semalt.com"                     1;
  "~kambasoft.com"                  1;
  "~savetubevideo.com"              1;
  "~descargar-musica-gratis.net"    1;
  "~7makemoneyonline.com"           1;
  "~baixar-musicas-gratis.com"      1;
  "~iloveitaly.com"                 1;
  "~ilovevitaly.ru"                 1;
  "~fbdownloader.com"               1;
  "~econom.co"                      1;
  "~buttons-for-website.com"        1;
  "~buttons-for-your-website.com"   1;
  "~srecorder.co"                   1;
  "~darodar.com"                    1;
  "~priceg.com"                     1;
  "~blackhatworth.com"              1;
  "~adviceforum.info"               1;
  "~hulfingtonpost.com"             1;
  "~best-seo-solution.com"          1;
  "~googlsucks.com"                 1;
  "~theguardlan.com"                1;
  "~i-x.wiki"                       1;
  "~buy-cheap-online.info"          1;
  "~Get-Free-Traffic-Now.com"       1;
}

server {

  [...]

  if ($bad_referer) {
    return 444;
  }

}

Obie propozycje skutecznie blokują żądania z niechcianymi refererami jednak mają jedną, bardzo poważną wadę — aktualizowanie takich list może być niezwykle trudne i w ogólnym rozrachunku jest mało ekonomiczne.

Jeżeli chwilę się zastanowisz, to najprawdopodobniej stwierdzisz, że mogą pojawić się przypadki, w których przydałoby się wykorzystać replikację złożoną z więcej niż jednego mistrza. Niestety Redis nie wspiera takiej implementacji i żeby ją zestawić za jego pomocą, musielibyśmy wykorzystać rozwiązanie podobne do Active-Active Geo-Distribution (CRDTs-Based). Więcej na ten temat poczytasz w artykule High Availability and Scalability with Redis Enterprise.

Z drugiej strony, czy istnieje rozwiązanie Open Source, które zapewniłoby taki sposób działania Redisa? Jest kilka możliwości rozwiązania tego problemu. W tym wpisie przedstawię alternatywne rozwiązanie oparte na forku projektu Redis zwanym KeyDB.

Czym jest KeyDB?

Autorzy projektu opisują go jako w pełni zgodny z Redisem i wysokowydajny fork ukierunkowany na wielowątkowość, wydajność pamięci i wysoką przepustowość. Myślę, że można go traktować bardziej jako solidny dodatek z kilkoma ekstra funkcjami. Co istotne, dostarcza on niektóre z mechanizmów projektu Redis Enterprise w tym ten, który nas interesuje najbardziej, czyli aktywną replikację.

Jedną z największych zalet, o której wspominają autorzy, jest wydajność w porównaniu z oryginałem. Na stronie głównej projektu przedstawiono to w ten sposób:

On the same hardware KeyDB can perform twice as many queries per second as Redis, with 60% lower latency. Active-Replication simplifies hot-spare failover allowing you to easily distribute writes over replicas and use simple TCP based load balancing/failover. KeyDB's higher performance allows you to do more on less hardware which reduces operation costs and complexity.

Więcej informacji na temat testów i porównań znajdziesz we wpisie A Multithreaded Fork of Redis That’s 5X Faster Than Redis.

Proces instalacji i czynności wstępne

W pierwszej kolejności przejdźmy do instalacji (wykorzystałem system CentOS 7), która jest niezwykle prosta i szybka. Oczywiście istnieje możliwość zbudowania pakietu ze źródeł, co zostało dokładnie opisane we wpisie Building KeyDB.

Najpierw pobierzmy klucz GPG repozytorium i dodajmy go do bazy kluczy:

rpm --import https://download.keydb.dev/packages/rpm/RPM-GPG-KEY-keydb

Następnie pobierzmy paczkę i zainstalujmy ją:

https://download.keydb.dev/packages/rpm/centos7/x86_64/keydb_all_versions/keydb-6.0.16-1.el7.x86_64.rpm
yum install ./keydb-6.0.16-1.el7.x86_64.rpm

Na koniec dodajmy uruchamianie usługi przy starcie systemu:

systemctl enable keydb

Przed przystąpieniem do edycji plików konfiguracyjnych wykonajmy kilka zadań w celu wprowadzenia pewnego porządku. W pierwszej kolejności utworzymy kopię głównego pliku konfiguracyjnego:

cp /etc/keydb/keydb.conf /etc/keydb/keydb.conf.orig

Następnym krokiem jest posprzątanie w konfiguracji, czyli na podstawie oryginalnego pliku wyfiltrujemy tylko faktyczne dyrektywy z pominięciem komentarzy:

egrep -v '#|^$' /etc/keydb/keydb.conf.orig > /etc/keydb/keydb.conf

Jeżeli zależy Ci na dokładniejszym dostosowaniu konfiguracji, zerknij do oficjalnej dokumentacji projektu lub do poprzednich moich wpisów dotyczących Redisa, w których dosyć dokładnie wyjaśniłem najważniejsze z parametrów.

Replikacja Active-Replica

Domyślnie KeyDB działa tak, jak Redis i zezwala tylko na jednokierunkową komunikację z instancji głównej do repliki. Natomiast typ replikacji Active-Replica znacznie upraszcza scenariusze przełączania awaryjnego, ponieważ repliki nie muszą już być promowane do instancji nadrzędnych. Ponadto ten tryb replikacji pozwala na lepsze rozłożenie obciążenia w scenariuszach opartych na zapisach. Poprawia także odczyty i zapisy w obu wykorzystywanych instancjach, co może zwiększyć ich liczbę przy dużym obciążeniu, a także przygotować repliki do pracy w przypadku awarii, co jest niemożliwe w przypadku replikacji Master-Slave złożonej z dwóch węzłów.

Ten tryb replikacji nadaje się idealnie w scenariuszach, w których masz dwa węzły i chcesz zapewnić odpowiednią wydajność zapisów lub zależy Ci na zachowaniu pełnej odporności na awarie. Więcej na ten temat poczytasz w rozdziale Active Replica Setup oficjalnej dokumentacji.

Istnieje jeszcze jedna, niezwykle ważna zaleta takiego rozwiązania. Otóż pozwala ono na wyeliminowanie sytuacji, w których połączenie między węzłami nadrzędnymi jest zrywane, ale zapisy są nadal wykonywane, przez co może dojść do sytuacji, w której dwie instancje mają ten sam klucz o różnej wartości. W KeyDB rozwiązana to tak, że każdy zapis jest oznaczony znacznikiem czasu, a po przywróceniu połączenia każdy mistrz udostępni swoje nowe dane. Zapisy z najnowszym znacznikiem czasu mają pierwszeństwo, co zapobiega zastępowaniu nowych danych zapisanych po zerwaniu połączenia przez stare dane.

Poniżej znajduje się poglądowy zrzut prezentujący to, w jaki sposób zostanie zestawiony ten typ replikacji:

Wszelkie komendy uruchomione w jednym węźle będą widoczne w drugim węźle. Jeśli jeden z serwerów ulegnie awarii, sygnatura czasowa zapewni, że replika nie nadpisze nowszych zapisów, gdy zostanie przywrócona do trybu online. Przy bardzo dużym obciążeniu może wystąpić niewielkie opóźnienie.

Z technicznych rzeczy, jakie się pojawiają w porównaniu ze zwykłym trybem pracy Master-Slave, są dynamicznie generowane identyfikatory. Nie są one nigdzie zapisywane i istnieją tylko przez cały czas działania procesu. Są one używane głównie w celu zapobiegania ponownemu rozpowszechnianiu zmian do serwera głównego.

Konfiguracja tego typu replikacji sprowadza się tak naprawdę do ustawienia parametrów active-replica yes i replica-read-only no na każdym z węzłów, przy czym drugi z parametrów po włączeniu pierwszej automatycznie przyjmuje wartość no, chyba że został jawnie wskazany w konfiguracji.

Cała konfiguracja z rozbiciem na węzły wygląda jak poniżej:

### R1 ###
bind 192.168.10.10 127.0.0.1
port 6379
requirepass meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
masterauth meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
active-replica yes
replica-read-only no
replicaof 192.168.10.20 6379

### R2 ###
bind 192.168.10.20 127.0.0.1
port 6379
requirepass meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
masterauth meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
active-replica yes
replica-read-only no
replicaof 192.168.10.10 6379

Uruchamiając obie instancje, po wydaniu polecenia INFO replication zobaczymy cztery istotne parametry:

192.168.10.10:6379> INFO replication
# Replication
role:active-replica
master_global_link_status:up
master_host:192.168.10.20
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_repl_offset:319620
slave_priority:100
slave_read_only:0
connected_slaves:1
slave0:ip=192.168.10.20,port=6379,state=online,offset=321520,lag=0
master_replid:f5093d23b283d0e32a357d9b0ce1c15c77593227
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:321520
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:319195
repl_backlog_histlen:2326

192.168.10.20:6379> INFO replication
# Replication
role:active-replica
master_global_link_status:up
master_host:192.168.10.10
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:320015
slave_priority:100
slave_read_only:0
connected_slaves:1
slave0:ip=192.168.10.10,port=6379,state=online,offset=321171,lag=1
master_replid:0ac9e564a25e1d4f63946aa5bb5a15205623ae0d
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:321171
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:318823
repl_backlog_histlen:2349

Pierwszy z nich to rola danego węzła, która przy poprawnej konfiguracji przyjmie wartość active-replica. Dwa pozostałe parametry powinny być nam znane i są nimi master_host określający instancję nadrzędną danego węzła oraz slave0, którego wartością jest podpięty węzeł nadrzędny. Widzimy, że w takiej konfiguracji każda z instancji w obu parametrach będzie miała lokalizację drugiego węzła. Czwarty parametr, tj. master_global_link_status określa ogólny status instancji nadrzędnej w całej grupie. W przypadku awarii jednego z węzłów jej status będzie miał wartość down.

Możemy teraz utworzyć testowo klucz na jednym z węzłów:

192.168.10.10:6379> SET foo bar
OK

I zweryfikować czy jest widoczny na każdym z nich:

### R1 ###
192.168.10.10:6379> GET foo
"bar"

### R2 ###
192.168.10.20:6379> GET foo
"bar"

Replikacja Multi-Master

Kolejnym rodzajem replikacji jest replikacja Multi-Master, która pozwala na obsługę wielu instancji nadrzędnych. Jest ona jednak nadal w fazie eksperymentalnej. Jeśli Twoje środowiska nie ma wygórowanych wymagań i zamierzasz wykorzystać tylko dwa węzły KeyDB, użyj replikacji Active-Replica, ponieważ jest bardziej stabilna niż Multi-Master i przetestowana pod kątem obsługi dużych obciążeń.

Oficjalna dokumentacja wspomina o niezwykle ważnej kwestii jeśli chodzi o zasadę działania w porównania z tradycyjnym modelem replikacji:

• wielokrotne wywołania polecenia replicaof spowodują dodanie kolejnych węzłów, a nie zastąpienie aktualnego
• KeyDB nie usuwa swojej bazy danych podczas synchronizacji z serwerem głównym
• KeyDB połączy wszystkie polecenia odczytu i zapisu, które odebrał z mistrza z własną wewnętrzną bazą danych
• KeyDB domyślnie nadaje najwyższy priorytet ostatnio wykonanej operacji

Oznacza to, że replika z wieloma mistrzami będzie zawierała nadzbiór danych wszystkich instancji głównych. Jeśli dwie instancje nadrzędne mają różną wartość tego samego klucza, nie jest zdefiniowane, który klucz zostanie przyjęty. Jeśli instancja główna usunie klucz, który istnieje w innym węźle głównym, replika nie będzie już zawierała kopii tego klucza.

Ten tryb replikacji nadaje się idealnie w scenariuszach, w których masz więcej niż dwa węzły i chcesz zapewnić odpowiednią wydajność zapisów lub zależy Ci na zachowaniu pełnej odporności na awarie. Więcej na ten temat poczytasz w rozdziale Using Multiple Masters oficjalnej dokumentacji.

Oficjalna dokumentacja opisuje możliwe zalety wykorzystania tego trybu:

With multi-master setup you make each master a replica of other nodes. This can accept many topologies, you could make different variations of ring topologies or make every master a replica of all other masters. If not all are synced, consider failure scenarios and ensure that one break wont cause others to lose their connections.

Konfiguracja tego trybu jest niezwykle podobna do tego omawianego we wcześniejszym rozdziale i sprowadza się do ustawienia parametru multi-master yes oraz odpowiedniego wskazania pozostałych węzłów Master.

Cała konfiguracja z rozbiciem na węzły wygląda jak poniżej:

### R1 ###
bind 192.168.10.10 127.0.0.1
port 6379
requirepass meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
masterauth meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
multi-master yes
active-replica yes
replica-read-only no
replicaof 192.168.10.20 6379
replicaof 192.168.10.30 6379

### R2 ###
bind 192.168.10.20 127.0.0.1
port 6379
requirepass meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
masterauth meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
multi-master yes
active-replica yes
replica-read-only no
replicaof 192.168.10.10 6379
replicaof 192.168.10.30 6379

### R3 ###
bind 192.168.10.30 127.0.0.1
port 6379
requirepass meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
masterauth meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
multi-master yes
active-replica yes
replica-read-only no
replicaof 192.168.10.10 6379
replicaof 192.168.10.20 6379

Uruchamiając każdą z instancji, po wydaniu polecenia INFO replication zobaczymy ponownie cztery istotne parametry oraz kilka dodatkowych informacji:

192.168.10.10:6379> INFO replication
# Replication
role:active-replica
master_global_link_status:up
master_host:192.168.10.30
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:4323
master_1_host:192.168.10.20
master_1_port:6379
master_1_link_status:up
master_1_last_io_seconds_ago:8
master_1_sync_in_progress:0
slave_repl_offset:4369
slave_priority:100
slave_read_only:0
connected_slaves:2
slave0:ip=192.168.10.20,port=6379,state=online,offset=7047,lag=1
slave1:ip=192.168.10.30,port=6379,state=online,offset=7047,lag=0
master_replid:10b8b05f4121996cf8ba64880140e8e1a8abce63
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:7047
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:4826
repl_backlog_histlen:2222

192.168.10.20:6379> INFO replication
# Replication
role:active-replica
master_global_link_status:up
master_host:192.168.10.10
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:6187
master_1_host:192.168.10.30
master_1_port:6379
master_1_link_status:up
master_1_last_io_seconds_ago:8
master_1_sync_in_progress:0
slave_repl_offset:4323
slave_priority:100
slave_read_only:0
connected_slaves:2
slave0:ip=192.168.10.30,port=6379,state=online,offset=5229,lag=0
slave1:ip=192.168.10.10,port=6379,state=online,offset=5229,lag=0
master_replid:15640f5845c0c8f99e17a38976139486ffc4b9bf
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5229
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:3008
repl_backlog_histlen:2222

192.168.10.30:6379> INFO replication
# Replication
role:active-replica
master_global_link_status:up
master_host:192.168.10.20
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:4323
master_1_host:192.168.10.10
master_1_port:6379
master_1_link_status:up
master_1_last_io_seconds_ago:8
master_1_sync_in_progress:0
slave_repl_offset:6141
slave_priority:100
slave_read_only:0
connected_slaves:2
slave0:ip=192.168.10.10,port=6379,state=online,offset=5183,lag=0
slave1:ip=192.168.10.20,port=6379,state=online,offset=5183,lag=1
master_replid:c77d822c70f3b13b48eeb39ac898d545dadbb6fc
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5183
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2985
repl_backlog_histlen:2199

Widzimy, że każdy z węzłów posiada dodatkowo lokalizację i parametry drugiej instancji głównej:

### R3 ###
master_host:192.168.10.20
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:4323
master_1_host:192.168.10.10
master_1_port:6379
master_1_link_status:up
master_1_last_io_seconds_ago:8
master_1_sync_in_progress:0
slave_repl_offset:6141

Oraz parametry slave0 i slave1, które zawierają lokalizację i parametry pozostałych instancji nadrzędnych. Możemy teraz utworzyć testowo klucz na jednym z węzłów:

192.168.10.10:6379> SET bar foo
OK

I zweryfikować czy jest widoczny na każdym z nich:

### R1 ###
192.168.10.10:6379> GET bar
"foo"

### R2 ###
192.168.10.20:6379> GET bar
"foo"

### R3 ###
192.168.10.30:6379> GET bar
"foo"

Konfiguracja HAProxy

Pozostaje jeszcze wybór odpowiedniego load balancera, którym w tym przykładzie będzie HAProxy z bardzo prostą konfiguracją:

global
  pidfile /var/run/haproxy.pid
  log 127.0.0.1 local0 info
  user haproxy
  group haproxy
  maxconn 512
  nbproc 2
  nbthread 2

defaults redis
  mode tcp
  timeout connect 4s
  timeout server 10s
  timeout client 10s
  log global
  option tcplog

frontend http
  bind *:8080
  default_backend stats

backend stats
  mode http
  stats enable
  stats uri /
  stats refresh 5s
  stats show-legends
  stats auth ha-admin:piph1NeiceHe

frontend ft_redis
  bind :16379 name redis
  default_backend bk_redis

backend bk_redis
  log global
  balance roundrobin
  server R1 192.168.10.10:6379 check inter 1s
  server R2 192.168.10.20:6379 check inter 1s
  server R3 192.168.10.30:6379 check inter 1s

Możemy ją zastosować dla obu typów replikacji. Zwróć uwagę na rodzaj równoważenia obciążenia, czyli techniki używanej do dystrybucji obciążenia. W zastosowanym tutaj trybie tj. roundrobin, load balancer ma listę serwerów i przekazuje każde żądanie do każdego serwera z listy w odpowiedniej kolejności. Po osiągnięciu ostatniego serwera pętla ponownie przeskakuje do pierwszego serwera i zaczyna się od nowa.

Należy mieć świadomość pewnych problemów, jakie mogą się pojawić, zwłaszcza gdy bierze się pod uwagę długość lub zapotrzebowanie na przetwarzanie połączenia. Gdy ruch jest znaczny lub połączenia są długie i zaczynają się gromadzić, obciążenie na serwerach, które otrzymują takie połączenia, może znacznie wzrastać.

Przetestujmy na koniec czy zapisy i odczyty w powyższej konfiguracji propagują się w odpowiedni sposób i czy istnieje możliwość połączenia się do instancji KeyDB przez HAProxy:

redis-cli -h 192.168.10.20 -p 16379 -a <password> SET xyz 123
OK

for i in 192.168.10.10 192.168.10.20 192.168.10.30 ; do
  redis-cli -h "$i" -p 16379 -a <password> GET xyz
done
"123"
"123"
"123"

Oczywiście nic nie stoi na przeszkodzie, abyś dostosował odpowiednią metodę równoważenia obciążenia w zależności od środowiska i instancji, które wykorzystujesz.

Dodatkowe zasoby

• Failover Redis like cluster from two masters with KeyDB.

W tym krótkim wpisie zaprezentuję właśnie taką sytuację, która może być niezwykle pomocna w przypadku danych tymczasowych takich jak sesje czy cache lub takich, które nie wymagają replikacji i odpowiedniego dbania.

Przed przystąpieniem do dalszego czytania, przypomnij sobie, jak we wpisie Redis: 3 instancje i replikacja Master-Slave cz. 3 przedstawiłem konfigurację HAProxy dostosowaną do wykrywania mistrza na podstawie odpytywania wszystkich instancji lub Sentineli i kierowania na tej podstawie ruchu tylko do instancji głównej.

Trzy instancje nadrzędne

W prezentowanej konfiguracji każda z instancji będzie miała ustawione poniższe parametry:

### R1 ###
bind 192.168.10.10 127.0.0.1
port 6379
requirepass meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2

### R2 ###
bind 192.168.10.20 127.0.0.1
port 6379
requirepass meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2

### R3 ###
bind 192.168.10.30 127.0.0.1
port 6379
requirepass meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2

Oczywiście pozostałe parametry tj. zapisy na dysk czy limity pamięci możesz dostosować do potrzeb aplikacji i środowiska. Ustawienie hasła nie jest wymagane, jednak w celu zachowania podstawowego poziomu bezpieczeństwa zostawimy je włączone (ponieważ wystawiamy instancje na interfejsach widocznych w sieci).

Konfigurację Redisa zaprezentowaną w tym wpisie przedstawia poniższy zrzut:

HAProxy i algorytmy równoważenia obciążenia

Aby zaprezentowane rozwiązanie zadziałało, musimy zmodyfikować konfigurację HAProxy. Jedną z technik, którą możemy wykorzystać, jest zastosowanie algorytmu, który przypisuje klienta zawsze do tej samej instancji, na podstawie skrótu obliczanego ze źródłowego adresu IP. Druga technika jest niezwykle podobna, jednak polega na tymczasowym „przyklejeniu” klienta do aktualnie działającej instancji.

W obu przypadkach dobrym pomysłem jest zapewnienie odpowiedniego i regularnego czyszczenia danych (cache, sesji) na instancjach, do których ruch był kierowany, a już nie nie jest, tak, aby po ewentualnym ponownym przepięciu, nie doszło do czytania danych, które są nieaktualne. Rozwiązać to można za pomocą wygasania kluczy i odpowiedniej polityki eksmisji.

Pamiętajmy także o odpowiednim przetestowaniu wykorzystanego rozwiązania, po to, aby zrozumieć zachowanie obu mechanizmów i tego, jakie mogą mieć wpływ na działanie aplikacji.

Source IP Hash

Technika ta wykorzystuje algorytm, który na podstawie adresu IP klienta tworzy unikatowy klucz, kojarzy go z jednym z serwerów docelowych i zapewnia podstawowy rodzaj trwałości sesji. Użytkownik jest kierowany do tego samego serwera w tej i kolejnych sesjach. Wyjątkiem jest sytuacja, gdy serwer jest niedostępny. Dlatego źródło o tym samym adresie IP będzie zawsze kierowane na ten sam serwer, natomiast jeśli adres IP jest dynamiczny, algorytm nie będzie w stanie połączyć swojej sesji z tym samym serwerem.

Oficjalna dokumentacja opisuje ten algorytm w ten oto sposób:

The source IP address is hashed and divided by the total weight of the running servers to designate which server will receive the request. This ensures that the same client IP address will always reach the same server as long as no server goes down or up. If the hash result changes due to the number of running servers changing, many clients will be directed to a different server. This algorithm is generally used in TCP mode where no cookie may be inserted.

Ponieważ skrót można ponownie wygenerować w przypadku zerwania sesji, ta metoda równoważenia obciążenia może zapewnić, że klient zostanie zawsze skierowany na ten sam serwer, z którego korzystał wcześniej. Oznacza to, że gdy HAProxy zobaczy nowe połączenia wykorzystujące tę samą informację (skrót), przekaże żądania do serwera skojarzonego z danym serwerem. Jest to przydatne, jeśli ważne jest, aby klient połączył się z sesją, która jest nadal aktywna po rozłączeniu i ponownym połączeniu.

Ta metoda równoważenia obciążenia zapewnia pewną trwałość, ponieważ wszystkie sesje z tego samego adresu źródłowego zawsze trafiają do tego samego rzeczywistego serwera. Dystrybucja jest jednak bezstanowa, więc jeśli dodamy nowy serwer lub usuniemy jeden z działających, dystrybucja zostanie zmieniona, a trwałość może zostać utracona. Tak samo w przypadku awarii, ponieważ przez pewien czas dane będą pobierane lub umieszczane na innym serwerze docelowym. Stąd należy pamiętać o odpowiednim ich czyszczeniu (wygasaniu).

Hashowanie na podstawie adresu IP działa w celu dystrybucji obciążenia na podstawie przychodzącego adresu IP żądania, dzięki czemu jest znacznie bardziej wyrafinowane. W tym trybie obciążenie ruchu rozkłada się równomiernie na wszystkie rzeczywiste backendy, jednak sesje nie są przypisywane w zależności od tego, jak zajęte są każde z nich.

Głównym problemem związanym z tym algorytmem jest to, że każda zmiana serwerów może przekierować żądanie na inny węzeł. Zwróć uwagę, że gdy serwer, który uległ awarii, stanie się ponownie dostępny, przypisani do niego klienci (określeni przez skrót) zostaną do niego ponownie przekierowani.

Poniżej znajduje się zmodyfikowana konfiguracja:

global
  pidfile /var/run/haproxy.pid
  log 127.0.0.1 local0 info
  user haproxy
  group haproxy
  maxconn 512
  nbproc 2
  nbthread 2

defaults redis
  mode tcp
  timeout connect 4s
  timeout server 10s
  timeout client 10s
  log global
  option tcplog

frontend http
  bind *:8080
  default_backend stats

backend stats
  mode http
  stats enable
  stats uri /
  stats refresh 5s
  stats show-legends
  stats auth ha-admin:piph1NeiceHe

frontend ft_redis
  bind :16379 name redis
  default_backend bk_redis

backend bk_redis
  log global
  balance source
  hash-type consistent
  server R1 192.168.10.10:6379 check inter 1s
  server R2 192.168.10.20:6379 check inter 1s
  server R3 192.168.10.30:6379 check inter 1s

Source IP Stick-Table

Niektóre aplikacje wymagają „lepkości” między klientem a serwerem. Oznacza to, że wszystkie żądania od klienta muszą być wysyłane do tego samego serwera także w sytuacjach, w których dojdzie do awarii aktualnej instancji. W przeciwnym razie sesja aplikacji może zostać zerwana, co może mieć negatywny wpływ na klienta.

W tym trybie HAProxy tworzy w pamięci specjalną tabelę do przechowywania stanu związanego z przychodzącymi połączeniami, indeksowaną przez klucz, taki jak adres IP klienta. Gdy klient jest przypisany do danego serwera, pozostaje on przypisany do momentu wygaśnięcia wpisu w tabeli lub jego awarii.

Jedną z głównych cech stosowania algorytmu Stick-Table jest to, że po powrocie serwera, który uległ awarii, żadne istniejące sesje nie zostaną do niego przekierowane. Stąd wynika właśnie jego lepkość, która trzyma się aktualnie działającego i przypisanego serwera do żądania, ale tylko przez określony czas lub do momentu awarii instancji, do której był kierowany ruch. Nie wynika z niej natomiast, że HAProxy będzie zawsze kierować ruch do już raz przypisanego serwera (ten problem rozwiązuje algorytm Source IP Hash).

HAProxy umożliwia synchronizowanie tabel w pamięci między wieloma instancjami, dzięki czemu przełączanie awaryjne może być przezroczyste.

Konfiguracja tego algorytmu w HAProxy nie jest tak oczywista jak w przypadku skrótów. Pojawia się tutaj kilka parametrów:

• type - decyduje o klasyfikacji danych, które będziemy przechwytywać (np. źródłowy adres IP)
• size - określa liczbę wpisów, które będziemy przechowywać (1k = 100000; 1 wpis ~ 50B, 1k wpisów ~ 5MB)
• expire - określa, jak długo (TTL) ma być przechowywany wpis w tabeli (jest to czas kiedy należy usunąć dane od ostatniego dopasowania, utworzenia lub odświeżenia rekordu w tabeli)

Pozwolę sobie przytoczyć ciekawe wyjaśnienie tych parametrów, które zostało opisane w artykule Better Rate Limiting For All with HAProxy:

stick-table type ip size 200k expire 3m - This declares a table to store the source IP addresses that is up to 200,000 entries long. Each IP entry is about 50 bytes and the connection rate and bytes out rate are 12 bytes each which are stored with each source IP address. So at 74 Bytes an entry we are looking at a possible 14 MBytes of usage for this table. The expire argument is how long to keep an entry in the table (In this case it just needs to be twice the length of the longest rate argument for a smoothed average).

Dzięki powyższym opcjom jesteśmy w stanie utworzyć pamięć typu Stick-Table i śledzić za jej pomocą dane. Poniżej znajduje się zmodyfikowana konfiguracja:

global
  pidfile /var/run/haproxy.pid
  log 127.0.0.1 local0 info
  user haproxy
  group haproxy
  maxconn 512
  nbproc 2
  nbthread 2

defaults redis
  mode tcp
  timeout connect 4s
  timeout server 10s
  timeout client 10s
  log global
  option tcplog

frontend http
  bind *:8080
  default_backend stats

backend stats
  mode http
  stats enable
  stats uri /
  stats refresh 5s
  stats show-legends
  stats auth ha-admin:piph1NeiceHe

frontend ft_redis
  bind :16379 name redis
  default_backend bk_redis

backend bk_redis
  log global
  stick-table type ip size 3 expire 30m
  stick on src
  server R1 192.168.10.10:6379 check inter 1s
  server R2 192.168.10.20:6379 check inter 1s
  server R3 192.168.10.30:6379 check inter 1s

Priorytety backendów

HAProxy pozwala na nadanie odpowiedniego priorytetu serwerom, które widzi w warstwie backendu. Służy do tego parametr weight, który dostosowuje wagę serwera w stosunku do innych serwerów. Wszystkie serwery otrzymają obciążenie proporcjonalne do ich wagi w stosunku do sumy wszystkich wag, więc im wyższa waga, tym do serwera zostanie dostarczona większa ilość żądań.. Domyślna waga to 1, a maksymalna to 256, przy czym wartość 0 pomija serwer z listy.

Waga każdego serwera to stosunek zadeklarowanej wagi tego serwera do sumy wszystkich zadeklarowanych wag. Tak więc przy 2 serwerach możesz po prostu użyć wartości 30 i 70, a dystrybucja będzie następująca: 30 ÷ (30 + 70 ) = 0,3 i 70 ÷ (30 + 70) = 0,7. W normalnym trybie rozkładania obciążenia tj. roundrobin, serwer, który „waży więcej”, otrzymuje proporcjonalnie więcej żądań. Oczywiście nic nie stoi na przeszkodzie, abyś używał wartości 3 i 7, 33 i 77 lub innych kombinacji w zakresie od 1 do 256. Zaleca się jednak, aby suma wszystkich wag była równa 100, ponieważ taki zapis jest bardziej przyjazny w zrozumieniu.

Wspominam o tym, ponieważ obie opisane wyżej techniki mają pewną wadę, która powoduje, że gdy klient puka do HAProxy na jednym z nich, to nie ma nigdy pewności, że żądania trafią do lokalnej instancji Redis. Nie jest to oczywiście wielką tragedią, jednak moim zdaniem, warto, aby żądania były kierowane zawsze do najbliższej instancji Redis jeśli każda z nich aktualnie działa. Jeśli ta będąca najbliżej ulegnie awarii, to oczywiście zrozumiałe jest, że proces HAProxy uruchomiony na tej samej maszynie będzie komunikował się z Redisem, który działa na innym węźle.

Taką priorytetyzację możemy zastosować dla obu opisanych technik. Na przykład dla algorytmu obliczającego skrót, ustawienie wag może wyglądać jak poniżej:

### H1 ###
[...]
server R1 192.168.10.10:6379 weight 50 check inter 1s
server R2 192.168.10.20:6379 weight 35 check inter 1s
server R3 192.168.10.30:6379 weight 15 check inter 1s

### H2 ###
[...]
server R1 192.168.10.10:6379 weight 35 check inter 1s
server R2 192.168.10.20:6379 weight 50 check inter 1s
server R3 192.168.10.30:6379 weight 15 check inter 1s

### H3 ###
[...]
server R1 192.168.10.10:6379 weight 15 check inter 1s
server R2 192.168.10.20:6379 weight 50 check inter 1s
server R3 192.168.10.30:6379 weight 35 check inter 1s

Co oznacza, że na węźle, na którym działa HAProxy (H1) i do którego łączy się klient, ruch będzie kierowany zawsze do lokalnej instancji R1 (która działa tam, gdzie HAProxy). To samo dla pozostałych węzłów, tj. ruch kierowany do H2 będzie zawsze kierowany do instancji nadrzędnej R2. W przypadku H3 będzie podobnie, ruch będzie zawsze kierowany do instancji R3. Jeżeli taka lokalna instancja Redis przestanie działać, ruch od klienta przechodzący przez HAProxy będzie kierowany do instancji w zależności od wagi, czyli w powyższym przykładzie do procesu o wadze 5.

Widzimy, że parametr wagi zaburza w pewien sposób działanie obu algorytmów i w obu przypadkach nie należy go traktować jako wskaźnika, który określa ile żądań (obciążenia) zostanie skierowanych do danego serwera w warstwie backendu. Określa on raczej priorytet, na podstawie którego dana instancja będzie otrzymywała żądania a jeśli ulegnie awarii, jej rolę przejmie kolejny serwer z ustawionym wyższym priorytetem niż pozostałe. Trwałość czy lepkość zostaje nadal zachowana, ponieważ żądania będą nadal kierowane do danej instancji.

Technika DNS Sinkholing (ang. sinkhole — lej) lub DNS Blackholing (ang. blackhole — czarna dziura), o której będziemy rozmawiać, jest używana do świadomego fałszowania wyników zwracanych z kontrolowanych przez administratora serwerów DNS. Dzięki temu jesteśmy w stanie ograniczyć lub odmówić dostępu do określonej domeny czy strony internetowej zwracając dla niej wskazany przez nas, zamiast oryginalnego, adres IP.

Gdy użytkownik próbuje uzyskać dostęp do sinkholowanej domeny może zostać mu zwrócony zasób z informacjami opisującymi ograniczenia lub może być skierowany do specjalnego miejsca w sieci lokalnej tak, aby zapobiec wejścia na zainfekowaną domenę/stronę. Widzisz, że sinkhole jest takim specjalnym miejscem, do którego kierowany jest, w sposób kontrolowany, ruch, który w normalnych warunkach byłby skierowany np. do złośliwej domeny.

Oczywiście technika ta może zostać użyta do niecnych celów, ponieważ każdy może mieć taki rodzaj serwera, jednak kluczowe jest to, że ma on wpływ najczęściej tylko na systemy, które używają tego konkretnego serwera DNS do rozpoznawania nazw (czyli np. wewnątrz sieci firmowej). Oczywiście główne serwery DNS lub serwery DNS kontrolowane przez dostawców usług internetowych będą miały wpływ na większą liczbę maszyn.

To tyle tytułem wstępu. Przejdźmy do dalszej części artykułu, w której przypomnimy sobie, jak działa DNS oraz cały proces leżący u podstaw tego systemu w typowej dystrybucji GNU/Linux. Następnie omówię trochę dokładniej technikę sinkholingu i zaprezentuję kilka możliwości zbudowania własnego serwera wykorzystującego ten mechanizm.

DNS i mechanizm rozwiązywania nazw

DNS (ang. Domain Name System) jest jedną z kluczowych części komunikacji, która pozwala na konwertowanie nazw alfabetycznych na numeryczne adresy. Dzięki temu, mając odpowiednio skonfigurowany serwer DNS, jesteśmy w stanie odpytywać go np. o adresy IP szukanych domen, które przechowuje.

Protokół DNS został dokładnie opisany w kilku dokumentach RFC. Dwoma głównymi są RFC 1034 - Domain Names - Concepts And Facilities oraz RFC 1035 - Domain Names - Implementation And Specification. Warto także zajrzeć do RFC 2671 - Extension Mechanisms for DNS, a także RFC 8499 - DNS Terminology Przeglądając je, znajdziesz w nich odnośniki to starszych wersji.

Jak dobrze wiemy, każdemu urządzeniu podłączonemu do sieci nadawany jest adres IP, który jest niezbędny do zlokalizowania go w sieci oraz wymiany komunikacji. Na przykład, gdy chcemy załadować stronę internetową znajdującą się na zdalnym serwerze, musi nastąpić tłumaczenie między tym, co wpisujemy w swojej przeglądarce (np. example.com), a zrozumiałym dla urządzeń i protokołów adresem IP (np. 192.168.10.25) niezbędnym do zlokalizowania danego zasobu. Ten proces tłumaczenia ma kluczowe znaczenie dla ładowania każdej strony internetowej i jest ściśle związany z mechanizmem rozwiązywania nazw za pomocą protokołu DNS.

DNS może korzystać z obu protokołów warstwy transportu i domyślnie używa portu docelowego o numerze 53. Gdy wykorzystywany jest UDP, mamy możliwość obsługi retransmisji i sekwencjonowania UDP. Natomiast protokół TCP jest najczęściej wykorzystywany, gdy rozmiar żądania lub odpowiedzi jest większy niż pojedynczy pakiet, na przykład w przypadku odpowiedzi, które mają wiele rekordów, w przypadku odpowiedzi IPv6 lub większości odpowiedzi DNSSEC.

To, co wpisujemy w przeglądarce, nazywamy nazwą domenową (lub po prostu domeną). Każda taka nazwa składa się z co najmniej jednej etykiety. Etykiety są oddzielone znakiem . tworząc w pełni kwalifikowaną nazwę (ang. FQDN - Fully Qualified Domain Name) — czyli pełną nazwę domeny dla określonego komputera lub hosta. Etykiety są konstruowane od prawej strony do lewej, gdzie etykieta po prawej stronie jest domeną najwyższego poziomu (ang. TLD - Top Level Domain). Na przykład mając domenę foo.bar.example.com etykieta znajdująca się najbardziej po prawej stronie, tj. .com będzie etykietą TLD.

Główną elementem, na którym operują klienci i serwery DNS są rekordy zasobów (ang. RR - Resource Records). Są to wpisy w bazie danych DNS, które zawierają informacje o hostach. Rekordy są fizycznie przechowywane w plikach stref na serwerze DNS. Na przykład rekordy mapowania adresów oznaczany jest za pomocą litery A i odpowiadają za przechowywanie nazwy hosta wraz z przypisanym do niego adresem IPv4. Innym typem rekordu jest rekord serwera nazw oznaczana za pomocą ciągu NS, który identyfikuje serwery nazw odpowiedzialne za twoją strefę DNS dla konkretnej domeny. Aby mieć prawidłową konfigurację DNS, rekordy NS skonfigurowane w strefie muszą być dokładnie takie same, jak te skonfigurowane jako serwery nazw u dostawcy nazwy domeny.

W jaki sposób jednak operujemy na rekordach? Wszystko odbywa się za pomocą zapytań (ang. queries). Pierwszym typem zapytań są zapytania rekurencyjne (ang. recursive). Szukając wartości danego rekordu, klient zazwyczaj kontaktuje się z lokalnym serwerem DNS w celu uzyskania odpowiedzi. Serwer musi udzielić odpowiedzi — dlatego odpowiada albo odpowiednim rekordem, albo komunikatem o błędzie, jeśli nie można go znaleźć.

Jednak przed zwróceniem błędu serwer wysyła zapytania do innego serwera DNS w imieniu oryginalnego klienta. Zapytanie rekurencyjne to rodzaj zapytania, w którym serwer DNS, który otrzymał Twoje zapytanie, wykona całą pracę polegającą na pobraniu odpowiedzi i zwróceniu jej, ponieważ podczas tego procesu serwer DNS może, również w Twoim imieniu, wysyłać zapytania do innych serwerów DNS, aby uzyskać odpowiedź. Widzimy, że klient prosi lokalny serwer DNS o wykonanie wszystkich potrzebnych żądań w jego imieniu.

Drugim typem zapytań są zapytania iteracyjne (ang. iterative). W tym typie zapytań zachowanie jest podobne, jednak jeśli serwer nie ma w swojej pamięci odpowiedniego rekordu, kieruje klienta DNS bezpośrednio do serwera głównego. Ten typ serwera prześle następnie lokalizację serwerów TLD, z którymi skontaktuje się klient. Następnie klient kontaktuje się z następnym serwerem nazw w łańcuchu, aż do znalezienia i osiągnięcia serwera zawierającego pełną nazwę FQDN. Widzimy, że klient musi powtórzyć zapytanie bezpośrednio na serwerach DNS i to on wykonuje całą pracę samodzielnie, aż do ostatecznego rozstrzygnięcia szukanej nazwy. Co istotne, dowolny klient DNS może wykonywać zapytania iteracyjne, jednak nie jest to zalecane.

Ostatnim typem zapytań są zapytania nierekurencyjne (ang. non-recursive). W tym typie zapytań klient otrzymuje odpowiedź od razu, ponieważ serwer DNS przechowuje ją w lokalnej pamięci podręcznej, albo wysyła zapytanie do serwera nazw DNS, który jest autorytatywny dla rekordu, co oznacza, że ​​na pewno ma poprawny adres IP dla tej nazwy hosta. W obu przypadkach nie ma potrzeby wykonywania dodatkowych rund zapytań (jak w przypadku zapytań rekurencyjnych). Zamiast tego odpowiedź jest natychmiast zwracana klientowi.

Dobrze, omówmy w takim razie cały proces, jaki odbywa się podczas rozwiązywania nazwy domenowej, ponieważ jego zrozumienie jest kluczowe. Wygląda on podobnie do poniższego diagramu w typowym systemie GNU/Linux:

Sam mechanizm i wszystkie kroki od wpisania w przeglądarce nazwy do uzyskania adresu IP a w konsekwencji wyświetlenia danego zasoby jest niezwykle fascynujący.

Klient (przeglądarka)

Wpisując np. w przeglądarce adres example.com, w pierwszej kolejności przeglądarka sprawdza, czy domena znajduje się w jej lokalnej pamięci podręcznej. Jeśli odwiedzałeś jakiś czas temu tę domenę, przeglądarka może już wiedzieć, jaki jest jej adres IP i mieć tę wartość w swoim lokalnym buforze.

Pamięć podręczna przeglądarki zwykle przechowuje obiekty dosyć krótko, a nie dłużej niż poprzez parametr czasu życiu (ang. Time to Live) — czyli adres jest przechowywany tak długo, jak został określony za pomocą tego parametru. Z drugiej strony, przeglądarki komunikują się z lokalnym resolverem więc TTL nie powinien mieć większego znaczenia. Po trzecie, przeglądarki posiadają wbudowane opcje, które sterują czasem życia rekordów, np. Firefox posiada parametry konfiguracyjne: network.dnsCacheExpiration i network.dnsCacheExpirationGracePeriod z domyślną wartością 60 sekund. Google Chrome i wbudowany wewnętrzny mechanizm rozpoznawania nazw DNS ignoruje TTL rekordów DNS i buforuje żądania DNS także przez 60 sekund.

Przy okazji wspomnę, że rekordy DNS mają parametr TTL, który jest ustawiany na autorytatywnych serwerach przez właściciela domeny.

GNU libc

Przejdźmy dalej. Jeśli przeglądarka nie znajdzie odpowiedniego wpisu w swojej pamięci podręcznej, zacznie szukać dalej, aby przeprowadzić wyszukiwanie. I tutaj pojawia się kilka ciekawych kwestii.

Po pierwsze, istnieje kilka sposobów rozwiązywania nazw na tym poziomie i tak naprawdę nie ma jednej metody uzyskania wyszukiwania DNS. W systemie GNU/Linux istnieje biblioteka GNU libc, która dostarcza trzy różne interfejsy rozpoznawania nazw. Istnieje niskopoziomowa implementacja BSD resolver(3), jest także funkcja gethostbyname i powiązane z nią dodatkowe funkcje, które implementują przestarzałą specyfikację POSIX, a także nowoczesna implementacja rozwiązywania nazw getaddrinfo zgodne ze standardem POSIX.

Zajmijmy się tymi dwoma ostatnimi. W oficjalnej dokumentacji biblioteki libc zostały opisane tak:

You can use gethostbyname, gethostbyname2 or gethostbyaddr to search the hosts database for information about a particular host. The information is returned in a statically-allocated structure; you must copy the information if you need to save it across calls. You can also use getaddrinfo and getnameinfo to obtain this information.

O ile nie określono inaczej, funkcja gethostbyname używa domyślnej kolejności, tj. próbuje uzyskać wynik z lokalnego pliku /etc/hosts lub używa pliku /etc/resolv.conf w celu określenia (rozpoznaje serwery nazw domen zgodnie z opisem w dokumencie RFC 883) serwera DNS i wysłania do niego zapytania w celu uzyskania nazwy.

gethostbyname sprawdza, czy nazwa hosta może być rozwiązana przez odniesienie w lokalnym pliku (którego lokalizacja różni się w zależności od systemu operacyjnego) przed podjęciem próby odpytania serwera DNS. Jeśli gethostbyname nie ma rekordu w pamięci podręcznej ani nie może go znaleźć w pliku hosts, wysyła żądanie do serwera DNS skonfigurowanego w stosie sieciowym najczęściej właśnie przez plik lokalnego resolwera. Zazwyczaj jest to router lokalny lub buforujący serwer DNS usługodawcy internetowego.

Druga z funkcji, tj. getaddrinfo także służy do wyszukiwania DNS. Jest jednak znacznie bardziej zaawansowana (i bardziej przeładowana), ponieważ po drodze wywołuje znacznie więcej wywołań systemowych, tj. odczyt plików systemowych, ładowanie bibliotek czy otwieranie dodatkowych gniazd. Spójrz poniżej na statystyki ilości wywołań:

strace -c ./gethostbyname.out
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  0.00    0.000000           0        10           read
  0.00    0.000000           0         1           write
  0.00    0.000000           0        10           close
  0.00    0.000000           0         1           stat
  0.00    0.000000           0         9           fstat
  0.00    0.000000           0         2           lseek
  0.00    0.000000           0        13           mmap
  0.00    0.000000           0         5           mprotect
  0.00    0.000000           0         2           munmap
  0.00    0.000000           0         3           brk
  0.00    0.000000           0         1         1 access
  0.00    0.000000           0         2           socket
  0.00    0.000000           0         2         2 connect
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0         8           openat
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000           0        71         3 total

strace -c ./getaddrinfo.out
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  0.00    0.000000           0        12           read
  0.00    0.000000           0         1           write
  0.00    0.000000           0        14           close
  0.00    0.000000           0         1           stat
  0.00    0.000000           0        11           fstat
  0.00    0.000000           0         2           lseek
  0.00    0.000000           0        13           mmap
  0.00    0.000000           0         5           mprotect
  0.00    0.000000           0         2           munmap
  0.00    0.000000           0         3           brk
  0.00    0.000000           0         1         1 access
  0.00    0.000000           0         5           socket
  0.00    0.000000           0         4         2 connect
  0.00    0.000000           0         1           sendto
  0.00    0.000000           0         3           recvmsg
  0.00    0.000000           0         1           bind
  0.00    0.000000           0         3           getsockname
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0         9           openat
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000           0        93         3 total

Oczywiście jest to przykład prostych programów napisanych w C odpytujących lokalnego hosta.

Generalnie tuż przed żądaniem DNS proces wykonuje wywołania systemowe i, jeśli trzeba rozwiązań nazwę z serwera DNS, pobiera adres IP serwera z pliku /etc/resolv.conf (niezależnie od używanej aplikacji, system operacyjny wyśle ​​zapytania DNS do serwerów DNS określonych w tym pliku). getaddrinfo pobiera informacje z /etc/hosts, czytając ten plik w całości za każdym razem, gdy wywołasz klienta.

Co niezwykle ciekawe, po uzyskaniu adresów IP przez tę funkcję, nie zwraca ona od razu odpowiedzi do klienta, tylko przeprowadza dodatkowo testy tych adresów, otwierając do nich gniazda i łącząc się z nimi:

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("172.217.20.206")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(48043), sin_addr=inet_addr("192.168.43.56")}, [28->16]) = 0
close(3)                                = 0
socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(0), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "2a00:1450:401b:805::200e", &sin6_addr), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
close(3)

Oraz nie buforuje odpowiedzi (ogólnie obie nie buforują, aby zapewnić taką funkcję można użyć demona nscd), więc kolejne połączenia także są dosyć kosztowne przy jej wykorzystaniu.

Interesujące jest także to, że żaden z wymienionych wyżej plików nie jest znany procesom tak po prostu. Taką wiedzę uzyskują one dopiero po załadowaniu specjalnych współdzielonych bibliotek w czasie swojego wykonywania. Na przykład wywołując obie funkcje w dystrybucji Debiano podobnej:

• /etc/hosts jest znany z poziomu libnss_files.so.2
• /etc/resolv.conf jest znany z poziomu libnss_dns.so.2

nsswitch.conf

Aby jeszcze bardziej skomplikować sprawę, musimy mieć świadomość, że proces pobiera listę takich źródeł w czasie wykonywania z innego pliku, tj. /etc/nsswitch.conf. Tak naprawdę GNU libc umożliwia skonfigurowanie kolejności, w jakiej funkcja czy proces, który z niej korzysta, próbuje uzyskać dostęp do usługi. Jest to kontrolowane właśnie przez plik nsswitch.conf. W przypadku dowolnej funkcji wyszukiwania obsługiwanej przez GNU libc plik ten zawiera wiersz z nazwami usług, które mają być używane.

Jeżeli chodzi o mechanizm rozwiązywania nazw, plik ten oczywiście przyjmuje różne wartości w zależności od systemu. Na przykład, w systemie FreeBSD 12.1 wygląda on tak:

hosts: files dns

Co oznacza taki wpis? Mówi on, że aby znaleźć hosta, najpierw należy odpytać bibliotekę libnss_files.so. Jeśli to się nie powiedzie, należy odpytać bibliotekę libnss_dns.so. W dystrybucji CentOS 7.7 wpis hosts w tym pliku wygląda następująco:

hosts: files dns myhostname

Jest on niezwykle podobny, jednak posiada dodatkową wartość. W tym wypadku mówi on, że aby znaleźć hosta, najpierw należy odpytać bibliotekę libnss_files.so. Jeśli to się nie powiedzie, należy odpytać bibliotekę libnss_dns.so. Jeżeli obie próby zakończą się niepowodzeniem, odpytaj bibliotekę libnss_myhostname.so. Oczywiście w zależności od systemu czy dystrybucji wartości mogą znajdować się na innym miejscu.

Widzimy, że z poziomu pliku nsswitch.conf możemy zmuszać funkcje gethostbyname i getaddrinfo do wypróbowywania każdej z wymienionych usług, np. do przeszukiwania serwera DNS przed plikiem /etc/hosts. Jeśli wyszukiwanie powiedzie się, zwracany jest wynik, w przeciwnym razie sprawdzona zostanie następna usługa z listy.

Praktycznie w każdym systemie i dystrybucji plik hosts ma pierwszeństwo przed pozostałymi usługami. Informacje o nazwie hosta, mogą się jednak zmieniać bardzo często, więc w niektórych sytuacjach serwer DNS powinien zawsze mieć najdokładniejsze dane, podczas gdy lokalny plik hostów traktowany jest jako kopia zapasowa tylko na wypadek awarii.

We wpisie hosts pliku nsswitch.conf może pojawić się jeszcze coś takiego jak mDNS. Jeżeli chcesz uzyskać więcej informacji na ten temat zerknij na odpowiedź mDNS or Multicast DNS service.

Wróćmy na chwilę do klientów i programów wykorzystujących omawiane funkcje. Mógłbyś pomyśleć: skoro każde z tych narzędzi uzyskuje ten sam wynik, więc na pewno wykorzystują te same mechanizmy. Tak naprawdę, różne programy uzyskują adres IP adresu na różne sposoby. Na przykład polecenie ping wykorzystuje mechanizm nsswitch, który z kolei może wykorzystać plik /etc/hosts, /etc/resolv.conf lub własnej nazwy hosta, aby uzyskać wynik.

Nie wszystkie narzędzia wykorzystują taki oto sposób. Na przykład komenda host jest typowym poleceniem służącym do odpytywania serwerów DNS. Wykorzystuje ona plik /etc/resolv.conf do ustalenia, które serwery DNS odpytać w celu uzyskania nazwy szukanego hosta. Tak naprawdę większość programów odwołuje się do tego pliku (jeśli zajdzie taka potrzeba) przy określaniu, który serwer DNS należy wykorzystać.

Podobnie sytuacja wygląda z narzędziem nslookup czy poleceniem ping. Pierwsze z nich wymusi wyszukiwanie DNS, podczas gdy ping będzie używać normalnej kolejności wyszukiwania nazw.

Zewnętrzne serwery DNS

Jeżeli procesom działającym w Twoim systemie nie udało się uzyskać adresu IP szukanej nazwy — pozostaje ostatni krok — czyli odpytanie zewnętrznych serwerów DNS. Jeśli wpiszesz w przeglądarce host1.b.example.com mechanizmy systemu operacyjnego w pierwszej kolejności spróbują przeszukać pamięć podręczną DNS i wszelkie dostępne źródła zewnętrzne. W tym celu wyślą ​​zapytanie do skonfigurowanego serwera DNS z pytaniem właśnie o tę domenę.

Rozwiązywanie nazwy nigdy nie opiera się na jednym serwerze DNS (chyba że buforuje on odpowiednie rekordy i jest w stanie zwrócić odpowiedź do klienta natychmiast) i jest to proces, w którym zaangażowanych jest kilka różnych typów serwerów, tj. serwer główny, serwer TLD i serwer autorytatywny, które muszą dostarczyć informacji, aby zakończyć wyszukiwanie. W przypadku buforowania serwery mogą zapisać odpowiedź na zapytanie podczas poprzedniego wyszukiwania, a następnie dostarczyć ją bezpośrednio z pamięci. Ostatecznie cały ten łańcuch serwerów DNS pozwala znaleźć adres IP domeny i zwrócić wynik go do klienta, aby mógł uzyskać dostęp do właściwej witryny internetowej.

Jak już wiesz, w pierwszej kolejności odpytane zostaną serwery DNS ustawione w pliku /etc/resolv.conf. Mogą to być rekursywne serwery DNS, tj. Google (8.8.8.8, 8.8.4.4), lub CloudFlare (1.1.1.1, 1.0.0.1). Pełną listę publicznych serwerów DNS znajdziesz na przykład w Public DNS Server List. Najczęściej jednak „najbliższym” serwerem jest serwer w sieci lokalnej, który jeśli nie posiada informacji o szukanej domenie, przekaże zapytanie do rekursywnego serwera DNS, często udostępnianego przez dostawcę usług internetowych (ISP). Tak naprawdę, kiedy twój system zapyta najbliższy z serwerów nazw o to, gdzie jest host1.b.example.com, taki serwer przekaże żądanie do dowolnego miejsca, w którym może uzyskać odpowiedź. Jeśli jeden z serwerów posiada rekordy w pamięci podręcznej, natychmiast odpowie klientowi, nie przeszkadzając wszystkim pozostałym serwerom pośredniczącym, zaczynając od serwerów głównych.

Rekursywny serwer DNS, ma własną pamięć podręczną i jeśli zna adres IP szukanej domeny, zwróci go do Ciebie. Jeśli nie, poprosi inny serwer DNS o pomoc w znalezieniu serwera głównego dla domeny, z którą chcesz nawiązać połączenie i której adresu IP szukasz. Ponieważ pamięć podręczna serwera DNS zawiera tymczasowy magazyn rekordów DNS, będzie on bardzo szybko odpowiadał na żądania, co jest jedną z kluczowych funkcji tego typu serwerów DNS. Tego typu serwery są nazywane nieautorytatywnymi serwerami DNS, ponieważ zapewniają rozwiązywanie żądań na podstawie wartości buforowanej uzyskanej z autorytatywnych serwerów DNS.

Wspomniałem o typach serwerów jednak bardzo często możesz się spotkać z terminem resolwer (ang. resolver). Co to takiego jest? Termin ten oznacza ogólny podsystem zajmujący się rozwiązywaniem zapytań. Tak naprawdę jest to cały podsystem, którego programy użytkownika używają do uzyskiwania dostępu do serwerów nazw, bez względu na jakąkolwiek konkretną architekturę. Najczęściej, jest on dość prostą biblioteką klienta działająca w procesach aplikacji, komunikującą się za pomocą protokoów UDP i TCP z uruchomionym programem zewnętrznym jako kolejnym procesem, który faktycznie wykonuje podstawową pracę związaną z rozwiązywaniem zapytań.

Jeśli odpytywany serwer DNS zna odpowiedź, ponieważ ostatnio zadano mu to samo pytanie, zwróci ją z pamięci podręcznej (o ile taki wpis nie wygasł). Jeśli odpytywany serwer DNS nie jest w stanie rozwiązać domeny, uruchomi dalszą procedurę odpytywania, np. gdy rekursywny serwer DNS usługodawcy internetowego nie może rozpoznać nazwy domeny, kontaktuje się (dlatego nazywamy je serwerami rekurencyjnymi) z innymi serwerami DNS, aby dostarczyć Ci wymaganych informacji. Każdy dostawca usług internetowych ma zazwyczaj dwa serwery DNS, w tym jeden pomocniczy, aby zapewnić maksymalną dostępność usługi.

Zapytania DNS klienta są wysyłane rekurencyjnie, co oznacza, że ​​klient powinien otrzymać od dostawcy DNS błąd lub rozwiązany rekord. Serwery pośredniczące także nie powinny samodzielnie rozwiązywać łańcucha pośrednich serwerów DNS, ponieważ ich zadaniem jest przekazywanie zapytań dalej do serwera DNS, który obsługuje żądania klientów. W ten sposób usługi przekazywania zmniejszają obciążenie pośrednich serwerów DNS i odpowiadają klientom tak szybko, jak to możliwe, ponieważ serwery DNS dostawców są bliżej klientów.

W tym celu musi ustalić, który serwer DNS jest tzw. serwerem autorytatywnym, czyli takim serwerem, który na pewno potrafi rozwiązać szukaną przez nas nazwę (jest jej właścicielem).

Autorytatywny serwer nazw to miejsce, w którym administratorzy zarządzają nazwami serwerów i adresami IP swoich domen. Ilekroć administrator DNS chce dodać, zmienić lub usunąć nazwę serwera lub adres IP, dokonuje zmiany na swoim autorytatywnym serwerze DNS. Istnieją również „podrzędne” serwery DNS, czyli takie, które przechowują kopie rekordów DNS swoich stref i domen.

Na tym etapie nie znamy jeszcze lokalizacji serwera autorytatywnego, dlatego musimy znaleźć takie serwery, które pomogą nam wskazać, gdzie on się znajduje. Tym sposobem docieramy do kolejnego poziomu, na którym znajdują się serwery główne (ang. root). Twój serwer zawiera listę wszystkich serwerów głównych i przechowuje ją najczęściej w miejscu zwanym Root Hints lub Root Zone — jest to po prostu lista (zbiór rekordów NS, A i AAAA) zawierająca ich adresy IPv4 i IPv6 serwerów, które są autorytatywne dla domeny głównej . (należy je traktować jako wskazówki dotyczące lokalizacji serwerów głównych). Lista takich serwerów jest publikowana przez IANA i można ją znaleźć tutaj.

Operatorzy serwerów DNS powinni regularnie aktualizować swoje pliki dotyczące serwerów głównych, aby wskazywały właściwe serwery nazw. Najczęściej takie listy dostarczane są wraz z paczkami serwera DNS dlatego nie musimy martwić się o ich aktualność.

Ponieważ wskazówki dotyczące roota są zadawane w twoim imieniu, serwery DNS otrzymają odpowiedź z odpowiednim rekordem od głównego serwera DNS, a następnie przekażą ci ten rekord.

Jak już wiemy, jeżeli rekursywny serwer DNS nie znajdzie odpowiedniego wpisu w swojej pamięci podręcznej, poprosi o pomoc serwery z tzw. autorytatywnej hierarchii (ang. authoritative DNS hierarchy), aby uzyskać odpowiedź. Dzieje się tak, ponieważ każda część domeny, taka jak host1.b.example.com, ma określony autorytatywny serwer nazw DNS (lub grupę nadmiarowych autorytatywnych serwerów nazw). Co istotne, ponieważ serwer DNS nie ma odpowiedniej strefy ani rekordu, najpierw przyjrzy się wewnętrznym mechanizmom przekazywani (czyli kolejnym serwerom, z którym może uzyskać odpowiedź). Jeśli nie ma skonfigurowanego odpowiedniego rekordu odpowiedzialnego za przekazywanie zapytań dla odpowiedniej strefy lub domeny, zacznie szukać odpowiedzi właśnie w tzw. wskazówkach dotyczących serwerów głównych.

W górnej części drzewa serwerów znajdują się główne serwery nazw domen. Każdy adres witryny internetowej ma domniemane . na końcu, nawet jeśli tego nie wpiszemy. To . wyznacza główne serwery nazw DNS na szczycie hierarchii DNS. Główne serwery nazw domen będą znać adresy IP autorytatywnych serwerów nazw, które obsługują zapytania DNS dla domen najwyższego poziomu TLS (ang. Top Level Domains), takich jak .com czy .gov.

Te serwery nie mają adresu IP, którego potrzebujemy, ale mogą wysłać żądanie DNS we właściwym kierunku. Widzimy, że pierwszym wysłanym zapytaniem będzie to, które dotyczy domeny głównego rzędu, tj. . (root), aby znaleźć odpowiedni serwer dla domeny niższego rzędu, tj. .com. Gdy uda się ustalić taki serwer, serwer DNS, który odpytywaliśmy, skomunikuje się z tym serwerem z ​​zapytaniem o serwer nazw. Rekurencyjny serwer DNS najpierw pyta główny serwer nazw domen o adres IP serwera TLD .com, ponieważ host1.b.example.com znajduje się właśnie w TLD .com.

To, co mają serwery nazw TLD, to lokalizacja autorytatywnego serwera nazw dla żądanej witryny. Autorytatywny serwer nazw odpowiada adresem IP dla example.com, a rekursywny serwer DNS przechowuje go w lokalnej pamięci podręcznej DNS i zwraca adres do komputera.

Główny serwer nazw domeny odpowiada adresem serwera TLD. Następnie rekursywny serwer DNS pyta autorytatywny serwer TLD, gdzie może znaleźć autorytatywny serwer DNS dla host1.b.example.com. Autorytatywny serwer TLD odpowiada i proces jest kontynuowany. Autorytatywny serwer host1.b.example.com jest pytany, gdzie znaleźć host1.b.example.com, a serwer odpowiada z odpowiedzią. Gdy rekursywny serwer DNS zna adres IP witryny sieci Web, odpowiada komputerowi, podając odpowiedni adres IP. Twoja przeglądarka ładuje stronę i możesz rozpocząć jej przeglądanie.

Podsumowując, gdy klient DNS wysyła takie żądanie, pierwszy odpowiadający serwer nie podaje potrzebnego adresu IP. Zamiast tego kieruje żądanie do innego serwera, który znajduje się niżej w hierarchii DNS, a ten do innego, dopóki adres IP nie zostanie w pełni rozwiązany. W procesie tym mamy trzy kluczowe elementy:

• serwery główne (ang. Root DNS Servers) - ten typ serwerów nie mapuje adresów IP na nazwy domen. Zamiast tego przechowuje informacje o wszystkich serwerach nazw domen najwyższego poziomu (TLD) i zajmują się one jedynie wskazywaniem ich lokalizacji. TLD to skrajna prawa sekcja nazwy domeny, na przykład .com w przypadku example.com lub .org w przypadku example.org. Serwery główne są krytyczne, ponieważ są pierwszym przystankiem dla wszystkich żądań wyszukiwania DNS

• serwery nazw TLD (ang. Top Level Domain DNS Servers) - ten typ serwerów zawiera dane z domen drugiego poziomu, takich jak example dla example.com. Wcześniej serwer główny wskazywał lokalizację serwera TLD, a następnie taki serwer kieruje żądanie do serwera zawierającego niezbędne dane dotycząca domeny

• autorytatywny serwer nazw (ang. Authoritative DNS Server) - ten typ serwera DNS jest ostatecznym miejscem docelowym dla żądań wyszukiwania DNS. Dostarcza on adres IP domeny z powrotem do rekurencyjnych serwerów DNS, a następnie do klienta (przy okazji rekord dla tego żądania jest teraz przechowywany w pamięci podręcznej serwera rekursywnego oraz klienta tj. przeglądarki internetowej). Jeśli witryna ma subdomeny, lokalny serwer DNS będzie wysyłać żądania do autorytatywnego serwera, aż ostatecznie ustali adres IP

DNS Sinkhole

Przypomnieliśmy sobie pokrótce, czym jest i jak działa system rozwiązywania nazw. Wiemy już, że jest to globalnie rozproszona, skalowalna, hierarchiczna i dynamiczna baza danych, która zapewnia m.in. mapowanie między nazwami hostów, adresami IP (zarówno IPv4, jak i IPv6) i jeszcze kilkoma innymi rekordami.

Z racji tego, że usługa ta jest podstawową i wręcz krytyczną usługą używaną do uzyskiwania dostępu do Internetu, istotne jest jej kontrolowanie. Tutaj do akcji wkracza mechanizm DNS Sinkholing mający na celu ochronę użytkowników poprzez przechwytywanie żądań DNS próbujących połączyć się ze znanymi złośliwymi lub niechcianymi domenami poprzez zwracanie fałszywego i kontrolowanego adresu IP. Technika ta została dokładnie opisana w świetnej pracy pod tytułem DNS Sinkhole ^[PDF], której autorem jest Guy Bruneau.

Na przykład przechwytując wychodzące żądania DNS próbujące uzyskać dostęp do znanych złośliwych domen lub choćby w pełni legalnych witryn zawierających jednak złośliwe reklamy, organizacja może kontrolować odpowiedź i uniemożliwić komputerom organizacji łączenie się z tymi domenami. Pozwala to zapobiec niechcianej komunikacji i jest w stanie złagodzić znane i nieznane zagrożenia w znanych złośliwych lub niechcianych domenach. Dzięki funkcji sinkholingu możemy blokować zapytania DNS do określonych domen, odbierać zapytania DNS na wyjściu sieci i podejmować działania, zamiast przekazywać je do wewnętrznych lub publicznych serwerów DNS.

Widzisz, że tak skonfigurowany serwer przechwytuje żądania DNS klienta do znanych złośliwych witryn, odpowiadając za pomocą adresu IP, który kontrolujesz, zamiast prawdziwego ich adresu, dzięki czemu klient kierowany jest w bezpieczne miejsce. Kontrolowany adres IP wskazuje najczęściej na serwer zdefiniowany i będący pod kontrolą administratora.

Jest to niezwykle potężna technika, która pozwala np. na ograniczenie ataków botów, poprzez blokowanie komunikacji między serwerem atakującego a nimi. Sinkholing można jednak wykonać na różnych poziomach. Wiadomo, że zarówno dostawcy usług internetowych, jak i rejestratorzy domen używają tej techniki do ochrony swoich klientów, kierując żądania do złośliwych lub niechcianych nazw domen na kontrolowane adresy IP. Administratorzy systemów mogą również skonfigurować wewnętrzny serwer DNS typu sinkhole w infrastrukturze swojej organizacji. Użytkownik może również zmodyfikować plik /etc/hosts w swoim systemie (co spowoduje nadpisanie wszystkiego lokalnie) i uzyskać ten sam wynik. Istnieje wiele list (zarówno otwartych, jak i komercyjnych) znanych złośliwych domen, których administrator może wykorzystać.

Taka metoda blokowania nie tylko zwiększa bezpieczeństwo stacji klienckich (zatrzymując potencjalne złośliwe reklamy), ale także pozwala klientom na ich blokowanie bez żadnych wtyczek czy dodatkowej konfiguracji. Kolejną zaletą blokowania na tym poziomie (DNS) jest to, że cała sieć może skorzystać z filtrowania bez konieczności konfigurowania jakiegokolwiek rodzaju filtrowania proxy na każdym kliencie.

Oprócz zapobiegania złośliwym połączeniom sinkholing może służyć do identyfikowania zainfekowanych hostów poprzez analizę dzienników i identyfikowanie klientów, którzy próbują połączyć się ze znanymi złośliwymi domenami. Na przykład, jeśli dzienniki pokazują, że jedna konkretna maszyna nieustannie próbuje połączyć się z tzw. serwerem C&C (ang. Command and Control) — czyli takim serwerem, który jest kontrolowany przez atakującego, który służy do wysyłania poleceń do systemów zainfekowanych złośliwym oprogramowaniem i odbierania skradzionych danych z sieci docelowej — ale żądanie jest przekierowywane z powodu sinkholingu, istnieje duża szansa, że ​​ta konkretna maszyna jest zainfekowana botem.

Jeśli zainfekowany system wysyła zapytanie DNS do naszego serwera rozwiązywania nazw w celu komunikacji z serwerem atakującego, nasz serwer DNS, który zawiera czarną listę domen niepożądanych miejsc docelowych, zwraca kontrolowany przez nas adres IP. W rezultacie, ponieważ komputer zombie próbuje komunikować się z naszym serwerem, nie może komunikować się serwerem atakującego. Z drugiej strony istnieje wiele cyberataków powodowanych przez złośliwe adresy URL zawarte w wiadomościach spam. Dlatego też, jeśli wyodrębnimy złośliwe adresy URL z tego typu wiadomości i zastosujemy je do techniki sinkholingu, wiele ataków opartych na spamie może zostać zablokowanych.

Istnieje kilka prostych sposobów, dzięki którym klienci mogą złagodzić opisane problemy, np. modyfikując plik /etc/hosts w swoich systemach, aby wskazywał na poprawne adresy IP dla domen, lub używając publicznej usługi rozpoznawania nazw. Ważną sugestią jest to, że powinniśmy to robić tylko na swoich wewnętrznych resolverach, ponieważ jeśli technika sinkholingu zostanie wdrożona na publicznych, autorytatywnych serwerach, administrator będzie odpowiadać na domeny, za które nie jest odpowiedzialny.

W przypadku serwera BIND konfiguracja jest niezwykle prosta i sprowadza się do określenia, które domeny będą blokowane. W pierwszej kolejności należy dodać odwołanie do specjalnie przygotowanego pliku w głównym pliku konfiguracyjnym:

// named.conf

//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/namedb/zones.rfc1918";

include "/etc/namedb/blacklisted.zones";

Natomiast plik /etc/namedb/blacklisted.zones może przyjąć poniższą zawartość:

zone "9nta.com" {type master​; file "/etc/namedb/sinkhole/blockeddomains.db";};
zone "malware.ru" {type master; ​file "/etc/namedb/sinkhole/blockeddomains.db";};
zone "adworks.cat" {type master; file "/etc/namedb/sinkhole/blockeddomains.db";};
zone "herngell-our.web.app" {type master; file "/etc/namedb/sinkhole/blockeddomains.db";};
zone "google.co.uk" {type master; file "/etc/namedb/sinkhole/blockeddomains.db";};

Jak widać powyżej, definiujemy strefy, dla których nasz serwer DNS będzie autorytatywny. Gdy otrzyma zapytanie od klienta dotyczące, np. 9nta.com, serwer dostarczy dane z powiązanego pliku. W tym przypadku, ponieważ traktujemy je wszystkie jako domeny typu sink, wszystkie mogą wskazywać ten sam plik strefy, aby ułatwić zarządzanie.

Plik blockeddomains.db dla specjalnie przygotowanej strefy może mieć poniższą zawartość:

$ORIGIN .
$TTL 600 ; 1 hour
@     IN SOA  ns01.example.com. hostmaster.example.com. (
              2020100301 ; serial
              3600       ; refresh (1 hour)
              900        ; retry (15 minutes)
              1814400    ; expire (3 weeks)
              3600       ; minimum (1 hour)
              )
      NS      ns01.example.com.
      NS      ns02.example.com.

; Każde odwołanie do 9nta.com spowoduje przekierowanie na wskazany adres
       A     172.31.252.10
; Każde odwołanie do *.9nta.com spowoduje przekierowanie na wskazany adres
*  IN  A     172.31.252.10

; *  IN  A     127.0.0.1
; *  IN  AAAA  ::1

W tym przypadku chodzi o wskazanie określonego adresu IP, na którym połączenia z nim będą monitorowane w celu generowania informacji o zapytaniach do niepożądanych domen. Jeśli zależy nam na zablokowaniu połączeń z takimi domenami, docelową lokalizację należy zmienić na adres pętli zwrotnej.

Po tych zmianach wewnętrzny resolver będzie od teraz autorytatywny dla wszystkich domen, które były wymienione na czarnej liście. Jeżeli chcesz poznać inny przykład podejścia, zerknij do poniższych artykułów:

• Bind DNS Sinkhole, Elasticsearch and Logstash
• Setting up a DNS Firewall on steroids

Na koniec koniecznie zapoznaj się z dokumentem Consequences of DNSbased Internet filtering ^[PDF], który przedstawia możliwe konsekwencje takiego blokowania domen z poziomu serwera BIND, a także świetnej prezentacji DNS Response Policy Zones na temat mechanizmu, który umożliwia administratorowi serwera nazw nakładanie niestandardowych informacji na globalny DNS w celu dostarczania alternatywnych odpowiedzi na zapytania klientów.

Zarządzanie i optymalizacja pamięci

Z racji tego, że Redis przechowuje wszystkie swoje dane w pamięci, ważne jest, aby zoptymalizować jej wykorzystanie i odpowiednio dbać o jej zużycie. Jednak pamiętaj, że wszystko tak naprawdę zależy od konkretnego przypadku.

Redis umożliwia wykonanie wielu złożonych operacji na danych i manipulowania nimi zapewniając obsługę wielu ich typów, stąd moim zdaniem, jedną z ważniejszych umiejętności podczas pracy z nim jest odpowiednia dbałość o rodzaj tych operacji. Ponadto zrozumienie, dlaczego nagle procesy Redisa zaczynają pochłaniać nieoczekiwanie duże ilości pamięci, jest równie ważne. Przydatna może być również wiedza na temat tego, w jaki sposób przechowywane są różne struktury, w jaki sposób są zaimplementowane i jak działają, zwłaszcza że programiści jak i administratorzy często nie rozumieją specyfiki pracy Redisa z pamięcią RAM oraz tego, za co i kiedy trzeba zapłacić cenę wysokiej wydajności.

Stosowanie odpowiednich struktur danych jest kluczowe z punktu widzenia wydajności i optymalizacji pamięci. Dlatego tak istotne jest, aby już na etapie projektowania ułatwić sobie pracę poprzez pewną optymalizacją i wdrożenie zaleceń. Temat jest niezwykle szeroki i to, co przedstawię poniżej, jest tylko pewną jego częścią. Myślę jednak, że może być dobrym punktem startowym do dalszych rozważań i analizy.

Jeżeli nie wiesz, za pomocą jakich poleceń możesz tworzyć struktury danych i jakie typy wykorzystywać, koniecznie przeczytaj poniższe artykuły:

• Data types
• An introduction to Redis data types and abstractions
• Understanding Redis Abstract Data types and it’s usages Part — I
• Top Redis Use Cases by Core Data Structure Types

Natomiast po prosty i w miarę wyczerpujący opis typów danych używanych w Redisie odsyłam do książki Redis 4.x Cookbook.

Jedną z największych zalet Redisa w porównaniu z innymi tego typu systemami pamięci jest bogaty zestaw dostępnych struktur danych. Uporządkowane listy, uporządkowane skróty i posortowane zestawy są szczególnie przydatnymi narzędziami do buforowania. Pamiętaj, że buforowanie to coś więcej niż upychanie wszystkiego w łańcuchy. Dokładne informacje o komendach powiązanych z daną strukturą znajdziesz w oficjalnej dokumentacji. Są one pogrupowane według typu danych:

• Skróty - dane użytkowników (nazwa użytkownika, adres e-mail), obsługa postów, rejestrowanie i przechowywanie metryk produktów
• Listy - kanały RSS, tabele wyników (np. MMORPG, jak wyjaśniono w oficjalnej dokumentacji Redis)
• Łańcuchy - jako pamięć podręczna sesji, obsługa wiadomości, kolejek, zarządzanie zadaniami
• Strumienie - gromadzenie dużych ilości danych przychodzących z dużą prędkością, systemy czatu, brokery wiadomości, systemy kolejkowania, pozyskiwania informacji o zdarzeniach
• Nieuporządkowane ciągi - analizowania zachowań klientów, wyniki wyszukiwania, filtrowanie treści, śledzenie adresów IP
• Uporządkowanego ciągi - platformy obsługujące pytania i odpowiedzi (Stack Overflow i Quora), interfejs API do indeksowania geograficznego, ustalanie priorytetu zadania w kolejce

Praca do wykonania niestety nie leży tylko w gestii administratora, ponieważ to, jak wykorzystywana będzie pamięć, zależy w dużej mierze od architekta i tego, jakie techniki przechowywania zastosuje. Jako administratorzy mamy jednak ogromny wpływ na działanie uruchomionych usług, ponieważ praca, którą wykonamy na początkowym etapie, ma zawsze niebagatelne znaczenie związane z ich działaniem, pracą serwera jak i całego środowiska. Z punktu widzenia operatora istnieją trzy niezwykle ważne rzeczy, o których należy pamiętać:

• dobór odpowiedniej konfiguracji sprzętowej i programowej serwera
  • w tym typ procesora i systemu (32-bit vs 64-bit)
  • w tym ilość dostępnej pamięci (więcej nie znaczy lepiej)
• dobór odpowiedniego kompilatora, jeśli budujemy Redisa ze źródeł (w tym dokonanie pewnych optymalizacji)
• dobór odpowiedniego alokatora pamięci

Od odpowiedniego doboru powyższych elementów zależy, ile pamięci zostanie faktycznie wykorzystane. Aby maksymalnie skrócić temat, poniżej znajdują się pewne sugestie i zalecenia, na podstawie zasobów, które kiedyś znalazłem w sieci oraz moich doświadczeń. Jeżeli będziesz miał jakiekolwiek wątpliwości, w pierwszej kolejności posiłkuj się oficjalnym dokumentem Memory Optimization for Redis.

Zachęcam Cię mocno do przeczytania zaleceń dotyczących zarządzania i optymalizacji pamięci. Repozytorium z wytycznymi znajduje się tutaj. Koniecznie zerknij także do oficjalnego repozytorium i rodziałów Memory Optimization i Memory allocation, rozdziału Chapter 9: Reducing memory use książki Redis in Action, świetnego dokumentu Memory management best practices z zasobów GCloud oraz artykułu Redis RAM Ramifications – Part I.

Aby przechowywać klucze, Redis przydziela co najwyżej tyle pamięci, na ile pozwala ustawienie maxmemory, jednak są możliwe niewielkie dodatkowe alokacje. Jest kilka rzeczy, na które należy zwrócić uwagę, jak Redis zarządza pamięcią:

Jeżeli wykorzystujesz Redisa, weź pod uwagę poniższe zalecenia:

• w przypadku problemów z pamięcią użyj:
  • polecenia MEMORY DOCTOR, które raportuje o różnych problemach związanych z pamięcią i podaje możliwe rozwiązania
  • narzędzi redis-rdb-tools, aby przeanalizować przechowywane zestawy danych. Dzięki nim dowiesz się, m.in. ile pamięci zajmuje każdy klucz. Pomoże ci to zdecydować, na czym skoncentrować się podczas optymalizacji

• jeżeli chcesz się dowiedzieć wielu przydatnych informacji o przechowywanym obiekcie, wykorzystaj komendę DEBUG, np. DEBUG OBJECT username:1303

• jeżeli chcesz znaleźć polecenia, które przetwarzane są przez długi okres czasu (przekroczyły czas wykonania), wykorzystaj komendę SLOWLOG

• zastanów się nad ustawieniem opcji jądra vm.overcommit_memory = 1
  • pozwala ona na przepełnienie pamięci
  • parametry vm.overcommit_* sterują alokacją pamięci w przestrzeni użytkownika, a w tym trybie jądro nigdy nie sprawdza, czy w systemie jest dostępna wystarczająca jej ilość. Zwiększa to ryzyko sytuacji braku pamięci, ale także poprawia przydzielanie pamięci procesom, które intensywnie z niej korzystają
  • w celu uzyskania szczegółowych informacji na temat tego parametru zerknij do wpisu Virtual memory settings in Linux - The Problem with Overcommit
• wyłącz funkcję jądra transparent_hugepage
  • w „normalnych” warunkach ma na celu poprawę wydajności poprzez efektywniejsze wykorzystanie mapowania pamięci procesora
  • jej działanie polega na tworzeniu mniejszej liczby dużych bloków pamięci zamiast wielu małych bloków w systemach z dużą ilością pamięci
  • jest to świetne rozwiązanie, jeśli proces wymaga dużych ciągłych dostępów do pamięci operacyjnej jednak w przypadku Redisa, sytuacja jest odwrotna, ponieważ niezależnie od dostępnej pamięci, wymaga on wielu mniejszych dostępów
  • jej włączenie może powodować problemy z wydajnością, a w najgorszym wypadku nawet wycieki pamięci. Jeśli masz problemy z dużym opóźnieniem, sprawdź, czy ta funkcja jest wyłączona
  • więcej informacji uzyskasz w artykule Disable Transparent Hugepages
• użyj pamięci SWAP (ilości równej pamięci operacyjnej)
  • przestrzeń wymiany w systemie Linux jest używana, gdy ilość pamięci fizycznej (RAM) jest pełna, dzięki czemu możliwe jest przeniesienie nieaktywnych strony z pamięci operacyjnej właśnie do przestrzeni wymiany
  • jeśli wykorzystujesz Redisa w systemie, w którym nie ma pamięci SWAP, a dana instancja przypadkowo zużyje zbyt dużo pamięci, to albo ulegnie awarii z powodu braku pamięci, albo zadziała mechanizm OOM Killer, który zabije proces Redis
  • wykorzystanie przestrzeni wymiany pozwala zapobiec takim sytuacjom, jednak najprawdopodobniej sprawi, że proces Redisa będzie działał znacznie wolniej a klienci zauważą opóźnienia w dostarczaniu danych
• ustaw limit pamięci za pomocą maxmemory i odpowiednią politykę eksmisji za pomocą maxmemory-policy
  • dzięki takiemu połączeniu zapewnisz większą stabilność działania serwera, na którym działa Redis i inne procesy
  • samo ustawienie limitu pamięci nie jest złe, ponieważ w momencie dojścia do ustawionego progu, Redis zacznie zgłaszać błędy, zamiast wysycić całą dostępną pamięć w systemie
  • przy ustawieniu wartość pierwszego parametru pamiętaj, aby obliczyć możliwy dodatkowy narzut na wykorzystanie pamięci w tym narzut jej fragmentacji. Dokumentacja podaje przykład: jeśli w systemie masz 10 GB pamięci, ustaw limit między 8-9 GB
• ​​musisz zapewnić pamięć na podstawie szczytowego jej wykorzystania
  • jeśli od czasu do czasu wymagane jest zapewnienie 10 GB pamięci dla danych, to w przypadku średniego wykorzystania pamięci na poziomie 5 GB, musisz zapewnić 10 GB
• Redis nie zawsze zwalnia (zwraca) pamięć do systemu operacyjnego po usunięciu kluczy, która została mu przydzielona przez system
  • jest to całkiem normalne zachowanie związane z większością implementacji funkcji malloc(), na przykład, jeśli Redis przechowuje 7 GB danych, następnie usuniesz 2 GB, to rozmiar oznaczony jako RSS, który jest liczbą stron pamięci zużytych przez proces, prawdopodobnie nadal będzie wynosił około 10 GB, nawet jeśli komenda INFO memory zwróci informację o wykorzystaniu równym 5 GB (jednak alokatory są inteligentne i są w stanie ponownie wykorzystać wolne fragmenty pamięci bez zwiększania metryki RSS)
  • często większość usuniętych kluczy jest przydzielana na tych samych stronach, co inne nadal istniejące klucze
  • z tego powodu współczynnik fragmentacji nie jest wiarygodny, gdy maksymalne użycie pamięci jest znacznie większe niż obecnie używana pamięć
  • pamiętaj o narzutach związanych ze strategią zmiany rozmiaru za pomocą parametru maxmemory
  • jeżeli wykorzystujesz kilka procesów Redis, pamiętaj, że aktywne zapisy mogą znacznie zwiększyć fragmentację pamięci, co może skutkować nawet 2 razy większym jej wykorzystaniem
• systemy 64-bitowe używają znacznie więcej pamięci niż systemy 32-bitowe do przechowywania tych samych kluczy, zwłaszcza jeśli klucze i wartości są małe
  • dzieje się tak, ponieważ małym kluczom przydzielane są pełne 64-bity, co powoduje marnotrawstwo niewykorzystanych bitów
  • wersja 64-bitowa ma więcej dostępnej pamięci w porównaniu do maszyny 32-bitowej, jednak jeśli masz pewność, że rozmiar danych nie przekroczy 3 GB, przechowywanie w 32-bitach jest dobrą opcją i optymalizacją
  • możemy przyjąć taką oto strategię zrozumienia: jeśli Redis chce przydzielić jakiś rozmiar dla danej struktury danych, np. 24 bajty, to zostanie on zawsze zaokrąglony do najbliższej potęgi liczby dwa, czyli zostanie przydzielone 32 bajty. Jeśli Redis będzie potrzebował 57 bajtów, zostaną przydzielone 64 bajty
• Redis jest nieprawdopodobnie szybki przy małych wartościach
  • staraj się maksymalnie ograniczyć małe ciąg, tzn. klucze z małymi wartościami (krótyszymi niż 100 bajtów)
  • jeżeli wydasz polecenie SET foo bar, będzie to kosztowało ok. 112 bajtów pamięci (56 bajtów na wartość i tyle samo na klucz), z czego ok. 106 bajtów to narzut na systemie 64-bitowym
  • koszt utworzenia pustego klucza za pomocą SET "" "" dla Redis v4.0.1 64-bit wynosi 51 bajtów pamięci, które są czystym narzutem, ponieważ żadne rzeczywiste dane nie są przechowywane (nie są też wykorzystywane do utrzymywania wewnętrznych struktur danych)
• projektując system, który będzie bardzo aktywnie wykorzystywał Redisa, należy kierować się zasadą: jeden zestaw danych = jeden Redis
  • przechowywanie heterogenicznych danych jest trudne ze względu na ustawienia hash-max-ziplist-entry i hash-max-ziplist-value a także ograniczenia kluczy bez prefiksów
• klucze odgrywają niezwykle ważną rolę w zwiększaniu zużycia pamięci
  • ogólnie rzecz biorąc, zawsze powinieneś preferować klucze opisowe
  • jednak jeśli masz duży zbiór danych zawierający miliony kluczy, mogą one pochłonąć dużo zasobów
  • jeśli to możliwe, używaj numerycznych nazw kluczy, wartości i pól w tabelach skrótów
  • nie używaj przedrostków lub postfiksów — zawsze używaj identyfikatorów całkowitych dla obiektów
• zestawy danych zawierające tylko liczby całkowite są niezwykle wydajne pod względem pamięci
  • niezależnie od używanego typu kodowania, Redis jest idealny dla liczb, akceptowalny dla ciągów o długości do 63 bajtów i niejednoznaczny podczas przechowywania większych ciągów
  • aby zaoszczędzić pamięć, przechowuj liczby całkowite w swoich zestawach, dzięki czemu Redis automatycznie użyje najbardziej wydajnej pamięci struktury danych
  • jeśli wykorzystujesz ciągi, spróbuj użyć liczb całkowitych, mapując identyfikatory ciągów na liczby całkowite
  • liczby całkowite w listach zip (ZIPLIST) są kodowane przy użyciu zmiennej liczby bajtów. Innymi słowy, małe liczby całkowite zajmują mniej pamięci
• jeśli masz setki milionów kluczy, nie używaj do ich przechowywania łańcuchów
  • zastępując proste klucze grupami tabel skrótów, pamiętaj, że optymalizacja działa dla miliona lub więcej kluczy
• jeśli dane w tabeli skrótów mają regularną strukturę, zapomnij o tabeli skrótów i przejdź do przechowywania danych w listach
  • użyj list zamiast słowników dla małych, spójnych obiektów
• w miarę możliwości używaj natywnych typów, tj. LIST, SET, ZSET, HASH
  • jednak pamiętaj, że zwykła implementacja SET to nieuporządkowana kolekcja ciągów
  • nie używaj ciągów do danych strukturalnych, sięgnij po hash
• skróty (ang. Hash) w Redisie to słowniki, które można bardzo wydajnie zakodować w pamięci
  • statystyki skrótów w danej bazie można wyświetlić za pomocą polecenia DEBUG htstats <db_id>
  • jeśli masz miliony i setki milionów kluczy, ponosisz ogromne wydatki na przechowywanie ich w słownikach i marnowanie pamięci na rezerwację takiej struktury danych
  • skrót składa się z pól i ich wartości. Podobnie jak wartości, nazwa pola również zajmuje pamięć, dlatego należy o tym pamiętać podczas przypisywania nazw pól
  • jeśli masz dużą liczbę skrótów o podobnych nazwach pól, wykorzystanie pamięci może znacznie wzrosnąć
  • aby zmniejszyć zużycie pamięci, możesz użyć mniejszych nazw pól
  • skróty zużywają mniej pamięci niż zestaw sortowany
  • możesz użyć hashy do indeksowania nazw użytkowników, ponieważ są znacznie bardziej kompaktowe niż sortowane listy (ZSET)
  • skrót używa wydajnej pamięciowo reprezentacji ZIPLIST, jeśli spełniony jest następujący warunek:

    len(hash) < hash-max-ziplist-entries && length-of-largest-field(hash) < hash-max-ziplist-value
    

    Możesz zwiększyć te dwa ustawienia, ale nie zwiększaj ich więcej niż 3-4 razy w stosunku do wartości domyślnej

• w celu zapewnienia większej wydajności pamięci zastanów się nad używaniem skrótów (używaj ich tam, gdzie to możliwe)
  • hashe o małej wielkości są kodowane w bardzo małej przestrzeni, dlatego należy próbować reprezentować dane za pomocą skrótów za każdym razem, gdy jest to możliwe
  • jeśli masz obiekty reprezentujące użytkowników w aplikacji internetowej, zamiast używać różnych kluczy dla imienia, nazwiska, adresu e-mail, hasła, użyj jednego skrótu ze wszystkimi wymaganymi polami

• jeśli przechowujesz dużo obiektów, powiedzmy więcej niż 50000 i mają one regularną strukturę, to możesz użyć koncepcji krotek (ang. NamedTuples), czyli liniowej listy tylko do odczytu, wokół których można zbudować tablice mieszające

• ciągów należy używać tylko wtedy, gdy:
  • wartość jest co najmniej większa niż 100 bajtów (ciągi mają narzut około 90 bajtów w systemie 64-bitowym)
  • przechowujesz zakodowane dane w ciągu zakodowanym w formacie JSON lub w buforze
  • używasz typu danych łańcuchowych jako tablicy lub zestawu bitów
  • jeśli nie wykonujesz żadnego z powyższych, użyj zamiast tego skrótów
• nie używaj ZIPLIST w tabelach haszujących z dużą liczbą wartości (od 1000), jeśli wydajność przy dużych rekordach ma dla Ciebie istotne znaczenie
  • wykorzystanie ZIPLIST daje (w niektórych przypadkach) nawet 5-6 krotny zysk zapotrzebowania na pamięć, spada wtedy jednak znacznie (naprawdę znacznie) prędkość zapisu i odczytu
  • narzut korzystania z ZIPLIST jest minimalny, przechowywanie ciągów w tego typu liście jest mniej kosztowne niż w jakiejkolwiek innej strukturze
  • implementacja ZIPLIST w Redis osiąga niewielki rozmiar pamięci dzięki przechowywaniu tylko trzech fragmentów danych na wpis; pierwsza to długość poprzedniego wpisu, druga to długość bieżącego wpisu, a trzecia to zapisane dane
• LIST jest prostszą strukturą od ZIPLIST i pozwala zaoszczędzić pamięć co najmniej 2 razy
  • jeśli przechowujesz dużo list, pamiętaj, że chociaż są one małe i zużywają mało pamięci, to gdy tylko zaczną się rozrastać, pamięć może dramatycznie wzrosnąć od 2 razy i więcej, a sam proces zmiany kodowania zajmie znaczną ilość czasu
  • pojedyncza duża lista nie jest dobrym pomysłem, ponieważ dostęp do elementów w środku listy będzie wolny
• zwykłe połączone listy (ang. Linked List) mają ponad 40 bajtów na wpis, natomiast ZIPLIST mają narzut w zakresie od 1 bajtu do 10 bajtów na wpis
  • jeśli przechowujesz milion liczb całkowitych na połączonej liście, rozmiar danych wynosi 4 MB, ale narzut to ponad 40 MB. Jeśli przechowujesz to samo na liście zip, rozmiar danych wynosi 4 MB, a narzut około 1 MB
• posortowany zestaw (ang. Sorted Set) jest strukturą danych Redis z największym narzutem
  • w porównaniu z listą, narzut pamięci wynosi ponad 200%
• zastanów się nad wykorzystaniem kompresji po stronie aplikacji, patrz: How we cut down memory usage by 82%
  • jeśli przechowywane dane są wystarczająco duże, często można zmniejszyć zużycie pamięci, dodając kompresję

• aby zidentyfikować wszystkie duże klucze w swojej instancji, wykorzystaj polecenie redis-cli --bigkeys

• ustawiaj automatyczne wygaszanie rzadko używanych danych

• stosuj odpowiednią politykę usuwania
  • jeśli ilość przechowywanych danych, rośnie z czasem i nie możesz pozwolić sobie na przechowywanie ich wszystkich w pamięci, prawdopodobnie chcesz skonfigurować Redis jako pamięć podręczną LRU
  • Redis zapewnia kilka zasad eksmisji a za ich konfigurację odpowiada parametr maxmemory-policy

• użyj map bitowych do kodowania danych, patrz: Redis Bitmaps – Fast, Easy, Realtime Metrics

• kodowania tego samego typu danych na instancjach Master/Slave może być różne, co pozwala na bardziej elastyczne podejście do wymagań

• powstrzymaj się od generowania dynamicznych skryptów, które mogą spowodować wzrost pamięci podręcznej Lua i wymknąć się spod kontroli
  • jeżeli masz załadowane takie skrypty, może to szybko wysycić pamięć
  • jeśli musisz używać dynamicznych skryptów, po prostu użyj zwykłego EVAL, ponieważ nie będą wstępnie ładowane
  • pamiętaj, aby śledzić zużycie pamięci Lua i okresowo opróżniać pamięć podręczną za pomocą SCRIPT FLUSH
• aby odzyskać pamięć, możesz wykonać jeden z trzech poniższych kroków:
  • zrestartuj proces Redisa, pamiętaj jednak, że w przypadku dużej ilości danych ich załadowanie do pamięci może zająć trochę czasu
  • uruchom cyklicznie skanowanie, co pomaga w odzyskaniu pamięci wygasłych kluczy. Redis używa strategii leniwego wygasania, klucze, które już wygasły, mogą nie zostać natychmiast usunięte. Jeśli jednak uzyskasz dostęp do klucza (za pomocą skanowania lub innych poleceń) i okaże się, że wygasł, zostanie on natychmiast usunięty, a powiązana pamięć również zostanie zwolniona
  • użyj aktywnej defragmentacji (patrz: activedefrag) zwiększając próbki pamięci w pliku konfiguracyjnym
    • umożliwia kompaktowanie przestrzeni umożliwiając w ten sposób odzyskanie pamięci
    • zwiększenie wartości może spowodować, że wygasłe klucze są szybciej odzyskiwane
• staraj się przechowywać obiekty jako pola i wartości dostępne za pośrednictwem jednego klucza zamiast poddawać je serializacji (czyli konwertowania obiektu do strumienia bajtów w celu przechowywania go lub przesyłania do pamięci czy pliku)
  • staraj się unikać serializacji
  • upewnij się, że serializujesz tylko to, czego potrzebujesz
  • użycie skrótu oszczędza serwerom pracy polegającej na pobieraniu całej zserializowanej wartości, deserializacji, aktualizowaniu, ponownej serializacji i wreszcie zapisywaniu z powrotem do pamięci podręcznej
• użyj struktury HyperLogLog do liczenia unikalnych wartości takich jak adresy IP, adresy e-mail, nazwy użytkowników czy wyszukiwane hasła
  • zużywa maksymalnie 12 kilobajtów pamięci i generuje przybliżenia ze standardowym błędem 0,81% (patrz: Big Data Counting: How To Count A Billion Distinct Objects Using Only 1.5KB Of Memory)

Dodatkowo poniżej znajduje się krótki, ale bardzo konkretny cheatsheet, który znalazłem jakiś czas temu, badając temat optymalizacji pamięci:

Wspomnę jeszcze o poleceniu DEBUG OBJECT, które wyświetla informacje m.in. o kodowaniu obiektów:

• łańcuchy mogą być kodowane jako raw (normalne kodowanie ciągów) lub int (ciągi reprezentujące liczby całkowite w 64-bitowym przedziale ze znakiem są kodowane właśnie w ten sposób, aby zaoszczędzić miejsce)

• listy mogą być kodowane jako ziplist (która jest specjalną reprezentacją pozwalającą zaoszczędzić miejsce na małe listy) lub linkedlist

• zestawy mogą być kodowane jako intset (to specjalne kodowanie używane dla małych zestawów składających się wyłącznie z liczb całkowitych) lub hashtable

• skróty mogą być kodowane jako ziplist (używane dla małych skrótów) lub hashtable

• sortowane zestawy mogą być zakodowane w formacie ziplist (dla małych sortowanych list) lub skiplist (dla posortowanych zestawów o dowolnej wielkości)

Wiele typów danych w Redisie jest kodowanych w bardzo wydajny sposób i zoptymalizowanych tak, aby zajmowały jak najmniej miejsca. Parametry konfiguracji, które się do tego odnoszą i które możesz zoptymalizować to:

hash-max-ziplist-entries 512
hash-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
set-max-intset-entries 512

Jeśli specjalnie zakodowana wartość przekracza skonfigurowany maksymalny rozmiar, Redis automatycznie skonwertuje ją na normalne kodowanie. Ta operacja jest bardzo szybka w przypadku małych wartości, ale jeśli zmienisz ustawienie, aby użyć specjalnie zakodowanych wartości dla znacznie większych typów, sugeruje się wykonanie niektórych testów porównawczych w celu sprawdzenia czasu konwersji. Dlatego nie zalecam zmiany w ciemno i proponuję posiłkować się oficjalną dokumentacją. Na przykład zwiększenie wartości set-max-intset-entries zwiększa opóźnienie operacji na zestawach (SET), a także zwiększa się wykorzystanie procesora.

Niezwykle ważnym poleceniem pomocnym w przypadku badania wykorzystania pamięci jak i występujących z nią problemów jest komenda INFO memory:

127.0.0.1:6379> INFO memory
# Memory
used_memory:2111424
used_memory_human:2.01M
used_memory_rss:4734976
used_memory_rss_human:4.52M
used_memory_peak:6191800
used_memory_peak_human:5.90M
used_memory_peak_perc:34.10%
used_memory_overhead:2058370
used_memory_startup:791616
used_memory_dataset:53054
used_memory_dataset_perc:4.02%
allocator_allocated:2557080
allocator_active:2969600
allocator_resident:8212480
total_system_memory:2095890432
total_system_memory_human:1.95G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:1024000000
maxmemory_human:976.56M
maxmemory_policy:noeviction
allocator_frag_ratio:1.16
allocator_frag_bytes:412520
allocator_rss_ratio:2.77
allocator_rss_bytes:5242880
rss_overhead_ratio:0.58
rss_overhead_bytes:-3477504
mem_fragmentation_ratio:2.29
mem_fragmentation_bytes:2664568
mem_not_counted_for_evict:0
mem_replication_backlog:1048576
mem_clients_slaves:33844
mem_clients_normal:183998
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

Metryka mem_fragmentation_ratio pokazuje stosunek pamięci przydzielonej przez system operacyjny (used_memory_rss) do pamięci używanej (used_memory). W tym przypadku used_memory i used_memory_rss będą już zawierały zarówno same dane, jak i koszty przechowywania wewnętrznych struktur. Redis traktuje RSS (ang. Resident Set Size) jako ilość pamięci przydzielonej przez system operacyjny, w której oprócz danych użytkownika (i kosztu ich wewnętrznej reprezentacji), koszty fragmentacji są brane pod uwagę, gdy sam system operacyjny fizycznie przydziela pamięć.

W praktyce, jeśli wartości mem_fragmentation_ratio wykraczają poza granice 1-1.5, oznacza to, że coś jest nie tak. Co w takim wypadku zrobić? Najprostszym rozwiązaniem jest restart instancji Redis — im dłużej proces, do którego aktywnie piszesz, działa bez ponownego uruchamiania, tym wyższy będzie mem_fragmentation_ratio. Na przykład wartość 2.1 mówi nam, że używamy 210% więcej pamięci, niż potrzebujemy. Wartość mniejsza niż 1 wskazuje, że pamięć się skończyła i system operacyjny się zamieni.

Współczynnik fragmentacji nie jest wiarygodny, gdy maksymalne użycie pamięci jest znacznie większe niż obecnie używana pamięć. Fragmentacja jest obliczana jako faktycznie wykorzystana pamięć fizyczna (wartość RSS, która odzwierciedla szczytową pamięć) podzielona przez ilość aktualnie używanej pamięci (jako suma wszystkich alokacji). Gdy używana pamięć jest niska, np. z powodu zwolnienia kluczy/wartości, ale RSS jest wysoki, stosunek RSS/mem_used będzie bardzo wysoki.

Tak naprawdę, jeśli metryka wskaźnika wykorzystania pamięci przekracza 80%, oznacza to, że jesteśmy blisko całkowitego wykorzystania pamięci. Jeśli nie podejmiesz żadnych działań, a użycie pamięci będzie nadal rosło, ryzykujemy awarię z powodu niewystarczającej ilości pamięci. Jeśli metryka szybko wzrasta do 80% i nadal rośnie, być może została użyta jedna z operacji intensywnie wykorzystujących pamięć. Na przykład wykonanie komendy BGSAVE, która wykorzystuje kopiowanie przy zapisie, w zależności od rozmiaru danych, objętości zapisu, może wymagać dwukrotnie więcej pamięci niż miejsca zajmowanego przez dane. Widzimy, że parametr fragmentacji jest kluczowym parametrem, który powinniśmy monitorować.

Drugą przydatną komendą jest INFO commandstats, która wyświetla statystyki komend i liczbę wywołań od momentu uruchomienia serwera lub ostatniego wywołania CONFIG RESETSTAT:

localhost:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=2015,usec=5867,usec_per_call=2.91
cmdstat_set:calls=2085,usec=19719,usec_per_call=9.46
cmdstat_setex:calls=89703,usec=1249687,usec_per_call=13.93
cmdstat_del:calls=88530,usec=1537560,usec_per_call=17.37
cmdstat_select:calls=302400,usec=577069,usec_per_call=1.91
cmdstat_keys:calls=1,usec=300,usec_per_call=300.00
cmdstat_scan:calls=1,usec=6,usec_per_call=6.00
cmdstat_dbsize:calls=2,usec=5,usec_per_call=2.50
cmdstat_auth:calls=6853034,usec=22901637,usec_per_call=3.34
cmdstat_ping:calls=12538371,usec=15151843,usec_per_call=1.21
cmdstat_multi:calls=7,usec=31,usec_per_call=4.43
cmdstat_exec:calls=28,usec=26823,usec_per_call=957.96
cmdstat_psync:calls=2,usec=1725,usec_per_call=862.50
cmdstat_replconf:calls=22,usec=36,usec_per_call=1.64
cmdstat_flushdb:calls=29,usec=984,usec_per_call=33.93
cmdstat_info:calls=7688890,usec=230663501,usec_per_call=30.00
cmdstat_debug:calls=1,usec=22344,usec_per_call=22344.00
cmdstat_subscribe:calls=26,usec=106,usec_per_call=4.08
cmdstat_publish:calls=8137206,usec=62551238,usec_per_call=7.69
cmdstat_client:calls=58,usec=58,usec_per_call=1.00
cmdstat_eval:calls=2015,usec=101008,usec_per_call=50.13
cmdstat_command:calls=2,usec=1898,usec_per_call=949.00

Już na sam koniec inne ciekawe zasoby:

• Quicklist Final
• Adventures in Encodings
• Storing hundreds of millions of simple key-value pairs in Redis
• Understanding Redis hash-max-ziplist-entries

Przesunięcie replikacji

Jednym z najważniejszych etapów procesu replikacji jest synchronizacja danych. Redis w nowszych wersjach wykorzystuje polecenie PSYNC, które służy do synchronizacji danych między instancjami. Polecenie to wymaga obsługi kilku komponentów, w tym przesunięcia replikacji (ang. replication offset). Jest to taki parametr, który mówi, jak daleko w aktualności danych są od siebie Master i Slave. Przy okazji zerknij do świetnego artykułu An in-depth explanation of redis master-slave replication principle, który bardzo dokładnie wyjaśnia synchronizację danych i replikację w Redisie.

Instancja główna po przetworzeniu poleceń zapisu, podczas ustanawiania replikacji, najpierw zrzuca swoją pamięć do pliku RDB (domyślnie), a następnie wysyła dane do swoich instancji podrzędnych w celu ich zsynchronizowania. Kiedy Slave zakończy odbieranie pliku RDB, ładuje go do swojej pamięci. Podczas tych kroków wszystkie polecenia zapisu do instancji głównej będą buforowane w specjalnym buforze i są wysyłane raz jeszcze do replik po ich załadowaniu.

Dobrze, w takim razie, jakie warunki muszą zostać spełnione, aby replikacja w ogóle została rozpoczęta i jaki związek z całym procesem ma wspomniane przesunięcie? Z punktu widzenia mistrza, musi on stwierdzić dostępność instancji podrzędnych. W tym celu wysyłane są pingi w ustalonych odstępach czasu. Można dostosować ten interwał, ustawiając odpowiednią wartość w parametrze repl-ping-slave-period (domyślna wartość to 10 sekund) w pliku konfiguracyjnym lub z poziomu konsoli. Natomiast z punktu widzenia repliki, wysyła ona REPLCONF ACK {offset} co sekundę, aby zgłosić swoje przesunięcie replikacji. Zarówno dla potwierdzenia PING, jak i REPLCONF ACK istnieje limit czasu określony przez limit czasu replikacji, a jego domyślną wartością jest 60 sekund. Jeśli przerwa między dwoma pingami lub REPLCONF ACK jest dłuższa niż ten limit, lub nie ma ruchu danych między instancjami główną a podrzędną w ramach takiego limitu czasu replikacji, połączenie replikacji zostanie przerwane. Tym sposobem Slave będzie musiał zainicjować kolejne żądanie replikacji.

W rzeczywistym środowisku produkcyjnym wartość repl-ping-slave-period musi być mniejsza niż wartość repl-timeout. W przeciwnym razie limit czasu replikacji zostanie osiągnięty za każdym razem, gdy będzie niewielki ruch między węzłami nadrzędnymi i podrzędnymi. Zwykle operacja blokowania może spowodować przekroczenie limitu czasu replikacji, ponieważ silnik przetwarzania poleceń serwera Redis jest jednowątkowy. Aby zapobiec przekroczeniu limitu czasu replikacji, należy postarać się unikać używania długich poleceń blokujących wykorzystując np. potoki. W większości przypadków wystarczająca jest domyślna wartość limitu równa 60 sekund.

Przesunięcie replikacji jest czymś naturalnym i pojawia się na przykład wtedy, kiedy ilość synchronizowanych danych nie jest taka sama na instancji głównej i podrzędnej. Pozwala ono ocenić, czy dane znajdujące się na każdym węźle są spójne. Może też jednak wskazywać, że instancja nadrzędna nie jest wystarczająco szybka lub występują problemy sieciowe, tj. sieć jest niskiej jakości albo jest po prostu przeciążona. Może też być kombinacją obu przypadków.

Przejdźmy może od razu do przykładów:

# Replication
role:master
connected_slaves:1
slave0:ip=192.168.10.20,port=6379,state=online,offset=121483,lag=0
slave1:ip=192.168.10.30,port=6379,state=online,offset=121483,lag=0
master_repl_offset:121483
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:121482

Interesują nas dwie wartości: przedostatni element parametru slave0 i slave1 oraz wartość parametru master_repl_offset. W tym przykładzie widzimy, że mają one taką samą wartość równą 121483, co oznacza, że obie repliki są idealnie wyrównane.

Jeżeli mielibyśmy taką sytuację:

slave0:ip=192.168.10.20,port=6379,state=online,offset=121483,lag=0
slave1:ip=192.168.10.30,port=6379,state=online,offset=121490,lag=0
master_repl_offset:121490

To replika slave0 byłaby za instancją główną o 7 bajtów i jest to różnica między wartością przesunięcia parametru master_repl_offset a wartością offsetu w wierszu slave0. Liczba przesunięć może się różnić w zależności od danego środowiska i warunków, jakie w nim panują. Idąc za tym, każda z instancji podrzędnym może mieć własną wartość przesunięcia, co jest zrozumiałe. Ostatni parametr, tj. lag określa czas w sekundach, kiedy replika odesłała „potwierdzenie” (ACK). Wskazuje on na opóźnienie replikacji, oraz że instancje podrzędne starają się nadążyć za zmianami, jakie zachodzą w węźle głównym. Może to być spowodowane zbyt dużą szybkością zmian lub zbyt dużym obciążeniem.

Podczas przełączania awaryjnego, jeśli instancja podrzędna nie jest zgodny z PSYNC, czasami poprosi o pełną synchronizację danych od mistrza. Jeśli zestaw danych jest dość duży, załadowanie całego zestawu danych i nowego elementu głównego zajmie trochę czasu, aby działał.

Powodem wzrostu wartości parametru master_repl_offset mogą być sytuacje, gdy:

• dochodzi do zmiany danych na instancji głównej
• urządzenie nadrzędne wysyła PING do urządzeń podrzędnych

W celu weryfikacji synchronizacji możesz wywołać polecenie CLIENT LIST podczas synchronizacji. Zwraca ono m.in. informacje o replikacji, wywołanej komendzie (cmd = sysc / psysc i odpowiednia flaga) czy ilości pamięci używanej przez bufor klienta.

Jeżeli chodzi o wyjście polecenia INFO, to mówiąc dokładniej, różnica między przesunięciem master_repl_offset a offsetem repliki jest ilością danych, które nie są replikowane (lub potwierdzone) w bajtach. Jeśli liczba jest duża, na przykład w przypadku nieprawidłowego wyłączenia mistrza, może nastąpić częściowa utrata danych. Parametr repl_backlog jest przeznaczony tylko dla polecenia PSYNC. Natomiast parametr repl_backlog_size to pojemność bufora (pamięci do śledzenia ostatnich zmian) przechowującego dane dla PSYNC. Ten bufor jest używany przez repliki do szybkiego nadrobienia zaległości po ponownym połączeniu zamiast przesyłania całej bazy danych. Parametr repl_backlog_histlen to ilość rzeczywistych danych w buforze i może wzrosnąć tylko do rozmiaru repl_backlog_size, więc bardzo często wartości obu parametrów są równe.

Pojawia się jeszcze jeden parametr, tzw. przesunięcie pierwszego bajtu zaległości przechowywane w repl_backlog_first_byte_offset, który jest równy maksymalnemu rozmiarowi bufora (repl_backlog_size), który to jest również równy aktualnie zapełnionym danym bufora (repl_backlog_histlen). Idąc za tym, master_repl_offset - repl_backlog_first_byte_offset = repl_backlog_size powinien oznaczać dokładny offset danych. Natomiast na intancjach Slave możesz zauważyć jeszcze jeden ciekawy parametr, tj. master_sync_in_progress, który wskazuje status synchronizacji mistrza z repliką.

Rzeczywiste opóźnienie jest więc różnicą między każdym przesunięciem na instancji podrzędnej a przesunięciem master_repl_offset. Tak więc gdyby na jednej replice przesunięcie wyniosło 616524735501 a na Masterze 616524769598 to całkowita wartość danych, których brakuje replice do osiągnięcia stanu replikacji mistrza wyniosłaby 34097 bajty (34 KB).

Wiemy już, że dane replikacji są wysyłane z instancji nadrzędnej do instancji podrzędnych asynchronicznie, a repliki okresowo odsyłają pakiety zwrotne w celu potwierdzenia otrzymanych danych. Możemy zadać pytanie, czy przesunięcie replikacji można zoptymalizować? Zerknijmy najpierw na fragment źródeł znajdujący się w pliku replication.c:

void replicationCron(void) {
...
    if (server.masterhost && server.master &&
        !(server.master->flags & CLIENT_PRE_PSYNC))
        replicationSendAck();
...
}

Powyższa metoda odpowiada za wysyłanie od czasu do czasu potwierdzeń do mistrza, który musi obsługiwać częściową synchronizację oraz przesunięcia replikacji. Natomiast wywołanie tej funkcji odbywa się z poziomu głównego pliku źródłowego serwera, tj. server.c:

int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
...
    run_with_period(1000) replicationCron();
...
}

Powoduje to ponowne łączenie się z mistrzem, wykrywanie ewentualnych błędów transferu czy rozpoczynania transferów RDB w tle. Metoda repliationCron() jest wywoływana N razy na sekundę z makrem run_with_period, które dodaje pewien interwał liczony w milisekundach. Dlatego im krótsza jest ta przerwa, tym mniejsza powinna być luka przesunięcia replikacji. Aby skrócić przesunięcie, należy zmienić wartość parametru server.hz, którego wartość pochodzi z opcji hz konfiguracji i domyślnie wynosi 10 sekund. Zgodnie z tym czas połączenia z serwerem nadrzędnym wykonywany jest co 10 sekund. Jednak przed przystąpieniem do modyfikowania tej wartości koniecznie zajrzyj do pliku konfiguracyjnego, w którym wyjaśniono, do czego może doprowadzić jej modyfikacja i jakie wartości są zalecane.

To, jak działa replikacja w Redisie zostało dokładnie opisane w rozdziale How Redis replication works oficjalnej dokumentacji dlatego bardzo zachęcam do zapoznania się z nim. W przypadku problemów, Redis dostarcza specjalny tryb, w którym mierzone są wszelkie opóźnienia. Aby z niego skorzystać, musisz przy uruchamianiu podać parametr --latency. Istnieje też potężne polecenie, które zgłasza różne problemy związane z opóźnieniami i informuje o możliwych środkach zaradczych. Jeżeli chcesz z niego skorzystać, wykonaj LATENCY DOCTOR w konsoli Redisa. Dokładne informacje o debugowaniu problemów z opóźnieniami i replikacji znajdziesz w poniższych zasobach:

• How fast is Redis?
• Redis latency problems troubleshooting
• Redis latency monitoring framework
• Thoughts on Redis Performance
• Understanding latency using Redis-Cli

Jeżeli zależy Ci na monitorowaniu tych wszystkich parametrów, to moim zdaniem idealnie nada się do tego Zabbix. Po więcej informacji zerknij tutaj.

Natomiast jeśli chcesz przeprowadzić testy replikacji czy opóźnień i potrzebujesz wygenerować dużą ilość danych, zapoznaj się z projektem redis-random-data-generator. Możesz także użyć innej metody. Jeżeli chcesz wygenerować wiele kluczy, możesz wykonać jedną z poniższych komend z poziomu konsoli. Jednak uważaj! Wykonanie jednego z poniższych skryptów doprowadzi do niedostępności Redisa i w przypadku działania Sentinela dojdzie do rozpoczęcia procesu przełączania awaryjnego, co doprowadzi w konsekwencji do nadpisania tych danych danymi znajdującymi się w nowym mistrzu. Dlatego wykonuj je na izolowanym środowisku:

127.0.0.1:6379> eval "for i=0,1000000,1 do redis.call('set', i, i) end" 0
(nil)
(10.54s)

127.0.0.1:6379> eval "for i=0,1000000,1 do local bucket=math.floor(i/500); redis.call('hset', bucket, i, i) end" 0
(nil)
(10.41s)

127.0.0.1:6379> eval "for i=0,1000000,1 do local b=math.floor(i/500); redis.call('hset', 'usernames:' ..b, i, i) end" 0
(nil)
(10.38s)

HAProxy

Mając poprawnie zestawioną replikację, nie pozostaje nam nic innego jak przekazać architektom i developerom namiary na serwer nadrzędny, do którego będą się łączyć. Tym samym nasza praca dobiegła końca.

Nic z tych rzeczy. Pomyśl, co się stanie jeśli Master ulegnie awarii i będziemy musieli awansować jedną z replik do nowej roli? Z naszej strony będzie to 5 minut pracy, jednak taką samą pracę (jak nie większą) będą musieli wykonać architekci, którzy zmuszeni będą zaktualizować konfigurację aplikacji, tak aby wskazywała na adres IP nowego mistrza. Wyobraź sobie, że taka sytuacja powtarza się kilkukrotnie, co spowoduje tylko niepotrzebną irytacją. Tutaj z pomocą przychodzi omawiane wcześniej HAProxy.

W jednym z początkowych rozdziałów stwierdziłem, że wykorzystanie HAProxy w tym zestawie wprowadza pewną inteligencję, dzięki której serwer nadrzędny jest automatycznie wykrywany na każdym węźle, więc jeśli działa, aplikacja zawsze pisze do niego. Dzięki temu aplikacja nie komunikuje się bezpośrednio z Redisem tylko z odpowiednim lokalnym gniazdem, na którym nasłuchuje HAProxy. Dla aplikacji całe rozwiązanie jest całkowicie transparentne i nie wymaga ciągłych zmian po stronie kodu. Oczywiście możliwości jest więcej a inną alternatywą opartą na HAproxy jest skonfigurowanie go tak, aby odseparował zapisy i odczyty i kierował je do różnych backendów.

W pierwszej kolejności zainstalujemy HAProxy z repozytorium SCL oraz włączymy usługę, aby uruchamiała się podczas startu systemu:

yum install rh-haproxy18
systemctl enable rh-haproxy18-haproxy

HAProxy dostępne w głównym repozytorium CentOS nie działa poprawnie i sprawia problemy z Redisem w wersji 5 i wyższymi, dlatego instalację przeprowadziłem z wersją RH. Konfiguracja HAProxy do współpracy z Redisem jest niezwykle prosta i najczęściej wygląda tak:

global
  pidfile /var/run/haproxy.pid
  log 127.0.0.1 local0 info
  user haproxy
  group haproxy
  maxconn 512
  nbproc 2
  nbthread 2

defaults redis
  mode tcp
  timeout connect 4s
  timeout server 10s
  timeout client 10s
  log global
  option tcplog

frontend http
  bind *:8080
  default_backend stats

backend stats
  mode http
  stats enable
  stats uri /
  stats refresh 5s
  stats show-legends
  stats auth ha-admin:piph1NeiceHe

frontend ft_redis
  bind :16379 name redis
  default_backend bk_redis

backend bk_redis
  log global
  option tcp-check
  tcp-check send AUTH\ meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2\r\n
  tcp-check expect string +OK
  tcp-check send PING\r\n
  tcp-check expect string +PONG
  tcp-check send info\ replication\r\n
  tcp-check expect string role:master
  tcp-check send QUIT\r\n
  tcp-check expect string +OK
  server R1 192.168.10.10:6379 check inter 1s
  server R2 192.168.10.20:6379 check inter 1s
  server R3 192.168.10.30:6379 check inter 1s

W zależności od wybranego źródła instalacji w systemie CentOS dodajemy ją do pliku /etc/haproxy/haproxy.cfg lub /etc/opt/rh/rh-haproxy18/haproxy/haproxy.cfg (w naszym przypadku) na każdym serwerze, na którym działają wszystkie usługi.

Taka konfiguracja jest dobra, ale pod warunkiem, że w naszym środowisku nie wykorzystujemy Redis Sentinela a przełączanie awaryjne wykonywane jest przez administratora — co jak się domyślasz, może być katorżniczym wyzwaniem. Jeżeli wykorzystujemy Sentinele to taka konfiguracja jest bardzo mocno niezalecana a wręcz niepoprawna w przypadku kiedy zależy nam, aby nie doszło do uszkodzenia ani utraty danych.

Dlaczego? Wyobraź sobie następującą sytuację. Jeżeli podczas pracy wystąpią pewne problemy z siecią, może dojść do sytuacji, że jedna z replik zostanie awansowana do roli nadrzędnej, podczas gdy stary Master nie będzie dostępny (zostanie odizolowany od reszty). Jeśli stary mistrz wróci to trybu online, nadal będzie miał rolę Master, a HAProxy uzna obie instancje jako prawidłowy backend, więc będzie wysyłać zapytania do obu nawet przez kilka sekund, do momentu, aż Sentinele nie rozwiążą tej sytuacji, degradując starego mistrza do roli instancji podrzędnej.

Główną ideą działania HAProxy jest to, że stara się on wykryć serwery główne poprzez wysyłanie zapytań do każdego ustawionego backendu. Jeżeli dojdzie do sytuacji podobnej jak wyżej, HAProxy będzie widziało dwa węzły główne, co spowoduje pisanie raz do jednego i raz do drugiego. W przypadku środowisk, gdzie tolerancja na utratę danych jest wysoka, nie będzie to problemem, jednak tam, gdzie dane są niezwykle krytyczne, dojdzie do ich nieodwracalnej utraty. Jeżeli wymagania biznesowe nie stawiają przed aplikacją przymusu odpowiedniego dbania o przechowywane dane w Redisie, konfiguracja HAProxy zaprezentowana wyżej sprawdzi się doskonale.

Natomiast jeśli wymagania są inne, należy mieć świadomość potencjalnych problemów, a także komplikacji w przypadku wykorzystania Redisa i Sentineli w połączeniu z HAProxy. Rozwiązaniem tych problemów jest dostosowanie HAProxy tak, aby pobierał informacje o aktualnym mistrzu wprost z działających Sentineli, które powinny być autorytetami w dostarczaniu wszelkich danych o działających instancjach i to niezależnie od ich roli. Czyli cały mechanizm przełączania instancji głównej z poziomu HAProxy będzie polegał na monitorowaniu i odpytywaniu wartowników. Moim zdaniem, powinniśmy zawsze odpytywać Sentinele, aby zminimalizować niepotrzebną utratę danych zapisywanych do Redisa (nawet, jeśli nie zapisujemy ich na dysk) oraz wykluczyć problemy w przypadku działaniu dwóch instancji głównych.

Długo szukałem za rozwiązaniem tego problemu i odpowiednim dostrojeniu konfiguracji HAProxy. Przykład zmodyfikowanej konfiguracji znajduje się poniżej:

global
  pidfile /var/run/haproxy.pid
  log 127.0.0.1 local0 info
  user haproxy
  group haproxy
  maxconn 512
  nbproc 2
  nbthread 2

defaults redis
  mode tcp
  timeout connect 4s
  timeout server 10s
  timeout client 10s
  log global
  option tcplog

frontend http
  bind *:8080
  default_backend stats

backend stats
  mode http
  stats enable
  stats uri /
  stats refresh 5s
  stats show-legends
  stats auth ha-admin:piph1NeiceHe

backend check_sentinel_R1
  mode tcp
  option tcp-check
  tcp-check connect
  tcp-check send AUTH\ meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2\r\n
  tcp-check expect string +OK
  tcp-check send PING\r\n
  tcp-check expect string +PONG
  tcp-check send SENTINEL\ master\ mymaster\r\n
  tcp-check expect string 192.168.10.10
  tcp-check send QUIT\r\n
  tcp-check expect string +OK

server S1 192.168.10.10:26379 check inter 2s
server S2 192.168.10.20:26379 check inter 2s
server S3 192.168.10.30:26379 check inter 2s

backend check_sentinel_R2
  mode tcp
  option tcp-check
  tcp-check connect
  tcp-check send AUTH\ meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2\r\n
  tcp-check expect string +OK
  tcp-check send PING\r\n
  tcp-check expect string +PONG
  tcp-check send SENTINEL\ master\ mymaster\r\n
  tcp-check expect string 192.168.10.20
  tcp-check send QUIT\r\n
  tcp-check expect string +OK

server S1 192.168.10.10:26379 check inter 2s
server S2 192.168.10.20:26379 check inter 2s
server S3 192.168.10.30:26379 check inter 2s

backend check_sentinel_R3
  mode tcp
  option tcp-check
  tcp-check connect
  tcp-check send AUTH\ meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2\r\n
  tcp-check expect string +OK
  tcp-check send PING\r\n
  tcp-check expect string +PONG
  tcp-check send SENTINEL\ master\ mymaster\r\n
  tcp-check expect string 192.168.10.30
  tcp-check send QUIT\r\n
  tcp-check expect string +OK

server S1 192.168.10.10:26379 check inter 2s
server S2 192.168.10.20:26379 check inter 2s
server S3 192.168.10.30:26379 check inter 2s

frontend ft_redis
  bind *:16379
  mode tcp
  acl network_allowed src 127.0.0.1 192.168.10.0/24
  tcp-request connection reject if !network_allowed
  timeout connect 4s
  timeout server 15s
  timeout client 15s
  use_backend bk_redis

backend bk_redis
  mode tcp
  tcp-check send PING\r\n
  tcp-check expect string +PONG

use-server R1-SERVER if { srv_is_up(R1-SERVER) } { nbsrv(check_sentinel_R1) ge 2 }
use-server R2-SERVER if { srv_is_up(R2-SERVER) } { nbsrv(check_sentinel_R2) ge 2 }
use-server R3-SERVER if { srv_is_up(R3-SERVER) } { nbsrv(check_sentinel_R3) ge 2 }
server R1-SERVER 192.168.10.10:6379 check inter 2s
server R2-SERVER 192.168.10.20:6379 check inter 2s
server R3-SERVER 192.168.10.30:6379 check inter 2s

Powyższa konfiguracja i taki sposób działania HAProxy powoduje, że:

• jeśli Sentinele nie będą w stanie wykryć instancji głównej, nie dojdzie do zapisów, splitów oraz utraty danych
• jeśli nie zapewnimy większości, Sentinel nie wypromuje działającej repliki na mistrza, nie dojdzie do zapisów, splitów oraz utraty danych
• jeśli Sentinele wykryją instancję główną a w tym czasie inna replika stanie się mistrzem, ruch kierowany będzie nadal do poprawnego węzła

Przekazanie komendy AUTH w drugim przykładzie jest wymagane wtedy, kiedy w konfiguracji Redis Sentinela ustawiony został parametr requirepass. Nie uruchamiajmy jeszcze HAProxy i poczekajmy do wyjaśnienia jeszcze kilku dodatkowych i istotnych kwestii.

Oczywiście warunkiem działania i jednocześnie pewnym minusem takiej konfiguracji jest ciągły wymóg dostępności przynajmniej jednego z Sentineli i instancji głównej, dlatego jedną z gwarancji ich działania powinno być kompletne odseparowania procesów Redis i Redis Sentinel od siebie (uruchomienie ich na całkowicie odrębnych serwerach). Problem może pojawić się także w sytuacji, w której z pewnych względów Sentinele nie będą mogły dostarczyć informacji o aktualnym mistrzu.

Innym problemem może być sytuacja, w której aktualny Master jest zamykany, a jedna z replik jest promowana w jego miejsce i musi załadować duży zestaw danych do pamięci lub kiedy nie odebrała od niego wszystkich danych. Może to spowodować awarię klientów jeśli nie są poprawnie napisani (widzisz, że także klienci powinni wykrywać i obsługiwać awarie instancji głównej). Nie jest to błahy problem, ponieważ w obu powyższych konfiguracjach HAProxy nie jest świadome ilości przetworzonego strumienia replikacji, więc na tej podstawie nie jest w stanie stwierdzić, który backend jest odpowiedni. Nie wiem, czy jest w ogóle sens zaimplementowania takiego sprawdzania a jedyną zaletą, jaką widzę, jest ochrona przed niepotrzebnymi zapisami do nowego mistrza, który jeszcze nie odebrał wszystkich danych lub, co chyba najważniejsze, nie załadował wszystkich danych z plików podczas powrotu z awarii. Inna sprawa jest taka, że przesunięcia replikacji są czymś normalnym dlatego ich weryfikacja z poziomu HAProxy może powodować niepotrzebne rozłączanie. Po drugie, pamiętajmy, że jeśli przesunięcie jest zbyt duże, Sentiele posiadają mechanizmy chroniące przed wypromowaniem takiej repliki do roli nadrzędnej. Widzisz, że podczas projektowania i wdrożenia jednego z rozwiązań musisz rozważyć wszystkie za i przeciw.

Druga konfiguracja rozwiązuje jednak w 100% problem zapisywania do dwóch mistrzów naraz. Mimo tego, że nadal istnieje krótki przedział czasowy, w którym podczas przełączania awaryjnego mogą działać dwie instancje główne, to dzięki zastosowaniu takiej konfiguracji jesteśmy w stanie zawsze pisać do aktualnego Mastera widzianego z poziomu Sentineli i zmniejszyć czas ew. niedostępności i niedziałania replikacji do minimum.

Twemproxy

W poprzednim rozdziale przestawiłem rozwiązanie, które pomaga klientom komunikować się z Redisem tak, aby widziały i miały dostęp zawsze do aktualnej instancji nadrzędnej. W tym rozdziale natomiast omówię rozwiązania, które poprawiają wydajność, np. głównie w celu zmniejszenia liczby połączeń z instancjami Redis.

Istnieją cztery niezwykle ciekawe technologie:

• CodisLabs/codis
• Netflix/dynomite
• Facebook/mcrouter
• Twitter/twemproxy

Każdy z wyżej wymienionych projektów jest bardzo ciekawy i prezentuje inne możliwości. Codis jest rozwiązaniem typowo przeznaczonym do pracy z klastrem i składa się z kilku części dlatego jego wdrożenie może zając trochę czasu. Jednak jest to bardzo stabilne narzędzie, które dodatkowo zapewnia przyjemne GUI. Natomiast sporą wadą Dynomite jest brak obsługi polecenia AUTH, więc jeżeli zechcesz go uruchomić, musisz zapewnić odpowiednie mechanizmy bezpieczeństwa. Mcrouter natomiast został przystosowany głównie do działania z memcached więc nadaje się idealnie jeśli wykorzystujesz to rozwiązanie.

Jeżeli napotkałeś problemy z wydajnością i szukałeś rozwiązania tego problemu, na pewno natknąłeś się na narzędzie Twemproxy, które jest kolejnym rozwiązaniem podobnym do tutaj opisywanych. Twemproxy to niezwykle lekki i bardzo szybki serwer proxy, który przekazuje żądania do puli instancji Memcached lub Redis. Został on opracowany głównie w celu zmniejszenia liczby otwartych połączeń (można je zredukować nawet o 80%) z oboma typami serwerów pamięci podręcznej, dzięki multipleksowaniu i potokowaniu żądań przez pojedyncze połączenie z każdą instancją. Dzięki temu pozwala on na ponowne wykorzystanie połączeń sieciowych, znacznie zmniejszając obciążenie połączenia z demonami Redis.

Jego zastosowanie służy głównie poprawie wydajności poprzez utrzymywanie trwałych połączeń. Ma on jednak wiele innych istotnych funkcji, tj. gromadzenie żądań (ang. Command Pipelining) przeznaczonych dla tego samego hosta i wysyłanie ich jako jedną porcję danych, zapewnienie kilku algorytmów mieszania używanych do określania, gdzie umieścić określony klucz w wielowęzłowym systemie buforowania, automatyczne odłączanie niedziałających węzłów czy automatyczne dzielenie danych między wieloma serwerami pamięci podręcznej. Na temat pozostałych funkcji i zalet możesz poczytać w oficjalnym repozytorium.

Niestety projekt nie jest aktualizowany od dłuższego czasu (jako alternatywę możesz rozważyć Dynomite). Spotkałem się także z opiniami co do wątpliwej jakości samego kodu, co jeśli jest prawdą (nie byłem w stanie tego zweryfikować), moim zdaniem trochę dyskwalifikuje go do wykorzystania produkcyjnego. Jednak lista organizacji, które wykorzystują Twemproxy jest naprawdę bardzo długa. Oprócz paru minusów słyszałem także wiele pozytywnych opinii, w których praktycznie zawsze pojawiała się największa zaleta stosowania Twemproxy, którą zresztą mogę potwierdzić: to, że działa naprawdę bardzo stabilnie.

Jedną z wad Twemproxy jest konieczność ponownego uruchomienia procesu w przypadku zmiany konfiguracji. Może wydawać się to nieistotnym i nadmiernym zarzutem, jednak czas ponownego uruchomienia w zakresie 1-2 sekund może być zbyt dużym zakłóceniem dla łączących się klientów.

W naszym przykładzie wykorzystamy ostatnie z rozwiązań, czyli Twemproxy. Przed przystąpieniem do dalszego czytania zalecam zapoznać się z opisem projektu oraz oficjalnymi rekomendacjami.

W pierwszej kolejności pobieramy źródła projektu:

git clone https://github.com/twitter/twemproxy.git

Następnie instalujemy dodatkowe paczki:

yum install dh-autoreconf

Teraz możemy przejść do zbudowania binarki:

cd twemproxy
autoreconf -fvi
./configure --enable-debug=full
make

Następnie tworzymy katalog dla przyszłych konfiguracji oraz pod dzienniki, w których będziemy odkładać komunikaty zwracane przez Twemproxy:

mkdir /etc/twemproxy /var/log/twemproxy

Na koniec kopiujemy nowo skompilowany program do /usr/local/sbin:

cp src/nutcracker /usr/local/sbin/nutcracker

I testowo go uruchamiamy w celu weryfikacji czy działa:

nutcracker --help

Możemy przyjąć kilka strategii uruchomienia Twemproxy. Jedną z nich przedstawia poniższy zrzut:

Taka konfiguracja pozwala na dwie rzeczy:

• buforowanie zapytań kierowanych do instancji Redis
• automatyczne wykrywanie mistrza i na tej podstawie kierowanie zapytań już nie bezpośrednio do instancji nadrzędnej, tylko do procesu Twemproxy, który będzie komunikował się z mistrzem

Oczywiście jedną z kluczowych rzeczy jest odpowiednio skonfigurowane HAProxy, które będzie odpowiedzialne za ciągłe wykrywanie mistrza. Pojawia się jednak jeszcze jedna istotna kwestia. Mianowicie ile serwerów Redis ustawić po stronie Twemproxy? Aby nie komplikować sytuacji, możemy ustawić gniazdo tylko do lokalnej instancji Redis na danym serwerze, na którym działa Twemproxy a wykrywaniem i rozrzucaniem serwera głównego nadal będzie zajmował się HAProxy.

Konfigurację zapiszemy do pliku /etc/twemproxy/nutcracker.yml na każdym z węzłów i będzie ona wyglądała tak (kopiujemy tylko część przeznaczoną dla danej instancji i dodajemy ją do pliku konfiguracyjnego):

### R1 - 192.168.10.10 ###
redis_stack:
  listen: 192.168.10.10:36379
  hash: fnv1a_64
  hash_tag: "{}"
  distribution: ketama
  auto_eject_hosts: true
  server_retry_timeout: 5000
  server_failure_limit: 2
  timeout: 5000
  redis: true
  redis_auth: meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
  servers:
   - 127.0.0.1:6379:1 R1

### R2 - 192.168.10.20 ###
redis_stack:
  listen: 192.168.10.20:36379
  hash: fnv1a_64
  hash_tag: "{}"
  distribution: ketama
  auto_eject_hosts: true
  server_retry_timeout: 5000
  server_failure_limit: 2
  timeout: 5000
  redis: true
  redis_auth: meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
  servers:
   - 127.0.0.1:6379:1 R2

### R3 - 192.168.10.30 ###
redis_stack:
  listen: 192.168.10.30:36379
  hash: fnv1a_64
  hash_tag: "{}"
  distribution: ketama
  auto_eject_hosts: true
  server_retry_timeout: 5000
  server_failure_limit: 2
  timeout: 5000
  redis: true
  redis_auth: meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
  servers:
   - 127.0.0.1:6379:1 R3

W sekcji servers ustawiony został adres interfejsu pętli zwrotnej. Jeżeli zajdzie potrzeba komunikacji między instancjami Twemproxy należy ustawić adresy IP interfejsu zewnętrznego. Dokładny opis wszystkich dostępnych parametrów znajdziesz w repozytorium projektu.

Musimy jeszcze nadać mu odpowiednie uprawnienia i pamiętać o zrobieniu tego samego dla katalogu z logami:

chown -R redis:redis /etc/twemproxy
chown -R redis:redis /var/log/twemproxy

Teraz pozostaje jedynie przygotowanie serwisu pod systemd. Umieścimy go w pliku /usr/lib/systemd/system/twemproxy.service:

[Unit]
Description=Twemproxy (Nutcracker) Redis Proxy.
After=network.target

[Service]
ExecStart=/usr/local/sbin/nutcracker -v 5 -o /var/log/twemproxy/nutcracker.log -c /etc/twemproxy/nutcracker.yml
ExecStop=/bin/kill -SIGTERM $MAINPID
Restart=always
User=redis
Group=redis

[Install]
WantedBy=multi-user.target

Pozostało jeszcze przeładować konfigurację systemd oraz dodać nowy serwis do autostartu:

systemctl daemon-reload
systemctl enable twemproxy

Możemy teraz wystartować nową usługę:

systemctl start twemproxy

Mając poprawnie skonfigurowane usługi Redis i Redis Sentinel, możemy podpiąć się pod konsolę instancji nadrzędnej i utworzyć testowy klucz. Następnie podłączyć się przez Twemproxy i zweryfikować czy mamy połączenie:

# Tworzymy klucz na węźle głównym (R1):
redis.cli
127.0.0.1:6379> SET foo bar
OK

# Testujemy połączenie z wykorzystaniem Twemproxy:
./src/redis-cli --no-auth-warning -a meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2 -h 127.0.0.1 -p 36379 get foo
"bar"

W konfiguracji złożonej z trzech instancji Redis tj. 1x Master i 2x Slave oraz uruchomionej usłudze Redis Sentinel na każdym węźle, serwery podrzędne będą kopiami danych (tylko do odczytu) serwera nadrzędnego. Redis Sentinel będzie stale monitorował węzeł główny i jeśli ulegnie on awarii, jedna z replik zostanie awansowana do roli Master. Pozostałe instancje Slave zostaną ponownie skonfigurowane, aby były replikami nowego węzła głównego.

Mamy już dwie możliwe konfiguracje HAProxy, jednak musimy je dostosować do działania z Twemproxy. Wykorzystamy tą, która do zlokalizowania instancji głównej wykorzystuje Sentinele. Zmiana jest trywialna, ponieważ dotyczy sześciu ostatnich linijek:

# Przed zmianą:
use-server R1-SERVER if { srv_is_up(R1-SERVER) } { nbsrv(check_sentinel_R1) ge 2 }
use-server R2-SERVER if { srv_is_up(R2-SERVER) } { nbsrv(check_sentinel_R2) ge 2 }
use-server R3-SERVER if { srv_is_up(R3-SERVER) } { nbsrv(check_sentinel_R3) ge 2 }
server R1-SERVER 192.168.10.10:6379 check inter 2s
server R2-SERVER 192.168.10.20:6379 check inter 2s
server R3-SERVER 192.168.10.30:6379 check inter 2s

# Po zmianie:
use-server T1-SERVER if { srv_is_up(T1-SERVER) } { nbsrv(check_sentinel_R1) ge 2 }
use-server T2-SERVER if { srv_is_up(T2-SERVER) } { nbsrv(check_sentinel_R2) ge 2 }
use-server T3-SERVER if { srv_is_up(T3-SERVER) } { nbsrv(check_sentinel_R3) ge 2 }
server T1-SERVER 192.168.10.10:36379 check inter 2s
server T2-SERVER 192.168.10.20:36379 check inter 2s
server T3-SERVER 192.168.10.30:36379 check inter 2s

Po zmianie należy przeładować obie usługi:

# Wystartowanie HAProxy i przeładowanie konfiguracji Twemproxy
systemctl start rh-haproxy18-haproxy
systemctl restart twemproxy

Niestety nie uda się tego zrobić w przypadku HAProxy i włączonego SELinuxa. Musimy wygenerowany i dodać odpowiedni moduł:

mkdir /etc/haproxy/selinux
cd /etc/haproxy/selinux

# Wygenerować moduł:
ausearch -m avc -c haproxy | audit2allow -a -M haproxy-conf

# Podgląd zawartości:
cat haproxy-conf.te

module haproxy-conf 1.0;

require {
  type redis_port_t;
  type ephemeral_port_t;
  type haproxy_t;
  class tcp_socket { name_bind name_connect };
}

#============= haproxy_t ==============

#!!!! This avc can be allowed using one of the these booleans:
#     nis_enabled, haproxy_connect_any
allow haproxy_t ephemeral_port_t:tcp_socket name_connect;

#!!!! This avc is allowed in the current policy
allow haproxy_t redis_port_t:tcp_socket name_bind;

#!!!! This avc can be allowed using the boolean 'haproxy_connect_any'
allow haproxy_t redis_port_t:tcp_socket name_connect;

# Załadować moduł
semodule -i haproxy-conf.pp

Jeżeli obie usługi mamy uruchomione, spróbujmy ponownie uzyskać klucz tym razem łącząc się z wykorzystaniem HAProxy:

# Tworzymy klucz na węźle głównym (R1):
redis.cli
127.0.0.1:6379> SET xyz 123
OK

# Testujemy połączenie z wykorzystaniem HAProxy:
./src/redis-cli --no-auth-warning -a meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2 -h 127.0.0.1 -p 16379 get xyz
"123"

Wartą do zastanowienia rzeczą jest sposób komunikacji między aplikacją a HAProxy i Twemproxy. W tym zestawieniu aplikacja działająca na każdym webie będzie pukać zawsze do HAProxy, które będzie odpytywać Sentinele w celu uzyskania informacji o aktualnym mistrzu. Na podstawie tego ruch zostanie skierowany do usługi Twemproxy uruchomionej na tym samym serwerze co Master. Twemproxy będzie działać bezpośrednio przed instancją główną, dzięki czemu zapewnimy mechanizm buforowania zapytań i utrzymywania połączeń. W przypadku przełączania awaryjnego HAProxy będzie aktualizować lokalizację mistrza i kierować ruch do odpowiedniego procesu Twemproxy.

Pamiętajmy, że uzyskanie 100% dostępności jest praktycznie niemożliwe. Jednak czas powrotu działania wszystkich komponentów jak i działania mechanizmu wykrywania instancji głównej w przypadku wykorzystania powyższych usług jest bardzo mały.

Smitty + alternatywy

Oczywiście nic nie stoi na przeszkodzie, aby zrezygnować z HAProxy i kierować ruch z aplikacji bezpośrednio do Twemproxy (zyskamy wtedy na wydajności połączenia przez brak dodatkowego przeskoku sieciowego). Wszystko zależy tak naprawdę od wymagań i konkretnych potrzeb. Możemy również postawić HAProxy i Twemproxy (lub tylko to drugie) przed Redisem oraz uruchomić specjalnego agenta, który będzie monitorował instancję główną.

Do tego celu możemy wykorzystać projekt o nazwie Smitty. Jest to agent napisany w języku Go, którego głównym celem jest rozszerzenie możliwości HA serwerów proxy nawet po awarii węzła Redis. Aby to osiągnąć, Smitty stale monitoruje zdarzenia +switch-master łącząc się do Sentinela w celu ich wykrycia. Gdy dojdzie do takiej sytuacji, konfiguracja Twemproxy zostanie zaktualizowana o dane nowego mistrza i w konsekwencji automatycznie uruchomiona ponownie w celu załadowania zmian. Użycie agenta jest tutaj kluczowym elementem, ponieważ w przypadku awansu jednej z replik, przy takiej konfiguracji Twemproxy nadal będzie kierował ruch do starej instancji głównej.

Dzięki takiemu połączeniu wszystkich trzech technologii możemy zapewnić praktycznie doskonałą redundancję. W tym celu możemy w konfiguracji HAProxy pominąć sprawdzanie lokalizacji instancji nadrzędnej odpytując Sentinele i po prostu rozrzucać ruch między wszystkie procesy Twemproxy. Całą logiką wykrywania mistrza i dynamicznego dostosowywania konfiguracji Twemproxy będzie zajmował się proces Smitty.

Konfiguracja będzie wyglądać tak jak poniżej przy wykorzystaniu tego rozwiązania:

Oficjalne repozytorium Smitty przedstawia inną, równie ciekawą grafikę prezentującą wykorzystanie tej usługi. Pozwolę ją sobie umieścić:

To tyle tytułem krótkiego wstępu do tej usługi. Aby zbudować projekt, w pierwszej kolejności należy pobrać i zainstalować kompilator Go:

wget https://dl.google.com/go/go1.13.5.linux-amd64.tar.gz
tar -xvf go1.13.5.linux-amd64.tar.gz
mv go /usr/lib && ln -s /usr/lib/go/bin/go /usr/bin/go

Następnie instalujemy wymagane zależności:

yum install bzr

Oraz pobieramy i instalujemy pakiet główny:

go get github.com/areina/smitty
ln -s /root/go/bin/smitty /usr/local/sbin/smitty

Na koniec tworzymy katalog na przyszłe konfiguracje oraz logi:

mkdir /etc/smitty /var/log/smitty

Oraz weryfikujemy czy narzędzie działa:

smitty --help

Natomiast konfiguracja jest niezwykle prosta i sprowadza się głównie do ustawienia i dostosowania poniższych parametrów:

twemproxy_pool_name: "redis_stack"
twemproxy_config_file: "/etc/twemproxy/nutcracker.yml"
sentinel_ip: "127.0.0.1"
sentinel_port: "26379"
restart_command: "systemctl restart twemproxy"
log_file: "/var/log/smitty/agent.log"

Musimy jeszcze nadać mu odpowiednie uprawnienia i pamiętać o zrobieniu tego samego dla katalogu z logami:

chown -R root:root /etc/smitty
chown -R root:root /var/log/smitty

Teraz pozostaje jedynie przygotowanie serwisu pod systemd. Umieścimy go w pliku /usr/lib/systemd/system/smitty.service:

[Unit]
Description=Smitty.
After=network.target

[Service]
ExecStart=/usr/local/sbin/smitty -c /etc/smitty/agent.yml -verbose
ExecStop=/bin/kill -SIGTERM $MAINPID
Restart=always
User=root
Group=root

[Install]
WantedBy=multi-user.target

Pozostało jeszcze przeładować konfigurację systemd oraz dodać nowy serwis do autostartu:

systemctl daemon-reload
systemctl enable smitty

Możemy teraz wystartować nową usługę:

systemctl start smitty

Istnieje jeszcze inne rozwiązanie o nazwie redis-twemproxy-agent. Nigdy z niego nie korzystałem, jednak zasada działania jest bardzo podobna do narzędzia opisanego wyżej. Sytuację i możliwą konfigurację złożoną ze wszystkich elementów, w których sprawdza się ten agent, przedstawia poniższa grafika:

Niestety, nie udało mi się sprawić, aby Smitty aktualizował adres IP nowego mistrza. Druga sprawa jest taka, że przy ustawionym parametrze requirepass w konfiguracji Sentineli, nie będzie możliwości podłączenia się do nich z poziomu obu rozwiązań. Zacząłem zastanawiać się, czy jest w ogóle sens stosowania takiego rozwiązania, a jeśli tak, to czy nie da się zrobić tego prościej. W niektórych przypadkach wykorzystanie Smitty ma sens zwłaszcza wtedy, kiedy nie wykorzystujemy HAPRoxy lub nie mamy mechanizmu, który będzie lokalizował serwer nadrzędny.

Po chwili namysłu napisałem bardzo proste narzędzie:

#!/usr/bin/env bash

_REDIS_CLI="/root/redis/src/redis-cli"
_MASTER_ID="mymaster"
_SENTINEL_IP="$1"
_SENTINEL_PORT="$2"
_SENTINEL_CFG="/etc/redis-sentinel.conf"
_TWEMPROXY_CONFIG="/etc/twemproxy/nutcracker.yml"
_TWEMPROXY_POOL="redis_stack"
_TWEMPROXY_RESTART="systemctl restart twemproxy"
_LOG_FILE="/var/log/twemproxy/twemproxy-change-master.log"
_CHECK_INTERVAL="5"

echo -en "Start Twemproxy Agent.\\n" >> "$_LOG_FILE"

while : ; do

  _MASTER_PARAMS=$("$_REDIS_CLI" --no-auth-warning \
  -a `grep '^requirepass' $_SENTINEL_CFG | awk '{print $2}' | sed 's/"//g'` \
  -h "$_SENTINEL_IP" \
  -p "$_SENTINEL_PORT" \
  SENTINEL get-master-addr-by-name $_MASTER_ID)

  # pip install shyaml
  _MASTER_OLD_PARAMS=$(cat "$_TWEMPROXY_CONFIG" | \
  shyaml get-value ${_TWEMPROXY_POOL}.servers | \
  awk '{print $2}')

  _MASTER_IP=$(echo "$_MASTER_PARAMS" | tr '\r\n' ':' | awk -v FS="(:|:)" '{print $1}')
  _MASTER_PORT=$(echo "$_MASTER_PARAMS" | tr '\r\n' ':' | awk -v FS="(:|:)" '{print $2}')

  _MASTER_OLD_IP=$(echo "$_MASTER_OLD_PARAMS" | tr '\r\n' ':' | awk -v FS="(:|:)" '{print $1}')
  _MASTER_OLD_PORT=$(echo "$_MASTER_OLD_PARAMS" | tr '\r\n' ':' | awk -v FS="(:|:)" '{print $2}')

  if [[ "$_MASTER_OLD_IP" != "$_MASTER_IP" ]] ; then

    echo -en \
      "detect new master: ${_MASTER_OLD_IP}:${_MASTER_OLD_PORT} -> ${_MASTER_IP}:${_MASTER_PORT}\\n" \
      >> "$_LOG_FILE"

    sed -i "s|${_MASTER_OLD_IP}:${_MASTER_OLD_PORT}|${_MASTER_IP}:${_MASTER_PORT}|g" \
    "$_TWEMPROXY_CONFIG"

    if grep "\- ${_MASTER_IP}:${_MASTER_PORT}:" "$_TWEMPROXY_CONFIG" ; then

      echo -en \
        "select new master: ${_MASTER_OLD_IP}:${_MASTER_OLD_PORT} -> ${_MASTER_IP}:${_MASTER_PORT}\\n" \
        >> "$_LOG_FILE"

      $_TWEMPROXY_RESTART

    fi

  fi

  sleep "$_CHECK_INTERVAL"

done

Nie jest ono idealne i wymaga kilku poprawek takich jak weryfikacja połączenia do Sentineli, weryfikacja autoryzacji czy logowanie czasu wykonania komend. Jednak w takiej formie działa i to całkiem dobrze. Zapiszmy w takim razie powyższy kod do pliku /usr/local/sbin/twemproxy-change-master i ustawmy uprawnienia wykonywania:

chmod a+x /usr/local/sbin/twemproxy-change-master

Oczywiście przed użyciem musisz dostosować początkowe zmienne. Narzędzie wywołuje się w ten sposób:

twemproxy-change-master 127.0.0.1 26379

Przygotujmy w takim razie nowy serwis pod systemd i poniższą konfigurację dodajmy do pliku /usr/lib/systemd/system/twemproxy-agent.service:

[Unit]
Description=Twemproxy Agent.
After=network.target

[Service]
ExecStart=/usr/local/sbin/twemproxy-change-master 127.0.0.1 26379
ExecStop=/bin/kill -SIGTERM $MAINPID
Restart=always
User=root
Group=root

[Install]
WantedBy=multi-user.target

Pozostało jeszcze przeładować konfigurację systemd oraz dodać nowy serwis do autostartu:

systemctl daemon-reload
systemctl enable twemproxy-agent

Możemy teraz wystartować nową usługę:

systemctl start twemproxy-agent

Na koniec przetestować czy wszystko działa.

W tym wpisie postaram się odpowiedzieć na kilka bardzo ważnych pytań związanych głównie z działaniem usługi Redis Sentinel:

• dlaczego minimalna zalecana ilość Sentineli wynosi trzy?
• dlaczego kworum nie zawsze jest większością jednak w jakich przypadkach może mieć na nią wpływ?
• dlaczego przy dwóch działających Sentinelach przełączanie awaryjne nadal działa?
• dlaczego przy jednym działającym Sentinelu i kworum równym jeden przełączanie awaryjne nie działa?
• dlaczego Sentinele (przy zachowaniu większości) awansują ostatni działający węzeł, który jest w stanie Slave?
• dlaczego Sentinele (przy zachowaniu większości) nie awansuję węzła, który jest w stanie Slave i został uruchomiony jako pierwszy po awarii?

Na ratunek Redis Sentinel

Przypomnijmy sobie konfigurację początkową, która złożona jest z następujących instancji: 1x Master, 2x Slave, 3x Sentinel. Uruchomiliśmy każdą z nich, replikacja działa poprawnie, wszystko jest OK. Dobrze, a co się stanie jeśli serwer główny ulegnie awarii? Taką sytuację możemy wygenerować na trzy sposoby:

• zatrzymać usługę Redis lub wyłączyć całkowicie serwer nadrzędny, wtedy na serwerach podrzędnych parametr master_link_status przejdzie ze stanu up w stan down
• w konsoli Redisa wydać polecenie DEBUG segfault, które wygeneruje błąd segmentacji pamięci i zatrzyma (wyłączy) proces, tutaj także na serwerach podrzędnych parametr master_link_status przejdzie ze stanu up w stan down
• w konsoli Redisa wydać polecenie DEBUG sleep 15, które zasymuluje stan „unreachable” (zawiesi proces), jednak na serwerach podrzędnych parametr master_link_status nadal będzie wskazywał stan up

Jest jeszcze jeden sposób, który polega na wywołaniu skryptu, który doprowadzi do błędu BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.. Na przykład:

127.0.0.1:6379> eval "for i=0,1000000,1 do redis.call('set', i, i) end" 0

Błąd ten oznacza, że istnieje długo działający skrypt Lua po stronie serwera. Taki skrypt jest wywoływany przez komendy EVAL lub EVALSHA. Długo działający oznacza, że czas wykonywania skryptu przekroczył próg określony w dyrektywie konfiguracyjnej lua-time-limit (domyślnie 5000 ms).

Ponieważ Redis jest jednowątkowy, po przekroczeniu limitu czasu odpowiada komunikatem o błędzie „-BUSY”, aby wskazać, że nadal jest zajęty. Aby zatrzymać taki skrypt, możesz wywołać komendę SCRIPT KILL, jednak powiedzie się ona tylko wtedy, gdy skrypt nie wykonał żadnych operacji zapisu. Jeśli zapisano dane, jedynym sposobem na jego zatrzymanie jest wyłączenie serwera bez zapisywania zmian za pomocą SHUTDOWN NOSAVE.

Podczas niedostępności serwera głównego, w wyniku polecenia INFO replication pojawi się parametr master_link_down_since_seconds, który odlicza czas, jaki upłynął od utraty komunikacji z serwerem nadrzędnym. Omówimy go jednak później, ponieważ wartość, jaką przyjmuje, mówi o możliwych problemach związanych z przełączaniem awaryjnym. Natomiast dokładne informacje, jakie zwraca komenda INFO, znajdziesz tutaj.

Oczywiście potencjalnych przyczyn niedostępności instancji głównej może być więcej i najczęściej są one związane z awarią całego serwera lub problemami sieciowymi (np. port/interface flapping). Niezależnie od sytuacji, aplikacja łącząca się do serwera nadrzędnego najprawdopodobniej zacznie zwracać błędy, ponieważ HAProxy nie będzie mógł znaleźć serwera pracującego jako Master i odmówi połączenia. Taka sytuacja jest niepożądana i rozwiązaniem jest albo przywrócenie mistrza do działania (zalecany sposób), albo wyzerowanie konfiguracji niedziałających węzłów (co zazwyczaj jest niemożliwe jeśli nie działają i nie ma dostępu do serwerów, na których są uruchomione) i ręczne wypromowanie jednego z serwerów repliki za pomocą polecenia SLAVEOF no one. Widzimy jednak, że takie rozwiązanie wymaga ingerencji administratora i jest mało optymalne. Lepiej, gdyby cała operacja przełączania odbywała się automatycznie — tutaj właśnie z pomocą przychodzi omawiamy już kilkukrotnie Redis Sentinel.

Wykorzystując usługę Redis Sentinel musimy wiedzieć, że ma ona swoje własne komplikacje, dlatego tak ważne jest zrozumienie jak działa wykrywanie usług, które z opcji należy dostroić, szczególnie w przypadku złej infrastruktury lub sieci oraz dlaczego musimy zapewnić odpowiednią liczbę Sentineli. Co równie istotne, architektura replikacji Redis + Redis Sentinel nie gwarantuje zerowej utraty danych (czasami oznacza, że ​​możesz stracić dużo danych, gdy występuje partycja sieciowa), ale może jedynie zagwarantować wysoką dostępność. Podczas awansowania repliki na serwer nadrzędny zawsze istnieje ryzyko utraty wszystkich danych, które zostały zapisane w pamięci lokalnej węzła.

Redis Sentinel to rozwiązanie zapewniające wysoką dostępność (ang. High Availability), które w przypadku problemów automatycznie wykryje punkt awarii i przywróci odpowiednie instancje do trybu stabilnego bez interwencji administratora (przy zapewnieniu odpowiedniej konfiguracji i spełnieniu pewnych warunków). Redis Sentinel działa tylko w replikacji asynchronicznej Master-Slave i nie jest wykorzystywany w przypadku klastra. Jest rozwiązaniem typu hot-standby, w którym serwery podrzędne są replikowane i gotowe do awansu w dowolnym momencie. Może zostać skonfigurowany na dwa sposoby: tylko jako monitor, który nie może wykonać przełączenia awaryjnego, lub jako strażnik, który może rozpocząć przełączanie awaryjne. Jeżeli podczas awarii większość procesów Sentinel nie jest w stanie ze sobą rozmawiać, Sentinel nigdy nie uruchomi przełączania awaryjnego.

Lista najważniejszych zadań, którymi zajmują się Sentinele jest następująca:

• utrzymywanie komunikacji przy użyciu portu 26379 protokołu TCP
• ogłaszanie swojej obecności za pomocą komunikatów Pub/Sub co określony czas (patrz: Pub/Sub)
• stałe monitorowanie kanału __sentinel__:hello wiadomości Pub/Sub w celu wykrywania nowo podłączonych Sentineli lub takich, które są już niedostępne
• utrzymywanie i aktualizowanie (synchronizowanie) parametrów takich jak RunID, adres IP i numeru portu pozostałych Sentineli
• utrzymywanie i aktualizowanie listy obecnie działających Sentineli
• stałe monitorowanie serwerów nadrzędnych, podrzędnych oraz innych Sentineli za pomocą polecenia PING
• stałe monitorowanie stanu mistrza oraz pozostałych Sentineli za pomocą polecenia INFO, które wysyłane jest do serwerów nadrzędnych i podrzędnych (domyślnie co 10 sekund, odpowiada za to parametr hz w redis.conf)
• wykrywanie niedostępności serwera nadrzędnego, gdy nie jest już w stanie poprawnie odpowiedzieć na polecenie PING przez dłużej niż określoną liczbę sekund z rzędu
• zarządzanie stanami SDOWN i ODOWN serwera nadrzędnego i stwierdzanie (akceptacja przez kworum) czy jest on faktycznie niedostępny
• wybór lidera, który dokona ew. przełączania awaryjnego
• autoryzacja procesu przełączania awaryjnego większością głosów działających Sentineli

Co ważne, członkowie należący do grupy Sentineli utrzymują trwałe połączenia:

• z serwerami nadrzędnymi w celu ich monitorowania
• z serwerami podrzędnymi, które są wykrywane za pomocą wyjścia polecenia INFO z serwera nadrzędnego
• z pozostałymi Sentinelami, które są wykrywane za pomocą publikowania/subskrybowania wiadomości Pub/Sub

Zapewne zauważyłeś w powyższej liście dwa stany, które definiują stan niedostępności danego węzła (niezależnie od jego roli). Będziemy o nich opowiadać później, jednak już teraz wspomnę, że stan SDOWN (ang. subjectively down) mistrza, oznacza, że jest on niedostępny z perspektywy lokalnej instancji Sentinel, oraz że do oznaczenia takiego stanu nie jest brana pod uwagę decyzja kworum. Natomiast stan ODOWN (ang. objectively down) mistrza oznacza, że jego niedostępność została potwierdzona przez inne Sentinele w grupie (kworum). W źródłach Sentinela obu stanom odpowiadają poniższe makra:

#define SRI_S_DOWN (1<<3)   /* Subjectively down (no quorum). */
#define SRI_O_DOWN (1<<4)   /* Objectively down (confirmed by others). */

Dobrze, a jakie korzyści płyną ze stosowania Sentineli? Otóż ich wykorzystanie pozwala na rozwiązanie kilku problemów i pozwala na zapewnienie ciekawych mechanizmów. Najważniejszą jest chyba przełączanie awaryjne, dzięki któremu Sentinele są w stanie wykrywać problemy z serwerem nadrzędnym i odpowiednio reagować awansując jedną z replik na nowego mistrza. Drugą ciekawą funkcją jest dostarczanie informacji o serwerze nadrzędnym klientom — Redis Sentinel nie działa jako serwer proxy, jednak pozwala wskazać klientom lokalizację obecnego mistrza. Kolejną istotną rzeczą jest zapobieganie działaniu dwóch lub większej liczby mistrzów w tym samym momencie. Taka sytuacja może wystąpić z powodu awarii spowodowanej brakiem komunikacji między instancjami i brakiem synchronizacji między nimi. Ten przypadek jest również powszechnie nazywany partycją sieciową (ang. Network Partition). Przykładem partycji sieciowej jest sytuacja, gdy dwa węzły nie mogą ze sobą rozmawiać, ale są klienci, którzy mogą rozmawiać z jednym lub obydwoma węzłami.

Na przykład, jeśli używasz Redisa do kolejkowania wiadomości, to w przypadku wystąpienia partycji, klient usunąć klucz z jednej z instancji lub ponownie umieścić usunięty wcześniej klucz. Czyli element bazy może zostać dostarczony kilka razy. Widzisz, że klienci mogę nie zgadzać się co do stanu danych w bazie. Jeśli wymagania mocno odnoszą się do spójności danych a w sytuacji partycji sieciowej pomyślnie zapiszesz klucz A do instancji R1, to klient, który łączy się do replik, spodziewa się, że także zobaczy klucz A. Redis w połączeniu z Sentinelem nawet przy zachowaniu odpowiedniej topologii nie zapewni odpowiedniej konsystencji danych. Przy okazji polecam artykuł Asynchronous replication with failover, który mimo tego, że ma już 7 lat, to w bardzo ciekawy sposób opisuje problemy, które mogą występować w przypadku wykorzystania Sentineli.

Oczywiście nie wszystkie awarie sieci prowadzą do powstania partycji. Jeśli korzystasz z dobrego sprzętu sieciowego w redundantnych konfiguracjach (np. w prawdziwych centrach danych), znacznie zmniejszasz prawdopodobieństwo tego typu sytuacji. Wiele ważnych aplikacji może tolerować utratę danych przez kilka godzin w roku, jednak jeśli nie możesz tolerować utraty danych, Redis + Redis Sentinel (i przez to Redis Cluster) nie są bezpieczne w użyciu i nie gwarantują 100% spójności.

Wykrywanie awarii sieci jest trudne, ponieważ jedyne informacje, jakie możemy uzyskać o stanie innych węzłów, są dostępne właśnie przez sieć i często nie ma różnicy między opóźnieniem a awarią sieci.

Jeżeli serwer podrzędny (lub taki, który powinien być podrzędnym) ma taką samą rolę jak serwer główny, dzięki Sentinelowi, po niewielkim opóźnieniu, jest ponownie konwertowany na rolę Slave. Pozwala to zminimalizować tzw. splity (ang. Split-Brain lub Split-Horizon), czyli zakłócenia, w przypadku których węzły powinny być zgodne co do danej wartości, ale zamiast tego nie zgadzają się i tak naprawdę mają dwie różne. Zapisów (i odczytów) w tym stanie nie powinno się traktować jak w standardowym scenariuszu (bez takich zakłóceń), ponieważ klienci zobaczą różne wyniki w zależności od węzła, z którym rozmawiają. Spójrz na poniższy scenariusz:

• wszystkie instancje przechowują klucz foo o wartości bar
• została wykryta awaria węzła głównego
• awaria została potwierdzona, rozpoczyna się przełączanie awaryjne
• jeden z Sentineli (lider) wysyła komendę SLAVEOF no one do jednej z replik
• jednak Sentinel zostaje zabity przed otrzymaniem potwierdzenia z repliki
• replika staje się serwerem nadrzędnym
• dochodzi do aktualizacji wartości klucza foo
• stary serwer nadrzędny staje się dostępny
• mamy dwie działające instancje główne o różnych wartościach tego samego klucza

Oczywiście jest to tylko przykład, który jednak pokazuje, że przez pewien czas mogą działać dwa serwery nadrzędne, które mogą mieć różne wartości niektórych danych, jeśli dojdzie do zapisów do któregoś z nich. Jeśli podczas zapisów do aktualnego mistrza wystąpią problemy z siecią, a klienci będą nadal do niego pisać, to jeśli dojdzie do zdegradowania takiej instancji do stanu Slave, wszelkie zapisy wykonane w danym oknie zostaną zniszczone. Narusza to gwarancje trwałości danych, ponieważ w zależności od węzła, z którym komunikowali się klienci, niektórzy z nich utracą swoje zapisy, a inni je zachowają.

Natomiast Sentinel, który uległ awarii, uruchomi się ponownie, to zostanie on uruchomiony ze starą konfiguracją, według której przełączanie nie zostało technicznie zakończone, a Sentinel nigdy nie reklamował nowego mistrza. W takiej sytuacji może dojść do problemów w synchronizacji i uzgodnienia wersji konfiguracji, jednak jeśli konfiguracje Sentineli będą spójne i jeden z Masterów zostanie zdegradowany do instancji Slave, to i tak utraci dane, które przez ten czas zapisał.

Idąc za oficjalną dokumentacją, Redis Sentinel został zaprojektowany do działania w konfiguracji rozproszonej, w której współpracuje wiele procesów Sentinel. Kluczowe jest tutaj słowo rozproszonej, które oznacza, że każdy z Sentineli powinien być rozlokowany w odseparowanej lokalizacji, która umożliwia komunikację z pozostałymi Sentinelami. Często spotyka się konfiguracje, które prezentują uruchomienie Redisa i Sentinela na tym samym hoście. W celu zapewnienia prawdziwego HA nie powinno się uruchamiać Sentinela na tym samym węźle, na którym działa Redis, ponieważ kiedy dany host staje się niedostępny, tracisz jedno i drugie (a stanie się tak, gdy najbardziej będziesz potrzebował niezawodności) co osłabia tylko konfigurację HA.

Zdania na ten temat są oczywiście różne, jednak według mnie, robienie tego w ten sposób jest przykładem złej praktyki i nie zapewni „pełnoprawnej” wysokiej dostępności. Co więcej, jeden z Sentineli powinien znajdować się w całkiem innym centrum danych lub minimum na innej dedykowanej maszynie (generalnie każdy proces Redis i Redis Sentinel powinien być na innym serwerze fizycznym, nawet jeśli są na innych systemach wirtualnych). Oczywiście, wiele przykładów pokazuje uruchomienie obu usług na jednym serwerze (ten artykuł też to robi!), jednak jest to najprawdopodobniej spowodowane zwykłą chęcią zaprezentowania działania replikacji Master-Slave oraz prostotą takiego przekazu. W produkcji takie konfiguracje są w większości bezużyteczne i służą tylko do celów programistycznych i demonstracyjnych.

W rozdziale Master-Slave vs Redis Cluster wspomniałem, że w celu zapewnienia wysokiej dostępności przy wykorzystaniu replikacji Master-Slave, wymaganych jest kilka elementów. Sentinel jest tylko jednym z nich i zajmuje się niezwykle istotną rzeczą: przełączaniem awaryjnym. Oprócz tego umożliwia także wykrywanie instancji nadrzędnej, dzięki czemu klient może wiedzieć, z kim rozmawiać, aby dostać się do takiego serwera oraz synchronizacją konfiguracji między węzłami. Nie konfiguruje natomiast replikacji i nie zapewnia punktu końcowego.

Kworum i znaczenie większości

Wykorzystanie Redis Sentinela pozwala wykrywać awarie na podstawie decyzji członków kworum, tzn. gdy minimalna liczba członków zgodzi się, że dany mistrz nie działa zgodnie z oczekiwaniami. Podjęta decyzja pozwala rozpocząć proces przełączania awaryjnego w celu awansowania jednego z działających podwładnych na serwer nadrzędny. Oznacza to w konsekwencji, że instancje podrzędne są rekonfigurowane, aby używały nowego mistrza, a aplikacje wiedziały, gdzie obecnie znajduje się nowy serwer nadrzędny o nowym adresie.

Kworum to po prostu nieformalna umowa potrzebna do uznania stanu ODOWN obecnego mistrza. Należy ją trakować jako pewnego rodzaju wyzwalacz wymagany do wyboru nowej instancji głównej i jako głos w sprawie zmiany konfiguracji. Rzeczywiste przełączanie awaryjne wymaga jednak zawsze głosowania większości.

Należy zrozumieć ważną rzecz: wartość kworum. Jest to parametr, który określa minimalną liczbę członków, która uzna serwer nadrzędny za niedostępny i ma ogromny wpływ (zachodzi relacja między kworum a większością) na wynik podjęcia decyzji o autoryzacji procesu przełączania, a mówiąc dokładniej, ma wpływ na ilości Sentineli, która musi zaakceptować proces awansowania nowego mistrza. Możemy mieć pięć Sentineli i kworum ustawione na dwa, co oznacza, że minimum dwoje z pięciu członków musi uznać niedostępność mistrza (zgodzić się co do tego, że jest nieosiągalny) i oznaczyć go jako uszkodzony, jednak wyłonienie nowej instancji głównej (czyli rozpoczęcie procedury przełączania awaryjnego) rozpocznie się dopiero, jeśli większość (czyli minimum trzy) zautoryzuje cały proces, czyli wyrazi na to zgodę. Aby faktycznie dokonać przełączenia awaryjnego, jeden ze strażników musi zostać wybrany na lidera i musi mieć upoważnienie do kontynuowania całego procesu. Dzieje się tak tylko przy głosowaniu większości procesów Sentinel. Jeśli jednak ustawimy kworum na cztery, to po wyzwoleniu przełączenia awaryjnego, Sentinel próbujący wykonać całą operację, musi poprosić o autoryzację minimum czterech członków grupy.

Redis Sentinel pozwala na weryfikację parametru kworum oraz sprawdza, czy wartownicy są w stanie osiągnąć minimalną ilośc wymaganą do przełączenia awaryjnego, a także czy są w stanie zapewnić większość potrzebną do autoryzacji tego procesu. Możemy zweryfikować, czy te warunki są spełnione za pomocą polecenia SENTINEL ckquorum <label>, które wykonujemy z poziomu konsoli danego Sentinela.

Wyłapanie znaczenia jest niezwykle istotne, ponieważ może się wydawać, że kworum zawsze musi być większością, co nie jest prawdą. Zgodnie z definicją słowa kworum, jest to minimalna liczba członków, niezbędna do podjęcia wiążących decyzji. Kworum jest używane tylko do potwierdzenia stanu ODOWN serwera nadrzędnego, który wyzwala przełączanie awaryjne, jednak aby faktycznie doszło do takiej sytuacji i serwer podrzędny został awansowany, większość członków (więcej zwolenników niż przeciwników) musi wyrazić na to zgodę.

Zwróć uwagę, że ODOWN jest tzw. słabym kworum. Ten stan oznacza jedynie, że w danym przedziale czasowym wystarczająca ilość strażników uznała, że instancja główna nie była osiągalna. Jednak komunikaty mogą być opóźnione, więc nie ma silnych gwarancji, że odpowiednia liczba strażników zgadza się w tym samym czasie co do stanu wyłączenia. Jeśli dany Sentinel uzna, że mistrz nie działa, zacznie wysyłać żądania SENTINEL is-master-down-by-addr do innych wartowników w celu uzyskania odpowiedzi umożliwiających osiągnięcie kworum potrzebnego do oznaczenia mistrza w stanie ODOWN i wyzwolenia przełączenia awaryjnego.

Redis Sentinel ma dwie różne koncepcje „upadku” mistrza. Pierwsza z nich nazywa się subiektywnym wyłączeniem SDOWN (ang. Subjectively Down) i definiuje stan, który jest lokalny dla danej instancji Sentinel. Druga z nich nazywa się stanem obiektywnego wyłączenia ODOWN (ang. Objectively Down) i jest osiągana, gdy wystarczająca liczba Sentineli (co najmniej liczba skonfigurowana jako parametr kworum monitorowanego mistrza) ustawia warunek SDOWN serwera głównego. Co istotne, aby określić mistrza w tym stanie, informacje zwrotne uzyskiwane od innych wartowników (czyli z ich perspektywy) są przesyłane za pomocą komunikatu/komendy SENTINEL is-master-down-by-addr.

Jeśli kworum jest mniejsze niż większość, to autoryzacji dokonuje faktyczna większość, jeśli jest równe większości bądź większe, to autoryzacji dokonuje minimalna ilość członków równa kworum. Jeśli mamy pięć Sentineli i kworum jest ustawione na pięć, to wszyscy strażnicy muszą zgodzić się co do awarii serwera nadrzędnego, a do przełączenia awaryjnego dojdzie jedynie wtedy, kiedy autoryzacji dokonają wszyscy członkowie.

Parametr ten służy głównie do wykrywania awarii serwera głównego, jednak jak sam widzisz, ma wpływ na proces autoryzacji i pozwala tak naprawdę na dostrajanie czułości mechanizmu, który odpowiada za wykrycie i uznanie awarii:

• jeśli kworum jest ustawione na wartość mniejszą niż większość Sentineli, zwiększa się czułość i Sentinele stają się bardziej wrażliwe na niedostępność mistrza, dzięki czemu przełączanie awaryjne jest uruchamiane gdy niewielka ilość strażników nie może skomunikować się z serwerem główny. Może to jednak powodować przekłamania i niepotrzebne awansowanie instancji podrzędnej na nadrzędną zwłaszcza w przypadku wystąpienia partycji sieciowej

• jeśli kworum jest ustawione na wartość większą niż większość Sentineli, zmniejsza się czułość, jednak zwiększa gwarancja i pewność, że decyzja o niedostępności jest bardziej miarodajna i właściwa. Pozwala to na zminimalizowanie przypadkowego przełączania. W ten sposób system aktywuje się tylko wtedy, gdy problem rzeczywiście dotyczy węzła głównego, a nie problemu z siecią.

Przy określaniu wartości kworum powinieneś pamiętać o danym środowisku i infrastrukturze. Na przykład mając cztery Redis Sentinele, które rezydują w dwóch rozdzielonych centrach danych ustawienie kworum na trzy przy awarii jednego z DC, może okazać się problematyczne, ponieważ nie uda się przeprowadzić przełączania awaryjnego w przypadku kiedy działać będą tylko dwa z czterech wartowników (wymagany jest jeszcze jeden dodatkowy aby zachować kworum).

Zawsze, gdy kworum jest osiągnięte, większość wszystkich znanych węzłów Sentinel musi być dostępna i osiągalna, aby wybór lidera był możliwy. Następnie lider podejmie wszystkie decyzje dotyczące przywrócenia dostępności usługi w tym:

• wybierze nowego mistrza
• zrekonfiguruje replikę, która zostanie awansowana na nowego mistrza
• rozgłosi nowego mistrza pozostałym węzłom Sentinel
• zrekonfiguruje pozostałe repliki i Sentinele tak, aby widziały nowego mistrza
• zdegraduje starego mistrza, gdy stanie się on ponownie dostępny

Z tego powodu ustawienie tej wartości na równą minimalnej większości (czyli dwa w przypadku trzech Sentineli i trzy w przypadku pięciu) wydaje się optymalnym rozwiązaniem, które jednocześnie pozwala wyeliminować błędną interpretację niedostępności serwera nadrzędnego, dzięki czemu węzły jak i cała replikacja oparta na nich działa przewidywalnie i stabilnie. Wartość kworum nie może być natomiast większa niż ilość działających Sentineli.

Podsumowaniem tego niech będzie poniższa tabela:

Po jej przeanalizowaniu wnioski są następujące: zawsze jest tylko jeden lider (co jest oczywiste) oraz jeśli wartość kworum jest równa minimalnej większości lub od niej większa, to ma wpływ na wybór lidera i liczbę Sentineli wymaganą do autoryzacji przełączania awaryjnego.

Ile Sentineli potrzebujemy?

Tym sposobem dochodzimy do kolejnej istotnej kwestii, mianowicie, jaka jest zalecana ilość strażników? Otóż zgodnie z oficjalną dokumentacją, minimalna ich liczba musi być równa trzy, jednak moim zdaniem, idealnie kiedy jest ich więcej. Studiując przykładowe konfiguracje i zalecenia, mogłeś spotkać się ze stwierdzeniem, że ilość Sentineli powinna być zawsze nieparzysta, tj. 3, 5, 7, itd. w celu zachowania większości. Uważam, że nie jest to prawdą, ponieważ aby zaakceptować proces przełączania awaryjnego, wystarczy taka ilość wartowników, z której dopiero będzie można uzyskać nieparzystą większość. Możemy mieć cztery Sentinele, dzięki czemu uzyskamy nieparzystą minimalną większość równą trzy. Może być ich również sześć, dzięki czemu uzyskamy parzystą minimalną większość równą cztery. Natomiast wartością minimalną i graniczną jest liczba dwóch Sentineli (co jednak jest mocno niezalecane), które oczywiście muszą jednocześnie autoryzować cały proces.

Wartość nieparzysta ma jednak ogromne znaczenie dla poprawności działania tzw. algorytmu konsensusu, używanego do rejestrowania przełączeń awaryjnych, który nie znosi liczb parzystych. Odpowiada on za porozumienie członków w sprawie przełączania awaryjnego i jego poprawne działanie jest niezwykle istotne w przypadku awarii. Instancje Sentinel próbują znaleźć konsensus podczas przełączania awaryjnego i tylko nieparzysta liczba wystąpień zapobiegnie większości problemów, przy czym trzy to minimum, aby algorytm ten był skuteczny w przypadku awarii. Dzięki temu jedna z instancji Sentinel może ulec awarii, a przełączenie awaryjne nadal będzie działać, ponieważ (miejmy nadzieję) pozostałe dwie instancje osiągną pewną jednomyślność wymaganą w procesie awansowania do węzła nadrzędnego (zaczekaj jednak na konkretne przykłady, aby zobaczyć, jak system zachowuje się podczas rzeczywistego działania).

Zgodnie z tym, jeśli jest pięć procesów Sentinel, a kworum dla danego wzorca jest ustawione na wartość dwa, to:

• jeśli dwa Sentinele jednocześnie zgodzą się, że Master jest nieosiągalny, jeden z nich spróbuje rozpocząć przełączanie awaryjne
• jednak aby to się stało, muszą być osiągalne co najmniej trzy Sentinele, wtedy dopiero przełączenie awaryjne zostanie autoryzowane i faktycznie się rozpocznie

W praktyce oznacza to, że podczas awarii Sentinel nigdy nie uruchamia przełączania awaryjnego, jeśli większość procesów nie jest w stanie komunikować się ze sobą.

Dokładna informacja dotycząca zaleceń znajduje się w rozdziale Fundamental things to know about Sentinel before deploying oficjalnej dokumentacji. Pozwolę sobie ją zacytować:

1. You need at least three Sentinel instances for a robust deployment.
2. The three Sentinel instances should be placed into computers or virtual machines that are believed to fail in an independent way. So for example different physical servers or Virtual Machines executed on different availability zones.

Podobne uwagi znajdują się w rozdziale Example 1: just two Sentinels, DON’T DO THIS dokumentacji, która opisuje przykład z dwoma działającymi Sentinelami i problemy, jakie taka konfiguracja może powodować.

Widzimy, że ilość Sentineli jest powiązana z wartością kworum, która zależy właśnie od ich liczby. Wiemy też, że kworum to Sentinele, które muszą zgodzić się co do tego, że master jest nieosiągalny, aby oznaczyć go jako uszkodzony i ostatecznie rozpocząć procedurę przełączania awaryjnego (pod warunkiem, że jest możliwe jej uruchomienie). Jednak kworum służy tylko do wykrywania awarii, a nie do przełączania. Aby uruchomić proces przełączenia awaryjnego, jeden z Sentineli musi zostać wybrany na lidera i to on zajmuje się faktycznym przełączaniem. Niemniej jednak, aby mógł to zrobić, musi posiadać upoważnienie do wykonania tego procesu, co stanie się tylko przy głosowaniu większości procesów Sentinel, nie inaczej. Widzimy, że jeśli jeden z węzłów ma być awansowany na węzeł główny, najpierw musi zostać wybrany lider z dostępnych węzłów Sentinel.

Aby uruchomić mechanizm monitorowania i automatycznego przełączania za pomocą Redis Sentinel, wymagane jest uruchomienie takiej ich liczby (w minimalnej ilości trzech, niezależnie od ilości instancji Redis), aby utrzymać większość i zapewnić przynajmniej jedno przełączanie awaryjne.

Inną zaletą takiego rozwiązania jest to, że przełączanie w większości przypadków działa, nawet jeśli nie działają wszystkie instancje, dzięki czemu system posiada pewną tolerancję i odporność na awarie. Posiadanie systemu przełączania awaryjnego, który sam w sobie jest w końcu pojedynczym punktem awarii, jest czymś mocno niepożądanym. Ponadto konfiguracja złożona z minimum trzech instancji Sentinel zmniejsza możliwość pomyłki (fałszywych trafień) w procesie wyboru nowego mistrza. Ważne wspomnienia jest także to, że Sentinel dba o zmianę ustawień konfiguracji master/replika, tak aby wypromowanie i synchronizacja odbywały się we właściwej kolejności, po to, aby nie doszło do uszkodzenia danych — ta praca także zależy od ilości instancji wartowniczych.

Poniższa grafika przedstawia kilka możliwości zachowania się replikacji Master-Slave przy zapewnieniu odpowiedniej liczby Sentineli. Została ograniczona do trzech węzłów, ponieważ jest to wartość minimalna i graniczna, która działa przewidywalnie i zgodnie z zaleceniami. Za jej pomocą chcę pokazać, w jakich dokładnie scenariuszach dojdzie do procesu promowania nowego mistrza a w których nie. Jest ona tak naprawdę potwierdzeniem tego wszystkiego, co powiedziałem w tym rozdziale oraz wstępem do dwóch następnych rozdziałów:

Zapamiętaj dokładnie ostatni przykład. W następnych rozdziałach zobaczysz, że w przypadku jednego działającego wartownika i kworum równym jeden może dojść do awansowania ostatniej działającej repliki do roli Master, ale tylko w przypadku ręcznej ingerencji za pomocą polecenia SENTINEL failover (z wykorzystaniem Sentinela). Działającej, czyli takiej, która była online w momencie awarii mistrza i nie wystąpiła w tym czasie zbyt długa przerwa w replikacji między repliką a instancją nadrzędną. Jeżeli taka replika uległaby awarii i wróciła jako pierwsza, jedyną możliwością awansowania jest wywołanie komendy SLAVEOF no one, oczywiście przy braku spełnionego kworum i większości.

Nie ma jednak róży bez kolców i należy poruszyć niezwykle istotną kwestię jeśli chodzi o działanie Redis Sentinela oraz ręczne mianowanie węzłów za pomocą SLAVEOF no one. Otóż takie działanie jest wysoce niezalecane, o czym wspomina Salvatore Sanfilippo, główny twórca Redisa:

Never use SLAVEOF commands in Redis instances monitored by Sentinel, in a manual way, all the changes must be operated using Sentinel. At this point, every time there is a fail over, Sentinel will make sure that all the configurations are in sync.

Powodem takiego zalecenia jest to, że w przypadku działania Sentineli i promowania ręcznego, Sentinel może nie wiedzieć, że doszło do zmiany konfiguracji bez przełączania awaryjnego. Jeśli chcesz przełączyć instancję główną, musisz uruchomić przełączanie awaryjne za pośrednictwem Sentineli, używając procedury ręcznego przełączania awaryjnego właśnie z ich poziomu. Dzięki temu Sentinel zaktualizuje konfiguracje instancji przy użyciu CONFIG REWRITE i innych środków ostrożności. Oczywiście ogranicza nam to przywrócenie replikacji do działania, ponieważ Sentinel może nie być w stanie awansować danego węzła za pomocą ręcznej procedury. Jednak dobrą praktyką w tym przypadku powinno być wykonanie SENTINEL failover zawsze w pierwszej kolejności.

W przypadku ręcznego awansowania repliki na mistrza za pomocą polecenia SLAVEOF no one stanie się ona z powrotem repliką jeśli stary mistrz zostanie przywrócony do działania oraz jeśli zostaną spełnione dodatkowe warunki, tj. odpowiednia ilość Sentineli, która będzie w stanie przeprowadzić proces przełączania. Dlatego widzisz, że ręczna modyfikacja stanu danego węzła najczęściej jest pozbawiona sensu, może wprowadzić niepotrzebne zamieszanie (przykład dwóch działających instancji głównych) i sprawdza się jedynie w przypadku, w którym wiemy, że nie będziemy w stanie przywrócić serwera nadrzędnego do działania oraz nie mamy odpowiedniej ilości instancji Sentinel, które wykonałyby cały proces automatycznie. Jeśli wykonamy ręczne promowania repliki a Sentinele nadal będą niedostępne, to w przypadku powrotu starego mistrza będziemy mieli dwie instancje nadrzędne. Jeśli wartownicy nadal będą nieosiągalni, to rozwiązaniem tej sytuacji jest ręczne zdegradowanie jednego z nich do roli Slave (najlepiej tego, który nie widnieje jako wartość parametru sentinel monitor).

Problem dwóch instancji

Chwilę wcześniej napisałem, że dwie instancje Sentinel zapewniają większość. Skoro tak, to dlaczego minimalną zalecaną liczbą są trzy i taka ich ilość zapewnia dopiero wysoką dostępność i odpowiednie monitorowanie węzłów Redis? Wiemy już, że taka ilość jest wymogiem poprawnego działania algorytmu porozumienia. Co więcej, w topologii z trzema węzłami Sentinel możesz pozwolić sobie na wyłączenie tylko jednego z nich, aby proces przełączania nadal działał, co jest niemożliwe w przypadku dwóch instancji, które są minimalną ilością, jaka musi zostać zapewniona, aby mechanizm awansowania w ogóle działał. Kolejno przy pięciu lub sześciu wartownikach maksymalnie dwa mogą zostać wyłączone, aby rozpocząć przełączanie awaryjne, jednak już przy siedmiu maksymalnie trzy węzły mogą ulec awarii. Dostawienie minimum jednego lub dwóch kolejnych Sentineli poprawia dokładność diagnostyki błędów i zwiększa czułość na zmianę stanu mistrza. Ma też ogromny wpływ na autoryzację procesu przełączania i awansowania nowego lidera.

Jeśli masz dwa fizyczne hosty, Sentinel jest przeważnie bezużyteczny, ponieważ gdy jeden z nich ulegnie awarii, większość, zdefiniowana jako S / 2 + 1, nadal wynosi więcej niż jeden i nie ma możliwości, aby drugi Sentinel został wybrany na lidera. Jeśli instancja główna ulegnie awarii, dwa Sentinele nadal działają, więc nastąpi przełączenie awaryjne.

Dlatego trzy Sentinele są ilością minimalną oraz taką, od której rozpoczyna się budowanie grupy Sentineli. Oczywiście nic nie stoi na przeszkodzie, abyś uruchomił parzystą ilość Sentineli, np. równą cztery. W takiej sytuacji także uda się większością głosów potwierdzić proces przełączania, co jest oczywiste i będzie miało miejsce, kiedy trzy z czterech węzłów zatwierdzą całą operację. Widzisz, że tak naprawdę każda liczba równa lub większa od trzech spełnia warunek posiadania większości. Nieparzysta ilość ma jeszcze jeden plus, ponieważ dzięki temu zapewniamy większy zapas Sentineli w przypadku ich awarii.

Posiadanie trzech różnych instancji Sentinel ma o wiele więcej sensu. Jeżeli nie masz możliwości uruchomienia trzech instancji, to możesz rozważyć zainstalowanie trzeciej po stronie klienta (patrz: Example 3: Sentinel in the client boxes) i ustawić kworum na dwa. Fakt, że strażnicy mogą być umieszczeni poza systemem Master-Slave, sprawia, że są one w stanie dokonać decyzji z bardziej obiektywnego punktu widzenia, aby uznać Mistrza za niesprawnego.

W konfiguracji złożonej z dwóch Sentineli dojdzie najprawdopodobniej do przełączenia awaryjnego, ponieważ oba zajmą zgodne stanowisko co do całego procesu. Jednak przy dwóch działających Sentinelach, w przypadku awarii jednego z nich, cały proces się nie powiedzie.

Jedynym powodem uruchomienia grupy z mniej niż trzema Sentinelami jest tak naprawdę wykrywanie usług, co oznacza, że nie używa się go do zarządzania przełączaniem awaryjnym tylko do dostarczania klientom lokalizacji aktualnego serwera nadrzędnego. Jeżeli klienci łączą się bezpośrednio do instancji Redis (z pominięciem np. HAProxy), mogą uzyskiwać adres mistrza właśnie za pośrednictwem usługi Redis Sentinel. Jeśli serwer główny będzie niedostępny, połączenie powinno zostać zerwane przez klienta, po czym klient ponownie połączy się z Sentinelem i otrzyma nowe informacje o mistrzu. Zauważ, że Sentinele śledzą aktualnego mistrza i serwery podrzędne, jednak klienci nie łączą się z serwerem głównym przez nie.

Nawiązując do powyższego, należy nadmienić o jednej istotnej kwestii. Mianowicie, sprawdzając tylko jednego wartownika, nie możesz niezawodnie stwierdzić lokalizacji mistrza, ponieważ istnieje pewne opóźnienie między przełączeniem awaryjnym a strażnikami niebędącymi liderami, więc właściwym rozwiązanie jest uzyskanie informacji wprost od lidera. Tak samo sprawdzając każdy z serwerów wartowniczych, będziesz wiedział, że albo nie możesz komunikować się z mistrzem, albo polegać na decyzji większości, mimo że któryś z Sentineli nie uchwycił jeszcze zmiany.

Co się dzieje gdy działa jeden Sentinel?

Przejdziemy teraz do sytuacji, która jest niezbędna do zrozumienia przykładów konfiguracji i działania replikacji, które znajdują się w kolejnych rozdziałach.

Przyjmijmy, że nasza początkowa konfiguracja składa się z trzech węzłów, tj. 1x Master i 2x Slave, trzech procesów Sentinel, które działają na tych samych węzłach co instancje Redis oraz kworum równego 2. Jeśli serwer, na którym działa Master ulegnie awarii, tracimy jednocześnie jednego ze strażników. W tej sytuacji wykonany zostanie podobny do poniższego algorytm:

• dwa pozostałe Sentinele wykryją, że serwer nadrzędny jest nieosiągalny ustawiając stan SDOWN, który oznacza, że instancja nie jest już dostępna z punktu widzenia Sentinela, który wykrył niedostępność mistrza
• wyślą żądania SENTINEL is-master-down-by-addr do pozostałych Sentineli
• natomiast do potwierdzenia stanu ODOWN wymagane jest kworum, które w naszej konfiguracji wynosi dwa
  • warunek ten zostaje spełniony, ponieważ ilość dostępnych Sentineli jest równa kworum, dlatego kworum powinno zgodzić się na awarię mistrza
• następnie spośród dostępnych Sentineli wybierany jest lider
• aby lider został wybrany, muszą zostać spełnione dwa warunki:
  • bezwzględna większość głosujących Sentineli (50% + 1)
  • głosy Sentineli zapewniające kworum
• wykonywane jest skanowanie wszystkich podłączonych strażników, aby sprawdzić, czy istnieje przywódca dla określonej epoki
• lider, który wygrał wybory w określonej epoce, może wykonać przełączenie awaryjne pod warunkiem, że mistrz jest w stanie ODOWN
• lider przed rozpoczęciem procesu przełączania awaryjnego wymaga autoryzacji tego procesu u większości Sentineli
  • większość jest zapewniona, ponieważ mamy dwóch strażników i oboje akceptują przełączanie
• dzięki temu lider uruchamia przełączanie awaryjne i awansuje jedną z replik na serwer nadrzędny

Po powyższym przełączaniu aktualna konfiguracja to 1x Master, 1x Slave, dwa procesy Sentinel i kworum równe 2. Po pewnej chwili tym razem nowy serwer nadrzędny ulega awarii a razem z nim działający Sentinel, przez co oba stają się niedostępne. Co się dzieje?

• Sentinel, który pozostał w grupie, wykryje, że serwer nadrzędny jest nieosiągalny ustawiając stan SDOWN, który oznacza, że instancja nie jest już dostępna z punktu widzenia Sentinela, który wykrył niedostępność mistrza
• zacznie wysyłać żądanie SENTINEL is-master-down-by-addr do pozostałych Sentineli
• natomiast do potwierdzenia stanu ODOWN wymagane jest kworum, które w naszej konfiguracji wynosi dwa
  • warunek nie zostaje spełniony, ponieważ nie mamy wymaganej ilości Sentineli równej kworum, dlatego nigdy nie dojdzie do awansowania nowego mistrza właśnie z tego powodu

Jeżeli chwilę się zastanowisz, to przyjdzie Ci na pewno do głowy, że rozwiązaniem może być zmniejszenie wartości kworum do jeden. Przyjmijmy jednak, że taka wartość była ustawiona od samego początku i pierwszy etap przeszedł bezbłędnie. Rozpocznijmy więc raz jeszcze od ostatniej działającej konfiguracji:

• Sentinel, który pozostał w grupie, wykryje, że serwer nadrzędny jest nieosiągalny ustawiając stan SDOWN, który oznacza, że instancja nie jest już dostępna z punktu widzenia Sentinela, który wykrył niedostępność mistrza
• natomiast do potwierdzenia stanu ODOWN wymagane jest kworum, które w naszej konfiguracji wynosi jeden
  • warunek ten zostaje spełniony, ponieważ ilość dostępnych Sentineli jest równa kworum, dlatego kworum powinno zgodzić się na awarię mistrza
• następnie spośród dostępnych Sentineli wybierany jest lider
• aby lider został wybrany, muszą zostać spełnione dwa warunki:
  • bezwzględna większość głosujących Sentineli (50% + 1)
  • głosy Sentineli zapewniające kworum
• wykonywane jest skanowanie wszystkich podłączonych strażników, aby sprawdzić, czy istnieje przywódca dla określonej epoki
• lider, który wygrał wybory w określonej epoce, może wykonać przełączenie awaryjne pod warunkiem, że mistrz jest w stanie ODOWN
• lider przed rozpoczęciem procesu przełączania awaryjnego wymaga autoryzacji tego procesu u większości Sentineli
  • większość jest zapewniona, ponieważ mamy jednego strażnika, który akceptuje przełączanie

Jak myślisz, czy jedyna działająca instancja podrzędna zostanie awansowana na mistrza? Otóż nie, nie zostanie. Jeśli w grupie pozostał jeden Sentinel, to nie może on wybrać lidera, ponieważ nie uzyska większości głosów (zerknij na tabelkę znajdującą się na samym końcu rozdziału wyżej i na wzór S / 2 + 1), nawet mimo głosowania na samego siebie, aby rozpocząć przełączanie awaryjne. Stąd punkty:

• lider, który wygrał wybory w określonej epoce, może wykonać przełączenie awaryjne pod warunkiem, że mistrz jest w stanie ODOWN
• lider przed rozpoczęciem procesu przełączania awaryjnego wymaga autoryzacji tego procesu u większości Sentineli
  • większość jest zapewniona, ponieważ mamy jednego strażnika, który akceptuje przełączanie

Albo nigdy się nie wydarzą (brak spełnionych warunków potrzebnych do wybrania lidera) a jeśli wydarzą, to zwrócą błąd, który nie dopuści do wykonania całego procesu przełączania awaryjnego. Rozwiązaniem tego jest dostawienie większej liczby Sentineli. Co istotne i warte wspomnienia, pomijając już to, czy warunki zostały spełnione, czy nie, jeśli dany Sentinel jeszcze nie głosował, to albo zagłosuje na najczęściej wybieranego strażnika, albo na siebie.

Widzisz, że musi zostać zapewniony podstawowy warunek bezstronności, czyli, że ostatni węzeł nie może zostać sędzią we własnej sprawie (zawsze potrzeba dodatkowego głosu), ponieważ możliwość przełączenia awaryjnego bez dodatkowej zgody jeszcze innego członka, byłaby bardzo niebezpieczna i nigdy nie powinniśmy do niej dopuścić. Jeżeli w środowisku mamy trzy Redis Sentinele i jeden z nich ulega awarii, to w przypadku awarii serwera głównego dojdzie do uznania, że jest on niedostępny, ponieważ dwa Sentinele mogą dojść do porozumienia w sprawie awarii i mogą również autoryzować przełączenie awaryjne (co nie znaczy, że w tej sytuacji nie unikniemy problemów). Dlatego tak ważne jest, aby uruchomić minimum trzech wartowników po to, by zawsze dwa węzły z trzech mogły stanowić większość.

Drugim powodem przerwania procesu wyboru lidera i przełączania awaryjnego są działające mechanizmy ochrony danych (zwłaszcza gdy większość Sentineli ulegnie awarii) zapobiegające destrukcyjnym działaniom oraz ewentualnemu ich uszkodzeniu.

Spójrzmy jednak, co dzieje się na samym dole tego procesu. Najpierw ustawiany jest stan SDOWN dla R2:

+sdown master mymaster 192.168.10.20 6379

Następnie potwierdzony musi zostać stan ODOWN, oczywiście zaakceptowany przez kworum:

+odown master mymaster 192.168.10.20 6379 #quorum 1/1

Trwa nowe przełączanie awaryjne, czekające na wybór większości:

+try-failover master mymaster 192.168.10.20 6379

Następuje głosowanie na lidera, w tym wypadku ostatni węzeł głosuje na samego siebie:

+vote-for-leader c8e2591af9d8437bdafd78ccdc6c5b9f618613d6 35

Istotna natomiast jest poniższa informacja, która oznacza, że proces przełączania awaryjnego został przerwany, jeśli dany Sentinel po pewnym czasie nie został liderem, co miało miejsce:

-failover-abort-not-elected master mymaster 192.168.10.20 6379

Po niej następuje powtórzenie procesu:

Next failover delay: I will not start a failover before Sat Sep 19 16:57:05 2020
+new-epoch 36
+try-failover master mymaster 192.168.10.20 6379
+vote-for-leader c8e2591af9d8437bdafd78ccdc6c5b9f618613d6 36
-failover-abort-not-elected master mymaster 192.168.10.20 6379

Pierwszy wpis oznacza, że ostatnia próba przełączenia awaryjnego rozpoczęła się zbyt wcześnie i należy odczekać pewien określony interwał, aby operacja została powtórzona. Wybór lidera może czasami zakończyć się niepowodzeniem w danej rundzie głosowania, gdy nie zostanie osiągnięty konsensus. W takim przypadku nowa próba zostanie podjęta po czasie określonym za pomocą parametru failover-timeout.

Jeśli przełączenie przez wybranego wartownika nie powiedzie się, drugi wartownik będzie czekał na czas przełączenia awaryjnego, a następnie przejmie kontrolę, aby kontynuować przełączanie. Jest to częsty przypadek (zbyt wiele przełączeń), który także blokuje możliwość awansowania nowego mistrza. Zdarza się też, że powyższy błąd jest rzucany przy braku poprawnej komunikacji między węzłami Sentinel, która spowodowana jest niepoprawną wartością parametru bind lub zdublowanym identyfikatorem danego Sentinela. Natomiast najbardziej prawdopodobnym powodem niepowodzenia powyższego procesu jest to, że jeden z Sentineli (w tym wypadku ostatni z nich i jedyny działający) nie może wybrać (co nie znaczy zagłosować) nowego lidera, jeśli dodatkowy z wartowników nie będzie działać.

Proces przełączania awaryjnego wartownika jest maszyną stanową i został zdefiniowany w funkcji sentinelFailoverStateMachine w pliku źródłowym sentinel.c. Podejmuje on następujące kroki:

void sentinelFailoverStateMachine(sentinelRedisInstance *ri) {
    serverAssert(ri->flags & SRI_MASTER);

    if (!(ri->flags & SRI_FAILOVER_IN_PROGRESS)) return;

    switch(ri->failover_state) {
        case SENTINEL_FAILOVER_STATE_WAIT_START:
            sentinelFailoverWaitStart(ri);
            break;
        case SENTINEL_FAILOVER_STATE_SELECT_SLAVE:
            sentinelFailoverSelectSlave(ri);
            break;
        case SENTINEL_FAILOVER_STATE_SEND_replicaof_NOONE:
            sentinelFailoverSendreplicaofNoOne(ri);
            break;
        case SENTINEL_FAILOVER_STATE_WAIT_PROMOTION:
            sentinelFailoverWaitPromotion(ri);
            break;
        case SENTINEL_FAILOVER_STATE_RECONF_SLAVES:
            sentinelFailoverReconfNextSlave(ri);
            break;
    }
}

Kluczowe jest wywołanie funkcji sentinelFailoverWaitStart. Za jej pomocą Sentinel zweryfikuje czy jest liderem w danej epoce wywołania przełączania awaryjnego. Jeśli nie jest liderem i nie jest to wymuszona awaria przez ręczne wywołanie SENTINEL failover, zostaje zwrócony błąd, który jednocześnie zostaje zapisany do pliku z logiem:

sentinelEvent(LL_WARNING,"-failover-abort-not-elected",ri,"%@");

Sentinel nie może kontynuować trwającego przełączania awaryjnego, co w konsekwencji prowadzi do wywołania funkcji sentinelAbortFailover. Tę funkcję można wywołać tylko przed potwierdzeniem promowania instancji nadrzędnej do instancji głównej. W przeciwnym razie przełączenia awaryjnego nie można przerwać, a sam proces będzie trwał do momentu, aż zostanie osiągnięty jego koniec (prawdopodobnie przez limit czasu).

Należy pamiętać, że na każdym etapie, który doprowadzi w konsekwencji do awansowania nowego mistrza, tj. weryfikacja kworum, wybór lidera czy zatwierdzenie przełączania, działa wiele różnych mechanizmów (niektóre z nich zostaną zaprezentowane później). Najczęstszym i najprostszym rozwiązaniem podobnych problemów jest zapewnienie minimalnej zalecanej konfiguracji, tak aby mieć pewność, że grupa Sentineli pozostanie silna i odporna na awarie pozostałych członków.

Warunki rozpoczęcia przełączania awaryjnego

Fakt, że master jest oznaczony jako ODOWN, nie wystarczy, aby rozpocząć proces przełączania awaryjnego. Należy również zdecydować, który z wartowników ma rozpocząć przełączanie awaryjne. Co istotne, strażnik może przyjąć dwie role podczas procesu przełączania:

• rola lidera, dzięki której Sentinel wykonuje przełączenie awaryjne
• rola obserwatora, która oznacza podążanie za procesem przełączania bez wykonywania aktywnych operacji

Obie role zostały zdefiniowane za pomocą flag:

#define SENTINEL_LEADER (1<<17)
#define SENTINEL_OBSERVER (1<<18)

Rola lidera daje ogromną władzę, ponieważ pozwala przeprowadzić proces przełączania awaryjnego. Aby zostać liderem w danej epoce, musi zostać zapewniona większość, czyli większość Sentineli powinna być dostępna. Co więcej, potencjalny lider musi widzieć pozostałych strażników, czyli takich, którzy kiedykolwiek byli widziani od ostatniego zerowania strażnika, i tacy, którzy zgłosili ten sam przypadek co lider z tej samej epoki.

Jednak aby doszło do faktycznego awansowania repliki na mistrza, musi zostać spełnionych kilka warunków (jest to rozszerzona wersja tego co powiedziałem przed chwilą):

• Sentinel będący liderem potrafi wykazać stan SDOWN serwera nadrzędnego
• musi także określić swój stan jako subiektywny przywódca (ang. subjective leader), czyli wybrać sam siebie na lidera
• jego Run ID (unikalny identyfikator) jest najmniejszy według porządku leksykograficznego (sposobu, w jaki słowa są uporządkowane w słowniku, najpierw według pierwszej litery, następnie według drugiej, i tak dalej)
• liczba pozostałych (działających) Sentineli, którzy postrzegają serwer nadrzędny jako nieosiągalny, jest równa kworum
• liczba pozostałych (działających) Sentineli, którzy myślą, że jeden z Sentineli to lider lub tzw. obiektywny przywódca (ang. objective leader), jest równa kworum
• istnieje co najmniej połowa + 1 wszystkich Sentineli zaangażowanych w proces głosowania (którzy są osiągalni i którzy również widzą, że serwer nadrzędny jest niedostępny) na obiektywnego lidera, który dokona ew. przełączania awaryjnego

Jeżeli te warunki zostaną spełnione, to:

• obiektywny lider dokonuje przełączania awaryjnego
• następuje zmiana stanu wybranego serwera podrzędnego w stan mistrza za pomocą polecenia SLAVEOF NO ONE
• następuje zmiana wszystkich węzłów podrzędnych, jeśli tacy istnieją, w węzły podlegające nowemu mistrzowi (czyli są widoczne z poziomu nowego mistrza)
  • ten proces odbywa się stopniowo, czyli zmiana odbywa się najpierw dla jednego węzła podrzędnego, a jeżeli proces synchronizacji zostanie zakończony, następuje zmiana stanu kolejnego podwładnego
• stary Master zostaje usunięty z konfiguracji a w jego miejsce wchodzi nowy

Tak naprawdę każdy węzeł Sentinel może zostać liderem. Gdy jeden z Sentineli uzna, że węzeł główny jest subiektywnie w trybie offline, zażąda od innych węzłów Sentinel wybrania siebie jako lidera. Jeśli liczba głosów w wyborach uzyskanych przez dany węzeł Sentinel osiągnie wymagane minimum (czyli według wzoru S / 2 + 1), węzeł taki zostanie wybrany na lidera, w przeciwnym razie wybory zostaną powtórzone.

Natomiast rola obserwatora powoduje, że dany Sentinel widzi stany serwera nadrzędnego, zwłaszcza ODOWN, jednak nigdy nie dokonuje przełączania awaryjnego (czyli nie jest wytypowany na lidera). Sentinel, do którego została przypisana taka rola, nadal może śledzić i aktualizować stan wewnętrzny na podstawie tego, co dzieje się w grupie oraz gdy nastąpi przełączanie awaryjne. Węzeł będący w tym stanie obserwuje stan pozostałych Sentineli, aby zrozumieć, co się dzieje i być na bieżąco z lokalizacją serwera nadrzędnego.

Funkcją odpowiedzialną za weryfikację, czy przełączanie awaryjne jest wymagane, jest sentinelStartFailoverIfNeeded. Weryfikuje ona dodatkowe warunki, które muszą zostać spełnione, aby było możliwe rozpoczęcie tego procesu:

• serwer nadrzędny będzie w stanie ODOWN, dzięki jednomyślności kworum
• w danej chwili nie trwa proces przełączania awaryjnego
• niedawno nie podjęto już próby przełączenia awaryjnego
• zostanie wybrany obiektywny przywódca spośród dostępnych Sentineli należący do kworum

W kodzie Sentinela odpowiada za to poniższy fragment (jest to część wyżej wymienionej funkcji):

/* We can't failover if the master is not in O_DOWN state. */
if (!(master->flags & SRI_O_DOWN)) return 0;

/* Failover already in progress? */
if (master->flags & SRI_FAILOVER_IN_PROGRESS) return 0;

/* Last failover attempt started too little time ago? */
if (mstime() - master->failover_start_time <
    master->failover_timeout*2)

Niestety, kroki opisane w tym rozdziale nie są jedynymi, które muszą zostać spełnione, aby proces przełączania awaryjnego zakończył się sukcesem. Etapem, który nie został opisany, jest wybór instancji podrzędnej, która będzie nadawała się do awansowania na nowego mistrza. Kroki potrzebne do dokonania takiego wyboru zostaną opisane w jednym z następnych rozdziałów.

Na koniec odpowiedzmy sobie szybko na dwa pytania, w kontekście procesu awansowania:

• co zyskujemy dzięki wykorzystaniu Sentineli?
  • dostępność instancji głównej, ponieważ jeśli ulegnie ona awarii, jej rolę przejmie jedna z instancji podrzędnych
• co zyskujemy dzięki Redis Cluster?
  • możliwość automatycznego dzielenia zbioru danych na wiele węzłów
  • możliwość kontynuowania operacji, gdy podzbiór węzłów ma awarie lub nie może komunikować się z resztą klastra

Omówienie parametrów konfiguracji

Podobnie jak w przypadku Redisa, poniżej znajduję się parametry konfiguracyjne z rozbiciem na każdy węzeł:

### S1 ###
bind 192.168.10.10 127.0.0.1
port 26379
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
sentinel monitor mymaster 192.168.10.10 6379 2
sentinel auth-pass mymaster meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 5000

### S2 ###
bind 192.168.10.20 127.0.0.1
port 26379
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
sentinel monitor mymaster 192.168.10.10 6379 2
sentinel auth-pass mymaster meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 5000

### S3 ###
bind 192.168.10.30 127.0.0.1
port 26379
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
sentinel monitor mymaster 192.168.10.10 6379 2
sentinel auth-pass mymaster meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 5000

Przed przystąpieniem do edycji konfiguracji, wykonajmy kilka zadań w celu jej uporządkowania. Katalog /etc/redis mamy już utworzony, dlatego od razu utworzymy kopię głównego pliku konfiguracyjnego:

cp /etc/redis-sentinel.conf /etc/redis/redis-sentinel.conf.orig

Ostatnim krokiem jest posprzątanie w konfiguracji, czyli na podstawie oryginalnego pliku wyfiltrujemy tylko faktyczne dyrektywy z pominięciem komentarzy:

egrep -v '#|^$' /etc/redis/redis-sentinel.conf.orig > /etc/redis-sentinel.conf

bind i port

Oba parametry mają takie samo znaczenie jak w przypadku Redisa więc nie będę ich raz jeszcze wyjaśniał. Jest natomiast jedna istotna kwestia dotycząca kolejności adresów. Pierwszym adresem musi być adres interfejsu, na którym Redis Sentinel będzie komunikował się z pozostałymi węzłami. Jeżeli pierwszą wartością będzie adres lokalnego interfejsu, to Sentinele nie będą w stanie wymieniać się informacjami, ponieważ proces użyje właśnie tego adresu (pierwszej wartości) przy uruchomieniu, na przykład:

redis  6503  0.3  0.1 142964  2588 ?  Ssl  13:30  0:03 /usr/bin/redis-sentinel 127.0.0.1:26379 [sentinel]

W prezentowanej konfiguracji Redis Sentinel będzie nasłuchiwał na dwóch adresach, tj. 192.168.10.x (podane w konfiguracji) i 127.0.0.1 oraz na domyślnym porcie 26379.

W prezentowanej konfiguracji parametr ten ma następujące wartości:

### S1 ###
bind 192.168.10.10 127.0.0.1
port 26379

### S2 ###
bind 192.168.10.20 127.0.0.1
port 26379

### S3 ###
bind 192.168.10.30 127.0.0.1
port 26379

requirepass

Parametr requirepass ustawia hasło i wymaga od klientów wydania komendy AUTH <PASSWORD> przed przetworzeniem jakichkolwiek innych poleceń. Widzisz, że znaczenie tej dyrektywy jest bardzo podobne jak w przypadku tożsamego parametru ustawianego w konfiguracji Redisa. Co więcej, parametr ten także jest wysyłany w postaci niezaszyfrowanej, więc nie chroni przed atakującym, który ma wystarczający dostęp do sieci, aby przeprowadzić podsłuchiwanie. Mimo tych ograniczeń jest to skuteczna warstwa zabezpieczeń przed oczywistym błędem pozostawiania niezabezpieczonych instancji Sentinel.

Jest to niezwykle ważny parametr, bez którego podłączenie do gniazda danego Sentinela nie wymaga żadnej autoryzacji. Dlatego też bardzo ważne jest zapewnienie dodatkowej warstwy ochrony np. w postaci filtra pakietów, który będzie zezwalał na połączenia do konsoli Sentineli tylko z pozostałych instancji wartowniczych lub zaufanych sieci. W przeciwnym razie każdy może wpiąć się do gniazda, na którym nasłuchuje wartownik i spowodować cykliczny auto-failover, który skutecznie unieruchomi replikację Master-Slave. Można to zrobić za pomocą prostego jednolinijkowca:

while : ; do redis-cli -h 192.168.10.10 -p 26379 SENTINEL failover mymaster ; sleep 0.5 ; done

W prezentowanej konfiguracji parametr ten ma następującą wartość i jest taki sam na każdym węźle:

requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"

monitor

Jest to chyba jedna z najważniejszych opcji. Wskazuje ona serwer nadrzędny i mówi, aby Redis Sentinel cyklicznie go monitorował i określał jego stan jako wyłączony tylko wtedy, kiedy wymagana liczba Sentineli, czyli kworum, się na to zgodzi. Parametr ten składa się z kilku wartości. Pierwsza z nich określa nazwę serwera nadrzędnego, dzięki której będziemy mogli się do niego odnosić (będzie występowała kilkukrotnie w konfiguracji) i dzięki której Sentinel będzie mógł automatycznie wykryć lokalizację (adres i port) mistrza. Druga i trzecia wartość wskazują adres IP i numer portu serwera nadrzędnego, który ma być monitorowany. Natomiast wartość ostatnia określa ile serwerów Sentinel musi wyrazić zgodę, aby doszło do uznania, że mistrz nie działa.

Ostatnia z wartości parametru sentinel monitor, tzw. kworum została już dosyć dokładnie wyjaśniona. Przypomnijmy sobie jednak, co oznacza kworum równe 2, czyli wartość wykorzystana w naszej konfiguracji. Mówi ona, że dwa Sentinele muszą jednoznacznie stwierdzić, że serwer nadrzędny jest nieosiągalny i powinien przejść w stan ODOWN. Jeżeli w grupie instancji jest jeden Redis Sentinel, ustawienie kworum na 2 spowoduje, że nigdy nie dojdzie do przepięcia.

Parametr ten musi być taki sam na każdym węźle i musi wskazywać na aktualnego mistrza (czyli serwer, który nie ma w konfiguracji ustawionego parametru replicaof). Co więcej, musi zostać umieszczony na samej górze konfiguracji, ponieważ jak wspomniałem, inne opcje odnoszą się do zdefiniowanej nazwy — parametr monitora musi być umieszczony zwłaszcza przed instrukcją auth-pass, aby uniknąć błędu No such master with the specified name podczas ponownego uruchamiania usługi Redis Sentinel.

Co istotne, parametr ten jest zmieniany automatycznie w zależności od sytuacji, czyli na przykład wtedy, kiedy dojdzie do zmiany serwera nadrzędnego.

W prezentowanej konfiguracji parametr ten ma następujące wartości:

### S1 ###
sentinel monitor mymaster 192.168.10.10 6379 2

### S2 ###
sentinel monitor mymaster 192.168.10.20 6379 2

### S3 ###
sentinel monitor mymaster 192.168.10.30 6379 2

auth-pass

Jest to druga z kluczowych opcji. Jeśli serwer główny Redis, który ma być monitorowany, ma ustawione hasło (w naszym przypadku ma), należy je wskazać po to, aby instancja Sentinel mogła się uwierzytelniać i administrować procesami Redisa. Jeżeli Sentinel nie będzie w stanie przepinać węzłów, w pierwszej kolejności zweryfikuj czy hasło w obu konfiguracjach na każdym węźle jest takie samo (musi być ono równe z wartościami opcji requirepass i masterauth).

W prezentowanej konfiguracji parametr ten ma następujące wartości i jest taki sam na każdym węźle:

sentinel auth-pass mymaster meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh

down-after-milliseconds i failover-timeout

Jeżeli Sentinel nie otrzyma żadnej odpowiedzi na polecenie PING z serwera nadrzędnego w przeciągu określonego czasu zdefiniowanego w parametrze down-after-milliseconds, uzna taki serwer za niedostępny/uszkodzony. Oznacza to, że jeśli dana instancja nie będzie odpowiadała przez 5 sekund, to zostanie sklasyfikowana jako +down (niedostępna) i w konsekwencji zostanie aktywowane głosowanie za pomocą wiadomości +vote w celu wybrania nowego węzła głównego (w obu przypadkach należy zajrzeć do plików dziennika, w którym pojawiają się obie instrukcje). Wartość domyślna to 60000ms (60s, 1min), natomiast w naszej konfiguracji ustawiliśmy ją na 5000ms (5s).

Pingujemy daną instancję za każdym razem, gdy ostatnia otrzymana odpowiedź, tj. PONG jest starsza niż skonfigurowany czas w down-after-milliseconds. Jeśli jednak wartość tego parametru jest większa niż 1 sekunda to i tak PING jest wykonywany co sekundę.

Natomiast parametr failover-timeout ustawia limit czasu przełączenia awaryjnego i definiuje on tak naprawdę kilka innych rzeczy (przeczytaj dokumentację parametru w pliku konfiguracyjnym). Wartość domyślna to 180000ms (180s, 3min). Zmienna ta ma wiele różnych zastosowań. Według oficjalnej dokumentacji określa ona:

• czas potrzebny do ponownego uruchomienia trybu failover po tym, jak poprzednie przełączenie awaryjne zostało już wykonane. Czas ten jest dwukrotnością limitu czasu przełączenia awaryjnego

• czas przełączenia awaryjnego liczony od momentu, gdy Sentinel wykrył nieprawidłową konfigurację

• czas potrzebny do anulowania przełączania awaryjnego, które już trwa, ale nie spowodowało żadnej zmiany konfiguracji (REPLICAOF NO ONE jeszcze nie zostało potwierdzone przez promowaną replikę)

• maksymalny czas oczekiwania w trakcie przełączania awaryjnego, aż wszystkie repliki zostaną ponownie skonfigurowane jako repliki dla nowo wybranego mistrza. Jednak nawet po tym czasie repliki i tak zostaną ponownie skonfigurowane przez Sentinele

W prezentowanej konfiguracji oba parametry mają następujące wartości i jest taki sam na każdym węźle:

sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 5000

myid

Parametr ten nie występuje w zestawie opcji do zmiany, jednak jest on również bardzo ważny. Określa on unikalny identyfikator lub etykietkę (ang. label) każdego węzła Sentinel. Zalecam nie ustawiać tego parametru po to, aby został wygenerowany automatycznie.

Jeżeli w grupie Sentineli występują węzły o takim samym identyfikatorze, mogą pojawić się problemy podczas przełączania awaryjnego. Na przykład może to powodować ignorowanie wszystkich wiadomości w tym tych o automatycznym wykrywaniu awarii i przepinaniu na węzłach o tym samym identyfikatorze.

Parametry dynamiczne

No właśnie. Musisz wiedzieć, że plik redis-sentinel.conf jest aktualizowany na bieżąco (podobnie jak redis.conf) i znajdują się w nim parametry, które zmieniają się w zależności od statusu danych węzłów. Podglądając sobie aktualny status za pomocą aliasu redis.stats, zobaczysz następujące opcje i ich wartości:

### S1 ###
sentinel known-replica mymaster 192.168.10.30 6379
sentinel known-replica mymaster 192.168.10.20 6379
sentinel known-sentinel mymaster 192.168.10.20 26379 f647de705536775591595dfb543a739924ce4364
sentinel known-sentinel mymaster 192.168.10.30 26379 c8e2591af9d8437bdafd78ccdc6c5b9f618613d6

### S2 ###
sentinel known-replica mymaster 192.168.10.20 6379
sentinel known-replica mymaster 192.168.10.30 6379
sentinel known-sentinel mymaster 192.168.10.30 26379 c8e2591af9d8437bdafd78ccdc6c5b9f618613d6
sentinel known-sentinel mymaster 192.168.10.10 26379 ef58a52e53566fde8106b9112ea4b9689023e35e

### S3 ###
sentinel known-replica mymaster 192.168.10.20 6379
sentinel known-replica mymaster 192.168.10.30 6379
sentinel known-sentinel mymaster 192.168.10.10 26379 ef58a52e53566fde8106b9112ea4b9689023e35e
sentinel known-sentinel mymaster 192.168.10.20 26379 f647de705536775591595dfb543a739924ce4364

Parametr known-replica (w wersji Redis 5 zastąpił poprzedni parametr known-slave) wskazuje Sentinelowi serwery podrzędne i niezależnie od stanu serwera (Master, Slave) oraz tego czy sama usługa Redisa działa lub nie, te parametry muszą być takie same na każdym węźle, jednak nie może znajdować się tam adres serwera nadrzędnego. Natomiast parametr known-sentinel wskazuje Sentinele, które na każdym węźle muszą być dwoma pozostałymi (nie może być tam adresu lokalnego Sentinela) i podobnie jak w parametrze wyżej jest niezależna od stanu serwera (Master, Slave) oraz statusu usługi Redis.

Konsola

Podobnie jak w przypadku Redisa, Sentinel umożliwia zarządzanie z poziomu konsoli po podpięciu się do gniazda, na którym nasłuchuje. Poleceń do administracji Sentinelami nie ma zbyt wiele a ich dokładny opis znajdziesz w rozdziale Sentinel commands oficjalnej dokumentacji. Poniżej omówimy tylko najważniejsze z nich.

Aby podłączyć się do konsoli, wydajemy polecenie:

# Bez uwierzytelniania:
redis-cli -h 127.0.0.1 -p 26379

# Z włączonym uwierzytelnianiem:
redis-cli -a $(grep "^requirepass" /etc/redis-sentinel.conf | awk '{print $2}' | sed 's/"//g') -h 127.0.0.1 -p 26379

Po poprawnym podłączeniu możesz sprawdzić, czy dany węzeł działa:

127.0.0.1:26379> ping
PONG

Każde z poleceń odnoszące się do Redis Sentinela zaczyna się ciągiem SENTINEL. Jednym z ważniejszych jest możliwość sprawdzenia dostępnych mistrzów i ich statusu:

127.0.0.1:26379> SENTINEL masters

Jednak aby wyświetlić informacje tylko o konkretnym mistrzu:

127.0.0.1:26379> SENTINEL master <label>

Natomiast jeśli zależy nam na uzyskaniu adresu i numeru portu aktualnego mistrza:

127.0.0.1:26379> SENTINEL get-master-addr-by-name <label>
1) "192.168.10.10"
2) "6379"

Możemy także wykonać polecenie ROLE, które zwraca informacje o danej instancji:

127.0.0.1:6379> ROLE
1) "slave"
2) "192.168.10.20"
3) (integer) 6379
4) "connected"
5) (integer) 1323988

Kolejne niezwykle istotne polecenie, które pozwala podejrzeć podłączone repliki:

127.0.0.1:26379> SENTINEL replicas <label>

Oraz podłączone pozostałe Sentinele w grupie:

127.0.0.1:26379> SENTINEL sentinels <label>

W przypadku problemów lub potrzeby wykonania procesu przełączania możemy wymusić jego rozpoczęcie za pomocą poniższej komendy, pomijając wszelkie mechanizmy autoryzacyjne:

127.0.0.1:26379> SENTINEL failover <label>

Pozwala ono traktować serwer nadrzędny tak, jakby był nieosiągalny i pomija wszelkie zgody, które w przypadku automatycznego przełączania muszą zostać wydane przez inne Sentinele. Co istotne, po wykonaniu tego polecenia nowa wersja konfiguracji zostanie opublikowana, tak aby inne Sentinele zaktualizowały swoje konfiguracje.

Tryb wiersza poleceń dostarcza możliwość zresetowania ustawień instancji nadrzędnej. Wyzwala on funkcję sentinelResetMaster, która powoduje usunięcie poprzednich stanów instancji głównej, w tym trwającego przełączania awaryjnego, przywrócenie wszystkich możliwych timerów do ustawień domyślnych, a także usunięcie wykrytych replik i Sentineli. Zresetowanie mistrza powoduje także rozłączenie wszystkich połączeń i zestawienie ich na nowo:

127.0.0.1:26379> SENTINEL reset <label>

Domyślnie konfiguracja jest aktualizowana za każdym razem, kiedy dojdzie do zmiany stanu Sentinela. Niekiedy jednak może być przydatne wymuszenie zrzucenia konfiguracji na dysk, np. jeśli utraciliśmy do niej dostęp lub została w jakiś sposób usunięta:

127.0.0.1:26379> SENTINEL flushconfig

Istnieje też możliwość weryfikacji parametru kworum oraz tego, czy Sentinele są w stanie je osiągnąć, aby rozpocząć przełączenie awaryjne, a także zapewnić większość potrzebną do autoryzacji tego procesu:

127.0.0.1:26379> SENTINEL ckquorum <label>

Oczywiście istnieje możliwość dynamicznej zmiany parametrów Sentineli, które ustawiane są w pliku konfiguracyjnym. Jeżeli zajdzie potrzeba zmiany mistrza, którego chcemy monitorować (odpowiada dyrektywie sentinel monitor):

127.0.0.1:26379> SENTINEL MONITOR <name> <ip> <port> <quorum>

Lub gdy wymagane będzie usunięcie obecnego mistrza, który jest monitorowany:

127.0.0.1:26379> SENTINEL REMOVE <name>

Podobnie jeżeli zajdzie potrzeba zmiany pozostałych parametrów danej instancji Redis Sentinel, na przykład:

127.0.0.1:26379> SENTINEL SET mymaster down-after-milliseconds 1000
127.0.0.1:26379> SENTINEL SET mymaster quorum 5

Uruchomienie Sentineli

Mając tak skonfigurowane Sentinele, przystąpmy do ich uruchomienia:

### S1 ###
sentinel.start

redis.stats
192.168.10.10
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
masterauth "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
replica-priority 1
protected-mode yes
replica-read-only yes
sentinel myid ef58a52e53566fde8106b9112ea4b9689023e35e
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
sentinel monitor mymaster 192.168.10.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 5000
sentinel auth-pass mymaster meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
sentinel known-replica mymaster 192.168.10.30 6379
sentinel known-replica mymaster 192.168.10.20 6379
sentinel known-sentinel mymaster 192.168.10.20 26379 f647de705536775591595dfb543a739924ce4364
sentinel known-sentinel mymaster 192.168.10.30 26379 c8e2591af9d8437bdafd78ccdc6c5b9f618613d6

### S2 ###
sentinel.start

redis.stats
192.168.10.20
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
masterauth "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
replica-priority 10
protected-mode yes
replica-read-only yes
replicaof 192.168.10.10 6379
sentinel myid f647de705536775591595dfb543a739924ce4364
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
sentinel monitor mymaster 192.168.10.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 5000
sentinel auth-pass mymaster meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
sentinel known-replica mymaster 192.168.10.20 6379
sentinel known-replica mymaster 192.168.10.30 6379
sentinel known-sentinel mymaster 192.168.10.30 26379 c8e2591af9d8437bdafd78ccdc6c5b9f618613d6
sentinel known-sentinel mymaster 192.168.10.10 26379 ef58a52e53566fde8106b9112ea4b9689023e35e

### S3 ###
sentinel.start

redis.stats
192.168.10.30
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
masterauth "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
replica-priority 100
protected-mode yes
replica-read-only yes
replicaof 192.168.10.10 6379
sentinel myid c8e2591af9d8437bdafd78ccdc6c5b9f618613d6
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
sentinel monitor mymaster 192.168.10.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 5000
sentinel auth-pass mymaster meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
sentinel known-replica mymaster 192.168.10.20 6379
sentinel known-replica mymaster 192.168.10.30 6379
sentinel known-sentinel mymaster 192.168.10.10 26379 ef58a52e53566fde8106b9112ea4b9689023e35e
sentinel known-sentinel mymaster 192.168.10.20 26379 f647de705536775591595dfb543a739924ce4364

Opcje Sentinela zaczynają się od ciągu sentinel jednak dla ogólnej przejrzystości wkleiłem też te obsługiwane z poziomu Redisa.

Dodawanie i usuwanie Sentineli

Przed przystąpieniem do testowania konfiguracji omówmy jeszcze przypadki dodania nowych Sentineli lub usunięcia starych. Sam proces jest bardzo prosty jednak na tyle ważny, że został opisany w artykule Adding or removing Sentinels oficjalnej dokumentacji.

Mając skonfigurowaną grupę wartowników, dodanie kolejnego jest niezwykle proste i sprowadza się jedynie do ustawienia poniższych parametrów w konfiguracji (czyli tych, które ustawialiśmy dla obecnie działających Sentineli):

bind <ip> 127.0.0.1
port 26379
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
sentinel monitor mymaster 192.168.10.10 6379 2
sentinel auth-pass mymaster meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 5000

Po uruchomieniu takiego węzła w ciągu 10 sekund (wartość parametru hz) zdobędzie on listę pozostałych Sentineli oraz informację o replikach dołączonych do aktualnego mistrza. Jeżeli zajdzie potrzeba dodania kilku Sentineli, to zgodnie z oficjalną dokumentacją, zaleca się dodanie ich jeden po drugim, czekając, aż wszyscy pozostali wartownicy dowiedzą się o pierwszym z nich przed dodaniem następnego.

Usunięcie jednego ze strażników jest trochę bardziej skomplikowane, ponieważ jak wspominaliśmy wcześniej, Sentinele zawsze przechowują informację o sobie jak i pozostałych Sentinelach nawet w przypadku powrotu z awarii czy planowanych restartach. Jest to w pełni zamierzone zachowanie, ponieważ strażnicy powinni być w stanie poprawnie skonfigurować powracającą replikę po awarii, a bez tych informacji nie będą w stanie tego zrobić.

Procedura usunięcia danej instancji jest następująca:

• zatrzymanie procesu Redis Sentinel, który ma zostać odłączony od grupy
• wysłanie polecenia SENTINEL RESET <label> lub SENTINEL RESET * do wszystkich działających instancji Sentinel, czyli wykonanie tego polecenia na każdym węźle Sentinel
• weryfikacja aktualnie aktywnych wartowników za pomocą polecenia SENTINEL masters lub SENTINEL master <label> na każdym węźle Sentinel

Powyższy przepis sprawi, że usunięty węzeł nie będzie więcej widoczny z poziomu działających Sentineli. Jednak jeśli konfiguracja usuniętego Sentinela nie została zmieniona, to po jego uruchomieniu ponownie zostanie dołączony do grupy — dlatego jeśli chcesz się go pozbyć raz na zawsze, pamiętaj o wyzerowaniu konfiguracji z pliku redis-sentinel.conf.

W przypadku permanentnego usunięcia jednej z replik polecenie SENTINEL RESET jest także wymagane do wykonania, aby działające Sentinele mogły zaktualizować swoje konfiguracje i zapomnieć o usuniętej instancji podrzędnej.

Scenariusz testowy: etap 1

Teraz przejdźmy do sedna sprawy, czyli wygenerujemy sobie dwa scenariusze testowe, w tym omówimy problemy, o których wspomniałem na początku tego jak i poprzedniego wpisu.

Na tym etapie sytuacja będzie lekko wyidealizowana, ponieważ pojawiające się problemy będą dotyczyły tylko usługi Redis uruchomionej na każdym z węzłów, natomiast Redis Sentinel uruchomiony także na każdym z nich będzie zawsze działał. Taki scenariusz jest rzadziej spotykany, ponieważ bardzo często oba procesy umieszcza się razem. Jeśli w przypadku awarii pada cały węzeł, na którym uruchomiony jest Redis oraz Redis Sentinel, tracimy obie usługi. Wykonajmy jednak ten etap (pozwoli on wyciągnąć kilka ciekawych wniosków), aby zobaczyć na własne oczy, jak zachowuje się system w przypadku minimalnej wymaganej i zalecanej ilości Sentineli.

Wszystkie węzły działają

Sytuacja ta ma miejsce kiedy wszystkie węzły są uruchomione i działają poprawnie. W konfiguracji początkowej serwer R1 pełni rolę mistrza natomiast R2 i R3 działają jako repliki.

Mając poprawnie skonfigurowaną replikację Master-Slave oraz usługę Redis Sentinel, możemy przełączać się między węzłami, czyli promować dany węzeł do stanu Master:

127.0.0.1:26379> SENTINEL failover mymaster
OK

Polecenie to jest zalecanym sposobem awansowania, który nie wymaga zgody innych strażników, i powinno być wykonywane zawsze przed wydaniem komendy SLAVEOF no one, która nie daje żadnej gwarancji działania i sprawdza się tylko, jeśli obecny mistrz uległ awarii wraz z Sentinelami, które nie są w stanie zapewnić wymaganego kworum i większości. Co ważne podkreślenia, wydając polecenie SENTINEL failover, Sentinel będzie promował instancję podrzędną do roli mistrza na podstawie parametru replica-priority. Przypomnijmy sobie, że wartość niższa ma pierwszeństwo i oznacza wyższy priorytet. Co więcej, Sentinel rozpatrzy tylko te repliki, które ma ustawione w parametrze sentinel known-replica, i które spełnią kilka dodatkowych warunków (o czym będzie za chwilę):

sentinel known-replica mymaster 192.168.10.20 6379 # R2
sentinel known-replica mymaster 192.168.10.30 6379 # R3

Czyli idąc za tym, Sentinel wybierze jedną z dwóch replik, która ma wyższy priorytet (tutaj: R2, priorytet 10). Zgodnie z tym, w naszej konfiguracji zawsze dojdzie do przepinania R1 (priorytet 1) między R2 (priorytet 10). Następnie Sentinel zaktualizuje parametr sentinel known-replica, który po przepięciu będzie wyglądał tak:

sentinel known-replica mymaster 192.168.10.10 6379 # R1
sentinel known-replica mymaster 192.168.10.30 6379 # R3

Jeżeli Sentinel ponownie przeprowadzi akcję awansowania nowego mistrza, wykona tak naprawdę akcję odwrotną, czyli wybierze węzeł R1 (priorytet 1), który ma wyższy priorytet niż R3 (priorytet 100). Dzięki temu w naszej konfiguracji zawsze dojdzie do przepinania R1 (priorytet 1) między R2 (priorytet 10) i na odwrót, natomiast R3 (priorytet 100) zawsze pozostanie repliką.

Jeżeli zdarzy się sytuacja, że dojdzie do przepięcia z R1 na R2 i Sentinel (bądź administrator) wypromuje z jakiegoś względu raz jeszcze nową instancję do roli Master, a parametry known-replica nie zostaną zaktualizowane w tym czasie, to serwer R3 stanie się mistrzem. Jest to jedyna sytuacja, kiedy R3 może przejąć rolę szefa i ma związek z logicznym ciągiem zdarzeń, ponieważ R3 nadal widnieje w parametrze known-replica zaś drugi węzeł, którego adres IP także znajduje się w parametrze known-replica, jest jeszcze w starej roli Master.

To jest kolejna ważna uwaga: w momencie przepięcia, przez chwilę dwa węzły mają rolę Master, jednak Sentinel natychmiast aktualizuje parametry sentinel monitor i replicaof (oraz parę innych), dzięki którym wiadomo, który z nich przejmie faktycznie rolę serwera nadrzędnego.

R2 nie działa

W sytuacji kiedy R2 (Slave) ulegnie awarii nie dzieje się nic złego, ponieważ aplikacja nadal może połączyć się do serwera nadrzędnego (za pomocą HAProxy, który go wykrywa). W takiej konfiguracji mamy jednego mistrza (R1) oraz jeden serwer podrzędny (R3).

Dzięki usłudze Sentinel możemy nadal przełączać się między obydwoma działającymi węzłami, ponieważ spełniamy kworum oraz większość wymaganą do autoryzacji przepięcia.

R2 i R3 nie działają

Jeżeli R2 (Slave) nadal nie działa i awarii ulegnie R3 (Slave) to nadal wszystko będzie działać poprawnie, ponieważ w mamy wciąż działający serwer nadrzędny (R1).

Istotną informacją jest to, że Redis Sentinel nie usuwa ani nie aktualizuje parametrów o węzłach, które nie działają:

redis.stats
192.168.10.10
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
masterauth "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
replica-priority 1
replica-read-only no
protected-mode yes
sentinel myid ef58a52e53566fde8106b9112ea4b9689023e35e
requirepass "meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2"
sentinel monitor mymaster 192.168.10.10 6379 2
sentinel auth-pass mymaster meiNae5Thio7shohghiovoh7AhMieng3feex7feiraiQuoh2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 60000
sentinel known-replica mymaster 192.168.10.30 6379
sentinel known-replica mymaster 192.168.10.20 6379
sentinel known-sentinel mymaster 192.168.10.20 26379 f647de705536775591595dfb543a739924ce4364
sentinel known-sentinel mymaster 192.168.10.30 26379 c8e2591af9d8437bdafd78ccdc6c5b9f618613d6
---------------------------------------
# Replication
role:master
connected_slaves:0
master_replid:f469ad2fcbe64467abb0a144087c50bc041088b2=
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:286910
second_repl_offset:-13
repl_backlog_active:14
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:28691f
PONG