Workflow del programma

10.1.1 ElasticDaemon

La classe eseguibile principale è ElasticDaemon, che si occupa di inizializzare tutti gli oggetti necessari per poter rendere attivo il cluster di istanze. Quando tutte le operazioni di inizializzazione sono state eseguite, ossia tutti gli oggetti richiesti sono stati creati, la classe crea un oggetto di tipo ElasticClusterThread, fornendo come parametri gli oggetti precedentemente definiti. Il ruolo della classe principale a questo punto è terminato per il cluster in questione, potrà essere utilizzata per gestire eventuali modifiche da effettuare ai parametri impostati nella prima fase.

Quando gli oggetti vengono creati, vengono effettuate alcune operazioni iniziali al fine di garantire il funzionamento corretto del sistema: in particolare vengono preparati i file necessari per l'esecuzione di HAProxy, creando un file di configurazione relativo al nuovo cluster e creando una copia del file eseguibile, che sarà poi utilizzato quando il cluster di istanze diventerà operativo. Un'ultima operazione che il sistema deve eseguire è quella di aggiungere l'indirizzo IP pubblico del load balancer all'interfaccia di rete pubblica della macchina, in questo modo si possono ricevere i pacchetti che hanno come indirizzo di destinazione quell'IP, i quali a loro volta saranno poi gestiti dal load balancer.

10.1.2 ElasticClusterThread

Il Thread appena avviato, della classe ElasticClusterThread, contiene tutte le funzioni richieste per gestire in maniera autonoma il comportamento dell'Autoscaling Cluster: il thread è costituito da un loop infinito, che continuamente verifica lo stato delle istanze attive e, in base al carico di lavoro riscontrato, ha il compito di attivare le scaling operation opportune. Nella fase di inizializzazione vengono indicati tutti gli oggetti che concorreranno nella gestione dell'insieme di istanze, in particolare vengono memorizzati un oggetto di tipo LoadBalancer, uno di tipo monitor e una lista di oggetti Instance. Prima di entrare nel loop infinito il thread avvia il processo di monitoring, costituito anch'esso da un thread, di classe VMMonitor, che verrà descritto più dettagliatamente in seguito. Una volta avviato il thread di monitoring il cluster inizia a controllare se sono verificate le condizioni per avviare o, in alternativa spegnere, una istanza del cluster; se nessuna di queste condizioni risulta vera, il thread attende un intervallo di tempo di qualche secondo e poi riesegue i controlli sulle condizioni; la pausa che viene effettuata tra un ciclo e l'altro è stata inserita per non sovraccaricare inutilmente la macchina che esegue questo programma, infatti non è necessario che il thread di controllo risponda in realtime ad un

10.1. Workflow del programma 149 cambiamento dello stato del cluster, dato che le stesse scaling operation richiedono tempi di attesa dell'ordine di qualche minuto. Conviene quindi mantenere il sistema un po’ meno reattivo, ma che utilizza molte meno risorse, in particolare la CPU.

Oltre a monitorare se le condizioni per avviare una scaling operation siano verificate, ad esempio se il sistema è sovraccarico, si deve avviare una Scale-up operation, il thread di controllo del cluster deve controllare anche se vi siano altre operazioni attive in quell'istante, se questo ulteriore controllo non venisse effettuato, può succedere che più scaling operation uguali vengano attivate in sequenza, facendo aumentare, o diminuire, troppo velocemente il numero delle istanze attive.

Basti pensare al caso in cui si verifichi un picco di richieste, ad ogni iterazione la condizione per attivare una nuova scale-up operation sarebbe vera, si avvierebbero così in numero imprecisato di nuove istanze, senza considerare che si stanno già svolgendo le operazioni di startup di altre macchine virtuali. Questo fenomeno non solo è logicamente scorretto, ma sarebbe anche poco gradito agli utenti, che dovrebbero pagare per un numero troppo elevato di istanze attive, quando la quantità richiesta per soddisfare le richieste in arrivo sarebbe molto inferiore.

10.1.3 VMMonitor

Questa classe si occupa di monitorare continuamente lo stato di utilizzo di risorse delle istanze, gli oggetti di questa classe sono eseguiti come Thread, infatti ad ogni Cluster di istanze viene associato un thread di classe VMMonitor. Le operazioni svolte da questo processo sono abbastanza semplici: il thread è costituito da un ciclo infinito, all'interno del quale viene scandita la lista contenente le informazioni sulle istanze attive, ad ognuna di esse viene inviata la richiesta per i dati sull'utilizzo delle risorse. Quando tutte le informazioni sono state raccolte, queste vengono elaborate secondo quanto definito nella fase di inizializzazione, calcolando i valori massimi, medi, ecc. Infine vengono aggiornati i valori generali, che rappresentano lo stato di utilizzo di risorse da parte del cluster; tali variabili sono quelle che poi vengono confrontate con le soglie definite dall'utente, per decidere se il cluster di istanze è sovraccarico di richieste o meno.

Il thread di monitor contiene, oltre alle istruzioni per l'esecuzione del thread principale, una serie di metodi per l'accesso ai valori raccolti, in particolare per confrontare i valori con le soglie di massimo e minimo utilizzo, come i metodi isOverloaded e isUnderloaded.

10.1.4 LoadBalancer

Questa classe si occupa di interagire e di gestire il funzionamento del load balancer associato all'Autoscaling Cluster; ad ogni oggetto ElasticClusterThread è associato un oggetto LoadBalancer, che contiene tutti i parametri e fornisce tutti i servizi per gestire l'esecuzione dell'istanza di HAProxy ad essa dedicata.

Quando viene inizializzato un oggetto di tipo LoadBalancer, viene per prima cosa effettuata una copia dell'eseguibile di HAProxy, che si occuperà del bilanciamento del traffico tra le istanze. Oltre

all'eseguibile viene creato un file di testo contenente le informazioni generali che deve conoscere il load balancer, come la politica di gestione delle sessioni, l'algoritmo di bilanciamento e l'indirizzo IP pubblico e la porta su cui dovrà ascoltare il frontend di HAProxy. L'istanza di HAProxy non viene avviata fino a quando non è presente almeno un'istanza attiva in grado di rispondere alle richieste in arrivo sul frontend, visto che per poter completare le procedure di startup lo stesso HAProxy richiede che venga definito almeno un server di backend. Gli oggetti di tipo LoadBalancer non sono eseguibili come thread, ma forniscono solo metodi di supporto che vengono invocati durante le scaling operation avviate dalla classe che si occupa della gestione e dell'esecuzione del cluster di istanze.

Le principali funzioni che fornisce la classe LoadBalancer sono: • Avvio e riavvio in modalità soft dell'istanza di HAProxy

• Modifica del file di configurazione in base ai nuovi parametri e alle nuove istanze attive

• Invio di comandi al load balancer, come il comando per impostare un server di backend in modalità “Zombie”

• Richiesta dei dati statistici sulle sessioni, per verificare se vi sono ancora sessioni attive su un determinato server di backend

10.1.5 Instance

Questo tipo di oggetto rappresenta un'istanza Eucalyptus, insieme a tutti i dati ad essa correlati; il sistema mantiene in memoria lo stato attuale di ogni istanza, insieme a tutti quei dati che vengono assegnati a runtime ad ogni istanza da Eucalyptus come l'ID univoco assegnato alla virtual machine e l'indirizzo IP ad essa associato. Gli oggetti Instance contengono poi anche tutti gli altri parametri caratteristici di un'istanza, come il tipo di macchina e il codice dell'immagine utilizzata per l'esecuzione; ogni oggetto fornisce i classici metodi get e set per i parametri appena descritti; al momento della creazione dell'oggetto non tutti i valori dei parametri sono conosciuti, infatti l'indirizzo IP e l'ID di una particolare istanza sono noti solo dopo che sono state completate le procedure di startup della macchina virtuale sul nodo di Eucalyptus.

10.1.6 Launch Configuration

Ogni oggetto ElasticClusterThread deve mantenere in memoria un puntatore ad un oggetto LaunchConfiguration, che contiene i parametri che il sistema deve utilizzare quando deve richiedere l'avvio di una nuova istanza ad Eucalyptus; l'oggetto LaunchConfiguration mantiene in memoria anche la access key e la secret key necessarie per potersi autenticare durante le interazioni con il servizio di IaaS.

I dati mantenuti in memoria corrispondono a tutti i parametri di avvio di una nuova macchina virtuale, ossia l'immagine da utilizzare, il tipo di macchina, la chiave di accesso da inserire per i collegamenti ssh e eventuali user-data che si vogliono passare all'istanza.

10.2. Aspetti Pratici 151