GRIMD Queue Management

Transcript

1 Università degli Studi di Salerno Facoltà di Scienze Matematiche Fisiche e Naturali Corso di Laurea Magistrale in Informatica Tesina per il corso di Sistemi Operativi II GRIMD Queue Management Gestione code utenti tramite interfaccia web e refactoring architetturale di GRIMD Prof. Giuseppe Cattaneo Gruppo Antonio Balsamo Salvatore Cascone Anno Accademico

2 Indice 1 Introduzione Grid Computing Motivazioni Caso di studio Obiettivi Stato dell arte Risultati Le tecnologie NET Framework Entity Framework Membership Windows Communication Foundation SQL Server Windows Server Internet Information Services Virtual Private Network Refactoring architettura GRIMD Modifiche apportate Sicurezza Requisiti minimi i

3 INDICE ii 4 Struttura del sistema Gestione utenti Base dei dati Servizio di gestione Master Modulo di identificazione Slave Modulo di gestione coda Modulo di controllo di stato del Master Altre modifiche Master FRED e GDUMP Slave Conclusioni 32 Bibliografia 33 A Appendice 34 A.1 Servizio di controllo stato Master A.1.1 IMasterStatus A.1.2 MasterStatus A.2 Servizio di coda A.2.1 IMasterQueue A.2.2 MasterQueue A.2.3 QueueHandler A.3 Servizio identificazione slave A.3.1 IVPNIDResolver A.3.2 VPNIDResolver

4 Capitolo 1 Introduzione 1.1 Grid Computing Al giorno d oggi i sistemi di Grid Computing (Griglia Computazionale) rappresentano una diffusa infrastruttura di calcolo distribuito, utilizzati per l elaborazione di grandi quantità di dati mediante l uso di un grande numero di risorse. Il termine griglia fu coniato nella prima metà degli anni Novanta. Il principale problema alla base del concetto di griglia è la condivisione coordinata di risorse all interno di un organizzazione virtuale. La condivisione non è limitata solo allo scambio dei file, ma si estende all accesso diretto a computer, a software ed in generale a tutto l hardware necessario alla risoluzione di un problema scientifico, ingegneristico o industriale. Gli individui e le istituzioni, che mettono a disposizione della griglia le loro risorse per la medesima finalità, fanno parte della stessa organizzazione. 1.2 Motivazioni Caratteristica comune dei progetti di grid computing è la necessità di disporre un ambiente di calcolo data-intensive, all interno del quale le applicazioni 1

5 CAPITOLO 1. INTRODUZIONE 2 hanno il bisogno di accedere a grandi quantità di dati geograficamente distribuiti in maniera veloce ed affidabile. Compito della griglia è far operare tali applicazioni nel miglior modo possibile. È facile osservare che nessun computer attualmente in commercio sarebbe in grado, da solo, di elaborare moli di dati abbastanza grandi in tempi ragionevoli. Tuttavia la condivisione di risorse quali CPU e dischi opportunamente coordinati può dare l impressione all utente di accedere ad un supercomputer virtuale, con una incredibile potenza computazionale e capacità di memorizzazione in grado di sopportare grandi carichi di lavoro. Tutta l architettura di una griglia, vista come un unico supercomputer virtuale, nasconde una grande complessità interna. Per esempio è importante notare l esigenza di progettare e realizzare uno scheduler di risorse, che rappresenta uno dei componenti critici del sistema di gestione delle risorse. Questo ha il compito di assegnare le risorse ai job, in modo da soddisfare le esigenze delle applicazioni e del sistema. Le risorse di cui esso deve tenere traccia e gestire includono sistemi di calcolo e sistemi di immagazzinamento dati. Lo scheduling è un campo tradizionale dell informatica, ma nonostante siano state studiate molte tecniche per numerose tipologie di sistemi, le caratteristiche tipiche delle griglie di dati rendono molti di questi approcci inadeguati. Infatti, mentre nei sistemi tradizionali le risorse e i job sono sotto il diretto controllo dello scheduler, le risorse delle griglie invece sono geograficamente distribuite. Queste inoltre sono di natura eterogenea e appartengono a diversi individui o organizzazioni, ciascuna con le proprie politiche di scheduling, costi d accesso, carichi di lavoro e disponibilità di risorse che varia dinamicamente nel tempo. La mancanza di un controllo centralizzato, insieme alla presenza di utenti che generano job, molto diversi l uno dall altro, rendono lo scheduling più complicato rispetto a quello dei sistemi di calcolo tradizionali.

6 CAPITOLO 1. INTRODUZIONE Caso di studio Nel corso del documento si discuterà delle modifiche apportate a GRIMD (Grid for Molecular Dynamics), un sistema concepito per effettuare calcolo distribuito tramite l utilizzo di YASARA (Yet Another Scientific Artificial Reality Application) su una griglia di computer, sfruttando la loro potenza di calcolo nei periodi di inutilizzo. L architettura prevede la presenza di una macchina master che coordina il lavoro di un numero indeterminato di slave. Attualmente il sistema è installato su alcune delle macchine presenti nel laboratorio Turing della facoltà di Informatica, nell aula 33 e nel laboratorio di bioinformatica del dipartimento di scienze farmaceutiche e biomediche dell Università degli Studi di Salerno Obiettivi L intento è quello di estendere le capacità di GRIMD ad un ambito più ampio, accademico o aziendale, mantenendo la versione precedente e sviluppando una versione web che consenta l utilizzo di computer appartenenti a diverse subnet, scavalcando i problemi dovuti alla presenza di NAT (Network Address Translation) e che permetta l utilizzo a più utenti contemporaneamente. La versione attuale infatti è stata pensata per un utilizzo ristretto ad un ambito di laboratorio, la nuova versione dovrà invece far operare i computer attualmente disponibili insieme ad altri appartenenti a diversi laboratori. Tali computer sono normalmente inaccessibili dall esterno della propria rete a causa della presenza di servizi come NAT o firewall. La nuova versione dovrà ovviare a questi problemi fornendo un interfaccia web alla quale i vari utenti possano autenticarsi e sottomettere i propri lavori che saranno distribuiti sulla griglia ed eseguiti non appena questa sarà disponibile. Dovrà quindi essere gestita una coda dei vari lavori sottomessi dagli utenti ed eseguirli cercando di utilizzare la massima potenza di calcolo disponibile.

7 CAPITOLO 1. INTRODUZIONE Stato dell arte Uno dei progetti, forse anche il più famoso, che più si avvicina agli argomenti trattati in precedenza è SETI@home (SETI at home) [2], un progetto di calcolo distribuito volontario che usa computer connessi ad internet, ospitato dalla Space Sciences Laboratory all Università della California, Berkeley, negli Stati Uniti d America. SETI è l acronimo di Search for Extra-Terrestrial Intelligence ed il suo scopo è quello di analizzare segnali radio in cerca di segni di intelligenze extraterrestri. Chiunque con un computer connesso ad internet può partecipare a SE- TI@home eseguendo un software gratuito che scarica ed analizza dati provenienti dal radio-telescopio. Il software di calcolo distribuito di SETI@home può essere eseguito sia come screensaver sia mentre l utente è a lavoro, sfruttando la potenza di elaborazione che altrimenti sarebbe inutilizzata. La prima piattaforma software, ora denominata SETI@home Classic [3] è stata utilizzata dal 17 maggio 1999 al 15 dicembre Quest ultima consentiva di eseguire solo SETI@home. Fu sostituito da Berkeley Open Infrastructure for Network Computing (BOINC) [4], il quale permette agli utenti di contribuire anche ad altri progetti di calcolo distribuito contemporaneamente all esecuzione di SETI@home. Un altro famoso progetto di calcolo distribuito è neugrid [5], finanziato dalla Comunità Europea. Il progetto prevede lo sviluppo di un infrastruttura digitale per la ricerca scientifica, basata sul sistema Grid ed è dotata di un interfaccia che permetterà alla comunità di neuroscienziati europei l avanzamento della ricerca per lo studio delle malattie neurodegenerative (come il morbo di Alzheimer). All interno di neugrid, vi è la possibilità di raccogliere ed archiviare un ingente quantità di dati di imaging molecolare e di effettuare analisi computazionalmente impegnative, attraverso il paradigma del calcolo distribuito. Un ricercatore interagisce con neugrid per selezionare un gruppo di immagini da analizzare, usando l algoritmo prescelto. Completata l elaborazione dell immagine sulla griglia, il dato di input viene confrontato al dato di output per verificare il risultato del processo. Questo

8 CAPITOLO 1. INTRODUZIONE 5 viene poi trasferito dall utente in postazione remota per ulteriori eventuali analisi statistiche e visualizzazioni avanzate. 1.5 Risultati Tutti gli obiettivi prefissati sono stati raggiunti con successo. La versione precedente di GRIMD ha dovuto essere modificata allo scopo di permettere tale gestione multiutente. Infatti sono state introdotte alcune componenti aggiuntive ed inoltre è stato necessario anche effettuare un refactoring a livello architetturale per risolvere alcune problematiche che saranno presentate successivamente. Allo stato attuale è disponibile un interfaccia web che permette l accesso al sistema agli utenti autorizzati e fornisce loro la possibilità di sottomettere i lavori che si desidera eseguire. I lavori sottomessi vengono poi gestiti da un apposito servizio di gestione della coda ed eseguiti utilizzando le basi fornite da GRIMD con le opportune modifiche.

9 Capitolo 2 Le tecnologie In questo capitolo saranno mostrate le tecnologie utilizzate durante lo svolgimento del lavoro. Se queste sono già conosciute la lettura del capitolo può essere tralasciata, in quanto si fornirà solamente una panoramica generale e non saranno trattati i dettagli delle varie tecnologie. 2.1.NET Framework Il.NET Framework è un framework software sviluppato dalla Microsoft, destinato ad essere usato dalla maggior parte delle nuove applicazioni create per le piattaforme Windows le quali ne forniscono il pieno supporto. Esso include una vasta gamma di librerie di base, detta Base Class Library (BCL) e fornisce l interoperabilità di linguaggio attraverso i diversi linguaggi di programmazione supportati (cioè ogni linguaggio può utilizzare del codice scritto in altri linguaggi). In particolare nel corso del lavoro sono stati utilizzati i seguenti linguaggi di programmazione.net: C#, linguaggio ad oggetti simile al Java della Oracle Corporation. Visual Basic.NET (abbreviato VB.NET), linguaggio orientato agli oggetti e multi-thread basato sulla sintassi di Visual Basic 6

10 CAPITOLO 2. LE TECNOLOGIE 7 ASP.NET, evoluzione del classico ASP (Active Server Pages), linguaggio di programmazione in ambiente web, implementa.net ed è dotato di librerie.net, anche se non viene considerato un linguaggio vero e proprio poiché può essere scritto utilizzando un qualsiasi altro linguaggio.net. ADO.NET, nuova versione per il.net Framework di ADO (ActiveX Data Objects) BCL fornisce classi per la creazione di interfacce utente, accesso ai dati, connettività a database, crittografia, sviluppo di applicazioni web, algoritmi numerici e comunicazione su rete. I programmatori producono software combinando il loro codice sorgente con BCL ed eventuali altre librerie di terze parti. Tutto il codice della BCL, librerie di terze parti e qualsiasi altro programma scritto in un qualsiasi linguaggio.net viene tradotto nel Common Intermediate Language (CIL) che rappresenta il linguaggio di programmazione di più basso livello ancora leggibile dall uomo definito dalla Common Figura 2.1: Diagramma della Common Language Infrastructure.

11 CAPITOLO 2. LE TECNOLOGIE 8 Language Infrastructure (CLI) rappresentata in figura 2.1, ossia lo standard Microsoft che descrive il codice eseguibile e l ambiente d esecuzione che forma il nucleo del.net Framework. I programmi trasformati in CIL vengono quindi eseguiti all interno di un ambiente software noto come Common Language Runtime (CLR), una macchina virtuale che fornisce importanti servizi e funzionalità quali la sicurezza, la gestione della memoria, la gestione delle eccezioni, etc. Per fare un esempio, il CIL e il CLR possono essere paragonati al Bytecode ed alla macchina virtuale di Java. Le librerie di classi BCL e il CLR, insieme costituiscono il.net Framework. In figura 2.2 è rappresentato lo stack.net Framework fino alla versione Entity Framework Entity Framework è un set di tecnologie ADO.NET (ActiveX Data Objects), ossia un sottoinsieme di librerie della BCL utilizzato per suppor- Figura 2.2: Lo stack.net Framework fino alla versione 4.0.

12 CAPITOLO 2. LE TECNOLOGIE 9 tare lo sviluppo di applicazioni software orientate ai dati. Le tecnologie ADO.NET rappresentano il primo modello di accesso relazionale ai dati per le applicazioni basate su Microsoft.NET Framework. Entity Framework rappresenta una soluzione di mapping relazionale ad oggetti ed è uno strumento che consente alle applicazioni di accedere e modificare i dati, i quali vengono rappresentati come entità e relazioni. Le informazioni contenute nei file di modello e di mapping, che necessitano di essere definiti tramite appositi linguaggi, vengono utilizzate per tradurre le query eseguite sui vari tipi di entità in query specifiche dell origine dati. Questo accade poiché le origini dei dati possono essere di tipo differente (Strutture dati, DBMS, file, etc) ed il risultato delle query viene poi rappresentato da oggetti gestiti da Entity Framework. Il meccanismo di traduzione delle query è fornito dai provider di dati EntityClient. Tali provider gestiscono connessioni alle sorgenti dei dati, convertono query di entità in query specifiche dell origine dati e restituiscono un lettore dati utilizzato successivamente da Entity Framework per materializzare i dati dell entità in oggetti. I metodi disponibili per eseguire query su un modello concettuale e restituire oggetti sono fondamentalmente due: LINQ to Entities: Fornisce il supporto LINQ (Language-Integrated Query) per l esecuzione di query su tipi di entità definiti in un modello concettuale Entity SQL: Sottolinguaggio SQL indipendente dall archiviazione che interagisce direttamente con le entità del modello concettuale e supporta il concetto di Entity Data Model (derivante dal modello Entity Relationship) La figura 2.3 mostra l architettura di Entity Framework per l accesso ai dati.

13 CAPITOLO 2. LE TECNOLOGIE 10 Figura 2.3: Architettura di Entity Framework per l accesso ai dati. LINQ Language Integrated Query (LINQ, si pronuncia link ) è un componente del.net Framework che aggiunge ai linguaggi.net la possibilità di effettuare interrogazioni su oggetti utilizzando una sintassi simile a SQL. Esso definisce un insieme di operatori che possono essere usati per interrogare, proiettare e filtrare dati in matrici, classi enumerabili, XML, database relazionali e sorgenti dati di terze parti. Consente l interrogazione di ogni sorgente di dati che rappresenti i dati sotto forma di oggetti. Per questa ragione, se la sorgente non memorizza in maniera nativa i dati come oggetti, è necessario l utilizzo di un connettore per accedere ai dati. Il risultato di una query viene restituito come una collezione di oggetti in memoria che possono poi essere enumerati.

14 CAPITOLO 2. LE TECNOLOGIE Membership La Membership è una funzionalità integrata di ASP.NET che consente di convalidare e archiviare le credenziali utente, facilitando così la gestione dell autenticazione degli utenti nei siti Web e fornisce il supporto per: Creazione di nuovi utenti e password. Archiviazione delle informazioni di account utente (nomi utente, password e dati di supporto) in Microsoft SQL Server, Active Directory o in un archivio dati alternativo. Autenticazione degli utenti che visitano il sito. È possibile autenticare gli utenti a livello di codice oppure utilizzare i controlli di accesso ASP.NET per creare un sistema di autenticazione completo che non richieda la scrittura di codice o la richieda solo in minima parte. Gestione delle password, comprese le operazioni di creazione, modifica e reimpostazione. A seconda delle impostazioni utilizzate, la Membership può anche fornire un sistema automatico per la reimpostazione delle password che accetti una domanda ed una risposta segreta fornite dall utente. Definizione di un provider Membership personalizzato, che è possibile utilizzare in sostituzione del provider di default per gestire gli account e mantenere i dati relativi. Gli utenti possono essere raggruppati per ruolo. La gestione dei ruoli in ASP.NET consente di gestire le autorizzazioni, permettendo di specificare quali utenti possono accedere a determinate risorse dell applicazione. Analogamente ai Membership Provider è possibile definire provider personalizzati per la gestione dei ruoli.

15 CAPITOLO 2. LE TECNOLOGIE Windows Communication Foundation Windows Communication Foundation (WCF), conosciuto in fase di sviluppo con il nome Indigo, è un sistema del.net Framework che offre la struttura API per la creazione di applicazioni distribuite. Ogni protocollo di rete (HTTP, FTP, SMTP, etc.) ha un suo modello di programmazione e necessita quindi di una conoscenza specifica da parte degli sviluppatori per poter essere utilizzata. WCF è stato invece realizzato con l intento di ricondurre ad un unico modello diverse tecnologie, rendendo più semplice ed uniforme la programmazione. È spesso utilizzato per implementare sistemi con architettura SOA (Service Oriented Architecture) Un servizio WCF si basa sul concetto di Endpoint che rappresenta la porta attraverso la quale le applicazioni comunicano con il mondo esterno. Si può quindi affermare che un servizio WCF sia una collezione di Endpoint. A sua volta, un Endpoint è costituito da quelli che sono i pilastri di WCF: Address, Binding, Contract. Address L Address è l indirizzo al quale il servizio risponde. L indirizzo è composto da un URI, una Identity ed una lista di Header. In fase di definizione di un Address, l informazione principale è l URI, che corrisponde all indirizzo fisico del servizio. Header e Identity sono informazioni opzionali che sono necessarie solo in casi particolari, come ad esempio per specificare un certificato X.509 nel caso sia richiesto un maggior grado di sicurezza. Binding Il concetto di Binding è forse il più importante tra quelli proposti in WCF. Infatti è proprio grazie ad esso se ci si può occupare esclusivamente del codice senza interessarsi minimamente all infrastruttura di trasporto. I Binding si occupano di quello che avviene tra il momento in cui il servizio spedisce

16 CAPITOLO 2. LE TECNOLOGIE 13 logicamente il messaggio ed il momento in cui questo viene fisicamente trasmesso sulla rete. In questo lasso di tempo vengono eseguiti numerosi passi che seguono una precisa pipeline di cui i binding sono responsabili. Il messaggio deve attraversare due livelli: il primo si occupa dei Behaviour (Comportamenti), ovvero delle trasformazioni che deve subire un messaggio, il secondo si occupa dei Channel (Canali), ovvero dell instradamento verso il canale fisico di trasporto. Nel primo livello ci si occupa della conversione dei dati dal formato originario al formato specifico del messaggio che dipende dal protocollo utilizzato. Ad esempio, potrebbe essere effettuata la serializzazione di una classe nel formato XML di un messaggio SOAP. In aggiunta i Behaviour si occupano anche della sicurezza, ad esempio della cifratura delle informazioni e di altre funzioni di gestione del dato. Durante la seconda fase il messaggio viene tramesso sul canale di trasporto. La gestione dei Binding può essere interamente gestita in fase di configurazione, si può quindi intuire come semplicemente cambiando la configurazione si può passare da un protocollo ad un altro, come ad esempio da HTTPS ad un trasporto diverso del messaggio come i semplici TCP o HTTP senza dover modificare il codice. Contract Il Contract rappresenta l interfaccia software vera e propria che il servizio pubblica ed espone all esterno. Ogni operazione definita nel contract consiste in un semplice scambio di messaggi utilizzando il protocollo specificato in fase di configurazione. 2.2 SQL Server Microsoft SQL Server è un DBMS relazionale, meglio noto come Relational Database Management System (RDBMS), prodotto da Microsoft. Nelle prime versioni era utilizzato per basi dati medio-piccole, ma a partire dalla

17 CAPITOLO 2. LE TECNOLOGIE 14 versione 2000 è stato utilizzato anche per la gestione di basi dati di grandi dimensioni. SQL Server utilizza una variante del linguaggio SQL standard chiamata Transact-SQL (T-SQL) comunicando sulla rete utilizzando un protocollo a livello di applicazione chiamato Tabular Data Stream (TDS). Supporta anche Open Database Connectivity (ODBC). 2.3 Windows Server 2003 Successore di Windows 2000, Microsoft Windows Server 2003 rappresenta una tappa della evoluzione della serie server dei sistemi operativi di Microsoft. Il lancio è avvenuto il 24 aprile 2003 ma conserva ancora oggi la compatibilità con molte delle caratteristiche presenti nei sistemi fino a Windows XP e Windows Internet Information Services Internet Information Services (abbreviato in IIS), è un complesso di servizi server Internet per sistemi operativi Microsoft Windows. Inizialmente venne distribuito come Option Pack per il sistema operativo Windows NT, venne poi integrato in Windows 2000 e Windows Server La versione corrente, integrata in Windows Server 2008 R2, è la 7.5 ed include i servizi server per i protocolli FTP, SMTP, NNTP e HTTP/HTTPS. L applicazione server non è in grado, di per sé, di eseguire elaborazioni Server-side ma ne delega l esecuzione ad applicazioni ISAPI (Internet Server Application Programming Interface), una interfaccia di programmazione (API) messa a disposizione da Microsoft per gli sviluppatori che intendono interagire ed ampliare le funzionalità del server web. Microsoft stessa fornisce una serie di applicazioni tra le quali il modulo per Active Server Pages ed ASP.NET. Altri sviluppatori hanno reso disponibili i moduli per il supporto ai linguaggi PHP e Perl.

18 CAPITOLO 2. LE TECNOLOGIE 15 Sebbene il mercato dei server web sia controllato saldamente da Apache, IIS è riuscito, negli anni, a guadagnarsi una fetta di server pari a circa il 20% dei domini totali. 2.4 Virtual Private Network Una Rete Privata Virtuale (Virtual Private Network o VPN) è una rete di telecomunicazioni privata, instaurata tra soggetti che utilizzano un sistema di trasmissione pubblico e condiviso, come per esempio Internet. Lo scopo delle reti VPN è di offrire alle aziende, a un costo inferiore, le stesse possibilità delle linee private in affitto sfruttando reti condivise pubbliche. Si può vedere una VPN come l estensione, a scala geografica, di una rete locale privata aziendale che colleghi tra loro siti interni all azienda stessa variamente dislocati su un ampio territorio sfruttando una rete IP pubblica per il trasporto su scala geografica e realizzando una rete LAN, detta appunto virtuale e privata, logicamente del tutto equivalente ad una infrastruttura fisica di rete appositamente dedicata. Per mezzo di una VPN, utilizzando una connessione Internet, è ad esempio possibile collegarsi dall esterno alla rete privata del proprio ufficio, scavalcando tutti i problemi dovuti alla raggiungibilità ad esempio per la presenza di firewall o NAT (Network Address Translation). Generalmente una VPN comprende due parti: una interna alla rete, e quindi protetta, che preserva la trasmissione, e una meno affidabile e sicura che è quella esterna alla rete privata, ad esempio via Internet. Le reti VPN utilizzano collegamenti che necessitano di autenticazione in modo da garantire l accesso ai soli utenti autorizzati. Per garantire la sicurezza che i dati inviati in Internet non siano intercettati o utilizzati da altri non autorizzati, le reti utilizzano sistemi di crittografia. Le reti VPN sicure adottano dunque protocolli che provvedono a cifrare il traffico transitante sulla rete virtuale. Oltre alla cifratura, una VPN sicura deve prevedere nei suoi protocolli dei meccanismi che impedisca-

19 CAPITOLO 2. LE TECNOLOGIE 16 no violazioni della sicurezza, come ad esempio il furto dell identità digitale o l alterazione dei messaggi. Alcuni dei protocolli più comuni utilizzati nelle VPN sono: IPsec (IP security), comunemente usate su IPv4 (parte obbligatoria dell IPv6). PPTP (point-to-point tunneling protocol), sviluppato da Microsoft. SSL/TLS, utilizzata nel progetto OpenVPN, è un framework molto spesso associato con il commercio elettronico, che s è rivelato di grande flessibilità ed è quindi usato come strato di sicurezza per varie implementazioni (più o meno standard) di reti private virtuali. In particolare nel corso del lavoro si è scelto di utilizzare il servizio VPN offerto da Windows Server 2003 che fa uso del protocollo PPTP.

20 Capitolo 3 Refactoring architettura In questo capitolo sarà presentata l architettura di GRIMD 1.1 [1], e le modifiche apportate nella nuova versione allo scopo di fornire un servizio di gestione web e multiutente. Ci si concentrerà quindi solamente sugli aspetti architetturali analizzando i vantaggi derivanti dalle scelte adottate nell ultima fase di sviluppo. 3.1 GRIMD 1.1 L architettura originaria di GRIMD prevede la presenza di una macchina master che coordina il lavoro di un numero indeterminato di slave. Il master gestisce una lista statica di slave ai quali si connette all avvio. Gli slave che non sono raggiungibili in quel determinato istante, o che vengono persi durante la computazione, saranno ricontattati ad intervalli regolari per verificarne la nuova eventuale disponibilità. È importante notare quindi che la direzione della connessione va dal master agli slave. Una volta instaurata, la connessione resta aperta fino alla terminazione dello slave o del master. Allo stesso modo una volta terminata una computazione il master ricontatta tutti gli slave, preleva da ciascuno un file contenente una sintesi dei risultati ottenuti, ed eventualmente li recupera salvandoli sulla macchina che lo ospita. 17

21 CAPITOLO 3. REFACTORING ARCHITETTURA Modifiche apportate La precedente versione di GRIMD si è rivelata particolarmente adatta all utilizzo in un ambito di laboratorio, dove ogni computer si trova all interno della stessa rete e i requisiti di sicurezza sono limitati. Con l intento di estendere le capacità di GRIMD ad un ambito più ampio, accademico o aziendale, abbiamo scelto di mantenere la versione precedente di GRIMD per un utilizzo di laboratorio e sviluppare una versione web che consenta l utilizzo di computer appartenenti a diverse subnet, scavalcando i problemi dovuti alla presenza di NAT (Network Address Translation), e più utenti contemporaneamente e che, soprattutto, preservi l integrità di ciascuna macchina slave negando l accesso ad utenti malintenzionati. Maggiori dettagli sulla sicurezza saranno forniti nella successiva sezione. Nella versione precedente di GRIMD, era il master ad instaurare la connessione verso gli slave. Questo risulta essere un grosso limite architetturale nell ottica di fornire accesso ad un numero maggiore di utenti, infatti non era possibile contattare slave che non si trovavano nella stessa sottorete del master. Inoltre, dal momento che il master comunica con gli slave utilizzando il protocollo SMB e richiede la disponibilità di una determinata porta (di default TCP 8883) la presenza di firewall sulle macchine slave potrebbe impedire la comunicazione, a meno che non siano configurate appositamente. Si è pertanto pensato di usufruire di un servizio VPN (Virtual Private Network). Il server che ospita il master, dotato di Windows Server 2003, è particolarmente adatto a far da server anche nella VPN, essendo già raggiungibile da tutti tramite IP pubblico (yadamp.unisa.it). La nuova versione dello slave all avvio si preoccuperà di instaurare una connessione alla rete virtuale utilizzando il supporto nativo del sistema operativo tramite protocollo PPTP (Point-to-Point Tunneling Protocol).

22 CAPITOLO 3. REFACTORING ARCHITETTURA 19 Figura 3.1: Diagramma dell architettura di GRIMD Sicurezza Nella versione precedente di Grimd le password utilizzate per la comunicazione tra master e slave erano memorizzate in chiaro sul master e nel file batch di installazione dello slave. Dovendo la nuova versione lavorare con un insieme più vasto di slave, dislocati in diversi laboratori dell ateneo, si è deciso di memorizzare tali informazioni sensibili in un unico database consultabile solo dagli addetti ai lavori, per evitare intrusioni nel file system distribuito del sistema, anche da parte di computer che appartengono alla griglia. Verranno, inoltre, impostate per la cartella dello slave maggiori restrizioni, in modo tale da permettere solo all utente amministratore l accesso in lettura e scrittura. La connessione e la comunicazione alla VPN sono cifrate tramite MS- CHAPv2 (Microsoft Challenge Handshake Authentication Protocol) e MP-

23 CAPITOLO 3. REFACTORING ARCHITETTURA 20 PE (Microsoft Point-to-Point Encryption), che fa uso di RSA RC4 con chiave di sessione a 128bit. Qualunque operazione sul file system degli slave continuerà a richiedere username e password. GRIMD 1.1 GRIMD 1.2 password in chiaro rimozione file di nei file di configurazione configurazione e del master gestione dinamica degli account degli slave password in chiaro rimozione del file di in file batch di installazione installazione permessi non impostati accesso consentito per la directo- ry slave solo agli utenti grimd e administrator Tabella 3.1: Sicurezza in GRIMD 1.1 e Requisiti minimi Il codice sorgente del master e dello slave è stato scritto utilizzando i linguaggi VB.NET e C# appartenenti alla famiglia di linguaggi Microsoft.NET Framework, mentre per l interfaccia web è stato utilizzato ASP.NET. La comunicazione interprocesso avviene utilizzando WCF (Windows Communication Foundation), mentre lo spostamento dei files sfrutta il protocollo SMB. Per garantire il funzionamento del sistema pertanto è necessario che tutti i pc slave dispongano dei seguenti requisiti: Windows XP SP3 o successiva

24 CAPITOLO 3. REFACTORING ARCHITETTURA 21.NET Framework v.4 o successiva Raggiungibilità al file system locale tramite protocollo SMB (Configurazione del firewall su interfaccia VPN) Raggiungibilità tramite protocollo TCP alla porta 8883 (Configurazione del firewall su interfaccia VPN)

25 Capitolo 4 Struttura del sistema In questo capitolo saranno descritte nel dettaglio l architettura ed il funzionamento di tutte le componenti del sistema introdotte per svolgere il lavoro. Saranno riportati anche gli schemi relazionali delle tabelle che compongono il database. 4.1 Gestione utenti Dal momento che uno degli obiettivi principali è quello di fornire l accesso a GRIMD ad un determinato numero di utenti, si è pensato fosse necessario introdurre, per motivi di ordine, una semplice gerarchia tra questi ultimi. Sono infatti stati definiti due ruoli per gli utenti, uno con privilegi amministrativi e l altro con normale accesso al sistema. In particolare, l utente amministratore ha il potere di: Creare o eliminare nuovi utenti dal sistema e gestirne i ruoli. Alterare arbitrariamente l ordine dei lavori in coda. Eliminare o modificare la posizione dei lavori in coda. Terminare il sistema. 22

26 CAPITOLO 4. STRUTTURA DEL SISTEMA 23 Gli utenti normali possono invece sottomettere le macro per uno o più lavori, le quali una volta caricate vengono inserite nella coda. 4.2 Base dei dati In figura 4.1 è mostrato il diagramma ER della base dati utilizzata. Per esigenze di spazio sono mostrate solamente le entità ritenute di maggior importanza. Di seguito sarà riportata una breve descrizione per ogni entità. Figura 4.1: Diagramma Entità-Relazione della base di dati utilizzata per immagazzinare tutte le informazioni necessarie.

27 CAPITOLO 4. STRUTTURA DEL SISTEMA 24 Workset Rappresenta un lavoro caricato da un utente e mantiene traccia di tutte le informazioni relative come il path e il nome del file della macro, data di inizio e fine computazione, tipo di computazione, tipo di scheduler utilizzato ed utente proprietario. Slaves Qui sono memorizzate le informazioni di tutti gli slave disponibili. Indirizzo IP nella VPN, porta in ascolto, stato (online/offline), nome NetBIOS della macchina, numero di core per processore, versione del sistema operativo, username e password di accesso per GRIMD e data di ultimo accesso. Queue Questa tabella viene utilizzata per tener traccia di tutti i workset che sono presenti nella coda dei lavori e la relativa posizione. SecondaryQueue Analoga a Queue, con la differenza che viene utilizzata per tener traccia di tutti i workset nella coda secondaria. aspnet User Tabella gestita quasi interamente dalla Membership di ASP.NET per tener traccia di tutti gli utenti che sono abilitati ad accedere al sistema. aspnet Roles Tabella gestita dalla Membership di ASP.NET per tener traccia di tutti i ruoli degli utenti che sono abilitati ad accedere al sistema. La relazione di tipo molti-a-molti con gli utenti è mantenuta tramite la tabella aspnet UsersInRoles

28 CAPITOLO 4. STRUTTURA DEL SISTEMA Servizio di gestione Master Come già spiegato in precedenza abbiamo deciso di mantenere quanto più possibile della struttura originale di GRIMD, modificando solo ciò che era strettamente necessario. Nella precedente versione l avvio del master corrisponde con l avvio di un nuovo lavoro. Il workset nella nuova versione dovrà essere reperito dalla coda e disposto nell apposito path. La terminazione del lavoro corrisponde alla terminazione del master. Pertanto si è reso necessario introdurre un servizio, mantenuto costantemente in esecuzione, che avvii il master ogni volta che in testa alla coda è presente un lavoro da eseguire. Chiaramente è necessario che questo servizio possa comunicare con il modulo di gestione della coda per prelevare da questa il prossimo workset e che si preoccupi di tenere avviato il servizio di identificazione degli slaves per poter conoscere le risorse a disposizione che possono essere assegnate al workset in elaborazione. La figura 4.2 mostra il diagramma delle classi del servizio di gestione del master. Le classi MasterQueue e VPNIDResolver contengono le implementazioni dei contract dei servizi di gestione coda e di identificazione slave esposti dal servizio di gestione master tramite WCF Modulo di identificazione Slave Nella precedente versione di GRIMD era il master a tener traccia degli indirizzi di tutti i possibili slave, i quali venivano contattati ad intervalli regolari per verificarne la loro eventuale disponibilità. Nella nuova versione, sia per i motivi di sicurezza descritti nel capitolo precedente che a causa dalla presenza della VPN, non è più possibile tener traccia staticamente di tutti gli slave dal momento che l assegnazione degli indirizzi IP nella VPN avviene tramite l utilizzo di un server DHCP e quindi uno stesso indirizzo, nel tempo, può essere assegnato a slave diversi. Si è deciso quindi di gestire dinamicamente l intera situazione facendo in modo che siano gli slave a comunicare la loro

29 CAPITOLO 4. STRUTTURA DEL SISTEMA 26 Figura 4.2: Diagramma delle classi per il gestore del master. disponibilità al servizio di gestione del master, il quale conserva lo stato di tutti gli slave in un unico registro. Per identificare ogni slave, all atto della registrazione, è necessario che questi forniscano ogni volta un ID univoco assegnato loro dal sistema di gestione, tramite il quale sarà possibile tener traccia di tutte le informazioni relative. Nel caso che uno slave non fornisca un ID valido, o nel caso che non lo fornisca affatto, gli viene assegnato un nuovo ID e vengono reperite e memorizzate tutte le informazioni mostrate nella descrizione della base dati. In figura 4.3 è mostrato il diagramma delle classi per il servizio di identificazione slave. L interfaccia IVPNIDResolver rappresenta il contract esposto

30 CAPITOLO 4. STRUTTURA DEL SISTEMA 27 Figura 4.3: Diagramma delle classi per il servizio di identificazione slave. tramite WCF, mentre la classe VPNIDResolver ne fornisce l implementazione tramite l ausilio della classe GRIMDEntities utilizzata per l accesso alla base dati Modulo di gestione coda Nonostante per un utente sia prevista la possibilità di sottomettere più lavori, nella coda non potrà essere presente un lavoro dello stesso utente per più di una volta. Più precisamente il sistema si preoccuperà di gestire due code differenti, una primaria ed una secondaria. Nella coda primaria, per la quale è prevista una politica di gestione di tipo FIFO (First In First Out), è presente il vincolo di una singola presenza in coda per ogni utente al fine di impedire che si possa monopolizzare il sistema e tenerlo impegnato per un periodo di tempo troppo lungo. Nella coda secondaria invece non sono presenti vincoli, ogni utente puo inserire un numero illimitato di lavori. Il più anziano tra questi sarà spostato in coda primaria non appena si sarà liberato l unico posto disponibile per ciascun

31 CAPITOLO 4. STRUTTURA DEL SISTEMA 28 Figura 4.4: Diagramma delle classi per il modulo di gestione coda. utente. La coda secondaria è stata pensata per permettere di inserire in coda più lavori facendo in modo che venga data priorità all ordine di inserimento per utente, invece che per lavoro. In figura 4.4 è mostrato il diagramma delle classi del modulo di gestione coda. L interfaccia IMasterQueue rappresenta il contract in WCF che viene esposto al sistema di gestione coda per interagire con essa. La classe Master- Queue ne fornisce l implementazione tramite l utilizzo della classe ausiliaria QueueHandler che si preoccupa di mantenere lo stato della coda nel database utilizzando l apposita classe GRIMDEntities.

32 CAPITOLO 4. STRUTTURA DEL SISTEMA Modulo di controllo di stato del Master Tutti i dati riguardanti l andamento del lavoro, come ad esempio il numero di slave totali, disponibili o persi durante la computazione, sono contenuti solamente all interno del processo del master e quindi praticamente inaccessibili dall esterno. Figura 4.5: Diagramma delle classi per il modulo di controllo di stato del master. Per permettere l accesso a questi dati tramite il pannello di controllo utente presente sull interfaccia web, è stato necessario introdurre nel master un modulo che esponga all esterno la possibilità di reperirli e quindi di visualizzarli. Come si può vedere in figura 4.5 il contract WCF (IMasterStatus) contiene un semplice metodo che restituisce un oggetto contenente lo stato del lavoro in esecuzione all istante dell invocazione. Per l implementazione nella classe MasterStatus è stato creato un apposito bean, GRIMDStatus, che viene costantemente aggiornato dal master e restituito come risultato dell invocazione del metodo presente nell interfaccia.

33 CAPITOLO 4. STRUTTURA DEL SISTEMA Altre modifiche Di seguito viene riportato l elenco di modifiche, di minore impatto, apportate ai servizi già esistenti nella versione precedente che non sono state ancora presentate Master Sono state effettuate altre modifiche minori nel master per quanto riguarda la creazione dei file di log. Infatti, in origine, nei file di log si teneva traccia degli indirizzi IP degli slave che, allo stato attuale, non forniscono un informazione sufficiente per la loro identificazione a causa dei problemi precedentemente descritti. Sono quindi state apportate modifiche al logging facendo in modo che oltre all indirzzo IP venga memorizzato anche l ID di ogni slave FRED e GDUMP Le informazioni conservate nei file di log sono utilizzate successivamente dai servizi FRED e GDUMP rispettivamente per forzare l operazione di reduce e per il recupero dell intero insieme dei risultati conservati sugli slave. È da precisare che la nuova versione di GDUMP permette anche il recupero selettivo dei risultati e non obbligatoriamente quello dell intero insieme. È stato necessario modificare le versioni precedenti di FRED e GDUMP, sia a causa del cambiamento del formato di log che per permettere il loro funzionamento tramite gli ID degli slave, utilizzati al posto di indirizzi IP. Infatti ora per ogni job cotenuto nel workset viene effettuata la risoluzione dell ID dello slave associato utilizzando l apposito servizio. In tal modo è possibile controllare se lo slave di riferimento è disponibile ed eventualmente ottenerne l indirizzo IP corrente per contattarlo e prelevare i risultati di interesse.

34 CAPITOLO 4. STRUTTURA DEL SISTEMA Slave Le modifiche apportate allo slave riguardano essenzialmente l introduzione dell ingresso in VPN e della registrazione al servizio di identificazione. Dopo queste due fasi iniziali lo slave funziona esattamente come nella precedente versione, ad eccezione della gestione dei risultati memorizzati. Nella precedente versione infatti, all inizio di un nuovo lavoro, il master provvedeva ad inviare allo slave una richiesta RESET DFS che causava la cancellazione dell intero insieme di risultati memorizzati sullo slave. Nella nuova versione invece, a prescindere dall inizio di un nuovo lavoro, si garantisce che i risultati siano conservati per un periodo di tempo minimo pari a quattro giorni dall ultimazione del lavoro, dopo i quali non si garantisce più la permanenza di tali informazioni sulla macchina. Pertanto, se queste sono oggetto di interesse, è obbligatorio effettuarne il recupero da parte dell utente entro questo termine.

35 Conclusioni Per quanto i sistemi di grid computing siano oggi estremamente utilizzati, esistono molti problemi, di difficile soluzione, quali la gestione dell alto grado di eterogeneità e la sicurezza, che rendono improponibile un avvento del Grid in qualità di tecnologia pervasiva. Ad oggi, il suo utilizzo resta circoscritto a grandi attori in grado di poter effettuare investimenti importanti in manodopera specializzata in grado di gestire e utilizzare i sistemi Grid di presente generazione. Questo lavoro può essere considerato come la base di partenza per lo sviluppo di applicazioni distribuite condivise tra più utenti, da proseguire sia attraverso l approfondimento progettuale sia attraverso l implementazione di ulteriori sviluppi tecnologici. Il progetto nasce come tentativo di allargare l esperienza d uso di un sistema condividendolo in un gruppo più vasto di utenti, cercando di facilitare il più possibile la comunicazione tra le risorse interne al sistema, spesso impedite da servizi di protezione come firewall oppure come il NAT. Il sistema sviluppato rimane comunque un progetto sperimentale, durante il quale si sono scoperti numerosi risvolti interessanti. Sviluppi futuri potrebbero consistere in miglioramenti nell organizzazione e nella comunicazione interna al sistema, nello sviluppo dell applicazione slave con compatibilità per sistemi LINUX, nell introduzione del supporto di nuove applicazioni anche non inerenti al calcolo scientifico o nell inserimento di un sistema che renda possibile la distribuzione e quindi l esecuzione di un applicazione generica, sempre seguendo il modello di programmazione Map/Reduce. 32

36 Bibliografia [1] Alessandro Bove, Alfonso Martorelli, Luigi Di Biasi. Distributed Map/Reduce Grid for YASARA 2011 [2] SETI Institute (Search for Extra-Terrestrial Intelligence) [3] - SETI at home Classic berkeley.edu [4] Berkeley Open Infrastructure for Network Computing (BOINC) [5] Grid-Based e-infrastructure for computationally data-intensive application in medical sciences php 33

37 Appendice A Appendice A.1 Servizio di controllo stato Master A.1.1 IMasterStatus 1 namespace MasterStatusLib 2 { 3 [ S e r v i c e C o n t r a c t ] 4 p u b l i c i n t e r f a c e IMasterStatus 5 { 6 [ OperationContract ( IsOneWay = f a l s e ) ] 7 GRIMDStatus g e t S t a t u s ( ) ; 8 } 9 } A.1.2 MasterStatus 1 namespace MasterStatusLib 2 { 3 [ S e r v i c e B e h a v i o r ( InstanceContextMode = InstanceContextMode. S i n g l e ) ] 4 p u b l i c c l a s s MasterStatus : IMasterStatus 5 { 6 #r e g i o n V a r i a b i l i d i s t a n z a 7 8 p r i v a t e GRIMDStatus s t a t u s ; 9 p r i v a t e ServiceHost h o s t ; #endregion 12 34

38 APPENDICE A. APPENDICE #r e g i o n Implementazione i n t e r f a c c i a p u b l i c GRIMDStatus g e t S t a t u s ( ) { return s t a t u s ; 18 } #endregion #r e g i o n Metodi p u b b l i c i p u b l i c void L i s t e n ( ) 25 { 26 h o s t = new ServiceHost ( t h i s ) ; 27 h o s t. Open ( ) ; 28 } p u b l i c void Close ( ) 31 { h o s t. Close ( ) ; 34 } #endregion #r e g i o n P r o p r i e t à p u b l i c GRIMDStatus Status 41 { 42 s e t 43 { 44 s t a t u s = value ; 45 } 46 } #endregion 49 } p u b l i c c l a s s GRIMDStatus 52 { 53 #r e g i o n V a r i a b i l i d i s t a n z a p r i v a t e i n t numberofslave, a c t i v e S l a v e, l o s t S l a v e, MFFAQueue ; 56 p r i v a t e i n t t o t a l J o b s, completedjobs, slavelosscount, worktoreassign ; #endregion #r e g i o n P r o p r i e t à p u b l i c i n t SlaveLossCount

39 APPENDICE A. APPENDICE { 64 get { r eturn slavelosscount ; } 65 s e t { slavelosscount = value ; } 66 } p u b l i c i n t WorkToReassign 69 { 70 get { r eturn worktoreassign ; } 71 s e t { worktoreassign = value ; } 72 } p u b l i c i n t CompletedJobs 75 { 76 get { r eturn completedjobs ; } 77 s e t { completedjobs = value ; } 78 } p u b l i c i n t TotalJobs 81 { 82 get { r eturn t o t a l J o b s ; } 83 s e t { t o t a l J o b s = value ; } 84 } p u b l i c i n t MFFAQueue 87 { 88 get { r eturn MFFAQueue ; } 89 s e t { MFFAQueue = value ; } 90 } p u b l i c i n t LostSlave 93 { 94 get { r eturn l o s t S l a v e ; } 95 s e t { l o s t S l a v e = value ; } 96 } p u b l i c i n t ActiveSlave 99 { 100 get { r eturn a c t i v e S l a v e ; } 101 s e t { a c t i v e S l a v e = value ; } 102 } p u b l i c i n t NumberOfSlave 105 { 106 get { r eturn numberofslave ; } 107 s e t { numberofslave = value ; } 108 } #endregion 111 }

40 APPENDICE A. APPENDICE } A.2 Servizio di coda A.2.1 IMasterQueue 1 namespace QueueHandlerInterfaceLib 2 { 3 [ S e r v i c e C o n t r a c t ] 4 p u b l i c i n t e r f a c e IMasterQueue 5 { 6 [ OperationContract ( IsOneWay = f a l s e ) ] 7 Workset IsUserInQueue ( S t r i n g username, out i n t positioninqueue ) ; 8 9 [ OperationContract ( IsOneWay = f a l s e ) ] 10 void Enqueue ( S t r i n g user, S t r i n g macrofilename, Int16 scheduler, S t r i n g computation, S t r i n g workname) ; [ OperationContract ( IsOneWay = f a l s e ) ] 13 void RemoveFromQueue ( S t r i n g user ) ; [ OperationContract ( IsOneWay = f a l s e ) ] 16 void MoveTo( S t r i n g user, Int16 newindex ) ; [ OperationContract ( IsOneWay = f a l s e ) ] 19 Workset GetNextWorkset ( ) ; [ OperationContract ( IsOneWay = f a l s e ) ] 22 void RemoveCurrentWorkset ( ) ; [ OperationContract ( IsOneWay = f a l s e ) ] 25 void RemoveWorkset ( i n t id ) ; [ OperationContract ( IsOneWay = true ) ] 28 void StartDump ( Workset w, S t r i n g arg1, S t r i n g arg2 ) ; [ OperationContract ( IsOneWay = true ) ] 31 void Shutdown ( ) ; 32 } 33 } A.2.2 MasterQueue 1 namespace QueueHandlerInterfaceLib

41 APPENDICE A. APPENDICE 38 2 { 3 [ S e r v i c e B e h a v i o r ( InstanceContextMode = InstanceContextMode. PerCall ) ] 4 p u b l i c c l a s s MasterQueue : IMasterQueue 5 { 6 #r e g i o n V a r i a b i l i d i s t a n z a 7 8 p r i v a t e QueueHandler queue ; 9 p r i v a t e ServiceHost h o s t ; #endregion #r e g i o n C o s t r u t t o r e p u b l i c MasterQueue ( ) 16 { 17 queue = new QueueHandler ( ) ; 18 } #endregion #r e g i o n Implementazione i n t e r f a c c i a p u b l i c Workset IsUserInQueue ( s t r i n g username, out i n t positioninqueue ) 25 { 26 return queue. GetUserWorkset ( username, out positioninqueue ) ; 27 } p u b l i c void Enqueue ( S t r i n g user, S t r i n g remotefilename, Int16 scheduler, S t r i n g computation, S t r i n g workname) 30 { 31 C o n f i g u r a t i o n c o n f i g = ConfigurationManager. OpenExeConfiguration ( ConfigurationUserLevel. None ) ; WebClient c l i e n t = new WebClient ( ) ; S t r i n g newdir = c o n f i g. AppSettings. S e t t i n g s [ WorksetRepository ]. Value + remotefilename + \\ ; 36 S t r i n g URIWorkset = c o n f i g. AppSettings. S e t t i n g s [ URIWorksetBaseAddress ]. Value + remotefilename +. z i p ; 37 S t r i n g saveto = c o n f i g. AppSettings. S e t t i n g s [ WorksetRepository ]. Value + remotefilename +. z i p ; 38