D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS

Transcript

1 D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS Il modello SaaS Architettura 3D Cloud Il protocollo DCV Benefici Il portale Web EnginFrame EnginFrame plugin Plugin piacloud Il modello SaaS Il modello SaaS è identificato anche come un modello di software on demand distribuito come servizio in hosting: si tratta di un modello di cloud in cui all utente viene messo a disposizione direttamente un ambiente completo con l applicazione da utilizzare, sollevandolo dalla responsabilità e dall onere dell installazione dell applicazione, della sua configurazione, e della configurazione del sistema host che eseguirà l applicazione. L accesso alle applicazioni SaaS può avvenire con un thin client. L utilità di questo tipo di client risiede nel fatto che la potenza di calcolo non dovrà essere una prerogativa del client che accede alla cloud, in quanto tutti i calcoli, le elaborazioni in generale e lo storage dei risultati avverrà sulla cloud stessa. Il thin client potrebbe essere addirittura un semplice network computer, senza disco rigido, con connettività di rete e che si limita a fungere da interfaccia tra l utente e la cloud per inserire i dati, le richieste di elaborazione, e presentare i risultati all utente. Architettura 3D Cloud Nell architettura 3D Cloud progettata, un unica macchina si occupa dell elaborazione grafica, essa è denominata rendering server. Questa macchina è in grado elaborare le richieste della varie applicazioni sfruttando la scheda grafica locale e inviando i pixel elaborati ai display remoti, i suddetti thin client o endstation, che possono essere molteplici.

2 Le endstation sono connesse al server grafico attraverso una rete standard e renderizzano l output del server in modo efficiente rispetto alle specifiche e alle performance della rete. Il numero di endstation è dinamico, con client in grado di connettersi e disconnettersi dal server in qualsiasi momento. Il protocollo utilizzato per implementare l archettura 3D è il protocollo DCV, che funziona sia su piattaforma Windows che su Linux, sfruttando le capacità di calcolo di schede grafiche NVIDIA di fascia alta e che supporta la condivisione di una stessa GPU verso una molteplicità di utenti e sistemi operativi differenti. Esso non richiede cambiamenti nell applicazione 3D e quindi può essere utilizzato in maniera trasparente da qualsiasi applicazione esistente. Il protocollo è integrato attraverso il portale EnginFrame che permette la gestione delle connessioni remote 3D (sessioni interattive). Il protocollo DCV Le principali caratteristiche del protocollo sono: Solo le immagini finali renderizzate vengono trasmesse al client (e quindi nessuna geometria o informazione di scena è trasmessa). Questo caratteristica è in grado di fornire un isolamento e una protezione delle informazioni dell utente. Si adatta automaticamente a infrastrutture di rete eterogenee, quali LAN, WAN e VPN, per far fronte a vincoli di larghezza di banda e di latenza. Gli utenti finali possono specificare il livello di compressione utilizzato per spedire le immagini finali verso il client in modo tale da bilanciare la qualità rispetto al frame rate e avere così un interattività ottimale con l applicazione. Gli algoritmi di compressione/decompressione delle immagini (codec) possono essere selezionati a seconda delle esigenze (di default i codec JPEG e ZRLE sono quelli utilizzati). Supporta gli aggiornamenti dell immagine ad alta qualità quando la rete e condizioni del processore grafico lo consentono. Solo gli utenti autorizzati possono connettersi al server e le credenziali vengono trasmesse attraverso un canale criptato (128 bit AES per la parte 2D e 128/256 bit AES per la parte 3D). Benefici I benefici lato business di questo tipo di architettura possono essere suddivisi in 4 categorie: Produttività Aumento della produttività dell utente su applicazioni pesanti e datasets molto grandi. Accesso alle risorse centralizzate attraverso un protocollo di remotizzazione. Maggiore produttività grazie alla collaborazione real time. Continuità Protezione degli utenti e i dati dai guasti delle workstations. Scaling e dimensionamento delle risorse di visualizzazione su richiesta, per soddisfare le diverse esigenze.

3 Possibilità per gli utenti di lavorare ovunque, attraverso standard e sicure connessioni TCP/IP. Sicurezza Accesso sicuro alle risorse centralizzate. Condivisione dei pixels e non dei dati. Collaborazione con i partners di lavoro proteggendo al tempo stesso la proprietà intellettuale. Gestione e Risparmio Spostamento degli investimenti sui miglioramente della rete. Riduzione dei costi dell IT consolidando le workstations come risorse centralizzate. Estensione del tempo di vita delle workstations esistenti. Risparmio di tempo sull installazione delle applicazioni e sugli aggiornamenti. Il portale Web EnginFrame EnginFrame è un portale avanzato per il calcolo tecnico scientifico che consente l'accesso e la gestione a risorse HPC, Grid e Cloud in maniera immediata ed efficiente. Infrastrutture, dati, licenze, applicazioni batch e interattive possono essere rese accessibili a qualsiasi client utilizzando un browser standard. EnginFrame è basato su tecnologie quali Java, XML e Web Services, e rende facile e intuitvo il deployment di applicazione e di portali data oriented. EnginFrame viene installato e utilizzato con successo in vari settori industriali come quello Petrolifero, Energetico, Automotive, Aerospaziale e Difesa, Medicale, e Finanziario. EnginFrame permette agli utenti di poter eseguire i loro job più velocemente, senza doversi preoccupare della complessità dell'infrastruttura di calcolo sottostante. Gli utenti possono interagire con un interfaccia grafica intuitiva e orientata alla gestione dei servizi del cluster. E sufficiente un semplice browser web per poter accedere ai propri dati, alle licenze, ai processi batch e alle applicazioni interattive. EnginFrame, fornisce funzionalità avanzate di gestione dei dati e una grande flessibilità nella definizione dei servizi, permettendo ad una infrastruttura standard di evolvere in una infrastruttura self service Cloud pubblica o privata. EnginFrame può essere facilmente utilizzato come frontend di uno o più cluster. Il portale fornisce una libreria di template di applicazioni predefiniti tali da rendere gli utenti immediatamente produttivi. Può essere facilmente esteso per ospitare nuove applicazioni o workflow più complessi, il tutto senza la necessità di avere competenze relative alle tecnologie Web o su altri linguaggi di programmazione. Attraverso i principali Scheduler sul mercato, EnginFrame traduce i click degli utenti in azioni opportune come: sottomissione di job, monitoraggio di dati e gestione dei file di input e output.

4 EnginFrame plugin 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 uno dato scopo, possa essere incluso nel portale web ed accessibile quindi agli utenti con gli adeguati permessi. Nella figura seguente è possibile visualizzare la struttura di un generico plugin, struttura che andremo a realizzare per questo progetto, per un nuovo plugin denominato piacloud. Figura 1. Struttura EnginFrame plugin Plugin piacloud Nel plugin andremo ad inserire i servizi definiti tramite linguaggio XML, gli script, il css e tutti i file necessari a fornire un accesso Web alle applicazioni 3D, ovvero fornire un Software As A Service. L utente finale e i suoi collaboratori saranno in grado di accedere alle applicazioni tramite dei servizi WEB sviluppati e accessibili dal portale EnginFrame, secondo lo schema seguente.

5 Figura 2. Architettura 3D Cloud Tutti i servizi web verranno realizzati a partire da una definizione XML del servizio stesso, seguendo le convenzioni e la sintassi standard per costruire un servizio web all interno del portale NICE EnginFrame, ricavabili dall EnginFrame Admin Guide. Il servizio viene definito in un tag ef:service. Ogni servizio EnginFrame possiede una ef:action, che identifica quale script deve essere eseguito da EnginFrame ogni volta che il servizio viene richiamato. Ad ogni action sono correlate anche una serie di ef:option che vanno a rappresentare i parametri necessari all esecuzione dello script. Questi possono essere parametri definibili dall utente in fase di sottomissione o parametri configurabili in un opportuno file di configurazione. Infine vi è il tag ef:info che rappresenta codice in formato HTML da visualizzare nella pagina o nel form di sottomissione del servizio, che può includere anche codice JavaScript o jquery. Riportiamo un esempio di definizione di un generico servizio in EnginFrame. <ef:service id="idservizio"> <ef:name>nome del servizio</ef:name> <ef:info> Eventuali informazioni o codice HTML da visualizzare </ef:info> <ef:option id="idparametro" label="etichetta parametro" class="classe css" type="tipo del parametro"> Valore di default del parametro </ef:option> <ef:action id="idazione" label="etichetta azione" result="tipo di risultato (es: text/xml)" >

6 "${EF_ROOT}/plugins/cloudpills/bin/idAzioneScript.sh" </ef:action> </ef:service> Verranno quindi realizzati dei servizi Web appositi per il progetto, seguendo le convenzioni e la sintassi standard per costruire un servizio web all interno del portale NICE EnginFrame, andando ad interfacciarsi nei modi opportuni con il MiddleWare e con il software di visualizzazione remota.