Vai al contenuto

Nginx come load balancer HTTP: esempio e limiti operativi

Nginx può distribuire richieste HTTP tra più backend tramite un gruppo upstream. È utile per ripartire il traffico, ma la continuità del servizio dipende anche da stato applicativo, database e disponibilità dello stesso bilanciatore.

Un esempio da provare in laboratorio

Questo frammento va dentro il contesto http della configurazione. Presuppone due servizi HTTP locali sulle porte 9001 e 9002; non configura TLS né rappresenta un server pubblico completo.

upstream app_backend {
    server 127.0.0.1:9001;
    server 127.0.0.1:9002;
}

server {
    listen 127.0.0.1:8080;
    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
    }
}

La guida ufficiale al bilanciamento HTTP descrive round robin e altre strategie. In questo esempio non viene selezionato un algoritmo alternativo, quindi si usa il comportamento predefinito.

Provare la distribuzione e il guasto

Fai restituire ai due backend un identificatore diverso e verifica quale risponde alle richieste di prova. Poi arrestane uno e osserva errori, tempi e recupero, senza dedurre il comportamento soltanto dalla configurazione.

I controlli passivi rilevano problemi attraverso il traffico. Non equivalgono a sonde attive periodiche di salute applicativa: funzionalità e disponibilità dipendono dall’edizione e dai moduli adottati.

Rendere i backend intercambiabili

Se sessioni o upload esistono soltanto sul primo server, il secondo può rispondere con dati mancanti. Serve una scelta coerente su stato condiviso o accesso ai dati. L’affinità delle sessioni può attenuare alcuni problemi, ma non sostituisce il recupero quando un nodo scompare.

Versioni del codice e configurazioni devono essere compatibili durante il rilascio. Un bilanciatore non corregge una migrazione del database incompatibile con metà dei backend.

Decidere quando ripetere una richiesta

La direttiva proxy_next_upstream governa i nuovi tentativi. Estenderli a operazioni non idempotenti richiede attenzione: un ordine può essere stato creato anche se la risposta non è arrivata.

Prima del reload verifica la sintassi con nginx -t. Dopo, controlla il percorso completo. Avere due backend è una parte della disponibilità; il punto di ingresso e le dipendenze comuni richiedono una valutazione separata.