Progetto

Generale

Profilo

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.