Una sintetica rassegna dei metodi e del funzionamento dei dispositivi che regolano e ottimizzano le performance dei grandi siti partendo dal server load balancing
Un sito Web che non funziona o è troppo lento viene abbandonato dopo una manciata di secondi di attesa e difficilmente sarà visitato una seconda volta. È un refrain ormai conosciuto: i siti di successo non costringono a lunghe attese, non inviano misteriosi messaggi di errore e non si fanno trovare indisponibili quando servono.
Si spiega così il rapido sviluppo di tecnologie e servizi mirati a migliorare le performance del Web, sistemi oggi largamente adottati dai siti più “cliccati” al mondo.
In genere, gli interventi tecnici si concentrano sul server, o meglio su un gruppo di server (o server farm), che ospita un sito. Le tecniche più utilizzate sono tre: il server load balancing, il Web caching e i content delivery network (Cdn), che rappresentano un’evoluzione del Web caching. Queste soluzioni si possono applicare su reti Ip pubbliche o private (Internet oppure su reti di campus aziendali).
Server Load Balancing
È un metodo abbastanza diffuso nel mondo delle reti e consiste nel distribuire il traffico tra i diversi server della farm (detti anche real server) in modo trasparente ai client, i quali “vedono” un unico server virtuale. In sostanza, alla server farm sono associati un unico indirizzo Ip e un’unica porta Tcp. Il server load balancing associa ogni nuova connessione Tcp a un server specifico, tramite appositi algoritmi, e ridirige verso lo stesso server tutti i pacchetti Ip appartenenti alla stessa connessione. Gli stessi dispositivi sono impiegati per distribuire il carico fra i firewall, elementi che frenano le reti.
Esistono due tipologie di apparati: content-unaware, o switch di livello 4, e content-aware, o switch di livello 7. Ovviamente, più si va in alto con i livelli Osi, più aumentano la complessità, il costo e le prestazioni. In effetti, nel primo caso l’apparato non ha nessuna consapevolezza del contenuto informativo della comunicazione in corso. Ciò richiede che tutti i server della farm abbiano lo stesso contenuto, perché devono essere in grado di rispondere a qualunque tipo di richiesta.
Nel caso del content-aware, al contrario, il server load balancer diventa egli stesso il punto di terminazione della connessione Tcp verso i client. Deve dunque essere in grado di gestire la connessione per tutta la durata. Una volta stabilita la connessione, l’apparato decide e instrada verso il contenuto richiesto.
Le server farm vengono suddivise in base al contenuto del sito, e il load balancer indirizza le chiamate al server appropriato: questo introduce una complessità notevole.
I prodotti in commercio generalmente integrano anche switch di livello 2 e livello 3, necessari per collegarsi ai server e alle reti Ip. In generale, inoltre, vengono realizzate soluzioni ridondanti, con due o più apparati in parallelo. Oltre ai prodotti di marca, esistono anche soluzioni pc-based su freeware, con tutte le limitazioni tipiche di questa tipologia di software.
Web caching
Il Web caching rappresenta un approccio diverso allo stesso problema, quello di accelerare il Web.
In generale, le cache (indicate con il simbolo “$”, perché si pronunciano come cash) sono memorie locali che contengono copie degli oggetti con un accesso più frequente, per esempio le pagine Web più viste. Il Web caching si può fare in tre modi. Nel caso delle proxy cache, i client indirizzano esplicitamente le proprie richieste a questa memoria: il nome e l’indirizzo della memoria
devono essere configurati nel browser. Questo metodo non è molto usato proprio perché richiede la riconfigurazione del browser.
L’approccio “transparent caching”, invece, prevede che la rete ridiriga le richieste del client a una o più cache tramite un cache redirector. In pratica, ogni richiesta passa prima dalla cache, e se questa non ha l’informazione viene ridiretta all’indirizzo di destinazione.
Con il reverse proxing, la Web cache viene utilizzata per ridurre il carico sul server. La cache risiede vicino al sito del service provider, in modo tale che la richiesta arrivi direttamente alla cache del service provider, che ridirige la richiesta al server più opportuno, se non ha la pagina al suo interno.
Content delivery network
I content delivery network sono un’evoluzione della Web cache. Sono fondamentalmente reti virtuali appoggiate su Internet e composte da nodi che prendono vari nomi: cache, content server, delivery node o replica. Vengono realizzati distribuendo cache in giro per il mondo, con l’obiettivo di migliorare il servizio agli utenti, ottimizzando le prestazioni della consegna del contenuto, che può essere Http o streaming media. I content delivery network cercano di risolvere i problemi della lontananza delle server farm dagli utenti, dell’indisponibilità temporanea di una server farm (per esempio per mancanza di corrente), delle congestioni su Internet e dei picchi di traffico. Sono basate sui Dns (Domain name server), dispositivi che effettuano la conversione fra il nome di dominio e l’indirizzo Ip. Nei content delivery network il Dns viene modificato: anziché associare solo il nome all’indirizzo Ip, si associa sia il nome che l’indirizzo Ip di chi ha richiesto la risoluzione del nome. Questa coppia viene associata all’indirizzo Ip di destinazione. In questo modo, la richiesta viene indirizzata sulla replica del sito richiesto più vicina all’utente, sempre che il proprietario del sito abbia acquistato un servizio da un content delivery network.
Il Dns si trasforma, così, in un oggetto molto complesso: diventa di fatto un content router, ossia decide l’instradamento in funzione del contenuto. Per effettuare questa operazione il Dns deve utilizzare un certo numero di metriche, per misurare le distanze degli Ip sorgente dalle cache, oltre che del carico su ciascuna cache.
La complessità sta dunque nella definizione di queste metriche, che non possono essere misurate a livello locale, ma in funzione dello stato di tutti gli altri Dns e cache, che comunicano fra loro. Inoltre, la granularità con cui viene fatto il content browsing riguarda il nome, non la singola richiesta Http. Anche questo è estremamente più complicato, perché non può più essere fatto a livello di Dns, e richiede una serie di accorgimenti addizionali.
Legato al Content network troviamo l’esempio offerto dall’uso di una Overnet.
L’esempio Overnet
È sempre una rete privata in grado di velocizzare lo scambio di dati sul Web. Il sistema, sfruttato commercialmente in Europa dalla società inglese Madge.Web, funziona proprio tramite dei Content Distribution Services (Cds), che utilizzano solo in minima parte la rete pubblica, ottimizzando la trasmissione di contenuti multiformato e d’alta qualità.
I Cds portano i contenuti ai server secondari della rete privata di Madge.Web (composta di 21 punti di distribuzione in 15 Paesi) in questo modo le informazioni vengono distribuite direttamente al server più vicino al destinatario, nei termini e nei tempi più opportuni, con le garanzie di controllo da parte del mittente.
