D6.2 Test e report relativi all integrazione della soluzione completa e collaudo MiddleWare

Transcript

1 D6.2 Test e report relativi all integrazione della soluzione completa e collaudo MiddleWare Architettura Scheda grafica NICE DCV Enginframe Schedulatore Linux Schedulatore Windows Middleware Orchestrator Cistern Daemons Loops Cooks Piattaforma di autenticazione OpenLDAP Il dominio Windows (Samba) La share dei dati L integrazione con OpenStack CloudInit CloudBase Init Riferimenti documentazione tecnica Riferimenti ai test Configurazione hardware e software Use Case Windows Test Use Case Linux Test Architettura Scheda grafica Nel parlare di 3D cloud dobbiamo sottolineare il fatto che le macchine virtuali devono necessariamente essere connesse in qualche modo ad un hardware dedicato e ad una scheda grafica professionale tale da permettere l esecuzione di codice OpenGL. Per il dimostratore è stata utilizzata una scheda video NVIDIA Quadro 2000, una scheda grafica professionale di fascia media, tale da permettere il Pass Through tramite XenServer. quadro 2000 it.html

2 NICE DCV Come ipotizzato in fase di studio della visualizzazione 3D in ambito cloud (D3.1) si è seguito un approccio misto di virtualizzazione della GPU. La scheda grafica è stata collegata fisicamente alla macchina nel quale l hypervisor XenServer è in esecuzione e, tramite Pass Through, la scheda grafica è stata esportata in una macchina virtuale linux. Questa macchina virtuale linux, che nel seguito chiameremo dcvrend, è stata utilizzata sia come Rendering Server per gli Application Host Windows, sia in modalità Display Isolation per le applicazioni Linux, secondo lo schema sottostante. Le modalità di utlizzo di DCV sono state spiegate nel dettaglio nel D3.1. Figura 1. Architettura NICE DCV Enginframe EnginFrame è stato installato in una macchina Linux di front end che chiameremo nel seguito pia fe, nella quale sono stati installati anche i master degli schedulatori windows e linux. Schedulatore Linux I prodotti analizzati sono stati selezionati fra i più diffusi e apprezzati schedulatori disponibili. La selezione era composta dai seguenti prodotti: Openlava, SLURM, Torque (software open source); Platform LSF, Oracle Grid Engine, PBS Professional (software commerciali).

3 I componenti del reparto Ricerca e Sviluppo dell azienda NICE s.r.l. vantano una notevole esperienza pluriennale nell utilizzo dello schedulatore Platform LSF. La scelta sarebbe ricaduta su questo, ma il fatto che non fosse open source e quindi con costi di utilizzo non nulli hanno fatto sì che venissero analizzate altre proposte. E stato scelto openlava in quanto rappresenta la più vicina alternativa open source allo schedulatore Platform LSF: utilizza le stesse convenzioni e i comandi per la gestione dei job o degli host ed è supportato in maniera efficiente da EnginFrame. E stato installato il master nella macchina linux nella quale abbiamo installato EnginFrame, pia fe e l agent nella macchina virtuale linux nella quale le sessioni virtuali devono partire. Schedulatore Windows Come schedulatore per le sessioni interattive la scelta era limitata ai seguenti Scheduler: Platform LSF, Oracle Grid Engine, PBS Professional (software commerciali). Tutti gli schedulatori supportati da EnginFrame erano commerciali e si è scelta quindi la via dell utilizzo di uno schedulatore windows in fase prototipale sviluppato internamente in NICE, tale da permettere l avvio e la gestione di sessioni grafiche in macchine Windows. E stato installato il master nella macchina linux nella quale abbiamo installato EnginFrame, pia fe e l agent nel template della macchina virtuale windows nella quale le sessioni grafiche devono partire. Middleware Il Middleware si compone di tre blocchi logici: orchestrator cistern daemons Oltre a questo è stato necessario introdurre una parte di autenticazione centralizzata per le varie componenti attraverso l'utilizzo di software ed interfacce standard. Orchestrator Orchestrator e' un'interfaccia REST che crea un livello di astrazione per poter comunicare con diversi cloud provider usando un unico dialetto. Cistern Cistern e' un'interfaccia REST che gestisce la persistenza delle informazioni di stato delle risorse e quindi quali cloud provider sono abilitati, quante e quali risorse sono a disposizione. Cistern si occupa quindi di gestire anche le interfacce con cui richiedere le informazioni ed effettuare modifiche di stato quali abilita vm, rilascia vm.

4 Daemons I demoni sono i programmi che gestiscono la logica di funzionamento dell'architettura. Date le necessita' di implementazione e' stato richiesto che il Middleware possa gestire un buffer di VM da tenere sempre attive in modo da avere delle VM sempre reattive. Permutando dal gergo di OpenStack, i demoni sono stati chiamati: loops cooks Loops Lo scopo del demone Loops e' quello di tenere sincronizzati gli ambienti cloud abilitati con le risorse memorizzate nel database, in questo modo verranno aggiornate le informazioni legate a images / tenants/ nodes / flavors e usages. Loops, interrogando Orchestrator, riconosco lo status dei vari cloud configurati ed itera su queste informazioni le routine di aggiornamento sul database. Loops si occupa anche di registrare le transizioni di stato delle VM, quando riconosce che una VM e' libera / assegnata / rilasciata / cancellata o genericamente passa da uno stato all'altro registra l'informazione sul database. Cooks Il demone Cooks e' usato per fare azioni sulle VM e quindi rispecchiare eventualmente lo status nel database. Lo scopo del demone e' di tenere vivo il numero minimo di Virtual Machines in modo da avere un accesso rapido a particolari applicazioni computazionalmente onerose. L'insieme di applicazione, numero minimo di VM, flavor ed image e' chiamato recipe. Il demone Cooks legge le recipes memorizzate nel database ad intervalli di tempo impostati come CHECK_CLOUD_POOL_NAPPING_TIME e verifica tramite Orchestrator e Cistern se ci sono sufficienti VM libere attive, in caso non ce ne fossero provvede ad avviarne secondo le indicazioni delle recipes. Piattaforma di autenticazione Allo scopo di fornire una piattaforma unica per l autenticazione degli utenti all interno del sistema si è scelto di utilizzare un servizio che fosse supportato direttamente, o tramite dei servizi intermedi, da tutti i componenti. La scelta è ricaduta su OpenLDAP che consente di autenticare:

5 gli utenti del portale, sia direttamente che configurando il server che lo ospita attraverso PAM ed utilizzando l autenticazione del server come base per quella web; gli utenti dei sistemi linux, configurando le immagini delle vm per la visualizzazione remota per fornire l autenticazione tramite openldap gli utenti windows, configurando un server di dominio windows con backend su OpenLDAP e configurando le immagini delle vm per la visualizzazione remota per autenticarsi su questo dominio; i job batch che eseguono la parte di calcolo che produce i risultati da utilizzare nella visualizzazione. OpenLDAP OpenLDAP è un implementazione del protocollo LDAP (Lightweight Directory Access Protocol), libera e rilasciato sotto la propria licenza opensource OpenLDAP Public License. Oltre ad essere ampiamente supportato da tutte le distribuzioni linux è anche uno dei meccanismi di autenticazione più diffusi e supportati, il che ne fa la scelta ideale per la realizzazione di un sistema di autenticazione centralizzato. Il dominio Windows (Samba) Allo scopo di rendere possibile un autenticazione centralizzata valida anche per le VM windows si è scelto di creare un dominio Windows che si appoggiasse al server openldap per l autenticazione. Per realizzarlo è stato necessario utilizzare Samba, un software libero ed opensource che implementa il protocollo SMB/CIFS di Microsoft e che supporta ldap come backend per l autenticazione. Infatti, a partire dalla versione 3 del software, è possibile configurarlo come Primary Domain Controller (PDC) di un dominio windows, per permettere alle macchine client di effettuare il join e l autenticazione sul dominio. La share dei dati Una delle necessità emerse nel corso del progetto è stata quella di permettere l accesso ai dati da parte degli utenti indipendemente dalla VM su cui si effettua l accesso. Per sodddisfare questa necessità sono state create delle share condivise linux/windows sul server centrale, integrate con la piattaforma di autenticazione. Sul fronte windows è stato sufficiente utilizzare i profili di windows resi disponibili da samba tramite CIFS. Su quello linux è stata configurata una condivisione NFS che i client rendono disponibile agli utenti al momento del boot della macchina virtuale. Tramite questo sistema anche i dati risultati dalle

6 sessioni di calcolo batch sono immediatamente disponbili agli utenti nelle sessioni interattive, indifferentemente che esse siano windows o linux. L integrazione con OpenStack OpenStack rende disponibile il servizio di metadata per permettere di configurare le macchine virtuali al boot. Tramite questo servizio è possibile far arrivare delle configurazioni alle VM in fase di avvio della VM permettendo la personalizzazione al volo di un template anonimo. Questo sistema è stato usato per fare in modo che le VM avessero un nome univoco assegnato dal MW ed utilizzato dal portale. Sulle macchine windows sono stati creati dei moduli per il servizio che si occupa di recuperare i metadati che permettono alle vm di integrarsi con il dominio SAMBA. CloudInit CloudInit è un pacchetto disponibile nelle principali distribuzioni linux che si occupa dell inizializzazione di un template linux. Le sue principali funzioni sono: settare la localizzazione settare l hostname generare le chiavi ssh Il servizio è sviluppato sotto forma di moduli per cui, oltre alle funzioni di base, è possibile estenderne la funzionalità tramite la scritture di nuovi plugin. CloudBase Init CloudBase Init è un servizio che replica nell ambiente windows quanto fatto da clouinit su linux. Anche in questo caso il software è possibile aggiungere nuove funzionalità tramite la scrittura di moduli da integrare nel servizio. Nel nostro caso specifico oltre a quelli forniti di base, come il cambio di hostname, sono stati creati due moduli aggiuntivi: il primo che effettua il join delle VM al dominio, rendendo disponibili le share e l autenticazione centralizzata; il secondo che rende disponbile la VM solo al termine della procedura di inizializzazione della macchina, evitando che possa essere usata dal portale prima del termine della stessa. Riferimenti documentazione tecnica

7 Per la documentazione tecnica, la descrizione implementativa, i test, il funzionamento e l'installazione dei moduli riferirsi alla documentazione generata ed allegata nel pacchetto wp_2.7.zip Riferimenti ai test Per la documentazione tecnica, la descrizione implementativa, i test, il funzionamento e l'installazione dei moduli riferirsi alla documentazione generata ed allegata nel pacchetto wp_2.7.zip Configurazione hardware e software E possibile visualizzare lo schema complessivo nella figura seguente. Figura 2. Architettura completa Come si può notare la Cloud è formata quindi dalla macchina virtuale di front end nella quale è stato installato EnginFrame e gli schedulatori, una macchina virtuale Linux configurata per utilizzare la scheda grafica sottostante tramite PassThrough, e un set di macchine virtuali Windows variabili configurate per utilizzare la macchina virtuale Linux come rendering server. Per il dimostratore è stata una sola scheda grafica e quindi è stata utilizzata una sola macchina virtuale linux, che grazie all utilizzo di display X virtuali e la display isolation garantisce l accesso contemporaneo a più utenti. Con più schede grafiche a disposizione si

8 può andare ad incrementare il numero di macchine virtuali linux utilizzate come Rendering Server e garantire un accesso ad un numero maggiore di utenti. Il numero di macchine virtuali windows è invece limitato per tipo sulla base di una configurazione effettuata a livello di middleware, tale da garantire un numero minimo di macchine sempre in esecuzione. Per l integrazione della soluzione completa e del dimostratore è stato utilizzato un cluster di macchine virtuali gestito dal CRS4, che consiste di: una macchina virtuale linux, nella quale è stato installato EnginFrame e i master degli schedulatori windows e linux, utilizzata quindi come front end IP: , hostname: pia fe una macchina fisica linux, nella quale è stato installato l hypervisor Xen e alla quale è stata collegata una scheda grafica NVIDIA Quadro 2000 IP: , hostname: render.crs4.it una macchina virtuale linux, installata sull hypervisor Xen, configurata per utilizzare la scheda video sottostante in modalità Pass Through, utilizzata come DCV Rendering Server e nella quale è stato installato l agent dello schedulatore linux IP: , dcvrend un set di macchine virtuali windows, utilizzate come DCV Application Host, istanziate a seconda delle necessità a partire da un template opportunamente configurato, con l agent dello schedulatore Windows e il CloudAgent IPs: x Use Case Windows Riportiamo un Use Case completo: L utente, sulla base delle operazioni che intende compiere, sulla base dei dati da analizzare, da visualizzare, selezionerà tramite portale l applicativo 3D Windows da avviare. Al click dell utente EnginFrame eseguirà un servizio e quindi una serie di script atti a creare una sessione grafica interattiva, nella quale possa essere eseguito l applicativo 3D selezionato. Il CloudAgent comunicherà al middleware i dati relativi alla macchina prenotata per la sessione interattiva, notificando in questo modo l avvenuta occupazione della macchina. Il middleware si occuperà di gestire il firewall in modo tale che l utente possa connettersi ad essa tramite una sessione grafica 3D, aprendo quindi le porte necessarie al funzionamento del visualizzatore remoto. Verrà fornito all utente un metodo di accesso alla macchina (file di connessione) e l utente potrà loggarsi ed utilizzare l applicativo selezionato. Successivamente alla notifica di occupazione della macchina virtuale, il middleware eseguirà le operazioni necessarie a garantire che il buffer delle macchine virtuali rimanga costante. La sessione grafica deve poter essere condivisa con altro utente

9 La sessione deve poter essere chiusa correttamente, tramite chiusura esplicita o logout dell utente, il CloudAgent comunicherà al middleware l avvenuto rilascio della macchina. La macchina virtuale viene distrutta Test L use case illustrato precedentemente è stato testato prima nelle sue singole parti, come illustrato nei D3.4 e D3.7, e poi nel suo insieme. E stato verificato che: Al click dell utente su un servizio interattivo, venisse avviata la corrispondente sessione su una macchina Windows > OK Una volta avviata la sessione interattiva il CloudAgent deve notificare l occupazione della macchina al middleware CRS4 Per effettuare questo test il team HPCN del CRS4 è rimasto in ascolto sui log del middleware, verificando che all avvio della macchina venisse inviato il corretto messaggio tramite web services > OK Effettuata la notifica vengono aperte le porte nel firewall e viene scaricato automaticamente dal portale EnginFrame un file di connessione.vnc > OK Nel file di connessione deve essere riportato l ip relativo alla macchina nella quale la sessione interattiva sta girando, grazie all aggiornamento automatico del file di configurazione di EnginFrame, nat.conf (vedi problematiche esposte in D3.6) > OK L utente può loggarsi nella macchina e l applicativo selezionato viene eseguito automaticamente dopo il login > OK L utente tramite portale può condividere la sessione con altri utenti > OK Un altro utente una volta condivisa la sessione può ricevere il file di connessione tramite portale e lavorare nella stessa sessione > OK Il middleware, dietro le quinte deve mantenere il buffer di macchine disponibili costante, avviando una nuova macchina appena notificata l occupazione Per visualizzare questo risultato è sufficiente andare nel servizio EnginFrame dove vengono elencati gli host windows disponibili > OK Una volta chiusa la sessione interattiva il CloudAgent deve notificare il rilascio della macchina al middleware CRS4 Per effettuare questo test il team HPCN del CRS4 è rimasto in ascolto sui log del middleware, verificando che alla chiusura della sessione venisse inviato il corretto messaggio tramite web services > OK Sono stati effettuati numerosi test, con utenze diverse e per tutte le applicazioni rese disponibili lato portale: Paraview (Windows) > OK VisIt (Windows) > OK JT2Go (Windows) > OK

10 Use Case Linux Riportiamo un Use Case completo: L utente, sulla base delle operazioni che intende compiere, sulla base dei dati da analizzare, da visualizzare, selezionerà tramite portale l applicativo 3D Linux da avviare. Al click dell utente EnginFrame eseguirà un servizio e quindi una serie di script atti a creare una sessione grafica interattiva, nella quale possa essere eseguito l applicativo 3D selezionato. Verrà fornito all utente un metodo di accesso alla macchina (file di connessione) e l utente potrà loggarsi ed utilizzare l applicativo selezionato. La sessione grafica deve poter essere condivisa con altro utente. La sessione deve poter essere chiusa correttamente, tramite chiusura esplicita o logout dell utente. Test L use case illustrato precedentemente è stato testato prima nelle sue singole parti, come illustrato nel D3.4 e poi nel suo insieme. E stato verificato che: Al click dell utente su un servizio interattivo, venisse avviata la corrispondente sessione su una macchina Windows o sulla macchina Linux a seconda del tipo di applicativo selezionato > OK viene scaricato automaticamente dal portale EnginFrame un file di connessione.vnc > OK Nel file di connessione deve essere riportato l ip relativo alla macchina nella quale la sessione interattiva sta girando > OK L utente può loggarsi nella macchina e l applicativo selezionato viene eseguito automaticamente dopo il login > OK L utente tramite portale può condividere la sessione con altri utenti > OK Un altro utente una volta condivisa la sessione può ricevere il file di connessione tramite portale e lavorare nella stessa sessione > OK La sessione viene chiusa correttamente > OK Sono stati effettuati numerosi test, con utenze diverse e per tutte le applicazioni rese disponibili lato portale: Paraview (Linux) > OK Accelrys (Linux) > OK Seeg Viewer (Linux) > OK