Università degli Studi di Napoli Federico II

Transcript

1 Università degli Studi di Napoli Federico II Scuola Politecnica e delle Scienze di Base Area Didattica Scienze MM.FF.NN. Master di I Livello in Tecnologie per il CAlcolo Scientifico ad Alte Prestazioni - CASAP Tesi di Master GAPP: Un'applicazione Android per la piattaforma GaaS Relatori Prof. Giuliano Laccetti Ing. Giovanni Battista Barone Anno Accademico Candidato Andrea Solla matr. Z62/000006

2 Indice PREFAZIONE...4 INTRODUZIONE...5 i. Il contesto di lavoro: progetto GaaS...5 ii. Gli obiettivi del lavoro di tesi Il problema e l'ambiente di riferimento L'ambiente hardware e software Il glossario Specifiche di prodotto I casi d'uso Lato client Lato server Strumenti e progettazione Modalità di comunicazione tra client e server Un linguaggio di comunicazione universale: il JSON Cifratura della comunicazione Diagramma delle classi Lato client Lato server Diagrammi di sequenza Lato client Lato server Il database MySQL...34 Pagina 2 di 51

3 Tabella USERS Tabella SITI Tabella ELEMENTI Tabella RISORSE Tabella RETE Tabella IP Tabella FLAVOR Tabella ESECUZIONI Diagramma EER Il Prodotto finale: GAPP Login Registrazione utente Schermata gestione siti Eliminazione sito Creazione sito Creazione elemento Visualizzazione dettagli e gestione elemento Conclusioni e sviluppi futuri...50 Pagina 3 di 51

4 PREFAZIONE Il lavoro svolto in questa tesi si colloca in un contesto progettuale più ampio che ha l'obiettivo di realizzare una piattaforma, GaaS, per l'integrazione dei paradigmi di Grid e Cloud computing. L'idea progettuale è un'iniziativa del gruppo di gestione del datacenter SCoPE (scopeadmin). Il Master CASAP ha fornito l'occasione e le persone per consolidare l'idea progettuale, già in parte realizzata negli ultimi due anni, attraverso la costituzione di un gruppo di lavoro al quale hanno partecipato quattro studenti del Master CASAP (F. Iannone, C. Napolitano, S. Scamardella e A. Solla) e i membri del gruppo di gestione del datacenter ScoPE (tutor relatori delle rispettive tesi di Master). Ciascuno degli studenti coinvolti ha contribuito alla definizione e all'arricchimento dell'architettura generale di GaaS, nonché all'implementazione di specifici servizi di gestione o di accesso. L'approccio utilizzato per lo svolgimento delle attività ha richiesto periodici incontri di coordinamento tra tutti i partecipanti al gruppo di lavoro, nonchè una stretta collaborazione tra gli studenti coinvolti nella realizzazione delle varie attività. Tutto il lavoro è stato svolto su un set di risorse del datacenter SCoPE dedicate all'allestimento dell'architettura di riferimento e una versione prototipale del prodotto realizzato è attualmente disponibile sulle risorse suddette. Pagina 4 di 51

5 INTRODUZIONE i. Il contesto di lavoro: progetto GaaS Con l'aumentare della complessita dei problemi nel calcolo scientifico e nella vita di tutti i giorni, le singole macchine anche se dotate di CPU multi-core molto performanti, risultano essere insufficienti per l'esecuzione di applicazioni necessarie alla risoluzione di problemi complessi. E' proprio da questa necessita che negli ultimi anni si e diffuso l'utilizzo di infrastrutture di calcolo parallelo e distribuito basate sull'utilizzo di diversi paradigmi tra i quali i più diffusi oggi sono Grid e Cloud. Anche se l'utilizzo del paradigma Grid si è molto diffuso all'interno della comunità scientifica, esso presenta alcuni svantaggi legati ad esempio alla staticità del modello di aggregazione delle risorse che rende complicato (se non impossibile) aggiungere, rimuovere o modificare dinamicamente risorse di calcolo o storage in un' infrastruttura Grid già esistente. La configurazione dei servizi Grid è infatti demandata esclusivamente all'amministratore del sistema e non può avvenire ondemand. Di contro, il Cloud computing sembra essere dotato di quella flessibilità che manca al Grid computing. Ed è proprio da questa osservazione che nasce l'idea di sfruttare l'elasticità del Cloud computing per realizzare infrastrutture Grid più dinamiche ed eventualmente fornite on-demand. In parole povere si tratta di virtualizzare l'ambiente Grid edi fornirlo all'utente come servizio Cloud creando, così, una particolare piattaforma Cloud di tipo PaaS (Platform as a Service) [1] che prende il nome appunto di GaaS (Grid as a Service) [2]. Il progetto GaaS nasce con l'obiettivo di realizzare servizi Grid virtuali (di calcolo e storage) utilizzando risorse Cloud private (o, in previsione, pubbliche). In particolare, in questo lavoro, l'attenzione è focalizata sul servizio GSS (Grid Site Pagina 5 di 51

6 Service) di GaaS, ovvero, su quel servizio che si occupa dell integrazione, in un infrastruttura Grid completa di servizi di alto livello, di un sito Grid completo di servizi di calcolo (Computing Element e Worker Nodes), di storage (Storage Element) e di un sistema informativo di basso livello (SiteBDII). ii. Gli obiettivi del lavoro di tesi Con la nascita e la diffusione su larga scala dei moderni dispositivi mobili o smartphone, l'attività degli sviluppatori di software si è estesa anche alla creazioni di applicazioni eseguibili su tali dispositivi: le APP. Grazie alle loro capacità computazionali, oramai, questi devices sono assimilabili a veri e propri personal computer dai costi, in alcuni casi, molto contenuti. Inoltre, il fatto che questi siano perennemente connessi alla rete, li rendono un'ottima piattaforma per l'accesso a servizi remoti. Tali caratteristiche, unite al fatto che questi dispositivi sono alla portata di tutti, ci hanno convinto ad investire su di essi per lo sviluppo di software per il management di GaaS. L'obiettivo di questa tesi è stato quello di progettare e sviluppare GAPP, un'applicazione ANDROID [3] che, da remoto, consenta la creazione e la gestione di siti Grid virtuali. La app interagisce con le necessarie funzionalità di basso livello implementate nell'ambito di altre due tesi di Master dagli studenti Ciro Napolitano e Francesco Iannone. Lo scopo ultimo di GAPP è facilitare di molto la vita degli amministratori di sistema che, in qualsiasi momento ed in qualsiasi luogo, possono gestire le Grid virtuali della piattaforma GaaS, garantendo in tal modo un più elevato livello di servizio per gli utenti. Pagina 6 di 51

7 1. Il problema e l'ambiente di riferimento In questa sezione viene riportata l'architettura di riferimento per il lavoro nonché le funzionalità richieste per l'applicazione GAPP L'ambiente hardware e software L'architettura utilizzata in questo progetto è una classica struttura client/server a più livelli. Come si vede dalla Figura 1, alla base (livello 0) di questa architettura troviamo una piattaforma di Cloud computing prototipale basata su Openstack composta da un controller node che fornisce informazioni sulle risorse disponibili e sulle istanze di risorse già create, e da due compute node che, invece, si occupano di ospitare le macchine virtuali istanziate. Ad un livello superiore (livello 1) dell'architettura c'è il GaaS server, che fornisce gli strumenti per l'interoperatività tra la piattaforma Openstack e il client mobile: esso è client agli occhi del controller Openstack, al quale invierà richieste relative alla creazione, eliminazione e visualizzazione degli stati delle istanze in esecuzione sul cloud, mentre è un server agli occhi del client mobile (livello 2 dell'architettura) poiché risponde alle sue richieste dell'utente. In particolare, al livello 1 dell'architettura (su cui si è focalizzata l'attenzione di questo lavoro di tesi) sono presenti: Un server Tomcat: che si occuperà di eseguire la Java servlet che comunicano direttamente con il device mobile [4]. Un server MySQL: per la memorizzazione delle informazioni di GAPP I client di OpenStack necessari all'implementazione dei servizi di basso livello che GAPP invoca. Infine, al livello d'astrazione più alto, si trova il client, rappresentato da un'applicazione Android che, tramite una comoda interfaccia grafica, da la possibilità all'utente di creare e gestire siti Grid virtuali e di accedervi come se Pagina 7 di 51

8 fossero reali macchine fisiche astraendo completamente il motore OpenStack sottostante. Figura 1: Schema dell'archiettura hardware/software di riferimento La scelta di uno schema architetturale a più livelli garantisce un elevato livello di trasparenza grazie al quale l'utente finale non dovrà assolutamente curarsi delle modalità di gestione e realizzazione delle macchine virtuali sottostanti, ma ricoprirà semplicemente il ruolo di utilizzatore. Inoltre l'approccio consente di demandare tutte le operazioni più onerose ai livelli sottostanti sollevando il client Android da eccessivi carichi di lavoro. Questo da la possibilità di installare il client anche su i terminali Android di prima generazione dotati di ridottissime risorse di calcolo. Infine, grazie alle caratteristiche di modularità dell'architettura, ogni componente può essere sostituita senza troppe complicazioni. Pagina 8 di 51

9 1.2. Il glossario Prima di iniziare la progettazione, è opportuno analizzare la lista delle principali parole chiavi che si incontreranno durante il corso di questa tesi. Sito Grid: è una raccolta di risorse informatiche interconnesse atte a raggiungere un obiettivo comune. Elemento: sono le risorse di cui dispone il sito Grid e a seconda del ruolo svolto, possono essere suddivisi in quattro differenti categorie: Computing Element (CE), Worker Node (WN), Storage Element (SE) e Site BDII (SB). Computing Element: elemento in grado di controllare e monitorare la potenza computazionale del sito Grid, fornendo un interfaccia uniforme a queste risorse. Worker Node: sono quelle macchine adibite al calcolo computazionale all interno di un sito. Per la loro gestione/monitoraggio vengono installati su di essi diversi client. Storage Element: è il componente a cui viene affidata la fase di memorizzazione delle informazioni:esso infatti offre un accesso uniforme allo spazio disco presente sulla macchina. Questo elemento della griglia può comodamente controllare un enorme numero di array di dischi di varia natura, e quindi diversi Terabyte di dati. Site BDII: è il componente contenente il sistema informativo della griglia. Di norma, questo elemento è costituito da un server LDAP standard che viene aggiornato da un processo esterno. Certificato X509: sono dei file, con una validità temporale limitata, usati per garantire l'identità di un soggetto, sia esso una macchina o una persona. Tale certificato, fornito da un ente terzo fidato e riconosciuto come Certification Authority (CA), è a sua volta autenticato per evitarne la falsificazione attraverso una firma digitale (chiave privata). Utente amministratore: è l'utente che ha il pieno accesso al sistema; Esso può effettuare la creazione di nuovi siti e elementi e visualizzare e gestire tutti i siti in esecuzione sul sistema, nonché accedere direttamente alle istanze tramite una connessione SSH. Pagina 9 di 51

10 Utente normale: è una tipologia di utente con accesso limitato; Esso può effettuare la creazione di nuovi siti ed elementi entro certi limiti, e può visualizzare e gestire esclusivamente i siti di sua proprietà Specifiche di prodotto Una volta definito il vocabolario di riferimento, bisogna descrivere le funzionalità del prodotto da realizzare. GAPP è un'applicazione mobile per Android per la gestione delle risorse grid istanziate sulla piattaforma GaaS. L'app necessita di un sistema di autenticazione dell'utente basato su certificati X509; Questa infatti deve essere in grado di aprire il certificato, estrarre le informazioni che identificano univocamente l'utente (in particolare la chiave pubblica e il nome utente) ed inviarle al server remoto, il quale si occuperà della profilatura (normale o amministratore) e provvederà al rilascio dei permessi idonei al tipo di utente. Una volta superata la fase di autenticazione, l'utente si trova nella schermata principale dal quale può creare un nuovo sito Grid o modificarne uno già esistente inserendo o eliminando elementi da questo. Inoltre, deve poter visualizzare le informazioni generali dei singoli elementi dei siti già istanziati (es. stato, indirizzo IP, creatore...ecc). Inoltre l'applicazione deve consentire di gestire i singoli elementi, dando la possibilità di accenderli, spegnerli e riavviarli come se fossero vere e proprie macchine fisiche; Infine gli utenti amministratori, devono poter gestire in maniera diretta agli elementi accedendovi tramite sessioni SSH. Pagina 10 di 51

11 1.4. I casi d'uso Lavoro preliminare alla realizzazione del lavoro è stato quello relativo ad una prima analisi dei requisiti volta all'individuazione delle funzionalità da implementare in questa prima versione del prodotto. Nel prossimo paragrafo sono riportati alcuni diagrammi di Use Case che hanno dato la possibilità di ottenere da subito il quadro generale del lavoro da eseguire Lato client Come possiamo vedere dalla Figura 2, esitono almeno 9 use case principali (corrispondenti a 9 differenti azioni che l'utente potrebbe voler eseguire) che sono stati considerati durante la successiva fase di progettazione. Figura 2: use case lato client Pagina 11 di 51

12 Login: E' una fase preliminare nonché fondamentale nell'uso del sistema. Per effettuare l'accesso al sistema è richiesto un certificato di tipo PKCS#12 che contiene le informazioni sull'identità dell'utente. Una volta aperto ed estratto le informazioni necessarie al riconoscimento dell'utente possono verificarsi due tipologie di scenario: 1. L'utente non viene riconosciuto dal sistema. In questo caso l'utente può richiedere all'amministratore l'associazione del proprio certificato ad un nuovo account per il sistema (sotto-caso d'uso Registrazione utente ). 2. L'utente viene riconosciuto dal sistema. La profilatura dell'utente può essere di due tipologie: Utente normale e Amministratore. Creazione sito La creazione di un nuovo sito Grid virtuale prevede la creazione e successiva configurazione di una Grid Farm minimale contenente un Compute Element, un Site BDII e, se l'utente lo richiede, uno Storage Element. Per effettuare la creazione del sito, l'utente dovrà specificare il nome del nuovo sito, il numero massimo di Worker Node associabili al sito e le taglie dei CE, SB ed eventuale SE. Se si desidera, una volta terminata la creazione del sito, possono essere aggiunti in nuovi elementi (vedi caso d'uso Creazione elemento ). Eliminazione sito Durante questa fase l'utente, in base alla profilatura riservatagli, può eliminare un Sito dalla piattaforma GaaS, eliminando di conseguenza tutte le istanze ad esso collegate (CE, SB, SE e WN). Pagina 12 di 51

13 Creazione elemento Una volta che la creazione e la configurazione di un sito è stata completata, l'utente può aggiungere uno o più elementi a questo in modo da aumentarne le capacità computazionali. L'utente ha la possibilità di aggiungere uno Storage Element a patto che esso non sia stato già aggiunto al momento della creazione del sito, oppure un numero arbitrario di Worker Node a patto che essi non superino il numero di Worker Node massimo imposto al momento della creazione del sito. Eliminazione elemento Se non più necessario, l'utente (se ne ha i permessi) può eliminare un elemento da un sito Grid. Visualizzazione dettagli elemento L'utente può visualizzare le informazioni complete relative ad un singolo elemento (nodo) della griglia ottenendo così informazioni relative al suo stato e alle sue caratteristiche hardware (es. CPU, RAM e Storage). Spegnimento/Riavvio elemento Essendo un elemento della griglia un elaboratore a tutti gli effetti (anche se virtuale), l'utente ha la possibilità di gestirlo in tutti i suoi aspetti, compreso il riavvio e lo spegnimento del dispositivo. Connessione ad elemento Se l'utente ha una profilatura di tipo amministratore, esso potrà connettersi alle macchine virtuali di una griglia effettuando una connessione SSH verso queste. Pagina 13 di 51

14 Lato server Figura 3: use case lato server Come è possibile notare dal diagramma di use cases riportato in Figura 3, i casi d'uso che avvengono tra l'applicazione mobile e la servlet sono quasi del tutto speculari a quelli che avvengono tra l'utente e l'applicazione; questo accade perchè, come detto in precedenza, l'applicazione vuole essere soltanto una interfaccia grafica remota del vero e proprio motore rappresentato dalla servlet e dagli script richiamati da quest'ultima. A quello appena detto fanno eccezione i casi d'uso Richiesta lista elementi e Richiesta lista siti che vengono utilizzati molteplici volte durante l'esecuzione di quasi tutti i casi d'uso del client. Da notare inoltre che, Pagina 14 di 51

15 mentre nell'applicazione mobile la registrazione del nuovo utente è un sotto-caso dello use case Login, sul lato server i due casi sono considerati completamente separati. Questa separazione è dovuta al fatto che per la servlet ogni richiesta dell'applicazione è standalone ovvero, non dipende e non influisce in alcun modo con qualsiasi richiesta passata o futura; Ciò accade perchè ogni richiesta viene gestita da un thread apposito ed isolato dagli altri. Pagina 15 di 51

16 2. Strumenti e progettazione Una volta delineate quali devono essere le funzionalità del nostro sistema, andremo ora ad elaborare una soluzione ideale per la sua realizzazione. Nel particolare andremo prima ad analizzare le modalità di comunicazione tra il client e il server, e poi illustreremo, tramite l'aiuto di opportuni diagrammi UML le classi implementate e le relazioni che intercorrono tra esse Modalità di comunicazione tra client e server La scelta della modalità con la quale il client comunica con il server è una fase molto delicata, ed alla fine la mia scelta è caduta su una comunicazione basata su richieste inviate tramite il metodo del HTTP POST e su risposte ricevute tramite l'utilizzo di semplici pagine HTTP testuali. Una volta scelto il mezzo di comunicazione, è stato necessario trovare un protocollo comune di comunicazione, ovvero, un linguaggio testuale comune tramite il quale i due attori (client e server) riescono a scambiarsi dati. La prima scelta era caduta inizialmente sull'utilizzo del linguaggio XML[5], ma questo, anche se riesce a descrivere in maniera egregia i dati e oggetti da inviare tra le due parti ed è adattabile alla nostra situazione, non è un linguaggio nato per questo tipo di comunicazioni; Infatti la serializzazione di classi ed oggetti in XML non è standardizzata, ed esistono decine di implementazioni di moduli di serializzazione degli oggetti in stringhe XML i quali mutano sensibilmente anche a seconda del linguaggio utilizzato. La nostra scelta si è quindi spostata verso l'uso di un linguaggio standard e nato per questo tipo di scopo, ovvero il JSON Un linguaggio di comunicazione universale: il JSON JSON (JavaScript Object Notation) è un linguaggio per lo scambio di dati. La forza di questo linguaggio è il suo essere Language-indipendent, ovvero può essere implementato ed utilizzato per descrivere oggetti e strutture in qualsiasi linguaggio Pagina 16 di 51

17 di programmazione rendendo JSON il linguaggio ideale per lo scambio di dati tra client e server anche se questi sono scritti in linguaggi di programmazione differenti.[6] JSON è basato su due strutture: Un insieme di coppie nome/valore. In diversi linguaggi, questo è realizzato come un oggetto, un record, uno struct, un dizionario, una tabella hash, un elenco di chiavi o un array associativo. Un elenco ordinato di valori. Nella maggior parte dei linguaggi questo si realizza con un array, un vettore, un elenco o una sequenza. Queste sono strutture di dati universali. Virtualmente tutti i linguaggi di programmazione moderni li supportano in entrambe le forme. E' sensato che un formato di dati che è interscambiabile con linguaggi di programmazione debba essere basato su queste strutture. In JSON, assumono queste forme: Un oggetto è una serie non ordinata di nomi/valori. Un oggetto inizia con { (parentesi graffa sinistra) e finisce con } (parentesi graffa destra). Ogni nome è seguito da: (due punti) e la coppia di nome/valore sono separata da, (virgola). Figura 4: Schematizzazione della rappresentazione di un oggetto nel linguaggio JSON Un array è una raccolta ordinata di valori. Un array comincia con [ (parentesi quadra sinistra) e finisce con ] (parentesi quadra destra). I valori sono separati da, (virgola). Pagina 17 di 51

18 Figura 5: Schematizzazione della rappresentazione di una array nel linguaggio JSON Un valore può essere una stringa tra virgolette, o un numero, o vero o falso o nullo, o un oggetto o un array. Queste strutture possono essere annidate. Figura 6: Schematizzazione della rappresentazione di una variabile nel linguaggio JSON Una stringa è una raccolta di zero o più caratteri Unicode, tra virgolette; per le sequenze di escape utilizza la barra rovesciata. Un singolo carattere è rappresentato come una stringa di caratteri di lunghezza uno. Una stringa è molto simile ad una stringa C o Java. Pagina 18 di 51

19 Figura 7: Schematizzazione della rappresentazione di una stringa nel linguaggio JSON Un numero è molto simile ad un numero C o Java, a parte il fatto che i formati ottali e esadecimali non sono utilizzati. Figura 8: Schematizzazione della rappresentazione di una variabile numerica nel linguaggio JSON I caratteri di spaziatura possono essere inseriti in mezzo a qualsiasi coppia di token Cifratura della comunicazione Essendo JSON un linguaggio di comunicazione leggibile e facilmente alterabile e Pagina 19 di 51

20 non avendo la possibilità di utilizzare una connessione HTTPS in questa fase dell'implementazione, per rendere la comunicazione un po' più sicura, ho deciso di cifrare le stringhe di comunicazione scritte in JSON tramite l'algoritmo AES a 128bit. AES (Advanced Encryption Standard) è un algoritmo per la cifratura di dati e basato sull'algoritmo Rijndael. AES fornisce una crittografia simmetrica, ovvero, una tipologia di crittografia caratterizzata dall'uso di una singola chiave precondivisa per entrambe le fasi di criptazione e decriptazione del dato.[7] Attualmente AES fornisce tre livelli di complessità di cifratura: a 128, 192 e 256bit, nel nostro caso, per rendere la comunicazione più rapida e non rallentata da una cifratura troppo complessa, abbiamo deciso di utilizzare la versione a 128bit; Questa scelta è data anche dal fatto che,la cifratura delle stringhe JSON rappresenta esclusivamente un palliativo momentaneo e comunque non definitivo dato che, quando l'applicazione GaaS entrerà nella fase di produzione, essa verrà eseguita su un motore Tomcat con un certificato abilitato alla creazione di connessioni sicure HTTPS e quindi molto più sicuro della soluzione adottata in questa fase di progettazione/implementazione. Figura 9: Funzionamento di un sistema di cifratura a singola chiave Pagina 20 di 51

21 2.2. Diagramma delle classi Di seguito riporto i principali class diagram per l'applicazione client e per la Java servlet con relativa spiegazione delle classi rappresentate e del loro ruolo all'interno del sistema Lato client Pagina 21 di 51

22 Come si può notare dalle immagini, le classi sono state pacchettizzate a seconda della loro area di competenza. Abbiamo dunque il pacchetto com.bizzarro.gaas.communication che è il pacchetto contenente le classi che si occupano di fornire uno standard comune per la comunicazione tra client e server, e in particolare troviamo: Request: E' una classe di tipo entity le cui istanze memorizzano le Pagina 22 di 51

23 informazioni riguardanti le richieste effettuate dal client verso il server. Response: E' una classe di tipo entity le cui istanze contengono le risposte date dal server a precedenti Request del client. Site: E' una classe entity le' cui istanze contengono le informazioni relative ai siti Grid. Element: è una classe entity astratta le cui estensioni sono WorkerNode, SiteBDII, StorageElement e ComputeElement le cui istanze contengono le informazioni relative ai nodi WN, SB, SE e CE di un sito Flavor: anch'essa è una classe entity le cui istanze contengono informazioni riguardanti i possibili flavors utilizzabili sulla piattaforma OpenStack. Cypher: E' una classe compute che offre dei semplici metodi per cifrare e decifrare stringhe tramite l'algoritmo AES a 128bit e che viene utilizzata per cifrare le comunicazioni tra client e server che altrimenti sarebbero facilmente leggibili ed interpretabili. Le classi contenute nel pacchetto com.bizzarro.auth si occupano dell'autenticazione degli utenti all'interno del sistema. Attualmente contiene un unica classe Certificate che tramite i suoi metodi, offre una gestione dei certificati X509 molto facile ed efficiente dando la possibilità, in pochi comandi, di accedere alle informazioni contenute nei certificati di questo tipo. Nel package com.bizzarro.android ci sono le classi ideate esclusivamente per il mondo android e contiene e contiene: HTTPRequester: Questa classe di tipo compute si occupa di effettuare Pagina 23 di 51

24 richieste HTTP verso la rete. ServerRequester: HTTPRequester, Grazie questa all'utilizzo classe di di tipo un'istanza della classe compute offre metodi preconfezionati che danno la possibilità di inviare richieste complesse al server. DirectoryScanner: Come suggerisce il nome, questa classe si occupa di dare informazioni sui files contenuti in una determinata directory. Il pacchetto in analisi contiene infine un sotto-pacchetto denominato activity, contenente classi compute estensioni della classe standard Android Activity che si occupano della gestione di tutti i componenti grafici e in generale di tutte le interazioni che l'applicazione può avere con l'utente. Infine c'è il pacchetto standard Android android.widget contenente le classi rappresentanti i componenti grafici utilizzabili dall'utente (es. tasti, finestre, menu a tendina, campi di testo...ecc). Pagina 24 di 51

25 Lato server Come è possibile notare anche in questa situazione, sono molte le classi condivise con l'applicazione mobile, ed in particolare tutte le classi appartenenti ai pacchetti com.bizzarro.gaas.communication e com.bizzarro.gaas.auth, che rendono possibile la comunicazione e l'autenticazione tra i due. Le classi differenti sono tutte quelle poste nel sotto-package servlet e che comprende: MainClass: classe estensione di HttpSrvlet e contenente il metodo processrequest, ovvero il metodo invocato dalla servlet quando riceve una richiesta HTTP. Questa classe rappresenta quindi la classe principale della servlet che si occupa materialmente di prendere la richiesta e farla elaborare e spedire l'output. Pagina 25 di 51

26 DBManager: questa classe è il cuore della nostra servlet; Questa infatti contiene tutti i metodi per leggere e scrivere (sia in modo diretto che indiretto), i dati dal database MySQL. Se opportuno, invoca (non direttamente) gli script per l'esecuzione di operazioni sulla piattaforma OpenStack. Script: Questa classe è stata ideata con l'unico scopo di mascherare all'utilizzatore, l'esistenza di scripts esterni all'ambiente Java. Infatti la classe Script con i suoi metodi vuole essere semplicemente una interfaccia Java per l'utilizzo degli script bash e python che si occupano di effettuare le operazioni suoi server OpenStack Pagina 26 di 51

27 2.3. Diagrammi di sequenza Un ulteriore strumento utile alla progettazione del nostro sistema sono i diagrammi di sequenza degli oggetti di quest'ultimo. I "Sequence Diagram" hanno il compito di evidenziare l aspetto temporale dell interazione fra gli oggetti illustrando i messaggi che i vari oggetti si scambiano, e in quale ordine essi lo fanno Lato client Creazione sito Pagina 27 di 51

28 Eliminazione sito Comunicazione con il server Pagina 28 di 51

29 Creazione di un nuovo elemento Pagina 29 di 51

30 Riavvio elemento Spegnimento elemento Pagina 30 di 51

31 Eliminazione elemento Connessione ad elemento Pagina 31 di 51

32 Login Pagina 32 di 51

33 Lato server In questo paragrafo, infine, mostriamo un semplice sequence diagram che mostra il modus operandi della servlet quando riceve una generica richiesta dal client. Pagina 33 di 51

34 2.4. Il database MySQL Come detto nei paragrafi precedenti, il sistema andrà a memorizzare le informazioni riguardanti gli utenti e i siti grid all'interno di un database SQL denominato GaaSDB. In questo paragrafo spiegheremo nel dettaglio la struttura del database da realizzare, soffermandoci sulle singole tabelle e sul loro ruolo all'interno del sistema Tabella USERS La tabella USERS è la tabella cardine per tutte quelle operazioni che prevedono l'identificazione e la profilatura dell'utente Essa contiene le informazioni ricavate dal certificato X509 presentato dall'utente al momento della registrazione più altre informazioni che ora andremo a vedere nel dettaglio: I campi di questa tabella sono 9 e sono: PUBLICKEY: La chiave pubblica dell'utente (che identifica in modo univoco il certificato e di conseguenza l'utente proprietario). CN (Common Name):il nome dell'utente così come registrato sul certificato. C (Country): il paese di appartenenza dell'utente. E ( ): l'indirizzo dell'utente. L (Locate): La località di provenienza dell'utente O (Organization): L'organizzazione (es. azienda, istituto...ecc) appartenenza dell'utente. ST (State): Lo stato di provenienza dell'utente. Pagina 34 di 51 di

35 TYPE: Questo campo è fondamentale per la profilatura dell'utente; infatti questa variabile indica al sistema se l'utente in questione è un utente normale oppure un amministratore. APPROVED: Questa variabile avverte il sistema se all'utente in questione è già stato concesso l'uso dell'infrastruttura GaaS. Come già spiegato in precedenza, per diventare utente del sistema bisogna inviare a quest'ultimo le proprie credenziali tramite l'uso del il proprio certificato X509. Queste informazioni passeranno poi al vaglia di un amministratore che deciderà se approvare o meno l'accesso al sistema da parte di quel preciso utente Tabella SITI La tabella SITI contiene le informazioni relative a tutti i siti Grid istanziati sul sistema. Questa tabella è composta da 8 campi che sono: ID: L'identificativo univoco del sito. NOME: Il nome del sito dato dall'utente al momento della sua creazione. USER: La public key dell'utente creatore del sito (fa riferimento al campo PUBLICKEY della tabella USERS). INFO: Contiene informazioni aggiuntive inserite dall'utente al momento della creazione del sito. MAX_WN: Numero massimo di Worker Node inseribili all'interno del sito in questione. USED_WN: Numero di Worker Node attualmente presenti all'interno del sito. Pagina 35 di 51

36 CE: Indica il nome del CE del sito in questione (fa riferimento al campo NOME della tabella ELEMENTI). STATO: Questa variabile può assumere due valori UP o DOWN a seconda che il sito sia completamente configurato e operativo o meno Tabella ELEMENTI La tabella ELEMENTI contiene invece le informazioni riguardanti i nodi costituenti i siti Grid presenti nel sistema. La tabella è composta da 9 elementi che sono: ID: identificativo univoco del nodo (corrisponde all'identificativo presente sulla piattaforma Openstack). NOME: il nome dell'elemento (fa riferimento al campo NOME della tabella IP) USER: La public key dell'utente che ha creato il nodo (fa riferimento al campo PUBLICKEY della tabella USERS). SITO: L'identificativo del sito che contiene il nodo in questione (fa riferimento al campo ID della tabella SITI). TIPO: Indica la tipologia del nodo in questione. Esso infatti può essere di 4 tipi: Compute Element (CE), Site BDII (SB), Worker Node (WN) o Storage Element (SE). Pagina 36 di 51

37 IP_PUBBLICO: Se disponibile per il nodo in questione, questo campo contiene l'ip pubblico tramite il quale è possibile avere un accesso diretto all'elemento (fa riferimento al campo IP della tabella IP). IP_PRIVATO: Se disponibile per il nodo in questione, questo campo contiene il suo IP privato. STATO: Contiene l'identificativo dello stato in cui si trova nodo in questione (ricavato dalle informazioni di Openstack). FLAVOR: Contiene l'identificativo del flavor (set di componenti hardware), del nodo (fa riferimento al campo ID della tabella FLAVOR Tabella RISORSE La tabella RISORSE contiene informazioni cruciali per quanto riguarda l'istanziazione di nuovi nodi sul sistema; infatti questa contiene le informazioni sui componenti di tipo Compute della piattaforma Openstack ed in particolare sulle risorse disponibili su di questi. Queste informazioni vengono utilizzate dal sistema per la scelta del Compute sul quale istanziare nuovi nodi. La tabella è composta da 4 campi che sono: ID: Identificativo del Compute all'interno della tabella. COMPUTE: Il nome del Compute Il numero di CPU/Core fisici attualmente disponibili sul Compute. La memoria fisica attualmente disponibile sul Compute. Pagina 37 di 51

38 Tabella RETE La tabella RETE contiene le informazioni viene utilizzata per l'assegnazioni delle classi di indirizzamento per la rete privata dei siti. I campi di questa tabella sono i seguenti: NUMERO: identificativo della riga RETE: la classe di indirizzamento /24 SITO: l'identificativo del sito a cui è stata assegnata la classe di indirizzi (fa riferimento al campo ID della tabella SITI). OCCUPATO: indica se la classe in questione è già stata assegnata o meno Tabella IP La tabella IP contiene un pool di indirizzi IP pubblici associabili ai nodi da creare. Essendo indirizzi pubblici, questi sono associati ad un certificato e le macchine ai quali verranno assegnati avranno gli stessi nomi indicati sul certificato. Pagina 38 di 51

39 La tabella è composta da 4 elementi che sono: IP: indirizzo IP pubblico. NOME: Il nome della macchina associata o da associare. OCCUPATO: Indica se l'indirizzo è attualmente già utilizzato da un nodo o meno. TIPO: Indica la tipologia di nodo associabile Tabella FLAVOR La tabella FLAVOR contiene le taglie hardware (numero di CPU, diimensione RAM e disco) utilizzabili per la realizzazione dei nodi. I campi di questa tabella sono: ID: Identificativo del flavor NOME: Nome del flavor. MEMORIA: Dimensione della memoria RAM. CPU: Numero di CPU/Cores utilizzabili. DISCO: Dimensione della memoria di massa. Pagina 39 di 51

40 Tabella ESECUZIONI L'esecuzioni di molte funzionalità richiedono un accesso esclusivo a determinate risorse. Per far ciò, è stata creata questa particolare tabella che registra lo stato delle operazioni ad accesso esclusivo, in modo da creare una specie di semaforo verso quelle risorse che prevedono per alcuni motivi un accesso di tipo concorrenziale. La tabella è costituita dalle segueti colonne: ID: Identificativo dell'esecuzione. SITO: Identificativo del sito sul quale sta avvenendo l'esecuzione (fa riferimento al campo ID della tabella SITO). USER: Public key dell'utente che ha richiesto l'esecuzione (fa riferimento al campo PUBLICKEY della tabella USERS). TIPO: Indica a quale funzione si sta facendo riferimento (es. CREATE SITE, CREATE WN). DATA: Indica la data di inizio dell'esecuzione. STATO: Riporta lo stato dell'esecuzione (es. DONE, EXECUTING, WAITING) Pagina 40 di 51

41 Diagramma EER Nel diagramma EER sottostante possiamo osservare quali sono le interazioni tra le tabelle del database SQL denominato gaasdb. Pagina 41 di 51