tesi07-08-delprete-domenico by hedongchenchen

VIEWS: 3 PAGES: 105

									         Università degli Studi di Napoli Federico II




                 Facoltà di Scienze MM.FF.NN.
                         Corso di Laurea in Informatica


                 Tesi Sperimentale di Laurea Triennale



     Integrazione di servizi file transfer dedicati al GRID
     Computing su NAS Server del Data Center S.Co.P.E




  Relatori                                                  Candidato
Prof. G. Russo                                            Domenico Del Prete
Dr. S. Pardi                                              matr. 873/1




                         Anno accademico 2007/2008




                                                                           I
Ringraziamenti

   Al termine di questo lavoro, desidero ringraziare tutti coloro che mi hanno offerto il
   supporto necessario per portare a compimento questa esperienza accademica.
   In particolare ringrazio il Prof. Guido Russo e il Dr. Silvio Pardi che hanno creduto
   nelle mie capacità e mi hanno supportato con la loro esperienza in tutte le fasi del
   lavoro. Ringrazio i ricercatori e gli sviluppatori dei vari progetti Grid che ho conosciuto
   in questi mesi nella control room, dai quali ho ricevuto preziosi consigli: Vania,
   Giancarlo e tutti gli altri. Inoltre devo ringraziare tutti i miei compagni di studi che sono
   diventati col passare dei mesi e degli anni miei amici, con i quali ho vissuto a più stretto
   contatto l’esperienza universitaria: Andrea, Flavio, Vittorio, Vincenzo, Luigi Massa,
   Duffi, Ferdinando, Alduccio, Francesco Colmayer; Albenzo, Maurizio, Giusy, Paolo
   Caruso, Rosy, Stefano, Daniela, Enzo Imposimato, con i quali ho condiviso gioie e
   dolori della vita universitaria; un ringraziamento e un saluto vanno a tutti i tirocinanti
   del centro S.Co.P.E. con i quali ho condiviso le scoppiettanti pause caffè: Luigi Ilardi,
   Alessandro, Armando, il memorabile Saviano e tutti gli altri. Inoltre un ringraziamento
   particolare va a Joak che grazie alla sua valida conoscenza ha saputo consigliarmi e
   aiutarmi come un vero amico disponibile sa fare. Non posso poi non ringraziare i miei
   amici di sempre: Gennaro, Umberto, Mirco, Gaetano, Salvatore, Giuseppe, Diaisa, Asia,
   che mi hanno tenuto allegro in momenti nei quali non speravo di esserlo.
   Infine, il ringraziamento più grande e più sentito è rivolto alla mia famiglia, in
   particolare ai miei genitori per l'incrollabile sostegno morale ed economico che mi ha
   permesso di raggiungere questo importante traguardo.




                                                                                              II
                                       INDICE GENERALE
Introduzione...............................................................................................................1
1. La Griglia Computazionale....................................................................................3
    1.1 Il progetto S.Co.P.E.........................................................................................3
    1.2 La filosofia GRID ............................................................................................5
    1.3 L'architettura della Griglia Computazionale....................................................7
      1.3.1 I servizi core...............................................................................................8
      1.3.2 I servizi collective.......................................................................................9
2. Sistemi di Storage in ambito GRID.....................................................................13
    2.1 Problematiche ed esigenze di storage in ambito GRID................................13
    2.2 Gli scopi funzionali dei sistemi di storage GRID...........................................17
    2.3 La gestione dello storage nel Data Center...................................................19
    2.4 La possibilità di utilizzare NAS Server in ambito GRID................................25
    2.5 Le attrezzature prese in esame: Synology DS 508 & LACIEethernet disk. .27
3. I protocolli di trasferimento in ambito GRID........................................................31
    3.1 FTP (File Transfer Protocol).........................................................................31
    3.2 SCP (Secure CoPy)......................................................................................33
    3.3 BBFTP (BaBar FTP).....................................................................................34
    3.4 GridFTP.........................................................................................................34
      3.4.1 GridFTP tramite Globus Toolkit...............................................................37
4. Gli obiettivi della tesi...........................................................................................39
    4.1 Alternativa a sistemi di storage costosi e complessi....................................39
    4.2 La scelta dell'apparecchiatura NAS: Synology DS 508................................41
    4.3 Integrazione di applicazioni su sistemi di storage embedded......................42
5. L'implementazione dei servizi sul NAS Server Synology ..................................45
    5.1 Gli strumenti utilizzati....................................................................................45
    5.2 Implementazione del servizio BBFTP...........................................................46
    5.3 Implementazione del servizio GridFTP.........................................................49
    5.4 Configurazione dei servizi con l'uso di GSI..................................................53
      5.4.1 Message Privacy: cifratura tramite crittografia asimmetrica ..................55
      5.4.2 Non ripudation e message integrity tramite firma digitale ......................56
      5.4.3 Maggiore sicurezza con la delegazione proxy .......................................58
      5.4.4 Configurazione dei certificati sul NAS server .........................................60
6. Integrazione dei servizi nel sistema web d'amministrazione ............................63


                                                                                                                        III
    6.1 Predisposizione del server per consentire l'integrazione web ....................63
      6.1.1 Le tecnologie utilizzate ..........................................................................66
      6.2 Integrazione servizio BBFTP .....................................................................67
      6.3 Integrazione servizio GridFTP ...................................................................71
7. Testing prestazionale dei servizi.........................................................................80
    7.1 Il piano di testing...........................................................................................80
    7.2 Il risultato dei test..........................................................................................85
8. Conclusioni..........................................................................................................90
Bibliografia...............................................................................................................92
Appendice N° 1: .....................................................................................................94
Appendice N° 2: .....................................................................................................96
Appendice N° 3: ...................................................................................................102




                                                                                                                         IV
Introduzione

     L'oggetto della presente tesi identifica una sperimentazione originale: l’obbiettivo
     sperimentale è stato quello di estendere e potenziare le funzionalità di
     un’apparecchiatura di tipo NAS (Network Attached Storage) della Synology,
     originariamente designata a piccole e medie aziende per il management di servizi
     multimediali e di dati, per integrarlo nell’ambito dell’ infrastruttura GRID della
     Federico II, capace quindi di soddisfare tutte le tipologie di requisiti ricercate in
     quest’ambito, da quelle prestazionali e dei servizi offerti a quelle inerenti alla
     sicurezza e la riservatezza.
     L’apparecchiatura presa in esame è un sistema di storage embedded, concepito per
     fornire esclusivamente servizi contemplati in fase di progettazione. Su questo sistema
     è stata svolta una intensa attività sperimentale che ha portato all’implementazione di
     funzionalità aggiuntive embedded: il protocolli di trasferimento BBFTP e GridFTP,
     attraverso procedure di cross-compilazione e compilazione nativa, permettendo di
     utilizzare il server NAS come componente di Storage Element all’interno
     dell’infrastruttura grid del progetto S.Co.P.E.; inoltre sono state estese le funzionalità
     al kernel del sistema operativo esistente, favorendo l’integrazione di nuove
     applicazioni. Sono state modificate le componenti del sistema web di management
     fornito dalla casa produttrice consentendo l’esecuzione di script di shell in modalità
     esclusiva, favorendo così l’integrazione di moduli aggiuntivi autoprodotti.
     E’ stata quindi estesa l’interfaccia web d’amministrazione sviluppando componenti
     aggiuntivi, al fine di permettere il monitoraggio e la gestire dello stato dei nuovi
     servizi implementati nel sistema. Sono stati configurati i servizi di file transfer
     compilando altresì l’architettura di sicurezza Grid Security Infrastructure (GSI),
     garantendo l’integrità dei messaggi, il non ripudio e la privacy sul trasferimento dei
     dati, tutto questo con l’uso di certificati X.509 e crittografia asimmetrica.
     Finita l’attività implementativa, sono state eseguite diverse batterie di test con i
     seguenti obiettivi:




 Del Prete Domenico 873/1                                                    Pagina 1 di 101
       ▪ Mettere sotto stress il sistema con i nuovi protocolli


       ▪ Confrontare i servizi di trasferimento preesistenti con quelli implementati


       ▪ Validare l’attività svolta

    Le informazioni pervenute dall’attività di testing hanno dimostrato un notevole
    margine di guadagno sia nelle prestazioni di trasferimento che nella qualità di
    sicurezza acquisita sullo scambio delle informazioni.

    La sperimentazione svolta permette d’inquadrare l’apparecchiatura su un’alta fascia di
    utenza; questi risultati consentirebbero la possibilità di customizzare a livello di
    fabbrica il DS 508 Synology NAS server implementando i servizi di BBFTP e
    GridFTP in maniera nativa così da rendere disponibile sul mercato dei prototipi di
    NAS nativamente grid-compliant.

    Questa magnifica esperienza ha saputo arricchirmi di nuove capacità e saperi; per di
    più, oltre alla specifica problematica affrontata ho avuto modo di fare pratica anche su
    altre numerose apparecchiature di calcolo del Data Center, toccando con mano le
    diverse e complesse tecnologie che le governano.




Del Prete Domenico 873/1                                                 Pagina 2 di 101
 1. La Griglia Computazionale


    1.1 Il Progetto S.Co.P.E
    La presente tesi si inserisce nell’ambito del progetto S.Co.P.E [1] dell’Università
    Federico II di Napoli. L’acronimo sta per “Sistema Cooperativo Distribuito ad alte
    Prestazioni per Elaborazioni Scientifiche Multidisciplinari”, il progetto è stato
    finanziato sui fondi PON 2000-2006. L'obiettivo del progetto era la realizzazione di un
    Data Center composto da un sistema di calcolo ad alte prestazioni, rivolta al calcolo
    intensivo, basato sul paradigma del Grid e sulle più moderne tecnologie di calcolo
    distribuito, a supporto della ricerca e delle imprese.




                         Figura 1.1: Infrastruttura del progetto S.Co.P.E



    Il progetto è nato sulla base di una preesistente infrastruttura di rete metropolitana, che
    connette al gigabit tutte le maggiori strutture di ricerca dell’Ateneo; l’architettura del
    Data Center S.Co.P.E ha integrato le risorse di calcolo e storage già disponibili
    nell'ateneo, con nuovo hardware ad alte prestazioni. Tali risorse sono infine inglobate
    in un unica piattaforma di tipo Grid, basata su middleware di nuova generazione, che a
    sua volta permette l'integrazione con le altre infrastrutture di griglia, nazionali ed
    internazionali.


Del Prete Domenico 873/1                                                    Pagina 3 di 101
                              Figura 1.2: Il Data Center S.Co.P.E



    Il Data Center è realizzato su una potente infrastruttura di calcolo fornita dalla Dell.
    Esso opera nell’ambito della modellistica, del calcolo numerico a elevate prestazioni,
    nella gestione di grandi banche dati, nella simulazione e analisi di informazioni in
    ambito scientifico e applicativo-strategico; le aree scientifiche maggiormente
    coinvolte sono: scienze del microcosmo e del macrocosmo, scienze della vita, scienze
    dei materiali e scienze dell'ambiente.
    L'infrastruttura di calcolo si propone d'entrare nella classifica dei 150 centri di super
    calcolo più potenti del mondo, anche se chiaramente la classifica è molto dinamica.
    La    parte   hardware      comprende       al
    momento:


    a) 33 rack telecontrollati, 304 server blade
    (doppia CPU quad core per un totale di
    2432 core), raggruppati in 16 blade per
    chassis;
    b) 26 server 1U; c) 10 server 2U
    d) Otto server 8U quadriprocessori dual            Figura 1.3: I server blade del Data Center
    core; e) Soluzioni di storage misto: 200Terabyte di Storage Fiber Channel + 32
    Terabyte di Storage iSCSI




Del Prete Domenico 873/1                                                         Pagina 4 di 101
    f) Rete Gigabit ethernet;
    g) Infiniband su ogni macchina
    h) Rete Fibre Channel


    1.2 La filosofia GRID

  In molti settori, tra cui la scienza, l'ingegneria e l'industria, le collaborazioni tra diversi
  istituti e molti individui sono diventate fondamentali;; esperimenti scientifici, in
  particolare il campo della ricerca di base (come quelli di fisica delle particelle con
  l’acceleratore LHC “Large Hadron Collider” del CERN) sono portati avanti da folti
  gruppi di scienziati e tecnici. L'esigenza di raggiungere uno scopo comune, risultato del
  lavoro collettivo, presuppone la possibilità di condividere software, dati, e tecniche
  comuni di risoluzione dei problemi.


  Le Organizzazioni Virtuali
  Le griglie computazionali nascono per venire incontro alle necessità delle
  organizzazioni virtuali (Virtual Organization, VO) [2]. Queste sono degli insiemi di
  persone o istituti, che al fine di raggiungere uno scopo comune, necessitano di
  condividere    in   modo      dinamico
  risorse e dati attraverso regole ben
  determinate.
  Questo modello di condivisione
  quindi non è definita a priori, ma
  può essere modificata nel corso del
  tempo a seconda delle necessità
  richieste, come il bisogno di nuovi o
  particolari servizi, abilitare l'uso di
  questi   servizi    a   nuovi   utenti,
  escluderne degli altri. Una VO è
  caratterizzata, quindi, non tanto da
                                               Figura 1.4: La condivisione dinamica delle V.O.


Del Prete Domenico 873/1                                                        Pagina 5 di 101
  chi ne fa parte, ma quanto dalle politiche di accesso e utilizzo dei servizi e delle risorse
  condivise. La metodologia Grid adottata da S.Co.P.E consente di collegare insieme
  risorse eterogenee distribuite su larga scala geografica in un unico grande sistema
  permettendone l'utilizzo tramite meccanismi dinamici e facendole apparire come se
  fossero una singola entità.


  In altre parole, la griglia computazionale di S.Co.P.E è un'infrastruttura hardware e
  software scalabile ed interoperabile. Il suo obiettivo è quello di ampliare le capacità
  computazionali oggi disponibili tramite un utilizzo più intensivo delle risorse hardware
  già presenti; queste risorse infatti possono fornire una potenza di calcolo di parecchi
  ordini di grandezza più grande, rispetto quella a disposizione del singolo utente,
  venendo sfruttate anche quando rimangono inutilizzate dai possessori.
  Le caratteristiche di scalabilità e di interoperabilità sono fondamentali per un tale
  sistema distribuito.


  La scalabilità garantisce il graduale incremento della potenza di calcolo disponibile via
  via che le risorse entrano a far parte della rete, mentre l'interoperabilià consente la
  compatibilità tra i diversi tipi di risorse ed un'evoluzione dinamica delle VO.
  L'infrastruttura Grid di S.Co.P.E possiede, innanzi tutto, un insieme di protocolli
  comuni, che garantisce indipendenti metodi di controllo e gestione locale delle risorse:
  in questo modo può abilitare interazioni tra i diversi componenti del sistema; inoltre,
  con l'utilizzo di procedure gli utenti possono “scoprire” e utilizzare le risorse condivise.
  L'Application Program Interface (API) e Software development kit (SDK) utilizzate
  dagli sviluppatori aiutano, poi, la rapida costruzione di applicazioni che utilizzino al
  meglio le potenzialità offerte dalla Grid.




Del Prete Domenico 873/1                                                   Pagina 6 di 101
    1.3 L'architettura della Griglia Computazionale

  L’architettura definisce gli scopi, le modalità di funzionamento e le interazioni fra i
  componenti fondamentali del sistema. L'architettura del Grid S.Co.P.E si può definire di
  tipo “aperta”, ovvero in continua evoluzione: in questo modo da fissare regole ben
  precise per poi soddisfare le richieste di estensibilità ed interoperabilità richieste dalla
  generica Griglia Computazionale.


  Il Middleware costituisce l'insieme dei protocolli, servizi, API e SDK necessari al
  funzionamento dell'infrastruttura Grid. Fornisce meccanismi di autenticazione e
  autorizzazione e la possibilità di utilizzare le risorse implementando servizi atti alla loro
  scoperta, al loro utilizzo (trovare disponibilità della CPU, reperire i dati di input,
  archiviare i dati in uscita, gestire e sincronizzare le repliche di file ecc.); in altre parole è
  un software che gestisce tutte le risorse del calcolo distribuito. Il Middleware di
  S.Co.P.E è INFNGRID [3]; esso garantisce:


       •   piena compatibilità con il middleware EGEE (gLite/LCG)
       •   release e aggiornamenti/bugfix frequenti
       •   semplicità di integrazione con l'infrastruttura Grid italiana (Grid.it) ed europea
           (EGEE)
       •   disponibilità di tool consolidati nati in ambito INFN ed utilizzati in diversi
           progetti ed infrastrutture Grid esistenti (GridICE, VOMS, DGAS Distributed
           Grid Accounting System)
       •   supporto tecnico sulla release e sui tool con la possibilità di comunicare
           direttamente con gli sviluppatori del middleware
    INFNGRID è diviso in due aree principali: quella dei servizi “core” e quella dei
    servizi “collective”.




Del Prete Domenico 873/1                                                       Pagina 7 di 101
    1.3.1 I servizi core
    I servizi Core sono presenti sulle risorse di calcolo di ciascun sito periferico e
    consentono l'inserimento delle risorse “locali” nell'infrastruttura Grid (policy di
    utilizzo) e richiedono management locale (start-up, aggiornamenti e troubleshooting).
    I principali servizi core sono:


 ➢ repository pacchetti del middleware (YAIM)
    Contiene tool automatici per l'installazione e l'aggiornamento dei nodi grid, consente
    l'installazione automatica del sistema operativo tramite PXE (sistema di boot remoto)
    e contiene una replica dei pacchetti INFNGRID e degli aggiornamenti del sistema
    operativo.


 ➢ servizi di computing (Worker Node e Computing Element)
    I Computing Element sono l'interfaccia Grid verso una Farm costituita da nodi di
    calcolo (Worker Node – WN); gestiscono i job di calcolo tramite un batch-queue
    system; tramite il batch system è possibile partizionare l'insieme di risorse di calcolo
    (CPU) e definire delle policy di utilizzo da parte delle varie VO (CPU time, numero di
    job concorrenti) mediante la creazione di code batch; inoltre ciascun Computing
    Element è fornito di certificato digitale (rilasciato al momento dalla CA INFN di
    Firenze) che attesta l'attendibilità delle transazioni. I Worker Node rappresentano host
    disponibili per l'esecuzione di job e vengono gestiti/allocati dai Computing Element.




                  Figura 1.5: La comunicazione attraverso i Computing Element




Del Prete Domenico 873/1                                                        Pagina 8 di 101
 ➢ servizi di storage (Storage Element)
    Gli Storage Element rappresentano lo spazio di storage Grid e fanno utilizzo del
    protocollo GridFTP per il trasferimento di file; essi consentono di gestire lo spazio di
    storage in modo da permetterne l'utilizzo da parte di varie VO. Ciascuno Storage
    Element è fornito di certificato digitale (rilasciato dalla CA INFN) che attesta
    l'attendibilità delle transazioni.


 ➢ User Interface (U I)
    Sono i componenti che permettono agli utenti di accedere alle risorse Grid. Le
    funzionalità di base sono: la sottomissione, visualizzazione e cancellazione dei job, il
    recupero dell'output dei job. L'utente può accedere all'UI tramite collegamento remoto
    di una UI di infrastruttura o di gruppo (esempio con SSH), tramite un PC desktop o
    notebook personale configurato con i componenti della UI, tuttavia l'utente per poter
    accedere ai servizi Grid deve utilizzare il proprio certificato personale secondo lo
    schema che segue:




                          Figura 1.6: L'accesso ai servizi Grid tramite UI




    1.3.2 I servizi collective
    Questa tipologia di servizi consente l'utilizzo “trasparente” delle risorse di computing
    e storage:
 ➢ Monitoraggio e diagnostica dei servizi: consentono il monitoraggio delle risorse di
    una VO, inclusi gli attacchi (intrusion detection).


 ➢ Servizi di autenticazione / autorizzazione (con Virtual Organization Membership


Del Prete Domenico 873/1                                                     Pagina 9 di 101
    Service) I servizi VOMS estendono le informazioni presenti nel certificato proxy di un
    utente con VO membership, gruppo, ruolo, privilegi; ha una gestione degli utenti
    tramite interfaccia web e con un solo VOMS server è possibile gestire più VO.


 ➢ Servizi di allocazione dei job (Resorce Broker)
    Il Resource Broker consente di abbinare un job (seriale o parallelo) ad una risorsa di
    computing e/o storage, tale abbinamento prende il nome di matchmaking e può
    avvenire o tramite l'elaborazione di “requirement del job” o attraverso lo “stato della
    Grid”. Ciascun Resource Broker è fornito di certificato digitale (rilasciato dalla CA
    INFN) che attesta l'attendibilità delle transazioni.


 ➢ Servizi informativi (Information Index)
    L'information Index è un servizio informativo che rappresenta ogni risorsa di calcolo e
    di storage presente nell'infrastruttura Grid. Essa espone il proprio stato e le proprie
    caratteristiche tramite il servizio GRIS (Grid Resource Information Service); ciascun
    GRIS si registra presso un Information Index che effettua il caching delle informazioni
    fornite dai vari GRIS in modo da fornire una visione aggregata delle risorse di tutta
    l'infrastruttura.


 ➢ Cataloghi di file / repliche (LCG File Catalog)
    E' un sistema di data management per la GRID che offre funzionalità come:
    localizzazione dei dati, copia dei dati, gestione e replica dei dati, gestione dei meta-
    dati, inoltre possiede un backend MySQL. Il livello di trasporto è basato su GSIFTP e
    possiede almeno una User Interface (UI).




            Figura 1.7: Localizzazione dei dati            Figura 1.8: Il ruolo dell'LCG File Catalog



Del Prete Domenico 873/1                                                          Pagina 10 di 101
                               Figura 1.9: Tipico schema di un sito Grid



   L'architettura della Griglia è formata da più livelli (layers) che rispecchiano la forma di
   una clessidra (hourglass) nella quale il Middleware si posiziona al centro. Ogni layer è
   costruito sulle potenzialità e i comportamenti offerti dai layer inferiori. Il modello è
   focalizzato su aspetti architetturali. Alle due estremità della “clessidra” si trovano da un
   lato le applicazioni degli utenti e dall’altro le Farm di computer.




                Figura 1.10: I livelli dell'architettura Grid equiparati a quelli Internet Protocol



   Fabric: Costituisce il layer di base del modello a clessidra dell'architettura Grid;
   è composto da risorse computazionali, di rete, storage system e dai cataloghi. Sono tutte
   quelle risorse computazionali e di rete, inclusi storage system e cataloghi, alle quali si
   accede tramite i protocolli Grid. Sono necessari sia dei meccanismi attraverso i quali le
   risorse possano essere scoperte, ovvero possano rendere pubblici i loro stati e
   potenzialità, sia dei meccanismi che ne consentano la gestione (resource management)
   assicurando che i servizi offerti rimangano affidabili.

Del Prete Domenico 873/1                                                                   Pagina 11 di 101
   Connectivity: è il secondo layer del modello a clessidra dell'architettura Grid; è
   costituito dai protocolli di comunicazione ed autenticazione necessari per l'infrastruttura
   Grid. Alcuni definiscono le regole di accesso e scambio di dati tra le varie risorse
   all'interno del layer Fabric; altri sono deputati alla fornitura di meccanismi per la
   verifica dell'identità degli utenti.
   In riferimento all'utilizzo dei protocolli di comunicazione e autenticazione, l'importanza
   del problema della sicurezza impone, quando possibile, l'uso di tecniche già esistenti (e
   quindi testate). L'autenticazione di un utente o di una risorsa deve possedere le
   caratteristiche seguenti:


        ▪ Single sign on: L'utente, una volta autenticato, deve poter utilizzare più risorse
             Grid senza l'obbligo di autenticarsi ogni volta su ognuna di esse.
        ▪ Delega: I programmi devono sapere quali sono le risorse sulle quali l'utente è
             autorizzato ad effettuare operazioni, così da poterle utilizzare e avere la
             possibilità di delegare un po' di permessi a sottogruppi di altri programmi al
             fine di distribuire le esigenze di calcolo.
        ▪ Interazione con le procedure di sicurezza locale: In Grid, le procedure di
             sicurezza non devono sostituire quelle locali, cioè dei vari siti che mettono a
             disposizione le risorse, ma devono piuttosto interagire ed essere compatibili
             con esse.
        ▪ Relazioni di fiducia: Gli utenti utilizzano contemporaneamente risorse diverse
             senza la necessità che le procedure che gestiscono la sicurezza nei vari siti
             comunichino tra di loro.


   Resource: è il terzo layer del modello a clessidra dell'architettura Grid; si basa sui
   protocolli di comunicazione ed autenticazione forniti dal layer Connectivity. Questo
   layer si basa sui protocolli di comunicazione ed autenticazione forniti dal layer
   precedente per definire protocolli, API e SDK che agiscano su una singola risorsa.
   Si possono definire due classi di protocolli:




Del Prete Domenico 873/1                                                   Pagina 12 di 101
        ▪ Information protocols: Sono utilizzati per ottenere informazioni sullo stato di
            una risorsa, la sua configurazione e le sue politiche di accesso ed uso.
        ▪ Management protocols:. Sono utilizzati per negoziare l'accesso alle risorse
            attraverso la specificazione delle richieste dell'utente.


   Collective: è il quarto layer del modello a clessidra dell'architettura Grid e come
   specificato precedentemente, riguarda il coordinamento di collezioni di risorse;
   comprende quei componenti che, basati su quelli dei livelli precedenti, possono offrire
   una molteplice varietà di servizi, anche meno generali, ovvero rivolti a particolari VO.




 2. Sistemi di Storage in ambito GRID


    2.1 Problematiche ed esigenze di storage in ambito GRID

   In un Data Center l'architettura più semplice da configurare e da gestire viene espressa
   con una configurazione DAS, ovvero Direct Attached Storage [4]. I DAS sono
   dispositivi di immagazzinamento dati collegati direttamente a un server o a una
   workstation senza una rete a fare da tramite; alcune volte il termine DAS viene
   utilizzato principalmente per differenziare gli storage non collegati a una rete dagli
   Storage Area Network e dai Network Attacched Storage.


   Tra le architetture di storage il sistema DAS è stato uno dei primi sviluppati.
   Tradizionalmente sono delle estensioni alla capacità di immagazzinamento dati di un
   server che mantengono, nella maggior parte dei casi, alte prestazioni di trasferimento e
   accesso ai dati. I protocolli più utilizzati nella comunicazione con il server sono SCSI,
   SAS e Fibre Channel mentre l'interfacciamento avviene tramite un Host Bus Adapter.




Del Prete Domenico 873/1                                                  Pagina 13 di 101
                              Figura 2.1: Tipica struttura di una DAS



   Per garantire robustezza, affidabilità e velocità di accesso, i controller dei dischi
   implementano spesso delle struttura RAID (acronimo per Redundant Array of
   Indipendent Disks) i quali a seconda delle configurazioni possono garantire ridondanza
   (affidabilità) e velocità. Quando però il numero dei server cresce, riesce difficile gestire
   il numero dei    dischi, soprattutto se i dischi possono avere caratteristiche diverse,
   controller diversi e File System diversi. La connessione diretta al server utilizzata nei
   DAS presenta alcuni limiti non trascurabili:
       • l'accesso e la condivisione delle informazioni sono difficili da gestire;
       • l'espansione comporta numerosi problemi;
       • manca la flessibilità di configurazione;
       • è presente il coinvolgimento dei server nelle operazioni di trasferimento dati
          verso lo storage.

    Le unità di memorizzazione e il formato dei dati sono vincolati alla piattaforma a cui è
    connessa l'unità. Le elevate performance messe a disposizione dai server e dai
    dispositivi di memorizzazione non sono quindi pienamente utilizzabili, risultando
    spesso inadeguate rispetto alla crescente domanda di prestazioni richieste dalle
    applicazioni e dagli utenti. Le reti tradizionali utilizzano server e protocolli di rete


Del Prete Domenico 873/1                                                   Pagina 14 di 101
    per trasferire i dati da e verso i client. Questi trasferimenti occupano un'elevata
    larghezza di banda, cicli macchina della CPU e molta memoria. Risulta chiaro quindi
    che, ogni volta che si effettuano operazioni intensive di scrittura/lettura dei dati
    attraverso la rete le prestazioni generali di quest'ultima crollano.

    Per snellire le limitazioni dei DAS, si può ricorrere a soluzioni diverse come quelle
    SAN: Storage Area Network [5]. Esso si può generalizzare come disco di rete
    connesso ad alta velocità (generalmente almeno un Gigabit/sec); Più precisamente, il
    dizionario tecnico pubblicato dalla Storage Networking Industry Association (SNIA)
    definisce una rete SAN nei seguenti termini:

    «Una rete il cui scopo principale è il trasferimento di dati tra sistemi di computer ed
    elementi di storage e tra elementi di storage. Una rete SAN consiste in
    un’infrastruttura di comunicazione, che fornisce connessioni fisiche e in un livello di
    gestione, che organizza connessioni, elementi di storage e sistemi di computer in
    modo da garantire un trasferimento di dati sicuro e robusto.»

    L'architettura SAN lavora in modo che tutti i dispositivi di memorizzazione siano
    disponibili a qualsiasi server della rete LAN o MAN di cui la SAN in questione fa
    parte; una SAN può essere anche condivisa fra più reti interconnesse, anche di natura
    diversa: in tal caso uno dei server locali fa da ponte fra i dati memorizzati e gli utenti
    finali. Il vantaggio di un'architettura di questo tipo è che tutta la potenza di calcolo dei
    server è utilizzata per le applicazioni, in quanto i dati non risiedono direttamente in
    alcuno di questi.




Del Prete Domenico 873/1                                                    Pagina 15 di 101
                            Figura 2.2: Tipica struttura di una SAN



   In una rete SAN le periferiche di storage sono connesse ai server attraverso una
   topologia costituita essenzialmente da canali di comunicazione, (molto spesso in fibra
   ottica) da switch, router e bridge che in teoria consentono la coesistenza di sistemi e
   dispositivi di storage di natura eterogenea, sebbene nella pratica gli aspetti di
   interoperabilità costringano ancora a creare reti SAN omogenee. Questo permette di
   evitare un sovraccarico della rete dato che tutto il traffico è gestito da questi dispositivi.
   Normalmente una SAN utilizza dischi collegati con una struttura di tipo RAID per
   migliorare le prestazioni e aumentare l'affidabilità del sistema.
   I centri di calcolo devono poter accedere ai dati in modo rapido e sicuro e quindi la
   filosofia dell'architettura SAN è quella di poter integrare tutte le caratteristiche dei
   tradizionali sistemi di memorizzazione, ovvero:


           ◦ Alte prestazioni                                 ◦ Alta disponibilità

           ◦ Scalabilità                                      ◦ Facilità di gestione




Del Prete Domenico 873/1                                                       Pagina 16 di 101
   Tutto ciò, con le caratteristiche di connettività e accesso distribuito del network
   computing, fornisce un’architettura di rete dedicata alla gestione e archiviazione dei
   dati, in grado di non sovraccaricare i server nelle operazioni di scrittura e lettura dei
   dati, da e verso lo storage.




    2.2 Gli scopi funzionali dei sistemi di storage GRID

   Nell'ambito del Grid Computing troviamo che i numerosi sistemi di storage, siano essi
   distribuiti in ambito geografico o all'interno di una rete locale, vengono gestiti
   centralmente da un apposito software (middleware) che provvede a ridistribuirne on-
   demand le risorse. I componenti chiave di una Grid Storage comprendono un file
   system distribuito e tecnologie di virtualizzazione (per esempio sistemi RAID scalabili)
   che consentono di adattare l'approccio Grid all'ambiente storage. Gli elementi base di
   una struttura Grid Storage sono rappresentati dai cosiddetti storage brick (mattoncino di
   storage) costituiti da apparecchiature di storage che prevedono non solo capacità di
   archiviazione dei dati, ma anche capacità di calcolo e di comunicazione. Le capacità di
   calcolo dello storage brick gli consentono di ospitare l'apposito software di gestione e di
   connettersi all'ambiente Grid insieme a tutte le altre risorse che ne entreranno a fare
   parte.   L'inserimento    di   un   nuova   apparecchiatura   all'interno   della   Griglia
   Computazionale consisterà, quindi, semplicemente nell'aggiunta dell'apparato al pool di
   risorse storage, mentre le funzioni di amministrazione, autenticazione e assegnazione
   dei diritti saranno automaticamente gestiti dal software di controllo della Grid Storage
   che comunicherà con il software ospitato dalla nuova risorsa. L'aggiunta di nuovi
   storage brick, grazie alle caratteristiche di questi ultimi, consentirà quindi non solo di
   aumentare le capacità di spazio dati dell'intera griglia, ma anche le sue capacità di
   calcolo e comunicazione (connessione). E' come dire che l'intera struttura Grid eredita
   di volta in volta le caratteristiche peculiari di ogni nuovo elemento che ne entra a fare
   parte, una caratteristica sicuramente da non sottovalutare, considerate le esigenze di
   scalabilità e adattabilità richieste dalle moderne necessità aziendali di archiviazione e


Del Prete Domenico 873/1                                                  Pagina 17 di 101
   gestione dei dati. Le esigenze di Storage per Grid attualmente più richieste, riguardano
   sopratutto gli esperimenti scientifici del CERN di Ginevra (come quello di LHC - Large
   Hadron Collider [6]), per le attività di elaborazione dati e simulazioni.
   Gli esperimenti di LHC e in particolare di ATLAS (uno dei suoi rivelatori), producono
   più 10 Terabyte di dati al giorno, i quali vengono processati da un'infrastruttura estesa
   su 33 nazioni, dalle straordinarie capacità di calcolo: stiamo parlando di 20.000 server
   dedicati all'analisi e allo storage dei dati, ed il Data Center S.Co.P.E è tra i centri che
   stanno svolgendo un ruolo fondamentale.
   La struttura della Griglia Computazionale è divisa su diversi Tier [7] che rappresentano
   anche i diversi livelli attraverso i quali passeranno i dati e a seconda dei quali verranno
   elaborati. Una volta eseguito l'esperimento i dati arrivano direttamente nel Tier-0 del
   Cern, qui vengono elaborati e ridistribuiti agli altri centri “Tier1” della infrastruttura, 11
   in totale. I centri Tier-1 sono gli elaboratori dei dati grezzi, tutti collegati con link a
   10Gbps al Cern e interconnessi tra loro in una speciale rete.
   Completata l'elaborazione dai centri Tier-1, i dati vengono trasferiti ai centri Tier-2,
   come quelli del Data Center S.Co.P.E all'interno delle quali gli scienziati hanno la
   possibilità di analizzare i dati, utilizzando se necessaria anche la potenza di calcolo della
   rete Tier-1 per ulteriori ricerche.


   Gli step della fase di elaborazione seguono la seguente successione:
    I. Il Tier-1 riceve dal Tier-0 una frazione dei dati (raw) o di dati già sottoposti ad una
        prima fase di ricostruzione, e deve archiviarli.
    II. I dati vengono elaborati in loco per produrre dati in formato utile all’analisi.
    III. I dati da analizzare vengono inviati ai Tier-2 e agli altri Tier-1.
    IV. Da i Tier-2 viene effettuata la produzione Montecarlo (simulazione MC) ma
        archiviata nel Tier-1, che provvede anche a smistarli verso gli altri Tier.
    V. Il Tier-1 deve anche essere dotato di risorse con cui effettuare l’analisi.


        .




Del Prete Domenico 873/1                                                       Pagina 18 di 101
    2.3 La gestione dello Storage nel Data Center

   Gran parte dello storage del Data Center S.Co.P.E è gestito mediante SRM [8] che è
   l'acronimo di Storage Resorce Manager, ed è un interfaccia che garantisce
   l'interoperabilità nell'interazione trasparente con i diversi tipi di Storage Element ed i
   diversi protocolli che essi implementano.
   I concetti chiave di SRM riguardano sopratutto:
        ▪ Il tempo di vita di un file
            Indica le modalità di preservazione dello stesso (es. volatile con lifetime
            prestabilito, permanente).
        ▪ Blocco del file
            Garantisce la consistenza, assicurando che il file non venga modificato durante
            le operazioni su di esso
        ▪ Pre-allocazione di spazio
            Garantisce una certa quantità di spazio necessaria all'operazione sul file per
            tutta la sua durata
        ▪ Classi di qualità
            Differenziano le diverse qualità di memorizzazione che è possibile garantire
            (es. disco o altro).


   Le funzionalità che fanno di SRM uno strumento indispensabile sono:
    ◦ La gestione dei dati: Preparazione dell'ambiente per le operazioni di accesso e di
        ricevimento dei dati
    ◦ La gestione dello spazio: Conservazione dello spazio necessario per la buona
        riuscita di un'operazione di scrittura
    ◦ Gestione delle Directories: Possibilità di operare sulle “dirs” (es. creazione,
        rimozione, modifica) alla maniera di UNIX
    ◦ Funzioni di richiesta: Possibilità di essere informati su un'implementazione SRM e
        delle sue caratteristiche




Del Prete Domenico 873/1                                                 Pagina 19 di 101
   SRM fornisce le sue funzionalità in due modalità differenti:
        •   Metodi asincroni (non bloccanti)
            Ad ogni richiesta corrisponde un gettone, l'agente usa il gettone per
            referenziare quel tipo di operazione (es. richiedere lo stato di un'operazione di
            gestione sullo spazio)
        •   Metodi sincroni (bloccanti)
            L'operazione SRM dev'essere completata prima di ridare il controllo
            nuovamente all'agente (es. richiedere la creazione di una “dir” o di preallocare
            dello spazio.


    StoRM [8] implementa in un ambiente GRID una soluzione SRM v.2.2 capace di
    sfruttare le potenzialità sia dei “cluster file system” che di quelli standard POSIX più
    semplici. Il suo ruolo fondamentale riguarda la sottomissione di JOB, il trasferimento
    dati e i servizi di management dello storage:




                            Figura 2.3: le comunicazioni SRM nella Grid



   StoRM permette la singola implementazione SRM per differenti sistemi di
   memorizzazione in un sito. Rende facilitata l'evoluzione da sistemi iniziali semplici (es.
   disco rigido del calcolatore) a sistemi più complessi (es. Sistemi paralleli a più
   dispositivi). E' molto efficiente ed è capace di prestazioni eccellenti nell'esecuzione di
   richieste SRM, tutto questo senza introdurre nessun ulteriore livello di latenza, inoltre e
   sicuro perchè possiede un meccanismo gerarchico basato sulle credenziali VOMS.


Del Prete Domenico 873/1                                                  Pagina 20 di 101
   StoRM è adattabile a diverse soluzioni, infatti è stato progettato per gestire sistemi
   complessi di “file system” ma allo stesso tempo è
   adattabile anche in siti Grid di piccole dimensioni;
   fa uso di protocolli “Grid standard” e implementa i
   protocolli di trasferimento più largamente usati nel
   contesto Grid (come per esempio gsiftp e rfio)
   Integra   le   funzionalità   VOMS,      quindi,   ha
   autenticazione e autorizzazione sono basati sulle
   credenziali VOMS. Fa uso di “Access Control
   List” (ACLs)      che agisce a livello fisico sui
   permessi per “files” e “directories”. Inoltre, cosa
   molto importante, supporta diversi File system,
   facendo uso di “driver” caricabili al momento
   della configurazione del servizio.                      Figura 2.4: Interazione StoRM - filesystem



   A livello di Frontend (FE) espone un'interfaccia “web service”. Gestisce la
   connessione con gli agenti e l'autenticazione degli utenti, salva le richieste asincrone in
   un “database” MySQL e comunica con il “backend” in caso di richieste sincrone,
   inoltre, recupera le richieste di stato da mostrare.


   Il livello di Backend (BE) rappresenta il cuore del funzionamento di StoRM, difatti
   gestisce tutte le richieste (sincrone e asincrone), autentica gli utenti per l'uso in locale
   del servizio e interagisce con altri servizi Grid (servizio informativo), ed infine carica il
   “driver” necessario al “file system” utilizzato. A rendere tutto quanto descritto molto
   efficiente, è obbligatorio l'uso di un file system parallelo scalabile. Il file system più
   usato per sistemi paralleli è GPFS [9] (General Parallel File System). GPFS è un file
   system commerciale sviluppato da IBM; ha buone caratteristiche di affidabilità sfruttate
   ancora meglio in infrastrutture SAN, bilanciamento del carico che migliora grazie alla
   parallelizzazione, inoltre è scalabile riuscendo a gestire 1024 nodi. In alternativa a
   GPFS c'è LUSTRE File System [10] offerto dalla SUN Microsystem.



Del Prete Domenico 873/1                                                        Pagina 21 di 101
   LUSTRE è un file system distribuito object-based ed è ideale per applicazioni che
   richiedono il massimo di performance sul I/O (centinaia di gigabyte al secondo), in
   grado di supportare fino a decine di migliaia di sistemi Client e Petabytes di stoccaggio
   disco. LUSTRE ha caratteristiche molto superiori rispetto a GPFS di IBM ed è open
   source, aspetto da non sottovalutare, anche per questo motivo si rivela ad hoc per la
   soluzione del Data Center.


   Lustre File System ha tre principali funzionalità:
        ▪ Un unico MetaData Target (MDT) per filesystem che memorizza i metadati,
            come ad esempio i nomi dei file, directory, permessi e file di configurazione.
        ▪ Uno o più Object Storage Targets (OSTs) per la memorizzazione su uno o più
            Object Storage Servers (OSSes). A seconda del tipo di server, un OSS
            tipicamente gestisce tra i due e gli otto targets e ciascun target (disco locale)
            può essere grande fino a 8 Terabyte.
        ▪ L'accesso ai dati da parte dei Client(s). Lustre si presenta ai Client con standard
            POSIX, accede ai file del file system in modalità concorrente, sia in lettura che
            in scrittura.


   Metadata Target, Object Storage Target e Client, possono essere installati sullo stesso
   nodo, ma     anche su nodi differenti; nelle tipiche installazioni queste funzionalità
   vengono disposte in nodi separati, da due o a quattro OSTs per ogni nodo OSS.
   LUSTRE supporta diversi tipi di rete, compresi Infiniband, il protocollo TCP / IP su
   Ethernet, Myrinet, Quadrics, e altre tecnologie proprietarie, inoltre, trae vantaggio su
   trasferimenti da remoto con accesso diretto alla memoria (RDMA) per migliorare il
   throughput e ridurre l'utilizzo della CPU. Quando un Client accede a un file, viene
   effettuata una ricerca sul MDS il quale propone le disponibilità al Client.
   Per le operazioni di lettura e scrittura, il Client passa le informazioni ricevute dall'MDS
   al Logical Object Volume (LOV), che mappa gli offset e le dimensioni di uno o più
   oggetti che risiedono sul OST. In questo modo il Client può gestire operazioni di lettura
   e scrittura in modo concorrente comunicando direttamente con gli OSTs.



Del Prete Domenico 873/1                                                  Pagina 22 di 101
   In questo modo si riesce a scalare quasi linearmente la strozzatura sulla banda che
   riporterebbero i Client per accedere ai dati. I Client non possono modificare
   direttamente gli oggetti di dati sul OST, ma devono delegare il compito agli OSS.
   Questo approccio garantisce la scalabilità per cluster e supercomputer di grandi
   dimensioni, miglioramento anche sicurezza e affidabilità. Contrariamente, i filesystem a
   blocchi condivisi, consentono l'accesso diretto ai dati a tutti i Client, rischiando di
   corrompere il filesystem, creando anche colli di bottiglia.


    Tutte le differenze essenziali sono espresse dalla seguente tabella:

            Aspetti                     LUSTRE                             GPFS
            Licenza                   Open Source                       Propretaria
       Tipo di soluzione                Software                 Generamente fornita con
                                                                      hardware IBM
                                  Numerosi partners:
         Procurabilità           Cray, Dell, HP, DDN,                       IBM
                              Hitachi, Terascala, Red Hat,
                                        and SUSE
      Scalabilità (numero                >25,000                            1024
           di Client)
        Reti supportate       La maggior parte delle reti        IP, InfiniBand, Federation
          Architettura               Object Storage              Tradizionale, architettura
                                      Architectture               VAX cluster file system
                                Integrata, con numerose
         Modificabilità         nuove tipologie di rete e                  Assente
                                apparecchiature storage




Del Prete Domenico 873/1                                                   Pagina 23 di 101
   L'organizzazione complessiva è stata pensata in modo da far convivere al meglio tutte le
   tecnologie descritte fin ora. Esse possono essere semplificate secondo questo schema:




                      2.5: configurazione complessiva LUSTRE - S.Co.P.E




Del Prete Domenico 873/1                                                  Pagina 24 di 101
    2.4 La possibilità di utilizzare NAS Server in ambito GRID

   I NAS server sono unità di memorizzazione dotate di hardware e software generalmente
   embedded, il cui scopo è quello di decentralizzare completamente i dati presenti su vari
   Client della rete, consentendo a chi ne fa parte, di poterne usufruire in qualsiasi
   momento, indipendentemente dalla presenza o meno degli altri Clients in rete. In questo
   modo vine rivoluzionato il concetto di Client/Server in passato utilizzato per una
   classica forma di condivisione. Questa architettura ha il vantaggio di rendere disponibili
   i file contemporaneamente su diverse piattaforme come ad esempio Linux, Windows e
   Unix (o Mac OSX), in quanto il sistema operativo implementa i server di rete per tutti
   gli standard più diffusi quali ad esempio FTP, Network File System (NFS) e Samba per
   le reti Windows. Spesso i NAS prevedono la possibilità di espandere la memoria di
   massa centrale attraverso l’impiego di unità di memoria aggiuntive, come ad esempio
   dei comunissimi dischi esterni USB, delle pendrive o addirittura possono prevedere
   funzionalità aggiuntive come l’implementazione di funzionalità print-server ed ftp-
   server: quest’ultima feature può essere utilizzata su alcuni modelli, sia in locale che da
   remoto, permettendo anche a chi non risiede fisicamente nel luogo in cui il NAS si trova
   di poter gestire i propri files da postazioni remote.


   Le unità in questione sono visibili all’interno delle comuni risorse di rete, proprio come
   se si trattasse di un normale PC che condivide i propri dati all’interno della LAN ma
   con il notevole vantaggio derivante dal fatto che non esistono più relazioni di
   dipendenza da una macchina costantemente accesa quale è il personal computer. In
   realtà i vantaggi sono molto superiori e non si limitano alla sola condivisione, ma
   entrano in gioco anche fattori di fondamentale importanza, come la sicurezza dei dati
   (RAID) e l’accesso differenziato ai dati stabilito in base a delle credenziali di
   autorizzazione.




Del Prete Domenico 873/1                                                  Pagina 25 di 101
                             Figura 2.6: il collegamento di una NAS



   L’importanza di avere un unità di stoccaggio esterna è un vantaggio rilevante, in quanto
   garantisce la veloce disponibilità in piena sicurezza di tutti i dati. Questa sicurezza deve
   essere garantita sicuramente da un sistema RAID, sia questo in modo particolare
   RAID1, copia speculare dell’hard disk utilizzato per i dati, o meglio ancora RAID 5,
   dove le informazioni vengono distribuite su due hard disk mentre un terzo è occupato
   dai dati di parità che permettono la ricostruzione, in caso di danneggiamento, di un hard
   disk dei tre collegati per il RAID 5.


   Nell'ambito della Griglia Computazionale, il vantaggio dei NAS è la possibilità di
   accogliere grosse quantità di dati con una infrastruttura più semplice di quella di una
   SAN. Una volta che i dati sono stati depositati nel NAS, questi risulteranno subito
   visibili a tutti gli utenti che hanno la facoltà di accesso alla risorsa. In questo modo le
   informazioni possono essere prelevate ed elaborate in modo molto semplice e pratico,
   dai server che li utilizzano decentralizzando il carico delle informazioni non più sulle
   singole unità di lavoro, ma su spazi condivisi, con la possibilità di accesso, in tutta
   trasparenza, senza trascurare la sicurezza. La gestione dei dati in questo modo risulta
   molto efficace, porta poi una notevole stabilità nell'organizzazione di lavoro e
   contribuisce ad aumentare la produttività.



Del Prete Domenico 873/1                                                   Pagina 26 di 101
    2.5 Le attrezzature prese in esame:
                       Synology DS 508 & LACIE ethernet disk


   Le apparecchiature prese in esame sono due sistemi embedded forniti di hardware e
   software ad hoc progettati appositamente per erogare i servizi previsti dalla casa
   produttrice del dispositivo.


   LACIE ethernet disk nativamente si avvale del sistema operativo incorporato Windows
   XP Embedded che fornisce tutte le funzioni necessarie per il backup dei dati, la
   memorizzazione e la condivisione di file tramite la connessione Gigabit Ethernet. Una
   funzionalità chiamata Active Directory riesce a supportare fino a 100 utenti con la
   possibilità di personalizzare i diritti di accesso per un massimo di 25 utenti simultanei;
   l'unità è installabile in rack da 19" in configurazione 1U (One Unit per Rack) e dispone
   di 4 Terabyte di spazio disco (Altre informazioni tecniche del prodotto sono disponibili
   nell'Appendice N°1).


   Caratteristiche rilevanti:


         Interfaccia                         1 porta Gigabit Ethernet da 10/100/1000 Mbit/s

          Capacità                                   Max 4 Terabyte (4 dischi EIDE)

      Protocolli di rete   SMB (Windows), AFP (Mac), FTP, HTTP, Bonjour e LaCie Network Assistant per Mac
                                                                   e PC
             OS                                         Windows XP® Embedded

     Porte di espansione           4 porte USB 2.0; 1 porta VGA; 1 porta per mouse, 1 porta per tastiera

    Gestione periferiche      Localmente tramite interfaccia dedicata oppure tramite opzione basata sul Web

     Processore / RAM                     VIA C7 da 1 GHz / RAM DDR da 256 MB o superiore

           Utenti                           Supporto per un massimo di 25 utenti concomitanti

     Protezione dei dati          Motore di backup incorporato per il backup su unità DAS o NAS esterne




Del Prete Domenico 873/1                                                                 Pagina 27 di 101
                                 Figura 2.7: LACIE ethernet disk




   Le funzionalità nativamente fornite dal sistema LACIE ethernet disk, sebbene ricercate
   in ambito aziendale, si sono rivelate poco adatte all'essere integrate nel sistema di
   storage preesistente. Per ovviare questo problema si è ricorso all'installazione di un
   sistema operativo Linux-based diverso da quello fornito dalla casa produttrice, ovvero
   FreeNAS, il quale supporta la maggior parte dei servizi richiesti dall'ambiente di
   calcolo. Nonostante ciò, l'hardware del sistema LACIE non ha permesso l'espandibilità
   di nuovi servizi molto importanti in ambito Grid, proposti anche come obiettivo di tesi
   (come per esempio quello del GridFTP).


   Con la “non espandibilità” ci si riferisce sopratutto all'impossibilità di compilazione o
   cross-compilazione di applicazioni, che normalmente non sono fornite in modo nativo
   dall'apparecchiatura. Queste limitazioni hardware hanno permesso di focalizzare le
   attenzioni verso un dispositivo di simile tipologia, ma molto diverso nella composizione
   hardware e software, si tratta del sistema NAS Synology DS 508.


   Il Synology DS 508 è un NAS Server che può alloggiare cinque dischi interni SATA II
   da 3,5 pollici in hot swap (estraibili e sostituibili a caldo, ovvero durante il
   funzionamento) dalle caratteristiche molto interessanti, le sue prestazioni lo rendono
   uno strumento molto efficiente sia per funzionalità di condivisione che di backup. (Altre
   informazioni tecniche del prodotto sono disponibili nell'Appendice N°2)




Del Prete Domenico 873/1                                                 Pagina 28 di 101
                                     Figura 2.8: Synology DS 508




   Caratteristiche rilevanti:


           Interfaccia                         2 porta Gigabit Ethernet da 10/100/1000 Mbit/s

            Capacità                                   10 Terabyte (5 dischi SATAII)

        Protocolli di rete                    CIFS, AFP (3.1), FTP, Telnet/SSH, HTTP, SMB

               OS                                            Linux embedded

     Porte di espansione                   2 porte USB 2.0; 1 porta e-SATA, 2 Lan; 1 porta COM

    Gestione periferiche                  Tramite SSH, Telnet, Web: AJAX-based Management UI

     Processore / RAM                        PowerPC 800Mhz e500v2 / RAM DDR da 512 MB

             Utenti          Ma user accont: 2048, Max group 256, max shared folder 256, 512 utenti concorrenti
                                                             (SMB, FTP, AFP)
     Protezione dei dati                              Network backup, Local backup




   Le prestazioni sono governate da un sofisticato sistema di Management molto valido
   (Synology Disk Station Manager) che permette di amministrare le funzionalità offerte
   dal sistema in maniera dinamica e semplice. Il DS 508 fornisce una soluzione ideale per
   la condivisione multi-piattaforma (cross platform sharing), permettendo l'accesso ai dati
   a tecnologie con diverso sistema operativo, non compromettendo la sicurezza dei dati.
   L'apparecchiatura fornisce diversi aspetti funzionali, tra i quali:
    •     IT Management
   Questo NAS riesce a gestire diversi tipi di volumi, da quello base a quello RAID
   0/1/5/6, permette di dedicare spazi disco differente a seconda degli user, in modo da


Del Prete Domenico 873/1                                                                 Pagina 29 di 101
   gestire lo spazio in modo efficiente e sicuro, inoltre operazioni più avanzate permettono
   l'espansione e / o il cambiamento di un unità RAID in modo da venire incontro alle più
   svariate   esigenze     di    flessibilità   e    management       di     spazio    disco.
   Il Sistema supporta funzionalità di S.M.A.R.T. (Self-Monitoring, Analysis, and
   Reporting Technology) che permette di rilevare e fornire diversi indicatori di
   affidabilità, nella speranza di anticipare i malfunzionamenti. La funzione di Link
   Aggregation prevede azioni di sostegno di carico e di failover permettendo affidabilità
   anche sulla connessione.


    •   Pratica scalabilità
   Se le attività di lavoro richiedessero ulteriore spazio per i loro dati, si ha la pratica
   possibilità di espandere lo spazio disco aggiungendo nuovo storage direttamente
   sull'apparecchiatura grazie alla comodissima connettività e-SATA (connessione Serial
   ATA esterna)


    •   Backup polivalente
   E' possibile effettuare operazioni di salvataggio dati sia verso un'altra apparecchiatura
   identica che verso altre apparecchiature predisposte; si possono effettuare backup
   simultanei sia verso cartelle condivise che su dischi esterni collegati tramite USB
   (Universal Serial Bus) oppure e-SATA.




Del Prete Domenico 873/1                                                   Pagina 30 di 101
 3. I protocolli di trasferimento in ambito GRID

    Le informazioni prodotte dagli esperimenti scientifici richiedono l'esigenza di
    trasferimento e accesso a grandi quantità di dati (nell'ordine di Terabyte e Petabyte) tra
    e verso vari sistemi di storage, spesso distribuiti in aree geograficamente molto distanti
    tra loro. Per permettere ciò, ci sono delle aree di storage dedicate proprio a queste
    esigenze specifiche, per il trasferimento e l'accesso a grandi dataset. Questi includono
    Distributed Parallel Storage System (DPSS) e la High Performance Storage System
    (HPSS), che forniscono alte prestazioni sull'accesso ai dati, utilizzando il trasferimento
    dei dati in parallelo e / o striping su più server. I protocolli più usati nell'ambito delle
    griglie computazionali sono:


             FTP                    SCP                  BBFTP                 GridFTP




    3.1 FTP (File Transfer Protocol)

   FTP (File Transfer Protocol) [11] è il protocollo generalmente utilizzato per trasferire
   dati tra due host. Il protocollo di trasferimento dati FTP viene descritto nella RFC 959;
   l'obbiettivo per cui è stato sviluppato è il trasferimento affidabile ed efficiente dei dati,
   per questo motivo si basa TCP. In particolare un FTP Server rimane in attesa di
   connessioni sulla porta 21, i comandi utilizzati sono di tipo case-insensistive, possono
   essere   seguiti   da    argomenti     e   sono    terminati    da   un    CRLF      (Invio).
   FTP utilizza due processi distinti per compiere il proprio compito:
        •   PI (Protocol Interpreter) attraverso cui il client invia i comandi e riceve le
            risposte dal server.


        •   DTP (Data Transfer Process) attraverso il quale il client ed il server si
            scambiano i dati;




Del Prete Domenico 873/1                                                     Pagina 31 di 101
    Il Data Transfer Process può essere di due tipi Active MODE (default) o Passive
    MODE.

    Nella modalità Active Mode il client contatta il server il quale da inizio alla
    connessione     (sulla    porta     21)      per   trasmettere    i   dati       al   client.
    Nella modalità Passive Mode è prerogativa del client anche dare il via alla
    connessione per il trasferimento dei dati.

    Le fasi di una sessione FTP sono:
    FASE 1: Il client contatta il server sulla porta 21 utilizzando il processo PI
    FASE 2: Autenticazione del client
    FASE 3: Trasferimento dati attraverso tramite il DTP
    FASE 4: Termine della sessione TCP

   Il protocollo FTP permette anche la possibilità di sessioni FTP anonime, situazione
   tipica di un file server pubblico dove per esempio viene reso disponibile software per il
   download. In questo caso al client, a cui viene richiesto username anonymous e come
   password il proprio indirizzo email, viene permesso l'accesso in sola lettura.
   Per FTP, come per altri protocolli, sono stati sviluppati client di tipo grafico per
   facilitare il trasferimento di file da parte degli utenti. Inoltre File Transfer Protocol è
   supportato anche sui comuni browser web.




Del Prete Domenico 873/1                                                   Pagina 32 di 101
    3.2 SCP (Secure Copy)

   SCP [12] è anch'esso un protocollo di file trasfer, ma a differenza di FTP i dati sono
   criptati durante i trasferimenti, per evitare che con un processo di sniffing (attività di
   intercettazione passiva dei dati) vengano estratte informazioni utilizzabili dai pacchetti
   di dati. Il protocollo in sé non fornisce autenticazione e sicurezza, ma si affida al
   sottostante protocollo SSH (un protocollo che permette di stabilire una sessione remota
   cifrata ad interfaccia a linea di comando con un altro host) per fornire le caratteristiche
   sopra descritte. Il protocollo SCP implementa solo il trasferimento del file. Esso ci
   riesce connettendosi all'host usando quindi SSH e là esegue un SCP del server. Il
   programma SCP del server è tipicamente lo stesso programma SCP del client.


    ◦ Per effettuare upload, il client fornisce al server i file da essere uploadati,
        opzionalmente includendo i loro attributi di base (permessi, timestamps). Questo è
        un vantaggio rispetto al comune protocollo FTP, che non fornisce al file finale sul
        server gli attributi del file originario “data originaria/timestamp”.


    ◦ Per effettuare download, il client manda una richiesta per i file o directory da
        scaricare. Quando si scarica una directory, il server fornisce al client le sue sotto-
        directory e i file. Il download è quindi server-driven, che implica un rischio di
        sicurezza quando ci si connette ad un "malicious server" (server che si sostituisce
        in modo fraudolento a quello desiderato).




Del Prete Domenico 873/1                                                    Pagina 33 di 101
    3.3 BBFTP (BaBar File Transfer Protocol)

   BBFTP [13] si può ritenere attualmente il secondo protocollo (in ordine di rilevanza) di
   file transfer usato in Grid; esso è ottimizzato per trasferimenti di grandi dimensioni di
   dati, molto sicuro perché crittografa le informazioni di connessione. Nei protocolli di
   trasmissione seriali (come ftp) un nuovo pacchetto viene spedito solo quando la
   consegna del precedente è stata completata. Durante la trasmissione le CPU dei nodi
   mittente e destinatario rimangono inattive, mentre nei protocolli di trasmissione
   paralleli (come BBFTP) si effettua la spedizione contemporanea di più stringhe in
   quantità configurabile dall’utente. Alcuni meccanismi che esso sfrutta sono applicati
   anche dal GridFTP e per questo motivo li analizzerò più avanti.
    Le principali caratteristiche sono:


        ▪ Codifica Username e Password alla connessione
        ▪ Moduli di autenticazione tramite SSH
        ▪ Trasferimento su flussi paralleli di grandezza arbitraria
        ▪ compressione dati “on fly” (durante la trasmissione)
        ▪ Regolazione finestra di trasferimento TCP (definita in RFC1323)
        ▪ Simulazione trasferimenti
        ▪ Integrazione con autenticazione AFS




    3.4 GridFTP

    IL GridFTP [14] è il protocollo più usato per effettuare trasferimenti in ambito GRID.
    Esso è sicuro e affidabile (usa i protocolli di sicurezza del Connectivity Layer e rientra
    tra i servizi Core offerti dal Middleware), è ottimizzato per effettuare trasferimenti dati
    su larga scala per grandi distanze (high-bandwidth wide-area networks), estende gli
    standard del protocollo FTP con funzionalità aggiuntive, come il trasferimento


Del Prete Domenico 873/1                                                   Pagina 34 di 101
    multicanale, autotuning e la sicurezza fornita da Globus che analizzerò a breve. In
    più, rispetto a tutti i protocolli trasferimento descritti fin ora, fornisce un efficiente
    sistema di autenticazione tramite certificati e l'autenticazione tramite un server proxy.
    Il GridFTP offre:


    ● Compatibilità e supporto GSI (Grid Security Infrastructure) e Kerberos
    Autenticazione robusta e flessibile, l'integrità e la riservatezza sono caratteristiche
    importanti durante il trasferimento o l'accesso ai file; GridFTP garantisce la sicurezza
    imposta dall'infrastruttura Grid (GSI) con l'autenticazione Kerberos (protocollo di rete
    per        l'autenticazione            tramite            crittografia)     e        mediante
    l'attuazione di meccanismi di autenticazione della GSSAPI definito dalla RFC 2228,
    “FTP Security Extensions”. Kerberos è un protocollo di autenticazione di rete che
    richiede regole ben precise di sicurezza (da qui il nome, che si ispira ad una figura
    mitologica Greca) e fa uso di metodi di crittografia. Sebbene sia usato in molte
    applicazione commerciali, un'implementazione gratuita ne è stata realizzata dal MIT
    (Massachusetts Institute of Technology).


    ● Third-party control of data transfer
    Per controllare grandi insiemi di dati di comunità distribuite, GridFTP offre uno strato
    di sicurezza che permette di controllare i trasferimenti tra storage e servers. Da questo
    deriva il supporto del “trasferimento tramite terzi” ovvero, si ha la garanzia del
    trasferimento di dati tra due storage server operato e controllato da un utente o
    un'applicazione “third-party” .




                        Figura 3.1: Controllo del trasferimento tramite terzi


Del Prete Domenico 873/1                                                        Pagina 35 di 101
    ● Parallelismo del trasferimento dati
    È possibile utilizzare l'uso contemporaneo di più flussi (stream) TCP (Transmission
    Control Protocol) rendendo possibile il collegamento e lo scambio affidabile (reliable)
    di dati tra due host.




                      Figura 3.2: L'operazione di suddivisione degli stream



    ● Striping del trasferimento
    Più coppie di endpoint possono concorrere ad un unico trasferimento logico (con una
    sola connessione di controllo). Trasferimenti di dati attraverso più stream richiedono la
    necessità di “spezzettare” i file in questione prima del trasferimento per poi ricostruirli
    a trasferimento avvenuto.




                     Figura 3.3: il meccanismo di funzionamento dello striping




Del Prete Domenico 873/1                                                         Pagina 36 di 101
    ● Regolazione della negoziazione del Buffer TCP
    GridFTP estende il set di comandi FTP standard permettendo l'impostazione manuale
    e automatico delle dimensioni del buffer di negoziazione TCP, per incrementare il
    rendimento di trasferimento di file di grandi dimensioni e grandi quantità di file di
    piccole dimensioni.


    ● Trasferimento parziale di file
    Può essere utile molto spesso trasferire in locale solo la parte di dati che interessa
    l'utente; il protocollo fornisce i meccanismi per “ritagliare” sottoinsiemi di dati da
    grandi database.


    3.4.1 GridFTP tramite GlobusToolkit

    Il protocollo GridFTP è stato sviluppato dal progetto Globus (Globus Alliance)
    dell’Argonne National Laboratory in collaborazione con l’University di Chicago e
    University of southern California’s Information Sciences Institute (è un progetto open
    source, disponibile sul sito http://www.globus.org). Globus permette di condividere
    risorse di calcolo, dati, database ed applicazioni tra istituzioni in modo sicuro,
    preservando l’autonomia organizzativa, gestionale ed amministrativa di ogni singola
    organizzazione. L’architettura del GlobusToolkit è modulare e indirizza alcune delle
    problematiche presenti in un ambiente di grid
    computing.     Tale    architettura   può    essere
    rappresentata come una struttura a tre pilastri con
    un basamento comune,(come illustrato nella figura
    seguente). Ogni singolo pilastro rappresenta un
    servizio che abilita l’utente a utilizzare la Grid o
    l’amministratore a gestirla.



                                                           Figura 3.4: Architettura Globus Toolkit




Del Prete Domenico 873/1                                                      Pagina 37 di 101
    I servizi offerti sono:


    ◦ gestione delle risorse


    ◦ gestione del sistema informativo


    ◦ gestione dei dati.

    Il basamento che sorregge tutta l’infrastruttura rappresenta il servizio di sicurezza.
    Prima di entrare nel dettaglio del GSI (Grid Securuty Interface), descriverò due
    concetti fondamentali che riguardano i servizi Grid ovvero OGSA e OGSI [15].

    L’Open Grid Service Architecture (OGSA) definisce le caratteristiche fondamentali
    che una Grid dovrebbe avere; definisce il modello di programmazione, fornisce
    informazioni su come costruire un servizio, ed infine precisa quali sono le componenti
    essenziali per costruire e distribuire un valido prodotto di Grid (OGSA da una
    descrizione di una griglia computazionale dal punto di vista fisiologico).

    L’Open Grid Service Infrastructure (OGSI), utilizza tecnologie che sono alla base dei
    Grid e Web Services, definisce i meccanismi per la creazione, la gestione e lo scambio
    di informazioni tra i Grid Service stessi. Le specifiche di OGSI estendono gli schemi
                                                      WSDL (Web Services Description
                                                      Language)     e    XML     (eXtensible
                                                      Markup Language) definendo un
                                                      servizio Grid come un servizio web
                                                      che obbedisce a regole ben precise in
                                                      merito alle modalità di interazione
                                                      con gli utenti. L'insieme di queste
                                                      convenzioni    è   fondamentale    per
                                                      l'utilizzo affidabile e sicuro che le
                                                      applicazioni distribuite richiedono ai

               Figura 3.5: Interazione Grid Service
                                                      servizi.


Del Prete Domenico 873/1                                                 Pagina 38 di 101
 4. Gli obiettivi della tesi

    4.1 Alternativa a sistemi di storage costosi e complessi

    Le esigenze di storage rappresentano già da qualche anno un tema molto caldo. Con
    l'avvento della multimedialità e di tutti i servizi digitali, il general pourpose (la massa
    e l'utenza comune) rappresenta senza dubbio la categoria con esigenze più svariate, tra
    queste abbiamo la domanda di spazio digitale che accresce giorno dopo giorno, sia da
    parte dell'utente che da chi offre i servizi stessi. Il prezzo dell'hardware di storage
    percorre una crescita inversamente proporzionale rispetto allo spazio offerto, ma
    nonostante ciò la domanda di spazio sembra non cessare, questo concetto
    fondamentale riguarda sia la massa che i gestori di servizi, ma sopratutto i centri di
    calcolo. Inoltre già da tempo è emersa l'esigenza di garantire la protezione dei dati
    sopratutto nel settore scientifico, oltre che quello pubblico e privato. L'aumento del
    numero di notizie sulla perdita di dati importanti ha dimostrato i rischi a cui sono
    sottoposte le informazioni quando non vengono adottate le procedure adeguate e non
    viene impiegata la tecnologia appropriata per assicurarne una minore vulnerabilità. Per
    tale motivo negli anni a venire si assisterà ad una sempre più crescente domanda di
    storage. I grafici mostrano l'aumento della densità di registrazione degli HDD negli
    ultimi 20 anni (figura 4.1) e il Miglioramento del rapporto prezzo-prestazioni delle
    tecnologie di microprocessore, registrazione e comunicazione (figura 4.2)




      Figura 4.1: densità di registrazione       Figura 4.2: rapporto prezzo/prestazioni tecnologie



Del Prete Domenico 873/1                                                           Pagina 39 di 101
   Se da un lato l'hardware per lo storage ha prezzi sempre più accessibili, dall'altro c'è
   l'aumento del costo di gestione, che proprio a causa della grande mole di spazio da
   gestire, impone ai gestori di servizi e a centri di calcolo, sistemi di storage che seguano
   standard architetturali molto più complessi rispetto a quelli utilizzati negli anni passati;
   tutto questo ha fatto si che il costo complessivo dello storage salisse molto di più per chi
   ha l'onere sulla gestione dei Data Center, sia dal punto di vista industriale che
   scientifico. Considerando il TCO, (Total Cost of Ownership) si stima che negli ultimi
   anni la crescita delle esigenze di storage sia stata del 68%, ma i costi di gestione sono
   cresciuti sette volte più velocemente.
   Proprio in questo si inseriscono varie soluzioni di sistemi di storage, di varia tipologia,
   pronte a sostenere problematiche discusse fin ora. Come ho già accennato in
   precedenza, il centro di calcolo S.Co.P.E. svolge un ruolo fondamentale nell'ambito
   della ricerca scientifica. Uno dei ruoli più importanti sostenuti dalle apparecchiature di
   storage del Data Center è la ricezione di grandi quantità di dati provenienti da altri
   centri di calcolo che effettuano una prima analisi e rielaborazione delle informazioni.
   Per supportare la ricezione della grosse quantità di dati, il    Data Center dispone una
   SAN composta da dieci Server Dell 2950 (Appendice N° 2) visti dalla griglia
   computazionale come Storage Element che accolgono informazioni sfruttando
   soprattutto il protocollo GridFTP. Queste apparecchiature possiedono un elettronica
   molto evoluta, permettono un'integrazione scalabile, capace di raggiungere prestazioni
   molto elevate; proprio per questo motivo sono apparecchiature molto costose,
   implementate per riflettere una configurazione ben precisa, pronte a rispondere anche a
   esigenze di investimento tecnologico futuro.
   Quella appena descritta però non può essere considerata l'unica soluzione, infatti
   l'esigenza di file transfer, può essere affrontata anche con apparecchiature molto meno
   costose ma non per questo meno adatte oppure meno efficienti. Le attrezzature che
   possono essere prese in considerazione sono i sistemi NAS, i quali offrono una grande
   finestra di servizi adatti a soddisfare svariate esigenze anche in ambito scientifico.
   L'acquisto di sistemi NAS comporta sicuramente una spesa inferiore rispetto la
   progettazione e realizzazione di una SAN, soprattutto in termini di risorse umane,



Del Prete Domenico 873/1                                                   Pagina 40 di 101
   interne ed esterne. Un NAS può essere una scelta interessante anche per chi non vuole
   investire su tecnologie relativamente nuove come quelle delle SAN, ma preferisce un
   approccio più semplice.


    4.2 La scelta dell'apparecchiatura NAS: Synology DS 508


   Il Primo obiettivo della tesi che mi è stato proposto è stato quello di permettere
   l'integrazione di apparecchiature NAS nell'infrastruttura S.Co.P.E. Come ho già
   descritto, la maggior parte delle apparecchiature NAS sono composte da software ed
   hardware embedded che permettono il solo funzionamento e la sola erogazione di
   servizi che sono stati contemplati nella fase di progettazione dell'apparecchiatura. Per
   far in modo che questa tipologia di server (NAS) venga integrata in ambienti di calcolo
   come quelli del Data Center S.Co.P.E, deve possedere una serie di caratteristiche
   strutturali, sia hardware che software che la fanno risultare predisposta all'integrazione
   stessa. L'analisi hardware e software delle due attrezzature prese in esame mi ha
   permesso di constatare che l'apparecchiatura fornita dalla Synology si è rivelata quella
   più adatta.


    ◦ L'architettura del sistema, rispetto a quella LACIE, si è rivelata molto più
        modulare al punto da poterla considerare quasi come quella di una normale
        macchina da personal computer, anche se di firma PawerPC (architettura
        micorprocessore).


    ◦ I servizi nativamente offerti, si posso considerare di grandissima utilità anche per
        rispondere a esigenze di carattere scientifico, come per esempio l'amministrazione
        dei gruppi e degli utenti, la gestione avanzata dei volumi, il servizio FTP e il
        protocollo NFS (Network File System).


    ◦ L'interfaccia di rete, si può considerare molto performante grazie alle due schede
        da un gigabit ciascuna, le quali hanno la possibilità di essere configurate con un


Del Prete Domenico 873/1                                                 Pagina 41 di 101
        Link Aggregation incrementando così sia la velocità del link oltre i limiti del
        singolo cavo che la ridondanza per una più alta disponibilità.


    ◦ Il sistema operativo di base è stato uno degli aspetti fondamentali che ha
        pregiudicato già da subito la scelta del sistema; infatti il DS 508 offerto dalla
        Synology dispone in modo nativo un sistema Linux-embedded, anche se molto
        minimale, che però ha permesso di effettuare le operazioni necessarie per favorire
        l'integrazione di nuove applicazioni, aspetto chiave dello scopo del lavoro.


    ◦ L'interfaccia Web d'amministrazione, si è dimostrata molto pratica, intuitiva e
        potente. In questo modo l'amministratore riesce a gestire l'intero sistema molto
        velocemente. L'interfaccia è stata sviluppata in AJAX (Asynchronous JavaScript
        and XML) e grazie alla presenza dell'applicazione PHP e la possibilità di accedere
        al sistema tramite SSH, è possibile aggiungere nuove funzionalità, rendendo in
        questo modo il sistema espandibile sia per i servizi che offre che per
        l'amministrazione degli stessi.


    4.3 Integrazione di applicazioni su Sistemi di storage Embedded

    Il secondo obiettivo della tesi che mi sono proposto è stato quello di rendere possibile
    l'integrazione di servizi file transfer sul sistema NAS Server. Come già descritto nella
    motivazione della scelta dell'apparecchiatura, il sistema embedded Synology DS 508 è
    risultato quello più adatto; esso è provvisto di kernel Linux con risorse molto limitate,
    dov'è preinstallato e configurato sia il firmware di funzionamento del dispositivo che il
    suo sistema web di management. La presenza del servizio SSH (Secure Shell) ha
    permesso di potermi collegare all'apparecchiatura come amministratore del sistema
    con una CLI (Comand Line Interface) e grazie all'esperienza acquisita nel percorso di
    studi del corso di laurea ho potuto constatare la possibilità di una futura integrazione di
    eventuali servizi non forniti nativamente dal sistema. Teoricamente la possibile
    integrazione di nuovi servizi su apparecchiature predisposte di kernel Linux può


Del Prete Domenico 873/1                                                   Pagina 42 di 101
    essere effettuata attraverso procedure di compilazione di sorgenti utilizzando un
    particolare gestore di pacchetti fornito dalla distribuzione di Linux stessa installata sul
    calcolatore. La compilazione consiste nella costruzione di file binari (eseguibili)
    partendo dal codice sorgente o codice di programmazione; dopo aver effettuato la
    compilazione e quindi creato i file binari, questi vengono posizionati nelle giuste
    directory per essere eseguiti dal sistema.




                             Figura 4.3: I passi della compilazione



   Le apparecchiature embedded come quella presa in esame, non permettono di eseguire
   questo tipo di procedura, anche perché sono sprovviste di ogni tipo di compilatore (visto
   che non è stata prevista l'espansione di nuove applicazioni); infatti questa tipologia di
   sistemi possiede un'architettura diversa da quella dei calcolatori presenti sul mercato
   dei personal computer. Questo tipo di problematica non rende possibile l'integrazione di
   nuovi servizi a meno che non si faccia uso di tecniche particolari, come quella della
   cross-compilazione. La cross-compilazione permette di compilare codice sorgente con
   un cross-compilatore, ottenendo così un file binario eseguibile su di un elaboratore con
   architettura diversa da quella della macchina su cui si è lanciato il cross-compilatore
   stesso; Nel caso studiato, la macchina che esegue il cross-compilatore è provvista di
   architettura i686 e prende il nome di host, mentre la macchina interessata ad ospitare il
   codice compilato (binario eseguibile), ottenuto dal processo di cross-compilazione,
   prende il nome di target, ed è fornita di architettura PowerPC. Per poter effettuare il
   processo di cross-compilazione di base c'è bisogno di una toolchain, la quale nella
   maggior parte dei casi è composta da: a) un editor di testo per l'inserimento del codice


Del Prete Domenico 873/1                                                   Pagina 43 di 101
   sorgente, b) un compilatore, c) un linker per la trasformazione del codice sorgente in
   programma eseguibile e d) librerie che forniscono l'interfaccia col sistema operativo.




                           Figura 4.4: I passi della cross-compilazione



   La tipologia di applicazioni e di funzionalità richiesta dall'infrastruttura della griglia
   computazionale preesistente si basa su protocolli di file transfer; affinché sia possibile
   l'integrazione di questa tipologia di storage element embedded (NAS DS 508) nell'intero
   impianto del data center, verranno implementati i seguenti servizi:


            ➢ Applicazione protocollo BBFTP
            ➢ Applicazione protocollo GridFTP
            ➢ Configurazione dei certificati usando il modello GSI
            ➢ Integrazione dei servizi implementati nel sistema web di amministrazione


   Nel capitolo successivo descriverò tecnicamente gli step e le operazioni necessarie che
   hanno       permesso         l'implementazione             delle       nuove        applicazioni.

Del Prete Domenico 873/1                                                          Pagina 44 di 101
 5. Implementazione dei servizi sul NAS Server


    5.1 Gli strumenti utilizzati


    In questo paragrafo descriverò tutte le procedure effettuate senza le quali non avrei
    mai potuto ampliare o modificare le funzionalità fornite normalmente dal sistema
    NAS. Utilizzando l'interfaccia web di gestione prevista e la Command Line Interface
    tramite connessione SSH, ho potuto prendere il pieno controllo del dispositivo e
    modificare il modo in cui esso opera. Questo tipo di apparecchiatura embedded, anche
    se provvista di sistema    linux molto ridotto, non dispone nativamente di nessun
    gestore di pacchetti; questo avrebbe permesso di effettuare installazione,
    aggiornamento e rimozione di alcune applicazioni fondamentali per l'amministratore
    del server, ma cosa più importante, la possibile configurazione di un compilatore. La
    casa produttrice del sistema NAS Synology ha messo a disposizione una Toolchain per
    sperimentare l'assemblaggio di file binari attraverso processi di cross-compilazione
    come quelli già discussi nel paragrafo precedente. Tutto ciò mi ha posto di fronte ad
    una problematica mai affrontata: la sperimentazione sulla creazione di eseguibili
    attraverso la tecnica del cross-compiling; in questo modo ho potuto prendere
    confidenza con le funzionalità della toolchain, maneggiando i numerosi paramenti di
    configurazione che hanno reso la corretta compilazione dei sorgenti. Successivamente
    effettuando studi accurati sulla versione di linux-embedded integrata sul server e le
    caratteristiche del processore ho trovato anche la possibilità d’integrare un particolare
    gestore di pacchetti molto leggero, minimale, adatto a questo tipo di sistema operativo
    e compatibile con l’architettura del processore; con esso ho potuto installare un
    compilatore sul server, creando così una soluzione alternativa a casi particolari
    generati dalla cross-compilazione (come vedremo più avanti).




Del Prete Domenico 873/1                                                 Pagina 45 di 101
    5.2 Implementazione del servizio BBFTP


   L'applicazione BBFTP è un software di file transfer fornito sotto la GNU (General
   Public License) prelevato dall'indirizzo: http://doc.in2p3.fr/bbftp/download.html; questo
   servizio è stato implementato sulla macchina NAS con lo scopo di dare un'alternativa ai
   servizi di trasferimento file dedicati al grid; ovvero di permettere ad un utente che non
   possiede ancora un certificato di usufruire comunque di un servizio parallel file transfer
   veloce quanto il GridFTP. Come descritto in precedenza, lo stile implementativo
   utilizzato è stato quello della cross-compilazione; per tale motivo ho eseguito i passi
   implementativi su una macchina con architettura i686 facendo uso della toolchain
   fornita dalla casa produttrice dell'apparecchiatura (Synology), per poi trasportare i file
   binari eseguibili sulla macchina server. Il pacchetto della toolchain è reso disponibile a
   questo indirizzo: http://sourceforge.net/projects/dsgpl/ . I passi percorsi possono essere
   rappresentati nel modo seguente:


    1. Download ed estrazione del pacchetto: la versione raccomandata dalla
        documentazione è stata la 3.2.0 (bbftp-server-3.2.0.tar.gz) che ho estratto nella
        seguente directory:


                   tar zxvf bbftp-server-3.2.0.tar.gz -C             /user/local/



    2. Gli step convenzionali che permettono la compilazione di un'applicazione
        generalmente sono: configure, make e make install. L'esecuzione dello step
        “configure” permette di controllare l'esistenza di tutte le librerie necessarie alla
        compilazione; questo tipo d'operazione è stata effettuata attraverso la toolchain ed
        è risultata la mancanza di alcune librerie SSL utilizzate dal protocollo BBFTP il
        quale adopera il trasferimento cifrato mediante chiavi RSA; tutto ciò ha portato
        alla cross-compilazione del modulo openssl che implementa i protocolli
        crittografici TLS (Transport Layer Security) e SSL (Secure Sockets Layer). Quindi
        anche openssl è stato cross-compilato con l'uso della toolchain e sono state


Del Prete Domenico 873/1                                                  Pagina 46 di 101
        integrate in essa le rispettive librerie mancanti: libcrypto.so, libcrypto.so.0,
        libcrypto.so.0.9.8, libcrypt.so.1, nella directory contenente le librerie preesistenti
        (/usr/local/powerpc-linux-gnuspe/powerpc-linux-gnuspe/lib/).


    3. Queste librerie hanno permesso l'esecuzione dei successivi step. A tal proposito ho
        sviluppato il seguente script di shell che ha permesso la successiva operazione di
        cross-compilazione dell'applicazione:


           export CC=/usr/local/powerpc-linux-gnuspe/bin/powerpc-linux

           gnuspe-gcc

           LD=/usr/local/powerpc-linux-gnuspe/bin/powerpc-linux-gnuspe-ld

           RANLIB=/usr/local/powerpc-linux-gnuspe/bin/powerpc-linux-
           gnuspe-ranlib

           CFLAGS="-I/usr/local/powerpc-linux-gnuspe/include                      -mcpu=8543
           -mhard-float -mfloat-gprs=double"

           LDFLAGS="-L/usr/local/powerpc-linux-gnuspe/lib"

           ./configure

           --host=i686-tesisti.scope.unina.it-linux \

           --target=mpc8543-synology01.scope.unina.it-linux \

           --build=mpc-pc-linux \

           --prefix=/usr/local

           Numerose altre modifiche sono state apportate al file “configure”, come la
           modifica di path standard di controllo, richiamo di librerie dinamiche e
           statiche per operazioni di linking; il file “configure” è stato omesso dalla
           seguente descrizione per favorire la comprensione del flusso del lavoro svolto,
           visto che la grandezza di tale file risulta essere di oltre 9800 righe di codice.

    4. Configurati tutti i componenti necessari sono passato alla compilazione
        dell'applicazione; quindi posizionandomi nella directory /usr/local/bbftp-
        server-3.2.0/bbftpd/       ho eseguito il comando make; l'operazione è terminata



Del Prete Domenico 873/1                                                   Pagina 47 di 101
        con successo dopo alcuni minuti. Quest'ultima operazione ha permesso la
        generazione dei file binari eseguibili sulla macchina target (Synology NAS
        server), i quali però, devono essere posizionati nelle giuste directory del sistema
        per essere eseguiti correttamente dal processore del server . Una volta effettuata la
        cross-compilazione è stata esportata la directory contenente tutti i file oggetto nella
        directory /usr/local/ del server NAS, dove è stato eseguito il comando di make
        install che ha permesso di posizionare tutti i file necessari al funzionamento
        dell'applicazione     nelle     giuste    directory,     ovvero:      /usr/local/etc/           e
        /usr/local/bin/       .


    5. A questo punto si ha la possibilità di attivare, disattivare e monitorare lo stato del
        servizio con i rispettivi comandi:
           /usr/local/etc/bbftpd start                 //attivazione
           /usr/local/etc/bbftpd stop                  //disattivazione
           /usr/local/etc/bbftpd status                //stato del servizio


    Per verificare l'effettiva implementazione del servizio ho eseguito alcuni test
    preliminari, come si può osservare nella figura seguente:




                            Figura 5.1: Test di trasferimento con protocollo BBFTP



Del Prete Domenico 873/1                                                             Pagina 48 di 101
    5.3 Implementazione del servizio GridFTP

   L'applicazione GridFTP è un progetto Globus, essa viene distribuita nell'applicazione di
   Globus Toolkit. La versione che mi è stata consigliata dalle documentazioni è la 2.4, in
   quanto risulta essere la più stabile e collaudata; le direttive per l'installazione le ho
   potute reperire sul sito di riferimento (http://www.globus.org/toolkit/).
   Dopo aver effettuato ricerche e studi, ho deciso di sperimentare “l'installazione” di un
   gestore di pacchetti molto minimale: ipkg. Esso è inspirato a dpkg (abbreviazione di
   Debian package, è il componente base del sistema di gestione dei pacchetti della
   distribuzione GNU/Linux Debian) è un software molto leggero, per piccoli sistemi
   Linux e dispositivi embedded, come ad esempio il Synology Server. Lo scopo
   dell'installazione di ipkg è stato quello di cercare d'integrare il cross-compilatore della
   toolchain fornita dalla casa produttrice sul sistema di base del server, in modo da evitare
   i relativi problemi di eventuali librerie mancanti (caso riscontrato nella prima procedura
   d'implementazione del sevizio bbftp).
   L'integrazione di ipkg si è rilevata possibile attraverso l'uso di un bootstap; un bootstrap
   è uno script di shell che contiene tutte le informazioni fondamentali per effettuare la
   configurazione dell'applicazione. Il tipo di informazioni che contiene un bootstrap sono
   soprattutto relative al tipo di architettura del processore; quindi nel mio caso ho dovuto
   usare un bootstrap adatto alla categoria PowerPC, nella fattispecie: 8543 PPC e500v2
   fabbricato dalla Freescale Semiconductor, che ho potuto prelevare a questo indirizzo:
   http://ipkg.nslu2-linux.org/feeds/optware/syno-e500/cross/unstable/syno-e500-
   bootstrap_1.25_powerpc.xsh.
   Accedendo alla riga di comando con privilegi di root, tramite protocollo SSH ho creato
   la directory “ public/ ” nel seguente path di sistema: “ /volume1/ ”, dove ho effettuato il
   download del file di bootstrap eseguendolo nel modo segunete: ./syno-e500-
   bootstrap_1.2-5_powerpc.xsh
   Successivamente ho potuto integrare la toolchain eseguendo con il comando:
   ipkg install optware-devel
   Grazie a queste opportune modifiche, il NAS server DS 508 è risultato pronto per
   effettuare le successive procedure di compilazione. L'implementazione dell'applicazione

Del Prete Domenico 873/1                                                   Pagina 49 di 101
   GridFTP è stata un susseguirsi di molte modifiche e sperimentazioni, ma può essere
   schematizzata nei seguenti step:


    1. Download dal sito di riferimento www.globus.org dei seguenti pacchetti: gpt-
        3.0.1-src.tar.gz e globus-data-management-server-2.4.3-src_bundle.tar.gz che ho
        esportato nella seguente directory: /volume2/sharedRAID0/gridftp/


    2. Creazione delle seguenti directory nel path di sistema /opt/. Esse sono le directory
        dove è stata installata l'applicazione:
           datatag_gpt
           datatag_globus
           datatag_log
           datatag_log/server



    3. Prima che l'installazione venga inizializzata devono essere settate le seguenti
        variabili d'ambiente; esse servono per settare i corretti percorsi d'installazione:
           > export GLOBUS_LOCATION =/opt/datatag_globus
           > export GPT_LOCATION=/opt/datatag_gpt



    4. Estrazione     del   pacchetto   gpt-3.0.1-src.tar.gz   nella   directory   ../griftp/   e
        assemblaggio dell'applicazione GPT; essa sarà costruita direttamente nella
        directory /opt/datatag_gpt:
           > gzip –dc gpt-2.2.9-src.tar.gz | tar xf –                     //estrazione
           > cd gpt-2.2.9                                 //posizionamento della directory
           > ./build_gpt                                  //compilazione applicazione
           Prima di lanciare il processo di compilazione ho dovuto modificare in modo
           opportuno il file di script “build_gpt”, intervenendo su diversi parametri di
           configurazione, come quelli riguardo alle locazioni dell'interprete perl e la sua
           compatibilità.


    5. I sorgenti di Globus sono stati assemblati usando l'applicazione GPT e il
        compilatore gcc della toolchain integrato in precedenza, inoltre con l'opzione

Del Prete Domenico 873/1                                                    Pagina 50 di 101
        “-logdir” il risultato dell'installazione è stato salvato in un file di log che
        permetterà di rintracciare eventuali errori nella compilazione; questo tipo di
        operazione è stata effettuata soltanto per i sorgenti che implementano il server, in
        quanto l'apparecchiatura sarà vista nell'intera rete grid come come uno storage
        element. L'intero processo termina con successo dopo 11 minuti.


           >   $GPT_LOCATION/sbin/gpt-build           globus-data-management-server-
           2.4.3-src_bundle.tar.gz gcc32dbg -logdir=/opt/log/server



    6. Per completare l'installazione e stato necessario eseguire i seguenti comandi:


           > . $GLOBUS_LOCATION/etc/globus-user-env.sh
           > $GPT_LOCATION/sbin/gpt-postinstall
           > $GLOBUS_LOCATION/setup/globus/setup-gsi
           > $GPT_LOCATION/sbin/gpt-verify
           > . $GLOBUS_LOCATION/etc/globus-user-env.sh



    Terminata l'installazione con successo ho effettuato la richiesta dei certificati
    macchina, tramite le specifiche procedure istanziate dalla Registration Authority (RA)
    locale (UNINA), la quale svolge un ruolo intermediario verso la Certificaion Autority
    (CA – INFN Firenze). La richiesta dei certificati è stata preceduta dalla procedura di
    mappatura del DNS (Domain Name System), operazione indispensabile per
    identificare in modo univoco il nome del server nella rete. Successivamente è stato
    aggiornato il file di configurazione della macchina “/etc/hosts” con l'univoco nome
    DNS mappato (synology01.scope.unina.it) come mostrato di seguito:


           127.0.0.1           localhost
           143.225.93.250      synology01.scope.unina.it
           0.0.0.0 Synology01




Del Prete Domenico 873/1                                                Pagina 51 di 101
    Per verificare l'effettiva implementazione del servizio ho eseguito alcuni test
    preliminari, come si può osservare nella figura seguente:




                      Figura 5.2: Test di trasferimento usando il protocollo GridFTP



    Nel prossimo paragrafo analizzerò lo scopo della sicurezza GSI (Grid Security
    Infrastructure) sul quale si basa l'uso dei suddetti certificati, definendo le specifiche
    procedure di configurazione effettuate su questo server NAS.




Del Prete Domenico 873/1                                                           Pagina 52 di 101
    5.4 Configurazione dei servizi con l'uso di GSI

    I servizi implementati sul NAS Sever sono stati configurati seguendo i principi di
    sicurezza del GSI (Grid Security Infrastructure) che garantisce le condizioni di
    sicurezza della comunicazione all'interno della rete Grid. Essa rappresenta
    un'implementazione delle richieste generali che ho descritto riguardo il layer
    connectivity (sezione1.3). Esso è standardizzato secondo i seguenti requisiti tecnici:


                                      Requisiti Tecnici
                        Multi-site authentication (verifica di identità)
                    Authorization (mappa l’entità ad un set di privilegi)
                                      Message integrity
                                      Non-repudiation
                                       Message privacy
                                     Delegation (proxy)
                                     Users virtualization



    Questi possono essere utilizzati e personalizzati a seconda degli obbiettivi richiesti
    dalla particolare infrastruttura che adotta GSI; i requisiti più rilevanti sui quali
    focalizzerò maggiore attenzione saranno:


                                 Message integrity
                                  Non-repudiation
                                  Message privacy


    Questi sono stati implementati dall'INFN utilizzando certificati X.509 e il protocollo di
    comunicazione SSL (Secure Sockets Layer); successivamente questo tipo di modello


    implementativo è stato importato da tutti i centri di calcolo che fanno parte della rete
    grid, compreso il Data Center S.Co.P.E. SSL (Secure Sockets Layer) è un protocollo di
    comunicazione che garantisce gli standard di sicurezza richiesti in Grid basato sulla


Del Prete Domenico 873/1                                                   Pagina 53 di 101
    crittografia a chiave asimmetrica. GSI nell'ambito del Globus toolkit, si occupa di
    garantire condizioni di sicurezza nella comunicazione all'interno di una rete Grid.
    X.509 costituisce uno standard di codifica di un certificato digitale (digital certificate).
    Un digital certificate è un documento digitale, assegnato da una Certification
    Authority (CA) che definisce le credenziali di un entità: utente o server.
    L'acquisizione di un certificato viene inizializzata dall'utente con la generazione di un
    certificato vuoto di richiesta: usercert_request.pem ( .pem è un certificato codificato
    con l'algoritmo Base64, racchiuso tra “-----BEGIN CERTIFICATE-----" e "-----END
    CERTIFICATE-----”) e una chiave privata criptata userkey.pem; successivamente
    l'utente invia il certificato vuoto alla propria CA (Certification Autority) che viene
    identificato tramite una Registration Authority (RA) locale la quale gioca il ruolo di
    intermediario.
    L'utente riceve il certificato compilato dalla CA contenente:




             Figura 5.3: Struttura del certificato digitale rilasciato dal Cetification Autority




Del Prete Domenico 873/1                                                                    Pagina 54 di 101
    A questo punto, dal certificato ricevuto, attraverso l'uso di una particolare procedura
    SSL vengono generati due file: usercert e userkey, che rappresentano rispettivamente:
    chiave pubblica e chiave privata. La chiave privata rimane in stretta custodia
    dell'utente; la chiave pubblica viene diffusa alle diverse entità interessate allo scambio
    dei messaggi. I certificati, quindi permetteranno all'utente di accedere ai servizi della
    griglia computazionale utilizzando la cifratura tramite crittografia asimmetrica la quale
    garantisce la Message Privacy, uno dei requisiti fondamentali richiesti da GSI.


    5.4.1 Message Privacy: cifratura tramite crittografia asimmetrica

    Nella tradizionale crittografia simmetrica viene utilizzata un'unica chiave sia per
    codificare che per decodificare i messaggi. Le informazioni (la chiave e l'algoritmo)
    necessarie per chi deve inviare il messaggio sono quindi identiche a quelle necessarie
    a chi deve riceverlo. Per concordare una chiave con il proprio interlocutore c'è bisogno
    di mettersi preventivamente in contatto con lui. In qualsiasi caso, esiste il pericolo che
    la chiave venga intercettata durante lo scambio delle informazioni, compromettendo
    quindi l'intero sistema comunicativo. La crittografia a chiave pubblica (asimmetrica)
    permette invece a due (o più) persone di comunicare in tutta riservatezza senza usare
    la stessa chiave, anche se non hanno avuto contatti precedentemente. La cifratura e la
    decifratura vengono effettuate con chiavi diverse: A pubblica e B privata. Il mittente
    prima di spedire un messaggio lo cifra attraverso la chiave pubblica fornita dal
    ricevente, il quale sarà l'unico a poter decifrare il messaggio.


    ◦ Tutto ciò che viene criptato con chiave A può essere decriptato solo con chiave
        B e viceversa; la chiave pubblica serve unicamente per codificare il messaggio,
        mentre quella privata serve unicamente per decodificarlo.


    ◦ Non si potrà mai ricavare la chiave A dalla chiave B e viceversa in quanto la
        coppia di chiavi pubblica/privata viene generata attraverso algoritmi basati sulla
        generazione di numeri casuali. Gli algoritmi asimmetrici (esempio RSA) sono
        studiati in modo tale che la conoscenza della chiave pubblica e dell'algoritmo



Del Prete Domenico 873/1                                                  Pagina 55 di 101
        stesso non siano sufficienti per risalire alla chiave privata.

   L'impossibilità di risalire alla chiave privata non è stata ancora dimostrata
   matematicamente, ma allo stato attuale le conoscenze matematiche e le potenze di
   calcolo disponibili non risultano sufficienti a dimostrarne la vulnerabilità.


    5.4.2 Non-repudiation e Message Integrity tramite firma digitale

   La firma digitale consiste nel siglare un messaggio (o documento) con la propria chiave
   privata; le entità coinvolte (utenti o server) una volta ricevuto tale messaggio, riescono a
   verificarne la firma solo con il certificato pubblico preventivamente conosciuto relativo
   a quella particolare chiave privata.

   Da un messaggio di lunghezza variabile, una funzione produce una stringa di
   lunghezza fissa (HASH: stringa di lunghezza fissa che dipende dal contenuto del
   messaggio) che rappresenta “l'impronta digitale” del messaggio stesso. L’hash, detta
   anche message digest, viene criptato con la chiave privata del mittente, generando
   quindi la firma digitale.

   La funzione hash, è fatta in modo da rendere prossima allo zero la probabilità che da
   messaggi diversi si possa ottenere il medesimo valore della stringa, inoltre è un
   operazione a senso unico, questo significa che dalla stringa hash è impossibile ottenere
   nuovamente il messaggio originario. La firma prodotta dipende dall'impronta digitale
   del documento e, quindi, dal documento stesso, oltre che dalla chiave privata dell'utente.
   A questo punto la firma viene allegata al documento.

   Dopo il trasferimento il destinatario verificherà l'autenticità del messaggio
   decifrando la firma digitale con la chiave pubblica del mittente, ottenendo
   l'impronta digitale del documento. A questo punto confronterà quest'ultima con
   quella che si ottiene applicando la funzione hash al documento ricevuto; se le due
   impronte digitali sono uguali, l'autenticità e l'integrità del documento sono
   garantite.


Del Prete Domenico 873/1                                                   Pagina 56 di 101
   Quando il ricevente confronterà le due stringhe hash riuscirà a rilevare in modo certo
   anche l'identità del mittente oltre l'integrità e l'autenticità del documento, perché
   decifrerà    il     messaggio      con     la      chiave       pubblica       del      mittente.
   La firma digitale assicura inoltre il non ripudio: il firmatario di un documento
   trasmesso non può negare di averlo inviato (la firma digitale del mittente contiene la
   stringa hash univoca del messaggio cifrata con la sua chiave privata), né può il
   destinatario negare di averlo ricevuto (la Certification Autority certifica al mittente
   l'identità del ricevente, tramite certificato pubblico del destinatario). Questo significa
   che l'informazione non può essere disconosciuta, come nel caso di una firma
   convenzionale su un documento cartaceo in presenza di testimoni. Inoltre la CA
   periodicamente rilascia una Certificate Revocation List (CRL), documento contenente la
   lista di certificati revocati non più validi a causa di molteplici ragioni: compromissione
   della chiave primaria, dimissioni, cambio dei dati personali etc, tutto a guadagno della
   sicurezza. La fase di autenticazione è quella più delicata in quanto garantisce che il
   messaggio del vero mittente sia ricevuto dal ricevente autentico.

   Ogni richiesta è accompagnata dal certificato dell’utente. La CA deve essere accreditata
   (trusted) presso il ricevente; il
   servizio genera una stringa casuale e
   la manda all'utente; l'utente riceve
   questa stringa e la cifra con la
   propria chiave privata e la invia al
   servizio; il servizio la decodifica con
   la chiave pubblica dell'utente e la
   confronta con la stringa originale, se
   coincidono, il servizio ricevente non
   può rifiutare la richiesta. Ogni
   transazione Grid è soggetta a mutua
   autenticazione.

                                             Figura 5.4 : Sequenza temporale dell'autenticazione




Del Prete Domenico 873/1                                                       Pagina 57 di 101
    5.4.3 Maggiore sicurezza con la delegazione proxy

    Il certificato utente rilasciato dalla Certification Autority ha validità limitata di un
    anno; se nell'arco di questo periodo di tempo il certificato venisse rapito e non venisse
    denunciato lo smarrimento, utenti sconosciuti potrebbero usarlo fino alla sua scadenza
    clandestinamente, violando dati e risorse. Questa vulnerabilità viene sopperita da un
    Proxy, il quale ha il compito principale di decrementare la validità temporale del
    certificato (per evitare che un certificato possa essere intercettato). Il proxy delega il
    ruolo del certificato che a sua differenza ha una validità molto inferiore (in genere 12
    ore).Ogni volta che l'utente vuole utilizzare una risorsa o svolgere qualsiasi tipo di
    attività deve creare un proxy delle credenziali il quale è locale e temporaneo;




                         Figura 5.5: La creazione del proxy temporaneo
                                con il comando "grid-proxy-init"



    L'attivazione del proxy implica l'uso della chiave privata risiedente nella macchina
    dell'utente, che per motivi di sicurezza è criptata e protetta da password. I certificati
    proxy viaggiano nella grid e sono forniti di: a) chiavi pubblica e privata (con chiave
    privata non criptata proprio per delegare tutte le veci di chi l'ha creato); b) il certificato
    dell'utente che l'ha creato, tranne la chiave privata. In questo modo il proxy riesce a

Del Prete Domenico 873/1                                                     Pagina 58 di 101
    comunicare con un Worker Node (per esempio) per la sottomissione di job, oppure
    permettere servizi di file transfer; ovviamente se anche il periodo di vita del proxy
    temporaneo risultasse lungo rispetto all'uso richiesto è prevista la sua distruzione con
    appositi comandi. Se invece l'attività dell'utente richiede tempo maggiore rispetto a
    quello fornito da un proxy temporaneo, ci sarà a disposizione il servizio MyProxy.




          Figura 5.6: Il modello di comunicazione attraverso l'uso del proxy fisico (MyProxy)




    Il servizio Myproxy è un online-credential repository (una vera e propria macchina
    server) che conserva le credenziali per un lungo periodo di tempo (generalmente una
    settimana) e consente a un utente di ottenere credenziali in maniera sicura quando è
    necessario. Ad esempio, per job di durata superiore alla scadenza del proxy, il
    WorkerNode dove risiede il job può contattare il MyProxy server con il certificato
    proxy ogni 12 ore (tipicamente), per ottenere nuove credenziali in maniera automatica
    senza l’intervento umano, in modo da garantire la sicurezza della delega di periodo
    settimanale pari alla sicurezza fornita da un server proxy temporaneo.




Del Prete Domenico 873/1                                                              Pagina 59 di 101
    5.4.4 Configurazione dei certificati sul server NAS


   Ricevuti i certificati (Pubblico: hostcert.pem e Privato: hostkey.pem) dalla Certification
   Autority, questi sono stati posizionati nella directory appropriata: “ /etc/grid-security ”.
   Norma molto importante è quella di settare i giusti permessi a ogni certificato, ovvero:
            > chmod 600 hostcert.pem                //lettura e scrittura per il proprietario e sola
            lettura per il gruppo di appartenenza e altri utenti
            >   chmod    400     hostkey.pem        //sola lettura per il proprietario e nessuna
            operazione possibile sia per il gruppo di appartenenza che per gli altri utenti.




                               Figura 5.7: Lo stato dei permessi dei certificati



   La scelta dei permessi rispecchia i canoni di sicurezza GSI, in questo modo il certificato
   pubblico è visibile da chi ne ha bisogno, quello privato invece è in stretta custodia
   dell'amministratore dello storage element. Settati i permessi, ho configurato la
   Certificate Revocation List (CRL), come descritto in precedenza, essa ha lo scopo di
   mantenere un alto livello di sicurezza aggiornando lo stato dei certificati revocati:
            > cd /etc/grid-security/                     //mi posiziono della giusta directory
            > wget      http://people.na.infn.it/~spardi/ca-crl.tar           //download del pacchetto
            CRL
            > tar -xvf ca-crl.tar                        //estrazione pacchetto



Del Prete Domenico 873/1                                                            Pagina 60 di 101
   Come tutte le entità anche uno storage element non dispone i diritti di accesso alla
   griglia computazionale finché non appartiene ad una Virtual Organization; questa
   appartenenza infatti viene gestita mediante un particolare file di configurazione che ha
   il nome di “grid-map file”. Il grid-mapfile stabilisce i diritti di un utente su una
   specifica risorsa in base alla sua VO di appartenenza; questo vale anche nel caso dello
   storage element in questione, in quanto la parola “utente” in questo caso si riferisce
   all'amministratore che gestisce la risorsa, il quale deve essere anch'egli registrato
   sull'apparecchio per rendere il servizio attivo. Le entries del grid-mapfile mappano gli
   utenti autorizzati della Grid, in utenti del sistema locale:


   "/C=IT/O=INFN/OU=Personal Certificate/L=Federico II/CN=Domenico Del Prete" domenico


   Prima di effettuare qualsiasi tipo di operazione che fa uso della Grid Security
   Infracstrutture è obbligatorio settare le seguenti variabili d'ambiente:

            > export GLOBUS_LOCATION=/opt/datatag_globus
            > export GPT_LOCATION=/opt/datatag_gpt
            >   . $GLOBUS_LOCATION/etc/globus-user-env.sh



   A questo punto si posso attivare i servizi che fanno uso di GSI, come per esempio
   quello di GridFTP implementato in precedenza. Per attivare questo servizio è sufficiente
   eseguire il seguente comando:


            > /opt/datatag_globus/sbin/in.ftpd -S -p 2811



   esso provvederà all'attivazione del servizio GridFTP server rimanendo in ascolto sulla
   porta 2811. Per disattivare il servizio è necessario identificare il processo di sistema
   (PID - Process IDentifier) associato al servizio, facendo uso del comando ps;
   Identificato il processo è possibile terminarlo eseguendo la sintassi del seguente
   comando:                 kill -9 “numero pid” -------------> kill -9 8083




Del Prete Domenico 873/1                                                      Pagina 61 di 101
              Figura 5.8: Output del comando “ps” - servizio Gridftp attivo sulla porta 2811




Del Prete Domenico 873/1                                                            Pagina 62 di 101
 6. Integrazione dei servizi nel sistema web d'amministrazione


    6.1 Predisposizione del server per consentire l'integrazione WEB


   Dopo che le applicazioni sono state integrate con successo, emerge il bisogno di poterle
   maneggiare in modo semplice e veloce. Tutto ciò può esser reso possibile attraverso
   l'uso di un interfaccia web dedicata al controllo delle applicazioni e dei servizi. Il server
   DS 508 dispone nativamente di un sistema web di management molto pratico e potente
   (Disk Station Manager), attraverso il quale è possibile controllare tutti i servizi offerti
   dalla macchina. L'idea di base proposta è quella di poter integrare i servizi implementati
   all'interno del web manager user interface preesistente per avere il pieno controllo
   anche dei nuovi servizi. Disk Station Manager è un applicativo sviluppato in AJAX
   (Asynchronous JavaScript and XML) che ha permesso, con opportune modifiche, di
   aggiungere nuovi componenti alla struttura preesistente. Le modifiche apportate che
   hanno concesso l'integrazione delle nuove applicazioni può essere racchiusa nei
   seguenti passi:


    1. Creazione delle directory delle nuove applicazioni (“bbftp/””gridftp/”) nel
        seguente path:     /usr/syno/synoman/webman/3rdparty/


    2. All'interno di ognuna delle nuove directory ho creato il file “application.cfg” che
        contiene i parametri di configurazione della nuova applicazione da integrare; di
        seguito è riportato il file editato per l'applicazione GridFTP:
            text = GridFTP         // il nome visibile dell'albero delle applicazioni
            description = Grid FTP         // descrizione applicazione
            icon_16 = images/gridftp16x16.png              // icona illustrativa
            icon_32 = images/gridftp32x32.png           // icona illustrativa
            type = embedded        // il tipo di visualizzazione all'interno della user interface
            protocol = http        // il tipo di protocollo usato per la visualizzazione



Del Prete Domenico 873/1                                                        Pagina 63 di 101
           address = 143.225.93.250              // indirizzo del sistema
           port = 5000     // la porta che permette l'interfacciamento con il web manager
           path = /webman/3rdparty/gridftp/index.php //la pagina             dell'applicazione


    3. Il server DS 508 è predisposto nativamente di PHP (PHP: Hypertext Preprocessor)
        il quale ha permesso l'implementazione di codice interpretabile dal web server; per
        rendere ciò possibile ho dovuto modificare il file di configurazione del web server
        Apache affinché fosse riconosciuto correttamente il linguaggio PHP. Il file di
        configurazione     è   localizzato   nella    seguente    directory      di   sistema:
        /usr/syno/apache/conf/httpd.conf-sys dove ho aggiunto le seguenti righe di
        codice per caricare librerie mancanti, abilitare funzionalità e settare path di
        esecuzione:


           AddType application/x-httpd-php .php
           LoadModule php5_module /lib/libphp5.so


           <Directory />
                  Options ExecCGI FollowSymLinks MultiViews Indexes
                  AllowOverride All
           </Directory>


           <Directory "/usr/syno/synoman">
                  Options ExecCGI FollowSymLinks MultiViews
                  AllowOverride All
                  Order allow,deny
                  Allow from all
           </Directory>


           <IfModule dir_module>
                  DirectoryIndex index.html index.htm index.cgi index.php
           </IfModule>


           <IfModule mime_module>
                  ...



Del Prete Domenico 873/1                                                    Pagina 64 di 101
                   AddHandler cgi-script .cgi
                   ...
           </IfModule>


        dopodiché per rendere attive le modifiche apportate ho riavviato il server http:


           /usr/syno/etc/rc.d/S97apache-sys.sh restart



    4. Senza l'ausilio di un'interfaccia web, la manipolazione dei nuovi servizi è resa
        possibile soltanto attraverso l'uso della riga di comando; ciò non permette di usare
        tutte le potenzialità offerte dal sistema in modo rapido e intuitivo. L'impiego di
        php e html mi ha permesso di mettere in comunicazione l'interfaccia web con il
        sistema operativo sottostante; infatti immergendo codice php in pagine html ho
        potuto richiamare script di shell, permettendo in questo modo l'amministrazione
        dello stato dei servizi come se si operasse da linea di comando, con il vantaggio
        della praticità del web. Normalmente questo tipo di operazione non viene
        consentita dalla configurazione di default, in quanto se usata in modo
        inappropriato può compromettere lo stato dell'intero sistema. Per eseguire comandi
        di sistema attraverso l'interfaccia web ho dovuto prima modificare il file di
        configurazione php.ini (nella directory: /usr/syno/etc/ ) modificando l'opzione si
        sicurezza a NULL:
               safe_mode_exec_dir = /user/syno/bin #valore originario
               safe_mode_exec_dir =                         #valore modificato



        inoltre l'apertura base delle directory a NULL:
           #valore originario
           open_basedir      =/usr/syno/synoman:/etc:/var/run:/tmp:/var/spool/
           php:/volume1/@tmp/php:/var/services/web:/var/services/photo:/va
           r/services/blog:/var/services/homes:/var/packages/MailStation/t
           arget/roundcubemail
           #valore modificato
           open_basedir      =




Del Prete Domenico 873/1                                                 Pagina 65 di 101
        successivamente per attivare le modifiche ho riavviato il server web Apache:
                /usr/syno/apache/bin/httpd -k restart
   A questo punto il NAS server si può considerare predisposto per accogliere
   l'integrazione di servizi aggiuntivi nel sistema web management preesistente.




    6.1.1 Le tecnologie utilizzate


   Le nuove interfacce web implementate sono state realizzate con l'uso delle seguenti
   tecnologie: AJAX, PHP, HTML; AJAX è uno strumento di sviluppo per la realizzazione
   di applicazioni web interattive che si basa sullo scambio asincrono dei dati, asincrono
   nel senso che i dati richiesti al server sono caricati in background senza la necessità di
   richiedere che venga ritrasmessa l'intera pagina web (nella pagina visualizzata si
   effettua il caricamento solo delle informazioni richieste), la tecnologia AJAX è
   realizzata tramite l'istanza di un oggetto Javascript del tipo XMLHttpRequest utilizzato
   per lo scambio asincrono dei dati tra il client e il server. Per istanziare un oggetto
   XMLHttpRequest è stata scritta un funzione Javascript cross browser, che gira su tutte
   le versioni del noto browser Firefox e IE fino alla versione 6. La tecnologia PHP invece
   è un linguaggio di scripting che mi ha permesso di scrivere script lato server per
   mandare in esecuzione script di shell depositati sul server, in modo da attivare,
   disattivare e monitorare lo stato di servizi quali bbftp e gridfpt; Tutto ciò mi ha
   permesso di creare nuove estensioni software perfettamente integrabili nel software di
   gestione/monitoraggio già esistente.




Del Prete Domenico 873/1                                                 Pagina 66 di 101
    6.2 Integrazione del servizio BBFTP

    Di seguito e riportato il codice PHP della pagina index.php con la quale
    l'amministratore interagisce; essa fa riferimento ad altre due pagine: service.php e
    active_bbftp.php, le quali servono rispettivamente per monitorare lo stato del servizio
    e controllare lo stato della check-box affinché venga attivato o disattivato il servizio.


    Index.php:
    <!DOCTYPE         html      PUBLIC     "-//W3C//DTD    XHTML    1.0     Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
        <head>
          <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
          <title>Impostazioni BBFTP</title>
          <style type="text/css">
    <!--
    .style1 {
            font-size: 13px;
            font-weight: bold;
    }
    .style3 {font-size: 12px}
    -->
    </style>
          <script type="text/javascript" src="library/LibraryAjax.js"></script>
          <script type="text/javascript">
                  <!--
                  function send_status(frm)
                  {


                       //costruisco l
                       var AjaxRequest=assegnaXMLHttpRequest();


                       //controllo che l'oggetto ajax sia stato creato
                       if(AjaxRequest){
                         // impostazione richiesta asincrona in GET del file specificato
                         AjaxRequest.open("get", "service.php");
                             AjaxRequest.setRequestHeader('Content-Type', 'application/x-www-
    form-urlencoded');


                         AjaxRequest.onreadystatechange = function()



Del Prete Domenico 873/1                                                   Pagina 67 di 101
                              {
                                  if (AjaxRequest.readyState == 1)
                                      {
                                             window.document.getElementById("result_status").i
    nnerHTML = "Attendere...";
                                      }
                                      else
                                           {
                                                 if(AjaxRequest.readyState == 4)
                                                                  if(AjaxRequest.status == 200 ||
    AjaxRequest.status == 0)
                                                         {
                                                                window.document.getElementById("r
    esult_status").innerHTML                                 ="<b>Stato                           del
    servizio</b><br>"+AjaxRequest.responseText;
                                                         }
                                                         else
                                                              {
                                                                    window.document.getElementByI
    d("result_status").innerHTML = "<b>Stato del servizio</b><br>\nRisposta inattesa:
    HTTP STATUS CODE " + AjaxRequest.status+"<br/>Riprova"
                                                              }
                                                         }
                                                     }
                                                AjaxRequest.send(null);
                        }
                        return false;
                   }
                   //-->
            </script>
      </head>
      <body>
           <div    align="center"><img         src="bbftpmod.PNG"   alt="bbftpimage"   width="181"
    height="78" /></div>
        <div id="bbftp">
           <p align="left" class="style1">&nbsp;</p>
                       <p   align="left"   class="style1">Gli     utenti   possono   effettuare    il
    trasferimento file con il servizio BBFTP dopo averlo attivato </p>
                <p align="left" class="style1">La directory dedicata al trasferimento
    BBFTP &egrave; la seguente: <em>/volume1/bbftp/</em></p>
           <form method="post" action="active_bbftp.php">
               <table>
                  <tr>
                    <td class="style1">ATTIVATO</td>



Del Prete Domenico 873/1                                                        Pagina 68 di 101
                      <?
                  //controllo se il servizio bbftp è attivo
                           $comando="/usr/local/etc/bbftpd status"; //esecuzione del comado
    status
                           $disattivato="bbftpd is not running."; //output otteneto se il
    servizio è disattivato
                  //eseguo il comando
                  $output=popen($comando,"r");


                           //prendo tutto l'output prodotto dal comando
                  $return="";
                  while(!feof($output)){
                           $return=$return.fread($output,2096);
                  }




                                   if(substr($return,0,22)==$disattivato)   echo     "<td><input
    type=\"checkbox\" name=\"ftp\"></td>";
                        else echo "<td><input type=\"checkbox\" name=\"ftp\" checked></td>
    <input type=\"hidden\" value=\"disattiva\" name=\"operazione\">";
                  ?>
                  </tr>
                       <tr><td colspan="2" align="right"><input type="submit" name="submit"
    value="Applica"></td></tr>
               </table>
             </form>
             <div id="message_bbftp" align="center">
             <?
                  if(isset($_REQUEST['mess_bbftp']) && trim($_REQUEST['mess_bbftp'])!="")
    echo $_REQUEST['mess_bbftp'];
             ?>
             </div>
        </div>
        <div id="status" align="center">
             <p align="center" class="style1">Controlla lo stato del servizio </p>
             <form onsubmit="return send_status(this);">
               <table align="center">
                                <tr><td   align="center"><input   type="submit"    name="status"
    value="Status" title="Clicca ed esegui il comando"></td></tr>
               </table>
             </form>
             <div id="result_status" align="center">
             </div>



Del Prete Domenico 873/1                                                    Pagina 69 di 101
          </div>
        </body>
    </html>



    service.php:
    Esegue il comando di STATUS del servizio BBFTP e lo comunica all'amministratore.


    <?php
    $output=popen("/usr/local/etc/bbftpd status","r");


    //prendo tutto l'output prodotto dal comando
    $return="";
    while(!feof($output)){
            $return=$return.fread($output,2096);
    }
    echo $return;
    exit;
    ?>


    active_bbftp.php:
    A seconda dello stato della check box viene disattivato o attivato il servizio.


    <?php
    //controllo se la la check è stata     attivata oppure no
    if(isset($_POST['ftp']))    $comando="/usr/local/etc/bbftpd      start";   //comando   per
    attivare il servizio
    else $comando="/usr/local/etc/bbftpd stop"; //comando per disattivare il servizio
    $output=popen($comando,"r");


    //prendo tutto l'output prodotto dal comando
    $return="";
    while(!feof($output)){
            $return=$return.fread($output,2096);
    }


    //rindirizzo
    header('Location:index.php');
    ?>




Del Prete Domenico 873/1                                                   Pagina 70 di 101
    Il codice relativo al servizio BBFTP si presenta all'amministratore con questo layout:




                                Figura 6.1: layout BBFTP administrator




    6.3 Integrazione del servizio GridFTP

   Di seguito è riportata la pagina index.php che si propone come interfaccia principale
   all'amministratore. Per attivare, disattivare e monitorate lo stato del servizio essa
   richiama le pagine active_gridftp.php e service.php, le quali interagiscono con gli script
   di shell del sistema operativo sottostante con lo scopo di finalizzare le azioni richieste;
   inoltre grazie alla pagina up_files.php è possibile importare certificati macchina sul
   server facendo uso del protocollo ftp.


   index.php:
   <!DOCTYPE     html      PUBLIC     "-//W3C//DTD         XHTML         1.0   Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml">
     <head>
       <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />


Del Prete Domenico 873/1                                                       Pagina 71 di 101
        <title>Impostazioni BBFTP</title>


   <style type="text/css">
   <!--
   .style1 {
       font-size: 13px;
       font-weight: bold;
   }
   .style3 {font-size: 12px}
   .Stile1 {font-size: 14px; font-weight: bold; }
   -->
         </style>
         <script type="text/javascript" src="library/LibraryAjax.js"></script>
         <script type="text/javascript">
                 <!--
                 function send_status(frm)
                 {


                     //costruisco l'ogetto XMLHttpRequest
                     var AjaxRequest=assegnaXMLHttpRequest();


                     //controllo che l'oggetto ajax sia stato creato
                     if(AjaxRequest){
                        // impostazione richiesta asincrona in GET del file specificato
                        AjaxRequest.open("get", "service.php");
                          AjaxRequest.setRequestHeader('Content-Type', 'application/x-www-
   form-urlencoded');


                        AjaxRequest.onreadystatechange = function()
                            {
                                if (AjaxRequest.readyState == 1)
                                   {
                                          window.document.getElementById("result_status").inn
   erHTML = "Attendere...";
                                   }
                                   else
                                        {
                                             if(AjaxRequest.readyState == 4)
                                                             if(AjaxRequest.status == 200 ||
   AjaxRequest.status == 0)
                                                     {
                                                         window.document.getElementById("res
   ult_status").innerHTML ="<b>Stato del servizio</b><br>"+AjaxRequest.responseText;
                                                     }



Del Prete Domenico 873/1                                                   Pagina 72 di 101
                                                           else
                                                                {


                                                                    window.document.getElementById(
   "result_status").innerHTML      =     "<b>Stato       del   servizio</b><br>\nRisposta   inattesa:
   HTTP STATUS CODE " + AjaxRequest.status+"<br/>Riprova"
                                                                }
                                                           }
                                                     }
                                             AjaxRequest.send(null);
                      }
                      return false;
                 }
                 //-->
            </script>
     </head>
     <body>
       <?
       //eseguo comando di script per attivare variabili d'ambiente per i servizi grid
       $output = popen(". /home/grid-script.sh", "r");
       ?>
       <div align="center"><img src="gridftp.gif" alt="gridftpimage" /></div>
       <div id="gridftp">
            <p align="left" class="style1">&nbsp;</p>
            <p align="left" class="style1">&nbsp;</p>
            <p align="left" class="style1">&nbsp;</p>
                     <p   align="left"    class="style1">Gli        utenti   possono   effettuare   il
   trasferimento file abilitando il servio GridFTP sulla porta 2811.</p>
              <p align="left" class="style1">E' possibile eseguire il trasferimento dei
   file con <em>globus-url-copy </em> nella directory <em> /volume1/gridftp/</em></p>
            <form method="post" action="active_gridftp.php">
              <table>
                <tr>
                    <td class="style1">ATTIVATO</td>
                    <?
                $var=fopen("/home/stato.txt","r");
                //prendo tutto l'output prodotto dal comando
                while(!feof($var)){
                $return=trim(fread($var,1024));
                }


                fclose($var);
                $wood=array();
                $wood=explode("\n",$return);



Del Prete Domenico 873/1                                                          Pagina 73 di 101
                          if(trim($wood[0])=="gftp=1")   echo   "<td><input   type=\"checkbox\"
   name=\"ftp\" checked></td>";
                else echo "<td><input type=\"checkbox\" name=\"ftp\"></td>";


                ?>
                </tr>
                     <tr><td colspan="2" align="center"><input type="submit" name="submit"
   value="Applica"></td></tr>
            </table>
          </form>
          <div id="message_bbftp" align="center">
          <?
          if(isset($_REQUEST['mess_bbftp']) && trim($_REQUEST['mess_bbftp'])!="") echo
   $_REQUEST['mess_bbftp'];
          ?>
          </div>
       </div>
       <div id="status" align="center">
          <p align="center" class="style1">Controlla lo stato del servizio </p>
          <form onsubmit="return send_status(this);">
            <table align="center">
                <tr><td align="center"><input type="submit" name="status" value="Status"
   title="Clicca ed esegui il comando"></td></tr>
            </table>
          </form>
          <div id="result_status" align="center">
          </div>
       </div>
       <div id="upload">
         <p class="Stile1">Carica certificati</p>
         <p align="center" class="style1">ATENZIONE</p>
          <p align="center" class="style1">Il caricamento dei certificati &egrave; un
   operazione non reversibile</p>
         <p align="center" class="style1">si consiglia di effettuare il trasferimento
   solo se i ceritificati sono scaduti      </p>
         <form method="post" action="up_files.php" enctype="multipart/form-data">
           <table>
               <tr><td class="style1">Scegli file</td>
               <td><input type="file" name="file"></td></tr>
                     <tr><td colspan="2" align="center"><input type="submit" name="submit"
   value="Carica"></td></tr>
           </table>
         </form>
         <div id="message_up" align="center">



Del Prete Domenico 873/1                                                      Pagina 74 di 101
         <?
                if(isset($_REQUEST['mess_up']) && trim($_REQUEST['mess_up'])!="") echo
   $_REQUEST['mess_up'];
          ?>


         </div>
       </div>
     </body>
   </html>



   active_gridftp.php:
   Per attivare il servizio viene eseguito lo script di shell grid-attiva.sh:

   export GLOBUS_LOCATION=/opt/datatag_globus
   export GPT_LOCATION=/opt/datatag_gpt
    . $GLOBUS_LOCATION/etc/globus-user-env.sh
   /opt/datatag_globus/sbin/in.ftpd -S -p 2811
   echo gftp=1 >/home/stato.txt
   ps |grep ftpd: >>/home/stato.txt


   esso salva lo stato d'attivazione e il relativo PID (Process Identifer) del processo nel file
   stato.txt. Quando verrà inoltrata una richiesta per disattivare il servizio, il codice
   provvederà a controllarne lo stato accedendo al file stato.txt nel quale la prima riga
   rappresenterà lo stato del servizio, la seconda il PID di riferimento, memorizzati
   rispettivamente nei campi dell'array wood[0] e wood[1]. Successivamente la funzione
   explode salva tutti gli elementi della riga (stringhe senza spazi grazie alla funzione trim)
   nell'array number, il quale conterrà tanti elementi quante sono le parole che formano la
   riga; il PID del processo si troverà certamente nella prima posizione dell'array number e
   sarà passato come parametro d'ingresso allo script grid-disattiva.sh:


   export GLOBUS_LOCATION=/opt/datatag_globus
   export GPT_LOCATION=/opt/datatag_gpt
    . $GLOBUS_LOCATION/etc/globus-user-env.sh
   kill -9 $1
   echo gftp=0 >/home/stato.txt




Del Prete Domenico 873/1                                                    Pagina 75 di 101
   il quale disattiverà il servizio uccidendo il processo che lo identifica e aggiornando lo
   stato del servizio nel file stato.txt.

   <?php
   $var=fopen("/home/stato.txt","r");
                //prendo tutto l'output prodotto dal comando
                while(!feof($var)){
                $return=trim(fread($var,1024)); //prende 1024 della riga
                }


                fclose($var);
                $wood=array();
                $wood=explode("\n",$return);        //si salva la variabile
   if(isset($_POST['ftp'])){
                     //trim toglie spazi adiacenti alla riga
                if(!(trim($wood[0])=="gftp=1")) {
                      //eseguo comando di script per attivare il servizio GridFTP
                      $output = popen(". /home/grid-attiva.sh", "r");
                }
                header('Location:index.php');
   }
   else {
       if(trim($wood[0])=="gftp=1") {
                      $number=explode(" ",trim($wood[1]));
                      //eseguo comando per disattivare il servizio GridFTP
                       $output    =   popen(".   /home/grid-disattiva.sh   ".trim($number[0]),
   "r");
                      header('Location:index.php');
                }
                else header('Location:index.php');
   }
   ?>




Del Prete Domenico 873/1                                                    Pagina 76 di 101
   service.php:
   la pagina service.php viene utilizzata per monitorare lo stato del servizio accedendo al
   file stato.txt; leggendo la prima riga del file vine ricavato lo stato del servizio (gftp=0:
   disattivato, gftp=1: attivato) e mandato in output all'amministratore con messaggi di
   stampa.


   <?php
   $var=fopen("/home/stato.txt","r");
                //prendo tutto l'output prodotto dal comando
                while(!feof($var)){
                $return=trim(fread($var,1024));


   }


                fclose($var);
                $wood=array();
                $wood=explode("\n",$return);
                if(trim($wood[0])=="gftp=1") echo "Gridftp attivato";
                else echo "Gridftp non attivato";
   ?>



   up_files.php:
   La pagina seguente viene utilizzata per caricare il certificati macchina utilizzati da
   GridFTP; i certificati vengono caricati con l'ausilio del protocollo FTP e posizionati
   nella directory dei certificati con lo script cp_cert.sh; successivamente viene informato
   l'amministratore dell'esito del trasferimento.


   <?php
   $dim = 2097152; //dimensione massima del file
   $host = "143.225.93.250"; //host ftp
   $user = "admin"; //user ftp
   $password = "syno01scope01"; //password ftp
   $dir = "/cert/"; //directory di destinazione del file


   //controllo che il file sia stato scelto
   if (isset ($_FILES['file'])) {
       if ($_FILES['file']['size'] > 0) {
             //controllo la dimensione del file



Del Prete Domenico 873/1                                                   Pagina 77 di 101
              if ($_FILES['file']['size'] <= $dim) {


                    //apro sessione ftp
                    if (($con = ftp_connect($host,"21"))) {
                           if (ftp_login($con, $user, $password)) {
                                  if   (ftp_put($con,   $dir   .   $_FILES['file']['name'],
   $_FILES['file']['tmp_name'], FTP_BINARY)) {
                                          //chiudo la connessione ftp
                                          ftp_close($con);
                                          //esuguo comando per spostare il file caricato
   nella directory deicertificati
                                          $output   =   popen("/volume1/cert/cp_cert.sh",
   "r");
                                          header('Location:index.php?mess_up=File
   trasferito');
                                  } else {


                                          header('Location:index.php?mess_up=File       non
   trasferito');
                                  }
                           } else {
                                  header('Location:index.php?mess_up=Impossibile
   loggarsi');
                           }
                    } else {
                           header('Location:index.php?mess_up=Impossibile            aprire
   connessione ftp');
                    }
              } else {
                    header('Location:index.php?mess_up=Dimensione        massima       file
   superata');
              }
       } else {
              header('Location:index.php?mess_up=File non scelto');
       }
   } else {
       header('Location:index.php?mess_up=File non scelto');
   }
   ?>




Del Prete Domenico 873/1                                                 Pagina 78 di 101
   Il codice relativo al servizio GridFTP si presenta all'amministratore con questo layout:




                               Figura 6.2: layout GridFTP administrator




Del Prete Domenico 873/1                                                  Pagina 79 di 101
 7. Testing prestazionale dei servizi


    7.1 Il piano di testing


   Benchmark preliminari dsponibili in letteratura [16] eseguiti sul server DS 508 hanno
   fornito informazioni più accurate sulle reali prestazioni del sistema, soprattutto per
   quanto riguarda i servizi di trasferimento file preesistenti e il tempo di scrittura/lettura
   dei dati su diverse configurazioni di dischi. I test del server sono stati eseguiti
   effettuando trasferimenti con il client sullo stesso switch (da 1 Gbit/sec) in modalità
   esclusiva (con la sola connessione delle apparecchiature client e Synology server)
   utilizzando il protocollo FTP su tre classi di grandezze di file: large, medium e small,
   rispettivamente con le seguenti grandezze variabili: 2 trasferimenti x1,8GB totali, 63
   trasferimenti x1Gb totali e 14746 trasferimenti x659MB totali. I trasferimenti sono stati
   effettuati con tre configurazioni RAID differenti: RAID 0, 1, 5 riscontrando le seguenti
   differenze riportate in media aritmetica:
                           Velocità di scrittura in MByte/sec
                             LARGE                   MEDIUM                   SMALL
       RAID 0                  40,1                     36,6                     2,3

       RAID 1                  38,5                     35,5                     2,2

       RAID 5                   32                      28,3                     4,9


                           Velocità di lettura in MByte/sec
                             LARGE                   MEDIUM                   SMALL
       RAID 0                  75,4                     40,8                     1,1

       RAID 1                  60,8                     39,3                     1,1

       RAID 5                  72,5                      40                       1


   La configurazione dei dischi del server usata per i test di trasferimento effettuati
   nell'ambito del presente lavoro è stata quella RAID 0. Dopo aver effettuato



Del Prete Domenico 873/1                                                   Pagina 80 di 101
   l'implementazione dei servizi con successo, ho eseguito diverse batterie di test transfer
   con lo scopo di verificare la qualità del servizio offerto e il suo comportamento. A
   sostenere il confronto con i nuovi servizi è stato il protocollo FTP, il quale rimane
   sempre un punto di riferimento proprio perché rappresenta la base di tutti i protocolli di
   trasferimento esistenti. Tra i servizi implementati ho focalizzato maggiore attenzione su
   i test del protocollo GridFTP, in quanto più predisposto sulla sicurezza richiesta
   dall'infrastruttura preesistente.
   Tutte le prove sono state effettuate in condizioni di parità ma allo stesso tempo sono
   stati riprodotti i normali casi di bisogno dell'uso dei servizi, in modo da riprodurre
   situazioni ed esigenze ricorrenti, riconducibili all'uso medio delle risorse. Ogni batteria
   di test è composta da venti prove ripetute per ogni file trasferito (100MB, 200MB,
   400MB, 800MB, 1200MB, 2400MB) delle quali è stata ricavata una media aritmetica
   che rappresenta il singolo valore riportato su ogni grafico. Le macchine coinvolte nella
   prova sono state:


        ▪ User Interface di Bologna (appartenente al Centro Nazionale per la Ricerca
            e lo Sviluppo CNAF dell'INFN)
        ▪ User Interface di Cagliari (sezione INFN Cagliari)
        ▪ Storage Element Synology NAS Server (Data Center S.Co.P.E. Napoli)


   Le UI (User Interface) di Cagliari e Bologna sono state le macchine dove ho avviato le
   diverse ripetizioni di trasferimento, indirizzando il traffico dei dati verso il NAS Server
   di Napoli. Qualsiasi entità che fa uso di servizi file transfer risulta molto sensibile alla
   tipologia del Link di connessione sottostante. Il tipo di collegamento che permette la
   comunicazione fra l'User Interface di Bologna con Napoli è diverso da quello che
   collega Cagliari con Napoli. Entrambe le connessioni sono link dedicati, appartenenti
   alla rete GARR (Gruppo per l'Armonizzazione delle Reti della Ricerca) che offrono
   però larghezza di banda differente. Le politiche di trasmissione adottate su entrambi i
   collegamenti sono ti tipo best effort,ovvero non è fornita nessuna garanzia sulla
   consegna dei dati o sul livello di QoS (Quality of Service), ma tutte le comunicazioni


Del Prete Domenico 873/1                                                   Pagina 81 di 101
   avvengono con il massimo impegno possibile; questo tipo di politica può riscontrare
   una consegna dei pacchetti variabile in base all'attuale carico della rete. Il primo Link
   (Bologna – Napoli) si può considerare molto ampio (2,5 Gbps totali), anche se l'uso
   medio della rete non supera i 0,6 Gbit sia per l'input che per l'output. Il flusso dati che
   parte dalla sede GARR di Bologna usufruisce una banda di 10 Gbps; esso attraversa un
   totale di cinque router e diversi switch, arrivando a destinazione sulla banda partenopea
   di 2,5 Gbps; La figura 7.0 mostra la topologia GARR nell'intero territorio italiano:




                             Figura 7.0: IP Network Topology, 2008



Del Prete Domenico 873/1                                                  Pagina 82 di 101
   Nella figura successiva è possibile osservare il percorso che effettua l'informazione
   prima di arrivare a destinazione:




       Figura 7.0.1: Percorso dell'informazione tra l'User Interface di Bologna e il NAS server S.Co.P.E.




   Il secondo Link (INFN Cagliari – Napoli GARR) appartiene anch'esso alla rete GARR,
   ma dispone di banda molto inferiore rispetto quella che collega Bologna. Il flusso dati
   che parte da Cagliari attraversa un router in più (rispetto al link precedente) per un totale
   di 6 router e diversi switch d'interconnessione locale, inoltre sfrutta una banda totale di
   155 Mbps dei quali solo 30 Mbps dedicati alla connessione GARR. Nella figura
   seguente è specificato il percorso effettuato dall'informazione su questo specifico link:




Del Prete Domenico 873/1                                                               Pagina 83 di 101
       Figura 7.0.2: Percorso dell'informazione tra l'User Interface di Cagliari e il NAS server S.Co.P.E.




   Più avanti vedremo come proprio questa eterogeneità del supporto fisico di
   comunicazione ha permesso di verificare in modo rilevante il tipo di guadagno
   prestazionale tra il servizio FTP e quello GridFTP.
   Per ogni classe di test sono state ricavate le differenze prestazionali di velocità nell'unità
   di Mbyte al secondo; la stessa tipologia di informazioni è stata espressa nell'ordine dei
   tempi di trasferimento disponibili in altri grafici nell'Appendice N° 3.




Del Prete Domenico 873/1                                                                Pagina 84 di 101
   La successione dei test è schematizzata secondo il seguente ordine:
   Velocità di trasferimento FTP vs GridFTP (dalla sede CNAF-Bologna e dalla sede
   INFN -Cagliari) in 3 casi differenti:
        (1) Condizione di parità (configurazione parallelismo GridFTP con p = 1)
        (2) Confronto FTP – GridFTP (configurazione parallelismo p = 2)
        (3) Confronto FTP – GridFTP (configurazione parallelismo p = 8)




    7.2 I risultati dei Test

    (1) Condizione di parità (configurazione parallelismo GridFTP con p = 1)
    ◦ Velocità di trasferimento FTP vs GridFTP (da Bologna e da Cagliari)


   Il primo test è stato effettuato cercando di stabilire una situazione di parità tra i due
   protocolli, ovvero: sapendo che il GridFTP deriva dall'FTP e sapendo che quest'ultimo è
   un protocollo di trasmissione seriale (il nuovo pacchetto viene spedito solo quando la
   consegna del precedente è stata completata), ho cercato di creare lo stesso tipo di
   condizione nell'uso del GridFTP, cioè configurare l'opzione di parallelismo a uno (p =
   1), in modo da notare le eventuali “curiose” conseguenze. Come si può constatare , la
   condizione di parità fa risultare il servizio FTP leggermente più rapido rispetto a quello
   del GridFTP, da entrambe le posizioni geografiche; l'esperienza dei test di trasferimento
   mi ha permesso di rilevare che: anche configurando GridFTP con parallelismo TCP a 1
   (p = 1) la trasmissione viene eseguita sempre con approccio parallelo, ovvero una volta
   che la User Interface (client) ha stabilito la connessione (con l'host server), i pacchetti
   vengono spediti in maniera asincrona rispetto alla loro ricezione; questo tipo di
   trasferimento permette l'inoltro dei pacchetti in maniera più rapida, ma nella maggior
   parte dei casi procura oscillazione sulla velocità di trasferimento, la quale però tende ad
   assottigliarsi nella parte finale dello stesso; la leggera differenza è giustificata anche da
   un secondo motivo, infatti durante la trasmissione il GridFTP utilizza la crittografia
   dell'informazione, appesantendo leggermente i pacchetti trasmessi, inoltrando quindi


Del Prete Domenico 873/1                                                    Pagina 85 di 101
   quantità d'informazione maggiore rispetto a quella effettiva; tutto ciò procura una
   leggera perdita prestazionale che viene recuperata per trasferimenti file di dimensione
   maggiore; ovviamente questo tipo di “perdita” non viene riscontata con la
   configurazione parallela proprio perché viene sfruttato il multiplexing del flusso e la
   trasmissione separata degli stream.
   Questo tipo di perdita si può notare maggiormente nel caso dei trasferimenti effettuati
   da Cagliari, dove la banda disponibile è di 30 Mbps (molto inferiore rispetto alla banda
   disponibile da Bologna). Paradossalmente la trasmissione seriale FTP, in questo
   specifico caso di test, risulta essere più ordinata, rilevandosi più performante.


    (2) Confronto FTP – GridFTP (configurazione parallelismo p = 2)
    ◦ Velocità di trasferimento FTP vs GridFTP (da Bologna e da Cagliari)


   I test della prova successiva sono stati eseguiti configurando a due (p = 2) il parametro
   di parallelismo di GridFTP. Come si può notare dai risultati, la velocità dei trasferimenti
   con GridFTP risulta maggiore in media rispetto a quelli dell'FTP. Anche per file di
   dimensione più piccola si nota un leggero guadagno, ma nello specifico esperimento è
   emerso che la differenza maggiore si nota soprattutto per file di dimensione maggiore
   di 250 MByte circa.
   In tutti i test si nota la variazione di velocità in funzione della grandezza dei file
   trasferiti; emerge infatti che il servizio FTP (rispetto a GridFTP) risulta essere
   predisposto per il trasferimento di file dalle dimensioni relativamente piccole, infatti la
   velocità tende a seguire sempre un andamento quasi constante, non saturando
   completamente la banda disponibile. In modo differente invece GridFTP guadagna
   velocità di trasferimento gradualmente, fino a superare FTP per diversi ordini di
   grandezza, saturando quasi completamente la           banda disponibile (nel caso dei
   trasferimenti da Cagliari), oppure la velocità di scrittura del disco (nel caso dei
   trasferimenti da Bologna).




Del Prete Domenico 873/1                                                    Pagina 86 di 101
    (3) Confronto FTP – GridFTP (configurazione parallelismo p = 8)
    ◦ Velocità di trasferimento FTP vs GridFTP (da Bologna e da Cagliari)


   Da numerosi test ho notato che configurando il servizio GridFTP con parallelismo
   maggiore di due risultano sicuramente valori migliori, ma settando il parametro di
   configurazione p = 8 si è ottenuta la massima saturazione degli stream paralleli. Infatti
   per trasferimenti con opzione di parallelismo p > 8 si ottengono numerose oscillazioni
   di velocità che riducono leggermente le prestazioni di trasferimento risaltando il caso
   limite.
   I parametri del servizio FTP non possono essere configurati come quelli del GridFTP,
   questo rende i suoi valori statici con andatura simile in ogni esperimento; invece
   variando le opzioni di parallelismo di GridFTP fino al valore massimo di 8 è emersa una
   considerevole riduzione del tempo di trasferimento. Lo stesso modello di valori è
   riscontrabile sia da Bologna che da Cagliari; anche se le macchine User Interface
   occupano geograficamente locazioni diverse e sono connesse con una larghezza di
   banda differente, rispecchiano valori asintotici somiglianti. Basti pensare che (in questo
   specifico caso di test) i trasferimenti eseguiti da Bologna utilizzando il servizio FTP
   riscontrano una velocità media di 9,8 MB/s ( da Cagliari 2,6 MB/s rispettivamente),
   mentre quella del GridFTP sale a 28,3 MB/s (da Cagliari 2,9 MB/s rispettivamente).


   Gli ultimi due grafici (figura 7.3 e 7.4) dimostrano che l'aumentare del parametro di
   parallelismo non sempre porta benefici al protocollo GridFTP; esso infatti è soggetto a
   saturazione, limite oltre il qualche si corre rischio d'apportare squilibri all'intero
   trasferimento (oscillazioni di velocità), traducibili in abbassamento della velocità media
   di trasmissione e quindi dilatazione del tempo complessivo di trasferimento.




Del Prete Domenico 873/1                                                 Pagina 87 di 101
   Figura 7.1: Velocità di trasferimento FTP vs GridFTP parallelismo p=1,2,8 – CNAF Bologna ----> S.Co.P.E




    Figura 7.2: Velocità di trasferimento FTP vs GridFTP parallelismo p=1,2,8 – INFN Cagliari ----> S.Co.P.E




Del Prete Domenico 873/1                                                              Pagina 88 di 101
    Figura 7.3: Velocità di trasferimento FTP vs GridFTP parallelismo p > 8 – CNAF Bologna ----> S.Co.P.E
    Si può notare che aumentando il parametro con p>8 si ha: sia una saturazione che una leggera perdita.




    Figura 7.4: Velocità di trasferimento FTP vs GridFTP parallelismo p > 8 – INFN Cagliari ----> S.Co.P.E
   Si può notare che aumentando il parametro con p>8 si riscontra una perdita nella velocità di trasmissione.



Del Prete Domenico 873/1                                                              Pagina 89 di 101
 8. Conclusioni


   Le conclusioni ricavate dal lavoro svolto identificano due facce di una stessa medaglia;
   da un lato c’è stato l’obiettivo di fornire un’alternativa a sistemi di storage costosi e
   complessi come quello già residente nel Data Center; dall’altro c’è stato un secondo
   obiettivo, ovvero rendere un sistema embedded come quello di un NAS server
   espandibile, con la possibilità d’implementare su di esso nuovi servizi normalmente non
   supportati e molto usati in ambito grid, in modo da integrare l’apparecchiatura
   nell’infrastruttura grid S.Co.P.E preesistente come unità di Storage Element, risolvendo
   così non solo problematiche di carattere implementativo, ma anche inerenti alla
   sicurezza.
   Tutti i test effettuati hanno permesso di rilevare diversi aspetti e differenze:
    ◦ A prescindere dalle tipologie di test eseguite, il GridFTP (a differenza dell'FTP) è
        risultato molto più predisposto al trasferimento di file di grandi dimensioni (per
        file di grandezza maggiore di 250 megabyte circa, in questa specifica classe di
        test).
    ◦ Il GridFTP nel suo caso peggiore (condizione di parità) raggiunge quasi le stesse
        prestazioni del servizio FTP, tenendo conto che le sue doti di trasferimento
        risultano apprezzabili soprattutto per file di grandi dimensioni.
    ◦ Il servizio FTP nel suo caso migliore non riesce mai a saturare la banda
        disponibile, contrariamente il GridFTP, grazie al parallelismo dei flussi TCP, riesce
        ad effettuare quasi una saturazione completa del canale disponibile. Proprio per
        questo motivo, anche test già eseguiti in passato hanno dimostrato che il protocollo
        GridFTP è molto performante sopratutto sul geografico, ovvero tra entità molto
        distanti fra loro, sopratutto dal punto di vista delle apparecchiature che i dati
        devono attraversare (generalmente router e switch) prima che arrivino a
        destinazione.
    ◦ L'ultimo aspetto da considerare è quello relativo alla sicurezza, in quanto a
        prescindere dalla posizione geografica dell'host, dalla velocità dei trasferimenti e
        dalla grandezza dei file da trasferire, il GridFTP risulta il protocollo di

Del Prete Domenico 873/1                                                     Pagina 90 di 101
        trasmissione più sicuro, che come abbiamo potuto già constatare precedentemente
        è un aspetto di fondamentale importanza soprattutto in ambito grid.


   In definitiva le attività di testing dimostrano che gli obiettivi sono stati entrambi
   raggiunti grazie alle considerevoli estensioni apportate al sistema, come i protocolli di
   file transfer BBFTP e GridFTP, i quali oltre ad aver arricchito la rosa dei servizi che
   offre il sistema, garantiscono i massimi livelli di sicurezza esistenti sullo scambio delle
   informazioni, utilizzando cifratura tramite algoritmo RSA e certificati X.509 rilasciati
   dalla Certification Autority. Inoltre le estensioni implementate, hanno potenziato
   notevolmente il rendimento dell’apparecchiatura permettendo l’incremento dell’uso
   intensivo delle risorse; per di più sono stati curati adeguatamente anche gli aspetti
   dell'usabilità dei nuovi servizi implementati, in quanto l'amministratore del sistema può
   maneggiare in tutta sicurezza le funzionalità dei protocolli attraverso le interfacce web
   sviluppate. Questo bilancio positivo quindi permette d’affermare che l’apparecchiatura
   presa in esame, grazie alle nuove estensioni apportate, può seriamente essere presa in
   considerazione da diverse realtà aziendali, centri di calcolo pubblici e privati, come
   soluzione alternativa a problematiche di storage esistenti, sia dal punto di vista
   economico che gestionale.




Del Prete Domenico 873/1                                                  Pagina 91 di 101
   Bibliografia


   [1] Progetto S.Co.P.E
   URL: www.scope.unina.it
   [2] The Anatomy of the Grid, Ian Foster, Varl Kesselman, Steven Tuecke
   [3] INFNGRID, G. Tortone INFN (21/02/07)
   [4] DAS, Direct Attached Storage
   URL: it.wikipedia.org/wiki/Direct_Attached_Storage
   [5] SAN, Storage Area Network
   URL: it.wikipedia.org/wiki/Storage_Area_Network
   [6] Large Hadron Collider
   URL: http://lhc.web.cern.ch/lhc/
   [7] Tier della GRID, Introduzione alle griglie computazionali (slides del corso), Prof. L.
   Merola.
   [8] SRM, StoRM, Giuseppe Misurelli - Corso di formazione per amministratori di siti
   Grid (Slides acces(storm) )
   [9] GPFS General Parallel File System,
   URL: http://www-03.ibm.com/systems/clusters/software/gpfs/index.html
   Alessandro Brunengo INFN-Genova “Cratteristiche e Prestazioni”
   [10] LUSTRE file system
   URL: http://www.sun.com/software/products/lustre/
   [11] FTP File Transfer Protocol
   URL: http://openskill.info/infobox.php?ID=759
   [12] SCP, Secure Copy
   URL: http://it.wikipedia.org/wiki/Secure_copy
   [13] BBFTP, BaBar File Transfer Protocol
   URL: http://doc.in2p3.fr/bbftp/
   [14] GridFTP
   URL: www.infis.univ.trieste.it/~noodies/html
   [15] OGSA, OGSI

Del Prete Domenico 873/1                                                  Pagina 92 di 101
   URL: http://gdp.globus.org/gt3-tutorial/multiplehtml/ch01s01.html
   [16] Benchmark Synology DS 508
   URL: http://www.behardware.com/articles/718-1/test-synology-ds508.html




Del Prete Domenico 873/1                                               Pagina 93 di 101
   Appendice N°1
   Caratteristiche tecniche LACIE ethernet Disk:




                                    Figura a1: LaCie back



    • Fornita di serie con Windows XP® Embedded
    • Supporta Active Directory per la partecipazione a domini Windows
    • Controllo degli accessi: condivisioni, gruppi e privilegi utente
    • Accesso remoto ai dati tramite Web: HTTP o FTP
    • Quattro porte USB 2.0 per il backup su unità esterne o l'espansione
    delle capacità
    • Firewall per la protezione dei dati
    • LaCie Network Assistant per la mappatura e la configurazione
    automatica delle unità
    • Design ultra-piatto in alluminio, installabile su rack
    Rete
    • Rilevamento automatico del protocollo di rete
    10/100/1000 Base-T
    • SMB (Windows), AFP v3.1 (Mac), FTP, HTTP
    • Assegnazione automatica degli indirizzi IP
    tramite server DHCP
    • Protocollo Apple Bonjour
    • Microsoft Active Directory
    • Autenticazione Kerberos v5.0
    • DNS, WINS
    • File Level Security (ACL)
    • Accesso in rete


Del Prete Domenico 873/1                                                 Pagina 94 di 101
    Tipi di client
    • Microsoft Windows® 98SE, Windows 2000,
    Windows Me, Windows XP e Windows Vista™
    • Mac® OS 9** e Mac OS X
    • Linux 2.4 e versioni successive; UNIX
    Browser Web
    • Microsoft® Internet Explorer
    • Mozilla Firefox
    • Apple Safari™
    Prestazioni
    • Velocità di lettura dei file: fino a 30 MB/s
    • Velocità di scrittura dei file: fino a 19 MB/s
    Funzionalità di backup
    • Genie Backup Assistant per il backup di workstation Windows
    • Intego Backup Assistant (o Time Machine) per il backup di
    workstation Mac
    • Funzione speciale per il ripristino della configurazione originale
    della workstation
    • Backup su unità DAS tramite USB o su unità NAS
    Contenuto della confezione
    • LaCie Ethernet Disk
    • CD con LaCie Network Assistant e la Guida
    per l'utente
    • Piedini LaCie per il montaggio in modalità
    indipendente
    • Cavo Ethernet
    • Alimentatore




Del Prete Domenico 873/1                                                   Pagina 95 di 101
   Appendice N° 2
   Caratteristiche tecniche Synology NAS Server DS 508




                             Figura a2: Synology DS 508 back



   MODELLO DS-508
   HARDWARE
   CPU Clock: 800 MHz
   RAM: 512MB
   HDD Interno: 3.5” SATA(II) 5X HDD
   Interfaccia esterna: 2X porte USB 2.0, 1x porta eSATA
   Misure: 203 mm X 242 mm X 177 mm
   Peso: 4,75 kg
   Rete locale: 2X Gigabit
   Ventola: 2X (80 mm X 80 mm)
   Power Recovery
   Alimentatore AC Tensione ingresso: da 100 V a 240 V
   Frequenza di alimentazione: da 50Hz a 60Hz, Monofase
   Capacità massima (HDD Interni): 10 TB
   Numero massimo IPCam: 10
   Temperatura operativa: da 5 a 35°C
   Temperatura immagazzinamento: da -10 a 70°C
   Umidità relativa: dal 5% al 95%RH


Del Prete Domenico 873/1                                       Pagina 96 di 101
   Altezza massima di esercizio: 3048 metri
   CONSUMO
   82w (Accesso);
   27w (Ibernazione)
   CERTIFICAZIONI
   FCC Class B,
   CE Class B,
   BSMI Class B,
   VCCI Class B
   PROTOCOLLI DI RETE
   CIFS
   AFP (3.1)
   FTP
   INTEGRAZIONE WINDOWS ADS
   ADS Support
   Domain users login via Samba/AFP/FTP
   Synology Data Replicator 3 per Domain Users
   SICUREZZA
   "FTP over SSL (explicit)" o "FTP over TLS (explicit)"
   Encrypted Network Backup
   HTTPS Connection
   FTP Auto-Block
   FILE SYSTEM
   EXT3
   FAT (Solo disco esterno)
   NTFS (Solo disco esterno Lettura)
   CONDIVISIONE FILE
   Numero massimo utenti: 2048
   Numero massimo gruppi: 256
   Numero massimo cartelle condivise: 256
   Numero massimo connessioni simultanee: 128

Del Prete Domenico 873/1                                   Pagina 97 di 101
   UTILITA'
   Synology Assistant
   Synology Data Replicator 3
   Synology Download Redirector
   Procedura guidata Aggiungi stampante
   APPLICAZIONI
   Survelliance Station
   Photo Station 3
   File Station
   Audio Station
   Web Station PHP/MySQL
   Download Station
   iTunes Server
   SUPPORTO SERVIZIO UPnP MULTIMEDIA
   Sony PS3, Microsoft Xbox360
   Formati Audio: AAC, M4A, MP3, Ogg Vorbis, WAV, WMA, WMA VBR, WMA PRO,
   WMA Lossless
   Formati Video: ASF, AVI, DAT, DivX, MP4, MPEG1, MPEG2, MPEG4, VOB, WMV,
   XviD
   Formati Immagini: BMP, JPG (jpe, jpeg), GIF, ICO, PNG, PSD, TIF (tiff), UFO
   Formati Playlist: WPL, M3U
   SUPPORTO SERVER ITUNES
   Formati Audio: MP3, M4A, M4P
   Formati Playlist: M3U, WPL
   SUPPORTO AUDIO STATION
   Formati Audio: AAC, M4A, MP3, Ogg Vorbis, WMA, WMA VBR
   Formati Playlist: M3U, WPL
   Radio Internet: SHOUTcast, Radioio
   SUPPORTO PHOTO STATION 3
   Formati Video: ASF, AVI, MPEG1, MPEG4, WMV, XviD, DivX, DAT,
   MP4, MPEG2, RM, RMVB, VOB

Del Prete Domenico 873/1                                            Pagina 98 di 101
   Formati Immagini: BMP, JPG (jpe, jpeg), GIF
   GESTIONE
   AJAX-based Management UI
   Download Station Bandwidth control
   Download Station Port Range Setup
   Editable HTTP Error Page
   Email Alert Message
   Email Notification for New User
   External HDD Hibernation (eSATA, USB)
   Firmware Upgrade
   FTP passive port range
   Hide-able Shared Folder
   Internal HDD Hibernation
   Scheduled Power On/Off
   Port range for BitTorrent
   Removable Default Shared Folder
   System Temperature
   Ez-Internet
   PPPoE
   UPS Management (Over USB 2.0)
   User Quota
   Web-based Download Station
   GESTIONE RAID
   Tipo di Volume: Disco singolo, RAID 0, RAID 1, Raid 5
   Aggiornamento da disco singolo a RAID 1
   Espansione RAID 1 o RAID 5 con Grossi hard-disk
   Espansione RAID 5 Aggiungendo Hard Drive a caldo
   Auto ricostruzione del Volume dopo una mancanza di energia elettrica
   Aggiornabile in RAID 5 aggiungendo un hard-disk a caldo
   Espansione a RAID 6 aggiungendo un hard-disk a caldo



Del Prete Domenico 873/1                                              Pagina 99 di 101
    SOLUZIONI DI BACKUP
    Backup di rete
    Backup locale
    Desktop Backup (usando Synology Data Replicator 3)
    Copia USB
    SOLUZIONI DI BACKUP DI TERZE PARTI
    Acronis True Image
    Symantec Backup Exec
    EMC Retrospect
    LaCie SilverKeeper
    CLIENTS SUPPORTATI
    dal Windows 2000 ai più recenti
    dal Mac OS 10.3 ai più recenti
    SUPPORTO STAMPANTI
    Numero massimo stampanti: 1
    Protocolli supportati: LPR, CIFS, AppleTalk
    LINGUE
    Inglese, Italiano, Spagnolo, Tedesco, Francese, Danese, Norvegese, Svedese, Koreano,
    Cinese tradizionale, Cinese Semplificato.
    AMBIENTE
    RoHS Compliant
    CONTENUTO DELLA CONFEZIONE
    DS508 Unità principale
    CD d'installazione
    Note di benvenuto
    Kit di montaggio
    Cavo alimentazione
    Cavo rete 2M RJ-45




Del Prete Domenico 873/1                                              Pagina 100 di 101
    Appendice N° 3




  Figura 10.1: Tempi di trasferimento FTP vs GridFTP parallelismo p=1,2,8,12 – CNAF Bologna ----> S.Co.P.E




   Figura 10.2: Tempi di trasferimento FTP vs GridFTP parallelismo p=1,2,8,12 – INFN Cagliari ----> S.Co.P.E


Del Prete Domenico 873/1                                                             Pagina 101 di 101

								
To top