Strategie di Bilanciamento del Carico di Nginx per l'Alta Disponibilità

Il bilanciamento del carico di Nginx viene solitamente introdotto dopo il primo limite doloroso: un server applicativo è troppo occupato, necessita di manutenzione o fallisce in modo da trascinare con sé l'intero sito. Mettere Nginx davanti a diversi backend ti dà spazio per distribuire le richieste, scaricare un server e sopravvivere a guasti ordinari.

Non è di per sé un'alta disponibilità magica. Nginx open source può smettere di inviare traffico a un backend dopo errori di connessione, ma non comprende a fondo se la tua pagina di checkout, la dipendenza API o la connessione al database siano in salute. Una buona configurazione combina la configurazione upstream di Nginx, timeout sensati, endpoint di health a livello applicativo, monitoraggio esterno e un processo di deployment in grado di rimuovere rapidamente un backend difettoso.

Comprendere il Bilanciamento del Carico

Al suo cuore, il bilanciamento del carico riguarda la direzione intelligente delle richieste dei client verso un pool di server. Invece di un singolo server che gestisce tutto il traffico, più server lavorano in concerto. Questo offre diversi vantaggi chiave:

• Alta Disponibilità: Se un server fallisce in modo rilevabile, altri possono continuare a gestire le richieste.
• Scalabilità: All'aumentare del traffico, puoi aggiungere più server al pool per gestire il carico.
• Prestazioni: Distribuire il traffico impedisce a un singolo server di diventare sovraccarico, portando a tempi di risposta più rapidi.
• Affidabilità: Rimuovendo i punti singoli di guasto, la tua applicazione diventa più robusta.

Nginx agisce come un proxy inverso in una configurazione di bilanciamento del carico. Riceve le richieste in arrivo dai client e le inoltra a uno dei server backend disponibili in base a un algoritmo configurato. Riceve anche la risposta dal server backend e la invia al client, rendendo il processo trasparente per l'utente finale.

Direttive di Bilanciamento del Carico di Nginx

Nginx utilizza direttive specifiche all'interno del suo file di configurazione (tipicamente nginx.conf o file inclusi da esso) per definire gruppi di server upstream e il loro comportamento di bilanciamento del carico.

Il Blocco upstream

Il blocco upstream viene utilizzato per definire un gruppo di server su cui Nginx bilancerà il traffico. Questo blocco è solitamente posizionato nel contesto http.

http {
    upstream my_backend_servers {
        # Le configurazioni del server vanno qui
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://my_backend_servers;
        }
    }
}

All'interno del blocco upstream, elenchi i server backend usando la direttiva server, specificando i loro indirizzi IP o nomi host e porte.

upstream my_backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    server 192.168.1.100:8080;
}

La Direttiva proxy_pass

La direttiva proxy_pass, utilizzata all'interno di un blocco location, punta al gruppo upstream che hai definito. Nginx utilizzerà quindi l'algoritmo di bilanciamento del carico configurato per selezionare un server da questo gruppo per ogni richiesta.

Algoritmi di Bilanciamento del Carico di Nginx

Nginx supporta diversi algoritmi di bilanciamento del carico, ognuno con il proprio approccio alla distribuzione del traffico. L'algoritmo predefinito è Round Robin.

1. Round Robin (Predefinito)

In Round Robin, Nginx distribuisce le richieste sequenzialmente a ciascun server nel gruppo upstream. Ogni server riceve una quota uguale del carico nel tempo. È semplice, efficace per server identici e il metodo più comunemente utilizzato.

Configurazione:

upstream my_backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

Pro:

• Semplice da implementare e comprendere.
• Distribuisce uniformemente il carico se i server hanno capacità simili.

Contro:

• Non tiene conto del carico del server o dei tempi di risposta. Un server lento potrebbe comunque ricevere richieste.

2. Round Robin Ponderato

Il Round Robin Ponderato ti permette di assegnare un peso a ciascun server. I server con un peso maggiore riceveranno una quota proporzionalmente maggiore del traffico. Questo è utile quando hai server con capacità diverse (ad esempio, hardware più potente).

Configurazione:

upstream my_backend_servers {
    server backend1.example.com weight=3;
    server backend2.example.com weight=1;
}

In questo esempio, backend1.example.com riceverà tre volte più richieste di backend2.example.com.

Pro:

• Permette il bilanciamento in base alla capacità del server.

Contro:

• Ancora non tiene conto del carico del server in tempo reale.

3. Least-Connected

L'algoritmo Least-Connected indirizza le richieste al server con il minor numero di connessioni attive. Questo metodo è più dinamico poiché considera il carico attuale su ciascun server.

Configurazione:

Per abilitare Least-Connected, aggiungi semplicemente il parametro least_conn al blocco upstream:

upstream my_backend_servers {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

Pro:

• Distribuisce il carico in modo più intelligente considerando il carico attuale del server.
• Buono per applicazioni con durate di connessione variabili.

Contro:

• Può essere leggermente più complesso da gestire se il numero di connessioni fluttua rapidamente.

4. IP Hash

Con IP Hash, Nginx determina quale server deve gestire una richiesta in base a un hash dell'indirizzo IP del client. Ciò garantisce che le richieste provenienti dallo stesso indirizzo IP del client vengano inviate costantemente allo stesso server backend. Questo è cruciale per le applicazioni che si basano sulla persistenza della sessione (sessioni sticky) senza utilizzare un archivio di sessione condiviso.

Configurazione:

Aggiungi il parametro ip_hash al blocco upstream:

upstream my_backend_servers {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

Pro:

• Fornisce la persistenza della sessione out-of-the-box.

Contro:

• Può portare a una distribuzione non uniforme del carico se molti client condividono un singolo indirizzo IP (ad esempio, dietro un gateway NAT).
• Se un server fallisce, tutti i client con hash su quel server saranno influenzati fino a quando il server non sarà di nuovo online o l'hash non verrà ricalcolato (anche se Nginx tenta di reindirizzare).

5. Hash Generico

Simile a IP Hash, l'Hash Generico ti permette di specificare una chiave per l'hashing. Questa chiave può essere una variabile come $request_id, $cookie_jsessionid o una combinazione di variabili. Questo offre maggiore flessibilità per la persistenza della sessione o il routing basato su attributi specifici della richiesta.

Configurazione:

upstream my_backend_servers {
    hash $remote_addr consistent;
    server backend1.example.com;
    server backend2.example.com;
}

Usare consistent con hash implementa l'hashing consistente, che minimizza la ridistribuzione delle chiavi quando l'insieme dei server cambia.

Pro:

• Altamente flessibile per logiche di routing personalizzate.
• Supporta l'hashing consistente per una maggiore stabilità durante i cambiamenti dei server.

Contro:

• Richiede un'attenta selezione della chiave di hashing.

Health Check e Stato del Server

Per un'alta disponibilità utile, Nginx deve evitare backend che stanno fallendo. La versione open source lo fa principalmente in modo passivo: nota i tentativi falliti mentre proxy il traffico reale. Questo aiuta con host morti, connessioni rifiutate e alcuni casi di timeout. Non è la stessa cosa di un health check attivo che chiama /healthz ogni pochi secondi prima che gli utenti colpiscano il servizio.

max_fails e fail_timeout

Questi parametri, aggiunti alla direttiva server all'interno di un blocco upstream, controllano come Nginx tratta i server falliti.

• max_fails: Il numero di tentativi non riusciti di comunicare con un server entro un periodo fail_timeout specificato. Dopo max_fails fallimenti, il server viene contrassegnato come non disponibile.
• fail_timeout: La durata per cui un server è considerato non disponibile. Dopo questo periodo, Nginx tenterà di verificarne nuovamente lo stato.

Configurazione:

upstream my_backend_servers {
    server backend1.example.com max_fails=3 fail_timeout=30s;
    server backend2.example.com max_fails=3 fail_timeout=30s;
}

In questo esempio, se backend1.example.com ha tre tentativi non riusciti durante la finestra di fallimento, Nginx lo evita temporaneamente. Dopo il timeout, Nginx potrebbe riprovare. I fallimenti si basano su tentativi di connessione/proxy, non su una risposta di health dell'applicazione personalizzata a meno che tu non stia utilizzando strumenti aggiuntivi o funzionalità di Nginx Plus.

Parametro backup

Il parametro backup designa un server come backup. Riceverà traffico solo se tutti gli altri server attivi nel gruppo upstream non sono disponibili.

Configurazione:

upstream my_backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    server backup.example.com backup;
}

Se backend1 e backend2 sono giù, backup.example.com prenderà il sopravvento.

Health Check di Nginx Plus

Nginx Plus, la versione commerciale, include health check attivi integrati. Può inviare periodicamente richieste ai backend, valutare le risposte e rimuovere i server non sani prima che il traffico utente venga instradato lì. Se stai usando Nginx open source, puoi comunque costruire un sistema solido, ma normalmente lo abbini a monitoraggio esterno, service discovery o automazione che modifica/rimuove i target upstream.

Esempi Pratici di Configurazione

Mettiamo in pratica questi concetti con scenari comuni.

Scenario 1: Bilanciamento del Carico Round Robin Semplice

Distribuisci il traffico su due server web identici.

Configurazione:

http {
    upstream web_servers {
        server 10.0.0.10;
        server 10.0.0.11;
    }

    server {
        listen 80;
        server_name yourdomain.com;

        location / {
            proxy_pass http://web_servers;
            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;
        }
    }
}

Spiegazione:

• upstream web_servers: Definisce un gruppo chiamato web_servers.
• server 10.0.0.10; e server 10.0.0.11;: Specifica i server backend.
• proxy_pass http://web_servers;: Indirizza il traffico al gruppo upstream web_servers.
• proxy_set_header: Queste direttive sono cruciali per passare le informazioni originali del client ai server backend, spesso necessarie per il logging o la logica applicativa.

Scenario 2: Bilanciamento del Carico con Persistenza della Sessione (IP Hash)

Assicura che gli utenti rimangano connessi allo stesso server backend, utile per applicazioni che memorizzano i dati di sessione localmente.

Usalo solo quando comprendi il compromesso. Se molti utenti arrivano attraverso lo stesso NAT dell'ufficio, gateway dell'operatore mobile o proxy aziendale, IP hash potrebbe inviare troppo traffico a un backend. L'archiviazione di sessione condivisa, cookie stateless firmati o la replica di sessione a livello applicativo sono spesso più puliti che affidarsi alla persistenza dell'IP del client.

Configurazione:

http {
    upstream app_servers {
        ip_hash;
        server 192.168.1.50:8000;
        server 192.168.1.51:8000;
    }

    server {
        listen 80;
        server_name api.yourdomain.com;

        location / {
            proxy_pass http://app_servers;
            # ... altre direttive proxy_set_header ...
        }
    }
}

Scenario 3: Bilanciamento del Carico Ponderato con Failover

Indirizza più traffico a un server più potente e tieni un backup pronto.

Configurazione:

http {
    upstream balanced_app {
        server app_server_1.local weight=5;
        server app_server_2.local weight=2;
        server app_server_3.local backup;
    }

    server {
        listen 80;
        server_name staging.yourdomain.com;

        location / {
            proxy_pass http://balanced_app;
            # ... altre direttive proxy_set_header ...
        }
    }
}

Qui, app_server_1.local riceve 5 parti del traffico, app_server_2.local riceve 2 parti e app_server_3.local serve solo richieste se gli altri due non sono disponibili.

Migliori Pratiche e Suggerimenti

• Usa proxy_set_header: Imposta sempre intestazioni come Host, X-Real-IP, X-Forwarded-For e X-Forwarded-Proto in modo che le tue applicazioni backend conoscano i dettagli del client originale.
• Mantieni Nginx Aggiornato: Assicurati di eseguire una versione stabile e aggiornata di Nginx per miglioramenti di sicurezza e prestazioni.
• Monitora i Server Backend: Implementa strumenti di monitoraggio esterni oltre ai controlli di integrità interni di Nginx. Nginx sa solo se può raggiungere un server, non necessariamente se l'applicazione sul server funziona correttamente.
• Considera Nginx Plus: Per applicazioni mission-critical, Nginx Plus offre funzionalità avanzate come health check attivi, persistenza della sessione e monitoraggio dell'attività in tempo reale, che possono semplificare la gestione e migliorare la resilienza.
• Bilanciamento del Carico DNS: Per la distribuzione del traffico tra regioni o più punti di ingresso Nginx, il DNS può aiutare, ma il failover DNS dipende dal comportamento del resolver e dai TTL. Non trattarlo come un failover istantaneo.
• Terminazione SSL: Puoi spesso terminare SSL al bilanciatore di carico (Nginx) per scaricare l'elaborazione SSL dai tuoi server backend.

Un Punto di Partenza Pratico

Per due o tre server applicativi identici, inizia con il semplice round robin, timeout proxy conservativi e logging upstream chiaro. Aggiungi max_fails e fail_timeout, poi testa cosa succede quando fermi un backend. Non aspettare un incidente reale per imparare come si comporta Nginx.

Se le richieste richiedono tempi molto diversi, prova least_conn. Se un server è più grande degli altri, usa i pesi. Se l'applicazione memorizza lo stato della sessione localmente, correggi il design della sessione se puoi; usa ip_hash solo quando hai bisogno di un ponte pratico.

La migliore strategia di bilanciamento del carico di Nginx è quella che corrisponde a come la tua applicazione fallisce. Una VM morta, un backend lento, un rilascio rotto e un'interruzione del database appaiono tutti diversi dal punto di vista del proxy. Configura l'algoritmo, poi prova il comportamento di fallimento con piccoli test prima di definire la configurazione altamente disponibile.