Approfondimento - Cluster and Griddisys/Cluster_Grid_DeCandia_Nettis.pdf · 5. Microsoft Cluster...

SSIISSTTEEMMII DDIISSTTRRIIBBUUIITTII:: AARRCCHHIITTEETTTTUURRAA EE

MMOODDEELLLLAAZZIIOONNEE

AAAA.. 22000088//22000099

AAPPPPRROOFFOONNDDIIMMEENNTTOO SSUU SSIISSTTEEMMII CCLLUUSSTTEERR

EE GGRRIIDD

Sviluppatori:Sviluppatori:Sviluppatori:Sviluppatori:

de Candia Corrado de Candia Corrado de Candia Corrado de Candia Corrado –––– Mat. 540276Mat. 540276Mat. 540276Mat. 540276

Nettis Giuseppe Nettis Giuseppe Nettis Giuseppe Nettis Giuseppe –––– Mat. 540242Mat. 540242Mat. 540242Mat. 540242

2

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

1 - Cluster

Un computer cluster, o più semplicemente un cluster (dall'inglese grappolo), è un 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 vengono risolti in parallelo. Questo ovviamente aumenta la potenza di calcolo del sistema.

Un cluster quindi è generalmente 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 Applications (Amazon, eBay);

◦ Database Applications (Oracle on clusters).

• Internet Applications:

◦ ASPs (Application Service Providers);

◦ Computing Portals;

◦ E-commerce and E-business.

• Mission Critical Applications:

◦ Sistemi di controllo, banche, cont

3

Un computer cluster, o più semplicemente un cluster (dall'inglese grappolo), è un 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.

eneralmente costituito da due o più computer (nodi) connessi tra loro, in un 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:

commerce Applications (Amazon, eBay);

Database Applications (Oracle on clusters).

ASPs (Application Service Providers);

business.

Mission Critical Applications:

Sistemi di controllo, banche, controllo di reattori nuclear,ecc.

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

viene scomposto in sottoproblemi separati i quali vengono risolti in parallelo. Questo ovviamente aumenta la potenza di calcolo del sistema.

eneralmente costituito da due o più computer (nodi) connessi tra loro, in un fisicamente separate e connessi via LAN. Appare come un unico sistema agli

utenti e alle applicazioni e fornisce un modo conveniente per ottenere benefici

4

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, Web-Service 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.

5

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

6

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.

7

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.

8

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.”

9

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

Solaris + GLUnix + xFS

AM, PVM, MPI, HPF, Split-C

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

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

10

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).

11

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'

12

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

13

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

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.

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

14

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 anni ’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.

15

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.

Il subito sopra questi elementi c’è un livelmessaging, 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, etctrae 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 computegran 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à ungriglia 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 de

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 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, peervirtualizzazione - :

16

Il subito sopra questi elementi c’è un 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

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, etctrae vantaggio dai server di applicazioni del middleware, che forniscono supporto allo sviluppo di

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 è 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

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à ungriglia 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

L’immagine sottostante è un esempio semplificato 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

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.

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ù

come ad esempio il calcolo distribuito, il web, peer-to-peer computing e le tecnologie di

lo 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

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. OGSA trae vantaggio dai server di applicazioni del middleware, che forniscono supporto allo sviluppo di

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

r è 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

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 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

l 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

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.

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ù

r computing e le tecnologie di

17

• 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

18

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

19

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

Property 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



Architecture Vertical multi tiered system

Layered and modular toolkit

Vertically integrated system

Layered component and utility model

Implementation

Model

Abstract Job Object

Hourglass model at system level

Object-oriented metasystem

Hourglass model at user level

Implementation Technologies

Java C and Java C++ C, Java, C# and Perl

Runtime Platform Unix Unix Unix Unix and Windows with .NET

Programming Environment

Workflow environment

Replacement libraries for Unix & C libraries. Special MPI library (MPICH –G), CoG (Commodity Grid) kits in Java, Python, CORBA, Matlab, Java Server Pages, Perl and Web Services

Legion Application Programming Interfaces (API).

Command line utilities

Broker Java API

XML-based parameter-sweep language

Grid Thread model via Alchemi.

Some Users and Applications

EuroGrid], Grid Interoperability Project, OpenMolGrid

AppLeS, Ninf], Nimrod-G, NASA IPG, Condor-G, Gridbus Broker,

NPACI Testbed, Nimrod-L, and NCBioGrid. Additionally, it has

ePhysics, Belle Analysis Data Grid], NeuroGrid], Natural Language

20

and Japanese NAREGI.

UK eScience Project], GriPhyN], and EU Data Grid.

been used in the study of axially 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

21

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.

22

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 strumenti 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.

23

Le Grid di applicazioni e/o servizi, rappresentano una delle visioni più futuribili nel campo del Grid Computing. Esse, infatti, non si limitano 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

24

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

25

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:

26

• 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

27

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-to-peer con il quale, al contrario, condivide il concetto fondamentale di condivisione dinamica di risorse geograficamente distribuite.

28

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.

29

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

30

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.

31

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:

32

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.

33

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.

34

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

35

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.

36

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.

37

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.

38

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:

39

• 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:

40

• 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

41

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.

42

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 configure-lvs-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/configure-lvs_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:

43

# 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

44

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).

Approfondimento - Cluster and Griddisys/Cluster_Grid_DeCandia_Nettis.pdf · 5. Microsoft Cluster...

Documents

Transcript of Approfondimento - Cluster and Griddisys/Cluster_Grid_DeCandia_Nettis.pdf · 5. Microsoft Cluster...