• Problem Solving Environment • Grid Computing – Globus – MPICH-G2 – NWS • Autonomic Computing • L’ambiente CAMELot – L’Automa Cellulare – Il linguaggio CARPET • CAMELotGRID – L’architettura – Il modello basato sull’isoefficienza – Esempio di esecuzione Problem Solving Environment Risorse di computazione per la risoluzione di problemi in domini specifici Usati per implementare, compilare, eseguire e visualizzare applicazioni relative ad una precisa classe di problemi Permettono agli utenti di concentrarsi esclusivamente sull’applicazione tralasciando i dettagli hardware/software Finora sono stati eseguiti su macchine sequenziali Nascono alcune esigenze: Coinvolgere sistemi paralleli e distribuiti che permettano la collaborazione e lo scambio di dati e di risorse Utilizzare sistemi che forniscano capacità computazionali elevate S O L U Z I O N E Le Griglie Computazionali Consentono di condividere ed utilizzare la potenza di elaborazione di una serie di risorse collegate in rete tramite le infrastrutture di Internet. Permettono livelli di potenza, altrimenti impossibili, accessibili ad ogni partecipante alla comunità scientifica o privata Coinvolgono migliaia di server in tutto il modo, superando qualsiasi barriera fisica Le comunità di condivisione di risorse all’interno delle griglie sono chiamate Organizzazioni Virtuali (VO) Forniscono una capacità elaborativa elevata e dunque possono essere adottate nell’implementazione dei PSE Le Griglie Computazionali si basano su di una struttura stratificata dalla forma a “clessidra” Base: Nodi locali che fondamentali mettono a disposizione i servizi Middleware che provvede all’accesso uniforme ai servizi locali. Qui si aggiungono i nuovi servizi. Parte Superiore: Applicazioni ad alto livello avviate sulla griglia Collo: Il Globus Toolkit è uno dei maggiori strumenti software per la gestione dei servizi in ambienti di Griglia. Resource Specification Language (RSL) GRAM il modulo di gestione delle risorse GEM il modulo di gestione di file eseguibili Nexus il modulo per la comunicazione GASS GSI il modulo per l’accesso remoto ai dati il modulo per la sicurezza GRIS GIIS HBM MDS il modulo per Il monitoraggio il modulo per l’Information Service Presentiamo ora due strumenti importanti per ambienti di griglia: • MPICH-G2 : tool di programmazione a scambio di messaggi • NWS : sistema di monitoraggio di host e reti che come vedremo in seguito, sono stati utilizzati anche nell’implementazione del nostro sistema CAMELotGRID Eterogeneità elevata Scalabilità crescente da poche unità a centinaia di risorse Dinamicità estrema Vantaggi: Aumento delle potenzialità computazionali dei sistemi Problemi: Complessità di gestione e di manutenzione Frequenti malfunzionamenti delle risorse L'Autonomic Computing Paradigma proposto nel 2001 dall’IBM Idea: Creare un sistema simile al sistema nervoso autonomico umano Un sistema computazionale autonomico deve essere in grado di gestire se stesso e ottimizzare il suo rendimento senza alcun intervento umano - Kephart, J.O. / Chess, D.M. (IBM Thomas J. Watson Research Center) : “The vision of Autonomic Computing”, IEEE Computer Society – January 2003 La struttura di un sistema autonomico si basa su otto principi fondamentali: 1. Auto Definizione 2. Auto Protezione 3. Auto Ottimizzazione 4. Auto Riparazione 5. Auto Configurazione 6. Cosciente del contesto in cui opera 7. Aperto 8. Capace di anticipare le richieste Autonomic Manager (CONTIENE LE REGOLE AUTONOMICHE DEFINITE DALL’UTENTE) APPLICAZIONE UTENTE MIDDLEWARE AUTONOMICO (Monitoraggio, analisi e verifica, attuazione) SISTEMA COMPUTAZIONALE PSE per sviluppare, compilare, eseguire e visualizzare modelli ad Automi Cellulari in grado di simulare fenomeni complessi E’ un’implementazione portatile su computer paralleli, basata su MPI. Rete di piccole e identiche celle, connesse uniformemente e sincronizzate. Funzione di transizione viene usata ad ogni passo da ogni cella per determinare il suo nuovo stato a partire dallo stato corrente e dagli stati di alcune celle che compongono un vicinato della cella stessa. Applicazioni significative: produzione di modelli in grado di simulare il comportamento intrinseco distribuito e di auto-organizzazione dei fenomeni. L’ambiente CAMELot offre: un linguaggio, chiamato CARPET, che può essere usato per definire algoritmi cellulari ed eseguire comandi di computational steering un’interfaccia grafica (GUI) per editare, compilare, configurare, eseguire, pilotare la computazione molti strumenti per la visualizzazione on-line e off-line dei dati di output Un’interfaccia con Database Geografici (GIS) •Computational Steering •Bilanciamento del carico E’ un linguaggio di programmazione per la definizione di modelli double px; basati int succ; su automi cellulari e delle loro funzioni di transizione int succ; { if (step == 1) { px = ( (double)rand() ) / RND_MAX; cadef update (cell_ground, tree); { dimensionif2;(px < pb) update (cell_ground, land); radius 1; else update 1); Una state sezione di (cell_display, dichiarazione conosciuta come (short ground,display); } sezione cadef DEFinition) neighbor cross(CA [4] ([0,-1]North, [-1,0]West, [0,1]South, [1,0] East); else parameter (pb =0.6); { dist Distance (zona1); region (zona1 (40,60,30,40,1,1,1,200,1) &succ) == fire) && if ( (MaxRegion(zona1_ground, } < 30) && (dist > 20) ) update (cell_ground, dead); Una sezione(dist per la definizione della funzione di else if ( (cell_ground == tree) && transizione (North_ground == fire || East_ground == fire || (West_ground == fire || South_ground == fire) ) steering update (cell_ground, fire); { if (step == 1) else if ( (cell_ground == fire) ) update (cell_ground, dead); { steer_colrange (ground, 0.0, 5.0); funzione di Una sezione per la definizione della if ( (InRegion(zona1) ) && (cell_ground == land) ) steer_colrange (display, 0.0, 5.0); update (cell_display, 10); steering (opzionale) } else update (cell_ display, cell_ground); } } endsteering } APPLICAZIONE UTENTE Regole autonomiche AUTONOMIC MANAGER Modello dell’isoefficienza CAMELotGRID CAMELotGRID GRID-Aware Modulo Scheduler Monitor dinamico delle risorse Evento Monitor delle risorse dell’esecuzione Resource Hardware Repository MPICH-G2 DUROC MDS GRAMs Griglia Computazionale RisorsePool di Risorse Banda di Disponibili Connessione Comunicazione via vendor-MPI e TCP-IP Griglia Computazionale NWS c a αi b a foreach z,y,x trans_function(x,y,z,step) copy_boundary exchange_boundary copy_CA d bytes A Width B Height C Depth D Dimensione del substato in byte P Numero dei processori tf(i) Tempo di esecuzione medio della funzione di transizione sull’iesimo processore ts(i,i+1) Tempo start-up per le comunicazioni dall' iesimo processore all' i+1esimo processore tb(i,i+1) Tempo necessario per inviare un byte nella comunicazione fra iesimo processore all' i+1esimo processore tas(i) Tempo sequenziale additivo dell' iesimo processore tap(i) Tempo parallelo additivo dell' iesimo processore Cl(i) Carico di Cpu disponibile riferito all’iesimo processore tf’ (i) tempo di esecuzione media della funzione di transizione sull’i-esimo processore (su una cella). Nel calcolo viene considerata anche la percentuale disponibile di CPU. Definiamo fi = 1/ tf’(i) (indice della frequenza di calcolo riferita ad un singolo processore) αi = fi/f f i 1 f i p dove Ogni processore avrà assegnata una sottogriglia dell’automa cellulare di dimensione: ai bc Il carico computazionale risulterà bilanciato: fi 1 1 abc abc i t f 'i abc t f ' i abc t f 'i f f t f 'i f Il tempo di esecuzione parallelo può essere modellato come: abc abc Tp max {t as (i) Texc (i)} max {t as (i) Texc (i)} f f Dove : Texc(i)= ts(i,i-1) + b c d tb(i,i-1) + ts(i,i+1) + b c d tb(i,i+1) che indicano i tempi di scambio bordi e di latenza con i vicini di destra e di sinistra. Otteniamo come risultato finale: abc p p Tp maxi 1 { t ap (i)} 4b c d maxi 1 {t b (i, i - 1) } f 1.Stima del numero di processori da coinvolgere nell’esecuzione GRID-Aware 2.Raccolte diScheduler tutte le informazioni relative alle caratteristiche delle risorse a disposizione e della rete di comunicazione MPICH-G2 3.Calcolo delle porzioni in cui suddividere l’automa cellulare in base alle potenzialità delle macchine DUROC 4.Scrittura dell’esecuzione dei file di impostazione e avvio GRAMs Si applica il modello di predizione per stimare il tempo di esecuzione Monitor dinamico delle risorse Evento Resource Hardware Repository MDS NWS APPLICAZIONE UTENTE Regole autonomiche AUTONOMIC MANAGER CAMELotGRID Monitor dinamico delle risorse Evento GRID-Aware Scheduler Resource Hardware Repository MPICH-G2 DUROC MDS NWS GRAMs Pool di Risorse Comunicazione via vendor-MPI e TCP-IP Griglia Computazionale 1) 3) 4) 5) 6) 2) L’utente crea il programma CARPET chedidefinisce ilRisorse modello adestrae automa L’NWS analizza leinformazioni e dei la processori rete comunicazione ed Lo scheduler Durante L’MDS scheduler raccoglie l’esecuzione può calcola le ora avviare ilrisorse ilnumero Monitor l’esecuzione sulle dinamico risorse disponibili da delle coinvolgere sulla griglia partendo provvede dalale cellulare dache eseguire. All’interno della sezione dirispettate. steering inserisce le regole informazioni sulle disponibilità didall’utente. CPU vengano e sui Avendo tempi dipoi banda valore dell’efficienza controllare le regole desiderata autonomiche a disposizione Ine latenza caso contrario i dati autonomiche che desidera vengano rispettate. Ad esempio:delleePerformance, forniti un lancia dall’MDS evento allo e dall’NWS scheduler eche utilizzando interrompe il modello l’esecuzione provvede ad provvede effettuare aIl lepartizionare modifiche l’automa cellulare fra i varieprocessori • valore di necessarie efficienza E da ottenere quello minimo da non superare durante l’esecuzione • Ogni quante iterazioni effettuare il controllo autonomico Macchine a disposizione: K1, K2, K3, K4, Minos, Icarus (LAN dell’ICAR-CNR) Processori: 11 (Minos è una macchina mono-processore) Modello di predizione basato sull’isoefficienza per stimare i tempi di esecuzione. Confronto con i tempi di esecuzione misurati. Host tas (μsec) tf ’ (μsec) CPU (numero) Memory k1, k2, k3, k4 728 2.382 PIII 800M (2) 256 M Minos 469 1.741 PIV 1,5G (1) 375M Icarus 564 1.923 PIII 1,133M (2) 2048M Host (processori) Tempo di esecuzione Tempo di comunicazione Tempo totale k4 , icarus (2) 71.91 101.70 173.71 k4 , icarus (4) 36.27 102.64 139.33 Minos , k4 (2) 68.31 141.36 209.74 Minos , icarus (3) 42.06 148.74 190.04 icarus , minos , k4 (5) 27.73 161.63 189.49 Host (processori) Tempo di esecuzione Tempo di comunicazione Tempo di copy_boundary Tempo totale k4 , icarus (2) 55.93 100.22 27.51 184.67 k4 , icarus (4) 30.8 106.46 18.59 155.48 Minos , k4 (2) 55.92 156.05 23.09 235.89 Minos , icarus (3) 34.53 115.21 23.29 172.95 icarus , minos , k4 (5) 24.78 120.68 12.09 158.37 Host (processori) Tempo totale Tempo totale Stimato Misurato Errore relativo k4 , icarus (2) 173.71 184.67 6% k4 , icarus (4) 139.33 155.48 10.38% Minos , k4 (2) 209.74 235.89 11.2% Minos , icarus (3) 190.04 172.95 -9.8% icarus , minos , k4 (5) 189.49 158.37 -19.65% Aumento della capacità computazionali utilizzando le griglie Grossi vantaggi nell’utilizzo della strategia dell’autonomic computing sia dal punto di vista dell’autonomia dei sistemi sia perché permette all’utente di disinteressarsi della gestione dell’hardware e del software Il modello basato sull’isoefficienza si è dimostrato efficace, naturalmente sarebbe necessario effettuare esperimenti con un numero di macchine maggiore e magari con una griglia sparsa un po’ nella rete globale In futuro si potrebbe entrare più nel merito dell’infrastruttura autonomica, fornendo magari un’interfaccia utente grafica che ottimizzi la fase di raccolta delle informazioni iniziali e dei risultati ottenuti con l’esecuzione