Varnish come Cache e Proxy


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Login/Register

Tanto tempo fa', almeno dal mio punto di vista, mi sono messo a scrivere un po' di cavolate sul sito. Poi, per chissa' quale motivo, la mia popolarita' e' aumentata ed improvvisamente mi sono ritrovato con un sacco (sempre dal mio punto di vista) di accessi. Finche' il sito era statico (html puro) non e' che ci fossero grandi problemi. Ma comincia a giocare con un CMS basato su un database e le cose cominciano a diventare pesantucce.

Aggiungi un paio di altri siti che usano del codice non proprio rapidissimo e dei database non proprio ottimizzatissimi e le cose possono diventare tragiche. Soprattutto se uno dei summenzionati siti si ritrova ad essere oggetto di un bel attacco spammatorio... Ed ecco che di botto mi ritrovo il server quasi inagibile con un Load Average 140...

Ok, qualche cosa s'ha da fare... E' il momento di installare Varnish! Ma prima, un po' di teoria...

Quando si parla di Proxy e' meglio specificare sempre se si intende dei Forward proxy o dei Reverse proxy. Che differenza c'e'? Per spiegarlo bisogna andare a vedere perche' sono stati inventati i proxy ed a che servono.

Ci sono molti casi in cui, da un punto di vista 'sicurezza' (e non solo) e' utile 'limitare' il tipo di cose che possono essere viste/fatte/cercate via internet. Non entro nel merito/utilita' del controllare figli e cose cosi' in ambito domestico perche' aprirei un casino di proporzioni galattiche, ma sicuramente sia in ambito aziendale che altro vi e' questa necessita'.

Per fare questo tipo di controllo vi sono vari metodi, piu' o meno sofisticati. Uno dei livelli piu' sofisticati consiste nel (letteralmente) "ispezionare" le pagine che vengono richieste in real-time (cioe' quando vengono richieste) ed eventualmente bloccare quelle "vietate". Ma per fare cio', e' necessario riuscire ad intercettare le famose pagine... il che puo' essere complicato se la rete e' grossa e gli utenti sono tanti. E puo' rendere la rete lenta.

A questo scopo aiuta l'uso di un proxy. Che roba e'? E' semplicemente un server (o piu' di uno) che fa da intermediario per l'accesso alla rete (web). Il termine proxy significa piu' o meno "intermediario". I vari browser mandano le richieste al proxy, che le esamina, porta a compimento se tutto ok, fornisce le risposte ed eventualmente conserva le pagine piu' visitate in una cache interna per sveltire le cose.

E' ovvio che se dei 1000 dipendenti di una azienda 800 si guardano "la repubblica" on line, il mettere in cache le pagine sveltira' di molto le operazioni.

Questo e' il tipo piu' classico di proxy: il Forward proxy, perche' riceve le richieste e le re-invia (forward) ai server di destinazione. Ne esiste pero' anche un altro che e' quello di cui andremo a parlare: il Reverse proxy!

Un reverse proxy si usa quando si vuole dare accesso dall'esterno ad uno o piu' servizi interni senza pero' esporre questi servizi direttamente. Sempre restando nell'ambito del web, i vari browser mandano le richieste ad un server (per via dell'indirizzo IP che corrisponde agli URL), il quale analizza gli URL richiesti e reinvia le richieste ad uno o piu' server secondari per essere elaborate e poi rimanda le risposte ai client. Dal punto di vista dei client non cambia nulla, ma dal punto di vista interno, non c'e' bisogno che i server che forniscono il servizio vero e proprio siano collegati direttamente ad internet. Inoltre il proxy puo' conservare una cache locale per (di nuovo) sveltire le operazioni.

Apache, il piu' usato WebServer nel mondo, ha diversi moduli che possono aggiungere diverse nuove funzioni, in particolare ha un modulo (ovviamente chiamato mod_proxy) che aggiunge funzionalita' di Reverse Proxy ed un altro che fornisce funzionalita' di Caching avanzate (o quantomeno configurabili).

Tuttavia, bisogna ricordarsi che Apache non e' un proxy ne' e' stato progettato per essere un proxy, come tale le sue funzionalita' sono piu' orientate al fornire pagine web come server web, e non all'operare come proxy. Pertanto, se non assolutamente necessario (come front-end a TomCat o altri application server per esempio) e' meglio evitare di usare Apache come proxy "solo perche' puo' farlo".

Varnish e' specificamente disegnato per essere un Forward proxy/Cache, ed implementa diversi meccanismi molto utili per questo tipo di operazioni. In particolare ha un esteso linguaggio di programmazione che consente di aggiungere rewrite e redirects direttamente nella fase di processo delle richieste, scaricandole dal lato "web server".

Inoltre, e' in grado di usare diversi "backend" per conservare le pagine in cache sveltendo notevolmente le operazioni.

Per prima cosa, procurarsi Varnish, se lo trovate gia' compilato per la vostra distribuzione, bene, altrimenti dovrete compilarvelo, non che sia una cosa tanto tragica. Una volta installato, e' necessario configurarlo. Per prima cosa copiare il file di configurazione di esempio fornito con i sorgenti "default.vcl" e dargli un nome sensato.

Il file di configurazione di default funziona, quindi prima di romperlo e' meglio farne una copia e tenerla bene.

Fatto questo e' necessario almeno configurare correttamente il backend:

backend default {
     .host = "127.0.0.1";
     .port = "8080";
}

In questo caso, il default e' connettersi allo stesso server su porta 8080. Perche' 8080? Semplice, se Varnish fa' da proxy significa che ascolta sulla porta "standard" 80 (http), il che significa che il 'vero' server httpd deve per forza usare una porta diversa (o essere limitato ad ascoltare su un indirizzo IP diverso), il sistema piu' semplice e' di spostare Apache su una porta diversa da 80 modificando la direttiva Listen nel file di configurazione di Apache.

La seconda cosa da fare e' creare un file contenente la "chiave di sicurezza" per la gestione (questo lo vedremo in seguito): create un file chiamato 'secret' (o quello che vi pare) contenente una stringa casuale (md5sum e' un ottimo generatore di stringhe semi-casuali).

A questo punto e' possibile avviare varnish:

varnishd -P /var/run/varnish.pid -a :80 -T localhost:6082 -f /etc/varnish.vcl  -u varnish -g varnish -S /etc/secret -s file,/var/lib/varnish/varnish_storage.bin,1G

Questo avvia Varnish impostando un file per il processId in /var/run/varnish.pid, in ascolto su porta 80, con l'interfaccia di gestione che ascolta su porta 6082 (porta di default), username e group "varnish" (dovrete creare uno user ed un gruppo), file di configurazione /etc/varnish.vcl (dovrete metterci il vostro file di configurazione ovviamente), file "segreto" /etc/secret e come cache abbiamo un file in /var/lib/varnish/varnish_storage.bin da 1 GigaByte.

Ovviamente digitare tutta questa roba ogni volta non e' proprio la cosa piu' semplice del mondo, percui e' consigliabile avere uno script allo scopo. Se avete installato Varnish con un package della vostra distribuzione ci sono ottime possibilita' che tale script sia gia' stato installato nel posto giusto.

In ogni caso, una volta che Varnish sta funzionando, e' possibile collegarsi al server e... tutto dovrebbe funzionare come prima.

Ho detto che 'tutto funziona come prima'? Si' l'ho detto... ma non e' del tutto vero. In effetti vi sono un paio di differenze. In particolare, il vostro server web verra' interrogato solo e solamente dal vostro proxy, se i due sono sulla stessa macchine voi vedrete solo accessi da 127.0.0.1. Il che significa che ACL basate su IP non funzioneranno piu' ed i vostri log diventeranno un po'... inutili. A meno che non cominciate ad ignorare l'indirizzo IP di origine e vi concentriate su quello forwardato (che Varnish invia attraverso X-FORWARDED-FOR). Modificare Apache per loggare quel parametro invece che REMOTE_HOST e' abbastanza banale, si tratta solo di cambiare la configurazione del logging. Ma cambiare come le ACL sono applicate... potrebbe diventare molto complicato... Quindi tenetene conto.

Un altra cosa di cui bisogna tenere conto e' l'utilizzo della cache. Se avete solo siti attivi (cioe' il contenuto e' ottenuto dinamicamente tramite un qualche tipo di programma), dovrete verificare che il vostro sistema fornisca un qualche modo per Varnish di capire se il contenuto e' ancora buono o no. Questo viene fatto di solito aggiungendo parametri (header) di scadenza del contenuto. Ricordiamo che usare la cache in modo efficiente e' il miglior modo per avere un sito "veloce".

Per verificare come e se la cache funziona viene fornito un bellissimo programmino chiamato varnishstat. Questo funziona in real time, visualizza quello che varnish sta facendo al momento. In particolare le informazioni piu' utili sono all'inizio:

client_conn             304466         0.43 Client connections accepted
client_drop                  0         0.00 Connection dropped, no sess/wrk
client_req              395482         0.56 Client requests received
cache_hit               207264         0.29 Cache hits
cache_hitpass             1159         0.00 Cache hits for pass
cache_miss              165507         0.24 Cache misses

All'inizio il parametro "cache_hit" dovrebbe essere molto basso ma aumentare con il tempo. Questo significa che la cache e' in uso. Idealmente 'hit' dovrebbe essere molto alto e 'miss' molto basso. Questo significa che un sacco di roba viene letta dalla cache e non richiesta all'applicazione sottostante.

Supponiamo che si debba (per qualunque motivo) aggiornare il file di configurazione. Per esempio perche' si e' aggiunta una Redirect o qualche cosa di simile. Un sistema semplice e' di aggiornare il file di configurazione e riavviare Varnish. Ma questo zapperebbe anche la cache. Un sistema piu' sofisticato e' di ricaricare il file di configurazione a runtime.

Come? Usando varnishadm. Varnishadm e' una interfaccia (command-line) che consente di fare diverse cose, in particolare consente di specificare un nuovo file di configurazione (che viene "compilato" e quindi verificato) e poi metterlo in uso, il tutto a run-time, senza dover riavviare niente.

Semplice esempio: supponiamo di aver modificato il file di configurazione e di volerlo verificare ed usare.

# varnishadm
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,2.6.37.6-smp,i686,-sfile,-smalloc,-hcritbit

Type 'help' for command list.
Type 'quit' to close CLI session.

vcl.load newconfig /where/is/your/config/file.vcl
vcl.use  newconfig

La prima riga 'carica' il file di configurazione compilandolo ed assegna al nuovo file un nome interno 'newconfig'. La seconda linea 'attiva' il file di configurazione.

Vedere la documentazione di Varnishadm per maggiori dettagli di cio' che questa CLI puo' fare.


I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

3 messaggi this document does not accept new posts
Anonymous coward Di Anonymous coward - postato il 13/02/2013 19:31

Puoi risolvere alla radice il problema degli IP visti da apache con mod_rpaf. Per Debian c'è un pacchetto, se no te lo devi installare a mano. Poi basta aggiungere:



     <ifmodule mod_rpaf.c="">


                RPAFenable On


                RPAFsethostname On


                RPAFproxy_ips 127.0.0.1


</ifmodule>        


(o se varnish l'hai su un altro IP, quello al posto del localhost) il pacchetto debian lo fa da sé in   /etc/apache2/mods-enabled/rpaf.conf.

Vedi: http://stderr.net/apache/rpaf

-- Anonymous coward


Anonymous coward Di Anonymous coward - postato il 29/05/2013 23:14

Andrebbe anche menzionato che Varnish per scelta degli sviluppatori non lavora per design con SSL (sarebbe troppo codice da implementare), quindi dimenticarsi reverse su ssl o passando da ssl.

Davide, hai mai visto delegate ? Quello è da pazzi :D

--
Anonymous coward


Davide Bianchi@ Anonymous coward Di Davide Bianchi - postato il 30/05/2013 09:36

Andrebbe anche menzionato che Varnish per scelta degli sviluppatori non lavora per design con SSL (sarebbe troppo codice da implementare), quindi dimenticarsi reverse su ssl o passando da ssl.

Per l'SSL si usa Pound (o simile) prima di Varnish, in modo da "decodificare" l'SSL a monte.

 

--
Davide Bianchi


Precedente

Davide Bianchi, lavora come Unix/Linux System Administrator presso una societa' di "sicurezza informatica" (aka: $networkgestapo) di Haarlem. Contatti: mail: davide AT onlyforfun.net , Jabber: davideyeahsure AT gmail.com,

Volete contribuire? Leggete come!.
 
 

Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gort