Când o aplicație crește și un singur server backend nu mai poate face față cererilor, soluția standard este distribuirea încărcării între mai multe instanțe (Load Balancing). Nginx excelează la acest capitol, funcționând ca un repartizator de trafic ultra-ușor capabil să gestioneze zeci de mii de conexiuni concurente.
Prin blocul declarativ upstream, definești o listă de servere backend. Nginx suportă mai mulți algoritmi de rutare: Round Robin (implicit, distribuție ciclică egală), least_conn (trimite cererea către serverul cu cele mai puține conexiuni active) și ip_hash (garantează că același vizitator ajunge permanent pe același server, util pentru sesiuni nesincronizate).
Nginx monitorizează sănătatea serverelor prin parametrii `max_fails` și `fail_timeout`: dacă un nod din cluster cade, Nginx îl scoate automat din rotație fără ca utilizatorii să resimtă vreo eroare.
Sintaxă, opțiuni și concepte cheie
| Opțiune / Concept | Descriere practică |
|---|---|
round-robin |
Algoritmul implicit ce distribuie cererile pe rând fiecărui server disponibil. |
least_conn |
Direcționează traficul către instanța cu cea mai mică încărcare în acel moment. |
ip_hash |
Calculează un hash din IP-ul clientului pentru a asigura persistența sesiunii (sticky sessions). |
weight= |
Atribuie o pondere mai mare serverelor mai puternice hardware (ex: `weight=3`). |
max_fails=3 fail_timeout=30s |
Scoate automat din rotație serverul care a eșuat 3 cereri consecutive. |
Exemple practice și cod
Exemplul 1: Configurarea unui cluster de 3 servere backend cu failover automat
Distribuire bazată pe încărcare minimă cu server de rezervă.
# Definim clusterul de aplicații:
upstream cluster_api {
least_conn;
server 10.0.0.11:8080 weight=2 max_fails=2 fail_timeout=10s;
server 10.0.0.12:8080 weight=1 max_fails=2 fail_timeout=10s;
# Server de rezervă activat exclusiv dacă celelalte două pică:
server 10.0.0.13:8080 backup;
}
server {
listen 80;
server_name api.dexblog.ro;
location / {
proxy_pass http://cluster_api;
proxy_next_upstream error timeout http_500 http_502 http_503;
}
}Rezultat & Impact
Disponibilitate de 99.99% a serviciului chiar și în cazul căderii a două noduri din cluster.Greșeli frecvente și bune practici
- Folosirea algoritmului `ip_hash` în spatele unui proxy Cloudflare fără configurarea antetului real de IP, ceea ce face ca tot traficul global să fie trimis către un singur nod.
- Omiterea directivei `proxy_next_upstream`, făcând ca primul utilizator care nimerește pe un nod căzut să primească eroare 502 în loc de redirecționare transparentă către un nod sănătos.