Che materia stai cercando?

Tesi Marco Zennaro

Tesi sull'Effettuare il processo di rendering di un progetto di computer grafica 3D in remoto attraverso la creazione di macchine virtuali usate come render farm risparmiando risorse. Università degli Studi di Catania - Unict, Facoltà di Scienze matematiche fisiche e naturali. Scarica il file in PDF!

Materia di Computer Graphics relatore Prof. G. Gallo

Anteprima

ESTRATTO DOCUMENTO

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

europeo CHAIN-REDS [55], coordinato dall’INFN, che della Federated Cloud [56]

della European Grid Infrastructure [57], di cui l’INFN è uno dei membri.

Dopo avere avuto accesso alle dashboard di controllo delle due infrastrutture, ho

definito e creato personalmente il profilo della macchina virtuale, basata su Linux

CentOS, e operato tutte le configurazioni (nel gergo, contestualizzazioni) necessarie per

la creazione del relativo template e l’installazione automatica, di Blender e di tutte le

librerie necessarie al suo funzionamento, nonchè ovviamente dell’opportuno

compilatore.

Per completezza d’informazione, a titolo di esempio ed a beneficio di chi eventualmente

volesse avere a disposizione un rapido ma efficace primer, l’ Appendice 1 contiene il

dettaglio di tutte le operazioni che ho compiuto sull’infrastruttura Cloud basata su

OpenNebula.   Piattaforme  Cloud   43  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

    Piattaforme  Cloud   44  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

5. Science Gateway

Quando parliamo di Science Gateway, esattamente, a cosa ci riferiamo?

Cerchiamo di capire cos’è uno Science Gateway.

Riportiamo subito la definizione più comunemente accettata, creata per la prima volta

nell’ambito dei progetto Teragrid [58] e XSEDE [59], e ne approfondiamo di seguito il

suo significato:

“A Science Gateway is a community-developed set of tools, applications, and data that

is integrated via a portal or a suite of applications, usually in a graphical user

interface, that is further customized to meet the needs of a specific community.”  

Teragrid/XSEDE

Uno Science Gateway è dunque un insieme di set di strumenti, applicazioni e dati che è

integrato attraverso un portale web di nuova generazione o una suite di applicazioni

desktop, di solito in una interfaccia utente grafica di ultima generazione, che è

ulteriormente personalizzata per soddisfare le esigenze di una specifica comunità di

scienziati e ricercatori.   Science  Gateway   45  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

5.1. Un pò di storia: perchè nascono gli Science Gateway?

 

Negli ultimi 30 anni, il calcolo scientifico si è costantemente evoluto e si è passati da

soluzioni basate su mainframe centralizzati sino ad arrivare ad ambienti altamente

distribuiti, quali infrastrutture Grid e Cloud (vedi fig. 5.1).

Questo è stato possibile grazie alla disponibilità di hardware COTS (Commercial Of

The Shelf) sempre più potente e meno costoso ed alla concorrente diminuzione dei

prezzi delle componenti delle reti locali (Local Area Networl - LAN) ed aumento della

banda delle connessioni di rete su scala geografica (Wide Area Network – WAN).  

Figura 5.1 - Evoluzione Del Calcolo Distribuito

     

Nella prima metà degli anni '90 si è affermato il paradigma del cosiddetto Cluster

Computing, per applicazioni HTC (High Throughput Computing), basate su algoritmi

“trivialmente paralleli”. Tale modello di calcolo si è enormemente evoluto in questi

ultimi tempi, grazie all’avvento dei processori multi-core, delle GPU (Graphic

Processing Unit), delle reti locali a bassissima latenza (Infiniband [60], Myrinet [61] ) e

dei protocolli di comunicazione quali OpenMP [62] e MPI [63] ed è diventato di uso

comune anche nel campo delle applicazioni HPC (High Performance Computing),

basate su algoritmi “altamente paralleli”, a tal punto che negli ultimi cinque anni circa

l'80% delle macchine presenti nella classifica mondiale Top500 [64] sono basate su

un'architettura distribuita.

La forte riduzione dei costi delle connessioni geografiche a banda ultra-larga, ha

favorito negli ultimi 10-15 anni la diffusione e l'adozione del paradigma del Grid

Computing [65,66] che si è evoluto e ulteriormente complicato in quello del Cloud

Computing [9].   Science  Gateway   46  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

Un ulteriore grado di complessità è rappresentato dal fatto che i modelli di calcolo sopra

indicati non sono utilizzati in modo mutuamente esclusivo. Al contrario, in molti

domini scientifici, i ricercatori sono costretti, nell’ambito delle collaborazioni di cui

fanno parte, ad un uso concomitante di più cluster, di infrastrutture Grid e di

infrastrutture Cloud tanto che sta emergendo il concetto di Jungle Computing [67] (vedi

fig. 5.2).  

Figura 5.2 - Illustrazione del "Jungle Computing"

Il problema principale in questa jungle dei componenti delle moderne e-infrastrutture è

che si basano su una varietà di middleware che sono scarsamente (se non per nulla)

interoperabili tra loro grazie alla limitatissima adozione di standard, “de jure” o “de

facto”, internazionali.

La figura 5.3 mostra a titolo di esempio i middleware (rappresentati dai loro loghi)

sviluppati nel contesto di progetti Grid e HPC finanziati dalla Commissione Europea

(acronimi cerchiati in azzurro) e da altre Agenzie governative di finanziamento presenti

in varie altre regioni del mondo (acronimi cerchiati in altri colori).  

Figura 5.3 - Middleware sviluppati nell’ambito di diversi progetti Grid e HPC nel mondo

  Science  Gateway   47  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

La situazione non è migliore nel mondo delle Cloud (vedi fig. 5.4) dove, come abbiamo

visto nel capitolo 3, esistono Cloud pubbliche, Cloud private e Cloud commerciali e

dove Cloud di calcolo (le cloud nella parte superiore della figura) e di storage (cloud

nella parte bassa della figura) sono gestite da operatori distinti e sono molto spesso non

interoperabili tra loro (l’interoperabilità è di norma incompatibile con la fidelizzazione

degli utenti, detta in gergo vendor lock in, essenziale dal punto di vista commerciale e

del successo del modello di business).  

Figura 5.4 – Cloud commerciali e cloud pubbliche, di calcolo e di storage

Ciò che emerge chiaramente da quanto esposto finora è dunque la necessitù di una

soluzione che riesca ad accedere e utilizzare questa diversità di infrastrutture hardware e

software in maniera trasparente nei confronti dell’utente finale. La risposta a questa

domanda viene fornita in maniera naturale dagli Science Gateway che possono

“nascondere” le specificità delle varie infrastrutture, rendendole nel contempo

interoperabili a livello delle applicazioni dell’utente.

Gli Science Gateway consentono infatti ad intere comunità di utenti, condividenti con

un comune obiettivo scientifico, di utilizzare le risorse digitali a loro disposizione

attraverso un'interfaccia comune, anche quando tali risorse sono distribuite

geograficamente e basate su paradigmi computazionali differenti. Le risorse digitali in

questo contesto, potrebbero essere di qualsiasi tipo, da un'applicazione parallela in

esecuzione su un supercomputer ad una analisi Hadoop [68] in esecuzione su una

Cloud commerciale ad un'istanza condivisa di Matlab in esecuzione su una workstation.

Alcuni framework per lo sviluppo di Science Gateway ed alcune implementrazioni sono

descritti nei prossimi paragrafi.   Science  Gateway   48  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

5.2. Gli Science Gateway nel mondo

 

Grazie alle potenzialità descritte nel precedente paragrafo, negli ultimi anni gli Science

Gateway hanno ricevuto un notevole interesse.

A livello europeo, la European Grid Infrastructure [57] li ha inseriti nel suo piano

strategico EGI Strategic Plan - Seeing New Horizons: EGI’s Role in 2020 [69] per i

prossimi anni ed ha sia creato lo Science Gateway Virtual Team [70] che redatto lo

Science Gateway Primer [71] che fornisce utilissime informazioni, sia per gli utenti che

per gli sviluppatori, sui framework esistenti per lo sviluppo di Science Gateway.

Negli Stati Uniti, la National Science Foumdation (NSF) ha recentemente finanziato un

progetto su “Fundamental Cyberinfrastructure for Productive Science and Engineering:

Identification of Barriers to and Enablers of Successful Projects” ed uno dei rapporti di

questo progetto, intitolato Opening Science Gateways to Future Success [72], ha

riguardato gli Science Gateway e la loro importanza. Quest’ultima è confermata dal

programma sugli Science Gateway [73] lanciato e supportato dal progetto XSEDE e dal

grande numero di implementazioni [74].

Science Gateway sono presenti anche in altre regioni del mondo. Alcuni esempi sono

elencati di seguito:

Il portale GRISU [75] dell’ Australian Research Collaboration Service

• (ARCS) [76];

Il portale GOS [77] della China National Grid Infrastructure (CNGrid) [78];

• Il Gateway Open Source Drug Discovery (OSDD) [79] basato su Galaxy [80]

• (una piattaforma web per applicazioni di bioinformatica e di biomedicina) in

India;.

L'Universal Grid User Interface (UGI) [81] di NAREGI [82], la National Grid

• Initiative giapponese;

Il portale [83] di TWGrid [84], la National Grid Initiative di Taiwan che

• permette simulazioni meteoroliche e climatice con il Weather Research and

Forecasting Model (WRF) [85];

Lo Science Gateway del progetto EUMEGRID-Support [86], quello dell’Arab

• States Research and Education Network (ASREN) [87], quello di ARN [88] in

Algeria e quello di MaGrid [89] in Marocco, nei paesi di lingua araba;

Lo Science Gateway del progetto GISELA [90] in America Latina.

La maggior parte degli Science Gateway esistenti sono soluzioni verticali ma di recente

si stanno affermando anche dei veri e propri framework per la loro creazione. Nel

prossimo paragrafo è discusso quello che è stato usato per il lavoro condotto in questa

tesi.   Science  Gateway   49  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

5.3. Il Catania Science Gateway Framework

Il Catania Science Gateway Framework (CSGF) [91,92] è sviluppato da alcuni anni da

ricercatori e tecnologi della Sezione di Catania dell’Istituto Nazionale di Fisica

Nucleare (INFN) che lavorano sotto il coordinamento del Prof. Roberto Barbera,

correlatore di questa tesi. Le caratteristiche del framework e le sue componenti

principali sono presentate e discusse nei paragrafi seguenti.

5.3.1. L’architettura generale

 

L’architettura generale del CSGF è presentata nella figura 5.5.  

Figura 5.5 - Architettura del Catania Science Gateway Framework

 

Gli utenti, che possono avere diversi ruoli all’interno delle organizzazioni virtuali e

delle comunità scientifiche di cui fanno parte, accedono ad un portale web basato su

Liferay [93] usando le loro credenziali federate, rilasciate dall’Identity Provider [94] al

quale appartengono e che fa parte di una Identity Federation [95].

Il portale web contiene le applicazioni di interesse per la comunità/progetto per cui lo

Science Gateway è stato sviluppato e queste possono essere eseguite, in modo

trasparente per l’utente finale, su cluster HPC dedicati, su infrastrutture Grid e su

infrastrutture Cloud grazie all’adozione dello strandard SAGA [96] (Simple API for

Grid Applications) che è stato definito all’Open Grid Forum [50].

Inoltre, l’adozione dello standard OCCI [49], anch’esso definito dall’Open Grid Forum,

e che abbiamo visto nel capitolo 4, permette ad uno Science Gateway creato con il

CSGF di orchestrare Cloud basate su middleware differenti e gestite da enti diversi,

mantenendo lo stesso nome a dominio per i servizi, grazie al supporto di DNS dinamici.

  Science  Gateway   50  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

L’elenco degli standard e delle relative implementazioni adottate dal CSGF è riportata

di seguito per completezza d’informazione:

Ø Livello di Presentazione: lo standard JSR 168/286 [97]

(anche conosciuti come gli standard “portlet 1.0” e “portlet 2.0”);

Ø Autenticazione: lo standard Security Assertion Markup Language (SAML) [98]

definite da OASIS [99] e le implementazioni Shibboleth [100] e

SimpleSAMLphp [101], le più comuni nel mondo della ricerca scientifica;

Ø Autorizzazione: Il Lightweight Direct Access Protocol [102] e la sua

implementazione OpenLDAP [103];

Ø Gestione di certificati digitali su smartcards: lo standard Cryptographic Token

Interface Standard (PKCS#11) [104] e la sua implementazione Cryptoki;

Ø Interfaccia dell'applicazione al middleware sottostante: lo standard Simple API

for Grid Applications (SAGA) [96] definito dall’ Open Grid Forum (OGF) e la

sua implementazione JSAGA [105];

Ø Interfaccia alle infrastrutture Cloud: lo standard OCCI [49] definito dall’Open

Grid Forum e la sua implementazione rOCCI [106].

Le varie componenti del CSGF, e come queste fanno usi degli standard sopra elencati,

sono descritte ed approfondite nei seguenti paragrafi.

5.3.2. Le Portlet

 

Le portlet sono oggetti software riusabili all'interno di un portlet container (come, ad

esempio, Liferay), un portale web di nuova generazione agente su un application server

(come, ad esempio, Glassfish [107] o Tomcat [108] ).

Lo standard WSRP (Web Services for Remote Portlets) definisce un protocollo per il

dialogo fra il portale e le portlet mentre le Java Portlet Specification (JSR168 e

JSR286) definiscono un insieme di interfacce applicative (API) per l'interazione fra

il portlet container e le portlet.

Queste possono essere considerate come un tipo speciale di servlet, progettate per essere

inserite facilmente in un portlet container ed essere eseguite al comando dell’utente. A

differenza delle servlet, però, le portlet non hanno comunicazione diretta con il browser,

non possono dunque inviare redirect o errori, inoltrare richieste o scrivere markup al

flusso in uscita. Esse sono componenti più semplici e quindi più leggeri. Ciò consente

una maggior facilità di gestione: possono essere impostate, installate o rimosse, create o

cancellate direttamente dall'amministratore usando l'interfaccia grafica del portale.

Inoltre, a differenza delle servlet, che possono rappresentare pagine web complete, le

portlet rappresentano singoli componenti (possiamo facilmente pensare ad una portlet

come un mattoncino di Lego), aggregati dal portale che svolge la funzione di container.

Ne consegue che il portlet container ha un ruolo più determinante di quello del servlet

  Science  Gateway   51  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

container, poiché attraverso di esso le portlet comunicano tra loro, accedono a contenuti

remoti e a dati persistenti.

Tipicamente, quindi, una pagina di uno Science Gateway implementato con il CSGF è

suddivisa in una collezione di finestre, il contenuto di ciascuna delle quali viene definito

da una diversa portlet. A ciascuna portlet è destinata una o più azioni che possono

andare dalle più semplici, come quella di mostrare del testo, alle più complesse, come

quella di eseguire un’applicazione su una Grid o su una Cloud.

Il grande vantaggio dell’adozione dello standard delle portlet è che, come i mattoncini

del Lego, esse possono essere facilmente spostate da uno Science Gateway ad un altro,

se ciò è richiesto dalla comunità scientifica di riferimento.

5.3.3. Autenticazione ed Autorizzazione

 

Uno dei principali ostacoli per gli utenti non esperti che vogliono usare le e-

infrastrutture, come ad esempio le Grid , è il fatto che queste adottano meccanismi di

sicurezza complessi basati su protocolli basati su chiavi pubbliche e private (Public Key

Infrastructure - PKI) e vi si accede attraverso interfacce utente di basso livello, basate

su riga di comando (Command Line interface – CLI), cioè non grafiche.

Gli utenti sono quindi costretti a richiedere e a gestire certificati digitali personali

nonché ad avere credenziali diverse per i diversi sistemi ai quali hanno accesso.

Il CSGF supera questi problemi disaccoppiando la fase di autenticazione da quella di

autorizzazione e gestendole in maniera diversa.

Per l’autenticazione degli utenti il CSGF supporta lo standard SAML e, come detto in

precedenza, le implementazioni di tale standard fatte da Shibboleth e SimpleSAMLphp.

Lo standard SAML permette di implementare il Single Sign On (SSO) tra servizi web

diversi, dando così la possibilità all’utente di autenticarsi su risorse differenti tra loro

usando sempre le stesse credenziali.

SAML ha permesso in quest’ultimo decennio la creazione delle cosiddette Identity

Federation (Federazioni d’Identità). Alcuni termini di base che vengono utilizzati per

definire le entità all'interno delle Identity Federation sono:

Ø Il Service Provider (SP): fornisce un servizio agli utenti e “consuma”

informazioni su di questi, che possono essere utilizzate per ulteriori decisioni di

autorizzazione;

Ø L’Identity Provider (IdP): è un servizio connesso alla gestione delle identità

dell'organizzazione ed è responsabile dell’autenticazione digitale dei propri

utenti. L’IdP deve essere in grado di rilasciare informazioni reali e veritiere in

merito agli utenti della gestione delle identità dell'organizzazione in modo

standardizzato.

Ø L’Identity Federation (IdF): è un insieme di SP e di IdP aderenti a delle precise

regole e politiche di “fiducia” (trust); gli utenti provenienti dai vari IdP possono

  Science  Gateway   52  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

  accedere in maniera semplice e trasparente ai vari SP che si “fidano” delle

informazioni fornite dagli IdP circa l'identificazione dell'utente.

Ø Assertion: è un insieme di informazioni rilasciate dall’IdP riguardanti l'utente.

L'utente ha un account su almeno uno degli IdP e può accedere ad un SP solo se le

assertion fornite dal suo IdP soddisfano tutte le regole definite dalla politica del SP. Nel

dettaglio, il processo è il seguente: (i) un utente accede a un SP che non ha alcuna

informazione circa la sua identità ed affiliazione; (ii) l’utente viene reindirizzato all’IdP

della propria organizzazione per autenticarsi (inserendo le sue credenziali); (iii) dopo

che l'utente si è autenticato con successo sul suo IdP quest’ultimo crea l’assertion

riguardante l’utente e la invia all’SP; (iv) l’SP, verificata l’autenticità dell’utente,

verifica il suo livello di autorizzazione e gli mostra la pagina o le pagine web che ad

esso corrispondono.

Allo stesso modo, l'utente può accedere agli altri SP che appartengono alla Federazione

usando lo stesso set di credenziali (username e password) che gli sono stati forniti dal

suo IdP al momento della registrazione.

Il modello delle Federazioni d’Identità è quindi senza dubbio più semplice per gli utenti,

in quanto non è legato ad alcun particolare metodo di autenticazione ed è l’istituzione

che decide il metodo più appropriato per i propri utenti. Il cosiddetto Privacy

Enhancement è un benefico effetto collaterale dell’uso di asserzioni da parte di IdP ed

SP. L’IdP infatti può fornire solo affermazioni che non contengono informazioni

personali sull'utente, come ad esempio il fatto che una persona è membro di un

particolare gruppo, senza rivelare il suo nome o altro identificativo.

La popolarità delle Identity Federation è in costante crescita in tutto il mondo e ad oggi

più di 17 milioni di ricercatori posseggono delle credenziali federate. In Europa, tutte le

Reti Nazionali dell’Educazione e della Ricerca hanno creato una Identity Federation

nazionale; in Italia, il GARR [109] ha creato e gestisce la Federazione IDEM [110] e

l’Università di Catania è da alcuni mesi uno degli IdP di IDEM.

Il team di sviluppatori del Catania Science Gateway Framework ha creato un modulo

(in gergo, plugin) di Liferay che consente l’autenticazione tramite credenziali federate.

In tal modo, gli Science Gateway implementati con il CSGF possono configurarsi come

Service Provider di Federazioni d’Identità e quindi avere un enorme numero di

potenziali utenti.

Una volta andata a buon fine l’autenticazione, il CSGF gestisce le autorizzazioni tramite

l’uso di un registro LDAP implementato con OpenLDAP, nel quale i vari utenti sono

inseriti in gruppi con ruoli e privilegi definiti dalla comunità di riferimento per la quale

un dato Science Gateway è stato creato.

Nello specifico, Liferay recupera dal server LDAP l'elenco dei gruppi di cui l'utente è

membro e svolge l'associazione con l’ID corrispondente all’utente sullo Science

Gateway. Per ciascun gruppo definito in LDAP, Liferay crea automaticamente un ruolo

che è l'elemento in cui l'autorizzazione può essere specificata all'interno del portale.

Pertanto, il server LDAP è responsabile della gestione dei gruppi di utenti e, a seconda

del gruppo a cui appartiene, l'utente ottiene i ruoli e quindi le varie autorizzazioni da

  Science  Gateway   53  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

Liferay e di conseguenza gli vengono mostrate la pagina o le pagine web che può

vedere ed usare. L'amministratore dello Science Gateway è il responsabile ultimo della

coerenza tra il gruppo definito sul server LDAP e l'autorizzazione relativa al ruolo

associato al gruppo.

La figura 5.6 mostra schematicamente la sequenza delle fasi di autenticazione (a

sinistra) e di autorizzazione (a destra) discusse finora. I loghi inclusi nell’ellissi in alto si

riferiscono ad alcune delle Federazioni d’Identità supportate dagli Science Gateway

implementati con il CSGF.  

Figura 5.6 – Schema di Autenticazione e di Autorizzazione del CSGF

5.3.4. Gli adaptor di JSAGA

 

Come si è già detto in precedenza, SAGA è uno degli standard dell’Open Grid Forum e

definisce un’interfaccia di alto livello tra le applicazioni dell’utente ed il middleware

dell’infrastruttura su cui tali applicazioni devono essere eseguite.

I principali obiettivi per cui lo standard SAGA è stato definito sono:

v Fornire un unico livello di accesso ad infrastrutture di calcolo distribuito diverse

ed ai loro relativi middleware;

v Fornire un’interfaccia di programmazione stabile per applicazioni che devono

essere eseguite in maniera “distribuita”;

v Fornire un’astrazione di livello superiore rispetto a quella di un middleware

specifico di un particolare paradigma di calcolo (a cluster, Grid o Cloud).

L’implementazione dello standard SAGA utilizzata all’interno del CSGF è JSAGA

(acronimo per Java SAGA). JSAGA è costituito da:   Science  Gateway   54  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

  Librerie di base [111]: contenenti il sistema di base, i moduli di runtime e le

• API per le varie azioni (gestione dell’accesso, gestione dei dati, gestione delle

esecuzioni, ecc.);

Adaptor [112]: moduli software specifici che implementano le interfacce verso

• vari tipi di middleware.

Il team di sviluppatori del Catania Science Gateway Framework ha creato un adaptor di

JSAGA per OCCI [113] che sarà descritto nel prossimo capitolo e che permette di

interagire con diversi middleware Cloud e che è quello che ho usato per sviluppare

l’applicazione descritta nel prossimo capitolo.

5.3.5. Il Grid & Cloud Engine

 

Il “cuore” del Catania Science Gateway Framework è il cosiddetto Grid & Cloud

Engine, la cui architettura è mostrata schematicamente nella figura 5.7.

   

Figura 5.7 – Schema dell’architettura del Grid & Cloud Engine

Il Grid & Cloud Engine è una libreria Java che espone “verso l’alto” delle API facili ed

intuitive chiamabili da chi integra una data applicazione in uno Science Gateway e

s’interfaccia, “verso il basso”, con le API di JSAGA ed in particolare con gli adaptor

relativi ai vari middleware (alcuni dei quali rappresentati dai loro loghi nella box che

compare nella parte bassa della figura) esistenti sulle infrastrutture cui lo Science

Gateway ha accesso e sulle quali può eseguire le applicazioni che sono state integrate al

suo interno.   Science  Gateway   55  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

Il Grid & Cloud Engine fornisce funzionalità per la gestione delle esecuzioni (Job

Engine) e dei dati (Data Engine) delle varie applicazioni e si interfaccia con altri due

componenti molto importanti del Catania Science Gateway Framework: l’eTokenServer

e lo User Tracking DB.

L’eTokenServer è un servizio che permette allo Science Gateway di creare dei proxy-

certificate [114], necessari per “firmare” tutte le transazioni da e verso Grid e da e verso

Cloud, a partire da degli speciali certificati digitali, detti certificati “robot”, che sono

conservati su delle smartcard USB fisicamente connesse alla macchina che ospita il

servizio. Per far questo, l’eTokenServer fa uso dello standard Cryptographic Token

Interface Standard (PKCS#11) e della sua implementazione Cryptoki. Ciò permette agli

utenti di utlizzare infrastrutture Grid e Cloud senza preoccuparsi di possedere e gestire

un certificato digitale personale, cosa che, come già detto in precedenza, ha

rappresentato un ostacolo per l’uso di queste e-infrastrutture da parte di non esperti di

informatica e sicurezza digitale.

Naturalmente, se un dato Science Gateway contiene N utenti registrati tutti useranno lo

stesso certificato “robot” e questo viola la non repudiabilità delle azioni che è uno dei

pilastri fondanti delle Public Key Infrastructure. Per risolvere questa criticità,

soddisfacendo nel contempo le politiche di uso e di tracciabilità [115,116]

dell’European Grid Infrastructure, il CSGF include il servizio di User Tracking che altro

non è che un database MySQL sul quale vengono conservate tutte le azioni (es:

esecuzione di un’applicazione, caricamento/copia/cancellazione di un file, ecc.) che un

utente fa sullo Science Gateway dal momento in cui vi accede fino al momento in cui ne

esce. Com’è facile comprendere, lo User Tracking DB riveste quindi un’importanza

fondamentale per l’auditing e l’accounting dell’uso dei Catania Science Gateway da

parte dei loro utenti.   Science  Gateway   56  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

6. Progetto software e risultati  

Figura 6.1 – Pagina introduttiva della portlet di Blender

  Progetto  software  e  risultati   57  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

6.1. Introduzione

 

In questo capitolo presenterò il software che ho creato per questo lavoro di tesi,

analizzando le varie fasi che ho seguito per realizzarlo, dalla raccolta dei requisiti fino ai

risultati finali ottenuti. Alle varie fasi corrisponderanno i prossimi paragrafi. Il capitolo

sarà poi chiuso da una discussione sui possibili sviluppi futuri del progetto software.

Come ho studiato, infatti, nel corso di Ingegneria del Software, tenuto nell’Anno

Accademico 2012-2013 dal Prof. Emiliano Tramontana, l'analisi dei requisiti (talvolta

detta semplicemente analisi) è un'importante attività, preliminare allo sviluppo di

un sistema software, il cui scopo è quello di definire le funzionalità che il nuovo

prodotto deve offrire, ovvero i requisiti che devono essere soddisfatti dal software

sviluppato. Questa fase deve concludersi con la stesura di una dettagliata specifica dei

requisiti che descrive le funzionalità del nuovo software nella loro interezza.

Tale specifica guida le fasi successive di sviluppo che, complessivamente, sono volte a

realizzare quanto previsto da tale specifica che sarà descritta più avanti in un paragrafo

dedicato.

Altra fase importante che tratterò in un altro dei paragrafi di questo capitolo, è la

definizione dello schema delle classi la quale, grazie al supporto grafico di diagrammi

creati con l’Unified Modeling Language (UML) [117], consente di descrivere i tipi di

entità con le loro caratteristiche e le eventuali relazioni. I diagrammi UML delle classi

sono basati su versioni astratte di tali concetti e possono essere utilizzati per descrivere

sostanzialmente qualsiasi contesto, a qualsiasi livello di astrazione. Di conseguenza,

l’UML prevede un loro impiego a livello di analisi e in particolare di analisi del

dominio (ovvero, la descrizione del contesto in cui un sistema software deve operare),

ma anche a livello di progettazione (nella descrizione della struttura interna del sistema,

dei suoi componenti e delle loro relazioni).

 

6.2. Definizione del progetto software

  6.2.1. Formazione preliminare e materiale didattico

 

Prima di cominciare il lavoro di analisi del progetto software, ho acquisito la

formazione di base sul Catania Science Gateway Framework, seguendo offline il corso

web [118] per sviluppatori che è stato realizzato nel Luglio del 2013 dall’INFN di

Catania e rifacendo tutte le esercitazioni presenti nell’archivio di materiale didattico

[119].

6.2.2. Preparazione dell’ambiente integrato di sviluppo

 

Ultimata la formazione offline, ho quindi imparato a configurare l’ambiente integrato di

sviluppo ed ho realizzato autonomamente due postazioni di lavoro: una su di una

macchina con Linux Ubuntu e l’altra su di una macchina con Mac OS X Mavericks.

  Progetto  software  e  risultati   58  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

La macchina con Mac OS X è il mio notebook personale mentre quella con Linux è una

macchina virtuale che “gira” al suo interno. Tale configurazione è stata realizzata per

permettermi di lavorare sul mio progetto software anche “in mobilità”, grazie

all’accesso alla Virtual Private Network (VPN) del gruppo di sviluppatori del CSGF di

cui ho beneficiato durante il lavoro di tesi.

Per completezza d’informazione, i passi che ho seguito e documentato per la creazione

dell’ambiente integrato di sviluppo, in modo che ciò possa essere utile ad altri dopo di

nell’Appendice  2

me, sono riportati .  

  6.2.3. Requisiti

 

Come già più volte detto in precedenza, l’idea di sviluppare questo software è nata per

offrire un servizio di tipo SaaS a coloro che realizzano progetti di computer grafica con

Blender, permettendo loro di diminuire i tempi necessari all’inevitabile processo di

rendering.

Prima di tutto, di concerto con i miei relatori, mi sono autoimposto degli obiettivi da

raggiungere con il mio progetto software. Ecco dunque i vantaggi che dovevo poter

fornire ad un utente-tipo del mio servizio che non disponesse di mezzi di calcolo

particolarmente performanti:

Diminuire i tempi di esecuzione del processo di rendering, grazie all’utilizzo

• (eventualmente in parallelo) di potenti macchina virtuali;

Evitare l’utilizzo del processore della propria macchina, così da non sottoporla a

• problemi legati al riscaldamento (a volte così alto da subire un “freezing” con

conseguente shutdown, perdendo tutto il lavoro fatto) ed all’usura delle varie

componenti hardware;

Non dover tenere la propria macchina occupata durante il tempo di esecuzione

• del processo, riuscendo così a svolgere altri lavori senza preoccuparsi

dell’esecuzione del rendering.   Progetto  software  e  risultati   59  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

  6.2.4. Schema delle classi

 

Per completezza, le due figure mostrate nel seguito mostrano, rispettivamente, lo

schema della classe Java che ho creato per la mia applicazione e la lista dei suoi metodi.

Per ottenere le due figure ho installato e configurato JavaDoc [120] sulla mia macchina.

   

Figura 6.2 – Schema della classe Blender.class  

Figura 6.3 - Elenco dei metodi

 

 

    Progetto  software  e  risultati   60  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

6.2.4.1. Workflow della portlet

 

Prima d’iniziare a sviluppare una portlet, è importante capire il workflow interno

definito dallo standard JSR 168/286). La figura qui sotto raffigura bene l'intero

workflow tra i diversi componenti di una portlet.  

Figura 6.4 - Workflow interno di una portlet

 

Il ciclo più importante prevede lo scambio tra la ProcessAction e i metodi Render,

rispettivamente responsabili dell'azione selezionata dall'utente nei moduli di input e

quindi dell’interfaccia mostrata come conseguenza dell’azione compiuta dall'utente.

6.2.4.2. Modalità di una portlet

Le portlet standard lavorano in tre diverse modalità: [VIEW], [EDIT] ed [HELP]:

Ø à

[VIEW] Genera la normale interfaccia utente;

Ø à

[EDIT] Viene utilizzato per memorizzare le preferenze della portlet;

Ø à

[HELP] Mostra le istruzioni per d’uso della portlet.

Il metodo Render è responsabile dell’esecuzione di metodi diversi della classe

GenericPortlet, in base alla modalità della portlet corrente, come mostrato nella figura

seguente.   Progetto  software  e  risultati   61  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

 

   

Figura 6.5 - Chiamata del metodo Render

 

 

Il metodo Render chiama poi i seguenti metodi della classe GenericPortlet: doView,

doHelp e doEdit.  

Figura 6.6 - Metodo doView

  Progetto  software  e  risultati   62  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

   

Figura 6.7 - Metodo doEdit  

Figura 6.8 - Metodo doHelp

Ogni metodo è quindi in grado di mostrare l'interfaccia utente appropriata in base

all’azione dell'utente e in base alla portlet creata.

6.2.4.3. Scambio di dati tra Java e le pagine JSP

 

Durante l'interazione con l'utente avviene uno scambio di dati continuo tra la classe

GenericPortlet e le JavaServer Page (JSP) responsabili della presentazione grafica

dell'interfaccia utente. Vediamo come si può gestire lo scambio di dati tra il codice Java

e le JSP.   Progetto  software  e  risultati   63  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

JSP Java

All'interno della JSP, occorre inserire tutti i campi di input in Java in un form web:

<form action="<portlet:actionURL portletMode="view">

<portlet:param name="param_name_1" value="paramvalue 1" />

...

<portlet:param name="param_name_n" value="paramvalue n"/>

...

<input … />

<input … />

<input type="submit" … />

</form>

Dentro il codice Java, invece, si possono prendere i valori di input dell’interfaccia con

la seguente istruzione:

doView/doHelp/doEdit(RenderRequest request,…

// To obtain the parameter just set …

String param_i= request.getParameter("param_name_i");

Java JSP

Dentro il codice Java si possono prendere i valori di input dell’interfaccia web con:

doView/doHelp/doEdit(RenderRequest request,…

// To obtain the parameter just set …

String param_i= request.setAttribute("param_name_i","param_value_i");

Dentro la pagina JSP, invece, si possono assegnare i valori dei parametri con il

seguente codice:

<% // To load variables from PortletClass …

%>

<jsp:useBean id="param_name_k" class="<variable type k>"

scope="request"/>

<% // To reference a paramvalue

%>

Reference paramenter_name' value with: <%=param_name_k%>

  Progetto  software  e  risultati   64  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

6.2.4.4. GenericPortlet main workflow

L'immagine seguente mostra il workflow interno della classe GenericPortlet mentre

l'utente interagisce con la portlet integrata nello Science Gateway.

   

Figura 6.9 - Workflow della classe GenericPortlet

 

Il ciclo inizia con il metodo Init() e l'intero workflow viene eseguito dai metodi

ProcessAction e doView (supponendo come modalità quella “VIEW”). Per ogni “User

Action” sarà selezionato una diversa View.

Durante questo ciclo due istanze di oggetti importanti vengono utilizzati per scambiare

dati tra il metodo doView ed i metodi della classe ProcessAction:

Ø actionRequest: input del metodo processAction che prepara l'oggetto da

visualizzare con i metodi View;

Ø renderRequest: input per i metodi doView / doHelp / doEdit.

Ciò è mostrato nella figura successiva.  

Figura 6.10 - Scambio dati tra doView e ProcessAction

  Progetto  software  e  risultati   65  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

 

Per completezza, mostro di seguito la struttura del metodo processAction.

   

Figura 6.11 - Metodo ProcessAction

  6.2.5. Funzionalità

 

Compreso il meccanismo delle portlet, dei loro workflow interni e dello scambio di dati

con le JSP, sono passato quindi a progettare l’interfaccia utente della portlet per

l’esecuzione di Blender e le funzionalità che questa avrebbe dovuto avere.

Queste sono elencate nel seguito:

Una pagina descrittiva molto semplice su Blender e sull’infrastruttura/e Cloud

• che si sta/stanno utlizzando;

Una pagina che permettesse all’utente di visualizzare graficamente (o meglio,

• geograficamente) l’infrastruttura che sta usando;

Una pagina per la scelta dei parametri di esecuzione, del file da “renderizzare” e

• dell’eventuale notifica via email dell’inizio e della fine dell’esecuzione;

Una pagina per il controllo dello stato dell’esecuzione ed il recupero dell’output

• alla fine (questa fa già parte del coresoftware Science Gateway Framework).

 

    Progetto  software  e  risultati   66  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

6.3. Implementazione

 

Dopo aver fatto quanto esposto sin qui, ho iniziato la scrittura del codice.

Preliminarmente, ho studiato il funzionamento dell’adaptor JSAGA per OCCI che è

usato dal Grid & Cloud Engine ed il cui schema è riportato nella figura seguente.  

Figura 6.12 - Schema dell'adaptor JSAGA per OCCI

Come ogni altro adaptor JSAGA, quello per OCCI implementa i metodi per la creazione

del contesto di sicurezza tra Science Gateway e infrastruttura (nel nostro caso, la VM su

cui deve “girare” Blender), la gestione del ciclo di vita dell’esecuzione (accensione

della VM, inizio, monitoraggio, fine, distruzione della VM) ed il trasferimento dallo

Science Gateway all’infrastruttura (alla VM con Blender) e viceversa dei file di input e

di quelli di output.

Tutto ciò è descritto nel workflow disegnato nella figura 6.12 e spiegato qui di seguito:

Su richiesta dell’utente (quando questi vuole eseguire la sua applicazione), lo

• Science Gateway “chiama” l’adaptor e gli fa accendere la VM con la giusta

applicazione a bordo (nel nostro caso, Blender);  

 

Dopo di che, l’adaptor stabilisce una connessione SSH tra Science Gateway e

• VM e vi trasferisce i file di input (nel nostro caso, il file da “renderizzare”);  

  Fatto ciò, l’applicazione viene fatta partire e monitorata fino alla sua

• conclusione;  

  Alla fine, l’adaptor si fa carico di prelevare dalla VM i file di output e

• distruggerla.  

    Progetto  software  e  risultati   67  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

Capito come funziona l’adaptor JSAGA per OCCI, la prima cosa che ho scritto (in

linguaggio BASH) è stato lo script per l’esecuzione di Blender, che deve far parte dei

file di input da trasferire dallo Science Gateway alla VM. Per completezza, tale script, è

riportato nel seguito.

#!/bin/bash

echo "- Running on "`hostname -f`

echo "- Checking input file"

if [ "X$1" == "X" ] ; then

echo "file is missing!"

exit

else INPUT_FILE=`basename $1`

fi

OUTPUT_FILE=`echo $INPUT_FILE | awk -F'.blend' '{print $1}' `.avi

SOFTWARE_PATH=/root/blender-2.69-linux-glibc211-i686

echo "INPUT_FILE="$INPUT_FILE

echo "OUTPUT_FILE="$OUTPUT_FILE

echo "SOFTWARE_PATH="$SOFTWARE_PATH

echo "Checking Blender 2.69 software"

tree -L 1 ${SOFTWARE_PATH}

echo; echo "- Starting Blender 2.69 at ";date

${SOFTWARE_PATH}/blender -b ${INPUT_FILE} \

-o `basename ${OUTPUT_FILE}` \

-F AVIJPEG -a

#${SOFTWARE_PATH}/brender.py ${INPUT_FILE} ${OUTPUT_FILE} 2>/dev/null

>/dev/null

echo;echo "- Checking results..."

ls -al `basename ${OUTPUT_FILE}`

if [ $? -eq 0 ] ; then

echo "The AVI file HAS BEEN successfully processed."

else echo "Problems occured during the processing of the Blender

macro file, please check log files."

fi

cat <<EOF >> output.README

#

# README - Blender 2.69

#

# Marco Zennaro, Università di Catania

# <mailto:zennaro.unict@gmail.com>

#

This is a generic VM i686 server configured to run Blender 2-69.

Blender is a free and open-source 3D computer graphics software

product used for creating animated films, visual effects, art, 3D

printed models, interactive 3D applications and video games. Blenders

features include 3D modeling, UV unwrapping, texturing, raster

graphics editing, rigging and skinning, fluid and smoke simulation,

  Progetto  software  e  risultati   68  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

particle simulation, soft body simulation, sculpting, animating, match

moving, camera tracking, rendering, video editing and compositing.

Alongside the modelling features it also has an integrated game

engine.

If the job has been successfully executed, the following files will be

produced:

~ std.out: the standard output file;

~ std.err: the standard error file;

~ .avi: the movie file produced during the computation.

EOF

tar zcf results.tar.gz output.README `basename ${OUTPUT_FILE}`

2>/dev/null

Dopo aver scritto lo script di esecuzione, e definito quali dovessero essere i file di

output da recuperare alla fine dell’operazione di rendering (stdout, stderr e file

contenente il video “renderizzato”), ho iniziato finalmente a scrivere il codice della

portlet e le relative JSP. Tutto il codice che ho sviluppato è disponibile sul web alla

pagina:

http://sourceforge.net/p/ctsciencegtwys/liferay/HEAD/tree/trunk/blender-portlet/

Alcuni screenshot sono mostrati nel seguito, tranne quello della pagina di descrizione

dell’applicazione che è stato invece già inserito all’inizio del presente capitolo.

La figura seguente mostra la pagina nella quale l’utente può visualizzare l’infrastruttura

che sta usando e, volendo, scegliere il sito sul quale eseguire l’applicazione di

rendering;

   

Figura 6.13 - Pagina di visualizzazione dell'infrastruttura Cloud

  Progetto  software  e  risultati   69  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

La figura seguente mostra invece la pagina per la scelta dei parametri di esecuzione, del

file da “renderizzare” e dell’eventuale notifica via email dell’inizio e della fine

dell’esecuzione.

   

Figura 6.14 - Pagina con i parametri di configurazione dell'esecuzione

 

I vari campi sono spiegati nel seguito:

Virtual Server: permette di scegliere la VM da usare; al momento esiste solo un

• template con a bordo la versione 2.69 di Blender;

VM Template: permette di scegliere le dimensioni (in termini di numero di core

• logici e di GB di memoria) della VM da usare;

VM Name: permette di dare un nome logico alla VM;

• Description: permette di associare una breve descrizione all’esecuzione in

• modo da ritrovarla facilmente nell’elenco dei propri job;

Notification: permette di impostare la notifica via email dell’inizio e della fine

• dell’esecuzione dell’applicazione di rendering;

Advanced settings: al momento, permette solo di scegliere il file da

• renderizzare.

Fatte tutte le scelte, basta cliccare sul “bottone verde” che compare in basso a sinistra

per mandare in esecuzione l’applicazione. Da questo momento in avanti, il suo stato può

  Progetto  software  e  risultati   70  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

essere monitorato sulla pagina MyJobs, facente parte integrante del Catania Science

Gateway Framework, che è mostrata nella figura seguente.

   

Figura 6.15 - Pagina di monitoraggio delle varie esecuzioni

 

Quando l’esecuzione dell’applicazione è completata con successo, l’indicazione sul suo

stato (SCHEDULED, RUNNING, ecc.) viene sostituita da una piccola iconcina che

contiene il link per lo scaricamento dei file di output sul computer dell’utente.

 

6.4. Possibili sviluppi futuri

 

Come sempre accade, il lavoro relativo ad una tesi sperimentale, qual è stata la mia,

rappresenta una “finestra” che si apre per un tempo finito sul normale “scorrere” delle

attività di un gruppo di ricerca. Ciò significa che molto è stato fatto ma che sviluppi

futuri sono ancora possibili sul mio progetto software.

Alcuni sono elencati di seguito, a conclusione del capitolo:

La possibilità di scegliere la versione di Blender e/o l’algoritmo di rendering,

• cambiando nella pagina di input il template di VM;

La possibilità di lanciare simultaneamente pià renderizzazioni (in un’unica job

• collection in modo da sfruttare la scalabilità intrinseca ad un ambiente distribuito

qual è una Cloud);   Progetto  software  e  risultati   71  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

  Fare uno studio di scalabilità in termini di tempi di esecuzione del rendering e

• delle dimensioni del file da renderizzare;

Distribuire i template di VM utilizzati in altri siti, sia del CHAIN-REDS Cloud

• Testbed che dell’EGI Federated Cloud (questa attività è stata già pianificata);

Inserire la portlet per l’esecuzione di Blender in uno o più Science Gateway

• ufficiali (questa attività è stata già pianificata).

  Progetto  software  e  risultati   72  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

7. Appendice 1

7.1. Creazione del template di una Macchina Virtuale

 

Prima dell’installazione della macchina virtuale, ho dovuto tener conto della necessità

di soddisfare alcuni preriquisiti. Ho così eseguito i sequenti comandi:

# yum install -y gcc gcc-c++ glibc-devel glibc-devel.i686

# yum install csh

# yum install -y libpng-devel

Ho quindi compilato il compilatore GCC 4.8 all’interno della cartella objdir eseguendo:

# wget ftp://ftp.gwdg.de/pub/misc/gcc/releases/gcc-4.8.0/gcc-

4.8.0.tar.gz

# tar xzf gcc-4.8.0.tar.gz

# cd gcc-4.8.0

# ./contrib/download_prerequisites

# cd ..

# mkdir objdir

# cd objdir

# $PWD/../gcc-4.8.0/configure --prefix=/opt/gcc-4.8.0

# make

# make install

# cd ..

Ho quindi eseguito il download e l’installazione di Blender sulla macchina virtuale:

# wget http://download.blender.org/release/Blender2.69/blender-

2.69-linux-glibc211-i686.tar.bz2

# tar xf blender-2.69-linux-glibc211-i686.tar.bz2

# cd blender-2.69-linux-glibc211-i686

# yum install libfreetype.so.6

# yum install libSDL-1.2.so.0

# yum install libGL.so.1

# install libGLU.so.1

# yum install libXi.so.6

ed eseguito l’export di alcune variabili:

# export NETCDF=/usr/local/

# export WRFIO_NCD_LARGE_FILE_SUPPORT=1

# export CC=/opt/gcc-4.8.0/bin/gcc

# export CXX=/opt/gcc-4.8.0/bin/g++

# export FC=/opt/gcc-4.8.0/bin/gfortran

# export JASPERLIB=/usr/local/lib/

# export JASPERINC=/usr/local/include/jasper/

Ho scaricato e installato zlib. La zlib è di fatto una libreria per il supporto del

compressore di default del Sistema Operativo (gzip) ed ha molti ambiti di applicazione:

dalla lettura/scrittura di files compressi alla compressione “al volo” degli stream.

   

Appendice  1 73  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

  # wget http://zlib.net/zlib-1.2.8.tar.gz

# tar xvzf zlib-1.2.8.tar.gz

# cd zlib-1.2.8

# ./configure

# make

# make install

# cd ..

A questo punto ho compilato HDF5 che è un programma portabile ed estensibile per la

gestione e la manipolazione di diversi tipi di dati. Esso è stato disegnato per un I/O

flessibile ed efficiente di dati voluminosi e complessi.

# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gcc-

4.8.0/lib/:/opt/gcc-4.8.0/lib64/

# wget http://www.hdfgroup.org/ftp/HDF5/current/src/hdf5-

1.8.11.tar.gz

# tar xvzf hdf5-1.8.12.tar.gz

# cd hdf5-1.8.12

# ./configure --with-zlib=/usr/local/include,/usr/local/lib --

prefix=/usr/local/ --enable-fortran --enable-cxx --enable-shared

# make

# make install

# cd ..

Sono passato così all’installazione e compilazione di netcdf, un altro set di librerie per

la gestione di dati scientifici array oriented:

# wget http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-

4.3.0.tar.gz

# tar xvzf netcdf-4.3.0.tar.gz

# cd netcdf-4.3.0

# ./configure --enable-netcdf4 --enable-benchmarks

# make

# make install

# cd ..

e di netcdf fortran:

# wget http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-

fortran-4.2.tar.gz

# tar xvzf netcdf-fortran-4.2.tar.gz

# cd netcdf-fortran-4.2

# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/

# ./configure

# make

# make install

# cd ..

Quindi ho fatto le due ultime installazioni e configurazioni: prima di jasper

# wget http://www.ece.uvic.ca/~frodo/jasper/software/jasper-

1.900.1.zip

# unzip jasper-1.900.1.zip

# cd jasper-1.900.1

# ./configure --enable-shared

# make

# make install    

Appendice  1 74  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

e dopo di Grib:

# wget

https://software.ecmwf.int/wiki/download/attachments/3473437/gri

b_api-1.10.0.tar.gz?api=v2

# tar xvfz grib_api-1.10.0.tar.gz\?api\=v2

# cd grib_api-1.10.0

# ./configure --with-jasper=/usr/local/lib --with-

netcdf=/usr/local/lib

# make

# make install

# cd ..

Ora che la macchina virtuale con Blender è pronta, come mostrato nella figura

successiva, non resta che instaziarla all’interno di una piattaforma Cloud. Nel prossimo

paragrafo sono mostrati i passi da compiere per farlo su una Cloud gestita con

OpenNebula, che è una di quelle che ho utilizzato in questo lavoro di tesi.  

Figura 7.1 - Template della VM con Blender    

Appendice  1 75  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

7.2. Istanziazione della Macchina Virtuale

L’istanziazione di una VM si basa su tre aspetti: l’immagine, il template ed infine la

VM stessa. Prima di tutto, si crea l’immagine; nel nostro caso vogliamo che non sia

persistent dato che dovrà essere istanziata e distrutta dall’adaptor JSAGA per OCCI (v.

Capitolo 6).

Ho quindi eseguito i seguenti comandi di OpenNebula:

# one image create —name “<nome>” —path “<path>” —type OS —driver

“qcow2” — datastore default

# oneimage clone 133 Nome

La figura successiva mostra le impostazioni dell’ìmmagine creata che si ottengono con

il comando:

# oneimage show 133  

Figura 7.2 - Immagine della VM

 

Ho quindi creato la VM, istanziando il template definito in precedenza:

# onetemplate instantiate 4713 —name blender_server    

Appendice  1 76  

   

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

e l’ho visualizzata con il comando:

# onevm list  

Figura 7.3 – Lista dele VM contenente quella creata per Blender    

Appendice  1 77  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

     

Appendice  1 78  

   

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

 

8. Appendice 2

In questa Appendice sono riportati, per completezza d’informazione, i passi che ho

seguito e documentato, in modo che possano essere utili ad altri dopo di me, per la

creazione dell’ambiente integrato di sviluppo che mi ha permesso di realizzare il

software descritto nel Capitolo 6.

8.1. Configurazione dell’ambiente di sviluppo di Liferay

  8.1.1. Installazione della distribuzione

“bundle” di Liferay

 

Inizialmente, ho scaricato il file “Liferay Bundle 6.1.1-ce-

ga2 for Glassfish” da

http://www.liferay.com/downloads/liferay-portal/available-

releases e l’ho compresso con gzip in una cartella a mia scelta.

Ho così definito la variabile $LIFERAY_HOME, come percorso della cartella

contenente il mio bundle, con il seguente comando:

# Export LIFERAY_HOME=/Users/marcozennaro/Desktop/liferay-portal-

6.1.1-ce-ga2

ed ho configurato il permesso eseguibile a tutti i file binary contenuti nella cartella

“glassfish” con:

# chmod +x glassfish-3.1.2/bin/*

Ho dunque fatto partire il “domain” usando il seguente comando:

# $LIFERAY_HOME/glassfish-3.1.2/bin/asadmin start-domain domain1

ricevendo come output il seguente messaggio:

# $LIFERAY_HOME/glassfish-3.1.2/bin/asadmin start-domain domain1

Waiting for domain1 to start ......

Successfully started the domain : domain1

domain Location: /Users/Macbook/Downloads/liferay-portal-

6.1.1ce-ga2/glassfish-3.1.2/domains/domain1

Log File: /Users/Macbook/Downloads/liferay-portal-6.1.1-ce-

ga2/glassfish-3.1.2/domains/domain1/logs/server.log

Admin Port: 4848

Command start-domain executed successfully.          

 

Appendice  2 79  

 

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

Infine, ho aperto una finestra del browser alla pagina http://localhost:8080/ (questa

procedura prende del tempo durante la prima connessione perchè il sistema riempie la

cache del web browser) ed ho ottenuto la seguente schermata.

   

Figura 8.1 – Pagina ottenuta alla fine della configurazione iniziale

 

Premendo il bottone Finish Configuration, in basso a sinistra, viene generato il file di

configurazione del portale:

/Users/marcozennaro/Desktop/liferay-portal-6.1.1-ce-ga2/portal-setup-

wizard.properties

e mostrata la seguente schemata.  

Figura 8.2 - Generazione del file "setup-wizard.properties"

 

Ho quindi premuto il bottone Procedi al Mio Portale, accettato le condizioni di utilizzo

         

 

Appendice  2 80  

 

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

e scelto la nuova password con la relativa domanda per il recupero della stessa. Dopo

qualche istante, infine, sono stato reindirizzato alla Home Page di Liferay che è così

diventato il mio Science Gateway personale. I passi sono mostrati nelle due figure

seguenti.  

Figura 8.3 – Condizioni di utilizzo e Privacy

   

Figura 8.4 - Impostazione domanda segreta personale

 

Durante tutta la procedura è possibile, ed altamente consigliato, esaminare i log di

Liferay con il comando:

# tail -f

$LIFERAY_HOME/glassfish3.1.2/domains/domain1/logs/server.log          

 

Appendice  2 81  

 

   

Marco  Zennaro  |  “Rendering-­‐as-­‐a-­‐Service”  su  Cloud  

 

   

  8.1.2. MySQL – Installazione e configurazione (Mac Os X)

 

N.B. (Nel caso si abbia già un server MySQL nel proprio computer, è possibile

saltare questo passo verificando che la versione sia comunque inferiore alla 5.6

che è quella attualmente richiesta dal Catania Science Gateway Framework).

Prima di tutto, ho installato un server MySQL da http://dev.mysql.com/downloads/.

   

Figura 8.5 - Installazione MySQL

Le istruzioni sono disponibili dentro il file README.txt. Ho selezionato il file DMG

ed eseguito i due pacchetti da terminal.app  

Figura 8.6 - File "DMG" MySQL

Ho quindi eseguito il comando:

# sudo /Library/StartupItems/MySQLCOM/MySQLCOM start

e ho aggiornato la variable $PATH:

# export PATH=$PATH:/usr/local/mysql/bin  

Figura 8.7 - Start di MySQLCOM          

 

Appendice  2 82  

 

   

Marco   Z ennaro   |   “ Rendering-­‐as-­‐a-­‐Service”   s u   C loud  

 

   

 

 

Come mostrato nella figura precedente, ho quindi fatto partire il servizio:

# sudo /Library/StartupItems/MySQLCOM/MySQLCOM start

# Password: ********

Starting MySQL database server  

Figura 8.8 - Start di MySql server

ed ho generato il file :

portal-ext.properties

# cat <<EOF > $LIFERAY_HOME/portal-ext.properties

# jdbc.default.driverClassName=com.mysql.jdbc.Driver

# jdbc.default.url=jdbc:mysql://localhost/lportal?useUnicode=true&

characterEncoding=UTF-8&useFastDateParsing=false

# jdbc.default.username=liferayadmin

# jdbc.default.password=liferayadmin

# EOF  

Figura 8.9 - Generazione del file "portal-ext.properties"

A questo punto, ho creato il database necessario a Liferay.

# mysql -u root

CREATE USER 'liferayadmin' IDENTIFIED BY 'liferayadmin';

CREATE DATABASE lportal;

GRANT ALL PRIVILEGES ON lportal.* TO '

liferayadmin'@'localhost' IDENTIFIED BY 'liferayadmin';  

Figura 8.10 - Creazione Database Liferay

Ho poi scaricato mysql-connector da

http://sourceforge.net/projects/ctsciencegtwys/files/catania-grid-engine/1.4.21/mysql-

connector-java-5.1.13.jar/download e l’ho copiato in $LIFERAY_HOME/glassfish-

         

 

Appendice  2 83  

 


PAGINE

93

PESO

9.63 MB

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in informatica
SSD:
Università: Catania - Unict
A.A.: 2014-2015

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher redscorpion88 di informazioni apprese con la frequenza delle lezioni di Computer Graphics e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Catania - Unict o del prof Gallo Giovanni.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Corso di laurea in informatica

Analisi numerica - Appunti
Appunto
Calcolo Combinatorio
Appunto
Matrici e sistemi lineari teoria ed esercizi parte 2
Appunto
Matrici e sistemi lineari teoria ed esercizi parte 1
Appunto