Generator Nginx load balancer

Generator load balancera Nginx

Gdy jedna instancja aplikacji nie wystarcza, ruch rozkłada się między kilka serwerów. Nginx pełni wtedy rolę load balancera, zwiększając wydajność i niezawodność.

Metody rozkładu ruchu

Przykład

Dwie instancje aplikacji na portach 3000 i 3001 tworzą grupę backend. Nginx kieruje ruch metodą least_conn i utrzymuje do 32 połączeń keepalive na serwer.

Waga serwera

Dyrektywa weight pozwala kierować więcej ruchu do mocniejszej maszyny, np. server 10.0.0.1:3000 weight=3;. Serwer zapasowy ustawia się słowem backup, a wyłączony — down.

Jak działa generator load balancera Nginx

Generator zbiera wybrane ustawienia w jeden blok upstream i dopisuje do niego konfigurację proxy_pass wraz z nagłówkami przekazującymi dane klienta. Sam blok upstream jest listą serwerów, do których Nginx może kierować żądanie; reszta konfiguracji to reguły wyboru jednego z nich.

Mechanizm wyboru zależy od metody. W trybie round-robin Nginx przechodzi po liście serwerów po kolei i po ostatnim wraca do pierwszego. W least_conn wybiera serwer z najmniejszą liczbą aktywnych połączeń, a przy ustalonych wagach liczy ten stosunek względem wagi. W ip_hash wylicza skrót z adresu klienta i przypisuje go do stałego miejsca w grupie, więc ten sam klient trafia do tego samego serwera.

Waga nie jest proporcją ruchu wyrażoną w procentach — to mnożnik w kolejce wyboru. Przy wagach 3 i 1 (suma 4) co czwarte żądanie w round-robin trafia do lżejszego serwera, co daje 75% i 25%. Dyrektywa keepalive w upstreamie nie otwiera połączeń z góry — ustala, ile bezczynnych połączeń do każdego serwera Nginx może trzymać w cache i użyć ponownie. Dostępność sterują znaczniki backup i down oraz progi max_fails i fail_timeout: po przekroczeniu liczby nieudanych prób w oknie czasowym serwer jest pomijany na czas równy fail_timeout.

Przykład konfiguracji krok po kroku

1. Do grupy trafiają dwie instancje aplikacji: 10.0.0.1:3000 na mocniejszej maszynie i 10.0.0.2:3001 na słabszej. Każda jest osobnym wpisem server w bloku upstream.
2. Zostawiasz domyślną metodę round-robin i dodajesz weight=3 do pierwszego serwera. Suma wag wynosi 3 + 1 = 4, więc na każde 4 żądania trzy idą do 10.0.0.1:3000, a jedno do 10.0.0.2:3001 — czyli 75% i 25% ruchu.
3. Jeśli czasy odpowiedzi są nierówne, przełączasz metodę na least_conn. Nginx wybierze wtedy serwer o najmniejszej liczbie aktywnych połączeń, a waga nadal wpływa na ten wybór.
4. Dodajesz keepalive 32. Nginx może trzymać do 32 bezczynnych połączeń do każdego z dwóch serwerów, razem do 64 w puli. W bloku location ustawiasz proxy_http_version 1.1 oraz proxy_set_header dla nagłówka Connection z pustą wartością.
5. Ustawiasz max_fails 3 i fail_timeout 30s. Gdy w ciągu 30 sekund trzy próby do 10.0.0.1:3000 zakończą się błędem, serwer wypada z grupy na 30 sekund i 100% ruchu obsługuje 10.0.0.2:3001.
6. Na koniec dodajesz zapas: trzeci serwer 10.0.0.3:3002 oznaczasz słowem backup — przyjmuje ruch tylko wtedy, gdy oba serwery podstawowe są niedostępne.

Tabela referencyjna ustawień upstream

Praktyczne wskazówki

• Zacznij od round-robin — domyślna metoda wystarcza, gdy instancje mają podobną moc, a żądania są krótkie. least_conn włączaj, gdy czasy odpowiedzi są nierówne i część połączeń utrzymuje się dłużej.
• Waga to nie pomiar wydajności — weight=3 ustawiaj świadomie, znając różnicę między maszynami. Sam stosunek 3:1 nie chroni szybszego serwera przed przeciążeniem przy nagłym wzroście ruchu.
• keepalive wymaga dwóch linii w location — proxy_http_version 1.1 oraz pusty nagłówek Connection. Bez nich pula połączeń nie zadziała mimo wpisu keepalive w upstreamie.
• Nie mieszaj ip_hash z lepkim magazynem sesji — jeśli możesz przenieść sesje do wspólnego magazynu, ip_hash przestaje być potrzebny, a rozkład ruchu staje się równiejszy.
• Ustaw progi awarii — max_fails i fail_timeout chronią przed kierowaniem ruchu do martwej instancji. Wartości dobierz do tego, jak aplikacja znosi pojedyncze błędy.

Czego narzędzie nie uwzględnia

• Nie uruchamia Nginxa — generator zwraca fragment konfiguracji, ale nie waliduje go poleceniem nginx -t ani nie sprawdza, czy dane dyrektywy są dostępne w Twojej wersji.
• Nie zna Twojej infrastruktury — nie wie, ile rdzeni mają maszyny ani jakie jest realne obciążenie, więc waga i keepalive pozostają wartościami, które dobierasz samodzielnie.
• Nie monitoruje stanu serwerów — wygenerowana konfiguracja opiera się na max_fails i fail_timeout; zaawansowane health checks to funkcja Nginx Plus i narzędzie jej nie generuje.
• Nie uwzględnia warstwy transportu i limitów — konfiguracja TLS, worker_connections, rozwiązywanie nazw DNS w upstreamie i reguły zapory pozostają poza jego zakresem.

Najczęstsze pytania