D3.6 Documento illustrante le metodologie di interfacciamento tra il Portale di visualizzazione remota 3D e il MiddleWare. Architettura Client WS Configurazione Utenti Schedulatori Hosts Template Windows Moduli di interfaccia API Web Services Middleware Status Assign Release CloudAgent CloudAgent.exe CloudAgent.bat Trigger Architettura Nel D1.3 sono state effettuate delle scelte architetturali, che all avanzare del progetto sono state riviste e adattate, in seguito a numerosi test e valutazioni e sulla base delle esigenze implementative. I componenti dell architettura sono rimasti gli stessi, ma la parte di interfacciamento tra il Middleware sviluppato dal CRS4 ed EnginFrame è stata oggetto di revisione. Nell architettura precedente erano state riportate delle sezioni Physical Win e Physical Linux che sono state eliminate in quanto non attinenti all ambito Cloud. Nella figura seguente viene illustrata l architettura definitiva.
Figura 1. Architettura definitiva Client WS Era stata ipotizzata la creazione di un plugin per EnginFrame che si occupasse di comunicare con l orchestrator tramite chiamate Web Services, ma questo componente è stato spostato, andandolo ad inserire all interno delle macchine virtuali stesse nelle quali viene eseguito l applicativo 3D. Questa scelta è stata attuata in seguito a valutazioni relative alla gestione della Rete e soprattutto del Firewall. Per garantire che le porte del firewall verso una data macchina vengano aperte è stato realizzato da NICE un componente software, chiamato CloudAgent che, una volta avviata la sessione, si occupa di notificare al Middleware l avvenuta occupazione della macchina. Il Middleware del CRS4 una volta ricevuta questa notifica si occupa di aprire le porte del firewall necessarie e scatenare tutti i meccanismi tali da garantire che il buffer di macchine disponibili di un certo tipo rimanga costante. Allo stesso modo in fase di chiusura il CloudAgent notificherà al middleware l avvenuta chiusura della sessione interattiva in modo da effettuare lo spegnimento della macchina virtuale non più utilizzata. Configurazione Il blocco relativo alla configurazione è stato spostato all interno del Middleware. Esistono chiaramente numerosi parametri di configurazione anche lato EnginFrame ma si è pensato di tenere separate le due gestioni, in modo tale che il middleware potesse essere
configurato arbitrariamente, tenendo indipendenti il più possibile i due componenti architetturali. Utenti Un punto importante è stata la gestione degli utenti, in quanto era necessario che tutti i componenti fossero accessibili e abilitati per uno stesso utente. Un utente in grado di loggarsi nel portale e avviare una sessione deve essere in grado di potersi loggare all interno delle macchine virtuali Windows e Linux all interno di CloudStack. Per fare ciò è stato scelto il protocollo LDAP (Lightweight Directory Access Protocol). NICE si è occupata di configurare opportunamente EnginFrame in modo tale che gli utenti registrati in LDAP fossero in grado di loggarsi nel portale, avviare servizi, sessioni interattive e poter gestire job e sessioni. Il CRS4 si è occupato della gestione dell LDAP, dell interfacciamento con il middleware e della configurazione di Samba nei template delle macchine virtuali. E stato realizzato dal CRS4 uno script per l inserimento e la rimozione di un utenza nell ambiente LDAP e in Samba, in modo tale da permettere a NICE di poter effettuare test in piena autonomia. In una possibile evoluzione del progetto sarebbe possibile creare degli ulteriori servizi Web, per poter gestire gli utenti tramite portale EnginFrame. Schedulatori I master degli schedulatori sono stati installati nella VM Linux dove è stato installato EnginFrame. Tale VM di front end è totalmente indipendente dal Middleware. Hosts Linux, grazie alla possibilità di utilizzare più display virtuali in una stesse macchine permette l accesso di più utenti contemporanei ad una stessa macchina e quindi la condivisione dell hardware grafico. Per il dimostratore è stata utilizzata una VM Linux per le sessioni interattive Linux, connessa in Pass Through alla scheda grafica Nvidia. Windows invece, per le limitazioni date dal sistema operativo stesso, permette l accesso alla macchina di un solo utente per volta, l hardware grafico non può quindi essere condiviso tra più utenti. Per questo motivo lato Windows dovremo necessariamente avere a disposizione un set di macchine virtuali pronte all uso. Template Windows In collaborazione con il CRS4 è stato realizzato un template per le macchine virtuali Windows, tale da contenere gli applicativi 3D da utilizzare, lo schedulatore Windows opportunamente configurato per dialogare con il master, NICE DCV configurato in modalità External Rendering Server e il Cloud Agent.
Moduli di interfaccia API Web Services Middleware Il CRS4 si è occupato di realizzare un interfaccia Web Service al middleware, fornendo a NICE una guida sul loro utilizzo. Le operazioni fornite sono: status, start e stop delle vm e assign e release delle VM. Le operazioni di start e stop sono state utilizzate solo in fase di testing ma non sono state necessarie all integrazione, in quanto lo start e stop delle vm viene effettuato in maniera automatica dal Middleware sulla base dell assegnazione o del rilascio delle varie risorse. L operazione di status è necessaria per conoscere lo stato attuale delle risorse e poterlo comunicare ad EnginFrame. Riportiamo quindi la docmentazione relativa alle tre operazioni utilizzate per l interfacciamento: status, assign e relase. Status L operazione di status restituisce la lista dei nodi in formato JSON. $ http pretty all jv GET http://localhost:5050/api/v1/nodes/fake_driver GET /api/v1/nodes/fake_driver HTTP / 1.1 Accept : application/json Accept Encoding : gzip, deflate, compress Content Type : application/json; charset=utf 8 Host : localhost:5050 User Agent : HTTPie/0.6.0 HTTP / 1.0 200 OK Content Length : 683 Content Type : application/json Date : Wed, 17 Jul 2013 14:10:00 GMT Server : Werkzeug/0.9.1 Python/2.7.3 Set Cookie : session=eyjfawqionsiigiioijpv0pqtjjnevl6zgtargt6tudka1l6rmloemc0tldsa04yvtbar1pptudfpsj9fq. BMg3OA.z7nyaFmlhMHCDVhHixgJ3ssSmD0; HttpOnly; Path=/ "nodes" : [ "cloud_type" : "Dummy Node Provider", "extra" : "foo" : "bar", "id" : "1", "name" : "dummy 1", "private_ips" : [], "provider" : "dummy", "public_ips" : [ "127.0.0.1" ], "state" : 0,
"uuid" : "2c183c20f71eb5732512d6cfe1f75ebc9d9bb4dd", "cloud_type" : "Dummy Node Provider", "extra" : "foo" : "bar", "id" : "2", "name" : "dummy 2", "private_ips" : [], "provider" : "dummy", "public_ips" : [ "127.0.0.1" ], "state" : 0, "uuid" : "46ff62f5eafc7837de6ec1450b8e0e608db06d7a" ], "status" : "ok" Assign L operazione di assign comunica al Middleware che una data macchina virtuale è occupata per una sessione interattiva, di un dato utente. $ http pretty all jv PUT http://localhost:5050/api/v1/vm/action/assign/fake_driver 'node=fake_id' 'user=fake_user' 'vm_type=app_name' 'emulate=true' PUT /api/v1/vm/action/assign/fake_driver HTTP / 1.1 Accept : application/json Accept Encoding : gzip, deflate, compress Content Length : 82 Content Type : application/json; charset=utf 8 Host : localhost:5050 User Agent : HTTPie/0.6.0 "emulate" : "True", "node" : "fake_id", "user" : "fake_user", "vm_type" : "app_name" HTTP / 1.0 200 OK Content Length : 95 Content Type : application/json Date : Wed, 17 Jul 2013 14:10:03 GMT Server : Werkzeug/0.9.1 Python/2.7.3 Set Cookie : session=eyjfawqionsiigiioijpv0pqtjjnevl6zgtargt6tudka1l6rmloemc0tldsa04yvtbar1pptudfpsj9fq. BMg3Ow.NHVGqWYWe JCpT p4srxcue8quo; HttpOnly; Path=/ "id" : 42, "id_vm" : " fake_id ", "result" : "Node fake_id assigned", "status" : "ok"
Release L operazione di release comunica al Middleware che una data macchina virtuale non è più occupata per una sessione interattiva. $ http pretty all jv PUT http://localhost:5050/api/v1/vm/action/release/fake_driver 'node=fake_id' 'emulate=true' PUT /api/v1/vm/action/release/fake_driver HTTP / 1.1 Accept : application/json Accept Encoding : gzip, deflate, compress Content Length : 38 Content Type : application/json; charset=utf 8 Host : localhost:5050 User Agent : HTTPie/0.6.0 "emulate" : "True", "node" : "fake_id" HTTP / 1.0 200 OK Content Length : 95 Content Type : application/json Date : Wed, 17 Jul 2013 14:10:04 GMT Server : Werkzeug/0.9.1 Python/2.7.3 Set Cookie : session=eyjfawqionsiigiioijpv0pqtjjnevl6zgtargt6tudka1l6rmloemc0tldsa04yvtbar1pptudfpsj9fq. BMg3PA.03Np9fxYe7Znqz1iyfzKL0CHJg0; HttpOnly; Path=/ "id" : 42, "id_vm" : " fake_id ", "result" : "Node fake_id assigned", "status" : "ok" CloudAgent Il modulo software denominato CloudAgent è stato sviluppato in NICE in modo tale da avere un client Web Services all interno delle macchine virtuali, in grado di comunicare con i Web Services esposti dal middleware e notificare quindi la partenza e la chiusura di una sessione interattiva 3D. CloudAgent.exe Il CloudAgent è un eseguibile realizzato in C#. E stato dotato di un interfaccia via commandline tale da permettere il passaggio di parametri quali l url dell web service da contattare, l operazione che si sta eseguendo, il tipo della vm e l hostname e altri parametri utili, elencati di seguito. C:\Users\enrico\Desktop>CloudAgent.exe CloudAgent contacts Web Service to assign or release current VM instance to the current logged User.
Options: w, ws=url Web Service Url (Default: http://156.148.14.126:5070) v, version=version Web Service Version (Default: v1) a, action=assign release test Action type assign release test vm f, flavor=flavor Vm type (Flavor) to use i, id=id Vm node id (Default: local hostname) c, cloud=cloud Cloud name (Default: default cloud stack) e, emulate Enable emulation mode n, ntimes=number Number of times to contact Web Service before failing (Default: 5) s, sleep=sleep Sleep time [ms] between runs (Default: 5000 ms) t, timeout=times out Times to wait [ms] before request times out. (Default: 100,000 ms) h, help Show this message and exit Usage: CloudAgent a assign f testox [ c fake_driver] [ i 3c725bdb b575 4e0f b21b 67b0d089867d] [ ws http://156.148.14.126:5070] [ v v1] [ e] CloudAgent a release [ c fake_driver] [ i win_01] [ ws http://156.148.14.12 6:5070] [ v v1] [ e] Le operazioni utilizzate tramite CloudAgent sono chiaramente quella di assign e quella di release, utili a comunicare al middleware l assegnazione o il rilascio di una data macchina virtuale. CloudAgent.bat Per utilizzare in maniera ottimale il CloudAgent all interno dell ambiente Interactive di EnginFrame è stato realizzato uno script batch contenente le due funzioni di assign e di release. Questo script è stato installato nel template delle macchine virtuali. @echo off goto :EOF :cloudassign call :log_debug "%SCHEDULER_HOME%\CloudAgent.exe" a assign f nice ws http://156.148.14.126:5070 v v1 ver >NUL 2>NUL "%SCHEDULER_HOME%\CloudAgent.exe" a assign f nice ws http://156.148.14.126:5070 v v1 IF NOT "%ERRORLEVEL%" == "0" ( call :log_error Command CloudAgent.exe a assign Failed echo "Failed" > "%SCH_TASK_WD%\cloudfailedwatchdog.txt" echo "Stopped" > "%SCH_TASK_WD%\watchdog.txt" goto :exit ) goto :EOF :cloudrelease IF NOT EXIST "%SCH_TASK_WD%\cloudfailedwatchdog.txt" ( call :log_debug "%SCHEDULER_HOME%\CloudAgent.exe" a release ws http://156.148.14.126:5070 v v1 >NUL 2>NUL ver >NUL 2>NUL "%SCHEDULER_HOME%\CloudAgent.exe" a release ws http://156.148.14.126:5070 v v1 >NUL 2>NUL
IF NOT "%ERRORLEVEL%" == "0" ( call :log_error Command "CloudAgent.exe a release" Failed ) ) goto :EOF A parte una serie di comandi utili alla gestione interna di EnginFrame delle sessioni interattive si può notare come viene richiamato il CloudAgent.exe con i parametri opportunamente settati. In fase di inizializzazione della sessione grafica viene richiamato uno script, che a sua volta tramite un semplice call :cloudassignsi occupa di richiamare la funzione di assign precedentemente definita. In fase di spegnimento viene invece chiamata la funzione di rilascio, tramite un semplice call :cloudrelease. Il tutto è stato testato in maniera graduale, verificando prima il funzionamento dei singoli componenti ed andando ad integrare man mano tutti i moduli. Trigger EnginFrame, andando a contattare gli schedulatori, si occupa di avviare una sessione grafica su una delle macchine disponibili. Lato linux non vi sono problemi particolari in quanto per il dimostratore si è scelto di usare una sola macchina virtuale che è stata aggiunta agli slave dello schedulatore Linux. Lato Windows invece data la necessità di avere un gruppo di macchine virtuali dinamiche è stato necessario creare un meccanismo che permettesse ad EnginFrame di conoscere l IP delle macchine rese disponibili dal Middleware, in modo tale da fornire all utente una connessione diretta verso quella macchina. E stato realizzato quindi un trigger, ovvero un servizio EnginFrame eseguito ciclicamente, ogni 90 secondi, che si occupa di aggiornare EnginFrame riguardo lo stato degli host virtuali. L intervallo di ripetizione selezionato è di 90 secondi in quanto per l avvio di una nuova macchina è necessario un tempo superiore. Tale servizio va ad eseguire uno script che si occupa di contattare il Web Services del middleware, richiedere lo stato del cluster e aggiornare di conseguenza il file di configurazione di EnginFrame contenente la mappatura degli IP delle macchine disponibili nel cluster ( nat.conf ). Il codice del trigger è di seguito riportato. Come si può vedere viene eseguito il servizio update.nat.conf all infinito, ogni 90 secondi. <?xml version="1.0"?> <ef:call service xmlns:ef="http://www.enginframe.com/2000/enginframe" sdf="$ef_root/plugins/piacloud/webapp/piacloud.xml" uri="//piacloud/update.nat.conf" user="$ef_admin" reuse spooler="true"> <ef:trigger type="simple" id="update.nat.conf" group="admin"> <ef:repeat forever/> <ef:repeat interval unit="seconds">90</ef:repeat interval>
</ef:trigger> </ef:call service> Il servizio EnginFrame, accessibile solo internamente, è così costruito: <ef:service id="update.nat.conf" hidden="true"> <ef:name>update nat.conf</ef:name> <ef:action id="submit" label="submit" result="text/xml" output mode="rest"><![cdata[ "$EF_ROOT/plugins/piacloud/bin/update.nat.conf" ]]></ef:action> </ef:service> Come si può notare viene eseguito uno script sh update.nat.conf, riportato nelle righe seguenti. #!/bin/sh _natconf_file="/opt/nice/ef/enginframe/plugins/interactive/conf/nat.conf" echo "dcvrend 156.148.14.45" > $_natconf_file curl s X GET H 'Content Type: application/json' http://156.148.14.126:5070/api/v1/nodes /opt/jsawk/jsawk 'return this.nodes' /opt/jsawk/jsawk 'return name:this.name,public_ip:this.private_ips' /opt/jsawk/jsawk n 'out(this.name,this.public_ip.join(","))' tr d []\" tr "," " " >> $_natconf_file Il flusso è il seguente: 1. viene impostato il percorso del file da aggiornare nella variabile locale _natconf 2. viene inserito nel file l ip della macchina dcvrend, ovvero la macchina linux utilizzata per le sessioni linux e come rendering server per le sessioni windows 3. Viene contattato il web services del middleware chiedendo lo stato del nodo 4. L output JSON ottenuto in risposta dal web service viene analizzato e ne viene effettuato il parsing tramite JSAWK (un tool simile ad awk che permette di parsare in maniera semplice un formato JSON) 5. L insieme degli hostname e degli IP vengono inseriti nel file nat.conf In questo modo siamo sicuri di avere un file di configurazione sempre aggiornato. Nel servizio di monitoraggio degli Host di EnginFrame è possibile avere una lista sempre aggiornata delle macchine disponibili e la mappatura hostname/ip permette ad EnginFrame di poterci avviare delle sessioni grafiche all interno. Riportiamo per completezza un esempio di nat.conf generato. [root@pia fe ~]# cat /opt/nice/ef/enginframe/plugins/interactive/conf/nat.conf dcvrend 156.148.14.45 tbme55qgvxxqp3i 156.148.14.71 v0pmszarj4g7aov 156.148.14.73 2ket1jdvvgj4ex2 156.148.14.69