Meccanismi di Autoscaling nel Cloud computing

Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Reti di Calcolatori I Meccanismi di Autoscaling nel Cloud computing Anno Accademico 2014/2015 Candidato: Gabriele Ascione matr. N46000302

[Dedica]

Indice Indice...III Introduzione...5 Capitolo 1: Cloud Computing e Autoscaling...5 1.1 Modelli di servizio...6 1.2 Autoscaling...7 1.3 Monitoraggio...8 Capitolo 2: Algoritmi di Autoscaling...9 2.1 Auto scaling con approccio basato su Learning Automata...9 2.2 Auto scaling e approccio trigger data stream...11 2.3 Auto scaling per workflows e bag-of-tasks...12 2.4 Auto scaling orientato al bilancio del carico...14 2.5 Auto scaling e approccio Bin packing...16 2.6 Auto scaling e Workflow scientifici...19 Capitolo 3: Soluzioni implementate dai Cloud Provider...24 3.1 Amazon e le Spot instances...24 3.2 Netflix e Scryer...26 Conclusioni...27 Bibliografia...28

Introduzione La diffusione della banda larga ha permesso lo sviluppo di applicazioni client con un carico di lavoro sempre più leggero per i personal computer degli utenti, fino a consentire l esecuzione di applicazioni attraverso i web browser, spostando gran parte del carico computazionale sui server. Applicazioni che prima richiedevano di essere installate su un unica macchina nella quale risiedevano tutti i dati elaborati, oggi sono disponibili dopo una breve sottoscrizione (gratis o a pagamento) attraverso un qualunque dispositivo che abbia una connessione ad internet. Basti pensare al recente sviluppo di nuvole nelle quali è possibile caricare o creare i propri documenti e, successivamente, modificarli grazie alla suite office accessibile attraverso il proprio browser, senza dover installare nulla sul proprio dispositivo. Grazie alla diffusione dei Cloud Provider, gli sviluppatori hanno ottenuto il vantaggio di poter implementare la propria applicazione senza doversi preoccupare della gestione dell infrastruttura sulla quale far girare il proprio servizio. I provider offrono la possibilità di poter pagare ciò che si usa grazie all'implementazione di meccanismi di autoscaling con i quali il sistema cloud può istanziare o rimuovere risorse computazionali, a seconda del traffico effettivo che l applicazione si trova a dover gestire. In questo elaborato cercheremo di fornire prima di tutto una panoramica generale, andando a descrivere il modello Cloud con le sue caratteristiche principali, i modelli di servizio, in che modo si realizza l autoscaling e la necessità di dover implementare meccanismi di monitoraggio. Successivamente analizzeremo gli algoritmi di autoscaling proposti recentemente, esaminando le problematiche legate ad alcuni contesti, come ad esempio quello della ricerca scientifica, e considerando i diversi approcci per implementare le logiche di scaling. Infine osserveremo le soluzioni implementate da due tra i maggiori cloud provider del settore. 4

Capitolo 1: Cloud Computing e Autoscaling Il Cloud Computing è un modello che consente di accedere, per mezzo di una rete Internet, a un insieme di risorse computazionali, condivise e configurabili, che possono essere rapidamente istanziate e rimosse, con minimi sforzi di gestione e interazione da parte dei fornitori dei servizi [1]. Caratteristiche essenziali di tale modello sono l erogazione automatica dei servizi su richiesta degli utenti, la possibilità di accesso alle funzionalità del cloud grazie a meccanismi che consentono di accedere alla rete tramite piattaforme client diverse tra loro (smartphone, tablet, pc ); presenza di un insieme di risorse fisiche e virtuali, assegnabili e riassegnabili dinamicamente, a più utenti, grazie a meccanismi di astrazione; capacità di assegnare e rilasciare risorse in maniera commisurata alle domande degli utenti; controllo ed ottimizzazione delle risorse per associare la configurazione ottimale ad ogni tipo di servizio. 1.1 Modelli di servizio I modelli di servizio di Cloud Computing si dividono in tre categorie che vengono rappresentate su tre livelli di astrazione, i quali consentono l implementazione dei servizi da erogare. I modelli si dividono in: Infrastructure as a Service (IaaS): a questo livello vengono fornite risorse hardware che si traducono in servizi di processing, network e storage, dando la possibilità all utente di implementare il proprio software e di scegliere le componenti di rete, nei limiti consentiti dal provider. Inoltre l utente può richiedere l aggiunta o la rimozione di altre risorse hardware, ma non è direttamente coinvolto nella gestione e nella implementazione dell infrastruttura fisica del cloud. Esempi di IaaS sono Amazon EC2 e Google Compute Engine. Platform as a Service (PaaS): vengono fornite piattaforme software, grazie alle quali gli utenti possono sviluppare e distribuire, nell infrastruttura cloud, le proprie 5

applicazioni. L utente ha controllo solo sulla propria applicazione e su alcuni parametri che ne regolano il comportamento nell ambiente nel quale è installata. Google App Engine e Microsoft Windows Azure sono esempi di framework per lo sviluppo e la distribuzione software in cloud. Software as a Service (SaaS): viene fornito l accesso ad applicazioni offerte da un provider, le quali risiedono in un infrastruttura cloud anziché nel computer dell utente. L accesso avviene tramite un interfaccia client e l utente può solo usufruire dei servizi offerti dall applicazione e configurarla nei limiti imposti dal provider. Tra gli esempi di SaaS ricordiamo Google Docs e Dropbox. 1.2 Autoscaling Figura 1: Autoscaling in una infrastruttura Cloud L Autoscaling (o Scalabilità Automatica) è la capacità di poter istanziare o revocare risorse computazionali in maniera automatica, a seconda dell incremento o della diminuzione del numero di richieste inoltrate dagli utenti. Tutto ciò serve a mantenere alto il livello delle prestazioni del servizio offerto e ridurre i costi sia da parte dell utente (in termini di risorse economiche), sia da parte del provider (in termini di risorse energetiche). Tale meccanismo viene configurato secondo le necessità e le possibilità dell utente, il quale ha l impressione di poter usufruire di un numero infinito di risorse [2]. 6

Figura 2: Scaling orizzontale e verticale L implementazione dell autoscaling è possibile grazie a tre azioni fondamentali [3]: Scaling orizzontale: anche detta replicazione, consiste nell aggiungere o rimuovere (scale in/out) istanze da un ambiente virtuale assegnato ad un utente. Tali istanze possono essere applicazioni, contenitori o Virtual Machine (VM) sulle quali girano i servizi richiesti dall utente. Scaling verticale: consiste nell aggiungere o rimuovere (scale up/down) risorse da una istanza virtuale (es: quantità di memoria e CPU assegnata ad una VM). E possibile cambiare le risorse assegnate ad una istanza a tempo di esecuzione (ridimensionamento), oppure è possibile terminare una istanza per avviarne una nuova con maggiore disponibilità di risorse (riposizionamento). Migrazione: Consiste nel trasferire una VM o un applicazione che è in esecuzione su un server fisico su un altro server. La migrazione in genere viene utilizzata per bilanciare il carico di lavoro da eseguire sui vari server a disposizione (Load Balancing). Per automatizzare questi metodi è necessario definire dei meccanismi di monitoraggio che consentano al sistema di comprendere quando intervenire nella istanziazione/rimozione delle risorse. 7

1.3 Monitoraggio [4] Il Monitoraggio del cloud è un processo che ha il compito di controllare lo stato e gestire l utilizzo delle risorse hardware e software del sistema. Questo consente di ottenere informazioni sulle performance del sistema (Quality of Service) e di adottare le dovute precauzioni nel caso si verifichino degli infrangimenti degli Accordi sui livelli di servizio (SLA) presenti nel contratto tra l utente ed il service provider. Poiché ogni cloud viene modellato su più livelli di astrazione, il monitoraggio viene implementato inserendo delle sonde, fisiche o virtuali, che restituiscono informazioni sullo stato di ogni livello. Possiamo quindi distinguere tra alto livello di monitoraggio e basso livello di monitoraggio: il primo fornisce informazioni sullo stato delle applicazioni e delle piattaforme virtuali, informazioni che interessano generalmente più gli utenti che i service provider; il secondo invece si interessa di inviare informazioni sullo stato e l utilizzo delle risorse hardware dei server presenti nel cloud, informazioni raccolte dai service provider, i quali difficilmente condividono questi dati con gli utenti. Per valutare le performance del sistema è necessario definire un insieme di metriche. Le metriche utilizzate per misurare lo stato del sistema si dividono in metriche basate sulla computazione e metriche basate sulla rete. Le prime includono il livello di utilizzo e di performance della CPU, della memoria (es: velocità di esecuzione, numero di cambi di pagine di memoria al secondo) e delle VM (es: tempo di avvio, tempo di rilascio di una VM ). Le seconde consentono di valutare lo stato della rete interna al cloud (da server a server) ed esterna al cloud (da server a utente). Tra queste ricordiamo: perdita di dati/pacchetti, banda disponibile, volume di traffico. Questi dati possono poi essere valutati in termini di indicatori statistici (media, mediana, ecc.) o in termini di semplice caratterizzazione temporale. 8

Capitolo 2: Algoritmi di Autoscaling Nel precedente capitolo abbiamo dato una definizione di Cloud Computing e di autoscaling, sottolineando la necessità di implementare processi di monitoraggio per consentire al sistema di poter discernere quando intervenire per aggiungere o rimuovere risorse ai processi in esecuzione. Per poter realizzare un tale meccanismo è necessario progettare algoritmi che definiscano il comportamento del sistema al variare di alcuni parametri, al di sopra o al di sotto di soglie stabilite. Di seguito illustreremo gli ultimi algoritmi che sono stati proposti per l ottimizzazione del cloud computing in diversi contesti di lavoro. 2.1 Auto scaling con approccio basato su Learning Automata [5] Figura 3: Relazione tra Learning automata ed il suo ambiente Learning automata può essere definito come un oggetto astratto che seleziona una funzione da un insieme finito di funzioni, in base al comportamento osservato dall ambiente esterno (environment). Per ambiente esterno si intende ogni condizione ed evento esterno che va a modificare il comportamento dell oggetto. Learning automata e l ambiente definiscono un ciclo, dove l oggetto seleziona una funzione dall insieme di funzioni disponibili che possono interagire con l ambiente, e l ambiente, in base alla funzione scelta dall oggetto, invia un output che sarà osservato dall oggetto. Un algoritmo 9

definisce il modo in cui learning automata utilizza l output per la scelta della prossima azione da eseguire. In questo modo l oggetto learning automata è in grado di identificare gradualmente, ad ogni ciclo successivo, l azione ottimale da eseguire. L algoritmo di autoscaling proposto si basa sull algoritmo di soglia (threshold algorithm), il classico algoritmo di scaling che confronta dei parametri hardware prefissati con una soglia superiore ed una soglia inferiore. Se i parametri osservati (ad esempio, l utilizzo della CPU) sono al di sotto della soglia inferiore, allora si procede con la rimozione della VM. Viceversa, se i parametri oservati sono al di sopra della soglia superiore, si interviene istanziando una nuova VM. L algoritmo proposto viene eseguito da ogni VM, e il parametro che sarà monitorato e confrontato con le due soglie è lo spazio occupato dalla VM in esecuzione. Poichè l algoritmo è ciclico, ad ogni ciclo viene effettuato un confronto tra lo spazio occupato dalle VM e le due soglie (inferiore e superiore). In base al risultato del confronto, aumenta o diminuisce la probabilità di eseguire una operazione di scale up o scale down. Al termine dei confronti, l azione con la probabilità più alta viene selezionata dalla stessa VM. Se, ad esempio, viene selezionata un azione di scale up, l algoritmo confronta lo spazio occupato dalla VM in esecuzione con la soglia superiore e, se è maggiore, viene inviato il comando ad un broker per l istanziazione di una nuova VM. Se l azione è di scale down, allora, nel caso in cui lo spazio occupato sia minore della soglia inferiore, verrà inviato un comando per la rimozione della VM in esecuzione. L efficacia di questo algoritmo sta proprio nel ruolo delle VM nello scegliere l azione da eseguire, scelta che crea armonia tra lo scaling da effettuare e lo stato attuale delle VM. Valutando i vantaggi di questo algoritmo rispetto ad algoritmi di autoscaling più elementari, si sono riscontrati dei miglioramenti significativi in termini di sovraccarico delle operazioni di scaling e violazioni degli accordi sui livelli di servizio (SLA). Ulteriori miglioramenti possono essere apportati individuando delle soglie che meglio si adattano al contesto nel quale l algoritmo è utilizzato. 10

2.2 Auto scaling e approccio trigger data stream [6] Fin ora abbiamo considerato solo parametri hardware per valutare l esecuzione di un operazione di scaling. Altri parametri da poter considerare per l attivazione dello scaling automatico sono i dati stessi generati dall applicazione che viene eseguita dalla VM. Un segnale all interno dei dati generati da un applicazione può servire come un indicatore per preparare il sistema ad una maggiore quantità di lavoro da svolgere, consentendo una gestione dei picchi di domande dei client ed un bilancio del carico molto più efficace. Ad esempio, possiamo considerare come indicatore una notizia importante pubblicata su un sito web, la quale sappiamo per certo che incrementerà il numero di accessi al sito. Oppure, nel caso di un applicazione di data mining, l estrazione di un dato rilevante per la ricerca in corso può suggerire l aumento del numero di risorse computazionali, per analizzare meglio quell area di ricerca. Nel nostro caso, considereremo un applicazione che valuta i tweet inviati durante un incontro di calcio, per analizzare l opinione dei tifosi riguardo al match in corso. Come indicatore utilizzeremo il tempo di esecuzione necessario per poter analizzare ogni tweet e la media dei sentimenti degli utenti. Entrambi i parametri sono stimati dall applicazione stessa e, per poter valutare l umore degli utenti, ad ogni tweet vengono associati tre numeri reali che daranno al tweet una valenza positiva, negativa o neutrale. In seguito, per stimare il tempo necessario per analizzare ogni tweet, viene loro associata una classe ed una distribuzione del ritardo, grazie alle quali è possibile, con un certo margine di errore, prevedere i tempi di esecuzione. Di seguito proponiamo due algoritmi basati sulla conoscenza a priori dell applicazione. In entrambi i casi la SLA da rispettare è che ogni tweet deve essere analizzato entro 5 minuti. Il primo è l algoritmo di carico (load algorithm), che si basa sul confronto tra il tempo previsto per l analisi dei tweet e il limite di tempo imposto dalla SLA. Poiché quest algoritmo è reattivo, non è effettuata nessuna previsione sul volume futuro di tweet da analizzare. Se il ritardo previsto per il calcolo dei tweet correnti è maggiore del limite imposto dalla SLA, allora vengono allocate più risorse. Se il ritardo previsto, invece, è al di sotto della metà del limite imposto, allora vengono rilasciate risorse. Il rilascio delle 11

risorse è limitato ad una singola CPU alla volta, così che improvvisi picchi nel volume di tweet da analizzare abbiano un minor impatto sul sistema. Per l allocazione vengono stimate le risorse necessarie, effettuando una proporzione tra il ritardo stimato per poter analizzare ogni tweet e il limite di tempo della SLA. Per quanto riguarda le performance, se utilizzato per monitorare piccoli eventi, rispetto ad altri algoritmi, il load algorithm riesce a consumare meno risorse e ad allocarne più velocemente di nuove. Ciò è possibile per via di una maggiore reattività dell algoritmo rispetto agli altri, reattività possibile grazie alla conoscenza del tempo stimato per l esecuzione dei task dell applicazione. L appdata algorithm, invece, si occupa solo degli improvvisi picchi nel numero di tweet da analizzare. Infatti, l appdata analizza la media dei sentimenti dell ultimo minuto e la confronta alla media dei sentimenti del minuto precedente. Se la media è aumentata dello 0.5 o più, allora una prefissata quantità di CPU viene allocata. Per grossi eventi con incrementi di dati da elaborare significativi ed improvvisi, l appdata algorithm si preferisce ad altri algoritmi per la sua capacità di prevedere i picchi di dati e prevenire le violazioni delle SLA, a fronte, però, di un maggiore spreco di risorse. Nella scelta di uno dei due algoritmi presentati bisogna valutare se ottenere un minor numero di violazioni delle SLA o un minor spreco di risorse: nel primo caso conviene scegliere l appdata algorithm; nel secondo caso, la scelta più appropriata è il load algorithm. 2.3 Auto scaling per workflows e bag-of-tasks [7] Nelle recenti ricerche scientifiche, le applicazioni utilizzate spesso si trovano ad elaborare un enorme quantità di task debolmente accoppiati. Queste applicazioni appartengono a due categorie, bag-of-task e workflow, a seconda del tipo di dipendenza tra i task (e quindi del pattern di esecuzione). Le applicazioni bag-of-task assegnano i task alle risorse senza tener conto delle loro dipendenze (in genere in questo caso i task sono debolmente accoppiati e sono indipendenti tra loro). Le applicazioni workflow, invece, eseguono i task in maniera ordinata, rispettando il loro schema di dipendenza e il loro percorso di esecuzione critico. 12

Il seguente algoritmo di autoscaling può realizzare un allocazione dinamica delle risorse considerando il tipo di applicazione in esecuzione (bag-of-task o workflow), istanziando automaticamente risorse del cloud considerando il tipo di dipendenza tra task e il tempo di trasferimento dei dati (dall applicazione all utente che ha inoltrato la richiesta di elaborazione). L algoritmo viene eseguito su una infrastruttura ibrida (HTCaaS) composta di cluster locali, cloud pubblici (cloud provider come ad esempio Amazon EC2) e cloud privati (es: Open Nebula). L algoritmo di autoscaling per Bag-of-task verifica prima di tutto se ci sono risorse disponibili nel cluster locale. Se ci sono risorse disponibili, allora il task viene assegnato al cluster che è in grado di portare a termine il task entro i limiti di tempo imposti dall applicazione. Se non ci sono risorse disponibili nel cluster, allora l algoritmo assegna il task alle risorse disponibili nel cloud privato, assegnandolo a virtual machine che sono in grado di rispettare i limiti di tempo di esecuzione. Se non ci sono VM in esecuzione ma è possibile avviarne altre, l algoritmo aggiunge una VM alla lista tostartup del cloud privato, lista contenente le richieste di creazione di VM. Se anche nel cloud privato non sono disponibili risorse, viene ripetuto il procedimento precedente per il cloud pubblico. Una volta trovata o avviata una VM gli viene assegnato il task, e in seguito viene stimato il tempo necessario per poterlo portare a termine, a partire dai suoi tempi di avvio e di esecuzione. L algoritmo di autoscaling per workflow è in grado di individuare ritardi e violazioni delle deadline confrontando il tempo di avvio attuale e il tempo di avvio stimato di un task in esecuzione. All interno di un applicazione workflow, i task sono ordinati in sequenza e sono collegati tra loro, così che ogni task conosce il tempo di terminazione stimato del task precedente e può utilizzare questo tempo come valore per il proprio tempo di avvio stimato, per rispettare l ordine di esecuzione. Ogni task di un applicazione workflow, quindi, deve considerare il task precedente e il suo tempo stimato di terminazione. Successivamente, task presenti sullo stesso percorso critico sono assegnati alla stessa risorsa che deve essere in grado di eseguire tutti i task 13

appartenenti al percorso. Se il task da dover eseguire è il primo di un percorso critico, allora viene assegnato ad una risorsa disponibile e che può eseguire tutti i task appartenenti al percorso, rispettando i loro limiti di tempo. Utilizzando quest algoritmo è raro che non si trovino risorse disponibili nel cluster locale e che si debbano cercare altrove nel cloud privato o pubblico. Nel caso non si trovino, l algoritmo dà precedenza alle risorse cloud private rispetto a quelle pubbliche. Una volta eseguito il primo task del percorso critico si passa al task successivo, eseguito sempre sulla risorsa corrente selezionata dall algoritmo. Una volta assegnati i task più urgenti si passa a quelli non appartenenti ad un percorso critico. Se ci sono risorse disponibili nel cluster, allora il task viene assegnato a risorse che possono eseguire il task entro i limiti di tempo (deadline). Se non ci sono risorse disponibili nel cluster, allora il task viene assegnato ad una VM in esecuzione nel cloud privato. Altrimenti, se nessuna VM in esecuzione nel cloud è disponibile, allora viene aggiunta una nuova VM nella lista tostartup. Qualora questo non fosse possibile per mancanza di risorse, il task viene assegnato ad una VM in esecuzione nel cloud pubblico. Al momento dell assegnazione del task alla risorsa, viene calcolato il suo tempo di terminazione stimato. Questo algoritmo tiene conto anche del tempo necessario al trasferimento dei dati da una risorsa all altra, considerando la mole di dati generati dai task e la larghezza di banda disponibile. I trasferimenti di dati tra risorse si rendono necessari nel momento in cui due task dipendenti sono eseguiti su tipi di risorse diverse (ad esempio, un task nel cluster e un altro nel cloud privato). Nel momento in cui task dipendenti tra loro sono eseguiti sullo stesso tipo di risorsa, non è necessario nessun tipo di trasferimento. Entrambi gli algoritmi eliminano la violazione dei tempi critici di esecuzione dei task, nel momento in cui l applicazione è in esecuzione. 2.4 Auto scaling orientato al bilancio del carico [8] Gli algoritmi di autoscaling dovrebbero tenere in considerazione la distribuzione del carico di lavoro tra i server, distribuendo dinamicamente i processi da eseguire e massimizzando l utilizzo delle risorse, incrementando così le performance del sistema. Infatti il load 14

balancing è utilizzato per evitare che alcune risorse siano inutilizzate mentre altre siano in esecuzione o addirittura sovraccaricate di lavoro. Ci sono diverse soluzioni per poter bilanciare il carico tra server. Ad esempio, il client può richiedere una VM al sistema, il quale mantiene una tabella con le VM istanziate e il loro stato di esecuzione (occupate o disponibili). Il sistema, quindi, scorrendo la lista, ritorna l ID della prima VM disponibile in grado di poter soddisfare i requisiti per l esecuzione dei task. Se la tabella viene scansionata interamente e non viene individuata nessuna VM disponibile, allora l algoritmo, anziché ritornare l id della VM, ritornerà un valore pari a - 1 e il sistema stabilirà come intervenire, se istanziando una nuova VM (scaling) o se mettere in coda la richiesta del client. Nel caso in cui ci sono VM disponibili, allora viene assegnata al client che ne ha fatto richiesta. Un altra soluzione che è stata proposta si ispira al comportamento delle formiche quando sono alla ricerca di cibo per la propria colonia. In questo approccio la formica (che nel nostro caso sarà il sistema preposto per l individuazione di VM disponibili) viaggia in una sola direzione alla volta e può viaggiare solo in due direzioni, avanti e indietro. Quando la formica viaggia in avanti, cerca cibo (nodi sovraccaricati) seguendo il feromone di foraggiamento (nel nostro caso, una mappa delle VM) e aggiornando il percorso di foraggiamento. Allo stesso modo, la formica torna indietro dopo aver incontrato cibo (un server sovraccaricato), seguendo il feromone e modificando il percorso. Quest approccio considera il tempo minimo di migrazione dei nodi per cercare nodi con poco carico di lavoro e che non siano troppo lontani tra loro per effettuare la migrazione dei processi da un server all altro, operazione che, se troppo onerosa in termini di risorse computazionali e di rete, potrebbe portare ad un calo delle prestazioni del sistema. Similmente al precedente esempio, il bilancio del carico può essere implementato anche osservando il comportamento che hanno le api nella ricerca di polline per l alveare. Alcune api operaie cercano una fonte di cibo e, quando la trovano, ritornano all alveare e iniziano a eseguire la danza circolare per poter comunicare le indicazioni sulla quantità e sulla qualità del cibo trovato. In seguito altre api seguono le prime per raggiungere il luogo trovato e prelevare il cibo. Le api operaie tornano all alveare ed eseguono la danza 15

circolare per comunicare la quantità di cibo rimanente che può ancora essere prelevata. Nel nostro caso i processi, quindi, vengono inviati a delle VM che hanno poco lavoro da eseguire e, come le api operaie sfruttano le risorse trovate fino all esaurimento, il processo successivo da assegnare viene inviato alla stessa VM, fino a quando la VM non si trova sovraccaricata di lavoro. Questa strategia considera il tempo minimo di migrazione ma non considera tutti i fattori necessari per garantire la Qualità del Serivizio. 2.5 Auto scaling e approccio Bin packing [9] Completamente opposto all approccio precedente, l approccio Bin packing cerca di diminuire il più possibile l utilizzo delle risorse, realizzando una soluzione ottimale che consenta di associare il maggior numero di processi al minor numero di risorse. Lo scaling delle risorse in questo caso può essere considerato come la depositazione o la rimozione di un oggetto all interno di un contenitore, così come richiesto dall algoritmo di Bin packing. In particolare, gli oggetti da aggiungere o rimuovere dai contenitori possono essere visti come istanze di applicazioni che devono essere eseguite dalle risorse computazionali. Nel problema bin packing, c è un insieme finito di oggetti con n elementi e un insieme finito di contenitori con una certa capacità. L obiettivo è di posizionare ogni oggetto in un particolare contenitore, così che il numero totale di elementi in un contenitore non superi la sua capacità e il numero totale dei contenitori utilizzati sia il minore possibile. I problemi bin packing si dividono in online e offline. In un problema bin packing online, ogni elemento dell insieme di oggetti viene inviato uno alla volta e deve essere assegnato ad un contenitore immediatamente dopo il suo arrivo. Il posizionamento di ogni elemento viene effettuato valutando la grandezza dell elemento corrente e sul posizionamento dell elemento precedente, senza avere nessuna informazione sull elemento successivo da posizionare. Inoltre le decisioni dell algoritmo sono irrevocabili: nessun elemento che è stato precedentemente posizionato può essere riposizionato e ogni elemento che è stato scartato (nel caso non sia possibile posizionarlo per mancanza di contenitori) non può essere ripreso per essere successivamente posizionato. 16

In un problema bin packing offline, invece, si è a conoscenza dell intera lista di elementi da dover posizionare, in modo da poter applicare strategie di posizionamento più avanzate. In genere si cerca di implementare algoritmi di packing semi-online, cioè algoritmi che cercano di mediare tra le caratteristiche degli algoritmi online e quelle degli algoritmi offline. Gli algoritmi semi-online sono meno restrittivi degli algoritmi online e permettono alcune operazioni in più ad ogni posizionamento di un elemento. Ad esempio, oggetti posizionati possono essere riposizionati in fasi successive, elementi ricevuti possono essere pre-posizionati secondo la loro grandezza ed è possibile, inoltre, bufferizzare alcuni oggetti prima di posizionarli definitivamente. In genere le richieste che arrivano in un ambiente Cloud sono impredicibili, ecco perché si considera il rapporto tra le performance degli algoritmi online e le performance di un algoritmo offline ottimale. Tale rapporto viene detto rapporto di competizione dell algoritmo online. Di seguito vengono proposti due algoritmi che tengono conto di una versione estesa del bin packing problem con vincolo sulle classi. In questa versione del problema, ogni elemento di un insieme di oggetti possiede una capacità unitaria ed un colore corrispondente ad una classe. Ogni contenitore ha una determinata capacità e può ospitare al massimo n classi di oggetti, dove, nel nostro caso, le classi corrispondono a delle applicazioni e gli elementi appartenenti alla classe corrispondono ai task delle applicazioni. Proprio perché ogni contenitore ha un limite sul numero di classi da poter ospitare al proprio interno, il problema così definito viene detto Class Constrained Bin Packing Problem. L obiettivo per la risoluzione di questo problema è, come nel precedente problema, utilizzare il minor numero di contenitori (e quindi di risorse). Il primo algoritmo è il Class Constrained Multiple Knapsack, il quale cerca di implementare un posizionamento che massimizzi il numero di elementi posizionati. In questo caso ci sono n oggetti, con un profitto p ed una dimensione s, ed m contenitori con capacità c. L obiettivo è cercare di posizionare gli oggetti nei contenitori, nel rispetto delle loro capacità e dei loro vincoli, cercando di massimizzare il profitto (cioè posizionando prima di tutto gli oggetti con profitto maggiore). Gli input ricevuti per valutare il posizionamento degli elementi sono la matrice di posizionamento corrente, la matrice dei 17

vincoli, la capacità di memoria e CPU di ogni VM, e la memoria e la CPU richiesta da ogni applicazione. Gli output dell algoritmo sono la matrice di posizionamento aggiornata e la matrice della distribuzione del carico. In particolare, gli obiettivi di quest algoritmo sono la condivisione di ogni VM con più applicazioni, l incremento del numero di task completati, la riduzione del numero di avvii e di terminazioni delle applicazioni, e il bilanciamento del carico tra le VM. L idea di base dietro quest algoritmo è di ottimizzare ripetutamente le scelte di posizionamento, ad ogni ciclo successivo. Le istanze dell applicazione possono essere classificate come istanze inattive, sottoutilizzate e pienamente utilizzate. Le istanze inutili vengono terminate e vengono avviate le istanze necessarie per l esecuzione dell applicazione. In base al posizionamento, viene calcolato il numero di richieste massimo che può essere soddisfatto utilizzando la distribuzione dei task corrente. L algoritmo termina quando tutte le richieste dell applicazione sono state soddisfatte. Nel caso in cui le richieste non sono ancora soddisfatte, allora l algoritmo distribuisce il carico tra le macchine disponibili. Ad ogni ciclo, l algoritmo prima di tutto invoca il processo per il trasferimento del carico di lavoro sulle VM, e successivamente invoca il processo per cambiare la posizione degli elementi e stabilire una distribuzione del lavoro ottimale. Il trasferimento del carico prima che si modifichi il posizionamento può facilitare la modifica successiva del posizionamento corrente. Non è possibile, però, riposizionare in seguito oggetti che sono stati scartati in un primo momento. Il secondo algoritmo è il Semi-online Class Constrained Bin Packing algorithm ed ha tra i suoi vantaggi l incremento del numero di richieste risolte inviate dalle applicazioni, la riduzione della frequenza dei cambiamenti delle posizioni dei task, la minimizzazione del tempo di risposta ad una richiesta e il risparmio di energia, che si ottiene lasciando alcuni server inutilizzati in standby quando il carico di lavoro è basso. L algoritmo proposto rientra nella famiglia degli algoritmi che gestiscono più colori (classi) di oggetti, dove ogni classe di oggetti è etichettata con un colore ed è inserita in un gruppo di colori. Il numero massimo di classi distinte che un contenitore può ospitare sarà pari a c. L ammontare delle risorse disponibili dei server, che vengono assegnate ai task delle applicazioni che devono essere eseguite, rappresenta la capacità del contenitore. 18

L algoritmo prende in considerazione le risorse disponibili come un insieme finito di server omogenei e con capacità simili, e questo rappresenta lo svantaggio fondamentale di questo algoritmo. La grandezza di un oggetto rappresenta il carico di lavoro dell applicazione, e la capacità di un contenitore è pari al numero di unità del carico di lavoro che possono essere assegnate alle risorse. Le richieste inoltrate dall applicazione rappresentano il numero di oggetti di una specifica classe in attesa di essere posizionati. Oggetti appartenenti a classi diverse vengono posizionati in maniera indipendente nei contenitori. Ogni classe di oggetti ha, inizialmente, un solo contenitore non ancora pieno e ad ogni contenitore possono essere associati al massimo c colori. Se tutti i contenitori associati ad una classe sono pieni o non possono ospitare altri colori, allora un nuovo contenitore viene aperto (viene istanziata una nuova VM). Inoltre, per poter riorganizzare gli oggetti all interno dei contenitori, l algoritmo consente la rimozione di oggetti già posizionati e lo spostamento di oggetti da un contenitore all altro. Figura 4: Posizionamento e rimozione di un elemento nel Class constrained bin packing problem 2.6 Auto scaling e Workflow scientifici [10] I workflow su larga scala di tipo scientifico, generalmente rappresentati come grafici 19

aciclici diretti (DAGs), sono un importante classe di applicazioni, i quali necessitano di una soluzione per la gestione delle risorse efficiente nel cloud computing. I workflow per problemi computazionali su larga scala sono spesso composti di più workflow raggruppati in insiemi (ensemble). I workflow raggruppati in uno stesso insieme hanno tipicamente la stessa struttura interna, ma differiscono tra loro nei dati di input, nel numero di task, e nella grandezza di ogni task che compone il workflow. Un esempio di ensemble scientifico è l applicazione Periodograms, la quale cerca continuamente pianeti non appartenenti al sistema solare individuando cali di intensità luminosa nella luce osservata. Gli scienziati, in genere, danno priorità ai workflow critici per l applicazione e che possono terminare prima degli altri. In questo modo possono osservare in fretta risultati rilevanti per la ricerca e possono portare a termine un determinato numero di workfllow entro i limiti imposti di budget e di tempo. Infatti, la gestione delle risorse in uno scenario come quello descritto, non deve tener conto solo delle metriche collegate alla performance dell applicazione (come, ad esempio, l utilizzo delle risorse), ma deve anche considerare i limiti finanziari legati all utilizzo di cloud pubblici e il rispetto delle deadline, che in contesti del genere assumono un valore critico. L obiettivo dei tre algoritmi proposti, quindi, è quello portare a compimento quanti più workflow ad alta priorità possibili, entro i limiti di tempo e di budget. Solo i workflow che hanno terminato ogni task entro una determinata deadline possono considerarsi completi; risultati parziali non verranno considerati. Per brevità, considereremo, per ogni algoritmo, solo la parte di distribuzione delle risorse. Il primo algoritmo è il Dynamic provisioning Dynamic scheduling (DPDS), ed è un algoritmo online in grado di fornire risorse e assegnare task a tempo di esecuzione. La procedura di distribuzione delle risorse è basata sull utilizzo passato delle risorse. DPDS inizia con un numero fissato di risorse da assegnare, calcolate in base al tempo e al budget disponibile, e aggiorna il numero di risorse assegnabili aggiungendone altre, se le risorse vengono pienamente sfruttate dall applicazione. Dato un budget in dollari b, una deadline in ore d ed un prezzo orario per singola VM in dollari p, è possibile calcolare il numero di VM (Nvm) da assegnare all applicazione in modo che l intero budget non sia esaurito 20

prima dello scadere della deadline del workflow in esecuzione: Nvm = b/(d p). Quindi DPDS distribuisce Nvm VM all inizio dell esecuzione di un ensemble e, in maniera periodica, calcola l utilizzo delle risorse considerando la percentuale di VM inutilizzate nel tempo, aggiornando il numero di VM assegnabili se l utilizzo delle VM è al di sopra o al di sotto delle soglie considerate. Poiché ogni VM ha un prezzo orario, l algoritmo considera solo le VM inutilizzate che si stanno avvicinando al loro tempo di terminazione, per valutare se rinnovare l acquisto o meno. Per prevenire la terminazione prematura di istanze che sono già state pagate, ad ogni ciclo dell algoritmo vengono terminate non più della metà delle risorse inutilizzate. Per evitare un incremento incontrollato nel numero di istanze, possibile nel caso di più workflow che lavorano in parallelo, l algoritmo non avvierà una nuova VM se il numero di VM in esecuzione è più grande del prodotto tra Nvm e un parametro di autoscaling Vmax, dove, se non specificato, Vmax=1. Il Workflow-aware DPDS estende DPDS introducendo una procedura di ammissione dei workflow, che è invocata ogni volta che l algoritmo vede il primo task di un nuovo workflow alla testa della coda di priorità dei task. La procedura di ammissione del workflow stima se c è abbastanza budget rimanente per ammettere un nuovo workflow; se non c è allora il workflow non viene ammesso e i suoi task sono rimossi dalla coda. WA- DPDS confronta il budget speso ed il budget rimanente, tenendo in conto anche il costo delle VM in esecuzione ed il costo dei workflow che sono stati ammessi. Inoltre, l algoritmo aggiunge un piccolo margine di sicurezza pari al 10% del costo orario di computazione per evitare di superare i limiti di budget. La procedura di ammissione non è solo utile per prevenire che workflow a bassa priorità prendano il posto di quelli ad alta priorità, ma anche per rifiutare workflow di grandi dimensioni che porterebbero ad un superamento del budget, ammettendo invece workflow più piccoli che riescono a terminare i propri task e ad utilizzare in maniera più efficiente le risorse inutilizzate. In ultimo, lo Static provisioning Static scheduling (SPSS) è un algoritmo offline che crea un piano di distribuzione e di assegnazione delle risorse prima che venga eseguito un qualsiasi task di un workflow (a differenza degli altri due algoritmi che operano a tempo di esecuzione). In questo modo SPSS avvia solo workflow che conosce a priori e che 21

possono essere completati entro i limiti di tempo e di budget, eliminando gli sprechi che potevano verificarsi con gli algoritmi dinamici precedenti. SPSS valuta ogni workflow e lo inserisce in una coda di priorità; se il workflow eccede le deadline e il budget, allora viene scartato. Una volta che il piano di esecuzione è completo, le VM vengono avviate e i task vengono loro assegnati secondo l ordine di priorità. Lo svantaggio di algoritmi statici come SPSS è la poca robustezza in caso di cambiamenti dell ambiente e dell applicazione, cambiamenti questi che possono rendere inconsistente la pianificazione effettuata. L idea di base dell algoritmo è che se ogni workflow dell insieme può essere completato entro i limiti di tempo con il minor costo possibile, allora il numero di workflow che possono essere completati entro un determinato budget viene massimizzato. Per pianificare un workflow SPSS assegna delle sotto-deadline ad ogni task del workflow: se ogni task può essere completato entro la propria deadline nel modo più economico possibile (senza spreco di risorse), allora il costo dell intero workflow può essere minimizzato. SPSS assegna le sotto-deadline ad ogni task basandosi sui tempi morti del workflow, tempi che si definiscono come l ammontare di tempo extra grazie al quale un workflow può estendere il proprio percorso critico e rimanere ancora entro i limiti di tempo previsti per il suo completamento. Ogni VM viene vista dall algoritmo come un insieme di blocchi, della durata di un ora, divisi in slot con durata variabile (al massimo pari ad un ora). Ad ogni task presente nel workflow viene assegnato uno slot che sia il meno costoso e sia abbastanza grande da poter garantire al task di terminare entro la propria deadline. Quando viene calcolato il costo per assegnare un task ad una determinata VM, l algoritmo deve scegliere tra slot inutilizzati, cioè frazioni di blocchi pagati in precedenza per altri task e che sono stati liberati, e slot di un nuovo blocco a pagamento. Se un task, ad esempio, richiede 10 min per essere completato, l algoritmo può scegliere se allocare un nuovo blocco al costo di 1$, oppure se allocare il task in un blocco che contiene uno slot maggiore o uguale a 10 min, senza dover attingere nuovamente al budget. Se il costo di slot appartenenti a due VM è uguale, allora viene scelto lo slot con il tempo di avvio più veloce. Per prevenire che troppe VM vengano istanziate, l algoritmo preferisce sempre estendere il tempo di esecuzione delle VM già esistenti, prima di allocarne di nuove. In 22

questo modo l algoritmo allocherà un nuovo blocco orario solo se non ci sono slot inutilizzati abbastanza grandi e abbastanza recenti, all interno di blocchi già esistenti, che consentono di terminare il task entro la propria deadline. Oppure, l algoritmo allocherà una nuova VM solo se non è possibile aggiungere un blocco orario ad una VM esistente per completare il task entro la propria deadline. 23

Capitolo 3: Soluzioni implementate dai Cloud provider In questo capitolo osserveremo i meccanismi di autoscaling di due dei maggiori cloud provider del settore. Il primo è Amazon Web Service (AWS), azienda leader nel mercato, che ha tra i suoi tipi di contratto le Spot instances, un interessante soluzione che offre all utente un risparmio economico a fronte di una non predicibilità della durata delle istanze, come vedremo di seguito. Il secondo Cloud provider (SaaS) è Netflix, azienda di video on demand che da tempo ha reso disponibile sul proprio blog tecnico il funzionamento di Scryer, il sistema di autoscaling progettato ad-hoc per migliorare le prestazioni della piattaforma on demand. 3.1 Amazon e le Spot Instance [11] Le spot instance sono particolari opzioni di pagamento per l acquisto di VM, opzione supportata da AWS, azienda leader nel mercato degli IaaS pubblici. Le spot instance si comportano esattamente come ogni altra VM di Elastic Cloud Computing (EC2), la piattaforma cloud di Amazon. La differenza sta nel listino prezzi delle VM: il prezzo orario della VM, infatti, non è fissato. In linea di massima i clienti dei Cloud provider pagano il tempo (generalmente in ore) in cui le macchine rimangono accese, secondo un modello paghi quello che usi, ed ogni IaaS provider ha il suo modello di fatturazione per le VM in uso. AWS offre tre opzioni di acquisto. La prima è On-demand, cioè si paga ogni ora in cui la Virtual Machine è accesa. Non ci sono investimenti iniziali e non ci sono impegni d uso. E un semplice modello che permette di usare ciò che paghi, ma la tariffa oraria è molto cara. La seconda opzione è Reserved: i clienti pagano per un periodo (settimane, mesi, anni) anziché per ore d uso. Ciò significa che, indipendentemente se le istanze siano utilizzate o meno, il prezzo resta invariato. Infine, le Spot instance: i pagamenti avvengono sempre per ore d uso, come nell opzione On-demand, ma il prezzo della tariffa oraria non è fissato. I clienti fanno un offerta su quanto sono disposti a pagare 24

per le ore d uso. AWS definisce dinamicamente lo Spot price, il quale varia in tempo reale basandosi sul cambiamento delle domande dei clienti e delle offerte del provider. Se l offerta del cliente è al di sopra dello Spot price corrente, allora l istanza viene avviata. Se lo Spot price cambia e si alza al di sopra dell offerta del cliente, l istanza viene terminata da AWS. Le Spot instance possono essere utilizzati in sistemi composti da spot instance e reserved instance, le quali rimarranno sempre accese per garantire la disponibilità del servizio, indipendentemente dalla presenza delle spot instance. Inoltre, l utilizzo delle spot instance nei processi di autoscaling riduce i costi di budget per l implementazione dei servizi cloud. Nell implementazione dei meccanismi di autoscaling, il valore corrente delle spot instance può essere acquisito in tempo reale grazie alle API messe a disposizione da AWS. Una volta che l algoritmo di autoscaling abbia stabilito quante unità sono necessarie per l operazione di scaling, viene valutata la scelta dell opzione d acquisto che garantisca il maggior risparmio in termini di budget. Acquisito lo Spot price corrente, viene fatta un offerta di poco superiore, valutando se l offerta per la spot instance sia superiore o inferiore al costo orario delle istanze On-demand. La possibilità della scelta delle istanze On-demand rende sicura la possibilità di effettuare una operazione di scaling (che sarebbe stata incerta nel caso dell utilizzo delle sole Spot instance, in quanto non sempre disponibili). Per l operazione di scale down, dal momento che nella lista di server attivi saranno presenti server con costi d attivazione diversi, vengono terminati prima i server che hanno un costo maggiore rispetto agli altri della lista, tenendo attivi i più economici. Le uniche istanze che non saranno mai terminate sono le Riserved, sia perché il cliente ha pagato per un intero periodo e non fa alcuna differenza se le istanze sono attive o meno, sia perché, in uno scenario in cui si offre un servizio attivo 24 ore su 24, ci devono essere sempre istanze attive che possano garantire l erogazione del servizio. Nel caso delle Spot instance, quando l offerta del cliente è inferiore allo Spot price, le istanze vengono automaticamente terminate da AWS. 25

3.2 Netflix e Scryer [12] Scryer è un sistema ideato da Netflix, l azienda di contenuti video on demand, che permette di istanziare il giusto numero di risorse di AWS per poter gestire adeguatamente il traffico di utenti che richiedono il servizio. A differenza di Amazon Auto Scaling, che reagisce al traffico monitorando le metriche e effettuando azioni di scaling in tempo reale, Scryer agisce cercando di prevedere quale sarà il traffico (e quindi il bisogno computazionale) al quale il sistema sarà sottoposto, istanziando nuove risorse sulla base di queste previsioni. Poiché il sistema di autoscaling di Amazon non era in grado di coprire alcuni casi d uso del servizio, si era reso necessario per Netflix adoperare un sistema di autoscaling che riuscisse a risolvere i seguenti problemi: picchi immediati nel numero delle domande da parte dei client, che lasciavano i server vulnerabili a causa dei tempi troppo lunghi per l istanziazione di nuove risorse; interruzioni del servizio causate da valutazioni errate nelle operazioni di scale down, operazioni spesso eseguite prima di un picco delle domande; andamenti diversi del traffico nell arco della giornata. Tutti questi problemi sono facilmente risolvibili eseguendo un numero elevato di azioni di scale up, le quali porterebbero però ad un sovraccarico delle operazioni di scaling. Oppure si potrebbe tenere sempre attivi un numero più elevato di server, ma questo andrebbe ad elevare in modo considerevole i costi di gestione del servizio. Netflix è riuscita a trovare una soluzione esaminando la tendenza nel tempo del proprio traffico di dati, osservando che, in un intervallo di 5 giorni, l andamento del traffico ha avuto un comportamento approssimativamente regolare, il che ha consentito di adottare politiche di scaling adeguate al problema. I benefici riscontrati utilizzando Scryer sono stati un miglioramento dell utilizzo delle proprie risorse cluster locali, una disponibilità ed affidabilità del sistema più elevate ed una riduzione dei costi per l acquisto di istanze di EC2. Eventuali andamenti del traffico non predicibili dal sistema possono essere risolti grazie all utilizzo in concomitanza sia del sistema Scryer, sia del sistema di autoscaling real time di Amazon. 26

Conclusioni In questo elaborato abbiamo esaminato i vantaggi e le problematiche legate all implementazione degli algoritmi di autoscaling. Nel primo capitolo abbiamo presentato le definizioni e abbiamo descritto le caratteristiche principali del Cloud Computing e dei meccanismi di Autoscaling e Monitoring. Nel secondo capitolo sono state descritte le varie soluzioni per poter implementare l autoscaling in diversi contesti e seguendo diversi approcci. Abbiamo osservato l importanza di definire le metriche e i segnali che il sistema deve cogliere per poter comprendere quando intervenire con delle operazioni di scaling, segnali che possono essere estrapolati dall ambiente esterno (nel caso si utilizzi una logica basata su Learning automata) oppure dall applicazione stessa che è in esecuzione sulle VM, andando ad utilizzare l output dell applicazione come trigger per lo scaling. Abbiamo osservato le differenze nel trattare applicazioni workflow, applicazioni con task che sono eseguiti sequenzialmente seguendo un percorso critico, e bag-of-task, cioè applicazioni con task debolmente accoppiati ed eseguibili in parallelo senza condizioni sull ordine di esecuzione. Inoltre abbiamo osservato che, nello scegliere quale logica di autoscaling implementare, è necessario effettuare un trade off tra bilancio del carico, cioè distribuire il carico di lavoro su tutte le risorse disponibili, e risparmio di risorse, utilizzando il minor numero di risorse sovraccaricando quelle già in esecuzione. Infine abbiamo analizzato in che modo implementare i meccanismi di autoscaling in un contesto di ricerca scientifica, dove sono presenti infrastrutture ibride, composte da cluster e istanze di cloud privati e pubblici, e numerosi percorsi critici raggruppati in ensembles. Nel capitolo conclusivo abbiamo esaminato alcune soluzioni implementate dai cloud provider pubblici. In particolare abbiamo analizzato i vantaggi che possono essere ottenuti utilizzando le Spot instance di Amazon Web Service, consentendo agli sviluppatori di risparmiare risorse, e abbiamo esaminato in che modo Netflix è riuscita a sviluppare il proprio sistema di autoscaling osservando la regolarità dell andamento del proprio traffico dati. 27