Load balancing con nginx: upstream, metodi e health check
Load balancing con nginx
Load balancer nginx: upstream, metodi, pesi, health check | We.Inc
Configura nginx come load balancer: il blocco upstream, round robin, least_conn, ip_hash e hash, pesi, max_fails e fail_timeout, server di backup, più un generatore di config.
Per bilanciare il carico con nginx, elenca i tuoi application server in un blocco upstream e punta proxy_pass al suo nome. Le richieste ruotano in round robin a meno che tu non aggiunga least_conn, ip_hash, hash o random. Ogni riga server può avere un weight, max_fails e fail_timeout per gli health check passivi, e i flag backup o down.
Metodi di load balancing di nginx
Direttiva
Come sceglie un server
Ideale per
(nessuna)
Round robin pesato, il default
Server simili e richieste brevi
Meno connessioni attive, tenendo conto dei pesi
Richieste di durata molto diversa
Hash dell'indirizzo del client (primi tre ottetti di IPv4, IPv6 intero)
Tenere un visitatore su un solo server
hash chiave
Hash di qualsiasi valore, come $request_uri
Affinità di cache; aggiungi consistent per limitare i rimescolamenti
Server casuale, o il migliore di due con random two
Più load balancer che condividono un unico pool
Distribuire il traffico su più copie di un'app è uno dei lavori più vecchi di nginx, e tutta la configurazione sta in una dozzina di righe. Il generatore qui sotto scrive il blocco upstream da un elenco di server, avvisa delle combinazioni che nginx rifiuta e mostra la quota di richieste di ogni server quando si applicano i pesi. Il riferimento che segue copre ogni parametro di server con il suo default.
Aggiungi nel generatore indirizzo e porta di ogni application server, con un peso se alcune macchine sono più grandi di altre.
Scegli un metodo. Lascia round robin a meno che le richieste varino molto in durata o i visitatori debbano restare su un solo server.
Copia il risultato nel contesto http, per esempio in un file in conf.d, ed esegui nginx -t.
Ricarica con nginx -s reload, poi ferma un application server e guarda le richieste spostarsi sugli altri.
Un singolo server in un upstream ignora max_fails e fail_timeout, quindi i controlli passivi contano solo con due o più server.
Con ip_hash, marca un server come down invece di cancellare la riga. Così l'hash dell'indirizzo di ogni altro client continua a puntare dove puntava prima.
I server backup ricevono traffico solo quando tutti i primari sono non disponibili, e non si possono combinare con hash, ip_hash o random.
Quali errori contano per max_fails lo decide proxy_next_upstream. Per default contano errori e timeout; un HTTP 500 no, a meno che tu non lo elenchi.
Aggiungi keepalive con proxy_http_version 1.1 e un header Connection vuoto per riutilizzare le connessioni verso i backend invece di aprirne una per richiesta.
Domande frequenti
nginx open source ha health check attivi?
No. La direttiva health_check appartiene alla versione commerciale NGINX Plus. nginx open source si basa su controlli passivi: se una richiesta a un server fallisce max_fails volte entro fail_timeout, il server viene saltato per fail_timeout e poi riprovato con traffico reale.
Quali sono i default di max_fails e fail_timeout?
max_fails vale 1 per default e fail_timeout 10 secondi. Un solo tentativo fallito quindi esclude un server per dieci secondi. Impostare max_fails=0 disattiva il conteggio per quel server.
Come rendo le sessioni sticky in nginx?
Usa ip_hash per tenere ogni indirizzo client su un solo server, oppure hash con una variabile cookie come $cookie_session per un controllo più fine. Le direttive sticky basate su cookie esistono solo nell'edizione commerciale.
Cosa fa il parametro weight?
Cambia quante richieste riceve un server rispetto agli altri. Con pesi 3, 1 e 1, in round robin il primo server riceve circa tre richieste su cinque. Il peso di default è 1.
nginx può bilanciare il carico delle connessioni WebSocket?
Sì. Punta proxy_pass all'upstream e inoltra gli header Upgrade e Connection. least_conn si adatta meglio del round robin ai socket di lunga durata, perché conta quante connessioni ha già ogni server.
Dove vanno i pezzi
Il blocco upstream sta nel contesto http, accanto ai tuoi blocchi server. Si limita a dare un nome a un pool; non succede nulla finché una location non dice proxy_pass http://name. Lo stesso pool può essere usato da molte location e molti blocchi server.
Health check passivi, passo per passo
Quando una richiesta a un server fallisce in un modo che proxy_next_upstream conteggia, nginx la riprova sul server successivo e registra l'errore. Quando un server raggiunge max_fails errori nella finestra di fail_timeout, nginx smette di sceglierlo. Trascorso fail_timeout, torna a mandargli con cautela richieste reali dei client, e un successo lo rimette in rotazione.
Poiché i controlli viaggiano sul traffico reale, un visitatore può incappare nel primo tentativo fallito. Timeout brevi su proxy_connect_timeout mantengono piccolo quel ritardo.
Parametri di server e relativi default
Parametri di una riga server dentro upstream
Parametro
Default
Effetto
weight=n
Quota relativa di richieste
max_fails=n
Tentativi falliti entro fail_timeout prima che il server venga saltato; 0 disattiva
fail_timeout=time
Finestra per contare gli errori e durata dell'esclusione del server
max_conns=n
0 (nessun limite)
Tetto di connessioni attive simultanee verso questo server
Usato solo quando tutti i server primari sono non disponibili
Marca il server come permanentemente non disponibile
Esempi completi
Round robin con un server di riserva
Due primari si dividono il carico; il terzo risponde solo se entrambi sono fuori uso.
least_conn con connessioni riutilizzate
keepalive mantiene in cache le connessioni inattive verso i backend; le due righe proxy lo fanno funzionare.
Affinità di cache per URL
Ogni URL continua ad arrivare sullo stesso server di cache; consistent mantiene intatta la maggior parte delle associazioni quando aggiungi o togli un server.
Nome dell'upstream
Metodo
Round robin (default)
Chiave di hash
Connessioni keepalive inattive (0 per nessuna)
Server
Indirizzo e porta
Peso
fail_timeout (s)
Quota
Rimuovi server {n}
Aggiungi server
nginx rifiuta i server backup con hash, ip_hash e random. Togli il flag backup o cambia metodo.
Tutti i server primari sono marcati down, quindi nessuno può ricevere traffico.