Prosty failover Nginx

Korzystając z serwera Nginx jako proxy dla treści statycznych i dynamicznych warto pomyśleć o konfiguracji instancji failover dla naszego zaplecza. Stworzenie takiego vhosta w obrębie serwera proxy, bądź na innej maszynie pozwoli nam nie tylko przekierować ruch na wybraną przez nas i wcześniej przygotowaną stronę (co zwiększy komfort UX), ale także da nam możliwość wysłania robotom odpowiednich komunikatów (w postaci nagłówków przeglądarki).

Nginx daje nam możliwość zdefiniowania stron poszczególnych błędów serwera. W ogólności robi się to w następujący sposób:

error_page 403 /error403.html;
location = /error403.html {
    root   html;
    allow all;
}

Skorzystanie z opcji failover i przekierowanie ruchu na odpowiednio skonfigurowaną instancję serwera www daje nam jedna o wiele większe możliwości zarówno w zakresie konfiguracji zachowania serwera (czasu i trybu przełączenia na failover) oraz zaserwowania użytkownikowi np. dynamicznej strony z komunikatem o błędzie serwera. Użycie tej metody nie wyklucza oczywiście przygotowania pięknych i indywidualnych stron dla poszczególnych błędów serwera 😉

Sposób konfiguracji Nginx jako proxy opisałem m.in. w notce o używaniu tego serwera do rozdzielania ruchu dla dostarczania treści statycznych i dynamicznych (cały tekst znajdziecie tutaj: „Serwer Nginx dla treści statycznych i dynamicznych„). Definicję naszego zaplecza rozpoczynamy od dyrektywy upstream w sekcji http konfiguracji Nginx:

upstream static_balancer {
       server 10.8.0.12:8099 weight=1 backup;
       server 127.0.0.1:8099 weight=1;
}

Powyższy przykład zawiera podstawową bardzo proste zaplecze z serwerem failover, gdyż jeden ze zdefiniowanych serwerów działa w trybie backup, a co za tym idzie zostanie użyty dopiero, kiedy wszystkie inne serwery będą obciążone bądź nieaktywne.

Takie zdefiniowanie zaplecza oczywiście pozwoli nam na uzyskanie podstawowego efektu failover, jednak dobrze byłoby zmodyfikować konfigurację tak, żeby moment przełączenia zaplecza na serwer failover następował w zdefiniowanych przez nas warunkach.

Nginx dostarcza dla serwerów zaplecza kilku parametrów, które pozwalają zdefiniować sposób zachowania proxy podczas przełączania się pomiędzy tymi serwerami. Na początek powinniśmy zdefiniować kiedy zaplecze ma zostać przełączone na kolejny serwer. Służy do tego dyrektywa proxy_next_upstream, którą w naszym przypadku definiujemy w sekcji http konfiguracji Nginx. Dyrektywa może przyjmować następujące opcje:

  • error – przełącza serwer przy błędzie w wysyłaniu zapytania bądź odbiorze odpowiedzi,
  • timeout – przełącza serwer przy wystąpieniu timeout’u,
  • invalid_header – przełącza serwer przy otrzymaniu błędnej albo pustej odpowiedzi,
  • http_50x – przełącza serwer przy wystąpieniu zdefiniowanego błędu 50x,
  • http_404 – przełącza serwer przy wystąpieniu błędu 404.

proxy_next_upstream posiada także opcję off, która wyłącza przełączanie zapytań pomiędzy serwerami zaplecza.

Kiedy już zdefiniujemy warunki pod jakimi proxy podejmie próbę przełączenia serwera powinniśmy zdefiniować dla poszczególnych serwerów kiedy zwrócą one proxy informację, że zaszedł warunek do przełączenia serwera. Parametry te definiujemy w każdej linijce server naszego zaplecza, a najważniejszymi z nich są:

  • max_fails – liczba nieudanych prób dostępu do serwera (wg definicji prób w proxy_next_upstream) po której serwer zostanie uznany za nieaktywny
  • fail_timeout – czas dostępu po jakim próba zostanie uznana za nieudaną

Po tych krokach konfiguracja naszego failover  jest właściwie zakończona. Pozostaje nam teraz jedynie odpowiednie przygotowanie serwera lub vhosta, na który przekierowane zostaną zapytania.  Co do zasady można zrobić to według własnych upodobań i zamysłu konstrukcyjnego całej infrastruktury, jednak z doświadczenia polecić mogę włączenie do tej konfiguracji trzech rzeczy, które są istotne z punktu widzenia obecności strony w wyszukiwarkach (przykłady na podstawie konfiguracji vhost Nginx):

  1. przekierowanie ruchu z podstron na stronę failovera – dodanie prostej reguły rewrite zapobiegnie pojawianiu się błędów 404, gdyż niezależnie z jakiego adresu ( url + uri ) użytkownik trafi na failover otrzyma domyślną stronę vhosta:
    index failover.html; //default document index
    try_files $uri $uri/ /failover.html; //rewrite uri to default document index
  2. zwracanie przez vhosta nagłówka Retry-After, który wskazuje robotom po ilu sekundach mają ponownie odwiedzić stronę w przypadku nieudanych odwiedzin:
    add_header Retry-After 600;
  3. zwracanie przez vhosta nagłówka 503 oznaczającego przerwę techniczną (w tym celu możemy skorzystać z modułu ngx_headers_more):
    more_set_headers -s 503;
Podziel się:

Mikołaj Niedbała

I'm a Poland based IT administrator, linux administrator and IT engineer creating professional IT infrastructure solutions based on Linux and virtual environments.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *