Il bilanciamento del carico distribuisce i visitatori di un sito su più app server. Davanti c'è un server load balancer: il tuo dominio punta a lui, risponde su HTTP e HTTPS, e Nginx inoltra ogni richiesta a uno degli app server che stanno dietro. Se un app server smette di rispondere, subentrano gli altri.
In Vimonto Deploy, un load balancer è un server a sé con sopra un sito con bilanciamento del carico. Nella pagina Bilanciamento del carico di quel sito scegli gli app server, come dividere il traffico tra loro e quali entrano in gioco solo quando gli altri non rispondono.
Come funziona il bilanciamento del carico?
| Parte | Cosa fa |
|---|---|
| Server load balancer | Un server di tipo Load balancer, con solo Nginx. Il DNS del tuo dominio punta a lui. |
| Sito con bilanciamento del carico | Il sito sul load balancer, creato dal preset Load balancer. Ha il dominio, il certificato e l'elenco degli app server, ma nessun codice. |
| App server | App server o web server della tua organizzazione, ognuno con un sito per lo stesso dominio. Eseguono il tuo codice e ricevono i deploy come al solito. |
Un visitatore si collega al load balancer. Lì Nginx sceglie un app server, gli inoltra la richiesta con gli header originali Host e X-Forwarded-*, e rimanda indietro la risposta. Gli app server vedono l'indirizzo IP del visitatore e sanno se ha usato HTTPS, perché i loro siti si fidano di questo load balancer (vedi di cosa hanno bisogno gli app server).
Configura un load balancer
- Crea un server di tipo Load balancer. Riceve solo Nginx; consulta i tipi di server.
- Assicurati che ogni app server abbia un sito per il tuo dominio, per esempio
shop.example.com, e che sia stato fatto il deploy. Usa lo stesso dominio oppure aggiungilo come alias in domini e SSL. - Nella pagina Siti del load balancer, clicca su Nuovo sito e scegli Load balancer sotto Bilanciamento del carico.
- Inserisci lo stesso dominio con Usa un dominio personalizzato e clicca su Crea sito. Un sito con bilanciamento del carico non ha repository, database né deploy.
- Apri la pagina Bilanciamento del carico del nuovo sito e aggiungi i tuoi app server (vedi sotto).
- Fai puntare il DNS del dominio all'indirizzo IP del load balancer e attiva HTTPS sul sito del load balancer in domini e SSL.
Finché non aggiungi un app server, il load balancer risponde a ogni richiesta con 503 Service Unavailable, e la panoramica del sito dice Ancora nessun server applicativo. I visitatori ricevono un 503 finché non ne aggiungi uno.
Un server load balancer ospita solo siti con bilanciamento del carico, e il preset Load balancer va solo su un server load balancer: il modulo elenca solo i server adatti.
Aggiungi un app server
- Nella pagina Bilanciamento del carico del sito, clicca su Aggiungi server.
- Scegli il Server. L'elenco contiene gli app server e i web server attivi della tua organizzazione a cui hai accesso.
- Imposta la Porta su cui è in ascolto il sito dell'app server:
80per impostazione predefinita. - Imposta il Peso, da 1 a 100: un server con peso 3 riceve il triplo delle richieste di uno con peso 1.
- Attiva Server di riserva se questo server deve ricevere traffico solo quando gli altri server non rispondono.
- Clicca su Aggiungi server.
Il load balancer raggiunge l'app server tramite la rete privata quando entrambi i server sono nella stessa, altrimenti tramite il suo indirizzo IP pubblico. L'elenco Server mostra ogni app server con l'indirizzo e la porta usati dal load balancer, il suo peso e un badge Riserva.
Puoi aggiungere un server più di una volta, su porte diverse.
Modifica un app server
Clicca su Modifica accanto al server, cambia la sua Porta, il Peso o l'impostazione Server di riserva e clicca su Salva. Il server in sé resta lo stesso; per usarne un altro, aggiungilo e togli questo. La modifica viene applicata subito.
Scegli il metodo di bilanciamento
In Metodo, clicca su una delle tre opzioni. La modifica viene applicata subito.
| Metodo | Come Nginx sceglie un app server |
|---|---|
| Round robin (predefinito) | Ogni server a turno, in base al peso. |
| Meno connessioni | Il server con meno connessioni aperte, per richieste che durano tempi molto diversi. |
| Hash IP | Ogni visitatore resta su un solo server, in base all'indirizzo IP. Usalo solo quando la tua app tiene qualcosa su un solo server. |
Nginx non accetta server di riserva insieme a Hash IP, quindi Vimonto Deploy non ti permette di combinarli. Con Hash IP scelto, Server di riserva non si può attivare e il modulo dice L'hash IP non funziona con i server di riserva. Scegli prima un altro metodo. Con un server di riserva nell'elenco, la scelta di Hash IP viene rifiutata con L'hash IP non funziona con i server di riserva: prima modifica i tuoi server di riserva in modo che non lo siano più.
Cosa succede quando un app server va giù?
Il load balancer controlla gli app server attraverso le richieste che invia; non ci sono controlli di stato separati. Quando una richiesta a un app server fallisce con un errore di connessione, un timeout o un 502, 503 o 504, Nginx prova il server successivo, così il visitatore riceve comunque una risposta. Dopo 3 errori in 10 secondi, il server non riceve traffico per 10 secondi, poi Nginx lo riprova.
I server di riserva ricevono traffico solo quando tutti gli altri server non sono disponibili.
Togli un app server
Clicca su Togli accanto al server e conferma. Il load balancer smette di inviargli traffico, e i siti su quel server smettono di fidarsi del load balancer (vedi sotto). Sul server non cambia nient'altro, e il suo sito continua a funzionare sul proprio indirizzo.
La stessa pulizia avviene da sola quando elimini il sito con bilanciamento del carico o il server load balancer: i siti sugli app server smettono di fidarsi di lui. Quando elimini un app server, il load balancer smette di inviargli traffico.
Di cosa hanno bisogno gli app server?
Ogni modifica nella pagina Bilanciamento del carico scrive anche la configurazione Nginx dei siti sugli app server che servono lo stesso dominio. Quei siti si fidano allora del load balancer, e solo di lui:
- L'indirizzo IP del visitatore. Nginx prende l'indirizzo da
X-Forwarded-For, ma solo quando la richiesta arriva dal load balancer (set_real_ip_from). La tua app vede l'indirizzo IP del visitatore come indirizzo remoto, senza impostazioni proxy proprie. - HTTPS. Quando il load balancer ha ricevuto la richiesta in HTTPS, PHP riceve
HTTPS=one un'app Node.js riceveX-Forwarded-Proto: https. Laravel e gli altri framework generano così linkhttps://senza configurare i trusted proxy.
Le richieste che arrivano da qualsiasi altra parte non possono falsificare questi header. Togliere un server, o eliminare il sito con bilanciamento del carico o il load balancer, rimuove di nuovo questa fiducia. Un sito con una configurazione Nginx personalizzata non viene toccato; aggiungi tu queste righe.
La tua app deve anche funzionare su più server contemporaneamente:
- Tieni sessioni e cache in Redis o nel database, su un server database o di cache condiviso, non in file su un solo server. Per Laravel significa impostare
SESSION_DRIVEReCACHE_STOREsuredisodatabasenel .env di ogni app server, puntando allo stesso Redis o database. - Tieni gli upload in un object storage come S3, non in
storage/di un solo server. - Fai il deploy del sito di ogni app server. Ogni app server ha la sua release e il suo deploy, quindi fai il deploy su tutti quando pubblichi una nuova versione.
- Esegui lo scheduler su un solo app server, a meno che i tuoi task pianificati possano girare più volte senza problemi.
HTTPS va sul load balancer, che comunica con gli app server in HTTP semplice. Un sito su un app server può comunque avere un proprio certificato, per esempio per raggiungerlo direttamente: reindirizza l'HTTP semplice su HTTPS per tutti tranne il load balancer, che serve in HTTP semplice, quindi non c'è alcun loop di reindirizzamento.
HTTPS sul load balancer
Il sito con bilanciamento del carico ha la sua pagina Domini e SSL. Dato che il tuo dominio punta al load balancer, il certificato Let's Encrypt gratuito si richiede lì, come per qualsiasi sito, e si rinnova automaticamente. Il load balancer risponde allora su HTTPS, reindirizza HTTP su HTTPS e inoltra le richieste agli app server in HTTP, con X-Forwarded-Proto: https.
Il traffico tra il load balancer e gli app server non è cifrato. Mettili nella stessa rete privata, così resta all'interno della rete del tuo provider.
Come appare la configurazione Nginx
La configurazione del sito con bilanciamento del carico ha un blocco upstream con gli app server e una location che gli inoltra le richieste:
upstream site_7_servers {
least_conn;
server 10.0.0.3:80 weight=3 max_fails=3 fail_timeout=10s;
server 10.0.0.4:80 max_fails=3 fail_timeout=10s backup;
keepalive 32;
}
server {
# listen, server_name, certificate and logs as for every site
location / {
proxy_pass http://site_7_servers;
proxy_http_version 1.1;
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;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade_keepalive;
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_read_timeout 120;
}
}
Le connessioni verso gli app server restano aperte e vengono riutilizzate, e le connessioni WebSocket vengono inoltrate. Ogni modifica viene scritta come task in background, testata con nginx -t e solo dopo caricata; se Nginx la rifiuta, resta attiva la configurazione precedente. Consulta Nginx.
Se hai salvato una configurazione tua nella pagina Nginx del sito con bilanciamento del carico, le modifiche nella pagina Bilanciamento del carico vengono salvate ma non applicate: vedi Salvato, non applicato. Ripristina la configurazione predefinita nella pagina Nginx per usarle.
Cos'altro ha un sito con bilanciamento del carico?
La barra laterale di un sito con bilanciamento del carico mostra Panoramica, Bilanciamento del carico, Domini e SSL, Log, Nginx e Impostazioni. Non ha le pagine Deployment e Ambiente, perché non ha codice. La sua pagina Impostazioni ha solo Elimina sito: non c'è directory web, impostazione dei deploy né isolamento da scegliere. L'intestazione del sito mostra a quanti app server inoltra il traffico.
- Log mostra i log Nginx degli errori e delle richieste del load balancer stesso. I log della tua app si trovano sui siti degli app server.
- Protezione con password, nel menu del framework nell'intestazione del sito, protegge in un colpo solo tutti gli app server dietro il load balancer. È l'unica funzionalità del sito di un sito con bilanciamento del carico.
Ogni membro può vedere la pagina Bilanciamento del carico. Per aggiungere, modificare e togliere server e cambiare il metodo serve il permesso di gestire i siti; consulta membri e ruoli. Ogni modifica viene registrata nel registro di audit.
Domande frequenti
Quanti app server posso mettere dietro un load balancer?
Quanti ne vuoi. Ognuno è una riga nel blocco upstream.
Mi servono le sticky session?
No, se le sessioni sono salvate in Redis o nel database, che ogni app server legge. In quel caso Round robin o Meno connessioni funzionano meglio. Usa Hash IP solo quando qualcosa vive davvero su un solo server.
Posso usare un solo load balancer per più domini?
Sì. Crea sul load balancer un sito con bilanciamento del carico per ogni dominio, ognuno con i suoi app server.
Perché sugli app server il mio dominio risulta puntare altrove?
Perché punta al load balancer, come deve. Solo il sito del load balancer ha bisogno del record DNS e del certificato.