Cloud driver

I Cloud driver vengono visti come un livello di astrazione fra la piattaforma e l’ambiente cloud sottostante. Essi sono i responsabili dell’interfacciamen- to con l’infrastruttura cloud, provvedendo a richiedere on-demand le risorse richieste dalle applicazioni installate sopra Cloudify. Questo layer viene sfruttato, quando si istanziano o rimuovono macchine virtuali di gestione, tramite i comandi bootstrap-cloud, teardown-cloud, quando si istanziano o rimuovono macchine virtuali per le applicazioni install-application,uninstall- application, oppure vengono sfruttati dall’ESM. L’ESM `e il responsabile dell’ auto-scaling, ne viene creato dall’infrastruttura uno per ogni istanza

di servizio, per sua natura dovr`a interagire con il Cloud e quindi sfrutter`a i Cloud driver. Tramite questi Cloud driver, sar`a possibile richiedere ai vari provider di servizio, siano essi pubblici o privati, un certo quantitativo di risorse, siano esse computazionali o di gestione del sistema. Ad esempio, sar`a possibile richiedere un certo range di porte per le varie applicazioni installate sulla piattaforma, oppure richiedere pi`u o meno processori dedi- cati. Essendo che i Cloud provider e le API non sono perfetti pu`o accadere che si generino degli errori che vanno gestiti. E’ importante ricordare che l’ infrastruttura del Cloud Driver non `e transazionale quindi `e compito del Cloud Driver gestire in maniera propria gli errori che possono scaturire dal- la piattaforma cloud sottostante e, cosa ancora pi`u importante, `e sempre compito del Cloud Driver rilasciare propriamente le risorse qualora un erro- re avvenga durante la richiesta di una macchina. Ad esempio, se un Cloud Driver richiede una macchina dal Cloud e poi attende che la macchina di- venti disponibile, la macchina potrebbe impiegare troppo tempo prima di diventare disponibile, superando cos`ı il timeout prefissato. In questo caso `e compito del Cloud Driver spegnere la macchina richiesta prima di lanciare una TimeOutException all’ infrastruttura.

Modello ad Attori

L’ introduzione in questa sezione del modello di programmazione ad attori nasce dal fatto che esso rappresenta sicuramente un modello di programma- zione valido per le applicazioni cloud come ad esempio vedremo in seguito per Orleans ( un framework per sviluppare applicazioni cloud gestito dalla microsoft). Innanzi tutto diciamo che il modello ad attori `e un modello nato nell’ ambito della programmazione concorrente e non di quella distri- buita. Le sue caratteristiche di atomicit`a, fairness e locazione lo hanno reso un modello molto apprezzato anche in altri ambiti. Cercando di fare un paragone per capire meglio le propriet`a fondamentali di questo paradigma, prendiamo in considerazione quello che `e un paradigma a noi ben noto, quello ad oggetti. In questa visione un oggetto incapsula sia i dati che il suo comportamento; questo separa l’interfaccia di un oggetto ( cosa fa ) dalla sua rappresentazione ( come lo fa ). Ci`o permette un ragionamento di tipo modulare durante la progettazione di sistemi object-based e ne facilit`a la loro evoluzione. Gli attori aggiungono ai vantaggi degli oggetti quelli della computazione concorrente separando il controllo ( dove e quando ) dalla logica della computazione.

Avendo fatto una sorta di paragone fra questi due modelli diamo ora una definizione pi`u precisa di che cosa `e un attore e un sistema ad attori. Un attore `e un oggetto autonomo che opera in maniera concorrente e asin- crona, ricevendo ed inviando messaggi ad altri attori, creando nuovi attori, ed aggiornando il suo stato locale. Un sistema ad attori consiste in una col- lezione di attori, alcuni dei quali possono ricevere o inviare messaggi da/ad attori esterni al sistema.

Infine nel corso dell’ esposizione parler`o anche di quelle che sono i prin- cipali framework per la JVM, confrontandoli e mettendo in luce quelle che sono le caratteristiche che offrono.

4.1

Attori

Gli attori sono come, abbiamo gi`a detto, entit`a autonome all’ interno del nostro sistema. Un attore ha un nome che lo identifica univocamente all’ in- terno del sistema e che gli permetter`a quindi di essere raggiunto dai messaggi degli altri attori. Essendo che un attore, che vuole inviare un messaggio ad un altro, ne deve conoscere l’ indirizzo, `e importante cercare di capire come pu`o fare per ottenerlo. Le modalit`a sono tre e sono o che era gi`a presente all’interno dell’ attore stesso, o che `e dato come risultato di una compu- tazione o, infine, che gli `e stato inviato all’ interno dell’ ultimo messaggio ricevuto. Si pu`o notare, da quanto appena scritto, che un indirizzo quindi non pu`o mai essere suggerito da altri attori presenti all’ interno del sistema se non tramite un messaggio. Quanto appena detto ci porta subito ad con- cetto fondamentale, ovvero che gli attori, come unico modo per interagire gli uni con gli altri, hanno lo scambio di messaggi; questo implica che gli attori non possono condividere lo stato, quindi le computazioni parallele non presentano problemi di concorrenza, non potendo interferire tra loro in alcun modo . Tutto ci`o ci introduce a quello che `e il concetto di task. I task non sono niente altro che il modo che esiste nei sistemi ad attori per rappresentare le comunicazioni; essi sono composti da una etichetta univoca che gli identifica, l’ indirizzo del destinatario ( target ) del messaggio e da un insieme di parametri che l’ attore dovr`a elaborare. Come gi`a sottolineato alla ricezione di un task un attore pu`o fare solo tre cose:

• inviare un messaggio ad un altro attore • cambiare il proprio stato

• creare un altro attore

Ovviamente queste tre non sono mutuamente esclusive, nel senso che un attore, una volta ricevuto un messaggio potrebbe eseguire solo una di queste azioni cos`ı come tutte e tre. Quindi man mano che la computazione procede il sistema evolve creando nuovi task e nuovi attori che sono creati

nel processare task gi`a presenti all’ interno del sistema. Tutti i task che sono gi`a stati processati e che non sono pi`u utilizzati possono essere rimossi dal sistema ( garbage collection ); citando direttamente Gul Agha we can say that the unprocessed tasks in a system of actors are the driving force behind computation in the system il cui significato `e che i task non ancora processati, in un sistema ad attori, rappresentano la forza che guida la computazione dell’ intero sistema.

L’ attore ha, come strumento per ricevere i messaggi, una mailbox o coda. Qualora arrivi un messaggio nella mailbox e l’ attore non sia gi`a occupato a processarne un altro se ne prende carico chiamando dei metodi ( similmente a quanto accade nel modello ad oggetti ) che sono funzione sia del messaggio ricevuto ma anche nello stato corrente. Pi`u nel dettaglio un attore una volta finito di processare un messaggio entra nello stato di idle e guarda nella mailbox se vi sono presenti altri messaggi. Qualora ve ne siano l’ attore prender`a il primo messaggio all’ interno della lista e lo processer`a, altrimenti entrer`a in uno stato di waiting aspettando l’ arrivo di un nuovo messaggio. A questo punto `e importante notare, come gi`a accennato, che l’ arrivo di un messaggio non pu`o mai interrompere la computazione che un attore sta eseguendo, ma viene sempre portata a termine prima di processare un nuovo messaggio.

Un altra caratteristica fondamentale del modello ad attori `e che essa introduce il non determinismo. Infatti i messaggi vengono consegnati, at- traverso la rete, secondo una politica di tipo best effort, questo implica che, anche qualora inviassimo due messaggi l’ uno di seguito all’ altro allo stesso attore, non potremmo mai avere la certezza di quali dei due arrivi per pri- mo a destinazione. Questo `e dovuto al fatto che non `e detto che i messaggi prendano la stessa strada per arrivare all’ attore finale e di conseguenza i ritardi introdotti dalla rete non sono predicibili; senza poi considerare il fat- to che il modello adotta il parallelismo e la concorrenza. Infine ricordiamo che i messaggi vengono inviati in maniera asincrona, di conseguenza una volta inviati dall’ attore, quest’ ultimo riprende immediatamente la propria esecuzione, senza aspettare alcun tipo di conferma n´e dal sistema n´e dal de- stinatario. Lascio di seguito un immagine che spero renda tutto pi`u chiaro e che riassume quanto detto in questo paragrafo.

Figura 4.1: Rappresentazione grafica di attori