Come impostare il bilanciamento del carico di base in NGINX

Logo NGINX
NGINX

NGINX è comunemente usato come server Web, ma svolge anche un ottimo lavoro come proxy inverso e bilanciatore del carico, un dispositivo di rete progettato per gestire la maggior parte del traffico e instradare le richieste a più server Web diversi.

Come funziona il bilanciamento del carico NGINXNX

Il principio di base di un Load Balancer è che si trova tra l’utente e un insieme di server e le richieste di proxy per loro. Di solito questo viene fatto con due o più server, in modo che il traffico possa essere distribuito più facilmente tra di loro.

Un bilanciatore del carico NGINX.

La maggior parte della configurazione avviene nel modo in cui NGINX seleziona a quale server indirizzare. L’impostazione predefinita è round-robin, che invierà le richieste a ciascun server in ordine, garantendo un’equa distribuzione del carico.

Tuttavia, non è sempre così semplice. Molte applicazioni web richiedono una qualche forma di persistenza della sessione, il che significa che l’utente deve accedere allo stesso server per l’intera sessione. Ad esempio, un carrello degli acquisti potrebbe essere archiviato localmente su un server delle applicazioni e, se l’utente cambia server a metà sessione, l’applicazione potrebbe non funzionare correttamente. Naturalmente, molti di questi scenari possono essere risolti con una migliore infrastruttura applicativa e datastore centralizzati, ma molte persone richiedono la persistenza della sessione.

In NGINX, l’insieme di server a cui inoltri è noto come an a monte, ed è configurato come un elenco enumerato di indirizzi:

upstream backend {
    server backend1.example.com weight=5;
    server backend2.example.com;
}

Questi upstream hai molte opzioni; qui, abbiamo impostato un peso, che darà la priorità a questo server più spesso (particolarmente utile se hai dimensioni diverse). Puoi anche impostare il numero massimo di connessioni e vari timeout. Se stai usando NGINX Plus, puoi anche impostare controlli di integrità in modo che le connessioni non vengano instradate a server non integri.

La forma più elementare di persistenza della sessione è l’utilizzo di un hash IP. NGINX utilizzerà l’IP per identificare gli utenti e quindi si assicurerà che questi utenti non cambino server a metà sessione:

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

L’hash IP è necessario per le applicazioni basate su socket e tutto ciò che richiede persistenza. Se non desideri utilizzare l’indirizzo IP, puoi personalizzare questo hash:

upstream backend {
    hash $scheme$request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}

Se non hai bisogno di alcun tipo di persistenza della sessione, puoi rendere la selezione round-robin un po’ più intelligente selezionando quale server ha il minor numero di connessioni:

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

Oppure, in base a quale sta attualmente rispondendo più velocemente:

upstream backend {
    least_time (header | last_byte);
    server backend1.example.com;
    server backend2.example.com;
}

NGINX Plus ha alcune altre forme di persistenza della sessione, ma l’hashing IP funzionerà per la maggior parte delle applicazioni.

Proxy al backend

Una volta che hai configurato il tuo backend, puoi inviargli richieste dall’interno dei tuoi blocchi di posizione, usando proxy_pass con un URI al backend.

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://backend;
    }
}

Ovviamente, se utilizzi HTTPS, dovrai inviare la richiesta con HTTPS:

server {
    listen      443 ssl;
    server_name example.com;

    ssl_certificate        /etc/ssl/certs/server.crt;
    ssl_certificate_key    /etc/ssl/certs/server.key;
    ssl_client_certificate /etc/ssl/certs/ca.crt;

    location /{
       proxy_pass https://backend;
    }
}