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.