AA. 2008/2009 - Dipartimento di Informatica

SIST EM I DIST R IBU IT I: A RCH IT ET T URA E
M OD EL LAZ ION E
AA. 200 8/2009
APPROFONDIMENTO SU SISTEMI CLUSTER
E GRID
Sviluppatori:
de Candia Corrado – Mat. 540276
Nettis Giuseppe – Mat. 540242
SOMMARIO
1 - Cluster........................................................................................................................................................... 3
1.1 - Requisiti per formare un cluster di computer ....................................................................................... 4
1.2 - Tipi di cluster computing ....................................................................................................................... 4
1.3 - Compute clusters................................................................................................................................... 7
1.4 - Consumer game consoles...................................................................................................................... 7
1.5 - Applicazione di cluster computing per grandi prestazioni .................................................................... 7
1.6 - Cluster Objectives .................................................................................................................................. 7
1.7 - Storia del calcolo cluster ....................................................................................................................... 8
1.8 - Tecnologie per il cluster ........................................................................................................................ 9
1.9 - Beowulf................................................................................................................................................ 10
1.10 - Sistemi operativi ................................................................................................................................ 10
2 - Grid computing ........................................................................................................................................... 11
2.1 - I sistemi Grid ........................................................................................................................................ 12
2.2 - Tipologie di grid computing ................................................................................................................. 12
2.3 - Un po' di storia .................................................................................................................................... 13
2.4 - Il modello dei servizi OGSA .................................................................................................................. 15
2.5 - Grid Computers vs Mainframes........................................................................................................... 16
2.6 - Come lavora il grid computing ............................................................................................................ 17
2.7 - Preoccupazioni sul Grid Computing .................................................................................................... 18
2.8 - Le applicazioni grid computing più importanti.................................................................................... 20
2.9 - Programmare in parallelo.................................................................................................................... 24
2.10 - Problemi aperti .................................................................................................................................. 26
3 - Grid Computing vs. Cluster Computing ...................................................................................................... 28
4 - Esempio Load Balancing: LVS ..................................................................................................................... 30
4.1 - Linux Virtual Server ............................................................................................................................. 31
4.2 - IP virtual server.................................................................................................................................... 32
4.3 - Architettura LVS .................................................................................................................................. 33
4.4 - IPVS ...................................................................................................................................................... 34
4.5 - Come funziona LVS .............................................................................................................................. 34
4.6 - Difesa da attacchi DoS ......................................................................................................................... 38
4.7 - Alta disponibilità e monitoraggio ........................................................................................................ 39
4.8 - Allestire un cluster a bilanciamento di carico ..................................................................................... 40
2
1 - Cluster
Un computer cluster, o più semplicemente un cluster (dall'inglese grappolo), è un insieme di
computer connessi tramite una rete telematica. Lo scopo di un cluster è quello di distribuire una
elaborazione molto complessa tra i vari computer componenti il cluster. In sostanza un problema
che richiede molte elaborazioni per essere risolto viene scomposto in sottoproblemi separati i quali
vengono risolti in parallelo. Questo ovviamente aumenta la potenza di calcolo del sistema.
Un cluster quindi è generalmente
eneralmente costituito da due o più computer (nodi) connessi tra loro, in un
singolo luogo, o fisicamente separate e connessi via LAN. Appare come un unico sistema agli
utenti e alle applicazioni e fornisce un modo conveniente per ottenere benefici
Il cluster ha numerose applicazioni scientifiche e ingegneristiche:
•
•
•
Business Applications:
◦
E-commerce
commerce Applications (Amazon, eBay);
◦
Database Applications (Oracle on clusters).
Internet Applications:
◦
ASPs (Application Service Providers);
◦
Computing Portals;
◦
E-commerce and E-business.
business.
Mission Critical Applications:
◦
Sistemi di controllo, banche, controllo
cont
di reattori nuclear,ecc.
3
I vantaggi sostanziali dei cluster corrispondono ad un rapporto Prezzo/performance dei Clusters
basso in confronto a quello dei computer paralleli dedicati, ad una crescita incrementale che
spesso si abbina con i patterns richiesti, alla possibilità di fornire sistemi multipurpose (Scientific,
commercial, Internet applications) e per questo sono diventati i principali sistemi informatici nelle
imprese.
1.1 - Requisiti per formare un cluster di computer
Per ottenere un sistema di computer operanti come un cluster è necessario:
1. un sistema operativo in grado di far funzionare i computer come cluster (per esempio
gNU/Linux, utilizzando OpenMosix)
2. hardware di rete ad elevate prestazioni
3. un algoritmo parallelizzabile
1.2 - Tipi di cluster computing
Esistono tre tipi di cluster: Fail-over, Load balancing ed High Performance Computing, WebService Clusters, Storage Clusters (GFS; filesystems paralleli; stessa visione dei dati da ogni
nodo), Database Clusters (Oracle Parallel Server), High Availability Clusters con i primi tre che
sono probabilmente i più diffusi:
1.2.1 - Fail-over Cluster
Il funzionamento delle macchine è continuamente monitorato, e quando uno dei due host smette di
funzionare l’altra macchina subentra. Lo scopo è garantire un servizio continuativo. I Failover
Clusters (conosciuti come High-availability clusters) sono implementati principalmente allo scopo di
aumentare la disponibilità di servizi che il cluster offre. Essi operano tramite dei nodi ridondanti,
che sono usati per offrire il servizio nel caso in cui delle componenti del sistema vengono a
mancare. La dimensione più comune per un cluster HA è quella a due nodi, che è il requisito
minimo per ottenere ridondanza. L’implementazione di cluster HA cerca di usare la ridondanza di
componenti cluster per eliminare ogni singolo punto di guasto o fallimento. In genere, se un server
con una particolare applicazione cade, l’applicazione non sarà disponibile fino a quando qualcuno
applicherà un fix al server caduto. Il clustering HA rimedia a questa situazione rilevando i faults
hardware/software, e lanciando immediatamente l’applicazione su un altro sistema senza
richiedere l’intervento dell’amministratore; questo processo è chiamato failover.
Come parte di questo processo, il software di clustering potrebbe configurare il nodo prima di
lanciare l’applicazione su di esso. Per esempio, alcuni file systems potrebbero aver bisogno di
essere importati e montati, oppure l’hardware di rete potrebbe essere configurato. I clusters HA
sono spesso usati per database critici, file sharing su una rete, applicazioni di business, ecc. I
cluster generalmente usano una connessione di rete privata che è usata per monitorare lo stato di
ogni nodo nel cluster. Una rara ma seria condizione che ogni software di clustering deve saper
trattare è il split-brain. Il split-brain avviene quando tutti i collegamenti privati cadono
simultaneamente, ma i nodi cluster sono ancora attivi. Se questo succede, ogni nodo nel cluster
potrebbe decidere, sbagliando, che ogni nodo è caduto e potrebbe cercare di avviare i servizi che
altri nodi stanno già gestendo. In questo modo istanze duplicate di servizi potrebbero causare il
danneggiamento dei dati sullo storage condiviso.
Vi sono varie implementazioni commerciali di High-Availability clusters per diversi sistemi operativi.
Il progetto Linux-HA è un pacchetto software free per il sistema operativo Linux.
4
Questi prodotti sono famosi per uso commerciale o accademico:
1. HP ServiceGuard for HP-UX and Linux
2. IBM High Availability Cluster Multiprocessing (HACMP) for AIX and Linux
3. Linux-HA
4. Pacemaker - un resource manager open source scalabile, usato in Novell's High
Availability Extension
5. Microsoft Cluster Server (MSCS) and Microsoft's Windows Server Failover Clustering
(WSFC) for Server 2008
6. Oracle Clusterware - multi-platform, offre una infrastruttura per Oracle Real Application
Clusters (RAC) e abilita la protezione di applicazioni Oracle e non-Oracle
* Red Hat
Cluster Suite - Linux only
7. Sun Cluster - Solaris/OpenSolaris solo
8. Veritas Cluster Server - multi-platform
I successivi sistemi cluster sono meno comunemente trovati in produzione:
1. Egenera - PAN Manager / BladeFrame
2. EMC Corporation AutoStart for all platforms
3. HA/FST Solaris Sparc & x86
4. Parallel Sysplex - unique to IBM mainframes
5. IBM Tivoli System Automation - z/OS, AIX, Linux, Windows Server 2003
6. Lexst Database Cluster Lexst database cluster
7. NEC ExpressCluster - Windows & Linux
8. openMOSIX Gentoo Linux
9. OpenSSI for Linux
10. TruCluster
11. OpenVMS - The original clustering OS - runs on VAX, Alpha and Itanium(2) only, still no
EOL
1.2.2 - Cluster con load balancing
E' un sistema nel quale le richieste di lavoro sono inviate alla macchina con meno carico; si ha
load-balancing quando vari computer sono collegati per condividere il carico di lavoro come se ci
fosse un solo computer virtuale. A rigor di logica, dal lato utente, si tratta di macchine multiple, ma
che funzionano come una singola macchina virtuale. Le richieste inviate dall’utente sono gestite e
distribuite tra tutti i computer per costituire un cluster. Tutto ciò porta a un lavoro computazionale
bilanciato tra le differenti macchine e ad un miglioramento delle performance del sistema.
1.2.3 - High Performance Computing Cluster
I computer sono configurati per fornire prestazioni estremamente alte. Le macchine suddividono i
processi di un job su più macchine, al fine di guadagnare in prestazioni. La peculiarità saliente è
che i processi sono parallelizzati e che le routine che possono girare separatamente saranno
5
distribuite su macchine differenti invece di aspettare di essere eseguite una dopo l’altra. GLI HPC
sono diffusi specialmente tra centri di elaborazione dati. L'utilizzo di questa tecnologia è molto
diffuso: per esempio Ferrari e Dreamworks utilizzano cluster (basati sul sistema operativo
GNU/Linux) sui quali fanno girare programmi di rendering e di simulazione fluidodinamica
computazionalmente molto onerosi.
High Performance Computing identifica un sistema in cui le risorse di calcolo sono particolarmente
performanti. Tradizionalmente i sistemi HPC sono rappresentati da macchine monolitiche capaci di
alloggiare più CPU e con bus dati estremamente performanti. Più recentemente, mediante
l'impiego di Mosix, è stato possibile realizzare un sistema HPC con molti vantaggi, quali:
1. costi decisamente inferiori rispetto ai sistemi monolitici
2. utilizzo di tecnologie comuni e componenti disponibili attraverso la grande distribuzione
COTS:Commodity Off The Shelf)
3. architettura scalabile dei sistemi
4. relativa semplicità di realizzazione e di amministrazione
Si evidenzia che utilizzando Mosix, software Open Source, gli unici costi del sistema sono relegati
eslusivamente all'hardware.
1.2.3.1 - Come si realizza un sistema HPC
Un cluster linux è un'architettura multicomputer che può essere usata, in versione HPC, per
eseguire elaborazioni parallele. Il sistema utilizza componenti hardware comuni, adattatori
Ethernet e switch specifici per l'applicazione. Esistono più possibilità di implementare un cluster
Linux HPC, per esempio si può utilizzare Beowulf oppure Mosix. L'architettura del sistema
normalmente è composta da un nodo server e da più nodi client connessi via Ethernet o altri tipi di
rete. In generale si utilizza un insieme di strumenti software che girano sul kernel Linux e che
includono software di message passing (MPI e PVM), Kernel modificati per gestire più interfacce di
rete,
driver
per
alte
prestazioni
ed
altre
specifiche
modifiche.
Le librerie specifiche per il message passing sono:
1. MPI con caratteristiche specifiche per lo scambio di messaggi su calcolatori paralleli e reti
di calcolatori
2. PVM con la capacità di creare in modo coerente un'astrazione software che rappresenta e
gestisce un calcolatore parallelo virtuale.
L'implementazione Mosix, per quanto simile a Beowulf, si distingue da quest'ultima per poter
disporre di un load balancer automatico e per la capacità di migrare i files aperti.
High-performance computing dunque consiste nell'uso di processi paralleli per eseguire programmi
e applicazioni efficientemente, velocemente e in modo affidabile. Il termine HPC è
occasionalmente usato come un sinonimo di supercomputing, sebbene tecnicamente un
supercomputer è un sistema che presenta il rate operazionale più alto per computer. I più comuni
utenti di sistemi HPC sono i ricercatori scientifici, gli ingegneri e le istituzioni accademiche. Alcune
organizzazioni governative, in particolare quelle militari, si servono di applicazioni HPC complesse.
Vista la richiesta di potenza computazionale e la crescita delle velocità, l’HPC presenta interesse
anche nel business di tutte le misure, in particolare per il trattamento delle transazioni e per i data
warehouses.
6
1.3 - Compute clusters
Spesso i cluster sono usati principalmente per scopi computazionali, piuttosto che per trattare
operazioni IO-oriented come web service o database. Per esempio, un cluster potrebbe supportare
simulazioni computazionali riguardanti il meteo o gli incidenti automobilistici. La distinzione
primaria nella computazione dei clusters è nel modo in cui i singoli nodi sono strettamente
accoppiati. Per esempio, un singolo processo di computazione potrebbe richiedere comunicazioni
frequenti tra i nodi; questo implica che i cluster condividono una rete dedicata. Questa
progettazione di cluster è riferita usualmente ad un Cluster Beowulf. L’altro estremo è nel caso in
cui un processo di computazione usa uno o pochi nodi, e ha bisogno di poca comunicazione tra i
nodi. Quest’ultima categoria è chiamata a volte “grid” computing. Clusters fortemente accoppiati
sono progettati per un lavoro che tradizionalmente potrebbe essere chiamato “supercomputing”.
1.4 - Consumer game consoles
A causa dell’incremento della Potenza computazionale di ogni generazione di console di gioco, è
emersa una nuova tendenza dove la consoles sono riproposte in clusters HPC. Alcuni esempi di
clusters di console di gioco sono i clusters Sony Playstation e i Microsoft Xbox. Si dice che alcune
nazioni che sono limitate dall’acquistare tecnologie di supercomputing acquisterebbero sistemi di
gioco per costruire clusters di computer per uso militare.
1.5 - Applicazione di cluster computing per grandi prestazioni
L'organizzazione TOP500 elenca ogni semestre i 500 calcolatori più veloci al mondo e solitamente
in questa lista sono inclusi molti cluster. TOP500 è una collaborazione fra università di Mannheim,
università del Tennessee e centro di elaborazione scientifico nazionale di ricerca energetica al
laboratorio nazionale Lawrence Berkeley. Al novembre 2006, il supercomputer più veloce era il
sistema IBM Blue Gene/L del Dipartimento per l'energia degli USA con le prestazioni di 280.6
TFlops. Usare cluster può fornire significativi incrementi di prestazioni contenendo il costo. System
X, il supercomputer di Virginia Tech, al giugno 2006 era il ventottesimo supercomputer più potente
sulla terra. É un cluster da 12.25 TFlops costituito da 1100 Apple XServe G5 a doppio processore
da 2.3 gigahertz (RAM da 4 GB, HD SATA da 80 GB) con sistema operativo Mac OS X ed
interconnessi tramite InfiniBand. Il cluster inizialmente era costituito da Power Mac G5 che poi
sono stati venduti. Gli XServe sono impilabili e meno voluminosi dei Mac desktop e consentono di
realizzare quindi un cluster più compatto. Il costo complessivo del suddetto cluster di Power Mac
era $5.2 milioni, un decimo del costo dei più lenti supercomputer costituiti da un unico elaboratore
(mainframe).
Il concetto centrale del cluster Beowulf è l'uso di calcolatori commerciali per produrre un'alternativa
economica ad un supercomputer tradizionale. Un progetto che ha preso questo concetto
portandolo all'estremo era lo Stone Supercomputer. Il progetto SETI@home sembrerebbe essere il
più grande cluster distribuito esistente. Utilizza circa tre milioni di personal computer sparsi in tutto
il mondo per analizzare i dati provenienti dal radiotelescopio di Arecibo, al fine di trovare la prova
dell'esistenza di intelligenza extraterrestre.
1.6 - Cluster Objectives
In genere il termine cluster era usato per rappresentare Server Clusters. I sistemi clusterizzati sono
sinonimi di un gruppo di servers. Il server, essendo il livello principale o la piattaforma dove il
database o l’applicazione di servizio risiedono, è il componente più importante nel fornire
disponibilità e alte prestazioni.
7
I clusters mirano principalmente a proteggere la disponibilità del server. Ogni fallimento in un
server è trasparente all’utente finale ed è nascosto dal failover dell’applicazione o del database su
un altro nodo. Gli utenti finali o i clients hanno accesso sull’altro nodo, permettendo al processo di
continuare. In un’altra situazione, un gruppo di nodi sono uniti per fornire servizi al database, come
se ci fosse un database parallelo. Il fallimento di un singolo nodo non interrompe l’accesso al
database visto che i nodi secondari sono ancora attivi e forniscono l’accesso al database.
1.7 - Storia del calcolo cluster
La storia del calcolo cluster è riassunta nel modo migliore in una nota in “In Search of Clusters” di
Greg Pfister:
“Virtualmente ogni dichiarazione rilasciata dalla DEC che menziona i cluster dice: DEC, che ha
inventato i cluster.... Non li ha inventati neanche IBM. Gli utenti hanno inventato i cluster, dal
momento che non potevano portare avanti tutto il loro lavoro su un solo computer, o necessitavano
di un backup. La data dell'invenzione è sconosciuta, ma penso che sia durante gli anni '60, o
anche alla fine dei '50.
La base della tecnologia del calcolo cluster inteso come il compiere un lavoro qualsiasi
parallelamente fu discutibilmente introdotta da Gene Amdahl della IBM, che nel 1967 pubblicò un
articolo con quella che sarebbe stata considerata la base del calcolo parallelo: la Legge di Amdahl,
che descrive matematicamente l'aumento di prestazioni che si può ottenere compiendo
un'operazione in una architettura in parallelo.
L'articolo scritto da Amdhal definisce le basi ingegneristiche sia per il calcolo multiprocessore che
per il calcolo cluster. La differenza significativa tra i due sta nel fatto che le comunicazioni
interprocessore sono supportate all'interno del computer (ad esempio con un bus o rete di
comunicazione interna adattata) oppure all'esterno del computer, su una rete commerciale. Questo
articolo definì le basi ingegneristiche sia per il calcolo multiprocessore che per quello cluster, dove
la differenziazione primaria è se la comunicazione interprocessore è supportata o meno
all'”interno” del computer (per esempio su un bus di comunicazione interno personalizzato o su
una rete) o all'”esterno” del computer su una rete commerciale.
Di conseguenza la storia dei primi computer cluster è più o meno direttamente inclusa nella storia
delle prime reti, dato che uno dei primi motivi per lo sviluppo di una rete è stata la possibilità di
collegare fra loro risorse di calcolo, di fatto creando un cluster di computer.
Le reti a commutazione di pacchetto furono inventate concettualmente dalla società RAND nel
1962. Utilizzando il concetto di una rete a commutazione di pacchetto, il progetto ARPANET riuscì
nella creazione nel 1969 di quello che era forse il primo cluster di computer basato su una rete
commerciale collegando quattro diversi centri di calcolo (ognuno dei quali era quasi un "cluster",
ma probabilmente non un cluster commerciale).
Il progetto ARPANET si sviluppò quindi come Internet, che può essere considerata la madre di tutti
i computer cluster; Internet raffigura il paradigma odierno del cluster di tutti i computer del mondo.
8
”
I PRIMI SISTEMI CLUSTER DI RICERCA
Project
Platform
Communications
OS/Management
Other
Beowulf
PCs
Multiple Ethernet with
TCP/IP
Linux + PBS
MPI/PVM.
Sockets and
HPF
Berkeley
Now
Solaris-based
PCs and
workstations
Myrinet and Active
Messages
HPVM
PCs
Myrinet with Fast
Messages
NT or Linux
connection and
global resource
manager + LSF
Java-fronted,
FM, Sockets,
Global Arrays,
SHEMEM and
MPI
Solaris MC
Solaris-based
PCs and
workstations
Solaris-supported
Solaris +
Globalization layer
C++ and
CORBA
Solaris + GLUnix + AM, PVM, MPI,
xFS
HPF, Split-C
1.8 - Tecnologie per il cluster
MPI è una libreria di programmi di comunicazione tra computer, ampiamente disponibili che
permette la scrittura di programmi paralleli nei linguaggi C, Fortran, Python, OCaml, e molti altri
linguaggi di programmazione. Il mondo GNU/Linux supporta vari tipi di software per il clustering,
come:
1. Beowulf, distcc, MPICH ed altri gran parte sono applicazioni di clustering molto
specializzate. Il programma distcc fornisce compilazione parallela quando utilizza la GCC
2. Linux Virtual Server, Linux-HA sono cluster con un computer-direttore che permette alle
richieste di servizi in arrivo di essere distribuite attraverso molteplici nodi del cluster
3. MOSIX, openMosix, Kerrighed, OpenSSI sono cluster sotto ogni punto di vista, che sono
stati integrati nel kernel che provvede alla migrazione automatica dei processi tra nodi
omogenei. OpenSSI, openMosix e Kerrighed sono implementazioni single-system image.
GNU/Linux è attualmente il sistema più utilizzato per il clustering: secondo Top500 nel 2006 è
stato il sistema più usato in assoluto. La piattaforma Microsoft Windows Compute Cluster Server
2003 basata su Windows Server 2003 Standard x64 Edition fornisce elementi per il calcolo ad alte
prestazioni, come "Job Scheduler", le librerie MSMPI ed altri strumenti di amministrazione. Lincoln,
recentemente installato nel NCSA è un cluster di 450 Dell PowerEdge 1855 blade servers sui quali
9
gira Windows Compute Cluster Server 2003. Questo cluster debuttò al centotrentesimo posto nella
Top500 nel giugno 2006 anche se attualmente come unico rappresentante di questa tecnologia.
DragonFly BSD, un recente fork di FreeBSD 4.8 è stato ridisegnato nel suo cuore elaborativo per
abilitare capacità di clustering naturali. Consente inoltre di ottenere capacità di single-system
image.
1.9 - Beowulf
Beowulf è un sistema di calcolo parallelo basato su cluster di personal computer collegati tramite
reti informatiche standard, senza l'utilizzo di apparecchiature sviluppate esplicitamente per il
calcolo parallelo.
Inizialmente venne sviluppato da Donald Becker alla NASA, ma in seguito lo sviluppo venne
continuato da una comunità internazionale interessata al calcolo scientifico.
Un Cluster Beowulf normalmente è un gruppo di computer IBM compatibili utilizzanti software open
source. Usualmente il sistema operativo è GNU/Linux o una delle varianti di Unix disponibili
gratuitamente. I collegamenti vengono realizzati tramite LAN TCP/IP, mentre la comunicazione e
sincronizzazione dei processi vengono realizzate tramite librerie disponibili gratuitamente.
Un Cluster Beowulf non è gestito da un particolare software. Spesso si utilizzano librerie per il
calcolo parallelo come le MPI (Message Passing Interface) e le PVM (Parallel Virtual Machine).
Queste permettono al programmatore di dividere i compiti da svolgere su un gruppo di computer
collegati in rete e di riunire i risultati dei singoli processi per ottenere la soluzione del problema
trattato.
Il nome del progetto deriva dal poema epico Beowulf.
1.10 - Sistemi operativi
Attualmente molte distribuzioni Linux sono state realizzate appositamente per permettere la
realizzazione di un sistema Beowulf in modo relativamente semplice.
1. ClusterKnoppix (basata su Knoppix)
2. ParallelKnoppix (anche questa basata su Knoppix)
3. Quantian (basata su clusterKnoppix)
4. PlumpOS
5. dyne:bolic
6. Rocks Linux
7. Oscar
8. Scyld
9. Clustermatic
Un cluster può essere realizzato semplicemente utilizzando un CD di boot della distribuzione
Knoppix in congiunzione con openMosix. Il computer verrà automaticamente configurato e
collegato al cluster con una semplice configurazione in modo da poter condividere la propria
potenza di calcolo e memoria. Questa tipologia di sistema è molto scalabile, può essere infatti
espansa in modo virtualmente illimitato (sempre che il canale di comunicazione non diventi il collo
di bottiglia).
10
2 - Grid computing
I grids sono clusters di computer, spesso incorporano insiemi eterogenei di computer,
possibilmente geograficamente distribuiti e amministrati da organizzazioni non correlate tra loro. Il
Grid computing è ottimizzato per carichi di lavoro che consistono di vari lavori o pacchetti di lavoro
indipendenti, i quali non condividono dati tra i processi durante la computazione. Le risorse
potrebbero essere condivise da tutte i nodi, ma i risultati intermedi di un lavoro non influenzano gli
altri lavori in progresso sugli altri nodi del grid.
I Grid computing o sistemi Grid sono dunque un’infrastruttura di calcolo distribuito, utilizzati per
l’elaborazione di grandi quantità di dati, mediante l’uso di una vasta quantità di risorse condivise e
coordinate all'interno di una organizzazione virtuale.
Tale sistema abilita la virtualizzazione di computazioni distribuite e risorse di dati come processing,
larghezza di banda di una rete e capacità di immagazzinamento per creare un’unica immagine del
sistema, garantendo agli utenti e alle applicazioni accesso a varie capacità. Cosi come in internet
gli utenti vedono il contenuto unificato via web, un utente grid essenzialmente vede un unico e
grande computer virtuale. Nel suo core, il grid computing è basato su un insieme aperto di
standard e protocolli, come ad esempio OGSA (Open Grid Services Architecture), che permettono
la comunicazione tra ambienti eterogenei e geograficamente dispersi. Con il Grid computing, le
organizzazioni possono ottimizzare la computazione e le risorse dei dati, metterle insieme per
grandi carichi di lavoro, condividerle tramite networks e permettere la collaborazione.
Le proprietà fondamentali del grid computing sono il controllo coordinato su larga scala di risorse,
appartenenti a diversi domini amministrativi, l'uso di protocolli ed interfacce standard, open e
general-purpose che forniscono una gamma di servizi, il supporto ad applicazioni eterogenee, il
supporto a Quality of Service(QoS) complessi: tempi di risposta, throughput, disponibilità,
affidabilità, sicurezza ed infine la capacità di gestire diversi sistemi contemporaneamente.
Dal punto di vista strutturale, un sistema di grid computing richiede:
•
Almeno un computer, di solito un server, che gestisce tutte le funzioni amministrative per il
sistema. Molte persone si riferiscono a questo tipo di computer come un nodo di controllo.
Un’altra applicazione e web server (sia fisici che virtuali) forniscono servizi specifici per il
sistema.
•
Una rete di computer con particolari software di rete di grid computing. Questi computer
agiscono sia come punto di interfaccia per l'utente e come risorse a cui il sistema fa
riferimento per le diverse applicazioni. I sistemi di Grid computing possono includere diversi
computer della stessa marca in esecuzione sullo stesso sistema operativo (chiamato un
sistema omogeneo) o un miscuglio di diversi computer in esecuzione su ogni sistema
operativo che si possa immaginare (un sistema eterogeneo). La rete può essere qualsiasi,
da un sistema cablato in cui ogni computer si collega al sistema con cavi fisici, a un
sistema aperto in cui i computer sono in contatto tra loro su Internet.
•
Una raccolta di software per computer chiamato middleware. Lo scopo del middleware è
quello di permettere a diversi computer di eseguire un processo o un'applicazione lungo
tutta la rete di macchine. Il Middleware è il cavallo di battaglia del sistema di grid
computing. Senza di essa, la comunicazione attraverso il sistema sarebbe impossibile.
Come il software in generale, non c'è un formato unico per il middleware.
Se middleware è il cavallo di battaglia del sistema di grid computing, il nodo di controllo è il
dispatcher. Il nodo di controllo deve definire le priorità e pianificare le operazioni in tutta la rete. E'
11
compito del nodo di controllo determinare a quali risorse ogni compito dovrà accedere. Il nodo di
controllo deve anche controllare il sistema per assicurarsi che non sia sovraccarico. E' anche
importante che ad ogni utente connesso alla rete non si verifichi un calo della performance del suo
computer. Un sistema di grid computing dovrebbe attingere alle risorse del computer non utilizzati
senza impattare tutto il resto.
2.1 - I sistemi Grid
Il termine “Griglia” è stato coniato intorno alla metà degli anni Novanta. Il vero e specifico problema
alla base del concetto di Griglia è la condivisione coordinata di risorse all’interno di una dinamica e
multi-istituzionale organizzazione virtuale (Virtual Organization, brevemente indicata con VO). La
condivisione non è limitata solo allo scambio dei file, ma si estende all’accesso diretto a computer,
a software, in generale a tutto l’hardware necessario alla risoluzione di un problema scientifico,
ingegneristico o industriale. Gli individui e le istituzioni, che mettono a disposizione della griglia le
loro risorse per la medesima finalità, fanno parte della stessa VO. Caratteristica comune dei
progetti Grid è la necessità di disporre un ambiente di calcolo data-intensive, all’interno del quale le
applicazioni hanno il bisogno di accedere a grandi quantità di dati geograficamente distribuiti in
maniera veloce ed affidabile e far operare tali applicazioni nel miglior modo possibile. È facile
osservare che nessun computer attualmente in commercio sarebbe in grado, da solo, di elaborare
simili moli di dati in tempi ragionevoli; tuttavia la condivisione di risorse quali CPU e dischi
opportunamente coordinati può dare l’impressione all’utente di accedere ad un supercomputer
virtuale, con una incredibile potenza computazionale e capacità di memorizzazione in grado di
sopportare grandi carichi di lavoro. Dall’idea di far apparire tutta l’architettura di un Grid come un
unico supercomputer virtuale, celando all’utilizzatore tutta la complessità interna e mostrandogli
solo i benefici, nasce l’esigenza di progettare e realizzare uno schedulatore di risorse Resource
Broker. Esso è uno dei componenti critici del sistema di gestione delle risorse, ha il compito di
assegnare le risorse ai job (Gridlet), in modo da soddisfare le esigenze delle applicazioni e del
sistema. Le risorse di cui esso deve tenere traccia e gestire includono sistemi di calcolo e sistemi
di immagazzinamento dati (mediante lo Storage Broker, rete di interconnessione e, tramite il
Network Monitor). Lo scheduling è un campo tradizionale dell’informatica, ma nonostante siano
state studiate molte tecniche per numerose tipologie di sistemi (da uniprocessore a
multiprocessore ai sistemi distribuiti), le caratteristiche tipiche delle griglie di dati rendono molti di
questi approcci inadeguati. Infatti, mentre nei sistemi tradizionali le risorse e i job sono sotto il
diretto controllo dello schedulatore, le risorse delle griglie sono geograficamente distribuite. Queste
ultime sono di natura eterogenea e, appartengono a diversi individui o organizzazioni, ciascuna
con le proprie politiche di scheduling, modelli di costo di accesso differenti, carichi di lavoro e
disponibilità di risorse che varia dinamicamente nel tempo. La mancanza di un controllo
centralizzato, insieme alla presenza di utenti che generano job (Gridlet), molto diversi l’uno
dall’altro, rendono la schedulazione più complicata rispetto a quella dei sistemi di calcolo
tradizionali.
2.2 - Tipologie di grid computing
Esistono vari tipi di grid, che si differenziano per tipologia di condivisione. La prima categoria di
riferimento è quella computazionale, ovvero quella che mette in relazione computer server o
porzioni di server (cluster), aumentando in maniera considerevole le prestazioni nel calcolo. Le
simulazioni nucleari sfruttano proprio questo tipo di modello, e non è un caso che in paesi come gli
Stati Uniti, i test reali siano stati abbandonati per far posto alle versioni simulative. La seconda
categoria è quella della condivisione dei dati, dove un unico centro dispone dell'archivio dati e tutti
12
gli altri si preoccupano solo della loro elaborazione. Il progetto grid legato al nuovo acceleratore di
particelleLHC (Large Hadron Collider) del Cern sfrutterà ampiamente questo metodo. L'Istituto di
Ricerca Europeo per il Nucleare e il Cern sembrano voler riprodurre le collisioni fra le particelle più
elementari che hanno dato inizio al Big Bang. L'obiettivo comune è quello di riuscire a
memorizzare ed integrare un petabyte di dati(un milione di gygabyte) - ha spiegato Wolfgang von
Ruden, Capo della Divisione IT del CERN - per poi favorirne l'elaborazione, grazie ai sistemi di
Grid Computing. IBM SW DiscoveryLink, applicato alla Fisica, ha sconvolto la dinamica della
seconda categoria, invertendo i compiti: numerosi nodi del network si occupano della creazione dei
dati ed un unico centro dell'elaborazione degli stessi. La terza categoria, invece, prevede la sola
condivisione degli strumenti analitici fra i vari partecipanti. Malgrado il mercato informatico dimostri
ogni giorno quanto la questione compatibilità sia fondamentale per le comunicazioni o le
trasmissioni di dati, il grid computing è un esempio di come sia possibile superare agevolmente
questo tipo di problemi quando si pone un obbiettivo comune. Attualmente vi sono numerose
tecnologie che permettono il superamento delle diversità hardware e software come: ..Condor,
Unicore, Legion, Globus, etc. Il progetto Condor, ad esempio, sviluppato dall'università del
Wisconsin-Madison, coinvolge circa 1000 workstation e più di 600 personal computer ogni giorno.
2.3 - Un po' di storia
Si possono identificare quattro “ere” (schematizzate nella tabella seguente) caratterizzate da
distinte metodologie e architetture dedicate al supercalcolo.
Era
Relazione tra calcolatori
e utenti
Architettura
di condivisione
Architetture
di super calcolo
Anni ’70
Uno a molti
Sistemi Time sharing
Supercalcolatore
Anni ’80
Uno a uno
PC e Workstation
Supercalcolatore
Anni ’90
Molti a uno
Clusterizzazione
COW
Terzo millennio
Molti a molti
Grid
Grid
La prima era è caratterizzata dal concetto “un computer per molti utenti”. In questa era il costo
della singola risorsa di calcolo è tale da essere accessibile solo a entità grandi, in grado di
ammortizzare l’investimento attraverso l’uso contemporaneo della risorsa da parte di numerosi
utenti.
2.3.1 - Dal Supercalcolatore al Cluster di Workstation
Il passo successivo viene preannunciato dal colpo di coda della Thinking Machine Corporation. Nel
1993, dopo un decennio di ardito pionierismo nel campo delle architetture SIMD, per tentare di
salvare un futuro che, sfumati i grandi finanziamenti militari per la guerra fredda, appare assai
oscuro, tenta la produzione della Connection Machine 5, un supercalcolatore basato
sull’interconnessione tramite una struttura proprietaria di pochi, potentissimi2 processori
mainstream: gli SPARC prodotti da SUN. I costi di produzione del sistema restano comunque
troppo alti a causa delle molte componenti altamente customizzate, quali per esempio la rete di
interconnessione dei processori, ancora presenti nell’architettura, e l’esperimento risulta, quindi,
economicamente fallimentare. Nel 1994, presso l’università di Stanford, il progetto Beowulf inizia
una nuova fase sottolineando con forza il concetto di architettura basata su Components Off The
Shelf (COTS) o Commodity Computing (CC). Questo concetto di Commodity Computing, cioè di
calcolo come servizio di base, è figlio dell’alleanza Intel/Microsoft che negli anni ’90 porta alla
13
realizzazione della visione “Un PC su ogni scrivania”. Infatti, tra le caratteristiche che rendono
particolarmente significativo il primo cluster Beowulf non vi sono performance di picco o peculiarità
architetturali, ma bensì:
•
l’uso come nodi computazionali di macchine comparabili con quelle destinate all’office
automation (PC con processore Intel DX4);
•
l’uso come tecnologia di interconnessione tra i nodi dello standard di rete progettato per
l’office automation (ethernet);
•
l’uso di un sistema operativo open source di uso generale, non specificamente progettato
per il calcolo ad alte prestazioni (Linux o FreeBSD).
Nella seconda metà degli anni ’90, nel mondo del calcolo ad alte prestazioni la ricerca verte in
larga misura su architetture cluster, cluster di workstation (COW) e cluster di PC4, cioè architetture
caratterizzate dall’aggregazione statica di nodi di computazione dedicati completamente
all’architettura cluster e interconnessi tramite un’interfaccia di rete di tipo standard. È fondamentale
notare che, tra la fine degli an- ni ’80 e l’inizio degli anni ’90, il processo che culmina con
l’affermazione dei concetti COTS e CC segna un cambiamento sostanziale nella ricerca dedicata
ai sistemi di calcolo. Se nel precedente ventennio tale ricerca era stata orientata principalmente
all’hardware, essa diventa ora sostanzialmente orientata al software. Infatti, anche lo sviluppo di
sistemi per il calcolo ad alte prestazioni risulta essere principalmente mirato alla definizione di
strati software (middleware5) atti a mascherare l’eterogeneità delle risorse di calcolo costruendo in
modo più o meno marcato una Single System Image. Per i sistemi cluster di tipo Beowulf, il livello
di SSI è dato fondamentalmente da:
•
la possibilità di compilare un programma eseguibile sull’intero sistema cluster;
•
la possibilità di schedulare l’esecuzione di un’applicazione su tutti o un sottoinsieme dei
nodi del cluster tramite un sistema batch;
•
la possibilità di monitorare ed eventualmente abortire le applicazioni in esecuzione.
2.3.2 - Dal Cluster al Grid
L’inizio del passo successivo è segnato, nel 1996, da una fioritura di progetti mirati a definire
sistemi per il metacomputing6. I sistemi di metacomputing possiedono molte caratteristiche in
comune con i sistemi cluster, infatti, come questi ultimi, essi sono gruppi di nodo computazionali di
tipo standard interconnessi tramite interfacce di rete di tipo standard. Tuttavia, esse possiedono in
sè le caratteristiche seminali del concetto di Grid Computing, ovvero definiscono “sistemi formati
dall’aggregazione dinamica di nodi computazionali non dedicati al metacomputer, interconnessi
anche attraverso Internet e appartenenti a domini di sicurezza e gestione non omogenei”. In
tabella 2 sono schematizzate le principali differenze tra un sistema cluster e un sistema per il
metacomputing. Per due anni, il termine metacomputer o sistema di metacomputing viene
utilizzato per rappresentare tutte le strutture di calcolo formate da nodi eterogenei distribuiti su
Internet. Persino il progetto Globus, negli articoli pubblicati sino all’inizio dell’anno 1998 viene
descritto dai suoi autori “Un toolkit per un’infrastruttura di metacomputing” . Tuttavia, tra l’inizio del
1998 e la prima metà del 1999, Ian Foster e Carl Kesselmann, i padri del progetto Globus,
pubblicano la loro visionaria metafora di una “Griglia di distribuzione della potenza computazionale
in cui, come i watt nella griglia di distribuzione dell’elettricità, la potenza computazionale può
essere distribuita a chi ne fa richiesta senza badare alla sua provenienza”. Questa futuristica
visione ha un immediato successo e viene adottata dalla comunità scientifica sostituendo il termine
metacomputing.
14
2.3.3 - Evoluzione del Grid computing
Il progetto SETI@home, lanciato nel 1999 da Dan Werthimer, è un esempio molto noto di un
progetto, seppur semplice, di Grid computing. SETI@Home è stato seguito poi da tanti altri
progetti simili nel campo della matematica e della microbiologia. Attualmente, la più importante grid
europea è quella del CERN di Ginevra che ora si chiama EGEE (gLite è il nome del middleware
che produce; precedentemente LCG e prima ancora DataGrid), sviluppata - tra gli altri - da un
team italo-ceco e prevalentemente presso l'INFN, l'Istituto Nazionale di Fisica Nucleare. A
differenza di quella utilizzata da SETI@Home, attualmente una grid viene concepita prevedendo
un livello di middleware fra le risorse di calcolo e memoria ( CE - computing element e SE storage element) e gli utenti della grid stessa. Lo scopo principale del middleware è quello di
effettuare il cosiddetto match-making, ossia l'accoppiamento tra le risorse richieste e quelle
disponibili in modo da garantire la distribuzione dei job (termine utilizzato nei sistemi batch per
indicare un o una parte di esso) nelle condizioni migliori avendo sempre visibilità dello stato
dell'intera grid.
Un altro importante fenomeno da evidenziare è la nascita accanto alle grandi GRID nazionali ed
internazionali, di molteplici implementazioni su scala locale o metropolitana di sistemi distribuiti che
mantengono le caratteristiche di una GRID. Tali sistemi vengono indicati con i termini Local Area
Grid (LAG) e Metropolitan Area Grid (MAG) o, più semplicemente, Metropolitan Grid con chiaro
riferimento alla classificazione introdotta nell'ambito del network. Come la coordinazione di Grid
nazionali prevede la futura costituzione di un world wide Grid, le implementazioni di locali o di Grid
Metropolitane si avvicinano al mondo delle Intranet . Esse infatti forniscono un tipo di infrastuttura
che può essere usata più semplicemente di internet per l'introduzione del calcolo distribuito in
ambito aziendale. L'organismo di riferimento per lo sviluppo di omogeneità e standard dei protocolli
usati dalle grid è GGF (Global Grid Forum), che ha creato gli standard OGSA ( Open Grid Services
Architeture). Nel 2004 è stato emanato WSRF (Web Services Resource Framework), che è un
insieme di specifiche per aiutare i programmatori a scrivere applicazioni capaci di accedere alle
risorse Grid. Oggi il software più famoso ed utilizzato è BOINC, un software di Grid Computing
sviluppato dall'Università della California (Berkeley). La sigla BOINC infatti sta per Berkeley Open
Infrastructure for Network Computing. Questo software è open source.
2.4 - Il modello dei servizi OGSA
Il modello dell’architettura Grid segue un approccio service-oriented, cioè
“Everything is represented by a Service: a network enabled entity that provides some capabilities
through the exchange of messages.”
Risorse computazionali, di storage, reti, programmi, database, etc, sono tutti dei servizi (Grid
Services)
Grid service: “a web service that conforms to a set of conventions and supports standard
interfaces, where each interface defines a set of operations that are invoked by exchanging a
defined sequence of messages”
I livelli principali che l’architettura OGSA abbraccia sono 4:
Il livello più basso comprende le risorse di base come processori, storage system, network
subsystems, e componenti che mirano al loro controllo. Principalmente queste risorse sono rese
visibili alla struttura OGSA aggiungendo funzionalità all’infrastruttura software. Ciò è al fine di
“virtualizzare o astrarre” l’hardware e le risorse del sistema in termini di servizi.
15
Il subito sopra questi elementi c’è un livello
livello di funzioni come file system, database, software per il
messaging, directory, etc che sono tipicamente implementate come un middleware general
purpose. Questo middleware generalmente sfrutta il livello sottostante di risorse fisiche ed inoltre
fornisce funzioni che posso essere “astratte” e “virtualizzate” come servizi in OGSA
Come “Service Oriented Architecture” OGSA è fondamentalmente un’estensione dell’esistente ed
affermata infrastruttura dei Web Service definiti da standard come XML, WSDL, SOAP, etc.
etc OGSA
trae vantaggio dai server di applicazioni del middleware, che forniscono supporto allo sviluppo di
programmi.
2.5 - Grid Computers vs Mainframes
Le machine in una configurazione grid costano una frazione di quello che un super costano: meno
del 10%, se si usano microcomputer per combinarli in una griglia. La grande differenza con i
mainframes e i supercomputers è che una griglia o i cluster computer
computer è per lo più costruito da una
gran numero si computer indipendenti. Al massimo le macchine separate potrebbero lavorare da
sole. Un’altra grande differenza sta nel fatto che un computer grid o cluster può essere costruito da
computer di fascia bassa come le macchine Intel pentium. Se si combinano le macchine come IBM
RN6000's in una griglia o cluster si ottiene una gigantesca superpotenza. Un esempio di questo è
il Blue Gene, che ha battuto il campione del mondo di scacchi: Casparow nel 1998. In realtà una
un
griglia può facilmente trasformarsi in un supercomputer che è principalmente una combinazione di
computer paralleli o di una massiccia quantità di CPU montate su schede separate, come le
macchine Cray.
L’immagine sottostante è un esempio semplificato del
del principio delle machine grid.
Ogni singolo punto giallo rappresenta un computer; ogni computer ha un singolo task: sommare
due numeri. Il trucco sta nel fatto che, mentre c’è l'aggiunta di due numeri e che passa alla riga
successiva (2 + 2) la prima riga
ga può fare un nuovo calcolo di nuovo mentre l'altro è occupato. La
risposta definitiva non deve essere calcolata da un unico computer. Si vedrà anche che questo
tipo di calcolo è inutile quando si ha da fare soltanto qualche semplice somma.
La classifica di un computer grid, come si può comprendere può essere collocata in tutte le classi.
Infatti, la griglia può essere visto come l'evoluzione più recente e completo degli sviluppi più
familiari - come ad esempio il calcolo distribuito, il web, peer-to-peer
peer
r computing e le tecnologie di
virtualizzazione - :
16
•
Come il web, il grid computing mantiene complessità nascosta: più utenti possono godere
di un'esperienza unificata.
•
A differenza del Web, che consente principalmente la comunicazione, il grid computing
consente la piena collaborazione verso obiettivi di business comuni.
•
Come peer-to-peer, il grid computing consente agli utenti di condividere i file.
A differenza di peer-to-peer, il grid computing consente lo sharing molti-a-molti - non solo i
file di risorse, ma anche altri.
•
Come cluster e il calcolo distribuito, il grid consente di mettere insieme le risorse di
elaborazione.
•
A differenza di cluster e il calcolo distribuito, che hanno bisogno di vicinanza fisica e di
omogeneità di funzionamento, le reti possono essere geograficamente distribuite ed
eterogenee.
•
Come le tecnologie di virtualizzazione, il grid computing permette la virtualizzazione delle
risorse IT.
A differenza di tecnologie di virtualizzazione, il grid computing consente la virtualizzazione di vaste
e disparate risorse IT.
2.6 - Come lavora il grid computing
Al suo livello più elementare, il grid computing è una rete di computer in cui le risorse di ogni
computer sono condivise con tutti gli altri computer del sistema. La potenza di elaborazione, la
memoria e memorizzazione dei dati sono tutte le risorse della comunità che gli utenti autorizzati
possono sfruttare per compiti specifici. Un sistema di grid computing può essere semplice come un
insieme di computer simili in esecuzione sullo stesso sistema operativo o complesso come dei
sistemi inter-rete costituiti di tutte le piattaforme informatica che si possono pensare. Il concetto di
grid computing non è una novità. E' un tipo speciale di calcolo distribuito. Nel calcolo distribuito,
diversi computer all'interno della stessa rete condividono uno o più risorse. Nel sistema ideale di
grid computing, ogni risorsa è condivisa, trasformando una rete di computer in un potente
supercomputer. Con l'interfaccia utente giusta, accedere ad un sistema di grid computing non
avrebbe nulla di diverso dall’accedere alle risorse di una macchina locale. Ogni computer
autorizzato avrebbe accesso a un enorme potenza di elaborazione e capacità di memorizzazione.
Sebbene il concetto non è nuovo, esso non è ancora perfezionato. Gli studiosi di informatica,
programmatori e ingegneri stanno ancora lavorando per la creazione, la definizione e attuazione di
standard e protocolli. Adesso, molti sistemi di grid computing esistenti si basano su software e
strumenti proprietari. Quando la gente sarà d'accordo su una serie affidabile di standard e
protocolli, sarà più facile e più efficace per le organizzazioni adottare il modello di grid computing.
I sistemi di Grid computing funzionano secondo il principio delle risorse messe in comune. Un
sistema di grid computing utilizza il concetto di condividere il carico su più computer per
completare le attività in modo più efficiente e veloce.
Normalmente, un computer può operare soltanto entro i limiti delle proprie risorse (cpu, memory e
storage). C'è un limite massimo di velocità nel completare un'operazione, o di quante informazioni
si possono memorizzare. La maggior parte dei computer sono aggiornabili, il che significa che è
possibile aggiungere più potenza o capacità in un singolo computer, ma questo è ancora solo un
aumento incrementale delle prestazioni. I Sistemi di Grid computing collegano le risorse del
computer in modo da permettere che qualcuno utilizzi un computer per accedere e sfruttare la
17
potenza raccolta di tutti i computer del sistema. Per il singolo utente, è come se il computer
dell'utente sia trasformato in un supercomputer.
Molte aziende e organizzazioni stanno lavorando insieme per creare un set standardizzato di
regole chiamati protocolli per rendere più facile la creazione di ambienti di grid computing. E'
possibile creare un sistema di grid computing adesso e molti già sono esistenti. Ma ciò che manca
è un approccio concordato. Ciò significa che i due diversi sistemi di grid computing potrebbero non
essere compatibile con un altro, perché ognuno sta lavorando con un unico insieme di protocolli e
strumenti.
Il potenziale per le applicazioni di grid computing è illimitato, fornendo a tutti l’accordo su protocolli
e strumenti standardizzati. Questo perché, senza un formato standard, gli sviluppatori di terze parti
– ovvero programmatori indipendenti che vogliono creare applicazioni per la piattaforma di grid
computing - spesso non hanno la possibilità di creare applicazioni che lavorano su sistemi diversi.
Benchè è possibile effettuare diverse versioni della stessa applicazione per sistemi diversi, ciò
richiede tempo e molti sviluppatori non vogliono fare lo stesso lavoro due volte. Un insieme
standardizzato di protocolli significa che gli sviluppatori potrebbero concentrarsi su un unico
formato, durante la creazione di applicazioni.
2.7 - Preoccupazioni sul Grid Computing
Ogni volta che si collegano due o più computer insieme, bisogna prepararsi ad alcune domande.
Come si fa a mantenere riservate le informazioni personali? Come si fa a proteggere il sistema da
parte di hacker malintenzionati? Come si fa a controllare chi può accedere al sistema e utilizzare le
sue risorse? Come si fa a verificare che l'utente non impegna tutte le risorse del sistema?
La risposta più immediata a questa domanda è middleware. Non c'è nulla di insito in un sistema di
grid computing, che può rispondere a queste domande. I protocolli emergenti per i sistemi di grid
computing sono progettati per rendere più semplice agli sviluppatori creare applicazioni e facilitare
la comunicazione tra computer.
La tecnica più diffusa che gli ingegneri informatici utilizzano per proteggere i dati è la crittografia.
Crittografare i dati significare codificare in modo che solo chi possiede la chiave appropriata può
decodificare i dati e accedervi. Ironia della sorte, un hacker può pensare di creare un sistema di
grid computing allo scopo di cracking di informazioni criptate. Dato che l’uso delle tecniche di
crittografia per codificare i dati sono complicate, per un normale computer ci vorrebbero diversi
anni per ‘crackare’ un codice (che di solito consiste nel trovare i due più grandi divisori principali di
un numero incredibilmente elevato). Con un sistema di grid computing abbastanza grande, un
hacker potrebbe trovare un modo per ridurre il tempo necessario per decifrare i dati crittografati. E'
difficile proteggere un sistema dagli hackers, in particolare se il sistema si basa su standard aperti.
Ogni computer in un sistema di grid computing deve avere un software specifico per essere in
grado di connettersi e interagire con il sistema nel suo complesso - i computer non sanno come
fare per conto proprio. Se il software del sistema informatico è proprietario, potrebbe essere più
difficile (ma non impossibile) per un hacker accedere al sistema. Nella maggior parte dei sistemi
grid della rete, solo alcuni utenti sono autorizzati ad accedere alla piena funzionalità della rete. In
caso contrario, il nodo di controllo sarebbe inondato di richieste di trattamento e non succederebbe
niente (una situazione di stallo chiamato deadlock). È anche importante limitare l'accesso per
motivi di sicurezza. Per tale motivo, la maggior parte dei sistemi sono dotati di protocolli di
autenticazione e autorizzazione. Questi protocolli limitano l’accesso alla rete ad un numero
selezionato di utenti. Gli altri utenti possono accedere ai propri macchinari, ma non possono
sfruttare l'intera rete. Il middleware e il nodo di controllo di un sistema di grid computing sono
18
responsabili di mantenere il sistema senza intoppi. Insieme, hanno il controllo di quanto ogni
computer dispone delle risorse della rete e viceversa. Mentre è importante non lasciare che uno
qualsiasi dei computer domini la rete, è altrettanto importante non lasciare che le applicazioni di
rete prendano tutte le risorse di un qualsiasi computer. Se il sistema sottrae agli utenti risorse di
calcolo, non è un sistema efficiente.
COMPARISON OF MIDDLEWARE TECHNOLOGIES
Middleware
UNICORE
Globus
Legion
Gridbus
Focus
High level
Programming
models
Low level services High level
Programming
models
Abstractions and
market models
Category
Mainly uniform
job submission
and monitoring
Generic
computational
Generic
computational
Generic
computational
Architecture
Vertical multi
tiered system
Layered and
modular toolkit
Vertically
Layered
integrated system component and
utility model
Implementation
Abstract Job
Object
Hourglass model
at system level
Object-oriented
metasystem
Hourglass model
at user level
Java
C and Java
C++
C, Java, C# and
Perl
Runtime Platform Unix
Unix
Unix
Unix and Windows
with .NET
Programming
Environment
Replacement
Legion
libraries for Unix & Application
C libraries.
Programming
Special MPI library Interfaces (API).
(MPICH –G), CoG
(Commodity Grid) Command line
utilities
kits in Java,
Python, CORBA,
Matlab, Java
Server Pages, Perl
and Web Services
Property
Model
Implementation
Technologies
Workflow
environment
Some Users and EuroGrid], Grid
Applications
Interoperability
Project,
OpenMolGrid
AppLeS, Ninf],
Nimrod-G, NASA
IPG, Condor-G,
Gridbus Broker,
19
Broker Java API
XML-based
parameter-sweep
language
Grid Thread model
via Alchemi.
NPACI Testbed, ePhysics, Belle
Nimrod-L, and
Analysis Data
Grid], NeuroGrid],
NCBioGrid.
Additionally, it has Natural Language
and Japanese
NAREGI.
UK eScience
been used in the
Project], GriPhyN], study of axially
and EU Data Grid. symmetric steady
flow and protein
folding
applications.
Engineering,
HydroGrid, and
Amsterdam Private
Grid].
2.8 - Le applicazioni grid computing più importanti
Il grid computing ha guadagnato l'onore delle cronache online quando nel Web si è iniziato a
parlare del progetto SETI@home. Il fascino legato all'argomento ha naturalmente contribuito
nell'alimentare l'interesse dei normali utenti, che sino ad un paio di anni fa sapevano ben poco
delle strategie per la condivisione del computing. SETI (Search for Extraterrestrial Intelligence)
sfrutta il processing di migliaia di personal computer, che dispongono di una piccola applicazione,
facilmente scaricabile dal sito ufficiale, in grado di attivare la condivisione online. Il programma
SETI@home è una specie di screensaver che durante l'inattività del computer permette l'analisi
dei dati in network elaborate dal più grande telescopio del mondo. Lo spettro radio catturato dal
telescopio ha bisogno di una gran quantità di processing, ottenibile a basso costo solo ed
esclusivamente con il sistema grid. Con questo tipo di applicazione, compatibile con tutti i sistemi
operativi, la ricerca di forme extraterrestri sembra aver guadagnato preziosi alleati: i singoli utenti
della Rete. L'Università della South Carolina, con la collaborazione dall'Argonne National
Laboratory, ha spinto oltre il concetto di grid computing, applicato alla dimensione scientifica, con
lo sviluppo di Globus, un toolkit per l'implementazione di nuove applicazioni grid. Ogni componente
del pacchetto software dispone di API (application programmer interface), fondamentali per i
programmatori di software. La disponibilità in Open Source di questo kit ha permesso inoltre al
Datagrid del Cern, sotto l'egida della comunità Europea, di dare vita ad un progetto di grid che
coinvolge tutti gli enti di ricerca più importanti del Vecchio Continente.
Non è un caso che la Nasa, The National Computational Science Alliance, The Network for
Earthquake Engineering Simulation Grid e numerose università abbiano utilizzato proprio questo
tipo di piattaforma per la realizzazione dei propri progetti di condivisione di computing. IBM sembra
essere l'azienda privata più attiva nel settore, tanto più che il suo servizio di capacità di calcolo a
distanza è già stato acquistato da numerose imprese, come la Shell e la Kansei Electric Power;
l'azienda statunitense inoltre ha recentemente annunciato la prossima commercializzazione di
pacchetti espressamente sviluppati per i settori agrochimici, petrolchimici e di engineering applicati
ai circuiti. Questa è la dimostrazione evidente che nel settore business l'innovazione del grid
computing può affermarsi come nuovo standard di riferimento non solo nel campo della ricerca e
sviluppo, ma anche nella normale gestione di tutti i processi che coinvolgono un'azienda moderna.
2.8.1 - La dimensione business
Un altro campo di riferimento sembra essere quello dell'intrattenimento videoludico online.
Buttery.net ha reso disponibile in commercio la sua personale piattaforma grid per il settore dei
MMG (Massively multiplayer games), ovvero quei videogiochi che sfruttano le potenzialità del Web
per permettere il gioco in contemporanea di centinaia di utenti. Grazie a questa tecnica il numero
dei giocatori giocanti, in un'unica sessione, può essere decisamente aumentato, senza per questo
inficiare le prestazioni di latenza, un dato fondamentale per la gestione fuida degli eventi di gioco.
Normalmente, infatti, gli ambienti virtuali utilizzano un certo numero di server che integrano i dati
20
dei singoli computer connessi, limitando però la quantità dei giocatori. Grazie alla grid di Butterfly si
creano, invece, delle sentinelle crossserver,che supportano tutte le azioni dei personaggi, così da
sgravare l'intero sistema e permettere la creazione di mondi virtuali di gioco con milioni di utenti.
L'ultima applicazione degna di nota, che proprio in questi ultimi mesi sembra aver coinvolto
migliaia di utenti riguarda il progetto Grub di LookSmart, che grazie al grid computing permetterà la
creazione del più grande motore di ricerca del Web e allo stesso tempo la composizione del più
aggiornato archivio di pagine Web. Certamente ci vorrà del tempo per raggiungere le 10 miliardi di
pagine che sono presenti su Internet, ma con l'aumento della comunità, che ammonta già a più di
un migliaio di utenti, l'obbiettivo finale dovrebbe essere vicino. La sfida per il futuro è aperta, come ha sottolineato durante un'intervista Ian Foster, docente presso la Chicago University e
responsabile del progetto Globus - ma i problemi non mancheranno. Come è successo per il Web,
le rivoluzioni in questo settore non mancheranno: è assai probabile che nei prossimi anni si assista
ad un radicale cambiamento sia degli strumenti di programmazione, che delle applicazioni da
implementare. Per ora Global Toolkit 3.0 è disponibile con una licenza che non ha restrizioni di
sorta per l'utilizzo; - ha aggiunto Foster - se il Web permette la condivisione delle informazioni, il
grid computing permette la vera condivisione delle risorse.
2.8.2 - Il Grid Computing in aiuto contro i tumori infantili
Nuova iniziativa del World Community Grid: lo scopo è di trovare il trattamento farmacologico per il
neuroblastoma, causa di morte comune nei bambini affetti da tumori solidi. IBM e i ricercatori
giapponesi del Chiba Cancer Center Research Institute e della Chiba University hanno unito le
forze nel progetto "Help Fight Childhood Cancer", come iniziativa del World Community Grid, che
ha lo scopo di trovare il trattamento farmacologico per il neuroblastoma, la causa di morte più
comune nei bambini affetti da tumori solidi. La causa della patologia non è nota anche se la
maggior parte dei medici ritiene che sia imputabile alla crescita cellulare accidentale durante lo
sviluppo dei gangli simpatici e del surrene.
Il neuroblastoma colpisce più spesso entro i primi due anni di vita e presenta un rischio elevato di
recidiva, con tassi di sopravvivenza inferiori al 40 percento.I rapidi progressi della ricerca genetica
compiuti presso il Chiba Cancer Center Research Institute si dimostrano molto promettenti per il
suo trattamento. Similmente agli altri progetti sostenuti dal World Community Grid, "Help Fight
Childhood Cancer" utilizza la potenza di calcolo inattiva dei computer messi a disposizione dai
volontari incanalandola nell'identificazione di quale farmaco, fra i tre milioni potenzialmente utili,
può impedire la crescita di tre proteine a cui si deve la progressione della malattia. Questo progetto
potrebbe contribuire a creare sistemi sanitari più intelligenti, fornendo migliori trattamenti
farmacologici in grado di consentire agli individui di personalizzare o di effettuare terapie e piani di
trattamento più mirati. Il Dr. Akira Nakagawara, ricercatore presso il Chiba Cancer Center
Research spiega: "Se procedessimo facendo unicamente ricorso alle nostre risorse di calcolo
occorrerebbe circa un secolo per ottenere progressi: al contrario, con l'accesso a uno dei più
grandi supercomputer virtuali del mondo, stimiamo di completare la ricerca in 2 anni e di iniziare
poi le sperimentazioni di laboratorio". Il Dr. Nakagawara è stato recentemente insignito del
Princess Takamatsu Cancer Research Fund Prize 2008 per le ricerche sul neuroblastoma. Nel suo
lavoro ha scoperto che una proteina, la TrkB, viene espressa a livelli elevati nei neuroblastomi
aggressivi e favorisce la crescita delle cellule tumorali. Il World Community Grid permetterà di
condurre simulazioni chimiche complesse dei farmaci candidati, per scoprire quali si legano alle tre
proteine TrkB, ALK e SCxx, in modo tale da approfondire i test in laboratorio. Tutti i risultati
saranno messi a disposizione della comunità scientifica, per promuovere il campo della biologia
oncologica e la scoperta di nuovi farmaci.
21
Il World Community Grid - lo ricordiamo - è una grande rete pubblica umanitaria, forte di oltre
430.000 membri che rappresentano oltre 200 paesi e collegamenti a più di 1,2 milioni di computer.
Recentemente ha fornito 250 milioni di risultati, poco meno di 2 risultati ogni secondo. Sono i
volontari che aiutano a fare la differenza, perché quando ciascuno condivide il proprio tempo di
calcolo, gli scienziati sono in grado di condurre le loro ricerche più rapidamente. Per entrare a far
parte del World Community Grid e donare tempo di calcolo inutilizzato, i soggetti possono
registrarsi su www.worldcommunitygrid.org e installare sui propri computer (con Windows, Linux o
Mac OS X) un piccolo software gratuito. Quando i computer sono inattivi, i dati vengono richiesti
dal server del World Community Grid. Questi computer eseguono quindi i calcoli e rinviano i
risultati al server, rendendosi poi disponibili per un nuovo compito.
2.8.3 - Una tassonomia del fenomeno Grid
Secondo la definizione del progetto Globus, uno dei primi, più importanti e, dal punto di vista dei
finanziamenti ottenuti, più fortunati progetti relativi al Grid Computing, “Le Grid sono ambienti
persistenti che rendono possibile realizzare applicazioni software che integrino risorse di
strumentazione, di visualizzazione, di calcolo e di informazione che provengono da domini
amministrativi diversi e sono geograficamente distribuite”. La definizione di Grid si basa, quindi, sul
concetto di condivisione di risorse di diverse tipologie e si presta, quindi, a categorizzare diverse
tipologie di Grid: le Grid computazionali, le Grid di dati, le Grid di applicazioni e servizi, le Grid di
strumentazione e, infine, le Grid di sensori. Una Grid computazionale è l’aggregazione di risorse di
calcolo provenienti da domini di sicurezza e gestione differenti. Tale aggregazione è finalizzata a
fornire a un insieme di utenti potenza di calcolo on-demand, in modo disaccoppiato dalla
provenienza, cioè dai nodi che la stanno fisicamente fornendo. Si consideri, ad esempio, il caso di
una società multi- nazionale con sedi sparse in tutto il mondo. Ognuna di queste sedi possiede,
oggi, un parco di architetture di calcolo dimensionato o secondo un worst-case, dimensionato cioè
per soddisfare non le necessità medie ma i picchi di richiesta, oppure dimensionato per soddisfare
le necessità medie e, quindi, non in grado di gestire le situazioni di picco.
Una struttura Grid in grado di sopperire alle richieste di picco con potenza computazionale
proveniente dalle altre sedi della società permetterebbe di dimensionare in modo più consono alle
reali necessità quotidiane il parco macchine realizzando così un notevole risparmio. Allo stesso
tempo, lo stesso meccanismo di raccolta della potenza di calcolo sull’intero insieme delle risorse di
calcolo della società permette di realizzare un supercalcolatore disponibile dinamicamente nel
momento del bisogno. Le Grid computazionali, rappresentando una linea evolutiva delle
architetture di calcolo, hanno una storia particolarmente ricca e variegata.
Le Grid di dati possono essere considerate una delle forme evolutive del Web. Infatti, come il Web,
nascono per contenere grandi moli di dati distribuite in domini differenti per gestione e posizione
geografica. A differenza del Web, dove, pur data la ricchezza delle informazioni presenti,
mancano sia meccanismi espliciti di standardizzazione dei significati associati a queste
informazioni, sia strumenti di elaborazione concorrente delle informazioni ottenute, le Grid di dati
coniugano la ricchezza delle sorgenti con gli stru- menti adatti a far sì che le informazioni presenti
possano essere facilmente correlate e vengano, quindi, a dotarsi di un alto valore aggiunto rispetto
al mero contenuto. Si consideri, a titolo di esempio, il caso delle basi di dati contenenti i casi clinici
dei singoli ospedali nel mondo. Ognuno di queste basi di dati possiede, già presa singolarmente,
un fortissimo valore in quanto permette di analizzare quali siano state nel passato le decisioni dei
clinici. Tale valore però, aumenta in modo non lineare se, aggregando le basi di dati in una Grid di
dati, si rende possibile analizzare, confrontare e correlare le decisioni prese da clinici di scuole
diverse in presenza di patologie uguali o, quantomeno, comparabili.
22
Le Grid di applicazioni e/o servizi, rappresentano una delle visioni più futuribili nel campo del Grid
Computing. Esse, infatti, non si limita- no a essere una versione globalizzata all’intera Internet del
concetto di Application Service Provider (ASP), cioè della possibilità di affittare un certo tempo di
esecuzione di una specifica applicazione su di un server remoto, ma contemplano anche la
aggregazione di componenti applicativi sviluppati indipendentemente al fine di realizzare nuove e
originali applicazioni. Si consideri, a titolo di esempio, il seguente caso. La costruzione di una nave
è un processo che ormai non coinvolge più il solo settore cantieristico in senso stretto, ma, al
contrario, richiede l’intervento di un largo insieme di fornitori dedicati ai singoli sottosistemi. Lo
sviluppo di tali sottosistemi, per esempio la parte motoristica, la parte di stabilizzazione o la parte
dedicata alla sensoristica di navigazione, viene affidato esternamente all’ente cantieristico
nominalmente responsabile della costruzione navale. In uno scenario tradizionale, ognuno di
questi fornitori ha una visione limitata al sottosistema di cui è incaricato e si viene così a perdere la
visione olistica del prodotto finale sino al momento in cui, ottenuti tutti i singoli sottosistemi dai
diversi fornitori, l’ente cantieristico sarà in grado di assemblare il prodotto finito. Questo non
permette di valutare all’interno del loop di progettazione gli effetti dovuti alle interazioni tra i diversi
sottosistemi, e rischia, quindi, di portare a scoprire indesiderati effetti collaterali solo in fase di
collaudo dell’intero sistema. Una soluzione a questa empasse è ottenibile tramite l’integrazione in
una Grid di applicazioni di elementi simulativi relativi ai diversi sottosistemi. Tuttavia, elementi
simulativi sviluppati secondo lo standard internazionale attuale, cioè (HLA) High Level
Architecture, non supportano l’assemblaggio dinamico a run-time di un sistema completo, hanno
un supporto limitato per l’esecuzione distribuita e non permettono di schermare completamente
agli altri utenti i dettagli interni al componente. Al contrario, una Grid di applicazioni deve
permettere a ciascun fornitore:
•
di mantenere il pieno controllo del componente simulativo relativo al suo prodotto;
•
di esporre solo un’interfaccia opaca;
•
di assemblare l’intero sistema nave in una simulazione completa.
In una situazione di questo genere, ovviamente, una Grid di applicazioni sussume al suo interno
sia una Grid computazionale che una Grid di dati. Infatti, le risorse di calcolo utilizzate per eseguire
i diversi componenti applicativi sono aggregate dinamicamente a partire da domini di gestione
diversi. Contemporaneamente, i dati su cui si trova a operare l’applicazione complessivamente
costruita provengono da sorgenti differenti e sono correlate tramite l’esecuzione coordinata delle
componenti applicative.
Una Grid di strumentazione consiste nella generalizzazione del concetto di accesso remoto ad
apparati di costo elevato o per rendere fruibile in forma remota un setup sperimentale di elevato
valore didattico. In una Grid di strumentazione, apparati gestiti da enti diversi possono essere
integrati per aggregare esperimenti complessi non possibili in nessuno dei singoli siti coinvolti nella
Grid o per condividere strumentazione didattica in modo da rendere disponibile a corsi di studi
afferenti ad atenei diversi una struttura condivisa per la realizzazione di esperimenti di comprovato
valore didattico.
Il concetto di Grid di sensori proviene, principalmente, dal mondo militare. In ambito militare, tale
concetto sta alla base della moderna teoria del combattimento come attività incentrata
sull’interconnessione delle componenti dell’esercito belligerante. In tale visione, infatti, si parla
della Grid di sensori come del livello atto a fornire la visione dettagliata dello stato corrente agli
agenti operativi e decisionali. Recentemente, tuttavia, l’idea di una Grid di sensori destinata a
fornire una visione dettagliata e a prova di guasto della situazione del campo è penetrata anche in
ambiti non militari quali quelli dell’agronomia e della salvaguardia del territorio. Si consideri, a titolo
23
di esempio, il caso di un insieme di sensori all’infrarosso sparsi per una foresta con lo scopo di
segnalare tempestivamente lo svilupparsi di focolai di incendio. L’integrazione delle informazioni
provenienti da un grande numero di sensori permette di effettuare una migliore separazione del
calore ambientale dal calore proveniente da un focolaio d’incendio e, quindi, garantisce una
consistente diminuzione della sensibilità del sistema ai falsi positivi. Le Grid di sensori, sono il
ramo del Grid Computing che maggiormente si avvicina al concetto di Ubiquitous Computing,
infatti, tutte le attività di ricerca dedicate a questa tipologia di Grid pongono una fortissima
attenzione alle pro-blematiche legate alle reti wireless, all’instradamento autonomo e alle reti
senza infrastruttura statica, cioè le cosiddette reti ad hoc.
2.9 - Programmare in parallelo
2.9.1 - Grid del Supercalcolo
Secondo la visione sponsorizzata dalla comunità del supercalcolo, una Grid computazionale
consiste nell’interconnessione dei supercalcolatori disponibili nei diversi centri al fine di realizzare
una struttura globale in grado di lanciare l’esecuzione dell’applicazione candidata su uno
qualunque dei supercalcolatori parte della Grid che sia in grado di fornire le risorse (CPU, memoria
e spazio disco) richieste dall’applicazione stessa. In tale visione, quindi, le applicazioni che devono
essere scritte per una Grid computazionale sono sostanzialmente le stesse che venivano scritte
per le architetture cluster in quanto la dinamicità del sistema Grid è, di fatto, limitata alla fase di
scelta del supercalcolatore su cui lanciare l’esecuzione. In questa situazione, quindi, le tecniche di
programmazione utilizzate sono quelle tradizionali dello scambio di messaggi e si basano,
fondamentalmente, sull’uso delle librerie derivate dal modello CSP quali PVM e MPI. Questa
soluzione implica un modello di applicazione con un accoppiamento stretto tra le sue varie parti e,
pur permettendo di ottenere livelli di prestazioni molto alti, pone vincoli tali da prevenire il completo
utilizzo della natura dinamica di una Grid computazionale. Inoltre, a meno di accettare degradi
prestazionali fortissimi, questo modello di applicazione richiede di ritagliare l’applicazione stessa
sulle caratteristiche del sistema di calcolo che, quindi, non può essere soggetto alle variazioni
dinamiche tipiche di una Grid computazionale. Infine, questo tipo di programmazione è
estremamente complessa e richiede una conoscenza approfondita delle problematiche proprie del
calcolo parallelo ad alte prestazioni. Quindi, pur essendo applicabile a una vasta gamma di
tipologie di applicazione, la generazione di una nuova applicazione secondo il paradigma di
scambio di messaggi o il trasporto di un’applicazione tradizionale allo stesso paradigma
computazionale richiede uno sforzo di ingegnerizzazione o reingegnerizzazione estremamente
elevato ed è affrontabile solo da un pool di programmatori esperti nelle problematiche proprie del
calcolo parallelo ad alte prestazioni. Per queste ragioni, questo tipo di soluzione, pur essendo già
disponibile sul mercato, è di fatto appetibile solo per la grande industria, quella che possiede al
suo interno uno staff IT di dimensioni tali da potersi permettere di addestrarne una parte in modo
specifico e di averne una parte considerevole dedicata allo sviluppo e alla manutenzione di
specifiche applicazioni.
2.9.2 - Grid “Montecarlo”
Una seconda visione delle Grid computazionali è quella pionierizzata da progetti quali
SETI@home e realizzata al presente nei sistemi di ditte quali Entropia o AVAKI o dei grandi
vendor di sistemi informatici citati all’inizio del presente articolo. In questa visione, un centro di
controllo della Grid computazionale gestisce l’allocazione di parti dell’esecuzione globale
dell’applicazione a nodi ottenuti dinamicamente in modo volontaristico, come nel caso di
24
SETI@home, o identificando nodi disponibili all’interno di una intranet aziendale, come nel caso
delle soluzioni commerciali. Le applicazioni generate in questo modo sono tutte di tipo Montecarlo,
realizzate con un modello di computazione farmer-worker ad accoppiamento ridotto. Questo tipo
di soluzione permette la creazione di nuove applicazioni o il trasporto di applicazioni pre-esistenti
verso piattaforme di tipo Grid computazionale con un costo di re-ingegnerizzazione piuttosto
basso. Essa, infatti, non richiede una conoscenza estremamente approfondita delle problematiche
proprie del calcolo parallelo ad alte prestazioni. Tuttavia, questa soluzione è adottabile solo per
una specifica categoria di applicazioni, quelle appunto basate su simulazioni di tipo Montecarlo o,
più in generale, quelle in cui è necessario eseguire una stessa sequenza di operazioni su di un
enorme insieme di dati o casi di test che possono essere ripartiti in sottoinsiemi processabili in
modo indipendente. L’indipendenza tra le diverse parti garantisce l’assenza di comunicazione tra i
nodi che eseguono le operazioni. Questo permette di trascurare i problemi che potrebbero essere
generati dall’eterogeneità delle interconnessioni tra i nodi della Grid computazionale e semplifica,
quindi, sensibilmente l’applicazione. Purtroppo, però, dati i vincoli sulla tipologia di applicazione
utilizzabile con questa soluzione, essa non è generalizzabile a un ampio bacino di utenza ed è
principalmente adottata per test di nuovi farmaci o ricerca di pattern all’interno di enormi moli di
dati come nei casi del progetto SETI o dell’analisi del genoma umano.
2.9.3 - Grid di Servizi
Una terza, nuova visione delle Grid computazionali, è quella di una Grid, orientata ai servizi, che
utilizzi la tecnologia dei Web Services. Questa visione viene formulata da alcuni progetti di ricerca
ed è stata formalizzata nella prima metà dell’anno 2002 dal progetto Open Grid Services
Architecture (OGSA), una joint venture tra IBM e il team del progetto Globus. Tale visione si
propone lo sviluppo di applicazioni capaci di utilizzare la tecnologia Grid-computing adottando un
paradigma di computazione multi-tier, basato su servizi con interfacce standardizzate. Nel modello
definito da OGSA, una Grid è sostanzialmente un’organizzazione virtuale in grado di permettere
e coordinare l’uso di risorse condivise. Al fine di realizzare questa visione, OGSA definisce tre
livelli di protocollo:
1. livello di connettività;
2. livello di controllo delle risorse;
3. livello di collettivizzazione delle risorse.
Il primo livello si occupa fondamentalmente di gestire la comunicazione tra le componenti della
Grid e il controllo degli accessi, sia da parte di utenti finali che da parte di altre componenti della
Grid, a ciascuna delle componenti stesse. Il secondo livello, si occupa di definire le necessità di
una richiesta ed effettuare un’associazione di tali necessità con le risorse atte a soddisfarle8. Il
terzo livello, infine, si occupa di coordinare l’utilizzo delle risorse condivise in modo da fornire un
servizio di gestione collettiva di tali risorse. Tale paradigma, facendo leva su tecnologie software
mainstream quali Web Services, Java2 Enterprise Edition e Microsoft.NET, risulta essere più
vicino alla sensibilità dei programmatori di applicazioni di tipo commerciale e presenta, quindi, una
minor difficoltà di adozione da parte delle piccole medie imprese. Una soluzione di questo genere,
pur dovendo sacrificare una parte dell’ottimalità prestazionale raggiungibile solo con paradigmi di
computazione dedicata alla computazione parallela quale quello di scambio di messaggi,
permetterebbe di rendere fruibile la tecnologia Grid-computing anche a ditte mediopiccole non
dotate di un gruppo di programmatori esperti nelle problematiche della computazione parallela.
Una soluzione di questo genere permetterebbe, quindi, di:
25
•
allargare il bacino di utenza della tecnologia Grid-computing rendendola disponibile non
solo alla grande industria ma anche alle PMI;
•
rendere disponibile alle PMI una potenza di calcolo decisamente superiore a quella
correntemente a loro disposizione senza per altro richiedere grossi investimenti in
hardware dedicato.
2.10 - Problemi aperti
Purtroppo, il lavoro iniziato dal progetto OGSA è ben lungi dall’essere completato. Si consideri, a
titolo di esempio, il caso del protocollo SOAP. Questo protocollo, è il protocollo di riferimento per
la trasmissione dati utilizzato dalle tecnologie Web Services e NET, tuttavia, le sue caratteristiche
lo rendono del tutto inadatto a situazioni che richiedano alti livelli di prestazioni. Per questa
ragione, il progetto OGSA ne suggerisce l’utilizzo soltanto per il livello di controllo delle risorse.
Tuttavia, sebbene siano in corso diversi studi per identificare quali protocolli possano sostituire
SOAP in ambienti ad alte prestazioni, tali studi sono ancora in fase sperimentale, quindi non
esiste, ad oggi, una soluzione unificante che possa essere suggerita all’interno di OGSA. I
modelli di programmazione per Grid computazionali disponibili sono, quindi, ad oggi, solo quello a
scambio di messaggi e quello farmerworker per applicazioni di tipo Montecarlo. Un secondo
problema aperto, è quello della gestione di un livello globale di eterogeneità all’interno delle risorse
presenti in una Grid computazionale. Come spiegato in precedenza, il meccanismo di
superamento del problema dell’eterogeneità e la costruzione di una SSI da super-imporre come
colla unificante al di sopra delle diversità. Il progetto Globus, lo standard de facto per la
costruzione di Grid di supercalcolo, ha definito un linguaggio di descrizione delle risorse che
permette di descrivere in modo univoco le pur differenti caratteristiche dei nodi presenti in una
Grid. Tuttavia, questa descrizione, seppure rappresenta una specie di SSI, si limita, di fatto, a
demandare alle singole applicazioni la gestione dell’eterogeneità. Sono in corso esperimenti
relativi alla costruzione
estemporanea di Grid computazionali a partire da un insieme
estremamente eterogeneo di risorse di calcolo, si consideri, per esempio, il caso di Flashmob
all’Università di San Francisco. Tuttavia, ad oggi, tutti i casi di successo per la costruzione di Grid
computazionali provengono esclusivamente da due categorie:
•
i casi in cui l’eterogeneità era resa innocua dalla natura stessa dell’applicazione (Grid
montecarlo);
•
i casi in cui l’eterogeneità viene limitata alla fase di identificazione delle risorse da usare al
tempo dell’esecuzione (Grid di supercalcolo).
Allo stesso modo, risulta irrisolto il problema di garantire un livello di qualità del servizio in
presenza di risorse che non solo sono eterogenee, ma cambiano la loro disponibilità nel tempo.
Infatti, se si escludono i due casi delineati sopra, ad oggi risulta praticamente impossibile garantire
un livello di qualità del servizio alle applicazioni in mancanza di una quantificazione minima e
massima delle risorse disponibili. In un ambiente dinamico come una Grid, un ulteriore livello di
complessità è dato dalla necessità di scoprire le risorse che si rendono via via disponibili. La
soluzione classica a questo tipo di problema è la realizzazione di un servizio di directory: tuttavia,
la maggior parte dei servizi di directory oggi disponibili si basano su architetture con server
centralizzato che, ovviamente, mal si prestano ad una struttura potenzialmente globale come una
Grid. Un esempio di directory globale e, in quanto completamente distribuita, estremamente
scalabile, viene dal Domain Name System (DNS). Tuttavia, l’architettura del DNS è progettata per
una frequenza di cambiamento dei dati presenti estremamente bassa, quindi non è in grado di
supportare un sistema Grid in cui le risorse possono comparire e scomparire molto in fretta. Si
26
consideri, a titolo di esempio, il caso di un nodo di computazione del sistema SETI@home. Esso
è, di fatto, un PC che, essendo rimasto inattivo per alcuni minuti, ha fatto partire lo screen saver.
Questo fatto, però, non fornisce alcuna garanzia sul prolungarsi della disponibilità della risorsa, al
contrario è altrettanto probabile che il proprietario, disturbato dalla partenza dello screen saver,
smetta di sognare ad occhi aperti e ricominci a utilizzare il suo PC. Per queste ragioni, le tecniche
di scoperta delle risorse che oggi vengono utilizzate per aggregare le Grid di supercalcolo non si
prestano a essere applicate a tipologie diverse di Grid e limitano, quindi, l’utilizzo di tale tecnologia
a poche situazioni particolari. Come dimostrato dal recente attacco orchestrato ai danni del
maggior sistema Grid degli Stati Uniti d’America, TeraGRID, il problema della sicurezza
rappresenta uno dei maggiori punti di vulnerabilità di un sistema massicciamente distribuito e
sottoposto a domini e regolamentazioni eterogenee come un sistema Grid. Ancora una volta, una
soluzione proviene dal progetto Globus. Tale progetto ha, infatti, definito una struttura di controllo
degli accessi alla Grid basata su Public Key Infrastructure (PKI) e un sistema di certificati standard
unico per l’intera Grid. Tuttavia, tale sistema si basa sulla reciproca fiducia tra le componenti
costitutive della Grid. Questo fatto ha in sè un fattore di rischio e una limitazione di uso. Il fattore di
rischio proviene dal fatto che, come dimostrato dall’attacco sopra citato, un sistema che assuma
la affidabilità di ogni sua componente è sicuro solo come la più debole delle sue componenti.
Quindi, nel caso di un sistema massicciamente distribuito tra diversi domini di gestione è
praticamente impossibile garantire un effettivo livello di sicurezza. La limitazione proviene dal fatto
che l’assunzione di fiducia completa di ogni componente una Grid in ogni altra componente taglia
fuori qualsiasi meccanismo volontaristico di acquisizione di risorse e, quindi, limita grandemente i
possibili usi della tecnologia. In particolare, ne limita la convergenza con il fenomeno del peer-topeer con il quale, al contrario, condivide il concetto fondamentale di condivisione dinamica di
risorse geograficamente distribuite.
27
3 - Grid Computing vs. Cluster Computing
Il grid computing è incentrato sulla capacità di sostenere il calcolo in domini amministrativi, si
distingue da cluster di computer tradizionali o tradizionali calcoli distribuiti. I Grid offrono un modo
di utilizzare le risorse informatiche in modo ottimale all'interno di un'organizzazione. In breve, si
tratta di virtualizzazione le risorse di calcolo.
Il grid computing è spesso confuso con il cluster computing. Dal punto di vista funzionale, si può
classificare i grids in diversi tipi: Griglie Computazionali (compresi i Grid CPU scavenging), che si
concentrano principalmente su operazioni di calcolo intensivo, e i data grids, o la condivisione
controllata e la gestione di grandi quantità di dati distribuiti.
Quando due o più computer vengono utilizzati insieme per risolvere un problema, si parla di cluster
di computer. Vi sono diversi modi di attuazione del cluster, Beowulf è forse il modo più conosciuto
per farlo, ma in fondo si tratta solo di una cooperazione tra i computer per risolvere un compito o
un problema. Cluster Computing è quindi solo la cosa che si fa quando si utilizza un cluster di
computer. Il grid computing è qualcosa di simile al cluster computing, si avvale di diversi computer
collegati in qualche modo per risolvere un problema di grandi dimensioni. C'è spesso una certa
confusione circa la differenza tra il grid e cluster. La grande differenza è che un gruppo è
omogeneo, mentre le grids sono eterogenee. I computer che fanno parte di un grid possono usare
diversi sistemi operativi e hanno hardware diversi considerando che i computer del cluster hanno
tutti lo stesso hardware e sistema operativo. Una griglia può usufruire di potenza di calcolo di
ricambio su un computer desktop, mentre le macchine in un cluster sono dedicate a lavorare come
una sola unità e nient'altro. I Grid sono intrinsecamente distribuiti, per sua natura in una rete LAN,
WAN o metropolitane. D'altra parte, i computer nel cluster sono normalmente contenuti in un unico
luogo o complesso.
Un'altra differenza sta nel modo in cui le risorse vengono gestite. In caso di cluster, l'intero sistema
(tutti i nodi) si comporta come un unico punto di vista del sistema e le risorse sono gestite da un
gestore delle risorse centralizzato. In caso di Grid, ogni nodo è autonomo cioè ha il suo gestore di
risorse proprie e si comporta come un’entità indipendente.
Grid rappresenta una struttura e un’architettura più grande, e si concentra sulla portata e obiettivi
più ampi. Grid incorpora molte risorse di calcolo e i cluster diventano spesso uno dei molti
componenti. Una griglia consente la condivisione, la selezione e l'aggregazione di una grande
varietà di risorse geograficamente distribuite tra i supercomputer, sistemi di storage, le fonti di dati
e dispositivi specializzati di proprietà di diverse organizzazioni per risolvere i grandi problemi ad
alta intensità di scala di risorse nel campo della scienza, dell'ingegneria e del commercio. I
clusters, d'altra parte, si concentrano su un obiettivo e uno scopo specifico, come un servizio di
database o un logic web application server. Questi cluster rientrano nell’architettura di rete molto
bene per una fondamentale condivisione di risorse ad un livello superiore di aggregazione. Con i
progressi tecnologici non può passare molto tempo prima che un gran numero di nodi (per
esempio, da 50 a 100 nodi) formino un cluster di database che incorpora una varietà di archivi di
dati consolidati in una fonte enorme di dati. Ciò può portare a una vera e propria griglia di dati di
diversi depositi supportati in un singolo cluster di grandi dimensioni.
28
Caratteristiche del Grid Computing
•
Basso accoppiamento (Decentralizzazione)
•
Diversità e dinamismo
•
Job Management & schedulino distribuiti
Caratteristiche del Cluster computing
•
Sistemi con forte accoppiamento
•
Immagine di un singolo sistema
•
Sistema di Job management & scheduling centralizzato
La tabella seguente mostra in maniera sintetica la comparazione tra Grid e Clusters.
CHARACTERISTIC
CLUSTER
GRID
Population
Commodity Computers
Commodity and High-end
computers
Ownership
Single
Multiple
Discovery
Membership Services
Centralized Index and
Decentralized Info
User Management
Centralized
Decentralized
Resource management
Centralized
Distributed
Allocation/ Scheduling
Centralized
Decentralized
Inter-Operability
VIA and Proprietary
No standards being
developed
Single System Image
Yes
No
Scalability
100s
1000?
Capacity
Guaranteed
Varies, but high
Throughput
Medium
High
Speed(Lat. Bandwidth)
Low, high
High, Low
29
4 - Esempio Load Balancing: LVS
Il Load Balancing è una tecnica informatica che consiste nel distribuire il carico di un servizio, ad
esempio la fornitura di un sito web, tra più server. Si aumentano in questo modo la scalabilità e
l'affidabilità dell'architettura nel suo complesso. In pratica se arrivano 10 richieste per una pagina
web su un cluster di tre server a tre risponderà il primo server, a tre il secondo ed a 4 il terzo.
La scalabilità deriva dal fatto che, nel caso sia necessario, si possono aggiungere nuovi server al
cluster. Mentre la maggiore affidabilità deriva dal fatto che la rottura di uno dei server non
compromette la fornitura del servizio; non a caso i sistemi di load balancing in genere integrano dei
sistemi di monitoraggio che escludono automaticamente dal cluster i server non raggiungibili ed
evitano in questo modo di far fallire una porzione delle richieste degli utenti. Viene da se che
affinché l'architettura sia in High Avaiability anche il sistema di load balancing deve essere
costituito da un cluster in HA.
Per ottenere Load balancing in genere si interviene o a livello di applicazione o di rete della pila
ISO/OSI. Nel primo caso si ha una maggiore flessibilità, non sempre utile, ma nel secondo caso si
riescono a gestire moli di traffico molto maggiori.
Dunque il Load Balancing identifica il meccanismo di ottimizzazione del carico di lavoro su più
elaboratori.
L'impiego di questa tecnica ottimizza il sistema sia per quanto riguarda le performance dei servizi
forniti, sia per l'uso delle risorse di calcolo.
Bilanciare un sistema significa:
•
evitare eventuali problemi di utilizzo non omogeneo delle risorse di calcolo
•
allocare dinamicamente le potenze di calcolo a disposizione in modo da poter far fronte ad
improvvisi carichi di lavoro.
Per esempio, un servizio web è caratterizzato da repentini picchi di traffico, in base ai quali è
impensabile dimensionare la potenza di elaborazione del sistema informativo.
Per un completo impiego delle risorse di calcolo, il bilanciamento statico dei processi
(schedulatore), non è sufficiente, occorre utilizzare un tipo di bilanciamento dinamico.
Infatti dopo l'allocazione iniziale dei job sui vari nodi, il carico della farm tende ad essere non
uniforme; alcune CPU possono essere idle dopo aver terminato la loro elaborazione ed altre
possono venire utilizzate in modalità concorrente, da più processi.
Il bilanciamento del carico si ottiene impiegando su due livelli e in tempi differenti scheduling
statico e migrazione dei processi.
Lo scheduling statico viene eseguito dal server schedulatore quando un job entra nel sistema,
assegnandolo al nodo migliore scelto in funzione dello stato delle risorse in quell'istante e
sfruttando un set di algoritmi per la condivisione adattiva delle risorse.
La migrazione dinamica viene effettuata in modo preemptive e trasparente alle applicazioni grazie
ad un continuo monitoraggio da parte di un processo supervisore, che valuta la necessità di
spostare l'immagine di processi da un nodo ad un altro per risolvere situazioni di carico sbilanciato,
ad esempio trashing dovuto a disk swapping eccessivo o mancanza di memoria in uno dei membri
del cluster.
30
4.1 - Linux Virtual Server
Linux vistual server (LVS) è un'avanzato sistema di load balancing per sistemi linux. E' un progetto
open source il cui scopo è costruire server ad alte prestazioni con tecnologie di clustering che
permettono buona scalabilità e affidabilità.
L'architettura del cluster server è trasparente all'utente, che può interagire con esso come se fossa
un singolo server virtuali ad alte prestazioni.
I server reali e il server che realizza il load balancing sono connessi tra loro con una lan ad alte
prestazioni o con una wan distribuita in una vasta area geografica. Il server di load balancing può
instradare richieste in server differenti e quindi realizzare l'esecuzione di servizi paralleli. Le
richieste possono usare tecnologie a livello di IP o a livello di applicazione per realizzare il load
balancing.
Con l'incremento costante di internet, dei servizi che esso offre e del traffico in rete, il problema
dell'overloading dei server diventa sempre più importante. Le soluzioni a questo problema sono le
seguenti:
31
1. acquisto di un singolo server ad alte prestazioni ogni qual volta il precedente incontra
problemi di overloading
2. realizzazione di un server virtuale ad alte prestazioni costituito da tanti server e, di
conseguenza, acquisto di altri server che incrementino le prestazioni del server virtuale
ogni qual volta ci siano problemi di overloading
La seconda soluzione appare di gran lunga piu vantaggiosa sia in termini di costi che di scalabilità.
Ci sono diversi modi per realizzare un cluster server:
•
basati sul dns: utilizza il domain name system per smistare le richieste nei differenti server
variando ogni volta l'ip di destinazione. Tramite variazione può essere realizzata con un
algoritmo, ad esempio quello round robin
•
basati su un server che funge da dispatcher: è usato per distribuire lavoro tra i cluster
dando l'impressione agli utenti di interagire con un unico server. Ruispetto al vistual server
basato su dns può schedulare i servizi con maggior granularità, e le failure possono essere
facilmente nascoste. Il load balancing può essere realizzato a livello di applicazione o a
livello di ip. A livello di applicazione si può realizzare un sistema che intercetti le richieste
http e le smisti in differenti web server. Il problema di overload si presenta nel momento in
cui le richieste http aumentano, rendendo il server dispatcher il collo di bottiglia del cluster
server. Il load balancing a livello di ip invece riduce il tempo di dispatching delle richieste e
dunque risolve il limite del dispatching a livello di applicazione.
4.2 - IP virtual server
Il virtual server è realizzato in tre modi:
•
NAT: ogni cluster può utilizzare un suo sistema operativo che supporti il protocollo tcp/ip e
può avere un suo accesso privato ad internet. Gli svantaggi sono dati dal fatto che è poco
scalabile e il load balancer può diventare il collo di bottiglia del sistema nel caso di 20 o piu
richieste.
•
IP TUNNELING: il load balancer si limita a schedulare le richieste nei diversi server reali, e
i server rispondono direttamente al client. In questo modo il load balancer non è più un
collo di bottiglia e può gestire oltre 100 server reali. Il massimo throughput del server
virtuale può raggiungere oltre 1Gbps, sebbenre il load balancer just abbia una scheda di
rete da 100Mbps full-duplex. Questo sistema è estremamente utile per creare server proxy
virtuali, perchè quando i server proxy ricevono la richiesta, possono accedere direttamente
in internet per processare una risposta e comunicare direttamente con il client. L'unico
limite è dato dal fatto che tutti i server devono avere il protocollo "IP Tunneling"(IP
Encapsulation) abilitato.
•
DIRECT ROUTING: l'aproccio è lo stesso dell'ip tunneling e i pacchetti di risposta possono
seguire diversi percorsi di routing per raggiungere il client. Tale modo risolve il (seppur
minimo) tempo di dispatching delle richieste dell'ip tunneling ma richiede che una delle
interfacce del load balancer e le interfacce dei server reali siano nello stesso segmento
fisico.
32
4.3 - Architettura LVS
Solitamente si adotta un'architettura a tre livelli:
L'architettura a tre liveli consiste di:
• Load Balancer, la macchina front-end dell'intero sistema cluster, smista le richieste dei
client tra i server reali
• Server Cluster, l'insieme dei server reali che eseguono i servizi di rete come Web, Mail,
FTP, DNS and Media service
• Shared Storage, che mantiene un'area di storage condivisa tra i server in modo tale da
consentire ai server di avere gli stessi contenuti ed eseguire gli stessi servizi
Per i sistemi di cluster che implementano il load balancing a livello di ip, i server contengono gli
stessi dati ed eseguono gli stessi servizi. Non è dunque importante quale server reale processa la
richiesta perchè il risultato sarà sempre lo stesso.
Per i sistemi di cluster che implementano il load balancing a livello di applicazione, i server
possono avere diversi contenuti e quindi il load balancer invia le richieste ai diversi server in
funzione del contenuto delle richieste.
33
L'area di storage condivisa può essere realizzata con database, network file systems, distribuited
file systems. I dati che devono essere aggiornati frequentemente è preferibile inserirli in database,
assicurando la consistenza e la concorrenzialità dell'accesso dei dati. I dati statici sono condivisi
con NFS.
4.4 - IPVS
In generale ipvs agirà in modo tale da far sì che:
• il client pensi di connettersi direttamente al server;
• il realserver pensi di essere stato contattato direttamente dal client.
La modalità di funzionamento di un protocollo introduce altri concetti, quali ad esempio quello di
servizio multiporta o di connessione persistente. Queste tematiche riguardano in particolare due
fra i servizi più comuni, per l’appunto l’FTP e HTTP, ma sicuramente, servizi che utilizzano
protocolli di comunicazione di tipo session oriented.
In generale, in ogni caso in cui la connessione ad un client debba essere assegnata allo stesso
server sia per motivi funzionali che prestazionali, LVS deve trattare questa affinità di connessione
in maniera particolare. Prendiamo il caso di FTP; questo è un esempio di richiesta funzionale per
affinità di connessione. Il client stabilisce due connessioni con il server, una sulla porta 21 per lo
scambio di informazioni di controllo e l’altra sulla porta scelta per il trasferimento dei dati,
solitamente la 20. Nel caso di FTP attivo, il client rende noto al server su quale porta è in ascolto
ed il server utilizzerà la 20 come porta data.
I casi in cui questo meccanismo deve essere utilizzato sono così riassumibili:
• necessità di mantenere uno stato della connessione sul server, ad esempio per lo scambio
di chiavi HTTPS;
• richiesta di un servizio multiporta, come nel caso di FTP attivo e passivo o HTTP/SSL;
• richieste di connessione che arrivano tramite proxy che presentano differenti IP per il client
per differenti connessioni TCP/IP dallo stesso client.
4.5 - Come funziona LVS
4.5.1 - Director
Il director è una sorta di router molto semplice, dotato di speciali routing table dedicate alle funzioni
dell’LVS. Queste routing table sono utilizzate per reindirizzare i pacchetti ai realserver per quei
servizi che sono stati sottoposti al controllo LVS. Il director prende decisioni a livello IP layer,
semplicemente analizzando il flusso dei pacchetti fra client e realserver; di questi pacchetti
vengono analizzate le sole informazioni IP contenute negli header. Per dare una connotazione più
tecnica, potremmo dire che il director è assimilabile ad un Layer 4 switch.
Riprendendo la definizione contenuta nella letteratura tecnica, un L4 switch determina il “path” di
un pacchetto basandosi sulle informazioni contenute al livello 4 della strutturazione a 7 livelli del
protocollo OSI. In pratica, nel contesto Internet, le informazioni a nostra disposizione consistono
nell’indirizzo IP, la porta ed il protocollo di rete utilizzato, TCP/IP o UDP/IP. Questo basta per
effettuare un bilanciamento di carico essendo in grado, grazie all’insieme di informazioni desunte,
di gestire le caratterizzazione di connection affinity necessarie per la gestione di connessioni
persistenti, e di cui parleremo nel seguito. Tuttavia questa definizione, all’interno della stretta
formalizzazione dello standard OSI, può non essere corretta. Infatti, lo strato IP, sul quale viene
34
operato lo switching da parte del director, è a livello 3 (L3). Il director comunque opera limitandosi
ad ispezionare le informazioni contenute negli header dei pacchetti, e non prende decisioni
basandosi sull’analisi del contenuto dei pacchetti. Ovvero, se il pacchetto contiene ad esempio un
http cookie, il director non se ne accorge.
Quindi il director non conosce alcunché delle applicazioni che hanno generato il flusso dei
pacchetti, poichè non ne ispeziona il contenuto (che invece si trova a layer 7).
Non essendo un L7 switch, non è capace di fornire session management o servizi basati sul
contenuto del pacchetto. Tuttavia le capacità L7 possono risultare molto utili per diversi contesti
applicativi, tant’è che una linea di sviluppo in tal senso è stata aperta: si veda ad esempio
KTCPVS, Kernel TCP Virtual Server, reperibile all’indirizzo:
http://www.linuxvirtualserv.org/software/ktcpvs/ktcpvs.html
che implementa un layer7 switch in Kernel space.
Nel link qui di seguito sono elencate altre soluzioni analoghe a lvs:
http://dmoz.org/Computers/Software/Internet/Site_Management/Load_Balancing/
Comunque, l’estrema semplicità come L4 switch del director è anche un suo punto di forza. Infatti,
il director non rappresenta dal punto di vista prestazionale un collo di bottiglia, poichè il suo scarso
uso di risorsa computazionale fa sì che, solitamente, le limitazioni sul numero di pacchetti
reindirizzati dal director siano frutto non dell’utilizzo intensivo di CPU, bensì delle limitazioni
dell’architettura hardware del PC (bus PCI, ad esempio) o del media di rete, mentre LVS non
aggiunge latenza significativa o modifiche sostanziali ai valori di throughput nell’operazione di
forwarding dei pacchetti normalmente compiuta.
4.5.2 - Metodi di forwarding
Il director, nel suo lavoro di reindirizzatore del traffico entrante, usa tre metodi di forwarding, che
comportano scelte differenziate per far fronte a differenti problematiche:
• LVS-NAT, basato su Network Address Translation (NAT), ovvero traduzione degli indirizzi
di rete, dove il director è il nodo da cui passa tutto il traffico fra client e realserver
• LVS-DR, basato su Direct Routing, dove i realserver rispondono direttamente ai client
senza passare dal director, ma per far questo devono condividere uno stesso spezzone di
LAN con esso
• LVS-Tun, modifica di VS-DR basata sulle capacità di IP-Tunneling dei realserver, rispetto al
suo predecessore permette ai realserver di risiedere anche su reti remote (in questo caso
lo schema è del tutto analogo a quello di LVS-DR).
Nel metodo LVS-NAT, il director rappresenta il punto in cui passano tutti i pacchetti nella
comunicazione bidirezionale fra client e realserver. Questo metodo, che è basato
sull’implementazione del CISCO LocalDirector, prevede che i pacchetti in entrata siano intercettati
dal director e che vengano da esso riscritti con l’introduzione dell’indirizzo di destinazione di uno
dei realserver e quindi ad esso rinviati. Le repliche del realserver sono mandate al director, che
nuovamente riscrive il pacchetto introducendo l’indirizzo sorgente del VIP. I vantaggi di VSNAT
sono essenzialmente due:
• ogni realserver può ospitare qualsiasi tipo di sistema operativo con stack TCP/IP
funzionante;
• è richiesto un solo IP address per il director, mentre tutta la parte dei realserver può essere
posta in rete privata.
35
L’unico svantaggio derivante da questo metodo è che il director è di fatto il gateway per tutti i
realserver. Questo potenzialmente limita il numero dei realserver utilizzabili, poichè tutti i pacchetti
di richiesta e risposta devono essere riscritti dal load balancer. Pur non essendo facilmente
identificabile un numero limite, è possibile che con circa 20 nodi di servizio il director diventi un
collo di bottiglia.
Il metodo LVS-DR è basato sul NetDispatcher dell’IBM. NetDispatcher, utilizzato come web-farm
front side, permette di virtualizzare l’intero set di web server come unico web site agli occhi dei
client. Questa soluzione è stata utilizzata ad esempio per l’implementazione del sito web delle
Olimpiadi di Atlanta e Sydney (con dietro, però, architettura di classe supercomputer).
Il director ed i realserver devono condividere uno stesso pezzo di rete, anche switched. Inoltre, i
realserver devono poter rispondere direttamente ai client, quindi le risposte non devono passare
attraverso il director. Infine, solo il director deve essere in grado di rispondere ad un client arp
request relativo al VIP (ovvero alle tipiche richieste Who has VIP, tell Client deve arrivare a
quest’ultimo la sola risposta del director); tutti i realserver devono avere definito il proprio VIP su
interfacce configurate in modo da non produrre risposte arp. In questo modo, il solo MAC address
associato al VIP fornito ai client sarà quello dell’interfaccia del director, ed in questo modo è
realmente mantenuta la consistenza del protocollare di connessione client-server. I vantaggi di
questo metodo sono da ricercare nelle prestazioni e nella scalabilità. Ogni realserver risponde
direttamente al client, utilizzando potenzialmete route distinte per ogni server.
Rispetto al metodo NAT, il bilanciatore di carico può quindi supportare un elevato numero di nodi
server (fino a circa un centinaio, si presume) senza degrado delle prestazioni generali.
Gli svantaggi possono essere diversi: prima di tutto, la necessità di configurare il VIP sui server su
non-arping device; in secondo luogo, la necessità di far condividere uno stesso spezzone di LAN
al director e ai server. Infine, il vincolo che i pacchetti di risposta dal realserver non debbano
passare per il director può essere un problema ove il director stesso svolga anche funzioni di
firewall.
L’ultimo metodo LVS-Tun, è una rivisitazione dell’LVS-DR, che attraverso tecniche di IP-tunneling,
permette di ottenere una distribuzione WAN dei realserver. Ovvero, il director ed i server possono
essere su reti distinte (si pensi ad esempio ad un insieme di ftp mirror distribuiti in nazioni diverse).
Il tipo di tunneling adottato è IP su IP (IPIP tunneling), e l’incapsulamento del
datagram di richiesta da parte del client viene operato dal director, con indirizzo destinazione il real
IP address del server scelto. Il server, ricevuto il pacchetto, recupera il datagram originario e quindi
l’indirizzo del client, a cui risponderà direttamente.
I vantaggi del metodo sono quelli dell’LVS-DR, con l’aggiunta del rilascio del vincolo di
condivisione di un interfaccia sulla stessa LAN per il director ed i realserver. Gli svantaggi possono
essere così riassunti:
• ogni realserver deve supportare l’IPIP tunneling (e quali altri sistemi operativi oltre Linux lo
consentono?);
• i router di ogni realserver devono essere programmati per far passare le richieste
provenienti dal director e contenenti nel campo sorgente il VIP; normalmente queste
richieste vengono bloccate dai router come conseguenza di regole anti-spoofing;
• l’IP tuneling comporta un sovraccarico sia sul director che sui server.
36
Nella tabella seguente riportiamo un confronto fra i vari metodi elencati, rispetto a caretteristiche
salienti sul lato server, quali particolari richieste per il sistema operativo ospite, vincoli topologici di
rete, numero di server supportati ed infine network gateway richiesto per fornire la risposta ai
client.
LVS-NAT
LVS-DRouting
LVS-Tunneling
Server OS
qualsiasi
non-arp device
IPIP tunneling
Server Network
privata
LAN
LAN / WAN
Numero Server
basso (10-20)
alto (>100)
alto (>100)
Server Gateway
director
proprio router
proprio router
A completamento, cerchiamo di capire più in dettaglio come il metodo LVS-DR (scelto per la
nostra installazione di test) gestisca il packet forwarding da director a realserver.
Riconsideriamo la nostra configurazione di prova come riportato nell'esempio seguente:
director# ipvsadm
IP Virtual Server version 0.9.8 (size=4096)
Prot LocalAddress: Port Scheduler Flags
-> RemoteAddress: Port Forward Weight ActiveConn InActConn
TCP 192.168.1.8: telnet rr
-> 192.168.1.3: telnet Route 1 0 0
-> 192.168.1.2: telnet Route 1 0 0
Con LVS-DR, la richiesta sulla porta 23 (telnet) del VIP (192.168.1.8) sul director sarà reindirizzata
alla porta 23 del VIP sul realserver; il director per far questo manderà un arp request per ottenere
l’indirizzo MAC del realserver scelto, diciamo 192.168.1.2, ed ottenuto il MAC gli manderà un
pacchetto link-layer (senza associare la porta, quindi) contenente un IP datagram con indirizzo
sorgente (CIP:12345), destinazione (VIP:23) e dati. Il realserver 192.168.1.2 riceve l’IP datagram,
guarda nelle sue routing table, riconosce il VIP come indirizzo locale e quindi lo tratta, mandando
la replica al client (CIP:12345) attraverso il proprio default gateway.
In questo processo è cruciale l’utilizzo di non-arping device. Infatti questo permette ai realserver di
avere nelle proprie routing table una entry locale per il VIP senza che le altre macchine possano
vederla, ossia le altre macchine non hanno risposta alle arp request per il VIP. Il trattamento del
cosiddetto arp problem nel metodo LVS-DR/TUN può avere diverse soluzioni e, nel caso di
realserver basato su Linux 2.4.x richiede l’introduzione di una patch, la hidden patch, che permette
appunto di impedire l’arp-reply sulle interfacce scelte.
Per il kernel 2.6.x, oltre l'uso della hidden patch, è anche possibile modificare la flag"arp_ignore" in
/proc.
4.5.3 - Load Balancing
Il director è implementato per mantenere in kernel space sia la componente di schedulazione dei
servizi virtualizzati che la componente di controllo.
37
L’amministrazione della configurazione del load balancer viene effettuata tramite il package
“ipvsadm”, operante in user space.
Il director mantiene in memoria sia la Tabella di Regole (VS Rules Table) determinata dalla
configurazione dell’LVS, sia la Connection Hash Table, ovvero la tabella delle connessioni
effettuate dai clients ai servizi bilanciati. Ogni entry in questa tabella occupa 128 byte di memoria
per ogni connessione TCP o UDP ed ogni connessione ha associata un hash key composta dalla
tripla: <protocollo,indirizzo – client,porta>.
Il dimensionamento delle voci presenti nella Connection Hash Table limita comunque la possibilità
di crescita incontrollata dell’occupazione di memoria, anche in presenza di numerose stale
connection e di situazioni di attacco Denial of Service (tipo SYN/FIN flood), anche grazie alla
presenza di alcuni algoritmi per la ripulitura di voci relative a stale connection. La Tabella delle
Regole di forwarding deriva dai settaggi operati mediante l’interfaccia ipvsadm. Con ipvsadm,
vengono associati ad ogni servizio da bilanciare (quindi ad una porta o ad un gruppo di porte) il
metodo di forwarding, gli indirizzi dei realserver che supportano il servizio e, infine, il metodo di
schedulazione con il quale effettuare il bilanciamento del carico. Gli algoritmi di schedulazione per
il bilanciamento del carico implementati correntemente sono:
• Round Robin (rr): le nuove connessioni sono assegnate ai realserver in modo ciclico, uno
per volta. Ad esempio, con tre realserve denominati A, B e C l’algoritmo rr fornirà la
sequenza: ABCABC... Questo tipo di algoritmo risulta il migliore quando tutti i server hanno
identica configurazione.
• Weighted Round Robin (wrr): come il precedente, ma ad ogni realserver viene associato un
peso per modificare la sequenzialità della scelta. Ad esempio, assegnando i pesi 3,2 e 1
rispettivamente ai realserver A,B e C, la sequenza potrebbe essere: ABCABA... Il wrr
scheduling algorithm è particolarmente utile quando i realserver differiscono dal punto di
vista prestazionale, oppure quando un realserver offre più di un servizio.
• Least Connected (lc): le nuove connessioni sono indirizzate al server con minor numero di
connessioni. Pur non coincidendo con un real load balancing, questo algoritmo è un buon
passo in questa direzione.
• Weighted Least Connected (wlc): variante del precedente con l’introduzione di “pesi”.
Altri algoritmi di schedulazione sono ad esempio DH (Destination Hash, progettato per webcache)
o SH (Source Hash, utilizzato per la gestione di firewall multipli).
Lo sviluppo di teniche di schedulazione è senz’altro destinata a crescere, proporzionalmente alla
diffusione ed all’uso di LVS come strumento di servizio, ma la vera sfida è passare da un load
balancing sul numero e tipo di connessione ad un load balancing basato effettivamente
sull’applicazione, ovvero uno schedulatore dinamico in grado di prendere decisioni del tipo “per la
presente richiesta di connessione al servizio Web, qual è la macchina con minor carico in questo
istante all’interno del pool di realserver?”.
4.6 - Difesa da attacchi DoS
Le tematiche di sicurezza di cui essenzialmente ci interesseremo riguardano eventuali attacchi
DoS al director. Ogni connessione comporta la creazione di una entry di circa 128bit; una
aggressione al director mediante attacco Denial of Service può, quindi, portare all’esaurimento
della memoria e conseguente potenziale crash del director stesso.
Per far fronte all’annoso problema dei Denial of Service sono state implementate tre strategie di
difesa:
38
• drop_entry: che elimina casualmente alcune entry della connection hash table per
recuperare memoria; procedura attivabile ogni secondo, scandisce fino ad un 1/32
dell’intera tabella ed elimina quei record che sono in uno stato SYN-RECV o SYN-ACK per
TCP e, parzialmente, quelli in uno stato ESTABLISHED per UDP, stategia che dovrebbe
essere indicata per attacchi denial of service di tipo syn-flooding: questa strategia può
essere controllata dai valori della sysctl variable "/proc/sys/net/ipv4/vs/drop_entry". La
soglia per determinare se il sistema ha abbastanza memoria disponibile, è data dal valore
(in memory page) presente nel file "/proc/sys/net/ipv4/vs/amemthresh"
• drop_packet: questa strategia elimina 1/rate pacchetti prima di redistribuirli ai realserver. La
variabile rate è determinata dalla formula: amemthresh / (amemthresh - available_memory)
ad è controllato dal valore della "/proc/sys/net/ipv4/vs/drop_packet". Esiste anche un
always drop mode, nel qual caso il valore di rate è controllato dalla variabile
"/proc/sys/net/ipv4/vs/am_droprate"
• secure_tcp: utilizza un tabella di transizione di stati per ogni connessione, stabilendo dei
timeout per ogni stato; l’utilizzo di questa strategia è controllata da
"/proc/sys/net/ipv4/vs/secure_tcp" ed i timeout possono essere settati sempre nella stessa
/proc directory nelle variabili timeout_*. Gli autori, per il metodo LVS-NAT, consigliano di
settare timeout_synrecv a 10 (secondi).
4.7 - Alta disponibilità e monitoraggio
Il software LVS di per sé non fornisce soluzioni di alta disponibilità, ma in realtà si presta molto
bene ad essere integrato con soluzioni software esterne per il raggiungimento di piena disponibilità
di servizio, prevedendo il rimpiazzo automatico, in caso di crash, di server o director. Questo non è
sufficiente per parlare di alta disponibilità, che è comunque una problematica che non può essere
analizzata a prescindere dal tipo di servizio posto sotto alta disponibilità.L’alta disponibilità non può
prescindere da una serie di meccanismi a livello di file system distribuito che consentano una
corretta implementazione di controllo dell’accesso condiviso a stesse porzioni di disco; ovvero,
possiamo parlare di alta disponibilità per un certo servizio quando si può contare su meccanismi a
basso livello che consentano di utilizzare, in modo coerente, porzioni condivise di filesystem da
parte di una molteplicità di sistemi, garantendo meccanismi di lock e di arbitrazione di accesso, di
caching e di sincronizzazione di esse ed eventualmente meccanismi di forzato spengimento di
quei sistemi che possono risultare in uno stato inconsistente.
Comunque, dal punto di vista delle componenti del cluster LVS, si possono verificare due tipi di
fallimenti: quello relativo ad un director e quello relativo ad un realserver.
Da un punto di vista di criticità, quasi certamente il primo assume ben altro peso, in quanto
solitamente, partendo da una configurazione standard LVS, esiste un solo director sul quale è
stato definito un servizio virtuale associato ad un VIP; se questo cade, quindi, l’intero servizio viene
a mancare, anche se la totalità del pool di realserver relativi potenzialmente sono in grado di
continuare ad offrire servizio.
Inversamente, il fallimento di uno dei realserver di un pool di N, porta ad una percentuale di
fallimento di connessioni pari, nel caso di algoritmo di schedulazione round-robin lineare, a 1/N.
Quindi, bassa criticità e la possibilità comunque di poter sempre intervenire a livello di director per
togliere a caldo quel sistema dal pool di servizio.
I meccanismi di ridondanza applicabili sono molteplici.
Quelli più comunemente usati, rispetto alla tipologia di crash, sono i seguenti:
39
• Director crash: risolvibile avendo a disposizione uno o più director ridondati, sia secondo
uno schema attivo/standby che, in alcuni casi, secondo uno schema attivo/attivo e facendo
ricorso a strumenti di monitoraggio e tecniche di IP address Takeover per il ripristino in
caso di crash del master director
• Realserver crash: utilizzando uno strumento di monitoraggio (healtchecker agents), il
director monitorizza i servizi posti sui realserver. Nel caso in cui il servizio su un sistema
diventi indisponibile, quel server è rimosso dal pool di realserver associatial servizio
virtuale, mediante utilizzo di ipvsadm.
In caso di crash del director principale, pur essendo possibile trasferire automaticamente il
controllo al secondario, le informazioni sulle sessioni IP attualmente in corso andrebbero perse.
Il problema è stato risolto tramite la progettazione di un demone che serve ad effettuare la
sincronizzazione dei vari director. Il demone è attivabile tramite il comando
# ipvsadm --start-daemon=master --mcast-interface=eth0
sul load balancer primario e, analogamente, sarà possibile attivarlo
# ipvsadm --start-daemon=backup –mcast-interface=eth0
anche su quello di backup; i due demoni, attivati dentro il kernel, usano pacchetti in ip-multicast per
scambiarsi i messaggi di sincronizzazione delle code di forwarding.
Lo stesso script configure.pl produce un file (mon.cf) di configurazione residente sul director;
questo viene utilizzato da MON, il modulo di monitoraggio scritto in Perl rilasciato con licenza GPL
reperibile sul sito http://www.kernel.org/software/mon/ che consente il monitoraggio dei servizi
configurati mediante chiamate ai protocolli applicativi o, quantomeno, verificando la connettibilità
dei realserver; in caso di risposta negativa per uno dei servizi monitorati, altri strumenti provvedono
a togliere il realserver interessato dal pool di macchine associato al servizio.
4.8 - Allestire un cluster a bilanciamento di carico
4.8.1 - Hardware necessario
Per una dimostrazione effettiva delle capacità di LVS servono tre sistemi, un client, il director ed un
realserver; per evidenziare la scalabilità della soluzione la parte dei realserver può essere dotata di
più sistemi:
• 1 director: una Linux-box, patched kernel 2.2.x or 2.4.x or 2.6.x, con 1 o 2 NIC 10 o 100
Mbps Ethernet. Per le prestazioni può essere sufficiente un Pentium I 75MHz che può
spedire 50Mbps di pacchetti su una PCI 33 fastEthernet 100 Mbps.
• 1 client: qualsiasi sistema operativo, che sia in grado di montare (per i nostri scopi) un client
telnet. Il client non deve essere un membro dell’LVS.
• realserver: per la scelta vedere regola nr.2. Devono essere dotati di almeno una interfaccia
4.8.2 - Tipo di forwarding
Come abbiamo visto in precedenza, le tecniche sono:
• LVS-DR (Direct Routing): è il default, consente alto throughput e può essere implementata
sulla maggior parte dei sistemi operativi;
• LVS-NAT (Network Address Translation): più basso throughput e maggior latenza, richiede
tuttavia che sui realserver sia presente solo una implementazione dello stack TCP/IP
(quindi, potenzialmente, anche una semplice stampante di rete). È consigliabile partire da
40
questa configurazione per approntare l’ambiente di test, per evitare di dover trattare il
problema delle risposte arp delle interfacce che ospitano i VIP;
• LVS-TUN (IP Tunneling): richiede che i realserver siano in grado di operare IP-IP
Tunneling, ma può essere utilizzato quando i realserver sono su rete diversa da quella del
director, con le stesse prestazioni del metodo LVS-DR.
La scelta del metodo di forwarding influenza la scelta dei realserver (a livello di sistema operativo
ospite); mentre per LVS-NAT non ci sono limitazioni e per LVS-TUN si può al momento scegliere
solo server Linux, per LVS-DR la scelta è dettata da come il sistema è in grado di gestire la
cosiddetta problematica della risposta arp, che tratteremo nel seguito.
Nel nostro esempio useremo il metodo LVS-DR, che ci consente di elaborare una spiegazione più
generale su come lavora LVS in un contesto che, presumibilmente, potrà essere lo stesso
utilizzato in ambito di produzione.
4.8.3 - Configurazione
Si intende usare una configurazione di servizio composta da un protocollo semplice (che utilizzi
una sola porta) che non utilizzi schema di persistenza sulla connessione (tipo HTTP cookie o ssl),
che utilizzi codifica ASCII in chiaro e che abbia client per ogni sistema operativo: telnet. E'
necessario verificare che il servizio scelto sia attivo sui realserver prima di attivare LVS: è
sufficiente attivate il telnetd, che di default si porrà in ascolto su tutte le interfacce e controllate che
il vostro TCP wrapper consenta il collegamento almeno dal client scelto.
Passiamo alla configurazione di rete: il director ed i realserver devono condividere uno spezzone di
rete, anche switched, per implementare il metodo LVS-DR. In una configurazione di test, il default
gateway dei realserver può essere definito puntare direttamente al client, rendendo quindi inutile la
presenza di router (come d’altronde sarebbe lecito attendersi in un ambiente di test). Tuttavia, può
valer la pena dotare sia il director che i realserver di interfacce aggiuntive oltre a quelle
strettamente necessarie, sia per gestire il flusso di pacchetti in modo separato, sia per
implementare sui realserver una non-arp interface, semplicemente mantenendo una interfaccia
attiva, ma non connessa alla rete, sui cui attivare i servizi LVS.
4.8.4 - Installazione
La configurazione di un cluster LVS consiste delle seguenti tre fasi:
1. dotarsi di un Linux kernel patchato e configurato per LVS (sul director ed, eventualmente,
sui realserver). Le patch sono reperibili alla URL: http://www.linuxvirtualserver.org/software.
Dalla versione 2.6.28-rc3 la patch è già inclusa nel kernel ed è sufficiente attivarla
2. una volta modificati i sorgenti, il kernel deve essere ricompilato con l’abilitazione del
supporto NetFilter (disabilitando il supporto di compatibilità con ipchains) e Virtual Server. Il
metodo di reindirizzamento LVS-NAT non presenta alcun tipo di problema di
configurazione, non dovendo trattare il problema della risposta arp sui realserver.
Utilizzando delle Linux-box come realserver, la scelta del metodo LVS-DR, così come per il
metodo LVS-TUN, può comportare invece la necessità di aggiungere la cosiddetta hidden
patch che permette di risolvere il problema della non-arp interface:
1. L’utilizzo di questa patch è obbligatorio per i kernel 2.4.x e 2.6.x
2. Nei kernel 2.2.x, con x<=12, nuovamente la patch si rende necessaria;
3. Nei kernel 2.2.x, con x>12, la hidden patch era già inclusa;
4. Nei kernel 2.0.x, la patch non è necessaria.
41
3. compilazione ed installazione, sul director, del pacchetto ipvsadm. La userland
administrative interface di LVS, che permette di amministrare da user space la
configurazione del modulo ipvs del kernel, è l’unico (potente) strumento che userete nella
configurazione e nella gestione del director. È buona norma installare la stessa versione di
ipvsadm e di kernel patch. Il modulo ipvs contiene nel suo albero il codice per ipvsadm e
può essere compilato dopo aver apportato le patch al kernel.
4. configurazione dell’ambiente di prova; in questo caso è utile ricorrere allo script configurelvs-x.x.x.pl che permette di produrre dei file di inizializzazione per i membri dell’LVS cluster.
Tale strumento è reperibile all'url http://www.linux-vs.org/Joseph.Mack/configurelvs_0.9.4.tar.gz
Qui di seguito i passi elencati:
1) create una directory di lavoro:
# export DIR=/tmp/work
# mkdir $DIR
2) scaricate un kernel e il modulo ipvs:
# cd $DIR
# wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.x.tar.gz
3) Solo per i kernel precedenti al 2.6.10 sarà necessario scaricare la patch ipvs da includere
nel kernel. Per semplicità si farà riferimento ad un kernel che già include tale modulo.
Nel caso vogliate utilizzare lo stesso kernel sui realserver, applicare la hidden patch,
presente nella directory
$IPVSDIR/contrib/patches:
# cat $IPVSDIR/contrib/patches/hidden-2.4.5-1.diff | patch -p1
4) compilate il nuovo kernel con tutte le opzioni già discusse
# make clean; make mrproper
# make menuconfig
(configurare le opzioni relative al virtual server)
# make modules
# make modules_install
# make bzImage
# make install (oppure copia arch/i386/boot/bzImage e modifica bootloader)
# reboot
Ora, il kernel così ottenuto può essere portato su altri sistemi Linux (sempre che completo di
moduli e driver necessari a supportare le diverse configurazioni), in modo semplice e veloce.
Avendo predisposto il kernel, possiamo quindi compilare il tool ipvsadm. In sostanza, basta
portarsi nel punto giusto dell’ipvs tree:
# cd $IPVSDIR/ipvs
e dare il comando:
# make -C ipvsadm install
che provocherà l’installazione (in /sbin) di ipvsadm, ipvsadm-save e ipvsadm-restore, nonché delle
relative man page. Per testare il software, basta eseguire ipvsadm, che compierà il check sul
kernel; nel caso che il kernel non abbia il supporto ipvs o che versione di ipvsadm e di kernel ipvs
layer differiscano, il comando restituirà un messaggio di errore.
Altrimenti dovrebbe visualizzare qualcosa del tipo:
42
# ipvsadm
IP Virtual Server version 0.9.8 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
Abbiamo scelto di utilizzare una configurazione hardware minimale, in cui il director ed i realserver
sono dotati di un’unica NIC. In questa configurazione siamo dotati di una sola rete (privata), e i
server usano come default gateway lo stesso client che compie le richieste.
Questa soluzione, non proponibile per un ambiente di produzione, permette tuttavia di mettere in
piedi un ambiente di test senza doversi preoccupare della presenza di router.
L’approccio scelto è quello di utilizzare una tecnica di dispatching delle richieste nota come Direct
Routing (DR): il VIP, Virtual IP Address del servizio, è condiviso sia dal load balancer che dai
realserver. Per il load balancer questo comporta che vi sia un interfaccia configurata (anche) con
l’indirizzo del VIP e che viene usata per accettare le richieste dal client; il director dovrà indirizzare
direttamente i pacchetti ricevuti al realserver scelto e quindi necessita di una interfaccia configurata
con un indirizzo appartenente alla LAN condivisa. Per i realserver c’è invece la necessità di
definire il VIP su un’interfaccia che sia in grado di non rispondere alle ARP request, ovvero alla
richiesta di identificazione sulla rete del possessore dell’indirizzo VIP. Infatti il client, a fronte di una
interrogazione arp “who has VIP, tell client”, deve ricevere il MAC address dell’interfaccia del
director.
I requisiti richiesti per procedere col nostro ambiente di test sono essenzialmente due:
• Il director ed i realserver devono condividere uno stesso segmento di LAN (anche
attraverso Hub o Switch);
• I realserver devono poter definire una non-arp alias interface.
La scelta che in generale può essere utilizzata è quella di definire un alias IP sulla loopback
interface. La maggior parte dei sistemi Unix permettono inoltre di utilizzare l’opzione “-arp”
all’interno del comando ifconfig di configurazione delle interfacce. Un'altra soluzione prevede
l'utilizzo della già citata hidden patch.
Per nascondere le interfacce alle arp request, devono essere aggiunte le seguenti righe in qualche
punto degli scripts di attivazione della vostra rete (per esempio /etc/rc.local):
# attivazione del meccanismo hidden
echo 1 > /proc/sys/net/ipv4/conf/all/hidden
# attivazione di hidden su lo:0 (ifconfig lo:8 -arp)
echo 1 > /proc/sys/net/ipv4/conf/lo/hidden
Non è più reperibile il pacchetto configure-lvs_x.x.x.tar.gz che contiene un utile script che,
leggendo da un file di configurazione che descrive il cluster LVS ed i servizi in esso attivati,
permette di produrre dei files rc.lvs_* da utilizzare, sia sul director che sui realserver, per
configurare ed inizializzare ogni membro del cluster.
Tali configurazioni si dovrebbero poter effettuare direttamente col modulo ipvsadmin: nella
directory contrib del tarball di ipvsadmin c’è uno script Perl, configure.pl, che permette la creazione
di file rc.lvs, che lanciato prima sul director poi sui realserver, produce una completa
configurazione dell’LVS cluster.
Il configure prende come argomento un file contenente una descrizione di configurazione del
cluster LVS e produce in output il succitato file rc.lvs, contenente l’insieme di comandi ipvsadm e
43
ipchains/iptables (per le regole di network filtering) ed i settaggi del proc filesystem necessari per
l’implementazione della configurazione descritta nel file.
rc.lvs deve essere eseguito sia sul director che sui realserver, essendo in grado di capire dal nome
dell’host quale ruolo il sistema riveste all’interno del cluster e quindi quale tipo di comandi applicare
per la corretta configurazione. Nel file di configurazione è contenuta, fra l’altro, la descrizione del
comportamento del bilanciatore, sia per quanto riguarda la scelta del metodo di redirezione dei
pacchetti che dell’algoritmo di schedulazione con il quale i realserver vengono selezionati.
4.8.5 - Testing
Adesso possiamo provare dal client a collegarci al servizio definito, tramite:
client# telnet 192.168.1.8
ottenendo il login prompt della prima macchina.
Una invocazione sul director dell’ipvsadm adesso produrrà:
# ipvsadm
IP Virtual Server version 0.9.8 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveCon InActConn
TCP 192.168.1.8:telnet rr
-> 192.168.1.3:telnet Route 1 1 0
-> 192.168.1.2:telnet Route 1 0 0
Ripetendo il telnet e facendo girare nuovamente ipvsadm dovreste, adesso, essere in grado di
vedere la connessione sull’altro server
# ipvsadm
IP Virtual Server version 0.9.8 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.8:telnet rr
-> 192.168.1.3:telnet Route 1 1 0
-> 192.168.1.2:telnet Route 1 1 0
Abbiamo quindi testato il nostro primo cluster LVS.
Ill telnet daemon parte in ascolto su tutte le intefacce presenti sul sistema, non richiede alcuno
sforzo configurativo aggiuntivo.
Volendo configurare un servizio tipo httpd, ad esempio, avremmo dovuto modificare il file di
configurazione del demone sui realserver per dirgli di partire sull’interfaccia VIP (ossia
sull’interfaccia virtuale in cui il client crede che il servizio sia definito).
44