Clusterizzare un'applicazione Django con Nginx¶

Si suppone di avere un'applicazione django da distribuire su più istanze server, e di volere che il carico sia distribuito fra queste istanze e che anche in caso di malfunzionamento di una o più istanze, il servizio non sia negato, finché almeno un server resta funzionante.

Prerequisiti¶

• Applicazione Django nella directory /home/utente/projects/django/myproject/ (per semplicità la guida assume che l'applicazione sia servita da ./manage.py runserver $PORTA)
• Nginx

Avvio delle istanze Django¶

Avviare 4 istanze della stessa applicazione in 4 terminali differenti (un comando per terminale):

$ ./manage.py runserver 8000
$ ./manage.py runserver 8001
$ ./manage.py runserver 8002
$ ./manage.py runserver 8003

In questo modo si avranno 4 istanze della stessa applicazione, e accedendo con il browser agli indirizzi 127.0.0.1:8000, 127.0.0.1:8001, 127.0.0.1:8002, 127.0.0.1:8003, si vedrà che ognuna funziona indipendentemente.

Oppure, in alternativa, usare Supervisor, guida a questo link.

Configurazione base di nginx¶

Si crei il file di configurazione /etc/nginx/sites-available/cluster:

upstream backend {
    server 127.0.0.1:8000;
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
    server 127.0.0.1:8003;
}

server {
    listen 80;
    root /home/utente/projects/django/;
    server_name cluster;
    access_log /home/utente/projects/django/access.log;
    error_log /home/utente/projects/django/error.log;
    location / {
        proxy_pass http://backend;
    }
}

e si attivi con:

# ln -s /etc/nginx/sites-available/cluster /etc/nginx/sites-enabled/cluster
# /etc/init.d/nginx restart

In questo modo si dice a nginx di redirigere tutte le richieste che giungono a http://cluster/ verso il cluster chiamato backend, che è il gruppo di istanze di django.

Perché l'URL http://cluster funzioni però, bisogna aggiungere una riga al file /etc/hosts (o configurare il DNS in modo appropriato):

127.0.0.1 cluster

Test¶

A questo punto si può accedere a http://cluster/ e vedere come le richieste vengano divise fra i 4 server, e fermandone alcuni e/o riavviandoli, il sito funziona sempre, a patto che ovviamente almeno un'istanza sia attiva.

Con questa configurazione di base il carico viene distribuito uniformemente fra i componenti del cluster, ma il modulo upstream di nginx supporta diverse opzioni (documentazione), ad esempio weight:

upstream backend {
    server 127.0.0.1:8000;
    server 127.0.0.1:8001;
    server 127.0.0.1:8002 weight=3;
    server 127.0.0.1:8003;
}

in questo modo nginx redirigerà sul terzo server statisticamente il triplo delle richieste rispetto agli altri (può essere utile se uno dei server del cluster ha performance hardware maggiori, o se ha più banda a disposizione), oppure max_fails e fail_timeout:

upstream backend {
    server 127.0.0.1:8000;
    server 127.0.0.1:8001 max_fails=2 fail_timeout=20s;
    server 127.0.0.1:8002;
    server 127.0.0.1:8003;
}

se nginx vedrà negate più di 2 richieste in 20 secondi dal secondo server, lo considererà non disponibile per 20 secondi (i default sono max_fails=1 e fail_timeout=10s)

upstream backend {
    server 127.0.0.1:8000 backup;
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
    server 127.0.0.1:8003;
}

in questo modo il primo server è considerato di backup, e quindi verrà usato solo quando nessun altro server è disponibile.