Spostamento sito sul cloud

Come anticipato in questo articolo, ho spostato il blog su una piattaforma cloud IaaS realizzata con OpenNebula e datastore su filesystem MooseFS, realizzata in collaborazione con Genesi Srl.

Le VM che ospitano il blog, non sono delle semplici istanze LAMP, ma seguono il metodo per realizzare un hosting scalabile ottimizzato per Wordpress illustrato negli articoli che stiamo pubblicando in questi giorni.

Purtroppo, trattandosi di una variazione di indirizzo IP sul DNS, sono necessarie 24/36 ore perchè la modifica si propaghi, periodo nel quale potrebbero verificarsi momentanei disservizi per i quali ci scusiamo anticipatamente.

Se anche tu hai un blog wordpress e vuoi ospitarlo su questa piattaforma, contattami!

Hosting scalabile per WordPress – vm01

Come annunciato nel precedente articolo, vm1 sarà la VM di frontend, l’unica dotata di indirizzo IP pubblico che gestirà le richieste provenienti dal web.

Creiamo questa VM partendo da una installazione “vanilla” di Debian Squeeze (6.0.1), dotando la VM di 256 MB di RAM, 1 VCPU (CPU virtuale), 0.25 CPU (assegnamo il 25% della potenza di una CPU fisica), 2 schede di rete (una con IP pubblico e una con IP privato), 512 MB Disco Swap e 1024 MB Datablock per li contenuti statici e i file PHP.

Configurazione di base
La prima cosa che andremo a fare è modificare alcune delle configurazoni di default, in particolare il file hosts che ci consentirà di raggiungere tramite mnemonico le VM del nostro sistema:

<strong>/etc/hosts</strong>
10.10.1.1   lb
10.10.1.2   php-appserver1
10.10.1.3   mysql-server1

Inoltre modifichiamo l’hostname:

<strong>/etc/hostname</strong>
lb

Installazione di nginx
Come già detto in questo articolo, nginx è un server web molto veloce che ben si adatta per fare da frontend per rispondere alle richieste provenienti dal web; rispetto all’installazione del precedente articolo in cui gestivamo le richieste di contenuti statici in locale e reindirizzavamo le richieste di file php al server Apache, aggiungeremo una sezione per predisporre il server in modo da gestire il reindirizzamento delle richieste PHP a più appserver.
E’ possibile installare nginx su Debian attraverso un pacchetto non ufficiale; pertanto è necessario modificare il file con i repository di debian aggiungendo la seguente riga:

<strong>/etc/apt/sources.list</strong>
deb http://packages.dotdeb.org stable all

a questo punto dobbiamo aggiungere la chiave GnuPG così:

wget http://www.dotdeb.org/dotdeb.gpg
cat dotdeb.gpg | sudo apt-key add -
rm dotdeb.gpg

Ora siamo pronti ad installare nginx attraverso il seguente comando:

apt-get update
apt-get install nginx

La web directory di nginx è usr/share/nginx/www/, per cui creiamo un link simbolico in modo che in futuro sia più facile accedervi:

ln -s /usr/share/nginx/www/ /var/www

Ora modifichiamo il file /etc/fstab in modo da montare automaticamente il Datablock aggiungendo la seguente riga:

<strong>/etc/fstab</strong>
/dev/sdc        /usr/share/nginx/www           ext3    defaults 0       0

e montiamo il disco con:

mount -a

Ora è giunto il momento di configurare nginx.

<strong>/etc/nginx/nginx.conf</strong>
user www-data;
worker_processes  2;
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
}
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    access_log /var/log/nginx/access.log;
    server_names_hash_bucket_size 64;
    sendfile        on;
    tcp_nopush     on;
    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;
    gzip              on;
    gzip_comp_level   5;
    gzip_http_version 1.0;
    gzip_min_length   0;
    gzip_vary         on;

    upstream appservers {
        fair weight_mode=idle no_rr;
        server php-appserver1 weight=10;
    }

    server {
        listen       80;
        server_name  _;
        access_log /var/log/nginx/default.access.log;

        location / {
            proxy_pass http://appservers;
            include /etc/nginx/conf.d/proxy.conf;
       }
       location ~* ^.+.(jpe?g|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|avi|mp3)$ {
            expires 30d;
            root /usr/share/nginx/www;
        }
    }
}
include /etc/nginx/sites-enabled/*;

La configurazione di nginx è simile a quella del precedente articolo, se si esclude l’aggiunta della sezione “upstream” che assolve il compito di load balancer (anche se in questo momento abbiamo un solo server). Esiste un modulo standard per il load balancer, però preferisco usare il modulo alternativo “fair” che meglio si adatta all’idea del cloud: questo modulo, al contrario dello standard, tiene conto di quante richieste contemporanee sta gestendo ciascun appserver. Il parametro weight_mode=idle no_rr obbliga il load balancer a disabilitare la funzionalità round-robin e girare le richeste al primo appserver finchè non raggiunge il valore di picco settato attraverso il parametro weight: ciò vuol dire che se utilizzassimo un sistema di cloud in cui si paga solo il tempo in cui la macchina lavora, non avremo consumi derivanti dall’utilizzo di server poco sfruttati ma si riesce a massimizzare l’utilizzo di ciascun appserver.
Ovviamente, continuando nell’analisi, ogni linea “server” identifica un application server e, come già detto, il parametro weight identifica il numero massimo di connessioni gestibili dal server.

Ora aggiungiamo il file di configurazione del proxy, identico a quello del precedente articolo:

<strong>/etc/nginx/conf.d/proxy.conf</strong>
proxy_redirect          off;
proxy_set_header        Host            $host;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size    10m;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffer_size   16k;
proxy_buffers       32   16k;
proxy_busy_buffers_size 64k;

Rimuoviamo il file /etc/nginx/sites-enabled/default in quanto è già presente nel file nginx.conf la configurazione del default virtualhost:

rm /etc/nginx/sites-enabled/default

Installazione di NFS ed export della directrory www
Ora installiamo NFS per esportare la directory /usr/share/nginx/www verso gli appserver:

apt-get install nfs-kernel-server nfs-common portmap

ed editiamo il file /etc/exports aggiungendo la seguente riga:

<strong>/etc/exports</strong>
/usr/share/nginx/www    10.10.1.2(rw,sync,no_root_squash,no_subtree_check)

Quindi configuriamo l’avvio di idmapd per sincronizzare l’id utente tra server e client:

<strong>/etc/default/nfs-common</strong>
NEED_IDMAPD=yes
NEED_GSSD=no






<strong>/etc/default/nfs-kernel-server</strong>
NEED_SVCGSSD=no

Ora riavviamo il demone con:

/etc/init.d/nfs-common restart
/etc/init.d/nfs-kernel-server restart

esportiamo il filesystem con:

exportfs -a

Configurazione di IP Forwarding
Il nostro Load Balancer si occuperà come ultima cosa di fungere da gateway per i server interni.
Per far ciò aggiungiamo le seguenti righe nel file /etc/rc.local:

<strong>/etc/rc.local</strong>
iptables --flush                         # Flush all the rules in filter and nat tables
iptables --table nat --flush
iptables --delete-chain                  # Delete all chains that are not in default filter and nat table
iptables --table nat --delete-chain

# Set up IP FORWARDing and Masquerading
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface eth1 -j ACCEPT         # Assuming one NIC to local LAN

echo 1 > /proc/sys/net/ipv4/ip_forward    # Enables packet forwarding by kernel

Hosting scalabile per WordPress – presentazione

In questa serie di articoli vi spiegherò come creare un servizio PaaS scalabile ottimizzato per ospitare un blog in Wordpress.

Il principio è ovviamente valido per qualsiasi sito PHP/MySQL, solo che Wordpress è notoriamente un sistema pesante che quindi trarrà immediato beneficio da una simile configurazione.

Struttura del sistema
Per realizzare il sistema creeremo 3 VM su un cloud realizzato con OpenNebula con datastore su MooseFS. In totale utilizzeremo 4 CPU di cui 1 dedicata, 1,75 GB Ram e due dischi Datablock (uno per le pagine PHP e uno per il database).

  • vm1 avrà il compito di ospitare fisicamente i file che compongono il sito in una partizione locale che sarà condivisa tramite NFS, di servire direttamente i file statici con nginx e di girare le richieste PHP agli application server sempre grazie ad nginx; inoltre fungerà da gateway per le altre VM;

  • vm2 è l’application server che potrà essere duplicato nel caso in cui si richieda maggiore potenza di calcolo (maggiori connessioni contemporanee): per servire gli script PHP utilizzeremo nginx come frontend, che comunicherà con php-fpm che è un innovativo sistema di esecuzione di PHP, simile concettualmente al FastCGI ma molto più veloce. Su questo server installeremo anche memcached per distribire la cache e mysql-proxy come frontend verso i server MySQL;

  • vm3 è il server mysql che potrà scalare in futuro aggiungendo slave server

Alla fine, proporremo anche come ottimizzare la velocità di Wordpress attraverso l’installazione di opportuni plugin in grado di sfruttare l’infrastruttura realizzata. Alla fine della serie di articoli, questo blog sarà spostato su questa infrastruttura in modo che possiate valutare l’effettivo aumento di prestazioni generato da un simile sistema.

Stay tunes…

La notte della rete

Cari amici, già più volte vi ho parlato della infame delibera Agcom 688/2010 che rischia di mettere fine alla libertà di espressione su Internet in Italia, un po’ come avviene in paesi “poco democratici” (è un eufemismo, ovviamente) come Cina, Iran, ecc.: Ne abbiamo parlato in questo articolo e, in parte, anche in questo.

Ora siamo alle battute finali e, il 6 luglio, è prevista l’approvazione finale della delibera Agcom che introdurrebbe un meccanismo automatico per l’inibizione di siti sospettati di violare il diritto d’autore.

Non sarà una vigilia tranquilla per l’Agcom: sarà, piuttosto, “La Notte della Rete”. Il 5 luglio, a 24 ore dall’approvazione della Delibera definita “ammazza-Internet” dai blogger italiani, artisti, esponenti della rete, leader politici, cittadini e utenti del web si troveranno a Roma per una no-stop contro il provvedimento.

Per maggiori informazioni sul provvedimento dell’Agcom vai alla pagina: www.agoradigitale.org/nocensura

L’evento si svolgerà martedì 5 luglio dalle 17.30 alle 21 presso la Domus Talenti a Roma ( via delle Quattro Fontane, 113 ) per cui se sei di Roma ti invito a partecipare alla nostra mobilitazione. Fai sentire la tua voce!

Fra i presenti già confermati:
Olivero Beha, Rita Bernardini, Emma Bonino, Pippo Civati, Nicola D’Angelo, Juan Carlos de Martin, Tana de Zulueta, Antonio Di Pietro, Dario Fo, Giovanbattista Frontera, Alessandro Gilioli, Peter Gomez, Beppe Giulietti, Fabio Granata, Margherita Hack, Carlo Infante, Giulia Innocenzi, Ignazio Marino, Gianfranco Mascia, Gennario Migliore, Roberto Natale, Luca Nicotra, Leoluca Orlando, Flavia Perina, Marco Perduca, Marco Pierani, il Piotta, Donatella Poretti, Enzo Raisi, Franca Rame, Fulvio Sarzana, Marco Scialdone, Guido Scorza, Mauro Vergari, Carlo Verna, Vincenzo Vita, Vittorio Zambardino.

Da parte nostra faremo il possibile per ritrasmettere in streaming l’evento direttamente da questo sito.