Równoważenie obciążenia z serwerami dedykowanymi: architektura, algorytmy i implementacja w rzeczywistych warunkach

Równoważenie obciążenia to proces dystrybucji przychodzącego ruchu sieciowego między wiele serwerów, tak aby żaden pojedynczy węzeł nie stał się wąskim gardłem, zapewniając stałą wydajność, odporność na awarie i skalowalność poziomą. W środowisku serwera dedykowanego moduł równoważenia obciążenia znajduje się przed pulą serwerów i podejmuje decyzje dotyczące routingu w czasie rzeczywistym na podstawie kondycji serwera, aktywnych połączeń, opóźnienia odpowiedzi lub niestandardowych reguł polityki.

W przypadku każdej infrastruktury obsługującej obciążenia wrażliwe na opóźnienia — platformy e-commerce, aplikacje SaaS, API o dużym ruchu lub strumieniowanie multimediów — równoważenie obciążenia nie jest opcjonalne. Jest to architektoniczny fundament, który oddziela kruchy setup z pojedynczym punktem awarii od odpornego systemu klasy produkcyjnej.

Jak naprawdę działa równoważenie obciążenia: przepływ techniczny

Zrozumienie równoważenia obciążenia wymaga zrozumienia pełnego cyklu życia żądania, a nie tylko abstrakcyjnej koncepcji „dystrybucji ruchu”.

Potok routingu żądań

1. Rozwiązanie DNS kieruje klienta na adres IP modułu równoważenia obciążenia (lub wirtualny IP w konfiguracji anycast), a nie na żaden indywidualny serwer.
2. Moduł równoważenia obciążenia odbiera połączenie na warstwie 4 (TCP/UDP) lub warstwie 7 (HTTP/HTTPS) modelu OSI.
3. Moduł ocenia swoją tablicę routingu, stosuje skonfigurowany algorytm i sprawdza aktualny stan kondycji każdego węzła backendu.
4. Żądanie jest przekazywane do wybranego serwera backendu. W zależności od trybu (NAT, Direct Server Return lub tunelowanie IP), ścieżka odpowiedzi może lub nie może przechodzić przez moduł równoważenia.
5. Demony sprawdzania kondycji działają równolegle, stale sondując każdy backend za pomocą TCP ping, kodów statusu HTTP lub niestandardowych skryptów. Węzeł z błędem jest usuwany z puli w ciągu kilku sekund.

Równoważenie obciążenia warstwy 4 vs. warstwy 7

To rozróżnienie jest jedną z najbardziej istotnych decyzji architektonicznych, jakie podejmiesz.

W przypadku większości aplikacji webowych hostowanych na Serwerach Dedykowanych, warstwa 7 jest właściwym wyborem, ponieważ umożliwia inteligentny routing, odciążanie SSL i szczegółowe sprawdzanie kondycji na podstawie kodów odpowiedzi HTTP, a nie surowej łączności TCP.

Algorytmy równoważenia obciążenia: wybór właściwej strategii

Algorytm określa, który serwer backendu otrzymuje każde przychodzące żądanie. Wybór niewłaściwego dla profilu obciążenia jest częstym źródłem nierównomiernego wykorzystania zasobów.

Round Robin

Żądania są dystrybuowane sekwencyjnie między wszystkie zdrowe węzły. Proste i skuteczne, gdy wszystkie serwery mają identyczne specyfikacje sprzętowe, a czasy przetwarzania żądań są w przybliżeniu równe.

Pułapka: Jeśli jedno żądanie trwa 10 sekund, a następne 10 milisekund, round robin nie uwzględnia tej dysproporcji. Wolny backend gromadzi kolejkę, podczas gdy inne są bezczynne.

Ważony Round Robin

Każdemu serwerowi przypisywana jest waga numeryczna. Serwer z wagą 3 otrzymuje trzy razy więcej żądań niż serwer z wagą 1. Używaj tego, gdy pula zawiera niejednorodny sprzęt — na przykład mieszając węzeł 32-rdzeniowy z węzłem 16-rdzeniowym.

Najmniej połączeń

Moduł równoważenia śledzi liczbę aktywnych połączeń z każdym backendem i kieruje nowe żądania do serwera z najmniejszą liczbą otwartych połączeń. Jest to najbardziej odpowiedni domyślny algorytm dla obciążeń o zmiennym czasie trwania żądań, takich jak aplikacje webowe oparte na bazach danych.

Najkrótszy czas odpowiedzi

Rozszerzenie algorytmu najmniejszej liczby połączeń, które uwzględnia również mierzone opóźnienie backendu. Wygrywa serwer z najniższą kombinacją aktywnych połączeń i średniego czasu odpowiedzi. Wymaga to od modułu równoważenia utrzymywania metryk opóźnień, co dodaje niewielki narzut, ale znacznie poprawia jakość dystrybucji przy mieszanym obciążeniu.

Hash IP (koligacja źródłowa)

Źródłowy adres IP klienta jest haszowany w celu deterministycznego wyboru backendu. Ten sam klient zawsze trafia na ten sam serwer, o ile skład puli się nie zmienia. Zapewnia to prymitywną formę trwałości sesji bez konieczności korzystania ze współdzielonego magazynu sesji.

Krytyczny przypadek brzegowy: Jeśli duża część ruchu pochodzi zza korporacyjnego NAT lub bramki operatora sieci komórkowej, tysiące użytkowników może współdzielić jeden źródłowy IP, powodując poważną nierównowagę. Zawsze audytuj dystrybucję ruchu przed poleganiem na hash IP w środowisku produkcyjnym.

Losowy z dwoma wyborami (potęga dwóch)

Moduł równoważenia losowo wybiera dwa serwery kandydujące i kieruje ruch do tego z mniejszą liczbą aktywnych połączeń. To probabilistyczne podejście skaluje się bardzo dobrze w dużych pulach (50+ węzłów), ponieważ unika narzutu koordynacji globalnego skanowania najmniejszej liczby połączeń, jednocześnie unikając najgorszego przypadku nierównowagi przy czystym losowym wyborze.

Trwałość sesji: gdy bezstanowość nie jest opcją

Wiele starszych aplikacji przechowuje stan sesji lokalnie na serwerze (na przykład $_SESSION PHP zapisywane na dysk). W takich przypadkach kierowanie powracającego użytkownika do innego backendu powoduje utratę sesji, co objawia się nieoczekiwanym wylogowaniem lub utratą danych koszyka zakupów.

Moduły równoważenia obciążenia rozwiązują to za pomocą lepkich sesji, implementowanych poprzez:

• Wstrzykiwanie ciasteczek: Moduł równoważenia wstrzykuje ciasteczko (np. SERVERID=node2) do odpowiedzi HTTP. Kolejne żądania od tego klienta zawierają ciasteczko, a moduł równoważenia odczytuje je, aby kierować z powrotem do tego samego węzła.
• Koligacja źródłowego IP: Jak opisano powyżej, mniej niezawodna, ale nie wymaga obsługi ciasteczek przez aplikację.

Właściwe długoterminowe rozwiązanie to eksternalizacja przechowywania sesji do współdzielonego backendu — Redis lub Memcached — tak aby dowolny węzeł backendu mógł obsługiwać dowolnego użytkownika. Eliminuje to całkowicie zależność od lepkich sesji i sprawia, że pula jest w pełni bezstanowa, co znacznie upraszcza skalowanie i przełączanie awaryjne. Jeśli budujesz nową aplikację, projektuj bezstanowe backendy od pierwszego dnia.

Sprawdzanie kondycji: mechanizm automatycznego przełączania awaryjnego

Moduł równoważenia obciążenia jest tylko tak niezawodny, jak jego konfiguracja sprawdzania kondycji. Błędnie skonfigurowane sprawdzenia kondycji są odpowiedzialne za znaczną część rzeczywistych incydentów z modułami równoważenia obciążenia.

Typy sprawdzeń kondycji

• Sprawdzenie TCP: Otwiera połączenie TCP do portu backendu. Potwierdza, że proces nasłuchuje, ale nie weryfikuje poprawności na poziomie aplikacji.
• Sprawdzenie HTTP/HTTPS: Wysyła żądanie HTTP do zdefiniowanego punktu końcowego (np. /health) i oczekuje określonego kodu statusu (zazwyczaj 200 OK). Jest to minimalny akceptowalny standard dla aplikacji webowych.
• Sprawdzenie niestandardowym skryptem: Wykonuje dowolny skrypt, który może odpytywać bazę danych, sprawdzać przestrzeń dyskową lub weryfikować stan aplikacji. Zwraca 0 dla zdrowego, wartość niezerową dla niezdrowego.

Krytyczne parametry konfiguracji

• interval: Jak często uruchamiane jest sprawdzenie (np. co 5 sekund).
• timeout: Jak długo czekać na odpowiedź przed oznaczeniem sprawdzenia jako nieudanego.
• rise: Liczba kolejnych pomyślnych sprawdzeń wymaganych do oznaczenia węzła jako zdrowego (zapobiega migotaniu).
• fall: Liczba kolejnych nieudanych sprawdzeń wymaganych do usunięcia węzła z puli.

Typowa konfiguracja produkcyjna dla HAProxy wygląda następująco:

backend web_servers
    balance leastconn
    option httpchk GET /health HTTP/1.1rnHost: example.com
    http-check expect status 200
    default-server inter 5s fall 3 rise 2 slowstart 60s
    server node1 192.168.1.10:80 check weight 10
    server node2 192.168.1.11:80 check weight 10
    server node3 192.168.1.12:80 check weight 5

Dyrektywa slowstart 60s jest szczególnie cenna: stopniowo zwiększa ruch do nowo odzyskanego węzła przez 60 sekund, zamiast natychmiast wysyłać pełne obciążenie, zapobiegając problemowi stada grzmotów, gdy backend wraca online po konserwacji.

Terminacja SSL i odciążanie TLS

Obsługa szyfrowania i deszyfrowania TLS jest kosztowna obliczeniowo. W naiwnej konfiguracji każdy serwer backendu wykonuje tę pracę niezależnie. Terminacja SSL na module równoważenia obciążenia oznacza, że moduł deszyfruje przychodzący ruch HTTPS i przekazuje zwykły HTTP do backendów przez zaufaną sieć wewnętrzną.

Korzyści:

• Zmniejsza obciążenie CPU serwerów backendowych, zwalniając cykle dla logiki aplikacji.
• Centralizuje zarządzanie certyfikatami — odnawiaj jeden certyfikat na module równoważenia, a nie na każdym węźle.
• Umożliwia inspekcję warstwy 7 zawartości żądań (niemożliwa przy szyfrowanym pass-through).

Kwestia bezpieczeństwa: Ruch między modułem równoważenia a backendami jest przesyłany niezaszyfrowany. Jest to akceptowalne, gdy wszystkie węzły znajdują się w izolowanej prywatnej sieci VLAN lub dedykowanej sieci zarządzania. Jeśli wymagania dotyczące zgodności (PCI-DSS, HIPAA) nakazują szyfrowanie end-to-end, użyj ponownego szyfrowania SSL: moduł równoważenia kończy sesję TLS po stronie klienta i nawiązuje nową sesję TLS z każdym backendem. Utrzymuje to pełne szyfrowanie, jednocześnie umożliwiając routing warstwy 7.

Połączenie terminacji SSL z prawidłowo wydanymi Certyfikatami SSL zapewnia, że infrastruktura z równoważeniem obciążenia spełnia zarówno wymagania wydajnościowe, jak i dotyczące zgodności.

Wysoka dostępność samego modułu równoważenia obciążenia

Moduł równoważenia obciążenia, który sam jest pojedynczym punktem awarii, niweczy cel całej architektury. Wdrożenia produkcyjne wymagają pary modułów równoważenia obciążenia o wysokiej dostępności.

Aktywno-pasywny z VRRP/Keepalived

Dwa węzły modułu równoważenia obciążenia współdzielą wirtualny IP (VIP). Aktywny węzeł utrzymuje VIP i przetwarza cały ruch. Pasywny węzeł monitoruje aktywny węzeł za pomocą heartbeat. Jeśli aktywny węzeł ulegnie awarii, keepalived wyzwala przełączenie awaryjne VRRP, a pasywny węzeł przejmuje VIP w ciągu 1–3 sekund.

# Install keepalived on both load balancer nodes (Debian/Ubuntu)
apt-get install keepalived

# /etc/keepalived/keepalived.conf on the MASTER node
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass securepassword
    }
    virtual_ipaddress {
        203.0.113.10/24
    }
}

Na węźle zapasowym ustaw state BACKUP i priority 90. Węzeł z wyższym priorytetem wygrywa wybory VIP.

Aktywno-aktywny z DNS Round Robin lub Anycast

Oba węzły modułu równoważenia obciążenia aktywnie przetwarzają ruch jednocześnie. DNS zwraca wiele rekordów A, dystrybuując klientów między oba moduły równoważenia. Podwaja to przepustowość, ale wymaga starannej synchronizacji stanu, jeśli używasz lepkich sesji.

W przypadku wdrożeń na dużą skalę na Serwerach Dedykowanych, konfiguracja aktywno-aktywna z routingiem BGP anycast zapewnia najwyższą przepustowość i geograficzną redundancję.

Łagodzenie skutków DDoS na warstwie modułu równoważenia obciążenia

Moduł równoważenia obciążenia umieszczony na brzegu sieci jest naturalnym miejscem do implementacji czyszczenia ruchu i ograniczania przepustowości przed dotarciem złośliwych żądań do serwerów aplikacji.

Ograniczanie szybkości połączeń (HAProxy)

frontend http_in
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/
    stick-table type ip size 100k expire 30s store conn_rate(3s),http_req_rate(10s)
    tcp-request connection track-sc0 src
    tcp-request connection reject if { sc_conn_rate(0) gt 100 }
    http-request deny if { sc_http_req_rate(0) gt 300 }

Ta konfiguracja śledzi szybkość połączeń na źródłowy IP w tabeli stick i odrzuca klientów przekraczających 100 nowych połączeń TCP na 3 sekundy lub 300 żądań HTTP na 10 sekund — progi blokujące większość wolumetrycznych ataków HTTP flood, jednocześnie zezwalając na legalny ruch burstowy.

Ochrona przed SYN Flood

Włącz SYN cookies na poziomie jądra na węzłach modułu równoważenia obciążenia, aby obsługiwać ataki SYN flood bez wyczerpywania tabeli połączeń:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.ipv4.tcp_synack_retries=2

Utrwal te ustawienia, dodając je do /etc/sysctl.conf.

NGINX jako moduł równoważenia obciążenia warstwy 7: konfiguracja produkcyjna

NGINX jest szeroko stosowaną opcją do równoważenia obciążenia HTTP, szczególnie gdy potrzebna jest ścisła integracja z funkcjami na poziomie aplikacji.

upstream backend_pool {
    least_conn;
    keepalive 32;

    server 192.168.1.10:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 weight=1 max_fails=3 fail_timeout=30s;
    server 192.168.1.13:8080 backup;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
        proxy_pass         http://backend_pool;
        proxy_http_version 1.1;
        proxy_set_header   Connection "";
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_connect_timeout 5s;
        proxy_read_timeout    60s;
        proxy_next_upstream   error timeout http_502 http_503;
    }
}

Kluczowe szczegóły tej konfiguracji:

• keepalive 32 utrzymuje trwałe połączenia z backendami, eliminując narzut uzgadniania TCP dla żądań o wysokiej częstotliwości.
• proxy_next_upstream automatycznie ponawia nieudane żądania na następnym zdrowym backendzie.
• Dyrektywa backup wyznacza node4 jako serwer zapasowy, który otrzymuje ruch tylko wtedy, gdy wszystkie węzły podstawowe są niedostępne.
• X-Forwarded-For zapewnia, że aplikacje backendowe widzą rzeczywisty IP klienta, a nie IP modułu równoważenia.

Porównanie opcji oprogramowania do równoważenia obciążenia

W przypadku samodzielnie zarządzanych Serwerów Dedykowanych, HAProxy i NGINX obejmują zdecydowaną większość przypadków użycia produkcyjnego. Traefik jest pragmatycznym wyborem dla obciążeń Docker Swarm lub Kubernetes ze względu na automatyczne wykrywanie usług.

Architektura rzeczywista: platforma e-commerce pod szczytowym obciążeniem

Rozważmy konkretny scenariusz: platforma e-commerce oczekująca 50 000 jednoczesnych użytkowników podczas wydarzenia promocyjnego.

Układ infrastruktury:

• 2x węzły HAProxy w konfiguracji aktywno-pasywnej współdzielące VIP (przez Keepalived)
• 6x serwery aplikacji obsługujące warstwę webową
• 2x dedykowane serwery baz danych (nie w puli modułu równoważenia — używają własnej replikacji)
• 1x klaster Redis do współdzielonego przechowywania sesji (eliminujący zależność od lepkich sesji)
• Współdzielony NFS lub obiektowy magazyn dla zasobów przesłanych przez użytkowników

Przepływ ruchu:

1. DNS klienta rozwiązuje się do VIP utrzymywanego przez aktywny węzeł HAProxy.
2. HAProxy stosuje algorytm leastconn, dystrybuując żądania między 6 serwerami aplikacji.
3. Każdy serwer aplikacji odczytuje/zapisuje dane sesji z Redis — nie jest wymagana koligacja sesji.
4. Zasoby statyczne są serwowane bezpośrednio z obiektowego magazynu przez CDN, całkowicie omijając moduł równoważenia obciążenia i zmniejszając jego obciążenie o 60–70%.
5. Jeśli sprawdzenie kondycji jednego serwera aplikacji nie powiedzie się trzy razy z rzędu, HAProxy usuwa go z puli w ciągu 15 sekund. Pozostałe 5 serwerów przejmuje jego ruch.
6. Jeśli aktywny węzeł HAProxy ulegnie awarii, Keepalived przenosi VIP do pasywnego węzła w ciągu 2 sekund — transparentnie dla wszystkich klientów.

Ta architektura obsługuje skok promocyjny bez żadnego pojedynczego komponentu stającego się wąskim gardłem i skaluje się poziomo poprzez dodawanie kolejnych serwerów aplikacji do puli HAProxy bez przestojów.

Jeśli obsługujesz obciążenia wnioskowania akcelerowane GPU za modułem równoważenia obciążenia — na przykład dystrybuując żądania obsługi modeli ML — te same zasady mają zastosowanie, ale sprawdzenia kondycji backendu powinny weryfikować dostępność GPU i zasoby VRAM, a nie tylko osiągalność HTTP. Infrastruktura Hostingu GPU znacznie korzysta z równoważenia opartego na najkrótszym czasie odpowiedzi ze względu na wysoką wariancję opóźnienia wnioskowania dla różnych typów żądań.

Monitorowanie infrastruktury z równoważeniem obciążenia

Wdrożenie modułu równoważenia obciążenia bez obserwowalności to działanie w ciemno. Oto metryki, które mają znaczenie:

• Aktywne połączenia na backend: Ujawnia nierównowagę w algorytmie dystrybucji lub koncentrację lepkich sesji.
• Szybkość żądań (RPS) na backend: Powinna być proporcjonalna do wag serwerów.
• Czas odpowiedzi backendu (p50, p95, p99): Skoki opóźnienia p99 na jednym węźle wskazują problem przed wyzwoleniem sprawdzeń kondycji.
• Wskaźnik niepowodzeń sprawdzeń kondycji: Backend oscylujący między zdrowym a niezdrowym (migotanie) wskazuje na podstawową niestabilność wymagającą zbadania.
• Głębokość kolejki połączeń: Jeśli kolejka modułu równoważenia rośnie, pula backendów jest za mała dla bieżącego ruchu.
• Szybkość uzgadniania SSL: Wysokie wskaźniki wskazują na potencjalny atak wyczerpania TLS lub błędnie skonfigurowanego klienta agresywnie ponawiającego próby.

HAProxy udostępnia stronę statystyk (włącz za pomocą stats enable we frontendzie) i gniazdo Unix do zapytań programowych. Przekazuj te metryki do Prometheus przez haproxy_exporter i wizualizuj w Grafana dla kompletnego stosu obserwowalności.

Praktyczna lista kontrolna decyzji

Użyj tej macierzy przed wdrożeniem lub modyfikacją architektury z równoważeniem obciążenia:

• Aplikacja stanowa? Przenieś przechowywanie sesji do Redis lub Memcached przed włączeniem równoważenia obciążenia. Nie polegaj na lepkich sesjach jako trwałym rozwiązaniu.
• TLS wymagany? Zakończ SSL na module równoważenia obciążenia. Upewnij się, że sieć backendowa jest izolowana. Uzyskuj certyfikaty i zarządzaj nimi centralnie przez Certyfikaty SSL.
• Zmienny czas trwania żądań? Użyj leastconn, a nie round robin.
• Niejednorodny sprzęt? Zastosuj wartości weight proporcjonalne do pojemności serwera.
• HA modułu równoważenia obciążenia? Wdróż dwa węzły modułu równoważenia z Keepalived/VRRP. Nigdy nie uruchamiaj pojedynczego modułu równoważenia obciążenia w środowisku produkcyjnym.
• Narażenie na DDoS? Zaimplementuj ograniczanie szybkości połączeń i ochronę SYN cookie na poziomie jądra i modułu równoważenia.
• Głębokość sprawdzenia kondycji? Używaj sprawdzeń HTTP względem dedykowanego punktu końcowego /health, który weryfikuje łączność z bazą danych, a nie tylko dostępność portu TCP.
• Plan skalowania? Dodanie nowego węzła backendu do puli HAProxy lub NGINX wymaga przeładowania konfiguracji (haproxy -sf $(cat /var/run/haproxy.pid) dla przeładowania bez przestojów) — zaplanuj odpowiednio proces zarządzania zmianami.
• Monitorowanie? Instrumentuj HAProxy lub NGINX eksporterami Prometheus przed uruchomieniem produkcyjnym, a nie po incydencie.
• Preferencja panelu sterowania? Jeśli preferujesz zarządzanie serwerem przez GUI obok ręcznej konfiguracji modułu równoważenia obciążenia, oceń Panele Sterowania VPS do zadań administracyjnych na poszczególnych węzłach.

FAQ

Jaka jest różnica między modułem równoważenia obciążenia a odwrotnym proxy?

Odwrotne proxy przekazuje żądania klientów do jednego lub więcej serwerów backendowych i zwraca odpowiedź do klienta — obsługuje routing, buforowanie i terminację SSL. Moduł równoważenia obciążenia to specyficzny typ odwrotnego proxy, którego główną funkcją jest dystrybucja żądań między wiele backendów przy użyciu zdefiniowanego algorytmu. Wszystkie moduły równoważenia obciążenia są odwrotnymi proxy, ale nie wszystkie odwrotne proxy wykonują równoważenie obciążenia.

Czy równoważenie obciążenia może działać z pojedynczym serwerem dedykowanym?

Technicznie tak — możesz uruchomić moduł równoważenia obciążenia przed pojedynczym serwerem w celu terminacji SSL, buforowania i ograniczania przepustowości. Jednak korzyści z odporności na awarie i skalowania poziomego materializują się dopiero przy dwóch lub więcej węzłach backendowych. Konfiguracja z jednym serwerem za modułem równoważenia obciążenia jest prawidłową architekturą przejściową, która sprawia, że przyszłe skalowanie jest operacyjnie trywialne.

Jak moduł równoważenia obciążenia obsługuje połączenia WebSocket?

WebSocket wymaga trwałych, długotrwałych połączeń TCP. Moduły równoważenia obciążenia warstwy 7 muszą być jawnie skonfigurowane do obsługi uzgadniania HTTP Upgrade, a następnie utrzymywania koligacji połączenia przez czas trwania sesji WebSocket. W NGINX ustaw proxy_http_version 1.1 i proxy_set_header Upgrade $http_upgrade z proxy_set_header Connection "upgrade". W HAProxy użyj option http-server-close i skonfiguruj odpowiednie wartości timeout (timeout tunnel 1h dla długotrwałych połączeń).

Co dzieje się z żądaniami w trakcie realizacji, gdy serwer backendowy ulegnie awarii?

Dzięki proxy_next_upstream w NGINX lub retries w HAProxy, moduł równoważenia wykrywa błąd połączenia lub timeout przy pierwszej próbie i natychmiast ponawia żądanie na następnym zdrowym backendzie. To ponowienie jest transparentne dla klienta. Idempotentne żądania (GET, HEAD) są bezpieczne do automatycznego ponawiania. Nieindempotentne żądania (POST, PUT) powinny być ponawiane ostrożnie — skonfiguruj proxy_next_upstream, aby wykluczyć http_500 dla tras POST, aby uniknąć podwójnego przetwarzania płatności lub przesłania formularza.

Ile serwerów backendowych jest potrzebnych, zanim równoważenie obciążenia przyniesie wymierną korzyść?

Dwa serwery zapewniają natychmiastową możliwość przełączania awaryjnego i w przybliżeniu podwajają pojemność. Trzy lub więcej serwerów zapewnia znaczącą dystrybucję statystyczną i umożliwia konserwację kroczącą (wyłączenie jednego węzła do aktualizacji, podczas gdy pozostałe przejmują ruch). W przypadku obciążeń produkcyjnych trzy węzły to praktyczne minimum dla odpornej puli — dwa węzły oznaczają, że pojedyncza awaria zmniejsza pojemność o 50%, co może naruszać SLA wydajności przy szczytowym obciążeniu.