Auto-Ottimizzazione Basata su Simulazione in Sistemi di Tipo Autonomic

Transcript

1 Università degli Studi del Sannio Dottorato di Ricerca in Ingegneria dell Informazione Auto-Ottimizzazione Basata su Simulazione in Sistemi di Tipo Autonomic Relatore: Prof. Umberto Villano Coordinatore: Prof. Michele Di Santo Candidato: Emilio Pasquale Mancini 2006

2 Indice 1 I sistemi di tipo autonomic L architettura di riferimento Livelli di maturità La descrizione dei sistemi e la simulazione MetaPL Estensioni per i Web Services Esempio Estensioni per i sistemi di tipo autonomic HeSSE L uso del simulatore HeSSE Interfacce Web Service per i tools HeSSEws MetaPLws L auto-ottimizzazione MAWeS L architettura di MAWeS La gestione delle simulazioni: il package core La gestione dei servizi di secondo livello: Il package services La gestione dei filtri: il package metafilter MAWeSclient Ciclo di esecuzione Sviluppo di Web Services di tipo autonomic Sistemi ad agenti mobili

3 Indice 2 4 Risultati sperimentali Applicazioni orientate ai servizi Valutazione delle prestazioni del framework Applicazioni soft-realtime Servizi composti Servizi composti e riconfigurazione su invocazione Servizi composti e riconfigurazione reattiva Ricerche correlate Conclusioni A Core ed estensioni di MetaPL A.1 MetaPL Core A.2 Estensione per OpenMP A.3 Estensione per MPI A.4 Estensione Object Oriented B Integrazione in Eclipse: Perforce B.1 HeSSEgraphs Indice analitico Riferimenti bibliografici

4 Introduzione I sistemi distribuiti sono intrinsecamente complessi, sia dal punto di vista dell analisi, sia da quello dell implementazione che della manutenzione. La loro importanza nel panorama informatico è cresciuta sempre più negli ultimi anni, ricevendo un impulso dalla diffusione delle reti di comunicazione e dall esigenza di avere sistemi sempre più performanti che, allo stesso tempo, non presentassero costi proibitivi. Con lo sviluppo delle tecnologie di comunicazione, dalle socket alle librerie a scambio di messaggi, da CORBA ai Web Services, costruire questi sistemi è diventato più semplice da un punto di vista tecnico. Purtroppo accanto a questa semplicità, si è avuto un forte incremento della complessità architetturale. I sistemi particolarmente complessi si sono rivelati, naturalmente, anche difficilmente gestibili, piuttosto vulnerabili e, in alcuni casi, quasi impossibili da ottimizzare. Nell ambito della ricerca sui sistemi informatici distribuiti, è stato quindi aperto un filone teso a rendere i sistemi autonomi, in grado, cioè, di gestire autonomamente i parametri che riguardano la propria configurazione (sistemi self-configuring), i propri errori (sistemi self-healing), la propria sicurezza (sistemi self-protecting), la propria ottimizzazione (sistemi self-optimizing). L obiettivo di questa tesi è lo studio dei sistemi autonomi autoottimizzanti e il conseguente sviluppo di un framework, chiamato MAWeS, con il quale poter implementare applicazioni autonome auto-ottimizzanti. Inizialmente sarà presentata una panoramica introduttiva sui sistemi autonomi (autonomic), quindi verranno descritti gli strumenti e

5 Indice 4 le tecnologie usate nello sviluppo del framework. Saranno, quindi, descritte in dettaglio la progettazione e l implementazione del framework MAWeS, facendo un particolare riferimento alle architetture orientate alla cooperazione dei servizi (SOA). Ed infine, nell ultima parte, saranno mostrati i casi di studio usati per la validazione del sistema e ne saranno discussi i risultati, prima di delineare gli sviluppi futuri del presente lavoro.

6 1 I sistemi di tipo autonomic Nell uso dei sistemi informatici di dimensioni medio-grandi ci si scontra con una difficoltà sempre maggiore per la gestione e la configurazione man mano che crescono le esigenze degli utenti e ci si rivolge a nuove tecnologie. In particolare l integrazione di strumenti diversi porta al moltiplicarsi di interconnessioni rendendo questi sistemi più vulnerabili sia agli errori, sia ai cali di prestazioni, sia ad azioni fraudolente. Per questo si parla di una vera e propria crisi della complessità del software [34]. Questa complessità sta diventando il fattore limitante nello sviluppo futuro. Inoltre l impiego di reti di elaboratori su larga scala per la comunicazione ed il calcolo favorisce l uso di applicazioni distribuite eterogenee in cui i singoli elementi si occupano di una moltitudine di differenti task, che possono spaziare, ad esempio, dai processi per il controllo interno, alla presentazione di contenuti Web, alla gestione supporto per il cliente. In aggiunta questo scenario è reso più complesso dall uso sempre più diffuso dei dispositivi mobili; non sono più rari i casi di dipendenti che comunicano da remoto con i sistemi aziendali usando laptop, PDA o telefoni cellulari, ciascuno basato su differenti tecnologie. Questa complessità è difficilmente controllabile da parte di operatori umani. Il controllo manuale richiede tempo, è costoso e soggetto ad errori, inoltre lo sforzo legato a questo tipo di controllo tende ad incrementarsi molto velocemente. Una delle soluzioni proposte per fronteggiare tutto ciò ha preso spunto dalla capacità del sistema nervoso autonomo umano di auto-gestirsi. È nato così un nuovo filone di ricerca, fortemente finanziato dalla IBM, quello dei sistemi di tipo

7 1 I sistemi di tipo autonomic 6 autonomic. L Autonomic Computing vuole affrontare la complessità tecnologica utilizzando la tecnologia stessa, cioè inserendo nei sistemi moduli in grado di renderli autonomi nelle aree della configurazione, dell ottimizzazione, della riparazione e della sicurezza [7, 34, 74]. I principi dell autonomic computing, ed il termine stesso autonomic, derivano dalla medicina, si sta tentando, cioè, di imitare il sistema nervoso autonomo che sovrintende alle funzioni vitali dell organismo umano di cui la persona non ha coscienza, come ad esempio il battito cardiaco. Allo stesso modo, le capacità autonomic di auto-gestione cercano di anticipare le necessità del sistema informatico e risolvono problemi col minimo intervento umano possibile basandosi su schemi e politiche predefiniti. Uno degli ambiti in cui l approccio dell autonomic computing sembra più promettente è quello dei sistemi ad alta affidabilità e disponibilità. Figura 1.1. L Autonomic Computing concentra i propri sforzi in quattro aree: selfconfiguring, self-optimizing, self-healing e self-protecting. Queste funzioni di controllo vengono normalmente suddivise in quattro grandi categorie: auto-configurazione, auto-riparazione, autoottimizzazione ed auto-protezione (figura 1.1): Self-configuring: installare, configurare, ed integrare sistemi informatici complessi è un attività che, oltre ad essere dispendiosa in

8 1 I sistemi di tipo autonomic 7 termini di tempo, può essere particolarmente soggetta errore. I sistemi autonomic affrontano queste problematiche ripromettendosi di configurarsi automaticamente in accordo con politiche di alto livello. In questo modo nel momento in cui si introducono nuovi componenti il resto del sistema si adatterà alla loro presenza. Lo scopo di quest area dell autonomic computing è di fornire capacità di auto-configurazione all intera infrastruttura IT, non solo ai singoli elementi. Self-healing: l obiettivo di quest area è permettere ai sistemi di tipo autonomic di riconoscere, diagnosticare e rimediare ai problemi derivanti da malfunzionamenti software e hardware, tramite, ad esempio, un test di regressione. Utilizzando le conoscenze sulla configurazione di sistema, un componente per la diagnosi potrebbe analizzare le informazioni provenienti dai file di log, integrandole con dati ricavati da altre fonti. Il sistema, poi, farà corrispondere le patch software conosciute coi risultati di diagnosi e installerà quella appropriata Self-optimizing: i middleware complessi possono avere centinaia di parametri che devono essere settati correttamente affinché il sistema sia eseguito in maniera ottimale. Di solito, inoltre, questi sono integrati con altri ugualmente complessi. Di conseguenza, il performance-tuning di un sotto-sistema può causare effetti non previsti sull intero sistema. I sistemi autonomic si propongono di ricercare modi per migliorare le proprie prestazioni, identificando e fissando le opportunità di rendere se stessi più efficienti dal punto di vista delle performance o dei costi. Auto-ottimizzazione, può significare anche riallocazione di risorse in risposta a cambiamenti dinamici nel carico di lavoro. Self-protecting: quest area dell autonomic computing si ripropone di anticipare, rilevare, identificare, e proteggersi dai comportamenti ostili. I sistemi dovrebbero rilevare minacce appena esse si verifichino ed eseguire azioni correttive che li rendano meno vulnerabili. I comportamenti ostili in questo contesto, possono includere, ad esempio, accessi ed utilizzi non autorizzati o l infezione e la proliferazione di virus.

9 1.1 L architettura di riferimento 1.1 L architettura di riferimento 8 Nell architettura di riferimento proposta dalla IBM, [30], i sistemi di tipo autonomic possono essere visti come delle raccolte di elementi a loro volta autonomic, ciascuno dei quali conterrà risorse ed erogherà servizi per gli altri elementi del sistema. Ciascuno di essi tenta di operare il più possibile localmente, richiedendo l attenzione ai livelli più alti solo se necessario. Un singolo elemento autonomic consiste di una o più risorse gestite, associate ad un singolo gestore che le controlla e le rappresenta. L elemento gestito sarà in buona sostanza, equivalente a ciò che si può trovare in un normale sistema non autonomic con la possibilità di monitorarlo e controllarlo attraverso un autonomic manager. La distinzione tra autonomic manager e risorsa gestita potrebbe divenire puramente concettuale piuttosto che architettonica, oppure scomparire, cedendo il passo ad elementi autonomic completamente integrati con funzionamenti ed interfacce ben definite, ma anche con qualche vincolo sulla struttura interna. Ogni elemento autonomic sarà responsabile della gestione del proprio funzionamento e del proprio stato interno, nonché della gestione delle sue interazioni con un ambiente composto in gran misura da segnali e messaggi provenienti dagli altri elementi e dal mondo esterno. Il suo funzionamento interno e le relazioni con gli altri saranno guidati dagli obiettivi che il suo progettista ha prefissato, dagli altri elementi che hanno autorità su di esso, o dalle commesse degli elementi di pari grado col suo consenso tacito o esplicito. Un elemento, come già detto, potrebbe richiedere assistenza agli altri al fine di realizzare i propri scopi. In questo caso, esso si assumerebbe la responsabilità di ottenere le risorse necessarie dagli altri elementi, e di trattare i casi eccezionali, come il guasto di una risorsa richiesta. Ai livelli più bassi, il range di funzionamenti e relazioni dell elemento, e l insieme di elementi con cui esso interagisce, potrebbe essere relativamente limitato e codificato. Su questi presupposti un sistema di calcolo autonomic viene organizzato nei layer e nelle parti mostrate nella figura 1.2 [54]. Queste parti sono connesse utilizzando un enterprise service bus che consente ai componenti di collaborare utilizzan-

10 1.1 L architettura di riferimento 9 do meccanismi standard come i Web Services. L enterprise service bus integra vari blocchi. Touchpoint per le risorse gestite; Basi di conoscenza; Autonomic Manager; Manual Manager. Figura 1.2. Architettura di riferimento dell Autonomic Computing. Il livello più basso contiene i componenti del sistema, o risorse gestite (managed resources), che costituiscono l infrastruttura IT. Queste managed resources possono essere qualsiasi tipo di risorsa (hardware o software) e potrebbero avere attributi di self-managing embedded. Il livello successivo incorpora interfacce consistenti e standard alla gestione per l accesso ed il controllo delle managed resources. Queste interfacce standard sono fornite tramite i touchpoint. I livelli superiori automatizzano alcune porzioni del processo IT utilizzando un autonomic manager. Una particolare risorsa dovrebbe avere uno o più touchpoint autonomic manager, ciascuno dei quali

11 1.1 L architettura di riferimento 10 implementa il loop di controllo relativo. Il terzo livello dal basso nella figura 1.2, illustra ciò descrivendo un autonomic manager per le quattro categorie introdotte in precedenza (self-configuring, self-healing, self-optimizing e self-protecting). Il quarto livello contiene gli autonomic manager che orchestrano gli altri autonomic manager. E questa orchestrazione a fornire le capacità autonomic a tutto il sistema incorporando i loop di controllo che hanno la visione più ampia di tutta l infrastruttura IT. Il livello più alto illustra i manager manuali (Manual Manager) che forniscono un interfaccia di gestione del sistema comune per gli operatori utilizzando una consolle integrata. I vari manager, autonomic e manual, possono ottenere e condividere la conoscenza attraverso le basi di conoscenza (knowledge sources). Un autonomic manager automatizza alcune funzioni di management in accordo con le politiche definite attraverso l interfaccia di gestione. L autonomic manager implementa il loop di controllo mostrato in figura 1.3: La funzione di monitoraggio fornisce i meccanismi per raccogliere, aggregare, filtrare e fornire il resoconto dei dettagli collezionati da una risorsa gestita. La funzione di analisi fornisce i meccanismi per correlare e modellare situazioni complesse. Tali meccanismi consentono ai manager di avere capacità di apprendimento sull ambiente IT ed aiutano a predire situazioni future. La funzione di pianificazione fornisce i meccanismi per la costruzione delle azioni necessarie al raggiungimento degli obiettivi. La funzione di esecuzione fornisce i meccanismi che controllano l esecuzione del piano con la possibilità di effettuarne l aggiornamento. Le quattro funzioni consumano e generano conoscenza. Questa è continuamente condivisa in modo tale che le decisioni possano esser prese grazie ad informazioni migliori. Un touchpoint di una risorsa gestita consente alle interfacce di sensori ed attuatori, che l autonomic manager usa, di interagire con una risorsa gestita. Una base di conoscenza è un implementazione di un repository che fornisce accesso alla conoscenza in accordo con le interfacce prescritte

12 1.1 L architettura di riferimento 11 Figura 1.3. Dettagli funzionali dell autonomic manager. dall architettura, condivise tra gli autonomic manager. La conoscenza può essere ottenute in tre modi diversi: 1. La conoscenza è passata all autonomic manager (es. politiche ed obiettivi); 2. La conoscenza è recuperata da una base di conoscenza esterna (es. conoscenze storiche di una risorsa); 3. L autonomic manager può creare conoscenza tramite la funzionalità di monitoraggio (che raccoglie le informazioni di una particolare risorsa attraverso i suoi sensori) o di esecuzione (che indica le azioni da prendere come risultato del monitoraggio e della pianificazione). Un touchpoint è un componente del sistema che espone lo stato e le operazioni di gestione per una risorsa del sistema. Un autonomic manager comunica con il touchpoint tramite l interfaccia di gestione (manageability interface). Il touchpoint è l implementazione dell in-

13 1.1 L architettura di riferimento 12 terfaccia di gestione per una specifica risorsa o un insieme di risorse gestibili. L interfaccia di gestione per controllare una managed resource è organizzata nelle interfacce dei suoi sensori ed attuatori. Il comportamento di sensori ed attuatori per una specifica risorsa viene realizzato, in un touchpoint, mappando le interfacce di sensori ed attuatori standard ad uno o più componenti dell interfaccia di gestione della risorsa. In questo modo la complessità dell interfaccia di gestione è ridotta, in quanto agli autonomic manager viene sempre offerta una interfaccia standard, sebbene i diversi componenti dell interfaccia sono associati a diversi tipi di risorse. Un sensore consiste in un insieme di proprietà che rendono disponibili informazioni sullo stato della risorsa accessibili attraverso operazioni get e un insieme di eventi di notifica nel caso in cui avvengono dei cambiamenti nello stato della risorsa che meritano attenzione. Un attuatore consiste in: un insieme di operazioni set, che consentono di cambiare lo stato della risorsa, ed un insieme di operazioni implementate dagli autonomic manager che consentono alla risorsa gestita di consultarsi con il suo manager. Sensori ed attuatori sono collegati tra loro. Per esempio, un cambiamento nella configurazione che avviene per mezzo dell attuatore dovrebbe riflettersi in una notifica di cambiamento di configurazione attraverso l interfaccia del sensore. Un manual manager è un implementazione dell interfaccia utente che consente ad un professionista IT di eseguire alcune funzioni di gestione manualmente. Il manual manager può collaborare con altri autonomic manager dello stesso livello o autonomic manager di orchestrazione. Il manual manager è la rappresentazione architetturale dell attività umana e tipicamente coinvolge un tecnico che utilizza una console di gestione. Un enterprise service bus è un implementazione che aiuta l integrazione di altri blocchi costitutivi (per esempio, autonomic manager e touchpoint) guidandone l interazione. Si può considerare ad esempio uno scenario di funzionamento di un autonomic manager. Si assume che ci sia un loop di controllo all inter-

14 1.1 L architettura di riferimento 13 no di un Web Server il cui obiettivo è di assicurare che l utilizzo della CPU non ecceda il 90%. Se la soglia viene superata, il sistema deve prendere dei provvedimenti. Il processo monitor è responsabile della raccolta e dell organizzazione dei dati. Una grossa fetta di conoscenza è fornita dalle informazioni di monitoraggio. E molto importante monitorare solo i dati che saranno utilizzati dal loop di controllo. Se, ad esempio, si memorizzano log di grandi dimensioni, le performance potrebbero essere deteriorate perchè sarebbero continuamente analizzati dati che non hanno alcuna rilevanza sul sistema. Un autonomic manager dovrà interrogare il sistema per vedere quale è l utilizzo della CPU e poi consegnare i dati all analyzer. L analyzer dovrà leggere i dati e determinare se è necessario fare qualcosa. Un cambiamento nell utilizzo della CPU fa sì che l analyzer invochi l oggetto di pianificazione per correggere il problema. Il ciclo di controllo è basato sulle policy; se una data condizione è soddisfatta deve essere eseguita un azione, in altri termini c è la necessità, di pianificare ed eseguire una risposta. Per l esempio riportato, la fase di pianificazione dell autonomic manager dovrà schedulare un azione di riavvio del server e vedere se ciò corregge il problema. Così come menzionato in precedenza, una grande quantità di conoscenza acquisita viene dal primo passo del ciclo di controllo: il monitoraggio. È importante considerare il tipo di dati che la conoscenza richiede. È semplice registrare tutte le transazioni che un Web Server produce, ma il tempo di elaborazione per estrapolare quei dati può avere un impatto eccessivo sul ciclo di controllo. Quando si assembla un sistema di calcolo autonomic, bisogna pianificare la conoscenza che deve essere registrata, che persistenza utilizzare e quali specifiche informazioni si stanno cercando. Non tutta la conoscenza richiesta, comunque, deriva da attività di monitoraggio; è possibile che un team di esperti progetti un insieme di scenari da aggiungere alla base di conoscenza del sistema. È anche possibile avere un database di sintomi ed azioni correttive. Per esempio, una rapida ricerca sul sintomo database server is down può avere come azione correttiva reboot the database server.

15 1.2 Livelli di maturità Livelli di maturità La maturità di un sistema autonomic è schematizzata in cinque livelli. Si parte dal livello base e si prosegue con quello gestito, predittivo, adattativo ed infine autonomic: Livello base: è il punto iniziale in un ambiente IT, ed il livello a cui si trovano alcuni sistemi IT oggi. Ogni elemento dell infrastruttura è gestito indipendentemente dall operatore che lo gestisce manualmente; Livello gestito: le tecnologie di gestione dei sistemi possono di solito raccogliere informazioni da fonti disparate, riducendo, man mano che aumenta la complessità dell ambiente, il tempo che l amministratore impiega a raccogliere e sintetizzare le informazioni; Livello predittivo: vengono introdotte nuove tecnologie per fornire correlazione tra i diversi elementi dell infrastruttura. Questi elementi possono cominciare a riconoscere procedure e a prevedere configurazioni ottimali; Livello adattativo: i sistemi stessi possono automaticamente eseguire l azione opportuna sulla base delle informazioni disponibili e della conoscenza su ciò che sta accadendo nel sistema; Livello autonomic: le operazioni dell infrastruttura sono governate da politiche ed obiettivi economici. Gli utenti interagiscono con la tecnologia autonomic per monitorare processi economici e modificare gli obiettivi.

16 2 La descrizione dei sistemi e la simulazione L obiettivo di questo lavoro è proporre una metodologia per rendere auto-ottimizzanti delle applicazioni informatiche. Si cerca di fare in modo, cioè, che un applicazione distribuita possa valutare autonomamente come configurarsi su un determinato sistema, quindi senza intervento esterno e basandosi essenzialmente sulla conoscenza che ha di se e del sistema che la ospita. Poiché le interazioni in programmi paralleli e distribuiti sono molto complesse da valutare analiticamente è stato scelto un approccio di tipo simulativo: l applicazione valuta l impatto che ha una determinata configurazione di parametri simulando un esecuzione. Per raggiungere l obiettivo di rendere un sistema autonomo dal punto di vista dell ottimizzazione delle prestazioni, si deve poterlo descrivere. È necessario, cioè, conoscere approfonditamente il sistema sia nelle sue singole parti sia nelle interazioni tra esse. Per questo è stato usato ed esteso un meta-linguaggio studiato per la descrizione di programmi paralleli: MetaPL [47, 48]. Mentre per ottenere la simulazione delle esecuzioni delle applicazioni è stato usato un simulatore di sistemi eterogenei: HeSSE [56]. Per entrambi è stata studiata un interfaccia Web Service in modo da facilitarne l integrazione in sistemi SOA. 2.1 MetaPL Il formato XML (Extensible Markup Language) è un formato per i file testuali derivato dallo Standard Generalized Markup Language (SGML, ISO 8879). I documenti XML sono fisicamente formati da

17 2.1 MetaPL 16 unità di memorizzazione chiamate entità, che possono contenere caratteri o altre entità. Logicamente un documento è composto da dichiarazioni, elementi, commenti caratteri e istruzioni di trasformazione ciascuno dei quali indicato esplicitamente da opportuni tag [70]. Ogni documento comincia con un entità radice. XSLT e XSL specificano un linguaggio per definire i fogli di stile per XML, vale a dire documenti di trasformazione. XSL include un vocabolario per specificare la formattazione e lo stile di un documento XML usando lo standard XSLT per specificare come un documento XML può essere trasformato in un altro [69]. Figura 2.1. Schema di principio del ciclo di vita dei documenti MetaPL. MetaPL è un linguaggio basato su XML per la descrizione di programmi paralleli. La sua caratteristica principale è l estensibilità, ottenuta sfruttando le caratteristiche di XML, mentre il suo scopo è di fornire un approccio unificato alla programmazione parallela, sia in fase di progettazione, sia nelle fasi successive. In particolare in questo lavoro, MetaPL sarà usato soprattutto dal punto di vista dell analisi e dell ottimizzazione delle prestazioni [47, 48]. È indipendente dal linguaggio di programmazione e può supportare diversi paradigmi di programmazione o librerie di comunicazione. Il nucleo centrale (core) può essere esteso tramite estensioni scritte

18 2.1 MetaPL 17 come DTD di XML, esse possono introdurre nuovi costrutti nel linguaggio. Nel seguito verranno descritte le estensioni sviluppate nell ambito di questa tesi. Il core definisce un piccolo insieme di elementi per le attività di base dei processi (cicli, switch, dichiarazione di variabili, creazione di processi...), mentre le estensioni definiscono ciò che caratterizzerà i programmi che si descrivono (si veda l appendice A). Sono state scritte infatti estensioni per le librerie a scambio di messaggi, per la memoria condivisa, per la programmazione object oriented. L uso effettivo di MetaPL è però basato sui concetti di Filtro e di Vista. Una vista è una descrizione del programma meno generale e più specifica; partendo da un documento MetaPL si possono ottenere, ad esempio, viste che siano diagrammi UML, documentazione in HTML o altri file MetaPL. La descrizione MetaPL, ha quindi lo scopo di concentrare in un unico documento strutturato, un insieme di informazioni legate ad un software esistente o in fase di progetto. Queste informazioni possono venire successivamente manipolate e raffinate per mettere in evidenza aspetti peculiari, o per usarle con software opportuni. Ogni nuova vista viene ottenuta applicando un insieme di filtri. Un filtro è un documento XSLT che genera una nuova vista a partire da un documento XML, ed è quindi strettamente legato ai propri DTD. La possibilità di applicarli deriva dalla strutturazione del linguaggio. Inoltre anche essi sono facilmente estensibili. In altri termini ogni DTD che definisce un estensione per MetaPL, indica quali sono gli elementi (tag) che è possibile usare e come usarli, cioè come annidarli negli altri tag e quali attributi inserire. Ogni filtro che fa riferimento a un DTD conosce quali sono questi elementi e come trasformarli in qualcos altro. Ad esempio ad un estensione che definisce un operazione di somma può corrispondere un filtro che deriva una funzione in linguaggio C corrispondente a quella descritta nel documento MetaPL. La figura 2.1 mostra come è possibile fare interagire tutti gli elementi appena descritti per sfruttarne le caratteristiche al fine di fare progettazione e analisi di programmi paralleli. Un documento Meta-

19 2.1 MetaPL 18 PL, che è un file testuale in formato XML, viene scritto basandosi su un insieme di estensioni, a loro volta implementate come file testuali in formato DTD (o XML Schema). Usando i filtri adatti (file testuali XSLT) una o più volte in cascata, il documento principale viene trasformato in nuove viste pronte da essere usate per lo sviluppo, l analisi, la simulazione o quanto altro le necessità dello sviluppatore detteranno. Operativamente per ottenere queste trasformazioni è possibile usare uno qualunque degli strumenti disponibili per validare e trasformare file XML. Nei test effettuati quello che ha permesso di ottenere i risultati migliori in termini di efficienza e potenzialità d uso, è stato Apache Ant. Pur essendo stato progettato esplicitamente per gestire progetti in linguaggio Java, esso offre facility per il trattamento dei documenti XML. In particolare integra i processori Xerces e Xalan [28, 65]. Per usare Ant è necessario scrivere un file di comandi in formato XML (build file), chiamato di solito build.xml, in cui viene riportata la sequenza dei comandi da eseguire. Tra le varie opzioni disponibili in questo strumento c è, appunto, la possibilità di usare trasformazioni xslt. Di seguito si mostra un frammento di build file di ant usato per applicare un filtro a del codice MetaPL: <? xml version =" 1.0 "?> <project name =" LogAnalysis - RAMPDS " default =" transform ">... <target name =" transform "> <xslt in=" Application / LogAnalysis. xml " out =" tmp / traces / LogAnalysis. view.1. xml " style =" Filters / oomethodunrolling. xsl "> < outputproperty name =" method " value =" xml "/> < outputproperty name =" standalone " value =" yes "/> < outputproperty name =" encoding " value =" iso8859_1 "/> < outputproperty name =" indent " value =" yes "/> </ xslt >

20 2.2 Estensioni per i Web Services 19 </ target >... </ project > 2.2 Estensioni per i Web Services Un Web Service è un interfaccia che descrive un insieme di operazioni, accessibili mediante messaggi in formato XML. La caratteristica distintiva dei Web Services rispetto agli altri tipi di strumenti e librerie per la programmazione distribuita, è l uso dello standard SOAP per la codifica dei messaggi, e dello standard WSDL (Web Services Description Language) per la definizione e la pubblicazione delle interfacce. Entrambi sono documenti in formato XML [8]. <! ELEMENT WebService ( wsmethod *) > <! ATTLIST WebService name CDATA # REQUIRED > <! ELEMENT wsmethod ( wsmethodmsgsize, ANY *) > <! ATTLIST wsmethod name CDATA # REQUIRED > <! ELEMENT wsmethodmsgsize (# PCDATA ) > <! ELEMENT wsremotework (# PCDATA ) > <! ELEMENT wsmethodcall (# PCDATA ) > <! ATTLIST wsmethodcall ws CDATA # REQUIRED > <! ATTLIST wsmethodcall name CDATA # REQUIRED > Figura 2.2. DTD che definisce le estensioni WS. L estensione per i Web Services permette la descrizione di interfacce remote e delle chiamate dei client a tali interfacce. Nella figura 2.2 è mostrato il DTD che definisce l estensione, sono presenti quattro elementi [38]: WebService è l elemento che identifica l intero Web Service; wsmethod indica un singolo servizio e contiene la logica del servizio stesso; wsmethodmsgsize indica le dimensioni del messaggio;

21 2.2 Estensioni per i Web Services 20 wsremotework indica il carico legato all esecuzione del servizio; wsmethodcall indica una chiamata ad un servizio già definito. <? xml version =" 1.0 " encoding =" ISO_8859-1" standalone =" yes "?> < xsl: transform version =" 1.0 " xmlns:xsl =" http: // /1999/ XSL / Transform "> < xsl:output method =" text " indent ="no" standalone =" yes "/> < xsl:template match ="*" > < xsl:apply - templates / > </ xsl:template > < xsl: template match =" WebService " > <xsl:value -of select " /> < xsl:text > </ xsl:text > <xsl:value -of select "/> </ xsl:template > < xsl: template match =" classmodule " > </ xsl:template > < xsl: template match =" Task " > </ xsl:template > < xsl:template match =" wsmethod "> </ xsl:template > </ xsl: transform > Figura 2.3. Esempio di trasformazione XSLT basata sull estensione per Web Services. Accanto al DTD sono stati definiti una serie di filtri. In figura 2.3 e 2.4 ne sono mostrati due che gestiscono rispettivamente i Web Services ed i servizi. Nel primo caso il filtro estrae semplicemente l elenco dei Web Services riferiti da un documento MetaPL, nel secondo vengono analizzati i servizi offerti e vengono riportate alcune informazioni (nome, carico e dimensioni) che saranno utilizzate come traccia in una simulazione Esempio Le figure 2.5 e 2.6 mostrano un esempio della descrizione MetaPL di un Web Service, mentre la figura 2.7 mostra un frammento di

22 2.2 Estensioni per i Web Services 21 <? xml version =" 1.0 " encoding =" ISO_8859-1" standalone =" yes "?> < xsl: transform version =" 1.0 " xmlns:xsl =" http: // /1999/ XSL / Transform "> < xsl:output method =" text " indent ="no" standalone =" yes "/> < xsl:template match ="*" > < xsl:apply - templates / > </ xsl:template > < xsl: template match =" WebService " > < xsl:apply - templates / > </ xsl:template > < xsl: template match =" classmodule " > </ xsl:template > < xsl: template match =" Task " > </ xsl:template > < xsl:template match =" wsmethod "> <xsl:value -of select " /> < xsl:text > </ xsl:text > <xsl:value -of select "/> < xsl:text > </ xsl:text > <xsl:value -of select "/> </ xsl:template > </ xsl: transform > Figura 2.4. Esempio di trasformazione XSLT basata sull estensione per Web Services codice della descrizione di un client. L applicazione di esempio, chiamata LogAnalysis, è un tool per l analisi dei log che verrà descritto approfonditamente nel capitolo 4.1. Per la prototipizzazione di LogAnalysis viene scritta inizialmente una singola classe (figura 2.5), che sarà il back-end del Web Service finale. La classe LogAnalysisImpl viene progettata in questo contesto usando un ulteriore estensione MetaPL per la programmazione orientata agli oggetti. Nel frammento mostrato vengono riportati i soli nomi e il tipo dei metodi disponibili. Ognuno dei metodi della classe LogAnalysisImpl viene quindi mappato direttamente su un servizio del Web Service LogAnalysis (figura 2.6) usando il tag methodcall. Poiché la chiamata ad un servizio web è un operazione complessa e dispendiosa, nel modello bisogna tener conto anche dei dati scambiati e del carico dovuto allo

23 2.3 Estensioni per i sistemi di tipo autonomic 22 < classmodule name =" loganalysis " > < class name =" LogAnalysisImpl " > < description > Test bed for WS traces. </ description > < method name =" LogAnalysisImpl " type =" void " access =" public " /> < method name =" getlogrow " type =" String " access =" public " /> < method name =" findaddresses " type =" String []" access =" public " /> <method name =" renew " type =" void " access =" public "/> </ class > </ classmodule > Figura 2.5. Descrizione MetaPL dell interfaccia di un applicazione basata su Web Services. stack di chiamata SOAP. Questi vengono dichiarati esplicitamente con wsmethodmsgsize e wsremotework, in quando i singoli messaggi possono venire arricchiti dall applicazione che li spedisce a seconda delle proprie esigenze. Infine il client dell applicazione web di figura 2.7, viene descritto come una normale applicazione MetaPL, inserendo delle chiamate WSCall descritte nell estensione Web Services. Nel caso specifico vengono eseguite dieci iterazioni di tre chiamate consecutive ai servizi di LogAnalysis. 2.3 Estensioni per i sistemi di tipo autonomic Nello sviluppo delle estensioni di MetaPL per i sistemi autonomi è stato considerato principalmente l uso che ne è stato fatto nel framework MAWeS (capitolo 3) [42 44]. Quindi più che descrivere in dettaglio tutti i vari aspetti da tenere in conto quando si progetta un sistema autonomo, si sono privilegiati i punti che riguardano l autoottimizzazione, ed in particolare l individuazione dei parametri di cui ricercare i valori migliori, e la specifica dei loro domini e dei vincoli da imporre. Nella figura 2.8 è riportato il DTD dell estensione, in esso vengono specificati cinque elementi: Autonomic: è l elemento che raggruppa l estensione;

24 2.3 Estensioni per i sistemi di tipo autonomic 23 < WebService name =" LogAnalysis " > < wsmethod name =" stub " type =" void "> < wsmethodmsgsize > 100 </ wsmethodmsgsize > < methodcall module =" loganalysis " class =" LogAnalysisImpl " name =" getlogrow " / > < wsremotework time =" 150 " /> </ wsmethod > < wsmethod name =" getlogrow " type =" String "> < wsmethodmsgsize > 100 </ wsmethodmsgsize > < methodcall module =" loganalysis " class =" LogAnalysisImpl " name =" getlogrow " / > < WSremotework time =" 150 " /> </ wsmethod > < wsmethod name =" findaddresses " type =" String " > < wsmethodmsgsize > 100 </ wsmethodmsgsize > < methodcall module =" loganalysis " class =" LogAnalysisImpl " name =" getlogrow " / > < WSremotework time =" 150 " /> </ wsmethod > < wsmethod name =" renew " type =" void "> < wsmethodmsgsize > 100 </ wsmethodmsgsize > < methodcall module =" loganalysis " class =" LogAnalysisImpl " name =" getlogrow " / > < WSremotework time =" 150 " /> </ wsmethod > </ WebService > Figura 2.6. Descrizione MetaPL di un applicazione basata su Web Services. <Task > <Loop start ="1" end ="10"> <Task > <WSCall ws=" LogAnalysis " method =" stub " /> < WSlocalworktime time =" 1" / > <WSCall ws=" LogAnalysis " method =" renew " /> < WSlocalworktime time =" 1" / > < WSCall ws =" LogAnalysis " method =" getlogrow " / > < WSlocalworktime time =" 150 " / > <WSEnd /> </ Task > </ Loop > </ Task > Figura 2.7. Descrizione MetaPL di un client di Web Services.

25 2.3 Estensioni per i sistemi di tipo autonomic 24 Parameter: indica quali sono i parametri da considerare nell ottimizzazione, e permette di specificarne il dominio; Value: se il parametro può assumere solo un numero limitato di valori questi vengono specificati nell elemento Value; Constrain: indica un vincolo tra i parametri, viene specificato come un espressione booleana cha ha come operando i nomi dei tag Parameter. Target: indica l elemento da considerare nell analisi dell output del simulatore. Quest estensione non è stata progettata per l uso con i filtri standard di MetaPL, quanto per l uso in congiunzione con il framework MAWeS. <! ELEMENT Autonomic ( Parameter *, Constrain *, Target ) > <! ELEMENT Parameter ( Value *) > <! ELEMENT Constrain (# PCDATA ) > <! ELEMENT Value (# PCDATA ) > <! ELEMENT Target (# PCDATA ) > <! ATTLIST Parameter name CDATA # REQUIRED > <! ATTLIST Parameter type CDATA # IMPLIED > <! ATTLIST Parameter min CDATA # IMPLIED > <! ATTLIST Parameter max CDATA # IMPLIED > Figura 2.8. DTD per le estensioni autonomic di MetaPL. L esempio di un istanza del DTD è riportato in figura 2.9, dove sono indicati tre parametri per l ottimizzazione e viene impostato un vincolo. Si presuppone che il programma possa funzionare solo con 4, con 6 o con 10 processi utilizzando contemporaneamente 2 oppure 3 server usando due tipi di politica (statica e dinamica) per un totale di 12 configurazioni possibili. Nell esempio è inoltre presente un vincolo che impone che il numero di processi attivabili nell applicazione debba essere doppio di quello dei server. In questo modo il numero di configurazioni possibili si riduce a 4 (2,4,static, 3,6,static, 2,4,dynamic, 3,6,dynamic).

26 2.4 HeSSE < Autonomic > < Parameter name =" NumberOfProcesses " > <Value >4</ Value > <Value >6</ Value > <Value >10 </ Value > </ Parameter > < Parameter name =" NumberOfServers " > <Value >2</ Value > <Value >3</ Value > </ Parameter > < Parameter name =" ServerChoicePolicy " > <Value >Static </ Value > <Value > Dynamic </ Value > </ Parameter > < constrain > NumberOfProcesses = NumberOfServers * 2 < constrain > </ Autonomic >... Figura 2.9. Frammento di un documento MetaPL in cui sono evidenziate le estensioni autonomic. 2.4 HeSSE HeSSE (Heterogeneous S ystem S imulation E nvironment) è uno strumento orientato alla simulazione di un applicazione per un ampia gamma di tipi di sistemi distribuiti e con differenti carichi di rete e computazionali. Risponde, cioè, all esigenza di predire e valutare il comportamento di un applicazione quando questa viene usata in diversi ambienti e con diverse condizioni [38, 50, 51]. L approccio modulare di HeSSE permette di descrivere sistemi distribuiti eterogenei connettendo componenti semplici [4]. Ogni componente riproduce i comportamenti (dal punto di vista prestazionale), di una parte del sistema ad un dato livello di dettaglio. Ogni componente deve riprodurre comunque il comportamento funzionale e temporale del sottosistema che rappresenta, intendendo come comportamento funzionale l insieme dei servizi esportati agli altri componenti (che da essi possono essere richiesti), e come comportamento temporale il

27 2.4 HeSSE 26 tempo speso nell esecuzione di tali servizi. La modellazione viene fatta in primo luogo a livello di architettura. Ad esempio le prestazioni del livello fisico come quelle di un determinato tipo di processore, può venire descritta con semplici modelli analitici o tramite simulazione comportamentale, cioè tenendo conto del tempo totale di calcolo senza considerare il comportamento delle singole istruzioni. HeSSE usa le tracce per descrivere le applicazioni. Una traccia è un file che registra tutte le azioni di un programma che sono rilevanti per la simulazione. Per esempio la traccia per un applicazione MPI è una sequenza di burst di CPU e richieste all ambiente di run-time [41]. Ogni traccia è la rappresentazione di una specifica esecuzione di un programma parallelo. I file di traccia sono descrizioni di un applicazione orientate all applicazione, tipicamente vengono ottenute dalla modifica dell applicazione. Quando l applicazione non è disponibile, perchè ad esempio non è stata ancora sviluppata, possono essere generati a partire da meta-codice, come ad esempio MetaPL, cui si è accennato precedentemente. Figura Schema di una sessione di simulazione con HeSSE.

28 2.4 HeSSE 27 Il processo di analisi e simulazione per una data applicazione può essere rappresentato schematicamente come in figura La fase di descrizione di un sistema si evolve in tre passi: Descrizione dell applicazione: produzione del codice MetaPL; Modello dell architettura: definizione del modello dell architettura del sistema; Calibrazione del modello: valutazione dei parametri temporali. La descrizione di un applicazione consiste essenzialmente nello sviluppo di prototipi in MetaPL in modo da generare tracce necessarie per simulare un esecuzione. La definizione di un modello, quindi, consiste nella scelta o nello sviluppo di componenti HeSSE che saranno composti in un file di configurazione. Una volta fatto ciò è possibile riprodurre l evoluzione del sistema. L ultimo passo consiste nell ottimizzazione del modello eseguendo dei benchmark sul sistema di destinazione in modo da inserire le informazioni temporali nel simulatore e nelle descrizioni MetaPL L uso del simulatore HeSSE Operativamente il simulatore viene usato scrivendo tre file di configurazione: Libs.HeSSE: che specifica le librerie del simulatore da utilizzare (figura 2.12); Config.HeSSE: che specifica gli elementi coinvolti nella simulazione e come questi vengono connessi (figura 2.13); Commands.HeSSE: che specifica comandi addizionali associati a ciascun elemento specificato in Config.HeSSE, e caratteristici dell implementazione dell elemento stesso (figura 2.14). Ogni elemento è caratterizzato da un identificatore numerico univoco indicato da CID (Component Identifier) nei file di configurazione. Ciascun elemento che definisce un sistema da simulare è quindi definito nel file Config.HeSSE attraverso il proprio tipo (presente nelle librerie) e attraverso il CID insieme alle connessioni tra con gli altri elementi (tag Connect in figura 2.13). A seconda del tipo ad ogni componente

29 < HeSSEtrc > <! -- simulator output -- > < Configure >... </ Configure > 2.5 Interfacce Web Service per i tools 28 <! -- configuration steps -- > < StartAll > <! -- simulation components to be started -- > < StartComponent =" MPM_Interface " ID="10" time ="0"/> </ StartAll > <! -- events in the simulated run -- > < Simulation > < createprocess ID="14" com =" MPM_App " time =" 0.01 "/>... < MPM_Broadcast ID="16" com =" MPM_App " time =" "/>... <End ID="26" com =" MPM_App " time =" " /> </ Simulation > <! -- simulation closure steps -- > < Deconfigure >... </ Deconfigure > </ HeSSEtrc > Figura Frammenti dell output di HeSSE. possono essere associati uno o più comandi nel file Commands.Hesse (figura 2.14). Node.dl Ethernet. dl EthDriver. dl PKT.dl MPM.dl Web.dl Figura Esempio di file Libs.HeSSE. 2.5 Interfacce Web Service per i tools Le descrizioni MetaPL e le simulazioni HeSSE rendono possibile analisi delle prestazioni tali da identificare i colli di bottiglia e configu-

30 2.5 Interfacce Web Service per i tools 29 Component CID 10 MPM_ Interface EndComponent Component CID 11 SMP_ Node EndComponent... Component CID 14 WebServer EndComponent Component CID 16 WebService EndComponent Component CID 1 Eth_ Switch EndComponent Component CID 2 MPM_ Data EndComponent Connect CID 13 PIN 1 CID 11 PIN 1 EndConnect Connect CID 12 PIN 1 CID 13 PIN 2 EndConnect... EndConfig Figura Frammento di file Config.HeSSE. rare di conseguenza sia i sistemi sia le applicazioni finali. Oltre all uso tramite linea di comandi ed interfaccia grafica [39], questi strumenti sono stati provvisti di un interfaccia Web Service che incapsula i servizi di descrizione, simulazione e analisi. Queste interfacce possono essere sfruttate da coloro che voglio accedere da remoto al simulatore o integrate in programmi che possono usarle per automatizzare i processi di analisi delle prestazioni.

31 Command SetTID CID 16 TID long 1 EndCommand Command Schedulable CID 10 Mode string false EndCommand Command Schedulable CID 20 Mode string false EndCommand Command SetDaemonPar CID 10 tp0 double e -12 tp1 double e -05 tp2 double e -01 tp3 double EndCommand Command SetDaemonPar CID 20 tp0 double e -12 tp1 double e -05 tp2 double e -01 tp3 double EndCommand Interfacce Web Service per i tools 30 Figura Frammento di file Commands.HeSSE HeSSEws HeSSE prende in input una serie di file di testo, producendo un file XML con gli eventi del modello simulato. Il Web Service HeSSEws permette di usare il simulatore da remoto, gestendone sia l esecuzione (runsimulation), sia l ambiente (operazioni su file e directory). Il modo in cui HeSSEws opera è descritto nel diagramma di sequenza di figura WS App rappresenta l applicazione che usa i servizi proposti. In prima istanza prepara l ambiente di simulazione creando una cartella di simulazione copiando i file necessari ed avviandovi la simulazione. Quando questa termina l applicazione web può richiedere il file XML che contiene il risultato (un frammento è riportato nella figura 2.11). L output di HeSSE è contenuto tra i tag <HeSSEtrc> </HeSSEtrc>,

32 2.5 Interfacce Web Service per i tools 31 ed è composto da diverse sezioni (elementi XML). I tempi calcolati dal simulatore sono raccolti dai tag Simulation, quindi, ad esempio, il tempo di esecuzione di un processo può essere ottenuto analizzando tale file. Figura Diagramma di sequenza di una sessione di simulazione usando l interfaccia basata su Web Services. HeSSEtrc è l elemento radice che contiene tutto l output di HeSSE; Configure è l elemento che descrive i passi compiuti duranti la configurazione della simulazione; StartAll è l elemento che indica l inizio della simulazione in tutti i componenti; Simulation contiene la sequenza di elementi che registrano le azioni di tutti i componenti durante la simulazione. Ciascun elemento corrisponde ad un azione, l attributo com indica il tipo di componente del simulatore, ID è un identificatore univoco del componente, time è il timestamp dell evento; Deconfigure è l elemento che descrive i passi compiuti durante il termine della simulazione. Tabella 2.1. Elenco dei tag principale usati nell output di HeSSE MetaPLws MetaPL opera su un insieme di file: documenti MetaPL, schema o DTD di XML, filtri e viste finali. Quindi il Web Service MetaPLws offre una serie di servizi che permettono di operare su essi. MetaPLws pubblica il servizio chiamato applyfilter, che applica un filtro ad un

33 2.5 Interfacce Web Service per i tools 32 documento MetaPL, ed execute, che esegue uno script (tipicamente una sequenza di filtri). La sintassi di questo sarà descritta nel capitolo seguente in quanto tutto il supporto al ciclo di vita dei documenti MetaPL è stato integrato nel framework MAWeS. Figura Diagramma di sequenza dell applicazione di filtri MetaPL.

34 3 L auto-ottimizzazione HeSSE e MetaPL permettono agli utenti di analizzare le prestazioni di un sistema, visto come insieme di software ed hardware, senza avviarne l esecuzione, e quindi, potenzialmente, quando si è ancora in fase di progetto. Inoltre, usati sinergicamente, semplificano l esplorazione di soluzioni alternative che offrono risultati più o meno validi, dando la possibilità di valutare rapidamente l uso di un applicazione in situazioni e su architetture diverse. Si può, ad esempio, valutare l impatto di una variazione del carico di rete su un applicazione distribuita. La velocità di simulazione, relativamente ad un esecuzione reale apre le porte alla possibilità di cercare a run-time le configurazioni migliori, intese come combinazioni migliori di parametri. Un software può quindi valutare lo stato del sistema che lo ospita ed il proprio stato, e quindi configurarsi in modo da migliorare le proprie prestazioni o ottimizzare l uso delle risorse. Conoscendo l architettura ed il software, si possono individuare una serie di parametri su cui il software ha il controllo che possono influenzarne le prestazioni, ad esempio su quanti processi dividere un compito, o quali macchine usare per un calcolo distribuito; per ognuno di tali parametri si può, quindi, individuare un dominio e porre dei vincoli. Ad esempio se si scelgono come parametri il numero m di macchine da utilizzare ed il numero p di processi da attivare, si può porre come dominio di m gli interi da 1 al numero di macchine disponibili (es. m [ ]), e come vincolo che ogni macchina abbia due processi attivi (p = 2m).

35 3.1 MAWeS 34 Allo scopo di studiare ed affrontare quanto appena esposto è stato sviluppato un framework che, integrandosi con il simulatore HeSSE, e sfruttando MetaPL, permette alle applicazioni che ne fanno uso di valutare le configurazioni di esecuzione ottimali, una volta che si conosca il sistema e le condizioni in cui questo si trova, siano esse misurate o presunte. Questo framework, chiamato MAWeS (MetaPL/HeSSE Autonomic Web Services), è stato progettato basandosi sugli standard dei servizi web in modo da sfruttarne le caratteristiche di interoperabilità, tenendo presente che l overhead delle comunicazioni SOAP è comunque trascurabile se paragonabile al tempo consumato nelle simulazioni iterative (figura 3.1) [8, 53]. Figura 3.1. Impatto della gestione e dell invio dei messaggi sul tempo di chiamata del servizio La possibilità di usare dati misurati o stimati per lo stato dei sistemi, apre la strada all ottimizzazione preventiva delle applicazioni: se un applicazione prevede un picco di carico per un determinato istante, può valutarne gli effetti preventivamente tramite simulazione, e quindi capire quale è la configurazione migliore per la situazione che si aspetta. È questo, ad esempio, il caso di un applicazione che fa streaming video, per cui si possono prevedere picchi di traffico a determinate ore. Si affronta in questo modo il problema dell ottimizzazione delle prestazioni da un punto di vista feedforward, di anticipazione, piuttosto che feedback, di reazione [43, 51, 60]. 3.1 MAWeS Nello studio e nello sviluppo del framework MAWeS si è voluto provare come fosse possibile automatizzare i processi di simulazione e predi-

36 3.1 MAWeS 35 Figura 3.2. Casi d uso del framework MAWeS. zione delle prestazioni in modo da sviluppare sistemi che si autoottimizzino. MAWeS offre i servizi di gestione del ciclo di vita dei documenti MetaPL, la gestione delle simulazioni HeSSE ed il sistema di ricerca delle configurazioni migliori (figura 3.2). All utente è demandato il compito di creare una descrizione dell hardware e del software, nonché di impostare una serie di filtri, scegliendoli, estendendoli o scrivendoli. Questi devono permettere di ottenere dei file di traccia usabili nelle simulazioni. L hardware e una parte dello strato software (ad esempio le librerie MPI) vengono invece descritti mediante file di configurazione di HeSSE. Il framework MAWeS è logicamente strutturato in tre livelli (figura 3.3): Frontend: permette l accesso ai servizi di MAWeS da parte dei client. Più che all aggiunta di funzionalità, questo modulo è preposto alla semplificazione dell uso dei servizi disponibili da parte dei moduli server; Core: è composto dai moduli che prendono le decisioni di ottimizzazione e coordinano le simulazioni e la generazione delle tracce;

37 3.2 L architettura di MAWeS 36 Interfacce WS: è l insieme dei Web Services usati per ottenere le simulazioni e le predizioni attraverso l uso di MetaPL e HeSSE. Figura 3.3. Schema della struttura logica di MAWeS. Attualmente il frontend di MAWeS fornisce un interfaccia, chiamata MAWeSclient, specifica per il linguaggio Java, che può essere estesa dalle applicazioni che vogliono usare il framework. Essa accetta in input un insieme di file che descrivono l applicazione in formato MetaPL (arricchito con le estensioni autonomic descritte nella sezione 2.3) ed il sistema ospite nel formato dei file di configurazione di HeSSE. Il Core di MAWeS sfrutta i servizi del sistema sottostante e dei moduli di gestione MetaPL/HeSSE per cercare le condizioni di esecuzione ottimali, per far ciò usa le informazioni contenute in questi file. 3.2 L architettura di MAWeS L activity diagram di figura 3.4 mostra le azioni che vengono effettuate durante l ottimizzazione dell esecuzione di un servizio. Queste azioni vengono inquadrate nei blocchi logici che compongono l applicazione ed il framework. Inizialmente il client applicativo richiede un servizio.

38 3.2 L architettura di MAWeS 37 Figura 3.4. Activity diagram del framework MAWeS

39 3.2 L architettura di MAWeS 38 Questo viene eseguito sull host che indicato nella richiesta, e, a seconda di come è stato configurato, avvia immediatamente o durante la propria esecuzione, il servizio di ottimizzazione. Questo può essere avviato in modo sincrono, ed è il caso di ottimizzazioni fatte nel momento della chiamata, o asincrono nel caso di ottimizzazioni avviate in seguito al variare delle condizioni del sistema. La richiesta del servizio di ottimizzazione avviene tramite il modulo MAWeSclient, che si occupa di inviare al core tutti i file necessari. Trattandosi di diversi documenti, che possono essere anche strutturati in directory, MAWeSclient li comprime con un algoritmo LZW standard e li invia al Web Service come attachment SOAP [53]. A questo punto il core estrae tutti i documenti dal messaggio, e comincia ad applicare i filtri indicati (con la modalità mostrata nella sezione successiva) in modo da produrre un insieme di tracce corrispondenti a configurazioni diverse del sistema. Ogni volta che questi filtri vengono applicati, il foglio di stile viene parametrizzato, usando i valori ottenuti dai parametri della descrizione MetaPL. Per ognuna delle configurazioni ottenute viene avviata una simulazione HeSSE, e vengono raccolti i risultati con i tempi di esecuzione. Alla fine, tra tutte le configurazioni simulate viene scelta quella con i tempi di esecuzione minori e restituita al client che ha avviato la richiesta di ottimizzazione. Il framework è organizzato in tre aree che ricalcano i casi d uso mostrati in figura 3.2. Queste tre aree corrispondono, nell implementazione a tre packages in linguaggio Java: core, metafilter e services (figura 3.5). Il package services contiene le interfacce ai motori simulativo e di filtraggio. Il package metafilter contiene il motore MetaPL, è quindi l implementazione del sistema di filtri e di script necessario per produrre le tracce di simulazione. Mentre il package core contiene la logica di gestione di MAWeS, quindi la generazione delle configurazioni, la coordinazione del filtraggio e delle simulazioni, la gestione delle aree di elaborazione temporanee e la gestione dei messaggi verso i client.

40 3.2 L architettura di MAWeS 39 Figura 3.5. Diagramma delle classi principali di MAWeS La gestione delle simulazioni: il package core La classe principale del core di MAWeS è la classe MAWeScore di cui di seguito si riporta un frammento. All interno di questa classe il metodo fondamentale è il metodo execute. Questo prende in input il pacchetto compresso contenente tutti i file che descrivono l applicazione e i riferimenti a quali sono i file MetaPL e di gestione dei filtri che dovranno essere presi in considerazione. public class MAWeScore { private static Log logger = LogFactory. getlog ( MAWeScore. class. getname ()); final MetaFilter metafilter ; final HeSSEParser hesseparser ; final HesseWrapper hessewrapper ; final MetaPLAutonomicParser metaplautopars ; public MAWeScore () throws Exception {... } public File execute ( File inzipf, String metaplflname, String scriptname ) throws Exception {...

41 3.2 L architettura di MAWeS 40 } } Di seguito è riportato un frammento dell algoritmo implementato nella funzione execute. Si può notare la sequenza delle azioni: impostazione dei valori dei parametri, valutazione dei vincoli, applicazione dei filtri, esecuzione delle simulazioni e valutazione dell output del simulatore. boolean someparmatermaychange = false ; do { final long t0 = System. currenttimemillis (); // Change parameter values... // Constrain while ( encon. hasmoreelements ()) { final String constrain = encon. nextelement (); final Evaluator e = new Evaluator ( constrain, enpar ); flag = flag && e. checkconstrain (); } if ( flag ) { // Apply filters if ( logger. isinfoenabled ()) logger. info ("[ MAWES CORE ] ("+ System. currenttimemillis ()+ ") Apply filters "); metafilter. execute ( sourcedir, scriptname, parameters ); // Execute HeSSE if ( logger. isinfoenabled ()) logger. info ("[ MAWES CORE ] ("+ System. currenttimemillis ()+ ") Start HeSSE simulation "); HesseWrapper. startsimulation ( sourcedir, ""); final File resultfile = new File ( sourcedir, MAWeS. props. getproperty (" hesse. outputfilename " )); if ( logger. isinfoenabled ()) logger. info ("[ MAWES CORE ] ("+ System. currenttimemillis ()+ ") End HeSSE simulation "); // Parse HeSSE output if ( logger. isinfoenabled ()) logger. info ("[ MAWES CORE ] Result analysis ("+ resultfile. getabsolutepath ()+ ")"); // Check if iterations must continue enpar = metaplautopars. params. elements (); while ( enpar. hasmoreelements () &&! someparmatermaychange ) { final Parameter p = enpar. nextelement (); someparmatermaychange = p. maychange (); }... } while ( someparmatermaychange );

42 3.2 L architettura di MAWeS La gestione dei servizi di secondo livello: Il package services La gestione degli strumenti di base (HeSSE e MetaPL) tramite interfaccia web è stata fatta con una semplice operazione di incapsulamento. In particolare di seguito viene riportato un frammento di codice estratto dalla classe che gestisce HeSSE: public class HeSSEwsImpl implements HeSSEws { private static Log logger = LogFactory. getlog ( HeSSEwsImpl. class. getname ());... public boolean startsimulation ( java. lang. String path ) throws java. rmi. RemoteException { if ( logger. istraceenabled ()) logger. trace (" startsimulation "); boolean out = false ; try { String env []={ " HeSSEBin ="+ properties. getproperty (" hesse. bin " )}; } } Runtime r= Runtime. getruntime (); Process p=r. exec (" properties. getproperty (" hesse. commandline "), env, new File ( path )); p. waitfor (); out = true ; } catch ( Exception e) { e. printstacktrace (); out = false ; if ( logger. iserrorenabled ()) logger. trace (" Hesse simulation failed : " +e. getmessage (), e); } return out ; La gestione dei filtri: il package metafilter L applicazione dei filtri è un operazione strettamente legata all applicazione che si sta modellando. È stata fatta, quindi, la scelta di descrivere la sequenza di filtri mediante uno script scritto in XML, il cui DTD è mostrato in figura 3.6. Questi script contengono un piccolo numero di elementi: metafilter è l elemento radice dello script; filter indica l applicazione di un filtro, si deve specificare il file a cui applicarlo, il file in ouptut e naturalmente il nome del filtro;

43 <? xml version =" 1.0 " encoding ="ISO "?> <! ELEMENT metafilter ( filter *, simulation ) > <! ATTLIST metafilter filterrepository CDATA # REQUIRED > 3.2 L architettura di MAWeS 42 <! ELEMENT filter ( echo *, param *) > <! ATTLIST filter in CDATA # REQUIRED out CDATA # REQUIRED filter CDATA # REQUIRED > <! ELEMENT echo (# PCDATA ) > <! ELEMENT param (# PCDATA ) > <! ATTLIST param name CDATA # REQUIRED type ( string int float ) " string " > <! ELEMENT simulation (# PCDATA ) > <! ATTLIST simulation hessebin CDATA # REQUIRED > Figura 3.6. DTD degli script di filtraggio. echo permette di inserire un messaggio definito dall utente nel file di log; param indica il nome dei parametri il cui valore sarà ricavato esternamente dal foglio di stile; simulation è un elemento opzionale che permette di avviare una simulazione direttamente dallo script. In generale questo tipo di script specificano quali filtri applicare, a quali file farlo e l ordine in cui applicarli. Inoltre è in questi script che deve essere esplicitamente attivata la simulazione, in modo da poter dare la possibilità di applicare ulteriori filtri anche all output del simulatore, nel caso in cui l utente decida che questo sia utile. La figura 3.7 mostra un esempio molto semplice di script che si uniforma a questo schema. Al documento MetaPL nbody.xml vengono

44 3.2 L architettura di MAWeS 43 applicati due filtri: il primo, flt.xsl, produce come output il file out.xml, il secondo, flt2.xml, viene applicato ad out.xml e produce il file out2.xml, alla fine viene avviata una simulazione HeSSE. <? xml version =" 1.0 " encoding ="ISO "?> <! DOCTYPE metafilter SYSTEM " scriptfilter. dtd " > < metafilter filterrepository =" http: // url / dir "> <! -- Filter the nbody file using the flt filter. --> <filter in=" nbody. xml " out =" out. xml " filter =" flt. xsl "> <echo >Filter 1</ echo > </ filter > <! -- Filter the nbody file using the flt filter. --> <filter in=" out. xml " out =" out2. xml " filter =" flt2. xsl " > <echo >Filter 2</ echo > <param name =" param1 " type =" string "> First parameter </ param > <param name =" param2 " type =" int " /> </ filter > < simulation /> </ metafilter > Figura 3.7. Esempio di script per il filtraggio. Figura 3.8. Esempio di applicazione dello script di figura MAWeSclient Il client MAWeS propone un implementazione Java che incapsula e semplifica le azioni necessarie a colloquiare con i servizi di MAWeS. Non implementa la logica legata all ottimizzazione, ma si limita a

45 3.2 L architettura di MAWeS 44 fornire facility per la gestione dei messaggi SOAP e delle directory di documenti MetaPL ed HeSSE che descrivono l applicazione. Di seguito è riportato un frammento di codice che evidenzia le funzioni fornite da MAWeS client: public class MAWeSclient { private MaweswsSoapBindingStub mawesws ; private MAWeSwsServiceLocator servicelocator ; public MAWeSclient ( URL address ) throws ServiceException { servicelocator = new MAWeSwsServiceLocator (); mawesws = ( MaweswsSoapBindingStub ) servicelocator. getmawesws ( address ); } private void addattachment ( File flattachment ) throws IOException {... } private void copyattachmentinfile ( AttachmentPart attpart, File outfl ) throws IOException, SOAPException {... } public long execute ( File dir, File outputdir, String metaplflname, String scriptname, CallTimes ct) throws IOException, RemoteException, SOAPException {... } } public long executeant ( File dir, File outputdir, String scriptname, String target, CallTimes ct) throws SOAPException, IOException {... } Ciclo di esecuzione I client sottomettono la descrizione dell applicazione al core di MAWeS, quindi i servizi del framework eseguono automaticamente le simulazioni necessarie e restituiscono l insieme dei valori dei parametri che individuano la configurazione migliore; i client a questo punto possono riconfigurarsi tenendone conto. Il processo di esecuzione mostrato in figura 3.9 si svolge, al livello logico, nei passi indicati di seguito: 1. Chiamata del servizio da parte del client: questo passo include la gestione del messaggio SOAP e l inclusione, come allegato compres-

46 3.2 L architettura di MAWeS 45 Figura 3.9. Diagramma di sequenza della procedura di ricerca dei parametri. so, di tutti i documenti necessari per la descrizione del software e per le simulazioni; 2. Gestione del messaggio di attivazione del servizio: in questo momento il sistema estrae dal messaggio tutte le informazioni e crea un area temporanea all interno della quale generare le configurazioni ed eseguire le simulazioni; 3. Generazioni dei valori per la singola configurazione: basandosi sulle informazioni inserite nella sezione autonomic del file Meta- PL, viene esplorato il dominio dei parametri, vengono generate, cioè tutte le configurazioni che il progettista ha ritenuto sia utile simulare; 4. Selezione del valore iniziale dei parametri: ai parametri viene assegnato un valore di partenza; 5. Variazione del valore dei parametri: per ogni nuova configurazione si fa variare il valore di un solo parametro per volta; 6. Applicazione dei filtri: ciascun filtro viene applicato in modo parametrico, usando, cioè, i valori dei parametri calcolati nel punto precedente, per specializzare il processo di filtraggio;

47 3.3 Sviluppo di Web Services di tipo autonomic Esecuzione della simulazione: viene attivato il simulatore HeSSE e raccolto l output; 8. Parsing dell output di HeSSE: viene individuato, nell output del simulatore, il valore che esprime il tempo di esecuzione. Se sono necessarie nuove simulazioni per esplorare il dominio dei parametri si torna al punto 5; 9. Raccolta dei risultati: vengono raccolti i risultati delle simulazioni e scelta quella che ottiene il tempo di risposta migliore; 10. Restituzione dei risultati: la configurazione migliore viene impacchettata e rispedita al client come attachment compresso all interno del messaggio SOAP di risposta. L implementazione è stata fatta in linguaggio Java usando Apache Axis come motore Web Services e Apache Tomcat come service provider. Inoltre è stato estensivamente usato il package JUnit per testare le varie funzionalità del framework [55]. 3.3 Sviluppo di Web Services di tipo autonomic Le Applicazioni Web sono fondamentalmente costituite da due elementi: i client ed i servizi; i primi sono i moduli che interagiscono direttamente con gli utenti finali, mentre i secondi contengono un insieme di servizi accessibili tramite interfacce Web Services. Di solito i client possono mantenere lo stato dell applicazione durante l esecuzione e sfruttare i servizi per i compiti di elaborazione, come la manipolazione di dati o l accesso alle basi di dati. Lo sviluppo di nuove applicazioni consiste nella definizione di un nuovo insieme di client con i quali dovranno interagire gli utenti, di nuovi servizi, scritti nell ottica della riusabilità, e della composizione di servizi esistenti. Per ottenere buone prestazioni da un applicazione web, è possibile sfruttare le tecniche di auto-ottimizzazione a tre livelli [42 44]: Livello del server: il sistema autonomo interessa lo strato distribuito sottostante, cioè le azioni di ottimizzazione vengono eseguite al livello del sistema operativo e della rete; Livello del Service Provider: il sistema autonomo influenza il fornitore di servizi, cioè le azioni di ottimizzazione hanno impatto sui

48 3.3 Sviluppo di Web Services di tipo autonomic 47 parametri e sulle politiche di gestione del carico dell insieme dei servizi offerti; Livello dell applicazione: il sistema autonomo influenza le applicazioni utente, modificando l uso delle risorse e le azioni che esse svolgono. Le operazioni di ottimizzazione del livello del server sono di solito affidate agli amministratori di sistema, mentre quelle dei livelli del fornitore di servizi e dell applicazione sono di pertinenza degli sviluppatori delle applicazioni. Questo capitolo si focalizza in particolare sul terzo punto studiando quando e come, i client invocano i servizi di ottimizzazione. Figura Uso di MAWeS al livello delle applicazioni: i client dell applicazione web contengono la logica di controllo delle ottimizzazioni. Uno dei modi possibili è l integrazione nei client che invocano i servizi di ottimizzazione e, quindi, i servizi operativi con i parametri ottimali. Lo schema di principio di questa configurazione è riportato in figura Ciascun client integra un modulo fornito dal framework che fornisce i servizi essenziali insieme a qualche facility. Saranno solo essi a connettersi ai servizi di ottimizzazione per decidere quando e come contattare i server. Naturalmente, questa configurazione è particolarmente adatta quando non si ha il controllo dei servizi applicativi. Una possibilità alternativa può essere quella dell integrazione della logica di ottimizzazione direttamente nei servizi, come mostrato nella figura In questo caso il compito dei client è quello di aggregare i servizi che si adattano automaticamente durante l esecuzione. Questa

49 3.3 Sviluppo di Web Services di tipo autonomic 48 configurazione è più adatta alle situazioni in cui è preferibile una gestione distribuita, o si vuole un ottimizzazione eterogenea, in cui ogni servizio può gestirsi localmente senza la conoscenza complessiva del sistema. Figura Uso di MAWeS al livello dei servizi: ogni servizio sceglie come ottimizzare i propri parametri. Una volta che nell applicazione è stata integrata la logica di autoottimizzazione, è necessario stabilire quando avviare l analisi delle prestazioni e la ricerca dei valori migliori per i parametri. Tra le possibili strategie se ne possono proporre tre più generali: Deploy: le ottimizzazioni vengono valutate solo al momento del deployment del servizio; Service Call: le ottimizzazioni vengono valutate ogni volta che un client chiama un servizio; Reactive: le ottimizzazioni vengono valutate solo in corrispondenza di particolari eventi (ad esempio ad intervalli regolari o picchi di carico). La prima strategia (Deploy), impedisce la riconfigurazione a runtime, e quindi la capacità di adattarsi ai cambiamenti dell ambiente: una volta che il servizio è stato pubblicato è impossibile riconfigurarlo. Questa può essere una strategia accettabile quando l overhead imposto da MAWeS non è ammissibile. Questo overhead potrebbe rendere poco appetibile anche la seconda strategia, quella dell ottimizzazione ad ogni chiamata dei servizi. In seguito a queste considerazioni, nella

50 3.4 Sistemi ad agenti mobili 49 maggior parte dei casi può essere preferibile una strategia basata su eventi. Si noti che in questo contesto le fasi di deployment sono intese come l adattamento del software all ambiente che lo ospita; come sarà chiarito nel seguito, questo adattamento dal punto di vista di questo studio viene fatto in due fasi: la descrizione dell ambiente e la scelta iniziale dell insieme dei parametri. Il modello di architettura risultante è mostrato nella figure Essa è basata sull integrazione dei client MAWeS nei servizi web, ma funziona asincronamente rispetto ad essi. Seguendo una temporizzazione predefinita il client MAWeS avvia l ottimizzazione dei servizi ed aggiorna l insieme dei parametri (azioni a-g in figura 3.12). Quando il client dell applicazione web chiama il servizio, questo si avvia in modo ottimizzato usando i parametri precalcolati (azioni 1-4 in figura 3.12). Usando l approccio basato su reazione, l ottimizzazione può essere avviata facilmente seguendo un profilo di carico; nel momento del deploy al servizio vengono date le informazioni sui tempi in cui il carico dovrebbe cambiare, e le ottimizzazioni vengono lanciate solo negli istanti in cui si prevede sia necessaria una riottimizzazione. 3.4 Sistemi ad agenti mobili La programmazione basata su agenti mobili è un paradigma emergente per la programmazione distribuita; le piattaforme basate su agenti si sono rivelate utili in vari campi come le Grid [2, 66, 75], o le applicazioni basate sui servizi (Service Oriented Architecture, SOA) [25,37]. In questi sistemi sono difficilmente applicabili le tecniche classiche di ottimizzazione, come la taratura ad-hoc o lo sviluppo basato sulla software performance engineering, questo a causa dei continui cambiamenti del contesto di esecuzione, in quanto un agente può sospendersi, trasferirsi su un altro host abilitato alla sua esecuzione e continuare l esecuzione nella nuova destinazione. Quindi la piattaforma che li ospita non ha il controllo completo sullo stato del nodo, così, anche se gli approcci ad agenti mobili possono aiutare lo sviluppo di applicazioni, in pratica l unica soluzione in grado di garantire requisiti critici sembra essere l uso di architetture

51 3.4 Sistemi ad agenti mobili 50 Figura Integrazione di MAWeS in un applicazione basata su Web Services.

52 3.4 Sistemi ad agenti mobili 51 che si auto-configurano. Più in dettaglio, quando un agente si sposta su un nuovo sistema modifica lo stato preesistente, una predizione dell impatto di questo spostamento può aiutare a compiere scelte migliori nella riconfigurazione degli agenti. Per permettere l integrazione tra i sistemi ad agenti mobili e MAWeS, ci si è basati su Aglet Workbench, sviluppato da IBM Japan Research Group [35] con un interfaccia Web Service, in modo da supportare la pubblicazione dei servizi forniti da un agent server. Questo permette di creare, spostare gli agenti e comunicare con essi usando il protocollo SOAP. L agent server viene avviato all interno di un server Tomcat [9], e implementa un bridge SOAP che permette alle applicazione di interagire con gli agenti ospitati localmente o su host remoti. Per usare MAWeS con Aglets, sono state sviluppate nuove librerie di HeSSE per la simulazione dell overhead imposto dagli agenti quando si muovono, si clonano o scambiano messaggi, e una nuova estensione MetaPL per la descrizione del comportamento degli agenti. Come mostrato in figura 3.13, il framework Mawes è stato esteso con due nuove caratteristiche: MAWeS Core System Management Extension: il core è stato arricchito da un nuovo modulo che tiene conto dell ambiente di esecuzione. Il modulo viene eseguito come un daemon: interroga ciclicamente un registry di WS (UDDI) per scoprire nuove piattaforme Aglet e genera nuovi file di configurazione per il simulatore che tengano conto delle nuove piattaforme. MAWeS Client Extension: Il client MAWeS è stato esteso in modo da gestire un insieme di agenti che dovrebbero essere avviati sulle piattaforme target e invia ciclicamente query al core per prendere decisioni riguardo alle possibili riconfigurazioni dell applicazione.

53 3.4 Sistemi ad agenti mobili 52 Figura Lo schema dell estensione del framework Mawes per gli agenti mobili.

54 4 Risultati sperimentali Per validare il sistema sono stati implementati diversi casi di studio. Essendo il framework MAWeS proposto come un servizio con interfaccia Web, è naturale che il primo test-bench sia stato quello delle applicazioni orientate ai servizi. È stata implementata un applicazione di test in grado di autoconfigurarsi al variare delle condizioni di esecuzione senza intervento esterno. Il problema fondamentale legato alla presenza del framework è quello dell overhead introdotto. Nel caso in cui i processi di ottimizzazione siano usati per lanciare nuove istanze di un applicazione con parametri ottimizzati rispetto al carico di sistema atteso questo si ripercuote in un considerevole aumento dei tempi di startup dovuto ai tempi di simulazione ed analisi prima che l istanza ottimizzata sia avviata. Naturalmente l uso del framework può essere vantaggioso se il tempo speso nella simulazione è molto minore rispetto ai tempi di esecuzione dell applicazione. 4.1 Applicazioni orientate ai servizi Il primo degli esempi scelti per valutare il framework, è un applicazione web service che fa l analisi di file di log. Si tratta di un caso di studio semplice ma realistico, che mostra come MAWeS influenza le prestazioni di un applicazione. Per implementarla è stato configurato un Service Provider, un insieme di servizi e un applicazione basata su Web Services. Minimizzare il tempo di risposta di quest ultima è l obiettivo delle ottimizzazioni del framework.

55 4.1 Applicazioni orientate ai servizi 54 Figura 4.1. Schema dell applicazione di test LogAnalysis. I servizi esportati dal server LogAnalysis permettono di analizzare generici file di log (preparati ad hoc per valutare meglio i risultati). Sono fondamentalmente tre (figura 4.2): getloglength: che restituisce le dimensioni del file di log in linee; getlogfragment: che accetta come parametri una dimensione e una posizione all interno del file di log e ne restituisce un frammento preso nella posizione e delle dimensioni indicate; unique: che accetta come parametro un frammento del file di log e restituisce l IP dei client indicati in tale frammento. Come si nota i servizi sono stati scelti con l obiettivo di stressare i sistemi dal punto di vista dell uso della banda, dell I/O e della computazione, più che con la finalità di un analisi efficiente dei log. L applicazione LogAnalysis valuta ciclicamente (ogni T secondi) il numero di accessi di ciascun web client, identificato da un indirizzo IP, analizzando i file di log con i servizi descritti. I client LogAnalysis possono eseguire questa operazione in un singolo passo interagendo, quindi, con il server una sola volta, o in passi successivi usando i servizi getlogfragment e unique. In quest ultimo caso si può verificare una divisione del carico tra più server LogAnalysis, ciascuno dei quali fa

56 4.1 Applicazioni orientate ai servizi 55 Figura 4.2. Class diagram di LogAnalysis riferimento allo stesso file di log. Poiché il client è basato su thread, ogni frammento del file di log è processato concorrentemente. Ogni volta che viene lanciata la scansione dei log, viene variato il numero di thread sul client e l assegnazione di questi thread ai vari server disponibili; in questo modo varia il carico sui nodi di computazione e sulla rete, facendo variare il tempo di risposta. Nei test sono stati valutati solo il carico di CPU e di rete generati direttamente ed indirettamente dall applicazione LogAnalysis. Comunque il simulatore permette di tener conto anche di eventuale carico generato da altre applicazioni che funzionano sui sistemi di test, come mostrato in un successivo caso di studio (cap. 4.2). Uno dei parametri del sistema di ottimizzazione è stato quello della politica di scelta del server a cui ogni client può connettersi. Ogni client può richiedere i servizi a uno qualunque dei server disponibili, nel test sono state previste, però due sole politiche di scelta: una politica statica ed una dinamica. Usando una politica statica, ogni client richiede i servizi sempre allo stesso server, c è un legame statico tra un client ed un server. Usando una politica dinamica un client decide di volta in volta a quale server connettersi usando degli schemi di scheduling predefiniti (ad esempio round-robin). Dalle misure fatte in mancanza di sistema di ottimizzazione è risultato che non c è un netto predominio di una delle due politiche in termini di prestazioni.

57 4.1 Applicazioni orientate ai servizi 56 Figura 4.3. Activity diagram di log analysis

58 4.1 Applicazioni orientate ai servizi 57 public class ClientRequestThread extends Thread { private static final Logger logger = Logger. getlogger ( LogAnalysisTest. class ); public final int clientnum ; public final int requestnum ; private final int numtotservers ; private long elapsed ; private final URL srvurl ; private static LogAnalysisService servicelocator = null ; private final LoganalysisSoapBindingStub las ; public ClientRequestThread ( int numactivesrv, URL url, int num, int reqnum ) throws ServiceException { if ( servicelocator == null ) servicelocator = new LogAnalysisServiceLocator (); clientnum = num ; requestnum = reqnum ; elapsed = 0; numtotservers = numactivesrv ; srvurl = url ; las = ( LoganalysisSoapBindingStub ) servicelocator. getloganalysis ( srvurl ); } public long getelapsedtime () { return elapsed ; } private void work () throws RemoteException { int [] res ; long loglen = las. getloglength (); int fraglen = ( int )( loglen / numtotservers ) -1; } final int from = requestnum * fraglen ; final int to = ( requestnum +1)* fraglen ; // To stress network las. getlogfragment (from, Math. min ( from +1000, to )); // To stress server CPU and I/ O las. uniq2 (from, to ); } public void run () { try { final long time0 = System. currenttimemillis (); work (); elapsed = System. currenttimemillis () - time0 ; } catch ( Exception exc ) { logger. log ( Level. SEVERE, " ERROR "+ exc. getmessage (), exc ); } } Figura 4.4. Frammento di codice dei thread client di LogAnalysis

59 4.1 Applicazioni orientate ai servizi <Task > <Loop iteration ="23"> <Block > <Sleep time =" 240 " /> <WSCall ws=" LogAnalysis " method =" renew " /> < WSlocalworktime time =" 1" / > < Loop iteration =" Nfragments " > <Block > < WSCall ws =" LogAnalysis " method =" getlogfragment " maxfragments ="mf" numfrag ="nf" /> </ Block > </ Loop > <WSCall ws=" LogAnalysis " method =" unique " /> <WSEnd /> </ Block > </ Loop > </ Task > < Mapping > < NumberOfProcesses value =" 5" / > < ProcessID value ="ID"/> < Autonomic > < Parameter name =" NumberOfProcesses " > <Value >5</ Value > <Value >10 </ Value > </ Parameter > < Parameter name =" NumberOfServers " > <Value >2</ Value > <Value >3</ Value > </ Parameter > < Parameter name =" ServerChoicePolicy " > <Value >Static </ Value > <Value > Dynamic </ Value > </ Parameter > </ Autonomic > </ Mapping > Figura 4.5. Frammento della descrizione MetaPL dell applicazione LogAnalysis; nell ultima parte si notano le estensioni autonome

60 4.1 Applicazioni orientate ai servizi 59 La figura 4.5 mostra la descrizione MetaPL dei client LogAnalysis; questa indica esplicitamente i parametri che il sistema dovrà ottimizzare: NumberOfProcesses: il numero di thread sui client LogAnalysis. Questo parametro è legato alla dimensione dei frammenti del file di log: la dimensione di ogni frammento è data dal rapporto tra le dimensioni del file di log e il numero di client; NumberOfServers: il numero di server LogAnalysis; ServerChoicePolicy: la politica di scelta dei server LogAnalysis. L esecuzione dei LogAnalysisClient procede come descritto nel seguito: ogni volta che viene avviata l analisi dei log, il client chiede al framework il numero ottimale dei thread client e dei server Log- Analysis, nonché la politica da usare: statica o dinamica. Il framework esegue una serie di simulazioni preliminari per trovare la combinazione ottimale dei parametri riferita alle condizioni dell ambiente che si verificano (carichi computazionali, traffico di rete,...) Valutazione delle prestazioni del framework Per valutare le prestazioni del framework autonomic, è stato svolto un gran numero di test, con istanze di client LogAnalysis. Ognuno di questi client effettua un analisi dei log a intervalli prefissati (es. T = 240s), in questi test si è assunto che tutto il carico, sia di rete sia computazionale, sia interamente da addebitarsi all applicazione Log- Analysis. Praticamente si è ottenuto ciò inibendo sui cluster di test ogni sorgente di rumore. Inoltre le analisi possono considerarsi sincronizzate, cioè i vari client partono contemporaneamente, se confrontati con i tempi caratteristici dell applicazione. Al fine dei test è stato usato un profilo di carico, indicato dalla linea continua nella figura 4.6. A ciascuno dei passi successivi (impostati a intervalli regolari), il numero dei client LogAnalysis varia secondo quanto riportato dal diagramma, facendo variare di conseguenza il carico del sistema. Per mostrare il funzionamento con feedforward si usa una curva di carico stimata diversa da quella reale, indicata dalla linea tratteggiata. I carichi reali e stimati coincidono su tutta la

61 4.1 Applicazioni orientate ai servizi 60 durata del test tranne in due periodi: da 12 a 13 con una predizione leggermente errata, e tra 19 e 22 con una predizione molto diversa dal carico reale. Il risultato misurato è relativo alla risposta di tutti i client attivi per una singola analisi del file di log. Figura 4.6. Profili di carico reali e stimati: il profilo stimato si discosta da quello iniettato per evidenziare i problemi dovuti agli errori di previsione. Il test è stato effettuato su un cluster basato sulla Rocks Linux Cluster Distribution, composto da un front-end IBM x345, con dual Intel Xeon 2.8 GHz, 1GB Ram, 72 GB RAID disk, e un Blade system con sette nodi computazionali con dual Xeon 2.8 GHz, 1 GB Ram, 72 HD. Il sistema di Web Services è stato sviluppato usando Apache AXIS e Apache Tomcat [9]. Ad ogni nodo è stato assegnato un solo ruolo, server o client, in maniera esclusiva.. Quindi ciascuno è stato, in maniera esclusiva, o uno dei service provider, o un server MAWeS o un client a seconda se offriva i servizi applicativi, quelli del framework di ottimizzazione o conteneva il client applicativo. In questo modo è stato possibile studiare il comportamento del framework in diverse configurazioni. In particolare per la configurazione studiata di seguito sono stati usati: Tre nodi server con piattaforma Web Services Tomcat/Axis su cui sono stati lanciati i servizi applicativi; Un singolo nodo con piattaforma Web Services Tomcat/Axis su cui sono stati lanciati i servizi MAWeS e su cui funzionava il simulatore;

62 4.1 Applicazioni orientate ai servizi 61 Un nodo su cui è stata lanciata l applicazione client. Nella figura 4.7 sono confrontati i tempi di risposta dell applicazione LogAnalysis in assenza di ottimizzazioni autonomic, usando, cioè due configurazioni scelte all inizio dell esecuzione e mantenute per tutte le condizioni di carico. Per le due configurazioni di riferimento, denominate Best Unloaded e Best Mean, sono stati scelti i parametri riportati nella tabella 4.1. La prima corrisponde all insieme di parametri per la configurazione che corrisponde al tempo di risposta minore per un sistema completamente scarico, e si comporta in maniera non ottimale quando il carico è presente. La seconda corrisponde alla configurazione che offre il miglior tempo di risposta medio per qualunque configurazione di carico. Figura 4.7. Autonomic response time vs. two fixed configurations Parametro Best Unloaded Best Mean NumberOfProcesses 4 1 NumberOfServers 4 4 ServerChoicePolicy static dynamic Tabella 4.1. Parametri usati per le due configurazioni di test di figura 4.7 (Best Unloaded e Best Mean). Come descritto in precedenza, uno degli usi più promettenti delle ottimizzazioni basate su strumenti simulativi è la possibilità di usare

63 4.1 Applicazioni orientate ai servizi 62 Metric FF vs NoAd 1 FF vs NoAd 2 Risultato medio -19,55% -35,75% Risultato migliore -61,92% -79,15% Risultato peggiore 9,42% 8,39% Nbest Nworst 8 5 Tabella 4.2. Confronto tra i risultati autonomic e le configurazioni fisse indicate in tabella 4.1. approcci feedforward. Un applicazione può usare i servizi di ottimizzazione per identificare le migliori condizioni di funzionamento quando il sistema non ha ancora raggiunto lo stato a cui ci si riferisce. In altri termini si possono anticipare le necessità. I risultati ottenuti con il metodo basato su feedforward sono stati confrontati con quelli ottenuti usando meccanismi di feedback per le ottimizzazioni. La differenza tra i due approcci sta nei dati usati per calcolare la configurazione migliore dei parametri: nel primo caso si tratta di dati stimati, nel secondo caso di dati misurati. La figura 4.8 mostra il tempo di risposta usando gli approcci a feedforward e con feedback, sotto le stesse condizioni di carico e con le stesse predizioni mostrate usate per la figura 4.6. Il diagramma mostra che approccio basato su feedback propone prestazioni migliori solo in caso di predizioni sbagliate. Figura 4.8. Tempo di risposta di LogAnalysis: confronto tra configurazione basata su feedforward e su feedback.

64 4.2 Applicazioni soft-realtime 4.2 Applicazioni soft-realtime 63 Molte applicazioni, soprattutto in ambito ludico (decoder video, sistemi di gioco online,...), possono tollerare una perdita di qualità nelle proprie elaborazioni, se queste diventano troppo dispendiose in termini di uso di risorse o di tempo di calcolo. Per esempio un avatar che si muove nel mondo virtuale di un videogioco può scegliere un path non ottimale per raggiungere il proprio obiettivo senza che vi siano variazioni apprezzabili nell esperienza dell utente, o un sistema di streaming video può inviare o decodificare dei frame a qualità più bassa garantendo tuttavia i propri servizi. Spesso le variazioni di carico non sono completamente casuali, ma seguono qualche tipo di legge empirica, come ad esempio i server web o di streaming che possono avere picchi di accesso ogni giorno alla stessa ora. Per testare il framework MAWeS con questo tipo di applicazioni è stato scritto un test sintetico che simula il comportamento di un sistema soft real-time. Lo fa eseguendo una serie di unità di lavoro che devono essere portate a termine in uno slot temporale predefinito, ad esempio 2000 ms. Si tratta in realtà di un sistema di conversione di immagini che trasforma dei frame di dimensioni prefissate (720x576 pixels) in formato jpeg usando le librerie di manipolazione delle immagini di Java. È stata progettata usando la metodologia descritta nei capitoli precedenti, basandosi su un architettura a Web Services. Lo schema di principio dell architettura usata nelle due configurazioni di cui sono riportati i dati, è visibile nelle figure 4.9 e Nel prima caso il modulo MAWeSClient è integrato nella parte client dell applicazione, nel secondo caso nella parte server. Il client (figura 4.11) attiva una chiamata al servizio convert, questo raccoglie i dati da convertire li elabora e li registra. Contemporaneamente effettua un analisi del sistema che può cercare configurazioni di funzionamento migliori ed attivare una riconfigurazione. Per dimostrare come i servizi possono adattarsi autonomamente all ambiente, viene applicato un carico esterno ai nodi computazionali (iniettando processi sull host in modo che il servizio non abbia l uso esclusivo delle risorse computazionali) e si studia l evoluzione del soft-

65 4.2 Applicazioni soft-realtime 64 Figura 4.9. Schema dell applicazione WorkHour nella configurazione con i servizi di ottimizzazione integrati nel lato client Figura Schema dell applicazione WorkHour nella configurazione con i servizi di ottimizzazione integrati nel lato server Figura Activity diagram dell applicazione WorkHour

66 4.2 Applicazioni soft-realtime 65 Figura Tempi di risposta con carico eterogeneo: in ogni nodo è stato iniettato un carico diverso ed è sottoposto ad una strategia di riconfigurazione diversa. ware. Nei test che seguono si assume che il carico abbia un andamento a gradino e che sia conosciuto sia il valore sia l istante di applicazione. Il tempo di risposta del servizio è l indice scelto per confrontare soluzioni diverse. Nella figura 4.12 vengono confrontati i tempi di risposta di un servizio che non ha alcun tipo di ottimizzazione con due versioni che hanno due profili diversi di carico esterno atteso. Nella prima configurazione (Pre Optimization) si assume che il carico esterno aumenti prima dell istante di iniezione del carico. Nella seconda configurazione, invece, si assume che il carico esterno sia avviato dopo che questo sia effettivamente iniettato. Si cerca cioè di sbagliare l istante di applicazione dell ottimizzazione prima per difetto, poi per eccesso rispetto ai dati reali. La figura 4.12 dimostra che il caso di Pre optimization riesce ad ottenere la risposta migliore in termini di prestazioni anche se la scelta non è ottimale. Gli strumenti proposti sono basati sull adozione di un approccio feed-forward, basato sull uso del simulatore e dei profili di carico esterno, inoltre sono in grado di usare una strategia a feedback. La figura 4.13 mostra la risposta di un servizio senza adattatività (No Adaptation), con strategia a feedback (Feedback) e a feedforward (FeedFor-

67 4.2 Applicazioni soft-realtime 66 ward). Il diagramma riporta in ascissa l istante di inizio della work unit ed in ordinata la sua durata. Si noti come l approccio feedforward dia i risultati migliori, mentre il feedback, ha alti tempi di risposta per le prime iterazioni (dopo l iniezione del carico), quindi ottimizza le proprie prestazioni. Quando l ottimizzazione è basata su feedback, il sistema riesce ad adattarsi solo dopo un periodo di perdita delle prestazioni. Deve monitorarsi e scoprire la perdita di prestazioni e quando ciò accade può cercare i parametri ottimali attraverso MAWeS. Figura The comparison between system evolution without MAWeS, with feedback and with feedforward MAWeS Quando l ottimizzazione è basata su feedforward, l utente deve stimare alcuni parametri (come ad esempio il numero di accessi ad un sito), quindi studiare l evoluzione del sistema usando la simulazione, ed infine cercare il valore ottimale per i parametri. Non può esservi, quindi un uso ottimale delle risorse quando non è possibile predire effettivamente l evoluzione del sistema (evoluzione tra 8 e 10 secondi in figura 4.13).

68 4.3 Servizi composti Servizi composti Uno degli scenari più comuni nelle architetture orientate ai servizi è quello della composizione, dell aggregazione, cioè, di più servizi, di livello più basso, da parte del servizio direttamente invocato dall utente. In questa prova è stato esteso il programma WorkHour introdotto nella sezione precedente introducendo un nuovo servizio: convertcs. L applicazione effettua una conversione di un numero specificato di immagini (frames) tutte della stessa misura suddividendo il calcolo tra diversi server. Sono stati esplorati due scenari, il primo per analizzare il caso di ottimizzazione su Service Call, il secondo per le ottimizzazioni reattive Servizi composti e riconfigurazione su invocazione Figura Scenario dell applicazione WorkHour nella configurazione con ottimizzazione su invocazione Nel primo caso (figura 4.14) viene affrontata la riconfigurazione su invocazione, l ottimizzazione, cioè, avviene nel momento in cui il client invoca il server, prima dell inizio dei calcoli veri e propri, in modo che questi ultimi possano essere avviati in maniera ottimizzata.

69 4.3 Servizi composti 68 Figura Activity diagram delle caso di servizi composti con ottimizzazione su invocazione Il diagramma delle attività di figura 4.15 mostra le azioni dell applicazione. Inizialmente viene invocato il servizio convertcs, indicandogli il numero di frames da convertire. L implementazione del servizio a sua volta richiede a MAWeS una configurazione ottimale inviandogli i documenti (MetaPL ed HeSSE) che descrivono il sistema nella configurazione attuale. A questo punto il sistema in base al risultato delle simulazioni decide su quali host allocare i calcoli. In particolare in figura 4.14 è mostrato il caso in cui sono state attivate due chiamate, la prima è stata allocata su due dei tre host disponibili. La seconda sul terzo host. Figura Gantt dell evoluzione delle invocazioni dei servizi composti