Le soluzioni di clustering sotto

clustering: LVS, Linux Virtual Server Project

LVS: Linux Virtual Server Project Presentiamo la soluzione OpenSource più utilizzata per la scalabilità dei servizi di rete e la realizzazione di cluster per alta disponibilità e affidabilità.

L

e soluzioni di clustering sotto Linux hanno in questi ultimi tempi caratterizzato l’offerta commerciale delle grandi case costruttrici, che offrono sovente soluzioni in stack di sistemi in bundle con soluzioni precostituite di clustering di vario tipo. Il mercato del cluster business si è ormai caratterizzato in tre segmenti tecnologici principali, che possono essere così riassunti:

√ HPC cluster, ovvero il calcolo tecnico ad alte prestazioni, con l’obbiettivo di incrementare la scalabilità delle applicazioni parallele; √ Network Load Balancing cluster, mirato al supporto di ambienti di servizio con necessità di gestire grossi carichi di traffico di rete; √ Commercial HA cluster, ovvero soluzioni di alta disponibilità a supporto di applicazioni mission critical. L’offerta commerciale, tuttavia, non sempre è così semplificativa o, quantomeno, non chiarisce i limiti e l’applicabilità delle soluzioni proposte. Nella maggior parte dei casi, il termine cluster viene utilizzato nell’accezione di cluster per ridondanza di servizi (si veda l’articolo sui cluster del numero 14 di Linux&C.) con componenti di bilanciamento di carico e affidabilità, ovvero il Network Load Balancing cluster. Il cluster HA, ovvero l’alta disponibilità, è spesso offerto come soluzione aggiuntiva, tecnicamente legata, oltre alle classiche richieste di ridondanza, a scelte di particolari soluzioni architetturali per lo storage e

38 avanzato

ad un supporto application-oriented che necessariamente comporta un investimento diverso, commisurato appunto al tipo di soluzione tecnica richiesta per il raggiungimento degli obbiettivi dell’HA. Analogamente, il cluster per applicazioni tecnico-scientifiche, laddove sia richiesto un ambiente di produzione per codici paralleli, è spesso considerato come soluzione integrabile ma che comporta una specializzazione hardware e software abbastanza estranea all’offerta di base. Quindi, le grandi case (sia produttrici di hardware ma anche di software) hanno realizzato che il business per Linux è identificabile con il clustering di servizi. E noi, nel nostro piccolo, non possiamo che dargli ragione! Ora, analizzando anche superficialmente le varie offerte di software layer dei prodotti di questo tipo, salta agli occhi che la quasi totalità delle soluzioni si basano su una componente comune: l’OpenSource project LVS, ovvero Linux Virtual Server Project. LVS è integrato nelle soluzioni commerciali di RedHat (Piranha o, come attualmente denominato in RedHat Advanced Server, Cluster Manager), di Steeling Eye (LifeKeeper), di Alinka (Alinka Orange), di VA Linux (UltraMonkey), di PoliServe (Local Cluster), di TurboLinux (TurboCluster) solo per citarne alcune fra le più famose e che, in alcuni casi, vengono offerte in bundle da IBM, HP e Compaq (o ComHPaq), ad esempio. Da qui la decisione di cercare di far conoscere un po’ più da vicino la natura di questo progetto, i suoi scopi e i campi di utilizzabilità, ma con una avvertenza

generale: la complessità generale dell’argomento potrebbe scoraggiare il lettore e certe tematiche richiedono una riflessione approfondita ed in effetti una conoscienza tecnica elevata. Nell’ottica di un articolo divulgativo, cercheremo di mantenerci su una linea soft, a beneficio delle comprensibilità e della scorrevolezza della lettura. Daltronde, questa è la linea che consigliano anche gli stessi sviluppatori dell’LVS a chi voglia cimentarsi nell’installazione e nel test di un cluster LVS; a tale scopo, a fronte di un LVS-HOWTO (per così dire, la documentazione tecnica completa) di circa 400 pagine, hanno approntato un LVS-mini-HOWTO di circa 16 pagine che permette di installare un cluster di test di

note sull’autore Italo Lisi [email protected] Laureato in Informatica all’Università di Pisa, ha una esperienza circa quindicennale quale sistemista in ambito Unix. Ha lavorato su sistemi a parallelismo massivo e su architetture a cluster sia orientati al calcolo scientifico che alla realizzazione di servizi di rete. Membro auditore della Linux Standard Base (LSB), ha affrontato fin dal 1995 le tematiche di sviluppo di cluster basati su Linux; nell’ambito di diverse associazioni tecnologiche, ha collaborato, per le problematiche computazionali, con progetti di ricerca in diversi settori, dall’astrofisica alla fisica delle alte energie. Ha rivestito per 10 anni il ruolo di Responsabile tecnico per il Calcolo Scientifico presso il CED della Scuola Normale Superiore di Pisa. Attualmente è Responsabile del Centro Servizi Informatici presso la Scuola Superiore Sant’Anna di Pisa

clustering: LVS, Linux Virtual Server Project

tre macchine con configurazione minimale, secondo la filosofia “prima faccio, poi imparo”. E secondo noi, in questo caso hanno ragione. Ma andiamo per ordine.

Che cos’è LVS Il Linux Virtual Server for Scalable Network Services (LVS per gli amici), è un software tool in grado di fornire un bilanciamento di carico per un insieme di nodi che forniscono servizi di rete. LVS è la soluzione OpenSource per servizi di rete che meglio di qualunque altra sia in grado di rispondere alle richieste di:

√ scalabilità di servizio; √ disponibilità; √ manutenibilità; √ ottimizzazione del rapporto costoprestazioni. LVS è una soluzione basata su architettura a cluster. Laddove non sia ovvio il motivo per percorrere una soluzione cluster-oriented rispetto ad una soluzione single-server, basti dire che la richiesta architetturale minimale per attivare un servizio LVS comporta due macchine Intel-based dotate di una singola scheda di rete; la scalabilità del servizio può essere ottenuta semplicemente con l’aggiunta di nodi server, di qualsiasi classe e con qualsiasi sistema operativo ospite. La configurazione del servizio LVS è demandata ad un semplice file di configurazione ed ad operazioni abbastanza elementari sui nodi di servizio, operazioni che non giustificano di per sé scelte di costose architetture single system image. Le prestazioni globali del sistema sono, infine, vincolate dalle prestazioni dei protocolli su IP e dall’infrastruttura di rete. Pensate, quindi, ad una soluzione di produzione per il vostro e-commerce web site supportato da un costosissimo server MPP con 12 processori, confrontatelo con un cluster etereogeneo composto da 6 PC dual-processor e traete da

soli le conclusioni! Proprio quello delle Web server farms (vedi figura 1) è un tipico esempio di utilizzo dell’architettura di un cluster LVS, dove i load balancer sono a monte della frontiera di servizio composta da una moltitudine di nodi Web server, i quali utilizzano i core service tipo ASP, DB server e File Server a loro volta configurati in cluster (magari in alta disponibilità).

Teoria e Principi del Bilanciamento di Carico Prima di addentrarsi nei meandri operativi del funzionamento di LVS, forse è meglio fermarsi un attimo e guardarsi intorno. Il gioco si chiama Bilanciamento di Carico, ed ha diversi concorrenti. In un ambiente di produzione il bilanciamento del carico ha due scopi distinti: 1) prevenire il sovraccarico di un sistema di servizio, a causa delle eccessive richieste che deve servire. 2) Fornire ridondanza e protezione da interruzioni di servizio, facendo sì che se un sistema cade o viene spento, il suo carico di lavoro può da quel

momento in poi essere spostato su qualsiasi altro computer del cluster senza che l’utente si accorga né di interruzioni di servizio né di degrado prestazionale nella risposta. Esistono diversi tipi di soluzioni di load balancing; proviamo ad esplorarne alcune sfruttando come esempio applicativo un ambiente di servizi web: 1) Bilanciamento via schedulazione Round Robin delle risposte del DNS (servizio di naming): quando un client richiede l’accesso al sito www.domain.com, viene contattato il DNS che convertirà la stringa “www.domain.com” nell’indirizzo di rete numerico. Se al nome il DNS server fa corrispondere diversi indirizzi, effettivamente le risposte saranno scelte con una scansione sequenziale e ciclica di tale lista, fornendo quindi all’utenza esterna una risposta sempre differente che corrisponde a server web diversi. 2) Bilanciamento via Bilanciatore: il load balancer, posto davanti ai server di servizio, intercetta le richieste dei client e decide quale webserver utilizzare per onorarle. La modalità con cui questa

1

Una tipica applicazione di LVS riguarda le “server farms” di molti computer dedicate all’offerta di servizi di web serving.

avanzato 39

clustering: LVS, Linux Virtual Server Project

Un breve glossario dei termini più utilizzati Nel Bestiario del Cluster, alcuni termini sono ricorrenti. Molto spesso si tratta di sigle, acronimi, come se in questa società ce ne fosse ancora bisogno. Insomma, il solito linguaggio iniziatico che aleggia di tecno-misticismo, a scapito di chiarezza e comprensibilità. Avendo, tuttavia, i nostri lettori guadagnato (per la pazienza con la quale ci sopportano) il diritto alla elevazione, il Gran Maestro del Bilanciato Affidabile e Disponibile Gran Sistema Distribuito ha deciso di divulgare una parziale interpretazione di questo linguaggio iniziatico, pur ammettendo versioni “apostate”. Cominciamo col chiarire alcuni dei termini che descrivono le diverse tipologie di cluster. Cluster: insieme di computer interconnessi che appaiono all’utilizzatore come una singola risorsa computazionale, i cui elementi sono risorse dedicate al funzionamento dell’intera struttura. High Performance Computing cluster: software di clustering per la costruzione di sistemi di calcolo parallelo e batch dotato di caratteristiche di bilanciamento di carico, bassa latenza nella comunicazione e, possibilmente, singola immagine di sistema. Le soluzioni software sono spesso accompagnate da particolare hardware per la comunicazione di rete (Myrinet e SCI le più utilizzate). Le tipiche soluzioni HPC provenienti dai più importanti progetti, solitamente si presentano

scelta viene fatta, differenzia i tipi di soluzioni disponibili sul mercato: Casuale semplice: nessuna garanzia di effettivo bilanciamento di carico. Dovrebbe includere la possibilità di riconoscere e trattare la situazione in cui un web server diventa indisponibile, migliorando nettamente l’approccio DNS Round Robin; Casuale ponderata: il criterio di scelta dovrebbe prevedere la possibilità di associare ai nodi di servizio un peso discriminante che permetta di tener conto delle diversità di configurazione, oppure tener conto del numero di connessioni IP effettuate fino a quel momento a ciascun nodo di servizio in modo da distribuire più uniformemente possibile le richieste di connessione fra tutti i nodi di servizio; Basata su effettivo carico dei server:

40 avanzato

con versioni proprie del kernel (ovvero con un elevato numero di estensioni al kernel), unitamente a diverse componenti prese da vari progetti OpenSource quali installatori, schedulatori, strumenti di monitoraggio etc. I problemi di scalabilità affrontati dai maggiori progetti riguardano ordini di grandezza di migliaia di nodi. Fra i progetti HPC cluster citiamo Bewoulf (Scyld, Scalable Cluster Environment), Single Sistem Image Cluster, openMosix. High Availability cluster: combinazione hardware e software che permette di ottenere una soluzione ridondata composta da due o più nodi che condividono dispositivi di memorizzazione, in grado di operare con continuità di servizio anche in presenza di guasti hardware o malfunzionamenti software. Rispondendo alla domanda di affidabilità e continuità di servizio, dal punto di vista tecnico e dal punto di vista di richiesta di investimenti questa tipologia di cluster è la più complessa, e necessita di storage particolare (shared storage, sia realizzato con tradizionali SCSI Raid multicanale o attraverso Storage Attached Network, tipicamente realizzate con FiberChannel). La scalabilità richiesta per questi tipi di cluster arriva a pochi nodi (da due fino a circa una decina). I progetti OpenSource in campo HA Cluster sono essenzialmente due: Kimberlite (soluzione completa) e High Availability Linux Project (che

il bilanciatore mantiene un monitoraggio costante dell’effettivo carico di lavoro o del tempo di risposta dei server ed indirizza il traffico verso il sistema al momento più scarico; Basata sull’analisi del contenuto del pacchetto: permette di valutare dall’analisi del contenuto del pacchetto che tipo di applicazione è richiesta e quindi discriminare in base alla richiesta fra i diversi server. Ad esempio, alcuni nodi potrebbero fornire servizio di transmissione di video stream, altri potrebbero essere ottimizzati (o avere prodotti licenziati) per altri tipi di servizi. Il livello di analisi effettuato solitamente viene rapportato ai livelli dello stack ISO OSI, partendo dal livello 3 (Rete) o 4 (Trasporto) per arrivare fino a livello 7 (Applicativo).

mette a disposizione componenti di base utilizzati da diversi altri progetti). Una corretta interpretazione della problematica dell’alta disponibilità non può prescindere dalle caratteristiche del servizio che deve essere posto in HA cluster; in alcuni casi, assicurare la ripartenza del servizio sul nodo secondario potrebbe non essere sufficiente a garantire l’integrità del flusso dati di servizio, abbia esso un’impostazione client-server, connectionoriented o connection-less. Load Balancing cluster: spesso confusa con HA cluster, è una soluzione che risponde alla domanda di ridondanza di servizio, e che può essere adottata come soluzione di alta disponibilità per determinate tipologie di servizio (webserver, dns server, smtp server etc.). In sistemi di produzione viene spesso utilizzato unitamente a HA Cluster. Lo schema di funzionamento prevede uno o più load balancer che intercettano le richieste di servizio da parte dei client e le dirigono su server di backend, secondo criteri di bilanciamento di vario tipo. La scalabilità può raggiungere decine o centinaia di nodi. Le soluzioni open più conosciute derivano per la maggior parte da Linux Virtual Server Project; un progetto funzionalmente simile è quello dello Zeus Load Balancer.

La soluzione scelta deve comunque tener conto della problematica generale del tracciamento delle sessioni, che è di fondamentale importanza in applicazioni in cui sia necessario mantenere lo stato del client; nel caso di una web farm, questo significa che se un client inizia la sua sessione di e-commerce sul server X, non deve essere spostato da quel server per tutta la durata della sessione, per non inficiare né il meccanismo di mantenimento di stato (ovviamente stiamo parlando di cookies), né l’eventuale scambio di chiavi a supporto dei meccanismi di criptazione. Ma come avremo modo di vedere nelle prossime puntate a proposito della soluzione LVS, le considerazioni che ruotano intorno a questa tematica delle cosidette connessioni persistenti (o affini) non sono solo di natura squisitamente tecnica.

clustering: LVS, Linux Virtual Server Project

2

Approcci Pratici Diversi prodotti di mercato propongono “La Soluzione” al problema del bilanciamento dei servizi di rete, adottando una specifica linea (od un mix) fra i predetti approcci. Riconosciamo le seguenti categorie:

√ Round Robin DNS: è un approccio largamente utilizzato, ma che non garantisce alcun controllo. Se un server selezionato dal DNS è indisponibile, il client vede semplicemente che il sito non risponde, e quindi passa a navigare altrove. Inoltre, il sistema di cache distribuita del DNS fa sì che l’aggiunta di un nodo non venga reso immediatamente disponibile attraverso il DNS.

Il progetto LVS permette di ottenere un cluster in cui le richieste di servizi dei client vengono distribuite un maniera bilanciata sui nodi.

Zeus Load Balancer è un prodotto commerciale che offre un distributore di traffico TCP/IP e combina una gestione contestuale del traffico TCP ed un sistema di monitoraggio e recupero da fail-over. In effetti si tratta di un bilanciatore che opera a livello applicativo ed è specializzato per l’ottimizzazione del traffico HTTP.

√ Bilanciatori di carico in Hardware: nomi famosi come Alteon, Cisco, Jupiter o Foundry Networks forniscono switch con integrate capacità di load balancing. Solitamente questi bilanciatori sono noti come layer 3 o layer 4 switch, ovvero analizzano i pacchetti per determinare il campo IP di destinazione oppure la porta TCP/UDP, rispettivamente. I criteri di bilanciamento sono limitati e prescindono dall’effettiva analisi del carico dei server.

√ Bilanciatori di carico in software: le caratteristiche e le prestazioni di tali oggetti variano, ma essenzialmente si individuano due grosse categorie, quella dei bilanciatori IP (come LVS) e quella dei bilanciatori di protocollo (come Zeus Load Balancer, ad esempio, che viene venduto come bilanciatore per HTTP). La maggior parte di queste soluzioni sono o possono essere integrate con soluzioni per la gestione della tolleranza ed affidabilità di servizio, sia sui nodi di servizio che sui bilanciatori di carico. La realizzazione di queste soluzioni (a parte quella basata esclusivamente su

DNS) solitamente opera una scelta che vede da un lato privilegiate le prestazioni globali per il traffico di rete e dall’altro la specializzazione applicativa. LVS di nuovo si pone in una posizione interessante che, pur privilegiando le prestazioni (la schedulazione del bilanciatore avviene a livello kernel), mantiene caratteristiche marcate di flessibilità, integrabilità e altissima configurabilità.

Che cosa fa LVS Nel suo insieme, LVS è un cluster di nodi che risponde come un unico server ad un client esterno che compia una richiesta di servizio. Questo singolo nodo apparente viene chiamato virtual server. I nodi individuali di servizio, chiamati realserver, sono sotto controllo di un bilanciatore di carico, chiamato director. Lo schema generale di funzionamento del cluster LVS è mostrato in figura 2. Mentre i realserver possono essere qualsiasi tipo di sistema che offra un servizio IP-based (TCP o UDP), il director deve essere un sistema Linux. Infatti il nodo di load balancing deve ospitare un Linux Kernel con incluso una patch contenente il

codice ipvs, essenziale al funzionamento di LVS. Naturalmente, il client può essere di qualsiasi tipo. Gli sviluppatori di LVS, fra cui citiamo Wensong Zhang, Julian Anastasov, Joseph Mack, Peter Kese, Horms, Roberto Nibali, sono più volte stati categorici su un punto: LVS è e sarà solo per Kernel Linux. Il director fornisce ai client un IP address chiamato Virtual IP (VIP). Quando un client si collega al VIP, il director redirige i pacchetti che giungono dal client ad un particolare realserver, per l’intera durata della connessione del client all’LVS. I realserver forniscono servizi (ad es. ftp, http, dns, telnet etc.) e, tuttavia, le connessioni ad essi vengono gestite tramite director attraverso il virtual IP address. Il VIP diventa così l’indirizzo su cui vogliamo compiere bilanciamento di carico, ad esempio l’indirizzo del nostro Web Site. Il VIP è un indirizzo associato ad un servizio e non ad un particolare sistema del cluster che offra quel tipo di servizio. Quindi, solitamente, il VIP è un alias (ad esempio, eth0:1) rispetto alla configurazione di interfacce presenti sul director o sui realserver.

avanzato 41

clustering: LVS, Linux Virtual Server Project

Site linuxcom

Description

LVS Notes

The Linux Portal

LVS web cluster

sourceforgenet

The largest OpenSource development site

LVS (load balancing HTTP
HTTPS
FTP
SSH
CVS)

themesorg

The largest interface/themes site for the X Window System

LVS web cluster

UK National JANET Web Cache Service

 Squid cache servers in three LVS clusters
GB content shipped/day

wwwzopeorg

The leading OpenSource web application server

web cluster

TuxFamilyorg

Free hosting for free software like savannah

using LVS/heartbeat ( load balancers failover and real servers) for all the hosting services

wwwcachejanet

wwwcarecom

valinuxcom

Largest web site community of people who  web servers and a single load balancer care about the environment

VA Linux Systems
Inc

LVS web cluster

Real Networks
Inc

LVS media cluster ( nodes)

A full service Internet Access and Presence Provider

LVS web hosting cluster

wwwgreenheck com

Leading manufacturer of air movement and control equipment

LVS web cluster ( node)

mapnet

An ICP that allows you to explore the Internet in the same way you explore a map

LVS web cluster ( nodes) by Brian Edmonds

a big hardware review site

two primary backup load balancers and eleven web servers
more information

wwwtiscovercom

The rd largest Portal Site in Austria with more than 
 visits per day

LVS web cluster

wwwcycosmoscom

An virtual community website in United Kingdom and Germany

LVS web cluster

wwwmybizcom

mybiz provides customer service and marketing tools that enable small businesses to build stronger and more profitable customer relationships

LVS cluster handling just about every public service
mainly web
plus back end clusters for in house daemons

Undergraduate Computer Cluster

Undergraduate Students in the Electronics and Computer Science Department at the University of Southampton (England) use it for compilation
and running software remotely

It consists of  dual processor real servers and balances telnet and ssh connections

datingfacescom

Online dating site

A LVS cluster with  directors (VS/DR) and  real servers handles about   million hits per day

wwwchezcom persoinfoniefr

Tiscali Group's massive web hosting services

 LVS directors:  for chezcom (  for fail over) and  for the other domains (  for fail over)
load balancing   Mb/s of HTTP and FTP

servecom

Large shared hosting environment

LVS web cluster with live fail over

One of the largest yellowpage site in Korea

 director/load balancer(single Pentium SuseLinux ) and  FreeBSD X web server cover about mil hits/day static HTTP traffic by Direct Routing

Astrodienst Homepage

 LVS director running in VS/NAT mode with four real servers

wwwrealcom wwwnetwalkcom

anandtechcom

yescallcom

astrocom

42 avanzato

Questo ricorso ad alias fa si anche che se il director cade, sia sempre possibile trasferire il VIP su un altro director. Questa gestione ridondata dei director risulta molto importante nei sistemi di produzione, eliminando in questo modo il punto di forte criticità dell’intero sistema, il director. LVS integra la gestione fault-tolerance (o per meglio dire, ridondata) dei director, facendo ricorso a tool di monitoraggio tipo heartbeat e mon. Quando il beat non risponde, o quando il monitoraggio risponde con parametri oltre le soglie di tolleranza, il VIP viene trasferito su un altro director, anche se questo fosse dotato di un’unica interfaccia di rete, grazie ad una semplice ifconfig di un alias ip. Ogni director può ospitare diversi VIP, ognuno dei quali è associato ad uno o più servizi. Ad esempio, un VIP potrebbe essere destinato al servizio HTTP/HTTPS bilanciato, un altro VIP potrebbe invece servire il servizio TELNET bilanciato, e le chiamate a questi VIPs potrebbero essere onorate da un unico realserver, oppure finire su realserver distinti. In quanto detto finora c’era un assunzione implicita: ovvero che ogni connessione di rete fosse indipendente dalle altre. Tuttavia, può accadere che almeno due connessioni da parte dello stesso client debbano essere associate allo stesso realserver. Un esempio di tale situazione è la gestione del protocollo FTP: esso utilizza due porte sul server, la 20 e la 21, rispettivamente per il trasferimento dati e per l’interscambio di informazioni di stato e comandi. Mentre per l’active FTP è il client a dire al server la porta sulla quale vuole aprire la connessione dati, nel modello passive FTP è invece il server, a dire su quale porta il client deve aprire la connessione. Come vedremo, esistono determinate situazioni in cui il director non interviene in entrambe le direzioni della comunicazione fra client e realserver, e questo di fatto comprometterebbe l’utilizzo di LVS per un servizio quale passive FTP. In alcune situazioni si presenta quindi la

clustering: LVS, Linux Virtual Server Project

3

Il sito del Linux Virtual Server Project, software utilizzabile per la creazione di cluster scalabili, per l’alta affidabilità.

necessità di raggruppare insieme alcune porte associate ad un unico servizio, per le quali sia necessario stabilire delle condizioni o parametrizzazioni sulle caratteristiche della connessione client/server. Questo ricorso ai raggruppamenti di VIPS e/o porte è reso possibile tramite ricorso a meccanismi di firewall marking, fwmark. Inoltre è possibile gestire particolari situazioni in cui sia necessario assicurare persistenza della connessione, ovvero ove sia importante assicurare che la connessione avvenga sempre sul medesimo realserver in maniera tale che le informazioni di stato della connessione stessa restino coerenti per tutta la sua durata. È questo il caso, ad esempio, delle connessioni http con cookie oppure https, oppure di servizi multiporta come ad esempio il già citato ftp.

Perchè utilizzare LVS Alla domanda “in quali situazioni posso utilizzare LVS?” non c’è una risposta definitiva. Ognuno può inventarsi un campo di applicabilità in cui LVS risulti utile. Qualche esempio nel seguito servirà a fornire degli spunti di riflessione. Rimandiamo, comunque, alla documentazione tecnica di progetto per avere un quadro più ampio di applicabilità. È quindi meglio capire a quali esigenze di servizio LVS è in grado di dare una risposta concreta e affidabile:

√ incremento prestazionale: il costo dell’incremento di prestazioni globali (throughput) del servizio è lineare, ovvero è rappresentato dal costo di ogni nodo aggiuntivo. Inversamente, il costo per incremento di prestazioni di un single-server per passare ad un sistema più potente è più che lineare.

√ garanzia di ridondanza: in un LVS cluster, ogni singolo nodo può essere soggetto a crash o essere spento per manutenzione senza interrompere il servizio. Le macchine possono essere spostate o aggiunte a piacere senza interruzione del servizio al client, grazie alla possibilità di configurare dinamicamente il pool di macchine di servizio.

√ adattabilità: a volte la richiesta di prestazioni può avere dei picchi limitati nel tempo e che comunque non giustificano grossi investimenti di scalabilità prestazionale. In questo caso la configurazione del cluster può essere incrementata o diminuita a piacimento ed in maniera del tutto trasparente. Analogamente, un nuovo servizio deve poter scalare gradualmente a seconda delle necessità, senza dover ricorrere a difficili previsioni di utilizzo su cui pianificare la giusta configurazione di una soluzione single-server.

economica, prestazionale, scalabile ed affidabile. A queste caratteristiche ne vanno aggiunte altre, che avremo modo di vedere insieme, quali ad esempio un grande configurabilità, una integrazione lineare con componenti ad alta disponibilità ed il supporto per la maggior parte dei servizi basati su TCP e UDP senza apportare alcuna modifica sia al lato server che al lato client. La base di installazioni LVS è vasta ed importante, e tende sempre più a crescere. Confrontato con altri prodotti commerciali analoghi, LVS può offrire prestazioni globali quantomeno comparabili con il vantaggio di essere a costo zero. A dimostrazione di quanto affermato vi proponiamo nella tabella a pagina 42 una lista di siti che utilizzano in produzione cluster LVS per varie tipologie di servizi. Pensiamo che questo sia sufficiente per invogliare il lettore ad entrare più nello specifico, seguendoci nel seguito dentro i meandri tecnici della soluzione LVS. Per chi fosse impaziente, il sito da consultare è http://linuxvirtualserver.org la cui attuale struttura è mostrata in figura 3. Oltre ad una completa documentazione di progetto, alla pagina di download sia per la linea stabile che di sviluppo di prodotto sia per i kernel attuali (2.4 o 2.2) che vecchi, il sito offre un buon numero di links a componenti software, integrabili in LVS, che fanno parte di progetti autonomi o derivati dal lavoro originario di Wensong Zhang. È inoltre possibile iscriversi alla mailing list: [email protected]

Per continuare Nel seguito vedremo come partire con una configurazione tipo Plug and Play di un cluster LVS, e gradualmente forniremo degli approfondimenti per capire un po’ meglio il funzionamento di LVS e le tematiche sottese. Nell’attesa, buon bilanciato divertimento.

Un cluster LVS rappresenta una soluzione

avanzato 43