Grid on Cloud : Implementazione e Monitoraggio

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea Grid on Cloud : Implementazione e Monitoraggio Anno Accademico relatore Ch.mo prof. Marcello Cinque correlatore Ch.mo Ing. Flavio Frattini Ch.mo Ing. Davide Bottalico candidato Antonio Nappi matr. M

2 Alla mia famiglia,alla mia Pazza,agli amici e a tutti quelli che mi sono stati vicino in questi anni 2

3 Lascia dormire il futuro come merita. Se si sveglia prima del tempo, si ottiene un presente assonnato,, 3

4 Indice Introduzione 1 1 Problematiche del Grid computing Grid Computing Componenti di un sistema Grid Un esempio di sistema Grid: SCOPE Limiti del Grid Cloud Computing Modelli di servizio Modelli di distribuzione Vantaggi e svantaggi del Cloud nei sistemi Grid Il monitoraggio dei sistemi informatici Definizione e tipi di monitoraggio Il processo di monitoraggio Requisiti di un sistema di monitoring Performance monitoring Tassonomia Metriche da valutare Virtualizzazione e piattaforma Cloud: installazione e configurazione Virtualizzazione Virtualizzazione Hypervisor-based e virtualizzazione Non-Hypervisor-based KVM i

5 3.3 Openstack Architettura Concettuale Architettura Logica I componenti di Openstack Installazione e configurazione di Openstack FlatManager FlatDHCPManager Implementazione di un sistema di monitoraggio basato su Ganglia Architettura di Ganglia Ganglia Monitoring Daemon Ganglia Meta Daemon(gmetad) Ganglia Web Fronted RRDtool Estendere Ganglia Moduli C/C Moduli Python Installazione e configurazione di Ganglia Abilitazione del monitoraggio virtuale Abilitazione e scrittura dei moduli python Metriche monitorate Verifica del Sistema: un semplice esperimento Preparazione del job Sottomissione del job Analisi sperimentale Nodo fisico Host del nodo virtuale Conclusioni e sviluppi futuri 113 A Installazione Openstack 115 A.1 Installazione e configurazione di Keystone A.2 Installazione e configurazione di Image Service ii

6 A.3 Configurare l hypervisor A.4 Installazione e configurazione NOVA A.5 Installazione e configurazione Block Storage A.6 Installazione e configurazione Dashboard B Installazione Ganglia 124 B.1 Installazione server B.2 Installazione client C Script creati 129 C.1 File per estendere Ganglia C.1.1 m600.pyconf C.1.2 m600.py C.1.3 chassisx.pyconf C.1.4 chassisx.py C.1.5 rackx.pyconf C.1.6 rackx.py C.2 File per la migrazione dati C.2.1 Analisi log torque C.2.2 Migrazione da RRA a mysql Bibliografia 172 Ringraziamenti 174 iii

7 Elenco delle figure 1.1 Virtual Organization Modello a clessidra Confronto tra l architettura Grid e il modello ISO/OSI I protocolli,servizi,api dei livelli Collective e Resource possono essere combinati in molti modi per fornire funzionalità alle applicazioni I software development kits implementano delle API specifiche. Queste API a loro volta utilizzano i protocolli Grid per interagire coi servizi di rete che forniscono le capacità agli utenti. Gli SDKs possono fornire funzionalità che non sono direttamente mappate con uno specifico protocollo, ma possono combinare più operazioni di diversi protocolli Architettura Grid Consumo in kilowatts di 500k computer Analisi del consumo di potenza Analisi dell utilizzo dei core del datacenter di Lione Rapporto tra il consumo energetico e l utilizzo delle risorse Vantaggi e svantaggi del Cloud Computing Modelli di servizio Server Consolidation Architettura di un sistema Grid Un republisher implementa sia l interfaccia di procuder che di consumer Esempio di tassonomia iv

8 3.1 Tipologie di Hypervisor KVM Architettura concettuale di Openstack Architettura logica di Openstack Esempio di Dashboard Architettura reale Requisiti hardware per l installazione Esempio di bridge FlatManager FlatDHCPManager Doppio gateway Pagina di login Pagina dell amministratore Architettura di Ganglia Architettura di Gmond Architettura di Gmetad Funzionamento di RRA Funzionamento di sflow Agent hsflowd Esempio di MIB Controllo Rack RRA in XML Metriche dei rack monitorate da Ganglia Consumo chassis Potenza aggregata del cluster SCOPE Potenza di un gruppo di host del cluster SCOPE Tabella dei job Tabella dei Worker Node Tabella dei rack Tabella dei chassis Infrastruttura Grid virtuale Output del job CPU wio v

9 5.4 Potenza media: ± Watts Utilizzo medio della system CPU : 0.8 ± 0.01% Utilizzo medio della user CPU : ± 4.03% Numero di processi in esecuzione Potenza media: ± Watts Utilizzo medio della system CPU : 9.17 ± 0.07% Utilizzo medio della user CPU : ± 0.46% Numero di processi in esecuzione A.1 Lista utenti A.2 Lista dei tenant A.3 Lista dei servizi A.4 Lista delle immagini di Glance A.5 Servizi Nova vi

10 Elenco delle tabelle 4.1 Funzioni di consolidamento Metriche di default di gmond Tempi di calcolo del job vii

11 Introduzione Negli ultimi anni il Cloud Computing ha trovato larga diffusione in numerose applicazioni, dalla condivisione di file alla proliferazione del software as a service, fino alla fornitura di infrastrutture hardware remote accessibili via Internet. Oggi, inizia a evolversi e diffondersi anche come paradigma per migliorare la gestione dei data center. Ciò è principalmente dovuto all utilizzo della virtualizzazione nei sistemi di Cloud computing e ai vantaggi che da essa ne derivano. Infatti, la virtualizzazione consente di consolidare il carico di un sistema in un numero ridotto di macchine fisiche, così da aumentare l efficienza energetica del data center, nonché di migliorarne l affidabilità attraverso l utilizzo di tecniche di fault tolerance, la cui implementazione è impraticabile per macchine fisiche[1]. Un caso particolare è costituito dai sistemi batch (batch systems), cioè supercomputer che eseguono attività di lavoro (job) senza l intervento umano. Anche i batch systems utilizzati per le elaborazioni scientifiche e facenti parte di un sistema Grid stanno migrando verso il paradigma del Cloud computing, sebbene ciò possa causare un degrado delle prestazioni del sistema. La presenza di un maggior numero di strati software, quali i middleware per la gestione del Cloud, nonché il tempo necessario alla creazione e distruzione delle stesse macchine virtuali, introducono delle operazioni aggiuntive da effettuare prima di poter eseguire i job sottomessi dagli utenti. Dopo che un job è sottomesso, un gestore delle risorse deve individuare una macchina fisica che che sia in grado di ospitare una macchina virtuale per l esecuzione del job stesso, avviare la macchina virtuale, eseguire il job e, quando questo è terminato, distruggere la macchina virtuale e liberare le risorse occupate. Inoltre, la presenza di un virtual machine monitor per la gestione delle macchine virtuali in esecuzione su macchine fisiche, introduce un overhead che 1

12 influisce sulle prestazione del sistema. L altra faccia della medaglia, però, è costituita dalla semplificazione della gestione delle macchine che consente il Cloud e dal consolidamento del carico su un numero ridotto di esse così da ottenere un guadagno in termini di consumo di energia elettrica. Mentre non è possibile compattare macchine fisiche, quelle virtuali necessarie all esecuzione dei job possono essere raggruppate su un numero ridotto di server fisici e tenere spenti o in stand-by quelli inutilizzati. Inoltre, le più recenti piattaforme per il Cloud computing consentono, oltre alla virtualizzazione delle macchine che eseguono i job (worker node), la virtualizzazione della rete e, quindi, dei canali di comunicazione tra i componenti costituenti il supercomputer. Ciò permette di determinare e salvare lo stato dell intero sistema, altrimenti difficile, se non irrealizzabile, per sistemi non virtualizzati, dove lo stato dei canali di comunicazione potrebbe non essere accessibile e quindi i messaggi in transito non noti in fase di determinazione dello stato del sistema. Altro componente chiave di un batch system, così come di un qualsiasi data center, è il sistema di monitoraggio, il quale permette di analizzare il comportamento del sistema al fine di migliorarne l utilizzo e la gestione. Esso consente di individuare in tempi rapidi comportamenti anomali e quindi avviare prontamente operazioni di ripristino o, ancora, di studiare i trend del sistema per effettuare operazioni di prevenzione. Inoltre, volendo valutare l effetto del Cloud e della virtualizzazione si un batch sysem, il sistema di monitoraggio deve anche fornire metriche di performance e consumo relative sia all esecuzione di un certo carico su macchine fisiche che del medesimo carico su macchine virtuali. Partendo da tali considerazioni, questo lavoro di tesi si incentra sulla implementazione di un batch system virtualizzato nonché del relativo sistema di monitoraggio. Il sistema batch considerato è S.Co.P.E., il supercalcolatore della Università Federico II facente parte della Grid nazionale ed Europea, nonché del progetto ATLAS per lo studio del Bosone di Higgs. La tesi è strutturata come segue. Nel Capitolo 1 si introducono il Grid computing e il Cloud computing e si discutono i limiti del primo e come il Cloud può essere utilizzato per superarli. Nel Capitolo 2 si evidenzierà il ruolo e l utilità del 2

13 monitoraggio in tali sistemi. Il Capitolo 3 è incentrato sulla virtualizzazione, illustrandone i principi base di funzionamento, e sulla presentazione della piattaforma software Cloud utilizzata. Nel Capitolo 4 si presenta il sistema di monitoraggio installato, le metriche da esso tenute in considerazione e le estensioni implementate per monitorare la potenza e altre metriche non presenti nel sistema di monitoraggio di base. Il Capitolo 5 mostra il corretto funzionamento delle infrastrutture Cloud e di monitoraggio attraverso un esperimento che confronta il sistema virtualizzato ed il sistema non virtualizzato attraverso l andamento delle metriche monitorate durante l esecuzione degli esperimenti. Infine, al Capitolo 6, si traggono le conclusioni e si delineano i possibili sviluppi futuri. 3

14 Capitolo 1 Problematiche del Grid computing In questo capitolo vengono presentati prima il Grid computing, con le sue principali caratteristiche e i suoi problemi, e successivamente il Cloud Computing. Inoltre si spiega come quest ultimo possa contribuire a superare i limiti presenti nel Grid. 1.1 Grid Computing Esistono molte definizioni di Grid computing: Plaszczak e Wellner[5] definiscono la tecnologia Grid come una tecnologia che abilita la virtualizzazione delle risorse,la fornitura di queste on-demand,e la condivisione di risorse e servizi tra organizzazioni. IBM [6] definisce il Grid computing come l abilità di utilizzare un insieme di standard e protocolli open, per guadagnare l accesso alle applicazioni e ai dati, incrementare la potenza di elaborazione,e aumentare la capacità di storage. Il Grid è un tipo di sistema parallelo e distribuito che abilita la condivisione,la selezione e l aggregazione di risorse distribuite tramite domini amministrativi diversi basati sui propri requisiti di disponibilità,capacità,performance e costi e QoS degli utenti. 4

15 CERN[7],che rappresenta uno dei più grandi utenti della tecnologia Grid, ne parla definendolo come un servizio per la condivisione delle capacita di data storage e di calcolo attraverso internet In generale il Grid computing o sistemi Grid sono un infrastruttura di calcolo distribuito, utilizzati per l elaborazione di grandi quantità di dati, mediante l utilizzo di una vasta quantità di risorse. In particolare, tali sistemi permettono la condivisione coordinata di risorse all interno di un organizzazione virtuale. Ciò che distingue il Grid computing dai sistemi di calcolo ad alte prestazioni convenzionali come cluster di calcolo, è che le reti tendono ad essere più debolmente accoppiate, eterogenee e geograficamente disperse. Il Grid può essere visto come un super computer virtuale, composto da molti computer debolmente accoppiati che agiscono insieme per eseguire compiti di grandi dimensioni. Questo è in contrasto con la nozione tradizionale di un supercomputer, composto da molti processori collegati tramite un bus ad alta velocità. Le dimensioni di una griglia possono variare da piccole - confinata ad una rete di pochi computer all interno di una società, per esempio, a grandi collaborazioni pubbliche in molte aziende e reti. È con la nascita del Grid computing, che vengono coniati nuovi termini come Virtual Organization, col quale ci si riferisce all insieme dinamico di individui o istituzioni, definiti attorno a un insieme di condizioni e di regole per la condivisione delle risorse. Tutte queste organizzazioni virtuali condividono alcuni elementi comuni tra di loro, comprese le preoccupazioni e le esigenze, ma possono variare di dimensione, di obbiettivi, di durata, e di struttura. I requisiti principali per il Grid computing possono essere riassunti in questo modo: Integrare e coordinare risorse, stabilendo un insieme di regole e permessi di condivisione garantite da procedure di autenticazione e autorizzazione. Gestire le risorse in modo trasparente, gli utenti devono accedere alle risorse remote come se fossero locali. Garantire servizi in termini di : performance, sicurezza, tolleranza ai guasti, disponibilità e tempi di risposta. 5

16 Accounting delle risorse: le informazioni sono raccolte in un database (Home Location Register) che non si appoggia su alcun archivio centrale, ma su una rete di server indipendenti usati per mantenere i record delle transazioni effettuate dagli utenti sulle risorse (il servizio può essere usato per tracciare classiche informazioni computazionali come il tempo di CPU o l uso della memoria). Tali informazioni possono essere aggregate in diversi modi: la granularità arriva fino al singolo job eseguito sul Grid Figura 1.1: Virtual Organization Solitamente l architettura Grid è rappresentata come una clessidra o come nell immagine 1.3 in cui viene evidenziato il parallelismo con il modello ISO/OSI. Come si può vedere dalle due figure l infrastruttura è divisa su più livelli: Fabric Connectivity Resource Collective 6

17 Figura 1.2: Modello a clessidra Application Il livello Fabric è il livello che fornisce le risorse che possono essere di tipo computazionale,oppure sistemi di storage o di rete, o ancora cataloghi e sensori. Ma una risorsa può essere anche un entità logica,come un file system distribuito, un cluster di computer. Per accedere a queste risorse vengono utilizzati i protocolli della griglia. Il livello Connectivity definisce il cuore dei protocolli di comunicazione e di autentificazione richiesti per le transazioni di rete per lo specifico Grid. I protocolli di comunicazione abilitano lo scambio di dati tra le risorse del livello Fabric.I requisiti di comunicazione includono trasporto, routing e naming. Il protocollo di autentificazione è costruito sui servizi di comunicazione per fornire meccanismi di sicurezza crittografica, allo scopo di verificare l identità di utenti e risorse. Le soluzioni per gli ambienti di VO devono avere le seguenti caratteristiche : Single sign on: l utente deve essere capace di fare il log in una sola volta e avere l accesso multiplo alle risorse del Grid definite nel livello Fabric, senza ulteriori interventi dell utente 7

18 Figura 1.3: Confronto tra l architettura Grid e il modello ISO/OSI Delegation: l utente deve essere in grado di dotare un programma con l abilità di eseguire a nome suo, in modo che quest ultimo possa accedere alle risorse per le quali l utente è autorizzato Integration with various local security solutiuons: ogni fornitore di risorse dovrebbe implementare le soluzioni per la sicurezza locale in modo che non interferiscano con quelli pre-esistenti User-based trust relationships: per permettere a un utente di usare risorse da più provider contemporaneamente, senza che il sistema di sicurezza richieda all utente di ri-autentificarsi Il livello Resource costruito sul livello Connectivity è utilizzato per definire dei protocolli per l iniziazione sicura, per il monitoraggio, e il controllo delle operazioni di condivisione sulle risorse individuali. Il layer Resource implementa questi protocolli invocando le funzioni del livello Fabric per accedere e controllare le risorse locali. I protocolli del livello Resource si interessano delle risorse individualmente e quindi ignora i problemi dello stato globale. Ci sono due classi di protocolli per il layer Resource : Information protocols che sono usati per ottenere informazioni circa la struttura e lo stato delle risorse. Management protocols sono usati per negoziare l accesso alle risorse condivise, specificando i requisiti delle risorse e le operazioni che devono 8

19 essere eseguite. Quindi i protocolli di management sono responsabili per l istanziazione di relazioni di condivisione. Il livello Collective, a differenza del livello Resource che focalizza l attenzione su una singola risorsa., contiene protocolli e servizi che non sono associati a una specifica risorsa ma piuttosto sono globali e catturano le interazioni tra collezioni di risorse. Esso possono implementare una grande varietà di comportamenti di condivisione senza imporre nuovi requisiti su risorse che devono essere condivise. Per esempio: Directory services permette ai partecipanti della VO di scoprire l esistenza e le proprietà delle risorse della VO Co-allocation, scheduling and brokering services permettono ai partecipanti della VO di richiedere l allocazione di una o più risorse per uno specifico scopo e di schedulare i task sulle risorse appropriate Monitoring and diagnostics service supporta il monitoraggio delle risorse della VO. Data replication services supporta la gestione delle risorse di storage della VO in modo da massimizzare le performance dell accesso ai dati. Grid-enabled programming systems abilita modelli di familiaretà che sono usati in ambiente Grid. Software discovery services scova e seleziona la miglior implementazione software e la piattaforma di esecuzione in base ai parametri del problema da risolvere L ultimo livello dell architettura Grid comprende le applicazioni degli utenti che lavorano in un ambiente VO. La figura sottostante mostra una vista dal lato del programmatore dell architettura Grid. Le applicazioni sono costruite in termini di servizi definiti a ogni livello. A ogni livello sono stati definiti protocolli che forniscono l accesso a servizi utili: management delle risorse, accesso ai dati, scoperta delle risorse e tant altro. Ad ogni livello possono essere definiti API la cui implementazione scambia messaggi con gli appropriati servizi per far si che vengano eseguite le azioni desiderate. 9

20 Figura 1.4: I protocolli,servizi,api dei livelli Collective e Resource possono essere combinati in molti modi per fornire funzionalità alle applicazioni Componenti di un sistema Grid In qualsiasi infrastruttura Grid i componenti fondamentali sono gli stessi. Esso è composto da : 1. Computing element : è l insieme di risorse di elaborazione localizzate in un sito(un cluster). Un CE include un Grid Gate che agisce come una generica interfaccia col cluster. 2. Worker Node : sono i veri e propri nodi che ospitano l elaborazione dei dati. Essi sono gestisti dal CE. 3. Storage Element: fornisce un accesso uniforme alle risorse di dati di storage. Inoltre supporta diversi protocolli e interfacce per l accesso ai dati. 4. User Interface: può essere una qualsiasi macchina dove gli utenti hanno un account personale e dove i loro certificati sono installati. Da una UI un utente può essere autentificato e autorizzato per usare le risorse. Le operazioni principali che si possono eseguire sono sottomettere un job, cancellare un job, richiedere la lista di tutte le risorse usate per eseguire un job, prendere l output di un job finito o mostrare lo status di uno in esecuzione. 10

21 Figura 1.5: I software development kits implementano delle API specifiche. Queste API a loro volta utilizzano i protocolli Grid per interagire coi servizi di rete che forniscono le capacità agli utenti. Gli SDKs possono fornire funzionalità che non sono direttamente mappate con uno specifico protocollo, ma possono combinare più operazioni di diversi protocolli 5. Information Service: fornisce le informazioni riguardo le risorse e il loro stato. 6. Workload management: ha lo scopo di accettare i job degli user, di assegnarli al compute element più appropriato e salvare il loro stato e prenderne l output Un esempio di sistema Grid: SCOPE S.Co.P.E. è un iniziativa dell Università degli Studi di Napoli Federico II. Nasce con l obiettivo di creare un infrastruttura di supercomputing general purpose, basata sul paradigma del Grid e sulle più moderne tecnologie di calcolo distribuito, a supporto della ricerca di base e delle Piccole e Medie Imprese. Sulla base di una preesistente infrastruttura di rete metropolitana, che connette al gigabit tutte le maggiori strutture di ricerca dell Ateneo, l architettura di S.Co.P.E. prevede di integrare le risorse di calcolo e storage attualmente disponibili, con nuovo hardware ad alte prestazioni. Tali risorse 11

22 Figura 1.6: Architettura Grid verranno infine inglobate in un unica piattaforma di tipo Grid, basata su middleware di nuova generazione, integrandosi altresì con le altre infrastrutture di griglia nazionali ed internazionali. L architettura finale consiste dunque nella creazione di una Grid Metropolitana capace di unire le sinergie dei dipartimenti e strutture di ricerca afferenti o in collaborazione con la Federico II, distribuite nella città di Napoli. S.Co.P.E. promuove inoltre lo sviluppo scientifico per la ricerca di base e l innovazione tecnologica, finalizzata alla creazione di codici innovativi ed applicativi nei 4 settori strategici: Scienze del Microcosmo e del Macrocosmo Scienze dei Materiali e dell Ambiente Scienze della Vita In queste aree di interesse è impegnata una grande comunità scientifica forte delle esperienze e delle competenze maturate in numerosi progetti pregressi ed in stretta collaborazione con l INFN ed altre strutture di ricerca 12

23 locali e nazionali. I nodi principali coinvolti nel progetto sono il CAMPUS- Grid, sede del polo scientifico dell ateneo e del Data Center SCoPE, le strutture di Ingegneria, il Policlinico ed il CSI (Centro di ateneo per i Servizi Informativi). Le risorse di calcolo del Data Center del progetto S.C.O.P.E vantano di hardware ad altissime prestazioni, che lo rendono una struttura molto competitiva nel campo del calcolo intensivo ad alte prestazioni. L intera struttura dispone di: Più di 300 Worker Node bi-processore quadcore a 64bit 8 o 16GB RAM (con un totale di 2432 core), in soluzione blade; 16 lame per shelf, con connessioni infiniband a 10 Gbit/sec; Risorse di storage di 200 TB connesse in Fiber Channel; 32 TB di storage iscsi connesse in Ethernet; 10 Storage Element con connessioni Fiber Channel; 33 Rack con raffreddamento interno; Rete infiniband su ogni macchina. Per quanto riguarda le risorse di rete invece il data center dispone di una divisione LAN e WAN: LAN: Dorsale di rete a 10 Gbit/sec. Rete ridondata divisa a 1 Gbit/sec. Rete a bassa latenza infiniband a 10 Gbit/sec. WAN Collegamenti Intranet a 2.4 Gbit/sec, ridondati Collegamenti Internet a 1 Gbit/sec, ridondati 13

24 glite glite è un middleware per il Grid Computing usato negli esperimenti LHC del CERN e dal datacenter S.Co.P.E. È stato implementato dalla collaborazione di più di 80 persone di 12 tra centri di ricerca industriali o accademici in Europa. glite fornisce un framework per costruire applicazioni nel calcolo distribuito e tra le risorse di storage attraverso Internet. I servizi di glite sono utilizzati da più di 250 centri di calcolo e usati da più di ricercatori in Europa e nel resto del mondo. I primi prototipi furono sviluppati tra il 2004 e il 2005 ma è solo nel 2006, con l uscita della release glite 3.0 che diventa il middleware ufficiale del progetto Enabling Grids for E-scienceE (EGEE). I componenti principali di glite sono : User Interface Computing element Storage Element Information service Workload management La User Interface è il punto di acceso al Grid glite. Si trova su una qualsiasi macchina dove gli utenti hanno un account personale e dove il loro certificato è stato installato. Dalla UI, un utente può essere autorizzato e autenticato ad usare le risorse, e ad accedere alle funzionalità offerte. Inoltre fornisce alcune operazioni base sul Grid : visitare la lista di tutte le risorse disponibili per eseguire un determinato job sottomettere job cancellare job richiamare l output dei job finiti mostrare lo stato dei job sottomessi 14

25 richiamare le informazioni di logging del job copiare, replicare e cancellare i file dal Grid richiamare lo stato di risorse differente dall Information System. Il Computing Element è come detto prima un insieme di risorse di calcolo localizzate in un sito. Questi include un GridGate che agisce come interfaccia generica per il cluster, un Local Resourse Management System/LRMS) e un insieme di Worker Nodes. Lo Storage Element fornisce un accesso uniforme alle risorse di data storage. Supporta vari tipi di protocolli d accesso ai dati. Inoltre spesso le risorse vengono gestite da un Storage Resource Manager, che è un servizio che fornisce capacità come la migrazione trasparente tra dischi. L Information Service fornisce informazioni sulle risorse del Grid e sul loro stato. Le informazioni sono essenziali per il funzionamento dell intero Grid in quanto è attraverso l IS che le risorse sono scoperte. Le informazioni pubblicate sono anche usate per scopi di monitoraggio e accounting. Lo scopo del Workload management System è di accettare i job degli utenti, per assegnargli il Computing Element, per memorizzare il loro stato e richiamare il loro output. Il Resource Broker è la macchina dove girano i servizi di WMS. I job che devono essere sottomessi sono descritti usando il linguaggio Job Description Language (JDL).La scelta del CE al quale è inviato il job è fatta da un processo chiamato match-making, che selezioni il primo, tra i CE disponibili, che soddisfano i requisiti espressi dall utente Limiti del Grid Una caratteristica ormai evidente nella stragrande maggioranza dei moderni Data Center è che continuano ad espandersi sempre più sia in termini di investimento tecnologico, sia in termini di capacità di calcolo. Assistiamo anno dopo anno, infatti, alla progressiva introduzione di nuovi apparati o soluzioni software, anche differenti tra loro, al fine di soddisfare esigenze crescenti ed agevolare comunicazione e rapporti verso clienti e fornitori. Si nota spesso, dunque, come le tradizionali metodologie, finora utilizzate per il monitoraggio degli ambienti e degli apparati dei Data Center, non siano più sufficienti 15