DjangoClusterNginx » Cronologia » Versione 2
Versione 1 (Mark Caglienzi, 13-12-2013 12:23) → Versione 2/6 (Mark Caglienzi, 13-12-2013 12:40)
h1. 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.
h2. 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
h2. Avvio delle istanze Django
Avviare 4 istanze della stessa applicazione in 4 terminali differenti (un comando per terminale):
<pre>
$ ./manage.py runserver 8000
$ ./manage.py runserver 8001
$ ./manage.py runserver 8002
$ ./manage.py runserver 8003
</pre>
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.
h2. Configurazione base di nginx
Si crei il file di configurazione @/etc/nginx/sites-available/cluster@:
<pre>
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;
}
}
</pre>
e si attivi con:
<pre>
# ln -s /etc/nginx/sites-available/cluster /etc/nginx/sites-enabled/cluster
# /etc/init.d/nginx restart
</pre>
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@:
<pre>
127.0.0.1 cluster
</pre>
h2. Test Conclusioni
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":http://nginx.org/en/docs/http/ngx_http_upstream_module.html), ad esempio @weight@:
<pre>
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;
}
</pre>
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@:
<pre>
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;
}
</pre>
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@)
<pre>
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;
}
</pre>
in questo modo il primo server è considerato di backup, e quindi verrà usato solo quando nessun altro server è disponibile.