D1.3 Documento contenente le specifiche tecniche e funzionali di massima delle componenti architetturali

Transcript

1 D1.3 Documento contenente le specifiche tecniche e funzionali di massima delle componenti architetturali Obiettivo: L'obiettivo del progetto è quello di realizzare un interfaccia accessibile via web, che permetta agli utenti l'utilizzo di applicazioni 3D in un ambiente di Cloud Computing e quindi la fruizione di risorse condivise hardware e software trasparente all'utente stesso. Un caso d'uso semplice è quello nel quale un generico utente deve poter selezionare un'applicazione 3D e i dati da eseguire o visualizzare (che possono essere frutto di un calcolo precedente o meno) nell'applicazione stessa. Tale applicazione e i dati necessari all'utente devono essere resi disponibili per l'utilizzo remoto, su macchine virtuali che mantengano isolate le sessioni di utenti diversi, ma allo stesso tempo ne permettano la condivisione su richiesta. Componenti dell'architettura: Come da Studio di fattibilità la scelta dell'architettura parte da alcune componenti fondamentali: Hardware; Middleware Open Source; Portale Enginframe; Visualizzatore remoto 3D; modello metereologico. L' Hardware (macchine fisiche, schede video, macchine virtuali) viene fornito dal gruppo Reti e Sistemi di Calcolo ad Alte Prestazioni del CRS4. Diversi Settori di Ricerca del CRS4 utilizzano in condivisione lo stesso hardware per questo motivo solo una parte di questo verrà dedicata al progetto. Le macchine verranno opportunamente configurate per garantire un accesso da parte degli utenti all'esterno e nella fase iniziale verrà garantito l'accesso a tutto il team di sviluppo del progetto stesso. E' da sottolineare l'importanza di una gestione adeguata del firewall, sulla base delle macchine virtuali attive, e delle applicazioni che si intendono utilizzare e allo stesso tempo una adeguata gestione del carico computazionale sulle diverse risorse fisiche, in accordo con le politiche interne di suddivisione delle macchine di calcolo del CRS4. Il CRS4 dispone di un parco macchine ad alte prestazioni, composto in totale da 400 nodi dual cpu quadcore, per un totale di 3200 unità di calcolo. Tali macchine verranno gestite totalmente dal gruppo Reti e Sistemi di Calcolo ad Alte Prestazioni e sarà quindi un loro compito fornire un sottoinsieme di queste risorse adeguato alle esigenze del progetto. L'hardware fisico verrà reso trasparente tramite il Middleware Open Source garantendo così il pieno controllo delle macchine di calcolo e di tutto l'hardware a disposizione del CRS4 e allo stesso tempo poter garantire un accesso adeguato alle esigenze del progetto. Da questo si deduce che è importante un protocollo di comunicazione adeguato tra interfaccia utente, che conosce il carico richiesto al sistema e le applicazioni utente, e il Middleware Open Source che andrà a posizionarsi sopra lo strato hardware vero e proprio, gestendone l'accesso e la distribuzione del carico. Il Middleware Open Source è una componente software che verrà sviluppata principalmente dal CRS4, in stretta collaborazione con il team NICE, esso si occuperà principalmente di occultare il comportamento del sistema sottostante, inteso come insieme di hardware vero e proprio, schedulatori interni al CRS4 e gestore di macchine virtuali e fornire una serie di caratteristiche allo strato software più vicino all'utente. Dopo un'opportuna analisi comparativa tra i vari middleware Cloud Open Source, il gestore di macchine virtuali selezionato dal CRS4 è stato Open Stack. Open Stack è un software Open Source capace di gestire e costruire

2 una piattaforma per il Cloud Computing, tramite interfaccia grafica o tramite API (Application Programming Interface). Open Stack fornisce una serie di caratteristiche molto interessanti ma solo alcune di queste sono necessarie al progetto. Il compito del Middleware realizzato dal CRS4 sarà quello di realizzare un'astrazione delle API del software Open Stack sottostante fornendo solamente il subset di operazioni necessarie alla realizzazione dell'architettura. Sarà compito del CRS4 studiare Open Stack, le sue caratteristiche e le sue API in modo tale da valutare quali di queste caratteristiche possano essere necessarie ed importanti per la realizzazione del progetto e astraendole opportunamente sarà quindi possibile realizzare una comunicazione adeguata tra livello utente e livello hardware sottostante. Il Middleware realizzato dal CRS4 avrà quindi due compiti: astrarre le funzionalità di Open Stack e allo stesso tempo gestire ed occultare le caratteristiche dell'harware vero e proprio sottostante. Una rappresentazione schematica può essere visualizzata nella Figura 1. Figura 1. Middleware Open Source. Il portale NICE EnginFrame verrà utilizzato come front end per gli utenti. Con EnginFrame è possibile creare portali Web per la sottomissione, il controllo ed il monitoraggio di job in ambienti HPC e di Grid Computing. Il caso in esame è un caso differente nel quale EnginFrame non dovrà interfacciarsi semplicemente con degli schedulatori e gestire quindi dei job, ma dovrà dialogare opportunamente con un middleware appositamente realizzato e si troverà a dover creare e gestire sessioni grafiche, avviate dagli utenti per applicazioni differenti, 3D o meno. Tali sessioni grafiche verranno eseguite in macchine virtuali gestite dal Middleware realizzato dal CRS4, che si occuperà di fornire l'accesso e comunicare opportunamente con Open Stack per creare, gestire e terminare le macchine virtuali sul quale verranno eseguite le applicazioni. EnginFrame ha una struttura che possiamo definire "a plugin", ovvero possiede un kernel con delle funzionalità base comuni al campo di applicazione di EnginFrame e tale componente può essere estesa con dei plugin ad hoc, sviluppati appositamente per le diverse esigenze. Per EnginFrame Plugin si intende una porzione di codice sviluppata nel linguaggio più opportuno che viene eseguita o in qualche modo interagisce con il portale per estendere le sue funzionalità di base. Per il progetto in questione se necessario EnginFrame verrà esteso con un opportuno Plugin, che fornirà le operazioni non incluse nel kernel. Il Visualizzatore Remoto 3D selezionato è NICE Desktop Cloud Visualization. Come descritto nello Studio di fattibilità vi è stata una fase di analisi dei diversi applicativi per la visualizzazione remota 3D, come RGS di HP, il pacchetto Open Source VirtualGL e il software DCV. Il software DCV è stato recentemente acquistato dalla NICE ed esiste attualmente all'interno della NICE stessa un settore Ricerca e Sviluppo che si occupa dello sviluppo su questo prodotto.

3 Questo motivo, unito agli altri elencati nel documento di analisi dei Visualizzatori Remoti 3D è uno dei motivi chiave per il quale questo software è stato scelto come Visualizzatore Remoto per il progetto. Il software NICE DCV è in grado di intercettare le chiamate OpenGL 3D degli applicativi e di inviarle direttamente in rete, garantendo prestazioni estremamente elevate. Per funzionare correttamente e con prestazioni soddisfacenti è necessario utilizzare una scheda video ad elevate performance (della serie NVIDIA Quadro o superiori). Tale scheda video dovrà essere opportunamente collegata ad una macchina fisica che verrà messa a disposizione dal gruppo del CRS4. Il Software NICE DCV dovrà essere installato in tutte le macchine virtuali nel quale vuole essere eseguita un'applicazione grafica 3D e nella macchina fisica effettivamente collegata alla scheda grafica. Da questo si deduce che sarà necessario creare delle ISO (Immagini disco) opportunamente configurate nel quale dovrà essere inserito anche il software NICE DCV. Verranno create delle ISO differenti a seconda del tipo di applicazione da eseguire (es: Google Earth, Paraview..) e a seconda del tipo di Sistema Operativo richiesto (Windows, Linux). Tali ISO verranno poi opportunamente istanziate nelle macchine virtuali grazie ad Open Stack e al Middleware realizzato dal CRS4. In tutte queste immagini disco dovrà comunque esserci il software di visualizzazione remota NICE DCV. Il Modello Metereologico da utilizzare per le simulazioni verrà fornito dal gruppo Energia e Ambiente del CRS4. La simulazione potrebbe consistere in una fase di calcolo e quindi una produzione di dati che verrebbero poi visualizzati tramite applicazioni 3D come Paraview o Google Earth. E' importante studiare un'opportuna gestione dei dati all'interno dell'architettura, per garantire un isolamento dei dati tra utenti differenti, una possibile condivisione tra utenti tramite condivisione della sessione grafica e un accesso uniforme ai dati, sia che essi vengano creati durante una simulazione effettuata nella Cloud stessa, sia che i dati provengano da un altro storage opportunamente connesso alla Cloud. Le applicazioni 3D da utilizzare verranno selezionate dal gruppo Energia e Ambiente del CRS4 in conformità con il Modello Metereologico da utilizzare. Le applicazioni verranno inserite anch'esse nelle immagini disco pre confezionate con il software NICE DCV e verranno istanziate e rese accessibili in seguito ad un opportuna fase di scambio dati tra Portale e Middleware. La progettazione dell'architettura intesa come schema di collegamento tra portale, middleware e hardware sottostante non dipende dal tipo di applicazione che si andrà ad utilizzare, in quanto l'unico elemento strettamente correlato all'applicazione è la macchina virtuale nel quale essa andrà eseguita, ma tale macchina potrà essere dimensionata in una fase successiva alla progettazione dell'architettura. Progettazione dell'architettura: Una serie di incontri tecnici tra NICE e CRS4 hanno portato alla definizione di un'architettura visualizzabile nella Figura 2. Proponiamo di seguito una descrizione dettagliata di tutti i moduli costituenti l'architettura.

4 Figura 2. Architettura completa. Il punto di partenza è l' Utente (Amministratore o utente finale). Tramite il portale di accesso EnginFrame, l'utente potrà connettersi all'architettura e se amministratore potrà gestire le sessioni grafiche attive e effettuare opportune configurazioni al sistema. Un utente amministratore dovrà poter accedere anche a tutte le macchine virtuali interne, per installare o rimuovere programmi, effettuare configurazioni di rete e dovrà poter accedere al pannello di amministrazione di Open Stack per gestire, se necessario, l'insieme di vm istanziate automaticamente dal sistema. Un utente non amministratore non avrà nessuna conoscenza dell'architettura. Esso dovrà semplicemente loggarsi al portale via web e, senza conoscere nessun dettaglio architetturale, poter avviare le applicazioni 3D a lui necessarie. EnginFrame verrà utilizzato come front end. Entrambe le tipologie di utenti (amministratore e non) potranno connettersi al portale e grazie ad un'opportuna configurazione delle ACL (Access Control List) gli utenti potranno essere filtrati e avranno quindi la possibilità di accedere a servizi differenti. EnginFrame, utilizzato per gestire portali Grid e HPC è in grado di dialogare con gli schedulatori più comuni (Platform LSF, OpenLava, Sun Grid Engine) e per sua natura è in grado fornire un'astrazione delle macchine gestite dagli schedulatori e gestire i job e le sessioni avviate su ogni macchina. Verrà sfruttata questa caratteristica chiave di EnginFrame nell'architettura, dando modo a EnginFrame stesso di dialogare direttamente con degli opportuni schedulatori. Vi sarà uno schedulatore Windows per gestire l'attivazione, la rimozione e tutto ciò che concerne un'applicazione in una macchina virtuale Windows e uno schedulatore Linux (OpenLava, SGE, LSF) per gestire i job o sessioni sulle macchine virtuali Linux. Il portale EnginFrame, è strutturato secondo un modello a plugin. Per plugin si intende una struttura a cartelle che, opportunamente posizionata nelle cartelle di installazione del portale, fa in modo che i file XML, XSL, script bash, CSS e tutto ciò che serve per un preciso scopo, possa essere incluso nel portale web ed accessibile quindi agli utenti con gli adeguati permessi. Vi sarà quindi un plugin per la gestione di ogni differente schedulatore, ed un ulteriore plugin per la gestione dell Orchestrator, che descriveremo più avanti. Lo Scheduler (o Schedulatore) è lo strato software che si occuperà di gestire la distribuzione e schedulazione dei job o delle sessioni grafiche nelle macchine virtuali disponibili. Lo Scheduler potrà essere differente per le macchine virtuali Windows e Linux.

5 Lato linux esistono molte possibili alternative, quali OpenLava, Sun Grid Engine, Platform LSF, Moab, mentre su windows le possibilità di scelta sono minori e durante le fasi successive del progetto si valuterà se utilizzare Platform LSF o utilizzare uno schedulatore Windows sviluppato internamente in NICE. Sarà necessario selezionare ed utilizzare un meccanismo di autenticazione condiviso, che permetta una gestione centralizzata degli utenti, amministratori o no, e le policy di accesso per i diversi componenti del sistema (EnginFrame, Storage, Schedulatori, macchine virtuali). La soluzione architetturale riportata dovrà permettere una gestione condivisa dei dati tra le varie risorse. Ogni utente avrà accesso solo ai dati personali in qualunque macchina virtuale, semplicemente effettuando il login con opportuno utente e password. Una serie di incontri tecnici e raffinazioni successive hanno portato all'ideazione di un oggetto fondamentale nell'architettura, di seguito denominato Orchestrator. Esso è costituito da due blocchi principali: il blocco denominato MW (il MiddleWare vero e proprio realizzato dal CRS4) e una libreria client (MW Client Lib) da utilizzare per le comunicazioni con il portale EnginFrame. Il compito del MiddleWare sarà quello di comunicare con le componenti sottostanti (SGE Sun Grid Engine, lo schedulatore interno al CRS4 e le macchine fisiche) e di astrarne il comportamento. Si occuperà di istanziare e rimuovere macchine virtuali sulla base delle risorse virtuali disponibili e quelle occupate dalle applicazioni utente. Il Middleware andrà a comunicare con OpenStack tramite API, sulla base delle richieste effettuate dagli utenti e delle risorse disponibili nel sistema. Sarà compito del gruppo Reti e Sistemi di Calcolo ad Alte Prestazioni del CRS4 realizzare questo modulo, partendo da una condivisione di obiettivi, una selezione di opportuni protocolli di comunicazione e sulla base dei requisiti del sistema. Il Middleware dovrà occuparsi di comunicare con gli schedulatori, per richiedere l'avvio o la terminazione di una macchina virtuale. Nello schema è possibile visualizzare, all interno delle cluod, un insieme di macchine virtuali. Queste macchine virtuali saranno gli oggetti nei quali verranno eseguiti i task veri e propri e nei quali verranno eseguite le applicazioni 3D. Dovrà quindi esserci installato un componente software noto come Agent degli schedulatori, che permetterà allo schedulatore di istanziare, eseguire o terminare le applicazioni all'interno delle vm e permetterà quindi una gestione (utente amministratore) e una visualizzazione (utente finale) di ciò che accade all'interno delle macchine virtuali tramite l'interfaccia web del portale EnginFrame. Nello schema viene riportato un ulteriore modulo, opzionale, denominato Config, che va a rappresentare un possibile database o più semplicemente un file di configurazione, che potrebbe contenere una serie di configurazioni architetturali accessibili ai diversi moduli dell architettura stessa, si valuterà durante le fasi successive di sviluppo la necessità o meno di questo componente. La struttura dell architettura e le caratteristiche dei singoli moduli, qui illustrate, sono soggette ad eventuali cambiamenti e successive revisioni sulla base delle effettive fasi di sviluppo del progetto stesso.