A mia nonna Frassidera

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "A mia nonna Frassidera"

Transcript

1 A mia nonna Frassidera

2 Indice 1 GRID Cos e? L architettura GRID Interoperabilità Descrizione dell Architettura Situazione Attuale della GRID L architettura di glite Alien, Globus Toolkit, Kerberos e Xen Virtualizzazione Para-Virtualization Xen A Kerberized Certification Authority Kerberos SSL/TLS Kerberos Credential Translator per il WEB Globus Toolkit OGSA-WS-WSRF GT AliEn L Architettura di Alien Installazione Installazione di Xen Installazione di Kerberos e AFS Installazione AFS Installazione di KCA & Kx Installazione di un sistema batch: SGE Installazione di Globus Configurazione della Security Configurazione del GridFTP, RFT e GRAM Configurazione di WebMDS Globus Delegation e KCA Criptografia a Chiave Pubblica e X Criptografia a Chiave Publica Certificati X

3 ii INDICE 4.2 GT4 Delegation Delegation e single sign-on simple-ca e KCA simple-ca Submit di un job su Globus KCA e Globus Confronto tra KCA e simple-ca globusrun-ws da itterbio a disprosio Futuri sviluppi AliEn a Firenze Installazione Configurazione Installazione di un Worker Node Installazione di AliRooT AliEn in Esecuzione Possibile Sviluppo: AliEn e KCA Conclusioni 91 A Messaggi in debug di globusrun-ws 93 A.1 globusrun-ws con autenticazione verso simpleca A.2 globusrun-ws con autenticazione verso KCA A.3 Messaggi in debug di globusrun-ws di un job sottomesso da una simpleca riconosciuta ma esterna al pool di Globus

4 Elenco delle figure 1.1 GRID Architettura GRID Layered I Servizi di glite Architettura del WMS di glite Visione globale dell architettura di glite Virtualizzaziione Shared OS Virtualization Confronto Para-Virtualization & Full System Virtualization Para-virtualizzazione Xen Logo Kerberos Autenticazione Kerberos Protocollo di handshake SSL Protocollo KX Protocollo KCT Collaborazione OGSA-WSRF Architettura dei Web Services WSDL Stubs Interazione Client/Server di un Web Service Server Side di un applicazione Web Service Implementazione della struttura di GRAM Diagramma degli stati di un job in Globus Componenti di ALiEn Architettura di ALiEn File Catalogue di ALiEn Autenticazione di ALiEn Pull Model di ALiEn MonALISA Sistema di Monitoring di ALiEn Sala Macchine Dipartimento di Matematica U. Dini terbio.math.unifi.it, olmio.math.unifi.it e itterbio.math.unifi.it erbio.math.unifi.it e tulio.math.unifi.it Web MDS Main page Web MDS Group Detail Web MDS RFT Detail Ctittografia a Chiave Pubblica Generazione di una Firma Digitale

5 iv ELENCO DELLE FIGURE 4.3 Esempio di un certificato Digitale CA trustworthy Delegation Un esempio di certificato rilasciato dal proxy Un esempio di certificato rilasciato dal proxy Login ed Informazioni di un accesso al Globus Toolkit Selezione di KCA come CA di default AliEn Installer AliEn Installer - Errore piattaforma non impostata Selezione pacchetti per l installazione di AliEn a Firenze LDAP VO AliEn - Florence - Configurazione CE LDAP VO AliEn - Florence - Configurazione SGE LDAP VO AliEn - Florence - Configurazione Monitor La coda di SGE Site di Firenze Inserito nella VO di ALICE ma inattivo Site di Firenze Inserito nella VO di ALICE attivo ma senza jobs in coda Site di Firenze Inserito nella VO di ALICE attivo e con jobs in elaborazione Tre jobs Attivi su Firenze Active jobs in Florence Zombie jobs in Florence

6 Ringraziamenti Vorrei ringraziare i miei genitori per il sostegno con cui hanno accompagnato la mia carriera universitaria e non solo, mia sorella, mio cognato, che forse è più un fratello, le nonne e gli zii. Un grazie particolare va al mio Relatore, Prof. Gregorio Landi, che mi ha permesso di fare una stupenda esperienza presso il CERN, al mio correlatore Dott. Alberto Mancini che mi ha sostenuto moralmente e professionalmente durante tutta la fase di sviluppo di questa tesi. Un Grazie a Massimiliano Masi, Ceri Stefano e Giacomo Sacchetti, che hanno condiviso con me gioie e dolori degli esami universitari. Non posso escludere dai miei ringraziamenti la mitica V C che dagli anni del liceo non mi ha mai abbandonato, i R.I.C. (Ettore compreso) che ormai sono parte della mia famiglia, i mitici compagni della Pallamano Calenzano e gli amici Alessio, Federico, Adriano, Sara, Eleonora, Elisa, Matteo, Riccio, Sato, Alessandro, Konse, Luca, Ilaria, Bizio, Zaza, Claudia, Chiara, Gianni, Monia, Maso e Francesca. Pensando che sono solo circa ventitre anni che la conosco come posso esimermi dal ringraziarla. Grazie Francesca per aver condiviso con me asilo, elementari, medie, superiori e non solo. Un grazie anche a tutte le persone che mi hanno sopportato in questi ultimi mesi durante la stesura di questa tesi, ovvero tutti i colleghi della Savino del Bene IT, la Fefi, il mio neurone Ciccio Sara e la mitica Laura (o multa che corre). Un grazie particolare è rivolto ad una persona speciale che mi è vicina nonostante tutto, che mi sopporta nei momenti permalosi e mi rallegra quando lo sconforto (ok le menate che mi faccio da solo) prendono il sopravvento: GRAZIE ELENA.

7 vi ELENCO DELLE FIGURE

8 Introduzione Lo scopo di questo lavoro è analizzare un ambiente GRID nelle sue componenti, con particolare attenzione al sistema di autenticazione e delega delle credenziali proponendo un alternativa all utilizzo di certificati X.509, basata sul sistema di autenticazione Kerberos. Struttura dei capitoli Diamo uno sguardo all organizzazione dei capitoli. Nel Capitolo 1 introdurremo il concetto di GRID System. Vedremo cosa sono i sistemi Grid, come è iniziata la ricerca in questo settore e quali sono le problematiche che intende affrontare. La Grid research è in rapida evoluzione e progetti ed iniziative di vario tipo nascono frequentemente in ogni parte del mondo. Cercheremo di dare le informazioni di base sui progetti di maggior interesse e visibilità. Nel Capitolo 2 descriveremo i software che compongono l ambiente di test utilizzato per verificare l effettivo funzionamento dell approccio presente in questa tesi. Vedremo in dettaglio i concetti di Virtualizzazione, Certification Authority come servizio Kerberos, Globus Toolkit e AliEn. AliEn è uno degli ambienti GRID sviluppati presso il centro europeo di ricerca nucleare (CERN ). Nel Capitolo 3 descriveremo la realizzazione dell ambiente di lavoro di questa tesi. Vedremo in dettaglio i passaggi necessari per l installazione di Xen, come sistema di virtualizzazione, Kerberos e AFS, come sistema di autenticazione e storage distribuito, KCA e Kx509, come Certification Authority basata su Kerberos (Kerberized CA), Sun Grid Engine, come sistema batch, Globus Toolkit 4, come ambiente di studio e testing per i sistemi di autenticazione Grid e AliEn. Nel Capitolo 4 descriveremo il sistema di autenticazione attualmente usato dagli ambienti GRID e il sistema proposto come alternativa. Vedremo in dettaglio il funzionamento dell autenticazione con le Certification Authority adottate dai Sistemi GRID come glite e AliEn e mostreremo come sia possibile usare come Certification un sistema di autenticazione basato su Kerberos. Nel Capitolo 5 descriveremo la realizzazione di un ambiente GRID reale, AliEn. Vedremo come si installa e lavora un sito del gruppo di ricerca ALICE (A Large Ion Collider Experiment), presso il CERN di Ginevra. Inoltre delineeremo come

9 2 ELENCO DELLE FIGURE applicare i test svolti nel capitolo precedente a questa realtà, permettendo ad utenti di un site krb (dotato di un sistema di autenticazione Kerberos) di accreditarsi verso la GRID, mediante l utilizzo dei servizi della KCA. Inoltre mostreremo i vantaggi che si otterrebbero nel gestire la GRID con macchine virtuali, ovvero avere la possibilià di mantenere gli host vivi anche durante le sostituzioni (o manutenzioni) hardware, in quanto XEN permette la migrazione di una macchina in esecuzione risultando totalmente trasparente all utente ed alle applicazioni. È disponibile una versione di questa tesi in lingua inglese al seguente url:

10 1GRID As computer networks become cheaper and more powerful, a new computing paradigm is poised to transform the practice of science and engineering.[10] Ian Foster 1.1 Cos e? The GRID (La Griglia) è il nome con cui viene chiamato il progetto che dal 1999, si propone di fornire una visione globale delle risorse computazionali (CPU e Storage) di coloro che decidono di partecipare a questo progetto [11]. Figura 1.1: GRID Quando si parla della Grid, ci viene presentato un nuovo modo di pensare ed usare il computer. L idea base è la volontà di creare un enorme Super Computer ([7])

11 4 CAPITOLO 1. GRID unendo le risorse di ogni piccola unità che compone la griglia ottenendo un immensa potenza di calcolo, impensabile altrimenti. L insieme delle tecnologie usate viene definito Grid Computing e le componenti Virtual Organizatons (VO). Il concetto di Organizzazione Virtuale è stato formulato per evidenziare la natura che unisce i componenti di una griglia, siano questi persone fisiche o VO sottostanti (Università, gruppi di ricerca, ecc..). Ogni membro mette a disposizione le prorpie risorse (hardware e software) defininendo chiaramente cosa è condiviso, a chi è permesso condividere e le condizioni sotto cui è disponibile la condivisione. Secondo queste direttive si è cercato di costruire l infrastruttura per ottenere un modo flessibile, sicuro e coordinato per condividere risorse tra gruppi dinamici di persone, dando così origine alla tecnologia della griglia, di cui elenchiamo i principali servizi: Autenticazione Sicurezza Autorizzazione Naming Scheduling Servizio per l esecuzone remota Il principale compito di questi servizi è quello di generare un unica interfaccia indipendentemente dalla configurazione di ogni Virtual Organization. 1.2 L architettura GRID Questa tecnologia è stata pensata per rendere possibile una condivisione flessibile di risorse tra le VO partecipanti. Un esempio pratico e chiaro si ha pensando alla ricerca scientifica, ad esempio al Cern, dove tanti gruppi di ricerca partecipano all esperimento LHC e devono condividere risorse. Grazie alla tecnologia GRID (che non a caso è stata sviluppata principalmente al Cern:AliEn e GLite, di cui parleremo nel capitolo successivo, sono nati e sono tuttora sviluppati presso il centro di ricerca europeo) viene condivisa questa conoscienza permettendo a tutti i membri di poter effettuare i propri studi jobs, rendendo possibile il lavoro dei vari gruppi su moli di dati altrimenti intrattabili. Il problema principale è quindi permettere alle Vitual Organization di stabilre relazioni di condivisione per raggiungere un efficace INTEROPERABILITÀ. Questo concetto espresso su una rete di computer equivale a definire dei protocolli comuni in grado di garantire i servizi richiesti (Sez. 1.1), spesso definito middleware Interoperabilità Le relazioni definite per ottenere un efficace condivisione dovono: Facilitare l ingresso dinamico di nuovi utenti, indipendentemente dalla piattaforma, dal linguaggio e dall envirovment di programmazione (flessibili e leggeri).

12 1.2. L ARCHITETTURA GRID 5 In assenza di protocolli capaci di garantire questo tipo di collaborazione, le VO sarebbero costrette ad effettuare condivisioni bilaterali, difficilmente erogabili a terze parti. Un particolare ancor più vincolante sarebbe la creazione di nuove VO che necessiterebbe di specifiche veramente limitanti. Risulta quindi evidente la necessità di standard protocols and syntaxes, rivoluzionando così le modalità di condivisione, proprio come il WEB (HTTP e HTML) ha rivoluzionato lo scambio di informazioni. La vera difficoltà nel creare questo standard risiede nel concedere la massima, se non totale, libertà ai meccanismi locali di sharing, poichè le istituzioni (VO) posso cambiare nel tempo cambiando così le politiche locali di gestione delle risorse. Per preservare questa peculiarità i protocolli gestiscono le interazioni tra le componenti e non le loro implementazioni. Per coaudiuvare meglio l interoperabilità tra le componenti della GRID sono stati utilizzati i Web Services, che sono definiti dal protocollo che usano e dal comportamento per cui sono stati implementati. Definendo uno standard services per ogni servizio offerto alle VO si può astrarre la modalità adottata localmente per fornirlo. Un maggiore interoperabilità è stata raggiunta grazie alla definizione di APIs (Application Programming Interfaces) e SDKs (Software Development Kits), che permettono agli sviluppatori delle VOs di elaborare software sofisticati per ambienti di esecuzione dinamici e complessi senza rinunciare alla possibilità di condividerli con la GRID Descrizione dell Architettura Il risultato delle considerazioni precedenti è stata la realizzazione di un architettura a layer seguendo i principi del hourglass model (modello a clessidra) ([14]). Figura 1.2: Architettura GRID Layered Il collo della clessidra è rappresentato da un insieme di astrazioni (soprattutto riguardanti le risorse) e dai protocolli (TCP e HTTP, ovvero la connectivity).

13 6 CAPITOLO 1. GRID La parte alta della clessidra invece rappresenta le molteplici astrazioni sui differenti comportamenti che possono essere definiti su questi protocolli che a loro volta sono definiti sulle diverse tecnologie possibili, parte bassa della clessidra. Passiamo ora ad analizzare brevemente i livelli di questa architettura: FABRIC CONNECTIVITY RESOURCE COLLECTIVE APPLICATIONS Fabric Questo livello fornisce l accesso alle risorse che vengo condivise dal protocollo della Griglia, per esempio un sistema di storage, un catalogo o una risorsa computazionale. I Fabric Component implementano quindi le specifiche locali necessarie per l accesso alle risorse (fisiche o logiche), che ad alto livello sono viste come il risultato di una normale operazione di condivisione. Ovviamente le specifiche implementate a questo livello vincolano fortmente le operazioni permesse ai layer superiori. Si è scelto di richiedere ai Fabric Component solo delle funzionalità minime sulle quali si basa l astrazione dalla risorsa sottostante, ovvero: 1. un enquiry mechanism per poter ottenere informazioni sullo stato le capacità della risorsa. 2. un resource managment per erogare effettivamente i servizi messi a disposizione della Griglia. Connectivity In questo layer vengono definiti i protocolli di comunicazione e autenticazione richiesti per una transazione GRID specifica. Quelli definiti per la comunicazione favoriscono lo scambio di dati tra più Fabric Layer. I protocolli relativi all Autenticazione garantiscono meccanismi di crittografamento sicuri per il riconoscimento di utenti e risorse. Le principali soluzioni adottate dalle VO per il processo di autenticazione hanno le seguenti caratteristiche: + Single sign on: Gli utenti devono avere la possibilità di accedere a tutte le risorse grid per cui possiedono i permessi effettuando il login una sola volta. + Delegation: Un utente deve avere la possibilità di delegare le proprie credenziali di accesso alle risorse ad un programma da lui eseguito.

14 1.2. L ARCHITETTURA GRID 7 + Integration (Integrazione con i sistemi alle VO locali di sicurezza): Le soluzioni adottate localmente devono poter essere non vincolate dalla Grid e la Grid Security deve essere in grado di interagire con esse. + User-based trust solution: Un utente deve poter usufruire contemporaneamente delle risorse a cui può accedere senza un interazione tra i security administrator dei siti a cui appartengono le risorse. Resource Questo livello fornisce un set di protocolli (e APIs e SDKs) elaborati sopra al Connectivity layer. Servono a garantire una sicura negoziazione, il monitoraggio, il controllo e tutte le operazioni necessarie per la condivisione delle singole risorse. L implementazione di questi rotocolli viene denominata Fabric layer (accesso e controllo locale delle risorse). Questo livello cura solamente gli aspetti relativi alle singole risorse lasciando il compito di una visione globale della Griglia al Collective Layer. I protocolli sviluppati da questo livello possono essere suddivisi in due classi principali: + Informazione: Rende possibile conoscere la struttura e lo stato di una risorsa + Controllo: Fornisce il meccanismo di negoziazione dell accesso alla risorsa, controllando che le condizioni di condivisione della risorsa siano rispettate dalla richiesta. Collective Rispetto al livello precedente questo focalizza l attenzine sull insieme delle risorse partecipanti alla GRID e soprattutto alle loro interazioni. In questo layer è infatti possibile implementare varie tipologie di condivisione senza dover imporre nuovi requisiti alle risorse sottostanti. Esempi di funzionalità messe a disposizione delle VO dal Collective Layer sono: + Directory services: Permette di rilevare l esistenza e le proprietà delle risorse partecipanti. + Co-allocation, scheduling, and brokering services: Permette alle VO di allocare una o più risorse.

15 8 CAPITOLO 1. GRID + Monitoring and Diagnostics services: Monitoriza lo stato delle risorse evidenziando eventuali intrusioni. Le Collective functions possono quindi essere implementate come servizi persistenti, poichè sono associati a protocolli specifici, SDKs e APIs a cui le applicazioni fanno riferimento. Applications L ultimo livello della GRID fornisce le applicazioni per l utente che si interfacciano direttamente con gli ambienti delle VO. Queste sono ovviamente costruite su i servizi forniti dai livelli sottostanti e possono essere di qualsiasi tipologia, non facendo mai riferimento alla struttura delle risorse utilizzate. Le applicazioni rappresentano infatti la parte superiore della clessidra. CLI Access API Security Authorization Auditing Authentication Information & Monitoring Information & Monitoring Application Monitoring Data Management Workload Management Metadata Catalog File & Replica Catalog Accounting Job Provenance Package Manager Storage Element Data Movement Site Proxy Computing Element Workload Management Figura 1.3: I Servizi di glite 1.3 Situazione Attuale della GRID Attualmente il progetto Grid è sostenuto da tutta la comunità scientifica mondiale, guidata dall unione Europea che ha riunito tutti i progetti correlati sotto EGEE (Enabling Grids for E-Science in Europe). Lo scopo di questo progetto è stato dare credibilità e stabilità al progetto GRID, che si era sviluppato in numerosi gruppi di ricerca senza una vera coordinazione e condivisione di conoscenza. Il primo passo di EGEE è stato quello di re-ingegnerizzre e integrare le varie attività di ricerca e creare così un middleware di componenti robuste. I due maggiori progetti che ne tracciano le linee guida sono e sono stati AliEn e LCG (LHC Computing Grid),

16 1.3. SITUAZIONE ATTUALE DELLA GRID 9 entrambi sviluppati presso il CERN come supporto all esperimento LHC. Il lavoro di EGEE ha cercato di riunire le specifiche dell architettura GRID sotto un unico progetto che, basandosi sulle esperienze dei gruppi di ricerca come ALICE (uno dei quattro esperimenti presenti in LHC, CERN) ha dato vita all EGEE Grid Middleware, chiamato glite L architettura di glite glite segue l architettura Service Oriented così da garantire l interoperabilità dei servizi GRID e facilitare il supporto degli standard OGSA (Open Grid Service Architecture), basati sugli stessi principi. L implementazione è quindi basata sulla tecnologia dei Web Services, le cui interfacce sono definite usando il linguaggio WSDL ([6]). Le componenti di glite, come detto sopra, derivano dai progetti già esistenti tra i quali il più influente è LCG, come risulta evidente dalla figura 1.3, che descrive i servizi di glite, ma potrebbe essere usata per descrivere quelli di LCG. I pricipali servizi offerti dal middleware possono essere raggruppati in: Security Service API and Grid Access Service Inormation and Monitoring Services Job Management Service Data Services Security Service È composto dai servizi di autenticazione, autorizzazione e verifica, che provvedono al riconoscimento delle entità (utenti, sistemi e servizi), alla concessione dell accesso alle risorse e la memorizzazione delle informazioni utili per l analisi di sicurezza relative agli eventi (ovvero viene salvata ogni informazione relativa alle azioni eseguite dall utente nel sistema). API and Grid Access Service Forniscono un framework comune per l accesso ai servizi della GRID. L Accesso serve a gestire il ciclo di vita di un servizio generico della GRID, in conseguenza ai diritti concessi all utente che lo sta usando. Ovviamente nonostante nella figura 1.3 siano rappresentati come servizio, le API non lo sono ma servono a tarcciare la modalità per accedervi. Inormation and Monitoring Services È il meccanismo che si propone di recuperare e pubblicare le informazioni relative allo stato delle risorse della Griglia. Per fare un esempio più specifico si può pensare al Job Monitoring Service, che è in grado di rappresentare in tempo reale lo stato di un job e lo stato che raggiunge dopo aver terminato tutte le sue transazioni.

17 10 CAPITOLO 1. GRID Job Management Service Questo servizio (gestione ed esecuzione dei jobs) è delegato ai Computing Element (CE), che relazionano tra di loro attraverso il workload management system (WMS). Esistono due politiche di gestione del WMS: Figura 1.4: Architettura del WMS di glite 1. Push Model: Il WMS decide su quale CE mandare i job in base alle caratteristiche richieste dal job e allo stato delle risorse disponibili su ogni Computing Element. 2. Pull Model: Il CE fa la richiesta al WMS del job specfico e lo preleva direttamente dalla coda. Data Services La gestione e l acesso ai dati è suddivisa tra tre gruppi: Storage Element (SE), Catalog Services e Data Management. La suddivisione delle competenze tra questi gruppi è stata pensata per la gestione dei file, ma è abbastanza generica per essere applicata ad un qualsiasi altro livello dello storage. In un ambiente distribuito si ha la necessità di usare e gestire le repliche, ovvero molteplici istanze dello stesso file su postazioni fisiche differenti così da ottimizzare le prestazioni. Per Gli utenti della GRID un file e tutte le sue copie sono identificate da un logical file name (LFN), memorizzato e raggiungibile grazie al Catalogo delle Repliche (RC). Tutto questo è visto da un utente come un file system globale, dove le repliche ono

18 1.3. SITUAZIONE ATTUALE DELLA GRID 11 voms-proxy-init UI JDL Input sandbox Output sandbox Resource Broker Input sandbox + Broker Info data info SE & CE info Output sandbox Data Catalogs Information Service Author. &Authen. Job Submit Event Logging & Book-keeping Job Query Job Status JDL Globus RSL Job Status Job Submission Service Job Status Publish Storage Element Computing Element Figura 1.5: Visione globale dell architettura di glite completamente trasparenti, infatti queste sono raggiungibili slo se tracciate dal RC e vengono identificate attraverso un Site URLs. All intero della griglia l accesso ai file è permesso solo attraverso gli Storage Element e controllato con le ACL (Access Control Lists) in tipico stile Unix. La semantica di accesso ai file è completamente dipendente dal sistema sottostante e per questo prevede molteplici modalità. Il Data Management è un altro problema non banale della gestione dati. Infatti ogni singolo dato può essere considerato come un job. Pe questo motivo per decidere a chi concedere l accesso ad un determinato dato si ricorre ad un Data Scheduler (DS) e ad un meccanismo che si occupa dei trasferimenti dei file FTL (Fie Transfer Library). Tutto questa strutura permette di ottenere le repliche aggiornate e quindi uno stato consistente di tutto lo storage presente nella GRID.

19 12 CAPITOLO 1. GRID

20 2 Alien, Globus Toolkit, Kerberos e Xen 2.1 Virtualizzazione In quest ultimo anno si è assistito ad un incremento esponenziale dell interesse nei confronti della virtualizzazione, tanto che gli stessi produttori di chip stanno costruendo i loro nuovi prodotti cercando un sempre più completo supporto per la virtualizzazione dell hardware. La Virtualizzazione è la tecnica con la quale risorse hardware come processore, storage, I/O e rete possono essere condivise da più macchine, dette virtuali. Un layer hardware/software permette di simulare o emulare tali risorse abilitando l esecuzione di molteplici ambienti, ognuno dei quali risulta di fatto un sistema completo. Si può dire che la virtualizzazione permette di dividere una macchina fisica in tante piccole macchine con configurazioni, ambienti e sistemi operativi totalmente differenti, creando l illusione di essere in presenza molte macchine. Esistono quattro approcci per virtualizzare un sistema Figura 2.1: Virtualizzaziione che differiscono per il livello a cui si effettua la virtualizzazione:

21 14 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Full System Virtualization: è la tecnica che prevede una totale virtualizzazione a livello hardware, ovvero avere la possibilità di eseguire parte delle istruzioni per l emulazione direttamente sull hardware e parte sul VMM (Virtual Monitor Machine). Il più grande vantaggio di questo approccio è che il sistema operativo ospite e le applicazioni che girano su di esso non necessitano di modifiche. Il problema più grande invece è che al momento questo non è relizzabile, poichè l hardware sul mercato non supporta totalmente il tipo di istruzioni richieste, che con buone probabilità l Intel e AMD includeranno nelle versioni future Figura 2.2: Shared OS Virtualization Para-Virtualization: questa richiede che il sistema operativo sia modificato in modo da trasformare quelle istruzioni che non possono essere virtualizzate completamente. Infatti per ovviare a questo sia il sistema ospitante che quello ospitato devono essere ricompilati in modo da rendere possibile la para-virtualizzazione. Le applicazioni da eseguire in entrambi i sistemi invece non richiedono modifiche. Hosted Virtual Machines: adotta un metodo in cui il VMM e il sistema ospite lavorano direttamente nelle user space della macchina host. Quindi i programmmi dell host e del guest condividono lo stesso user space e le stesse risorse, che sono fornite alla VMM direttamente dalla macchina host. Il vantaggio maggiore è che non è richiesta nessuna modifica al sistema ospite e alle applicazioni da eseguire. Di contro invece questo approccio è caratterizzato da una elevata mole di lavoro a carico dell host, che pregiudica fortemente le performance del sistema. Shared OS Virtualization: prevede la partizione di una macchina in tanti contenitori isolati dove i processi, la memoria e tutti i device condividono solo l immagine del kernel. Ogni contenitore viene chiamato Virtual Private Server.

22 2.1. VIRTUALIZZAZIONE Para-Virtualization La Para Virtualizzazione è la tecnica, come accennato sopra, dove il set di istruzioni hardware che non supportano la virtualizzazione sono modificate. Figura 2.3: Confronto Para-Virtualization & Full System Virtualization Modificare un set di istruzioni significa che le modifiche, relative all istruzioni che fanno riferimento all hardware non virtualizzato nativamente, devono essere portate anche verso il sistema operativo (ovvero il kernel) poichè dovrà far riferimento al nuovo insieme di istruzioni. Nella maggior parte dei casi le applicazioni non richiedono modifiche poichè non fanno uso di istruzioni che modificano i registri interni dell hardware o relative allo stato della macchina. Creando questo set parallelo set di istruzioni, deve essere implementato un hypervisor, che possa ospitare i kernels delle macchine guest. Seguendo questo approccio tutte le modifiche necessarie per la virtualizzazione sono fatte al momento della compilazione e non richiedono nessuna traduzione a run-time, non incidendo così sulle performance che risultano nella maggior parte dei casi simili a quelle di Full System Virtualization. Fare un confronto fra queste due tecniche risulta facile poichè differiscono solo per alcuni driver. L hypervisor, infatti mette a disposizione del sistema ospite solo quelle istruzioni che nativamente non supporterebbero la virtualizzazione, quindi gli scambi di messaggi tra VMM e macchina guest sono ridotti al minimo indispensabile in quanto gli altri driver sono di fatto un canale diretto tra hardware e sistema ospite come avviene in una virtualizzazione nativa. Il più grande svantaggio di questa tecnica risiede nella necessità di modificare il kernel del sistema, cosa che spesso non è possibile per problemi di licenza, come nel caso di Microsoft Windows Xen Xen è un monitor di macchine virtuali Open Source, l hypervisor, rilasciato sotto licenza GPL per piattaforma x86 e compatibili, sviluppato dall Università di Cambridge. La tecnica usata per l emulazione è la para-virtualizzazione. Xen consente una completa emulazione hardware senza andare a ridurre in modo drastico

23 16 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN le risorse del sistema, emulando sistemi operativi diversi tra loro. l accesso verso l hardware passa attraverso l hypervisor, che si occupa anche di fornire l user space necessario per i sistemi ospiti. Gli ospiti necessitano solo di saper interagire con il layer dell hypervisor incaricato di emulare l hardware. Virtualizzazione Linux Day 2005 Architettura di Xen Sempre in continuo sviluppo e sperimentazione, Xen ha tra i suoi finanziatori Xen in pratica nomi del calibro di AMD e Microsoft. Passiamo ora ad analizzare brevemente A colpo d occhio l architettura di Xen. Figura 2.4: Para-virtualizzazione Xen Guido Trotter Virtualizzazione di macchine Linux tramite XEN Architettura Xen: CPU, Memoria e Input Output Attualmente, sia Intel che AMD, hanno sviluppato indipendentemente le estensioni di virtualizzazione dell architettura x86 denominate Intel VT ( Virtualization Technology) e Pacifica (AMD Virtualization). Per assistere la virtualizzazione, VT e Pacifica hanno introdotto un nuovo livello privilegiato al di sotto del ring 0 1. Entrambe le soluzioni hanno aggiunto 9 nuove istruzioni che lavorano solamente nel livello denominato Ring -1, create appositamente per essere usate dall hypervisor. Questo permette di eseguire sistemi guest senza modificarne il sistema operativo e riducendone il costo di emulazione. Ovviamente quest ultimo non è eleminato del tutto in quanto ogni sistema operativo deve essere convinto che da solo ha accesso alla memoria della macchina ed ai bus di I/O, mentre in realtà è sempre l hypervisor che manipola l accesso ai dispositivi reali. La memoria è stata parzialmente virtualizzata a partire dai 386, nel senso che il SO e un controller hardware di memoria, assegnavano la RAM fra le applicazioni. AMD presenta un vantaggio in questo ambito perchè le sue CPU includono il controller di memoria che Pacifica può semplicemente riutilizzare. In contrapposizione, le CPU Intel demandano il controllo di memoria ad un circuito integrato separato che non supporta VT, comportando un maggiore lavoro da parte dell hypervisor nell amministrazione della memoria. Il controller di memoria Intel in futuro sarà introdotto nella CPU e potrà essere in grado di usare VT. Attualmente, la virtualizzazione di I/O richiede dei driver in esecuzione nell hypervisor, che si occupa di presentare i driver virtuali ai sistemi operativi guest. Le 1 da mettere spiegazione

24 2.2. A KERBERIZED CERTIFICATION AUTHORITY 17 future versioni di Pacifica e VT elimineranno i driver dall hypervisor, permettendo ai driver dei sistemi ospite di comunicare direttamente con l hardware. Questo consentirà con ogni probabilità a Xen di passare ad una virtualizzazione completa. Xen in pratica Analizzando Xen dal punto di vista dell utente, possiamo dire che è composto da un Domain-0, che è il primo sistema virtuale ed è anche il sistema dall interno del quale tutte le altre macchine virtuali possono essere gestite. Tale sistema è il primo a fare il boot, inserendosi al livello del kernel direttamente alla partenza del sistema (Xen non è un sistema operativo completo, e non può esistere da solo ). Altri domini possono avere l accesso a parte dell hardware, se specificato nella configurazione. Si possono usare diversi media come backend per i filesystem dei domini: Partizioni fisiche (statiche, veloci) Partizioni su LVM (ridimensionabili, veloci) File su disco (dinamici, allocazione sparsa, lenti, facili da condividere) Una caratteristica molto importante di Xen è la migrazione. Tutti i domini (tranne il Domain-0) possono essere fatti migrare a caldo 2 tra diverse macchine Xen (appartenenti alla stessa regione di broadcast). Per permettere questa feature i filesystem di backend devono essere visibili in partenza da entrambe le macchine. Questa carateristica è estremamente utile per poter fare manutenzione sui server che ospitano le macchine virtuali senza dare disservizio, oppure per bilanciare lõuso delle risorse tra le macchine fisiche o ancora aggiungerne nuove in maniera trasparente. 2.2 A Kerberized Certification Authority Prima di analizzare direttamente l idea e l effetiva ralizzazione di una Certification Authority Kerbeized anilzziamo rapidamente le componenti che devono essere messe insieme per realizzarla: Kerberos e SSL/TLS. Figura 2.5: Logo Kerberos 2 mentre i sistemi sono in esecuzione

25 18 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Kerberos Kerberos è un sistema di autenticazione basato sul protocollo di Needham-Schroeder. L Autenticazione viene raggiunta solo quando una delle due parti può dimostrare all altra di aver scoperto il segreto che hanno in comune. Per rendere l accordo sulle chiavi di complessità qudratica, Kerberos coinvolge, nel processo di autenticazione, una teza parte fidata: il KDC, Key Distribution Center. Ad esempio se Alice è un Kerberos Principal (ovvero un utente di Kerberos), e Bob è un servizio Kerberized entrambe condividono un segreto con KDC. Quando Alice deve effettuare KDC Alice 5 Bob Figura 2.6: Autenticazione Kerberos il login, per usufruire dei servizi di Bob, riceve un TGT (Ticket Garanting Ticket, una chiave di sessione criptata) dal KDC dopo avergli confermato la sua identità comnicadogli la propria password. Con il TGT Alice si può rivolgere ad un TGS (Ticket Garanting Service) e richiedere il Service Ticket per potersi definitivamente autenticare verso Bob, dimostrando al servizio Kerberized che è a conoscenza della chiave di sessione contenuta nel service ticket. ClientHello SSL/TLS ServerHello Certificate CertificateRequest ServerHelloDone SecureCLIENT Socket Layer è un protocollo per la gestione di connessioni sicure, SERVERgaran- tendo l autenticazione ClientKeyExchange delle entità, la confidenzialità e l integrità dei messaggi su Certificate una rete untrusted. CertificateVerify Finished Finished Il protocollo si basa sulla crittografia a chiave pubblica, in particolare fa uso dei certificati per l autenticazione Application Data e una chiave segreta cosí Application da garantire Data confidenzialità e integrità al canale di comunicazione. SSL si compone di due sotto protocolli: SSL record: definisce il formato usato per trasmettere i dati SSL handshake: usa il protocollo SSL record per negoziare un contesto sicuro per la sessione.

26 2.2. A KERBERIZED CERTIFICATION AUTHORITY 19 ClientHello CLIENT Certificate ClientKeyExchange CertificateVerify Finished ServerHello Certificate CertificateRequest ServerHelloDone Finished SERVER Application Data Application Data Figura 2.7: Protocollo di handshake SSL Nella figura 2.7 viene mostrato come interagiscono server e client per negoziare il contesto per la sessione. L autenticazione si basa su una chiave pubblica e un certificato di identita di tipo X509, si nota che SSL supporta la mutua autenticazione. Per prima cosa l utente procede ad autenticare il server, ha infatti la responsabilità di verificare tutte le informazioni, come firma, durata, stato di revoca che sono contenute nel certificato ricevuto dal server. A questo punto l utente invia la propria chiave pubblica al server e per provare che è lui il detentore della chiave privata correlata, invia un messaggio con l hash criptato della firma digitale che entrambe conoscono. Se il server riesce a leggerlo allora la prova è stata supreata e il contesto è stato stabilito. SSL permette anche la rinegozziazzione del contesto dopo un primo handshake, basta infatti che il client ne inizi un altro e la rinegoziazione comincia. Tutto il meccanismo risulta abbastanza pesante dal punto di vista di scambio di messaggi e calcoli crittografici; per semplificare e rendere più veloce la negoziazione di un contesto SSL permette di riusare le sessioni precedentemente usate, ovviamente tutto questo è demandato alla configurazione del server Kerberos Credential Translator per il WEB Lo scopo di questo progetto è implementare un sistema che permetta ad un utente di usufruire di un servizio Kerberized mediante un Web Server con le infrastrutture e politiche di sicurezza esistenti. Lo schema di realizzazione ha seguito le seguenti direttive: Il sistema deve cercare di non modificare i software sottostanti, Web Browser/Server e autenticazione Kerberos, quando possibile Non devono essere aggiunte difficoltà agli amministratori di sistema, poichè comprometterebbero la sicurezza Non devono essere aggiunte difficoltà per l utente, il sistema deve essere facile da usare e non deve richiedere l acquisizione di nuove credenziali Il Web server è vulnerabile quindi deve essere guidato Il sistema deve prevedere un sistema centrale per la gestione delle decisioni sulla poilitca delle azioni del Web Server

27 20 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN e le seguenti assunzioni di sicurezza: Il Web Server ha adeguate misure di sicurezza fisiche Il KDC ha adeguate misure di sicurezza fisiche Tutti gli utenti si fidano di una Certification Authority comune. Ovvero si suppone l esistenza di una Public Key Infrastructure. Il progetto si compone quindi di tre componenti che descrivo di seguito: KCA, KX.509, KCT. KCA & KX.509 Il KX.509 è un meccanismo di autenticazione single-sign-on che permette di ottenere sia le credenziali Kerberos che quelle PK (Public Key). KDC 1 Alice KCA Figura 2.8: Protocollo KX.509 Lo scambio di messaggi e le specifiche del prottocollo sono riportati in figura 2.8. Prima di dare una breve descrizione della dinamica riportata in figura è necessario specificare la natura e i compiti di una KCA. La KCA è un servizio kerberized che dalle informazioni del TGT crea un cetificato X.509, risultando di fatto una CA Kerberized. Rispetto ad una classica CA la KCA non gestisce gli utenti, effettua solo una traduzione correlando credenziali Kerberos con credenziali X.509. Tornando alla figura vediamo come quali siano i passi per ottenere un certificato da un TGT. KX.509: Per prima cosa l utente si autentica su Kerberos (vd ) ottendo un TGT dal KDC. A questo punto per ottenere un certificato del tipo X.509, deve prima chiedere un service ticket e preparare una coppia di chiavi pubblica/privata per poter interagire con la KCA. Quindi procede ad inviare alla KCA il service ticket {User, KCA, K U,KCA } ed un autenticatore{t } KU,KCA. Per essere sicuri di non avere alterazioni nei messaggi, vengono inviati insieme sia la chiave che l HMAC della stessa. Per calcolare l HMAC viene

28 2.2. A KERBERIZED CERTIFICATION AUTHORITY 21 KCT usata la chiave di sessione K U,KCA. La KCA quindi verifica sia il ticket che l autenticatore e genera un certificato X.509 a partire dalle credenziali Kerberos inviandolo all utente che lo aveva richiesto. Per evitare alterazioni, viene aggiunto l HMAC al messaggio di risposta. Le credenziali PK così ottenute hanno una durata pari a quella del TGT Kerberos. Abbiamo visto come la KCA si occupi di tradure le credenziali Kerberos sotto forma di certificato X.509. Analizziamo ora il processo inverso, traduzione da credenziali PK a Kerberos, il KCT. KDC 1 Web Server KCT Figura 2.9: Protocollo KCT Per prima cosa il Web Server che desidera tradurre le credenziali PK deve autenticarsi verso il KDC e presentare un service Ticket verso il KCT accompagnato dal corrispondente autenticatore. Quindi il Web Server fa pervenire l SSL transcript e la chiave di sessione al KCT che dopo averlo autenticato procede con i seguenti passi: Verifica che il transcript SSL sia un handshake valido Valida se i certificati dell utente e del server sono firmati da una KCA fidata Verifica la firma del CLIENT VERIFY, ovvero ricalcola l hash del messaggio di handshake relativo al CLIENT VERIFY e lo confronta con quello dell SSL handshake Web browser kpkcs11 Ticket cache SSL handshake Web server kct_module Verifica che l identita contenuta nel certificato del Server sia tra le identità di Kerberos. Questo ci assicura che il Web Server abbia partecipato kinit kx509 all handshake SSL Token cache Si Assicura che ilkdc transcript KCA sia valido (conrtolla KCT AFStimestemp, lifetime del certificato,ecc...) Genera un service ticket per l utente

29 22 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Cripta la chiave di Sessione e il Service Ticket con la chiave del Web Server Manda al Server il ticket, l autenticatore e la chiave di sessione Scrive traccia di queste operazioni sul file di log Dalle operazioni che deve eseguire un KCT risulta evidente che accedendo al databse del KDC deve godere delle stesse misure (fisiche) di sicurezza. In pratica è altamente consigliabile che i due, KCT e KDC risiedano sulla stessa macchina. 2.3 Globus Toolkit Il Globus Toolkit è un programma nato grazie alla collaborazione tra l Argonne National Laboratory, l Information Sciences Institute dell Università della Californa del Sud, le Università di Chicago e di Edinburgo e lo svedese Center for Parallel Compueters, che rappresenta lo standard de facto, come lo ha definito il New York Times, per l implementazione del Middleware Grid. Implemeta tutti i servizi necessari per un infrastruttura GRID dettati dalle direttive dell OGSA(Open Grid Services Architecture) risultando così la piattaforma pii usata dai progetti scientifici Grid- Oriented. Questo progetto è nato nel 1997 ed è attualmente alla quarta versione. Prima di analizzare la struttura e i servizi rilasciati dal GT4 è essenziale conoscere tre acronimi che costituiscono le basi su cui è stato costruito: OGSA, WS e WSRF OGSA-WS-WSRF OGSA e WSRF sono i concetti chiave su cui nasce e si sviluppa Globus. OGSA è il progetto, del Global Grid Forum (http://www.ggf.org), che cerca di definire una linea guida per lo sviluppo di applicazioni GRID. Questo in pratica consiste Figura 2.10: Collaborazione OGSA-WSRF nella trovare uno standard accettato dalla comunità mondiale che definisca le interfacce dei servizi tipici di questa architettura (job management services, resource

30 2.3. GLOBUS TOOLKIT 23 management services, security services, ecc.). Il primo importante passo affrontato da OGSA risiede nella scelta di un middleware distribuito su cui sviluppare tutta l infrastruttura, ovvero creare un ambiente per i servizi che permetta di specificare metodi universali per invocarli. Le opzioni prese in considerazione sono state molteplici, CORBA, RMI, o le tradizionali RPC ma alla fine i Web Services sono risultati quelli più idonei e affini alle specifiche dettate da OGSA, nonostante una loro grave mancaza: la caratteristica di essere stateless. Per rendere i WS completamente compatibili è stato inserito il WSRF (Web Services Resource Framework, svilupato da OASIS 3 ), che si occupa di rendere possibilie il binomio Web Services-Grid. Specifica come sia possibile realizzare WS stateful (fig. 2.10), infatti possiamo dire che se OGSA è l architettura, WSRF è l infrastruttura su cui viene realizzata. Web Services I Web Services sono, come detto sopra, un altro middleware per sviluppare applicazioni in ambienti distribuiti di tipo Client/Server. Come suggerisce il nome è una tecnologia Web che a differenza dei siti web non ha nessuna relazione con i Browser e l HTML, infatti si può dire che i siti web interagiscono con le persone, mentre i Web Services solamente con i software, esattamente come CORBA e gli altri middleware distribuiti. I WS rispetto alle altre tecnologie affini presentano dei vantaggi notevoli: Sono indipendenti dalla piattaforma e dal linguaggio (sfruttano le peculiarità del linguaggio XML). Ad esempio il client può essere scritto in C++ ed essere eseguito su un terminale Ms Windows, mentre il server sviluppato in Java è in esecuzione su un sitema Linux. Il canale di comunicazione dei WS è l HTTP; questo deve essere considerato un vantaggio perchè è uno dei pochi se non l unico canale che di default non è soggetto a particolari attenzioni da parte dei firewall. e ovviamente alcuni svantaggi: Overhead. Trasettere tutti i dati via XML non è efficiente come sfruttare i prorietary binary, infatti quello che si guadagna in portabilità viene perso in efficenza, infatti non troveremo mai applicazioni Critical Real-Time sviluppate con i Web Services. Di contro è vero che di solito il carico di lavoro che un ambiente Grid sviluppa risulta accettabile, e l aspetto della portabilità prevale. Mancanza di versatilità. Infatti tendono a fornire solamente i servizi base di cui un architettura ha bisogno, mentre ambienti come Corba mettono a disposizione dell utente numerose tipologie di servizi: persistency, notification, life cycle management, transaction, ecc. Comunque grazie a specifiche come il WSRF i Web Services stanno acquisendo una sempre più completa versatilità. 3

31 24 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Considerando vantaggi e svantaggi e che a differenza di Corba e le altre tecnologie i WS sono loosely coupled systems, ovvero non richiedono sistemi simili per buone prestazioni, risultano essere i candidati migliori per l architettura OGSA. Architettura dei Web Services Prima di esaminare come si richiedono i servizi verso un WS è sicuramente opportuno delineare l architettura dei Web Services. Come si vede dalla figura 2.11 Figura 2.11: Architettura dei Web Services l architetura dei WS è costituita da quattro livelli: - Service Processes Non è relativo ad un solo WS, infatti é il livello coinvolto nel discovery service, che vedremo successivamente quando descriveremo il funzionamento di un Web Service. - Service Description Una delle capacità più interessanti dei WS è il self-describing. Quindi una volta scoperto dove si trova il servizio, grazie al livello precedente, è possibile chiedergli informazioni sulle operazioni supportate e su come richiamarlo. Questo avviene con lo scambio di messagi scritti in WSDL (Web Services Description Language), linguaggio specifico per la descrizione di un WS. - Service Invocation Richiamare un Web Service richiede lo scambio di alcuni messaggi tra Client e Server secondo un protocollo ben preciso, SOAP (Simple Object Access Protocol), che regola sia il formato delle richieste che quello delle risposte. Ovviamente SOAP non è l unica soluzione, un alternativa potrebbe essere XML-RPC, ma è sicuramente la più usata. - Transport Infine abbiamo la gestione della trasmissione dei messaggi SOAP tra Client e Server. Ci sarebbero vari protocolli per gestire la trasmissione ma il più usato è l HTTP (HyperText Transfer Protocol), lo stesso usato per accedere alle pagine Web. Tipica chiamata di Web Services Per decrivere le fasi di interazione di un applicazione Client/Server basata sui Web Services è necessario introdurre due concetti fondamentali Client Stub e Server Stub.

32 2.3. GLOBUS TOOLKIT 25 Figura 2.12: WSDL Stubs Gli stubs sono porzioni di software delegate dal Client/Server per la creazione e la trasmissione dei messaggi. Esistono numerosi tools che generano automaticamente gli stubs necessari per la creazione e traduzione dei messaggi SOAP. Questa operazione segue le direttive del WSDL descriptor, che permette ai WS di astrarre dal linguaggio del server in quanto adotta uno standard accettato da tutti per la definizione dei parametri caratterizzanti della chiamata. Facendo riferimento alla figura 2.13 vediamo in dettaglio cosa succede quando viene invocato un Web Service: 1. Quando il client vuole richiamare i servizi di un WS, in realtà invia la propria richiesta verso il Client Stub. Questo risponde inserendo il messaggio in un adeguata richiesta SOAP. Questa operazione viene spesso definita processo di marshaling or serializing. 2. La richiesta SOAP viene inviata tramite il protocolo HTTP ed Internet. Il Server riceve il messaggio SOAP e passandolo al Server Stub riesce a tradurre il messaggio in qualcosa che il servizio è in grado di interpretare, comunemente chiamata operazione di unmarshaling or deserializing. 3. Il Server Stub quindi procede ad inoltrare la richiesta verso l implementazione del servizio che la processa secondo le direttive ricevute. Figura 2.13: Interazione Client/Server di un Web Service 4. Il risultato ottenuto passa quindi dal Server Stub che lo include in una SOAP response. 5. Questo messaggio viene quindi inviato tramite il protocolo HTTP ed Internet verso il client. Il Client Stub qundi traduce il messaggio SOAP in modo da renderlo leggibile. 6. Infine il client accede al risultato ricevuto in seguito alla sua richiesta e ne fa l uso per cui lo a richiesto.

33 26 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Quelli appena descritti sono i passi che rappresentano il fulcro di una richiesta SOAP per invocare un Web Service, dopo che il servizio richiesto è stato localizzato. Server Side di un Web Service Rimane un ultimo aspetto interessante da analizzare relativa ai Web Services: la struttura del Server. Figura 2.14: Server Side di un applicazione Web Service Osservando la figura 2.14 risulta chiaro che il server è composto da quattro livelli: Web Service: Come prima cosa ci sono i Web services, porzioni di software che offrono la possibilità di effettuare determinate operazioni. Ad esempio un implementazione in C++ di alcuni metodi (operazioni). Come abbiamo detto in precedenza il WS non necessità di conoscere come leggere o scrivere messaggi SOAP. SOAP Engine : Si occupa di gestire messaggi (richieste e risposte) SOAP. Spesso non si ricorre ai Server Stub per ogni singolo WS ma si usa un generico SOAP engine, come Apache Axis, come nel Globus Toolkit. Questo livello si occupa solamente di manipolare SOAP, infatti la parte che effettivamente esplica le funzionalità di server è demandata agli altri livelli. Application server: Questo livello si occupa di fornire un living space per le applicazioni che devono essere raggiunte da client diversi. Solitamente il SOAP engine è un applicazione di un application server. Nel nostro esempio Axis è il SOAP engine e il suo application server è Jakarta Tomcat. HTTP Server: Spesso l Application Server esercita anche le funzionalità di server HTTP, altrimenti viene inserito un altro software che si occupa di gestire i messaggi HTTP, come ad esempio un Apache Server, comunemente definito Web Server GT4 Il Globus Toolkit vesione 4 è un insieme di componenti software pensate per creare un sistema distribuito, dove ambienti diversi interagiscono scambiandosi messaggi

34 XX GLOBUS Ninf-G: Remote Procedure Call on the Grid 2.3. TOOLKIT 27 XX. in una rete. Per essere più precisi dobbiamo specificare che il GT4 è un insieme di 4.7 Services Case Studies Web che creano la base di un sistema distribuito veramente eterogeneo. How dare many?un What? attached Per ideahere di or quale sia to laearlier vera sections? natura del GT4, descriverò le componenti essenziali su cui si sviluppano tutti i servizi di Globus: GRAM ( Grid Resource Execution Management Case Study 1 Allocation and Management), MDS ( Meta Directory Service), GSI ( Grid Security XX Infrastructure) Execution Management Case Study 2 XX GRAM Il Grid Resource Allocation and Management è il servizio che rende possibile la 4.8 How GRAM Worksdi job allocando una risorsa computazionale remota. sottomissione e il controllo We review the GRAM information should be interest as l accesso Grazie allebriefly peculiarità deiimplementation. Web services,this GRAM è in grado di of permettere background to the discussion of GRAM configuration ( 4.5) and also to users wantreliability. some alle risorse di un sistema distribuito eterogeneo garantendo una who buona insight into how GRAM works and to developers as an example of a WSRF/WSN-based service. Job tions func Delegate GT4 Java Container GRAM GRAM services services Delegation Transfer request RFT File Transfer Compute element Local job control De l e gate sudo Client Service host(s) and compute element(s) GRAM adapter GridFTP FTP control Local scheduler User job FTP data GridFTP Remote storage element(s) Figure 10: GRAM implementation structure Figura 2.15: Implementazione della struttura di GRAM As illustrated in Figure 10, the primary elements of a GRAM deployment are as follows:! A set of services running in a GT4 Java container, as follows: La procedura che un utente deve seguire per sottomettre un job consiste in due o GRAM-specific services for creating, monitoring, and managing jobs soli passaggi: o A general-purpose delegation service, used to manage delegated credentials editare un file xml, come nell esempio 2.1, dove descrivere il job e le sue dipendenze (sistema operativo, librerie, ecc...) eseguire il comando globusrun-ws < f ilexml > Draft of 5/8/2005 A questo punto GRAM prende in gestione il lavoro e seguendo le specifiche descritte nel file esamina le code dei sistemi batch degli host a disposizione del sistema e seleziona quello più idoneo all esecuzione. Procede quindi ad allocare la risorsa prescelta lasciando così la gestione relativa all esecuzione al sistema locale, rilasciando all utente l handle, che gli permetterà di seguire il processo nel sistema. Nel GT4 a conferma di una sempre maggior compatibilità verso tutti i sistemi sono supportati come cluster management system: Condor, PBS, LSF e SGE (Sun Grid Engine, uno degli ultimi sistemi batch messi a disposizione da Sun). Comment [ ITF30] : Wha authorization callouts?

35 28 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Listato 2.1: Esempio di uno script GRAM relativo ad un job 1 <? xml version =" 1.0 " encoding ="UTF -8"?> 2 < multijob 3 xmlns:gram =" http: // www. globus. org / namespaces /2004/10/ gram / job " 4 xmlns:wsa =" http: // schemas. xmlsoap. org /ws /2004/03/ addressing "> 5 < factoryendpoint > 6 < wsa:address > 7 https: // resource - manager -0. globus. org:8443 / 8 wsrf / services / ManagedJobFactoryService 9 </ wsa:address > 10 < wsa:referenceproperties > 11 < gram: ResourceID > Multi </ gram: ResourceID > </ wsa:referenceproperties > 14 < wsa:referenceparameters /> 15 </ factoryendpoint > <job > 18 < factoryendpoint > 19 < wsa:address > 20 https: // resource - manager -1. globus. org:8443 / 21 wsrf / services / ManagedJobFactoryService 22 </ wsa: Address > 23 < wsa:referenceproperties > 24 < gram: ResourceID > Fork </ gram: ResourceID > 25 </ wsa:referenceproperties > 26 < wsa:referenceparameters /> 27 </ factoryendpoint > < executable >/ bin / echo </ executable > 30 < argument >Hello,</ argument > 31 < argument >Grid </ argument > 32 < argument >From </ argument > 33 < argument >Subjob </ argument > 34 < argument >1</ argument > 35 <count >1</ count > 36 </ job > <job > 39 < factoryendpoint > 40 < wsa:address > 41 https: // resource - manager -2. globus. org:8443 / wsrf / services / 42 ManagedJobFactoryService 43 </ wsa: Address > 44 < wsa:referenceproperties > 45 < gram: ResourceID > Fork </ gram: ResourceID > </ wsa:referenceproperties > 48 < wsa:referenceparameters /> 49 </ factoryendpoint > < executable >mpi - hello </ executable > 52 < argument >Hello,</ argument > 53 < argument >Grid </ argument > 54 < argument >From </ argument > 55 < argument >Subjob </ argument >

36 State Description Unsubmitted Job has not yet been submitted GLOBUS TOOLKIT StageIn Job is waiting for stage in of executable or input files to complete. Pending 29 Comment [ IT meaning of un The local scheduler has not yet scheduled the job for execution. < argument >2 </ argument > 57 < count >2Job </ count > Active is executing. 58 < jobtype > mpi </ jobtype > Suspended Job execution has been suspended. 59 </ job > 60 </ multijob > 56 StageOut Job execution has completed; output files are being staged out. CleanUp DoneMDS Job execution and stage out have completed; clean up tasks are underway. Job has completed successfully. Il Meta Directory Service ha il compito di reperire dinamicamente informazioni Failed Job failed. sulle risorse disponibili e sui loro cambiamenti di stato. Questo permette infatti Comment [ IT job be terminate status? Failed? Killed status? Suspended Unsubmitted Active Pending Done StageOut StageIn Failed CleanUp Figure 8: State transition diagram for GRAM jobs. Figura 2.16: Diagramma degli stati di un job in Globus File Staging and Other Features altri sevizi di has conoscere lo stato dellocated sitemaondistribuito. Le due In allagli examples so far, di theglobus executable been assumed to be the target computer, principali di MDS inputfunzionalità data is passed as arguments, and sono: output data has been written to files on the target computer. However, there will also be cases in which the executable or other files need to be staged in to the targetdiscovery: computer and/or output mustidonea be staged We specify file staging task by adding file trovare la files risorsa per out. eseguire un determinato transfer directives to the job description. These directives follow the RFT syntax, which enables third-party transfers. Each file transfer therefore a source URL and Monitoring: è il processo chemust si occupa dispecify osservare le risorse e/o ai destination servizi per permettere la soluzione di problemi e eseguire il tracking di un task Draft of 5/8/2005 Per garantire queste funzionalità MDS fornisce un aggregator services che raccoglie le informazioni sullo stato attuale delle risorse e fornisce un interfaccia, come un browser o la linea di comando stessa, che permette all utente di visionare le informazioni raccolte. Il Meta Directory Service nella versione 4 a differenza delle precedenti, fa uso dei WS per fornire i servizi e del formato XML per lo storage dei dati, facilitando così la ricerca dei dati con l uso di Xpath, un esempio chiaro è la ricerca di una entry in un albero LDAP. Gli aggregator services che MDS4 mette a disposizione sono tre: 1. MDS-Index: Permette di effettuare richieste Xpath su gli ultimi valori ottenuti dalle fonti di informazioni 2. MDS-Trigger: Si occupa di effettuare alcune azioni, come mandare una mail o scrivere un file di log, quando le informazioni raccolte coincidono con i criteri specificati dall utente Comment [ IT e.g., additional

37 30 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN 3. MDS-Archiver: Salva tutte le informazioni del sistema su di una base di dati permettendo così agli utenti di ricostruire uno storico con delle semplici richieste verso una base di dati. GSI La Grid Security Infrastructure provvede a gestire e garntire le condizioni di sicurezza nella comunicazione interna di una rete Grid. Implementa i servizi necessari per gestire le caratteristiche del livello connectivity descritto nella sezione del secondo capitolo. I componenti relativi alla sicurezza si occupano quindi di stabilire l identità di un utente o un servizio, Autenticazione, e proteggere le comunicazioni e determinare chi è abilitato a fare cosa, Autorizzazione. Entrambe le funzionalià sono implementate sulla base dei certificati X.509 ed il protocollo di comunicazione SSL (Secure Sockets Layer 4 ). Parlando specificatamente di GSI relativa al Globus Toolkit 4 si deve specificare che i WS security sono sviluppati su tre meccanismi: 1. Message Level: dove sono implementati gli standard WS-Security e WS-SecureConversation che garantiscono la protezione del messaggio durante lo scambio delle richiste SOAP di GT4 2. Transport Level: delega tutte le sue funzioni al TLS (Transport-Layer-Security) 3. Authorization Framework: permette di usare vari schemi di autorizzazione, come il grid-mapfile per il controllo degli accessi, con il solo vincolo che rispettino lo standard X.509 e che si scambino le informazioni relative alle autorizazioni secondo il protocollo SAML. Infine altri due importanti compiti di GSI sono la Delegation e la propagazione delle credenziali X.509. La propagazione è svolta da MyProxy che provvede a distribuire le credenziali, dell entita autenticata, verso tutti i servizi a cui ha diritto. La Delegation invece prevede un meccanismo di mapping che permette di demandare a sistemi alternativi l autenticazione sempre con l importante vincolo dello standard X Secure Sockets Layer è un protocollo di comunicazione che garantisce gli standard di sicurezza richiesti in Grid basato sulla crittografia a chiave asimmetrica vd. sezione 2.2.2

38 2.4. ALIEN AliEn AliEn (Alice Environment) è un ambiente di calcolo distribuito sviluppato da Alice Offline Project per offrire a tutti i membri dell esperimento un accesso trasparente alle risorse, sia di calcolo che di storage, indipendentemente dalla loro locazione fisica. Quest ambiente è stato sviluppato per affiancare le fasi di sviluppo di uno degli esperimenti di LHC, ALICE. Infatti AliEn affianca i membri dell esperimento mettendo a disposizione degli utenti una piattaforma di lavoro capace di sostenere gli sviluppi futuri del calcolo distribuito, seguendo il paradigma del GRID Computing. Figura 2.17: Componenti di ALiEn Alien è frutto dell unione di un gran numero di programmi OpenSource di cui sono state sfruttate le peculiarità senza modificarne il codice. Questo ha permesso un rapido sviluppo delle nuove versioni del software. Attualmente è usato da Alice per il calcolo distribuito dei dati, per il rilievo e la ricostruzione delle simulazioni del metodo di Monte-Carlo. La struttura di AliEn è composta di un insieme di circa trenta siti distribuiti sui quattro continenti. Un punto di forza di questo progetto del Cern è l estrema semplicità del sistema di installazione (un installer reperibile su ) che con un semplice script (alien-installer)permette di installare le componenti richieste e le loro dipendeze senza alcun intervento da parte dell utente. Al termine dell installazione si ottiene la configurazione di una nuova Virtual Organization, composta dai Web Services che collaborano e costituiscono l Alien Grid. Le prerogative su cui è nato e cresciuto Alien rispetto al sitema sottostante sono state: risultare più indipendente possibile essere flessibile avere una semplice procedura di installazione su sistemi di calcolo di grandi dimnsioni

39 32 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Queste tre caratteristiche assieme al fatto che sia completamente compatibile con la GRID del Cern (LCG) secondo i parametri dettati dal consorzio Europeo EGEE, hanno fatto si che AliEn abbia avuto un ottima diffusione nella comunità scientifica L Architettura di Alien La struttura (fig.2.18) è sostanzialmente suddivisa in tre gruppi: Software esterno Servizi e CORE di Alien Interfacca (Software ad alto livello) Software Esterno Questo livello è coposto da quattro software principali, rigorosamente Open Source: Un RDBMS (MySql) e Core e Moduli Perl: La ragione per cui Alice Offline ha scelto lo scripting language Perl è essenzialmente dovuta alla sua preponderante presenza nel Software libero in tema di algoritmi di crittografia, compatibili con la piattaforma clietn/server di SOAP e facilmente integrabili con il Web. In particolare questo linguaggio offre un modulo di accesso ai Database molto flessibile, perfetto per l implementazione di una Database Interface (DBI) dove il driver del DB è selezionao a run time. Figura 2.18: Architettura di ALiEn LDAP (Lightweight Directory Access Protocol): È un database gerarchico utilizzato per salvare tutte le informazioni relative alle singole Virtual Organizations che compongono l AliEn Grid. Le informazioni contenute nel DB sono principalmente riferite a Persone, Ruoli,

40 2.4. ALIEN 33 Pacchetti, Siti e tutte le informazioni che caratterizzano la VO rispetto alla Griglia. Ad esempio nei file di configurazione di una VO non si specifica che codice venga sviluppato in un detrminato sito poichè questo tipo di informazioni vengono ricavate estraendole dall albero LDAP dinamicamente. VO Pakages & Command: Ogni singola VO è tenuta a fornire informazioni riguardo al software installato e ai comandi che gli utenti della Grid possono eseguire attraverso lo specifico sito. Queste specifiche sono mantenute dall AliEn Pakage Manager, che si occupa inoltre di tenere aggiornate tutte le possibili dipendenze che un comando può avere rispetto a determinati pacchetti. Seguendo questo schema si riesce a mantenere una buona consistenza del softwre prodotto dalle VO che appartengono ad una stessa Griglia. Servizi e Core di AliEn Il Core di Alien è composto da: Database Interface: L elemento principale di AliEn può essere considerato un database relazionale o una federazione di database relaionali, anche eterogenea. In realtà tutto viene memorizzato su MySql. Per permettere ai client di non essere obbligati ad usare un unico driver per la connessione, le richieste verso il Db passano da un Proxy Service. Questo significa che le applicazioni hanno a disposizione un driver particolare AlienProxy, che permette l installazione del driver specifico solo sulla macchina che ospita il servizio di Proxy. File Catalogue: Questa è stata la prima componente realizzata ed il primo successo raggiunto. Si propone di essere la naturale estensione di un file system con l importante carateristica di non trattare mai fisicamente i files. Infatti il file catalogue si occupa solamene di mantenere un associazione tra Logical File Name (LFN) e Physical File Name (PFN) e informazioni utili su i jobs in esecuzione, simulando una /proc analoga alla directory dei sistemi Linux. Metadata Catalogue: Per semplificare l accesso alla gerarchia del File Catalogue, è stata affiancata una nuova tabella che contiene tutte le entità archiviate ( files, directory e sotto directory). A questa vengono associate altre tabelle che riflettono i diritti di accesso e i metadata, cosi da semplifcare sia la ricerca dei files che la negoziazione per accedervi. Configuration Manager: È il responsabile delle interazioni con l LDAP server. Seleziona ed estrae tutte le informazioni che caratterizzano la VO rispetto al contesto e le memorizza in una cache. Questo ottimizza le frequenti consultazioni verso LDAP. Pakage Manager: Come detto precedentemente provvede a tenere aggiornati i pacchetti e i

41 34 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN Figura 2.19: File Catalogue di ALiEn comandi che possono essere eseguiti su una VO. Questo implica che, al momento in cui la politica di una VO decide di accettare una tipologia di job, il Pakage Manager si occupa di installarvi tutti i pacchetti per le dipendenze (di librerie) di cui quel nuovo comando ha bisogno. In correlaziione al Core di AliEn i servizi hanno un ruolo centrale nel rendere AliEn un ambiente di calcolo distribuito. I servizi possono essere raggruppati in quattro sezioni principali: Figura 2.20: Autenticazione di ALiEn Autenticazione: Questa si occupa di verificare le credenziali dell utente usando il protocollo SASL, sul quale sono implementati diversi meccanismi (GSSAPI tramite Globus/GSI, AFS password, SSH key, certificati X.509 e AliEn tokens). In seguito al successo dell autenticazione il Proxy Service provvede ad abilitare l utente per l accesso alle risorse a cui a diritto, per un periodo limitato di tempo. Resource Broker: È il servizio che gestisce la coda dei jobs di AliEn, che sono descritti seguendo

42 2.4. ALIEN 35 le specifiche JDL (Job Description Language) di Condor ClassAds. Il Broker analizza le necessità dei lavori sottomessi (file di input, output,...) e se necessario modifica il JDL per definire esattamente la locazione dei file, comprese le eventuali repliche, necessarie per l esecuzione. A questo punto il Broker si occupa di mandare in esecuzione i job in uno dei siti che risulta idoneo alle specifiche JDL. Per effettuare quest operazione esistono, come detto in precedenza per glite, due modelli di funzionamento possibili il push e il pull. Figura 2.21: Pull Model di ALiEn AliEn adotta il Pull Model (fig.2.21), che permette al Broker di non conoscere lo stato del sistema demandandolo ai suoi Computing Element, che gli devono comunicare lo stato in cui si trovano. A questo punto il Broker provvede a distribuire i jobs sulle risorse disponibili, permettendo una buona flessibilità del sistema, che risulta avere una buona tolleranza ai guasti. Il meccanismo gestito dal Resource Broker coinvolge tre entità fondamentali di una VO: Computing Element, Storage Element e File Transfer. Il primo, come accennato poco sopra, agisce da interfaccia per il sistema batch locale, ovvero dialoga con il CPU Server (dove risiede il Broker) e una volta prelevati i JDL dei job, li traduce per il sistema batch locale (PBS, SGE, LSF, ecc...). Lo Storage Element si occupa invece della gestione dei file e della cache temporanea, appoggiandosi al File Transfer. Questo usa l FTD (File Transfer Daemon), e permette di spostare i files necessari per l esecuzione da e verso il Computing Element che ha preso in gestione il job (tutte le operazioni sono autenticate). Monitorizzazione: Questo Servizio è fornito dal Software MonaLisa, che raccoglie tutte le informazioni relative allo stato della griglia e le visualizza su pagine Web. Questo permette grazie ad una visione globale delle prestazioni di poter raggiungere un ottimizzazione e comprendere le reali Performance del sistema. Logger: È il meccanismo che riporta lo stato, compresa la condizione di errore, di tutti

43 36 CAPITOLO 2. ALIEN, GLOBUS TOOLKIT, KERBEROS E XEN ALICE Grid Monitoring with MonALISA - World map 27/05/ :27 PM MonALISA Repository for ALICE Repository Home Administration Section ALICE Reports Events XML Feed Firefox Toolbar MonaLisa GUI ALICE Repository ALICE Repository Google Map MonALISA Map Running trend Job Information SE Information Services Network Traffic FTD Transfers CAF Monitoring SHUTTLE LCG exp. monitoring Build system close all Current page Running jobs trend Running jobs trend 24h 12h 6h 1h (click arrows for detailed view) Running Jobs Zombie Jobs No Active Jobs ML Service Down Show xrootd transfers Show site relations Actions: Left Click - Zoom In Right Click - Zoom Out (Center on the mouse position) Zoom / Translation Factor: Image size: Adaptive Select Predefined Map: Europe Repository Home ALICE Web Page ALICE Clusters Contact CERN Copyright ALICE EXPERIMENT Figura 2.22: MonALISA Sistema di Monitoring di ALiEn i servizi. Questo permette al Grid Manager di monitorare tutte le eccezioni e correggerle dove possibile. Interfaccia (Software ad alto livello) Dopo aver descritto le componenti principali che costituiscono AliEn, l ultimo aspetto da analizzare sono le interfacce a disposizione dell utente per interagire con la GRID. Ad esempio il File Catalogue mette a disposizione sia una linea di comando che una maschera grafica per accedervi, sottomettere job e recuperare Pagina 1 di 1 i risultati. Un ulteriore modalità di accesso si ha attraverso il Portale Web, dal quale si può, oltre alle opzioni precedenti, accedere al pannello di controllo per amministrare e monitorare i servizi di una VO. Un alra importante via di accesso ai servizi della GRID è rappresentata dalle C/C++ API, che permettono l accesso a livello applicativo. In particolare quelle relative al C++ sono usate per facilitare l accesso al file system creato sulla base dell AliEn File Catalogue. Alienfs è stato implementato seguendo lo schema di LUFS (Linux Userland File System) (fig.??). Un utente unix deve solo fare un mount e un autenticazione alla GRID per poterlo usare come un file sytem locale. Ovviamente questo servizio, come tutti i servizi della GRID, sono e rimangono attivi previa autenticazione dell utente.

44 3 Installazione Procediamo adesso a descrivere i passi effettuati per preparare l ambiente per la realizzazione di un architettura GRID presso il dipartimento di Matematica U.Dini di Firenze. Il progetto prevede in una prima fase la sola installazione di più istanze del Globus Toolkit 4 (GT4) per studiarne il sistema di autenticazione e sperimentare una soluzione alternativa: Sostitire il sistema di autenticazione basato sulle Certification Authority con un sistema di autenticazione realizzato con Kerberos e il protocollo X.509. La fase successiva è composta dall installazione e configurazione di un ambiente GRID reale e funzionante: AliEn al quale sia possibile prospettare questo tipo di modifica. Il progetto prevede l installazione dei software tipici di un sistema GRID standard: un file system distribuito (AFS) un sistema di autenticazione Kerberos più istanze del Globus Toolkit 4 e di alcuni servizi che esulano dallo standard GRID e costituiscono pertanto la base dei test di questa tesi: un sistema batch SGE una certification authority basata su Kerberos un sistema di macchine virtualizzate con Xen

45 38 CAPITOLO 3. INSTALLAZIONE Per l installazione di queste componenti è stato necessario comporre un insieme di macchine dedicate, di cui è stato possibile ridimensionare il numero fisico grazie alla virtualizzazione Xen. L hardware messo gentilmente a disposizione dal dipartimento di Matematica si compone di quattro elementi tra cui due Dual Xeon, un Opetron e un Pentium III. Su queste macchine è stato installato il sistema di virtualizzazione Xen, dal quale originano quattro elementi: olmio.math.unifi.it, disprosio.math.unifi.it, itterbio.math.unifi.it e terbio.math.unifi.it. L Opteron, tulio.math.unifi.it, è stato utilizzato come macchina di servizio per l autenticazione e lo storage distribuito (KDC e AFS). Il Pentum III, erbio.math.unifi.it ospita un WN (Worker Node) di AliEn, ma principalmente è stato usato per le operazioni di test tra KCA e Globus. Figura 3.1: Sala Macchine Dipartimento di Matematica U. Dini Il sistema di virtualizzazione Xen ci ha permesso di provare installazioni di sistemi diversi osservandone le prestazioni mentre erano in esecuzione contemporaneamente, oltre che di ridurre il numero fisico di macchine (non decisivo in questo caso dove era comunque accettabile). Questo ha facilitato i confronti e quindi le considerazioni che hanno guidato le scelte. La prima operazione è stata la scelta del sistema Linux da installare: Scientific Linux Cern 4 (SLC4 ) o Debian Etch. La prima risultava idonea soprattutto perchè sviluppata dal CERN e quindi con le configurazioni base ideate per le necessità di un sistema GRID; ovvero i servizi che il centro di ricerca europeo fornisce ai suoi ricercatori, tra i quali il file system

46 3.1. INSTALLAZIONE DI XEN 39 Figura 3.2: terbio.math.unifi.it, olmio.math.unifi.it e itterbio.math.unifi.it distribuito AFS e Kerbros V. Debian è stata reputata una valida alternativa in quanto permetteva di testare la compatibilità della GRID con sistemi diversi da SLC4 e soprattutto perchè compatibile con le versioni più recenti di AFS, Kerberos, Xen che, come da tradizione Debian, sono in continuo e rapido aggiornamento. Dopo aver effettuato prove di installazioni su entrambe i sistemi, è stato scelto di installare Debian Etch, in quanto presentava meno problematiche per il mantenimento di uno stato consistente del sistema di virtualizzazione Xen. Andiamo ora a descrivere singolarmente l istallazione di ogni servizio. 3.1 Installazione di Xen L installazione del sistema di virtualizzazione Xen, vista l attuale simpatia che il mondo informatico gli riserva, è risultata più semplice del previsto. Il mondo Debian, come sua regola, anche a distanza di poche settimane ha fornito aggiornamenti migliorando così la stabilità e fornendo la possibilità di una gestione semplice e efficace delle macchine virtuali. Le macchine su cui è stato installato Xen 3.0 hanno le seguenti caratteristiche: gadolinio:~# uname -a Linux gadolinio xen-686 #1 SMP Thu May 10 03:24:35 UTC 2007 i686 gadolinio:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 1.60GHz stepping : 6 cpu MHz :

47 40 CAPITOLO 3. INSTALLAZIONE Figura 3.3: erbio.math.unifi.it e tulio.math.unifi.it cache size : 4096 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm bogomips : Per prima cosa è stato installato il sistema Linux Debian Etch classico senza componenti grafiche come Xorg o XFree86, in modo da non appesantire il carico delle macchine e limitare i problemi legati alla sicurezza che le interfacce grafiche sono solite portare. Una volta che Debian è stata installata e configurata, appoggiandosi al suo sistema di gestione dei,apt, si procede a installare: apt-get install xen-linux-system xen-68 apt-get install libc6-xen apt-get install bridge-utils xen-tool per ottenere un sistema di virtualizzazione. Per renderlo definitivamente attivo si deve controllare che il sistema di boot, ad esempio GRUB contenga la seguente sezione

48 3.1. INSTALLAZIONE DI XEN 41 title root kernel module module Xen Debian GNU/Linux, kernel xen-686 (hd0,1) /boot/xen i386-pae.gz dom0_mem=128m /boot/vmlinuz xen-686 root=/dev/md0 ro console=tty0 /boot/initrd.img xen-686 e quindi si avvia la macchina fisica con il kernel contenente la patch di Xen, le cui funzioni sono state descritte in 2.1. Dopo il reboot del dom0, macchina fisica, è attivo il demone xend che fornisce un tool per monitorare le macchine virtuali. Per installare una macchina virtuale è necessario per prima cosa modificare il file di configurazione per abilitare il colegamento delle interfacce di rete virtuali alla corrispettiva fisica così da consentire ai domu, le istanze virtuali, l accesso alla rete come se fossero vere e propri computer indipendenti. A questo punto si prepara lo spazio fisico, un LVM, una partizione o un file immagine, dove si vuole installare il domue si procede creare un istanza virtualizzata di un altro sistema Debian con il comando: xen-create-image hostname disprosio.math.unifi.it -debootstrap ip= Al termine non si ha ancora una macchina virtuale, ma solo un istallazione Etch su uno spazio fisico; per poterla eseguire come domu si deve editare un file di configurazione specificando alcuni parametri in file di configurazione come nell esempio che segue: # Kernel + memory size kernel = /boot/vmlinuz xen-686 ramdisk = /boot/initrd.img xen-686 memory = 512 # Disk device(s). root= /dev/sda1 ro disk= [ phy:xen1/postfix-dom1-disk,sda1,w, phy:xen1/postfix-dom1-swap,sda2,w ] # Hostname name= disprosio.math.unifi.it # Networking vif = [ ip= ] # Behaviour on_poweroff = destroy on_reboot = restart on_crash= restar adesso con il comando: xm create -c file-di-configurazione

49 42 CAPITOLO 3. INSTALLAZIONE viene avviato il domu che risulta essere una normale debian senza alcuna differenza da un istallazione effettuata su una macchina fisica. Con questa procedura sono state creati i seguenti domu: disprosio.math.unifi.it, olmio.math.unifi.it e terbio.math.unifi.it. 3.2 Installazione di Kerberos e AFS Il primo passo è stato installare il sistema di autenticazione Kerberos V, in quanto questa scelta caratterizza le configurazioni delle installazioni di AFS e KCA, tutti servizi che risiedono sullo stesso computer, tulio.math.unifi.it, con le seguenti caratteristiche: tulio:~# uname -a Linux tulio amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 GNU/Linux tulio:~# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 5 model name : AMD Opteron(tm) Processor 244 stepping : 10 cpu MHz : cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp flags : yes : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow up bogomips : TLB size : K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tulio:~# cat /proc/meminfo MemTotal: kb MemFree: kb Buffers: kb Cached: kb SwapCached: 0 kb Active: kb Inactive: kb HighTotal: 0 kb HighFree: 0 kb LowTotal: kb LowFree: kb

50 3.2. INSTALLAZIONE DI KERBEROS E AFS 43 SwapTotal: kb SwapFree: kb Dirty: 64 kb Writeback: 0 kb AnonPages: kb Mapped: kb Slab: kb PageTables: 1592 kb NFS_Unstable: 0 kb Bounce: 0 kb CommitLimit: kb Committed_AS: kb VmallocTotal: kb VmallocUsed: 4112 kb VmallocChunk: kb tulio:~# Il sistema installato su tulio, come su tutte le altre macchine del cluster, è una Debian Etch. I passi che descriverò per ottenere un istanza funzionante di Kerberos V, saranno abbastanza specifici per la distribuzione. I pacchetti necessari per installare Kerbros su un sistema debian con apt sono: apt-get install krb5-admin-server krb5-doc krb5-kdc krb5-user con questo semplice comando Kerberos è installato e funzionante, rimane solamente da configurarlo correttamente. I passi per la configurazione sono: 1. creare un REALM, che nel mio caso specifico sarà: GRID.MATH.UNIFI.IT 2. creare il databse di Kerberos ed un file per le ACL per accedervi 3. creare i principals necessari per autenticare l AFS e gli utenti nel sistema. Il primo step è la creazione del DB sono fatti automaticamente dall installer debian, per il secondo deve essere editato il file che si occupa di definire le ACL di default, in genere si trova in /etc/krb5kdc/kadm5.acl ed ha la seguente forma: tulio:~# cat /etc/krb5kdc/kadm5.acl */admin * tulio:~# In questo modo si specificano gli utenti che possono accedere al server Kerberos e con quali permessi, in questo caso tutti gli utenti il cui username termina in /admin hanno le credenziali di amministratori sul server tulio.math.unifi.it. Dopo queste operazioni è possibile connettersi al database e aggiungere gli account, denominati principals sotto kerberos. I comandi da usare sono kadmin.local per la connessione al database ed in seguito addprinc per per aggiungere gli utenti come ad esempio admin/admin con relativa password che sarà poi la password per accedere al sistema di storage distribuito AFS.

51 44 CAPITOLO 3. INSTALLAZIONE L ultima cosa da fare per rendere operativo il sistema di autenticzione Krb5 su tulio è creare correttamente il file di configurazione per il client, /etc/krb5.conf, specificando le coordinate per raggiungere il server, come si può vedere nell esempio che segue: [libdefaults] default_realm = GRID.MATH.UNIFI.IT # The following krb5.conf variables are only for MIT Kerberos. krb4_config = /etc/krb.conf krb4_realms = /etc/krb.realms kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true [realms] GRID.MATH.UNIFI.IT = { kdc = tulio.math.unifi.it admin_server = tulio.math.unifi.it } [domain_realm] math.unifi.it = GRID.MATH.UNIFI.IT.math.unifi.it = GRID.MATH.UNIFI.IT grid.math.unifi.it = GRID.MATH.UNIFI.IT.grid.math.unifi.it = GRID.MATH.UNIFI.IT [login] krb4_convert = true krb4_get_tickets = false Per l installazione del client servono solamente i pacchetti: krb5-clientse krb5-user Installazione AFS Come per Kerberos anche i pacchetti per l installazione dell Andrew File System sono forniti da Debian; è infatti sufficente eseguire il seguente comando apt-get install openafs-fileserver openafs-krb5 che risolve e installa tutte le dipendenze tra cui: openafs-client, openafs-modulessource. Quest ultimi sono i pacchetti che devono essere installati anche sulle macchine client. Dopo l installazione per rendere operativo il software, deve essere configurata la nuova cella e compilato il modulo openafs per ottenere la compatibilità del kernel linux e permettergli di fare il mount delle partizioni AFS. Per prima cosa si indica il nome della cella bos setcellname tulio grid.math.unifi.it -noauth

52 3.2. INSTALLAZIONE DI KERBEROS E AFS 45 e si avviano i servizi ptserver e vlserver : bos create tulio <servizio> simple /usr/afs/bin/<servizio> -cell grid.math.unifi.it -noauth. Si aggiunge l utente kerberos admin/admin come admin nell user list di AFS: bos adduser tulio admin/admin -cell grid.math.unifi.it -noauth bos addkey tulio -kvno 0 -cell grid.math.unifi.it -noauth pts cu -name admin -cell grid.math.unifi.it -noauth pts adduser admin system:administrators -cell grid.math.unifi.it -noauth come ultima cosa rimane da configurare il fileserver (fs) e il volume principale (root.afs): bos create tulio fs fs fileserver volserver salvager -cell grid.math.unifi.it -noauth vos create tulio /vicepa root.afs -cell grid.math.unifi.it -noauth la partizione /vicepa è la partizione fisica, formattata ext3, su cui viene creata la cella. A questo punto il server è configurato, rimane solamente da rendere operativo il client. Carichiamo il modulo del kernel compilato precedentemente e si creano due directory dove poter fare il mount del file system distribuito, ovvero: taylor:~# mkdir /afs} taylor:~# mkdir /usr/vice/cache} e si avvia il servizio ottenendo il seguente output: tulio:~# /etc/init.d/openafs-client start Starting AFS services: openafs afsd. afsd: All AFS daemons started. tulio:~# mount /dev/sda3 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/sda7 on /vicepa type ext3 (rw,errors=remount-ro) AFS on /afs type afs (rw) tulio:~# Per rendere realmente operativa la cella grid.math.unifi.it manca ancora da configurare i permessi per l accesso e i mount point per i volumi che si desidera creare su AFS, ad esempio il volume per le home degli utenti e quello relativo ai servizi sul quale installeremo il sistema batch SGE. La procedura seguita è la seguente:

53 46 CAPITOLO 3. INSTALLAZIONE tulio:~# vos create tulio /vicepa root.cell Volume created on partition /vicepa of tulio taylor:~# fs mkm /afs/grid.math.unifi.it root.cell tulio:~# fs sa /afs/grid.math.unifi.it system:anyuser rl tulio:/afs/grid.math.unifi.it# vos create tulio /vicepa user Volume created on partition /vicepa of tulio tulio:/afs/grid.math.unifi.it# /usr/afs/bin/vos create tulio /vicepa service Volume created on partition /vicepa of tulio tulio:/afs/grid.math.unifi.it# fs mkm /afs/grid.math.unifi.it/users user tulio:/afs/grid.math.unifi.it# fs sa /afs/grid.math.unifi.it/users/ system:authuser rl tulio:/afs/grid.math.unifi.it# fs mkm /afs/grid.math.unifi.it/service service tulio:/afs/grid.math.unifi.it# fs sa /afs/grid.math.unifi.it/service/ system:authuser rl tulio:/afs/grid.math.unifi.it# ls service users tulio:/afs/grid.math.unifi.it# Terminata la configurazione i passi per accedere al servizio si storage distribuito sono: 1. prendere le credenziali Kerberos (kinit) 2. ottenere il ticket per accedere AFS (aklog) che è a tutti gli effetti un sevizio kerberized (2.2.1) come vediamo nell esempio seguente, dove si ottengono i permessi per accedere e si visualizza lo stato dell Andrew File System: tulio:~# kinit -k admin/admin tulio:~# aklog tulio:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Valid starting Expires Service principal 07/22/07 18:00:14 07/23/07 18:00:14 07/22/07 18:00:18 07/23/07 18:00:14 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached tulio:~# bos status tulio Instance ptserver, currently running normally. Instance vlserver, currently running normally. Instance fs, currently running normally. Auxiliary status is: file server running. tulio:~# tulio:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal:

54 3.3. INSTALLAZIONE DI KCA & KX Valid starting Expires Service principal 07/13/07 11:35:37 07/14/07 11:35:37 07/13/07 11:35:41 07/14/07 11:35:37 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached tulio:~# 3.3 Installazione di KCA & Kx509 Il software che implementa il servizio di Certificaition Authority basato su ticket Kerberos, detto KCA, non rientra tra i pacchetti che Debian fornisce con il tool apt. Come specificato in 2.2.3, KCA e Kx509 sono progetti sviluppati da University of Michigan. Per installarlo si devono recuperare i sorgenti da e compilarli. Prima di procedere alla compilazione è stato necessario modificare il codice, in quanto in fase di compilazione generava errori relativi ad una funzione openssl, iptos(ntohl(peeraddr.sin_addr.s_addr),ipstore)), che era stata richiamata con una sintassi obsoleta. Effettuata la modifica, la procedura d installazione non ha presentato ulteriori problemi. I passi seguiti per ottenere i una kca funzionante sono stati:./configure enable-server make make install creare una coppia Private Key/Certificate per identificare la CA un file che contenente un seriale per identificare univocamente i certificati generati un file di configurazione, kca.conf configurare il DNS, Domain Name Server, in modo da raggiungere il servizio di KCA La fase più importante è stata senza dubbio creare una configurazione che fosse ottimale per la collaborazione con il Globus Toolkit 4. Insieme ai sorgenti viene distribuito uno script che permette di creare la coppia Private Key/Certificate senza incorrere in errori. Prima di eseguire lo script,./mkcacert.sh, andando a modificare la parte iniziale si può specificare la directory dei file di configurazione e dove risiede il comando openssl necessario per portare a buon fine questa operazione. #!/bin/sh ## ## mkcert.sh -- Make SSL Certificate Files for make certificate command ## Copyright (c) 1998 Ralf S. Engelschall, All Rights Reserved. ## # parameters configdir="/srv/kca/conf" # Configuration directory

55 48 CAPITOLO 3. INSTALLAZIONE openssl="/usr/bin/openssl" extdir="/srv/kca" # Path to the openssl program # Directory where to find extfile.ca... Lanciato lo script, dopo aver generato la chiave e prima di generare il certificato associato, chiede di specificare le informazioni da includere nel certificato che identificheranno la Certification Authority: Country Name (2 letter code) [IT]: State or Province Name (full name) [Italy]: Locality (eg, city) [Florence]: Organization Name (eg, company) [Dip. di Matematica U.Dini - Univ. Firenze]: Common Name (eg, FQDN) [grid.math.unifi.it]: Nome della CA Ottenendo così un certificato collegato alla chiave appena generata con il seguente subject: /C=IT/ST=Italy/L=Firenze/O=Dip.di Matematica U.Dini-Univ.Firenze/CN=grid.math.unifi.it A questo punto nella directory specificata, /srv/kca/conf, abbiamo il certificato e la chiave, mancano solo il seriale e il file di configurazione necessario per avviare il servizio. Per il primo è sufficiente creare un file serial con scritto all interno la stringa 01 ; per il secondo servono più operazioni. È necessario creare un keytab file per il servizio KCA generato da Kerberos V installato su tulio.math.unifi.it così da permettere a KCA di accedere al database Kerberos senza dover immetere alcuna password, passo essenziale in quanto la KCA deve lavorare come servizio kerberized. Fatta questa operazione manca solamente da creare il file di configurazione dove si specificano le coordinate dei certificati, del keytab file, la politica di gestione dei numeri seriali associati ai certificati e il dominio a cui appartiene la KCA, come si vede nell esempio riportato: # # KCA Configuration file # [ ca ] default_ca = CA_default # "CA_default" # # "default_ca" is the name of the default CA section of the config file # [ CA_default ] logfile_name = /srv/kca/log/kca.log # "/var/kca/kca.log" serial = /srv/kca/serial # "/var/https/test/ssl/kca_serial" sn_increment = 1 # "1" certificate = /srv/kca/conf/grid_cert.crt # "/var/kca/conf/kca.crt" private_key = /srv/kca/conf/grid_cert.key # "/var/kca/conf/kca.key" _domain = GRID.MATH.UNIFI.IT # <User s authentication realm> [ kx509 ] keytab = /srv/kca/conf/kca.keytab # "/var/kca/kca_service.keytab"

56 3.3. INSTALLAZIONE DI KCA & KX Per poter usufruire dei servizi della KCA manca solamente da aggiornare il DNS, dove si deve aggiungere la seguente riga al file relativo al dominio di interesse della KCA _kca._udp.grid.math.unifi.it. IN SRV tulio Dopo questo la configurazione è finita rimane solamente da lanciare il servizio in background: kca -c /srv/kca/kca.conf & Per quanto riguarda i client, è necessario solamente copiare gli eseguibili kx509 e kxlist, generati in fase di compilazione, sulle macchine che possiedono il client kerberos e sono configurate per raggiungere il realm grid.math.unifi.it. Di seguito riporto come esempio la successione di comandi per generare un certificato da credenziali kerbereos. disprosio:~# kinit gorini Password for disprosio:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Valid starting Expires Service principal 07/26/07 15:22:50 07/27/07 15:22:50 renew until 07/26/07 15:22:50 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached disprosio:~# kx509 disprosio:~# kxlist Service kx509/certificate issuer= /C=IT/ST=Italy/L=Firenze/O=Dip.di Matematica U.Dini-Univ.Firenze/CN=grid.math.unifi.it subject= /C=IT/ST=Italy/L=Firenze/O=Dip.di Matematica U.Dini-Univ.Firenze/OU=grid.math.unifi.it serial=25 hash=fa65a93d disprosio:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Valid starting Expires Service principal 07/26/07 15:22:50 07/27/07 15:22:50 renew until 07/26/07 15:22:50 07/26/07 15:23:01 07/27/07 15:22:50 renew until 07/26/07 15:22:50 07/25/07 15:23:01 07/27/07 15:22:50 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached disprosio:~#

57 50 CAPITOLO 3. INSTALLAZIONE 3.4 Installazione di un sistema batch: SGE Per soddisfare i requisiti di un installazione di AliEn Grid è risultato necessario installare sulla macchina che ospita il Computing Element, terbio.math.unifi.it, un sistema per la gestione di un cluster, che attualmente si compone di due macchine, ma che potenzialmente può ospitare un numero arbitrario di macchine. Il sistema batch scelto è quello sviluppato da Sun: SGE (Sun Grid Engine). La scelta è ricaduta su questo prodotto non solo per meriti specifici ma principalmente perchè è un prodotto Open Source, mentre la maggior parte degli altri supportati da Globus e quindi da AliEn sono sotto licenza proprietaria. L installazione di questo sistema batch è stata fatta sulla macchina virtuale con le seguenti specifiche: terbio:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 2.00GHz stepping : 7 cpu MHz : cache size : 4096 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc up pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm bogomips : Il software si può scaricare gratuitamente su scegliendo i binari a seconda dell architettura su cui deve essere instalato. Una volta recuperato il binario si crea una directory che diventerà il valore della variabile d ambiente SGE_ROOT, e vi si decomprime il contenuto del pacchetto. Fondamentale per l installazione è che la directory sia condivisa con i computer che avranno la funzione di nodi di esecuzione, nel nostro caso la directory SGE_ROOT per terbio.math.unifi.it risiede su AFS viene dunque montata da tutte le macchine del cluster. Con i binari viene fornito uno script per gestire il processo di installazione. Infatti eseguendo il file./install_qmaster vengono richieste le informazioni necessarie per la configurazione che si vuole dare al cluster e al termine si ottiene un istanza funzionante del qmaster di SGE, ovvero il processo che gestisce le code di esecuzione. Per rendere totalmente operativo il sistema rimane da installare il processo che permette alla macchina di agire come execution node per il cluster. Anche questo passo di installazione è assistito da uno script,./install_execd che richiede un qmaster attivo per poter essere eseguito correttamente. Questa procedura ha quindi portato ad ottenere un sistema SGE completo e funzionante al quale è possibile aggiungere nodi eseguendo solo il passo relativo all execd. Infatti al qmaster è

58 3.5. INSTALLAZIONE DI GLOBUS 51 stato affiancato un Worker Node di AliEn che lavora come un execution node di SGE, erbio.math.unifi.it, come si vede nell esempio che segue dove eseguendo il comando qstat -f è possibile controllare lo stato dei nodi SGE e delle code di esecuzione. ~]$ qstat -f queuename qtype used/tot. load_avg arch states BIP 1/ lx24-x86 a AliEn.JobA aliprod r 07/27/ :28: BIP 1/ lx24-x AliEn.JobA aliprod r 07/27/ :09:29 1 ############################################################################ - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS ############################################################################ AliEn.JobA aliprod qw 07/24/ :52: AliEn.JobA aliprod qw 07/25/ :20: AliEn.JobA aliprod qw 07/25/ :57: AliEn.JobA aliprod qw 07/26/ :00: AliEn.JobA aliprod qw 07/26/ :03: AliEn.JobA aliprod qw 07/27/ :26: AliEn.JobA aliprod qw 07/27/ :30: AliEn.JobA aliprod qw 07/27/ :09:29 1 ~]$ qselect ~]$ 3.5 Installazione di Globus L installazione di Globus è stata sicuramente la più delicata, in quanto ci sono molte componenti che devono coesistere per rendere possibile la collaborazione di più istanze e quindi di più computer. Le macchine su cui ho installato il Globus Toolkit sono virtuali e tutte con le seguenti caratteristiche: cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 1.60GHz stepping : 6 cpu MHz : cache size : 4096 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes

59 52 CAPITOLO 3. INSTALLAZIONE fpu_exception : yes cpuid level : 10 wp : yes flags : fpu tsc msr pae mce cx8 apic mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc up pni monitor ds_cpl vmx tm2 cx16 xtpr lahf_lm bogomips : Su queste macchine si è dovuto installare i seguenti programmi che sono considerati prerequisiti da [1]: zlib, J2SE SDK, apache-ant, gcc, g++, tar, sed, make, sudo, perl, postgres e libiodbc. Ci sono due strade per installare GT4: compilare tutti i sorgenti installare i binari specifici per la distribuizione e l architettura che si usa, ovviamente se questi sono presenti su, Le prime prove di installazione le ho fatte partendo dai sorgenti in quanto stavo effettuando delle prove su la distribuzione del CERN, SLC3. In seguito alla scelta di creare il pool di macchine con Debian, ho ritenuto più opportuno adottare i binary forniti dalla Globus Alliance. Ho quindi scaricato i pacchetti tar.gz relativi e li ho scompattati in una directory nella nella home di globus, che deve risultare il proprietario di tutti i file relativi al globus toolkit. Quindi ho creato la directory dove poi ho installato il software del toolkit, /usr/local/globus-4.0.5/. A questo punto ho eseguito esattament egli stessi pasi che si devono seguire installando il globus da sorgenti: 1. cd /home/globus/gt4.0.5-x86_deb_3.1-installer 2. export ANT_HOME=/usr/local/apache-ant export JAVA_HOME=/usr/java/j2sdk1.4.2_10/ 4. export PATH=$ANT_HOME/bin:$JAVA_HOME/bin:$PATH 5../configure prefix=/usr/local/globus-4.0.5/ with-iodbc=/usr/lib 6. make 7. make install Rispetto all installazione da sorgenti ho risparmiato del tempo in quanto i programmi erano già compilati per la distribuzione. Sono quindi passato alla parte più delicata la configurazione Configurazione della Security Per quanto riguarda la sicurezza come prima configurazione ho preferito adottare la CA suggerrita da [1] e quindi seguire lo schema di installazione della simpleca fornita insieme a Globus. Dopo aver impostato la variabile d ambiente export GLOBUS_LOCATION=/usr/local/globus-4.0.5

60 3.5. INSTALLAZIONE DI GLOBUS 53 e caricato l ambiente di globus mediante il comando source $GLOBUS_LOCATION/etc/globus-user-env.sh si richiama il setup della CA contenuta nel pacchetto di software che compone Globus $GLOBUS_LOCATION/setup/globus/setup-simple-ca Questo dopo aver richiesto la specifica di due parametri, password di certificato per la CA e l dell amministratore, provvede a generare la coppia chiave/certificato con cui firmare tutti i certificati che saranno generati. Al termine di questa procedura, viene richiesto di eseguire il setup-gsi del pacchetto Globus appena generato e installato. Questo passo però deve essere eseguito con i permessi di super utente, in quanto deve modificare tutte le componenti relative alla sicurezza specificate in GSI, ovvero eseguendo questo comando $GLOBUS_LOCATION/setup/globus_simple_ca_ebb88ce5_setup/setup-gsi -default viene creata la struttura di directory per la grid-security e i file contenenti le configurazioni per interfacciarsi alla simple CA per ottenere le creedenziali per accedere al sistema. Affinchè la Certification Authority creata e riconosciuta dal Toolkit risulti operativa deve essere creato un certificato host per la macchina che ospita la CA. Questo viene eseguito in tre passi: grid-cert-request -host hostname grid-ca-sign -in /etc/grid-security/hostcert_request.pem -out hostsigned.pem copiare il certificato firmato in /etc/grid-security e rinominare chiave e certificato come containerkey.pem e containercert.pem Configurazione del GridFTP, RFT e GRAM Dopo aver configurato la sicurezza di Globus è possibie completare l installazione del Toolkit inizializzando i servizi GridFTP, RFT e GRAM, necessari per lo spostamento dei file e per la scelta delle risorse coinvolte nel processo sottomesso alla GRID. Per quanto riguarda il GridFTP i passi per far partire il servizio sono due: inserire la riga relativo a questo servizio nel file relativo ai servizi, /etc/services e creare il seguente script per permettere al programma xinetd di avviare il servizio scrivendo /etc(init.d/xinetd reload. service gsiftp { instances = 100 socket_type = stream wait = no user = root env += GLOBUS_LOCATION=/usr/local/globus env += LD_LIBRARY_PATH=/usr/local/globus-4.0.5/lib server = /usr/local/globus-4.0.5/sbin/globus-gridftp-server server_args = -i

61 54 CAPITOLO 3. INSTALLAZIONE log_on_success += DURATION nice = 10 disable = no } A questo punto per completare la sezione che si occupa di trasferire i file si deve configurare l RFT, ovvero è stato configurato postgres ad accettare connessioni FTP per il database, rftdatabase, creato appositamente con gli script forniti dal toolkit. Dopo questo è stato possibile avviare il container ovvero tutto il pacchetto software installato con Globus, a meno del gestore delle risorse GRAM. Per avviare GRAM è bastato editare il file textsf/etc/sudoers con il comando visudo aggiungendo le seguenti righe: dopo di che riavviando il container tutti i servizi di Globus erano up and running. globus ALL=(gorini) NOPASSWD: /usr/local/globus-4.0.5/libexec/globus-gridmap-and-execute -g /etc/grid-security/grid-mapfile /usr/local/globus-4.0.5/libexec/globus-job-manager-script.pl * globus ALL=(gorini) NOPASSWD: /usr/local/globus-4.0.5/libexec/globus-gridmap-and-execute -g /etc/grid-security/grid-mapfile /usr/local/globus-4.0.1/libexec/globus-gram-local-proxy-tool * dove gorini è l utente che ho utilizzato per fare le prove di installazione. Ho ripetuto l installazione altre due volte con la sola differenza che in una, olmio.math.unifi.it, mi sono appoggiato alla simpleca già installata su disprosio.math.unifi.it (installazione appena descritta), mentre su itterbio.math.unifi.it ho installato un ulteriore CA in modo da poter ossevare il meccanismo di delegation Configurazione di WebMDS Per completare l installazione del Globus è stato configurato anche il sistema di monitoring fornito insieme al Toolkit, WebMDS. WebMDS è una servlet java che si interfaccia alle componenti di Globus, quali GRAM, RFT e GRIDFTP, appartenenti allo stesso gruppo di lavoro. L installazione consiste nel configurare un server Apache Tomcat su una delle macchine su cui è installata un istanza dei software GRID; nel nostro caso è stato scelto di installare il monitor su olmio.math.unifi.it, mentre la macchina adibita a raccogliere le informazioni a cui il WebMDS si rivolge per reperire informazioni è disprosio.math.unifi.it. Il risultato che si ottiene sono delle pagine web che monitorizzano lo stato delle macchine coinvolte nel gruppo di Globus, ovvero lo stato dei job elaborati in tutti i suoi aspetti. Di seguito sono riportati degli screenshot del WebMDS installato su olmio.math.unifi.it.

62 3.5. INSTALLAZIONE DI GLOBUS 55 Figura 3.4: Web MDS Main page Figura 3.5: Web MDS Group Detail

63 56 CAPITOLO 3. INSTALLAZIONE Service Group Entry Detail Service Group Entry Detail Service Group EPR Address: https:// :8443/wsrf/services/defaultindexserviceentry GroupKey: EntryKey: Member Service EPR Address: https:// :8443/wsrf/services/defaultindexservice Content AggregatorConfig: GetResourcePropertyPollType: PollIntervalMillis: ResourcePropertyName: wssg:entry AggregatorData: Entry: ServiceGroupEntryEPR: Address: https:// :8443/wsrf/services/defaultindexserviceentry ReferenceProperties: ServiceGroupEntryKey: GroupKey: EntryKey: MemberServiceEPR: Address: https:// :8443/wsrf/services/managedjobfactoryservice ReferenceProperties: ResourceID: Multi Content: type: ns5:aggregatorcontent AggregatorConfig: GetResourcePropertyPollType: PollIntervalMillis: ResourcePropertyName: glue:gluece Entry: ServiceGroupEntryEPR: Address: https:// :8443/wsrf/services/defaultindexserviceentry ReferenceProperties: ServiceGroupEntryKey: GroupKey: EntryKey: MemberServiceEPR: Address: https:// :8443/wsrf/services/managedjobfactoryservice ReferenceProperties: ResourceID: Fork Content: type: ns10:aggregatorcontent AggregatorConfig: GetResourcePropertyPollType: PollIntervalMillis: ResourcePropertyName: glue:gluece AggregatorData: GLUECE: ComputingElement: Name: default UniqueID: default Info: GRAMVersion: HostName: olmio.math.unifi.it LRMSType: Fork LRMSVersion: 1.0 TotalCPUs: 1 State: EstimatedResponseTime: 0 FreeCPUs: 1 RunningJobs: 0 Status: enabled TotalJobs: 0 WaitingJobs: 0 WorstResponseTime: 0 Policy: MaxCPUTime: -1 MaxRunningJobs: -1 MaxTotalJobs: -1 MaxWallClockTime: -1 Priority: 0 Entry: ServiceGroupEntryEPR: Address: https:// :8443/wsrf/services/defaultindexserviceentry ReferenceProperties: ServiceGroupEntryKey: GroupKey: EntryKey: MemberServiceEPR: Address: https:// :8443/wsrf/services/reliablefiletransferfactoryservice Content: type: ns15:aggregatorcontent AggregatorConfig: GetMultipleResourcePropertiesPollType: PollIntervalMillis: ResourcePropertyNames: rft:totalnumberofbytestransferred ResourcePropertyNames: rft:totalnumberofactivetransfers ResourcePropertyNames: rft:rftfactorystarttime ResourcePropertyNames: rft:activeresourceinstances ResourcePropertyNames: rft:totalnumberoftransfers Please report bugs and feature requests into the Globus Bugzilla. XSLT transformation provided by sgedetail.xsl version 1.4. Figura 3.6: Web MDS RFT Detail

64 4 Globus Delegation e KCA Prima di affrontare i concetti di sicurezza e di delegation che implementa Globus è fondamentale comprendere cosa significhi realmente stabilire una comunicazione sicura, che non si limita solo alla encryption e decryption dei dati coinvolti nella trasmissione. Una comunicazione per poter esser definita sicura deve rispecchiare queste tre caratteristiche: Privacy: Lo scambio di messaggi deve comunque rimanere privato, ovvero il messaggio deve essere leggibile solamente dagli interassati e non da intrusi che sono riusciti a intercettare il messaggio. Questo livello di sicurezza solitamente è raggiungibile con gli algoritmi di encryption/decryption. Integrity: Il messaggio inviato deve arrivare a destinazione senza subire alcuna modifca da parte di possibili intrusi. Questo è garantito grazie ad alcuni algoritmi di encrypting, come gli algoritmi di cifratura a chiave pubblica. Authentication: L identità coinvolte nella trasmissione devono essere certe, ovvero nessun intruso deve poter simulare uno dei due partecipanti alla comunicazione. Questo è garantito solo dagli algoritmi di encrypting più recenti. Spesso a questi parametri viene aggiunto un ulteriore punto per definire o meno una comunicazione sicura, l Authorization. Spesso confusa con l autenticazione (solo per affinità di suono, ma in realtà si riferisce ad un aspetto completamente diverso). L Autorizzazione infatti si occupa di definire cosa un utente autenticato può o non può fare. In un ambiente GRID la fase di Autorizzazione è tanto importante quanto gli altri aspetti, poichè gli utenti della griglia non possiedono gli stessi diritti. È evidente che per ottenere privacy, integrity e autentication è essenziale la Criptografia, che può essere definita come l arte di scrivere con caratteri segreti. È composta di due fasi: Encrypting, l azione di tradurre messaggi normali in in messaggi scritti con caratteri segreti (encrypted message) e Decrypting, ovvero tradurre i messaggi criptati in forma leggibile (unencrypted message). Gli algoritmi di crtittografia si dividono principalmente in due classi di algoritmi: Simmetrici la stessa chiave di cifratura è usata sia per cifrare che per decifrare

65 58 CAPITOLO 4. GLOBUS DELEGATION E KCA Asimettrici chiavi di cifratura diverse per cifrare e decifrare, l algoritmo a Chiave Pubblica è uno dei più usati di questa categoria. 4.1 Criptografia a Chiave Pubblica e X.509 Per coprire i requisiti elencati in precedenza e stabilire connessioni sicure il Globus Toolkit adotta un sistema di cifratura a chiave pubblica implementato con l uso dei certificati X.509 e connessioni SSL Criptografia a Chiave Publica L algoritmo di cifratura a chiave pubblica fa parte della classe ddegli algoritmi asimmetrici, quindi basato su due chiave chiavi, che vengono chiamate: Private Key conosciuta solo dal possesore Public Key conosciuta da tutti Figura 4.1: Ctittografia a Chiave Pubblica La relazione tra queste due chiavi è legata alla capacità che hanno di decifrare quello che l altra ha cifrato. Se il messaggio viene firmato con la chiave privata si è sicuri del mittente ma non che lo possa leggere un unico ricevente, mentre se si invia un messaggio criptato con la chiave pubblica siamo certi che lo leggerà solo chi possiede la chiave privata relativa, rispettando così il vincolo di privacy. La Crittografia a chiave pubblica basa la sua sicurezza sul fatto che ricavare la chiave privata conoscendo la pubblica è un problema, dall enorme costo computazionale, di non facile e rapida soluzione. Questo algoritmo presenta un grande svantaggio tipico della classe degli algoritmi asimmetrici, ovvero il calcolo è notevolmente più dispendioso e lungo rispetto agli algoritmi simmetrici. Di contro ha due aspetti vantaggiosi che risultano essenziali per ottenere e mantenere una connessione sicura. Il primo è non aver una necessità di mantenere una chiave comune tra i due partecipanti alla comunicazione; il secondo, ed anche il più significativo, è il fatto che la chiave pubblica, ripetto agli algoritmi simmetrici garantisce autenticazione e integrità oltre alla privacy.

66 4.1. CRIPTOGRAFIA A CHIAVE PUBBLICA E X Integrità L integrità nel sistema a chiave pubblica è garantita dalla firma digitale. La firma è di fatto una parte del messaggio che permette di capire se un messaggio ha subito modifiche durante la conversazione. Figura 4.2: Generazione di una Firma Digitale La firma digitale viene generata essenzialmente in due passi. Per prima cosa si crea un message digest, una somma del messaggio che si vuol trasmettere calcolata con un algoritmo di hashing che risulti sempre di dimensioni più piccole rispetto al messaggio e che cambi ad ogni minima modifica. Quindi si codifica con la chiave privata e si ottiene la firma digitale che viene inviata insieme al messaggio relativo. Il ricevente effettua le medesime operazioni, ovvero decodifica sia il testo che la firma, poi con lo stesso algoritmo crea il digest del messaggio che ha ricevuto e se risulta identico al digest associato al messaggio è certo che l integrità della comunicazione è stata preservata. Autenticazione La firma digitale contribuisce anche a garantire una weak authentication. Infatti se la relazione tra chiave pubblica e privata è rispettata siamo sicuri che il messaggio provenga da un determinato utente; è altrettanto vero però che questo non fornisce alcuna garanzia sulla possibilità che qualcuno possa impersonare il mandante. Applicando la firma digitale ai certificati, ovvero usando i certificati digitali, si ottengono le conferme cercate: che una determinata chiave sia veramente in possesso di un particolare utente Certificati X.509 La CA è l ente che gestisce il rilascio e garantisce le credenziali che queste forniscono, apponendo la firma su questi documenti come si vede nell esempio della figura 4.3. La firma della CA è ottenuta dalla sua chiave privata dalla quale si può verificare l integrità con la chiave pubblica applcando l algoritmo descritto in

67 60 CAPITOLO 4. GLOBUS DELEGATION E KCA Figura 4.3: Esempio di un certificato Digitale Tutto il meccanismo è fondato sulla fiducia, infatti il certificato digitale assume la funzione tipica di una firma digitale, confermando che il messaggio provenga da una determinata persona (meccanismo di chiave privata/pubblica); in più se la CA che ha firmato il certificato è trusted si ha anche la certezza che nessuno lo abbia usato impropriamente, ottenendo definitivamente la proprietà di autenticazione e di connessione sicura. Formato X.509 I certificati sono scritti secondo una codifica ben precisa: X.509. Un certificato X.509 è un file di testo che contiene numerose informazioni inserite secondo una precisa sintassi. Le informazioni che possono essere inserite sono molteplici ma quelle indispensabili per la funzione di un certificato sono quattro: - Subject : identifica il nome dell utente in un certificato codificato nel seguente modo, O=Università di Firenze, OU=Informatica, CN=Stefano Claudio Gorini dove : O identifica l organizzazione OU Unità specifica dell organizzazione CN il Common Name ovvero comunemente qui si trova il nome dell utente C il paese di appartenenza dell utente - Subject s Public Key indica la chiave e l algoritmo usato per clacolarla - Iusser s Subject indica la CA che ha rilasciato il certificato - Digital Signature è la firma digitale di tutte le informazioni contenute ne certificato generata con la chiave privata della CA. Quello che segue è un esempio reale di un certificato X.509 e come si può chiaramente vedere contiene molte altre informazioni, come la versione del formato X.509 utilizzata, il periodo in cui il certificato è considerato valido dalla CA. Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2)

68 4.2. GT4 DELEGATION 61 Signature Algorithm: md5withrsaencryption Issuer: O=Grid, OU=GlobusTest, OU=simpleCA-itterbio.math.unifi.it, CN=Globus Simple CA Validity Not Before: Jul 14 18:53: GMT Not After : Jul 13 18:53: GMT Subject: O=Grid, OU=GlobusTest, OU=simpleCA-itterbio.math.unifi.it, OU=math.unifi.it, CN=Gorini Stefano Claudio Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:d2:6e:90:81:b5:0e:a2:db:fb:d4:89:3a:f8:e8: f6:8e:4b:5e:53:5a:1b:04:01:3a:f5:f5:34:14:15: ab:25:21:18:9b:d8:7c:62:4d:da:4a:38:14:06:50: b7:14:f9:d4:2f:42:8b:19:d5:6e:7d:0a:e5:49:f2: e7:78:fe:24:e6:99:8b:a0:02:24:dc:de:e5:66:de: b1:ae:6b:60:a1:c2:76:57:0d:13:21:e1:e1:63:ad: c5:ee:0a:56:50:17:cd:cd:b6:3a:36:b7:06:93:2d: 6c:d6:48:7b:ab:57:b4:aa:9d:d3:48:6b:04:ef:c1: 5e:76:07:21:65:3a:4c:1f:05 Exponent: (0x10001) X509v3 extensions: Netscape Cert Type: SSL Client, SSL Server, S/MIME, Object Signing Signature Algorithm: md5withrsaencryption 9c:22:59:2e:d1:e4:74:0a:7f:0d:ea:6b:98:c8:5d:64:b4:95: f5:c2:d3:92:c7:8d:46:50:c3:17:d9:0b:09:74:00:4d:37:6f: 04:b5:e1:a8:cb:2d:54:0f:01:00:28:57:f4:8d:9d:27:df:01: 21:8b:b9:88:05:c8:dd:40:b7:7c:d5:3f:24:7b:f1:be:7a:6f: 51:5d:79:dc:04:6e:57:d1:cf:43:dd:10:71:9a:f8:e5:df:80: Tutto il meccanismo dei certificati si basa sulla fiducia che gli utenti ripongono nelle Certificaion Authority. Un ultimo chiarimento è quindi necessario per coprendere a pieno il meccanismo dei certificati digitali. Le CA che firmano per gli utenti sono a loro volta identificate da n certificato che le distingue in due tipologie: self-signed CA, detta anche root, e not self-signed CA. La prima firma il proprio cerificato da sola richiedendo così che gli utenti si fidino direttamente di lei. La seconda, invece, è parte di una catena dove a partire da una self-signed CA, derivano numerose CA i cui certificati di identità sono sottoscritti dalla root o da una CA che gerarchicamente risiede al livello superiore (fig.4.4). La catena che si forma crea anche una catena di fiducia permettendo agli utenti di fidarsi anche di CA non direttamente conosciute ma che sono segnate come trustworthy. 4.2 GT4 Delegation La sicurezza, come riferito in 2.3, rappresenta uno degli aspetti fondamentali di un ambiente GRID. Anche il Globus Toolkit implementa un infrastruttura per gestire questo aspetto, GSI (Grid Security Infrastructure).

69 62 CAPITOLO 4. GLOBUS DELEGATION E KCA Figura 4.4: CA trustworthy Delegation e single sign-on Delegation e single sign-on rappresentano una delle funzionalità più importanti di GSI. Infatti in una Grid sono tipicamente coinvolte più organizzaioni ognuna con il proprio meccanismo di autenticazione e dover inserire più volte le proprie credenziali risulta un operazione scomda oltre che inutile. Infatti è notevolmente più comodo e veloce accredi- Figura 4.5: Delegation tarsi una volta e far si che le risorse della Grid siano in grado di passarsi le credenziali degli utenti. La tecnologia che permette la delega delle credenziali è il Proxy Certificate. Si definisce proxy come lo strumento con cui una persona ha il permesso di eseguire operazioni in vece di un altra (The instrument by which a person is empowered to transact the affairs of another, definizione del vocavolario Webster); il proxy forniscce certificati del tipo raffigurato in 4.6 per permette questo tipo di operazione. Il certificato rilasciato è valido in quanto firmato con la chiave privata del proxy, che è generata appositamente, in accordo tra le entità coinvolte. Una particolarità (anche questa visibile dalla fig.4.6) dei proxy certificate risiede nel limite temporale imposto all usabilità con la specifica di un lifetime. L introduzione di quest ulteriore livello che permette a qualcuno di aagire incondizinatamente in nome di un altro introduce ovviamente nuovi rischi; i lifetime permettono di limitare i danni, ma la vera difesa è rappresentata dalla possibilità di poter limitare l uso dei proxy solamente ad alcune attività. Si descrive ora brevemente il meccaniso che permette di usare il proxy certificate. Il processo di validazione di un certificato proxy è simile a quello descritto nelle sezioni

70 4.3. SIMPLE-CA E KCA 63 Figura 4.6: Un esempio di certificato rilasciato dal proxy precedente. La differenza principale è che il certificato non è firmato da alcuna CA, ma dall utente. Infatti nel certificato viene specificato il nome dell utente la cui chiave pubblica deve essere usata per testarne l autenticità. Figura 4.7: Un esempio di certificato rilasciato dal proxy Per ovviare al fatto che il ricevente possa non conoscere l utente che firma la delega, viene inviata insieme al proxy certificate anche il certificato dell utente coinvolto. Quest ultimo, come tutti i certificati X.509 è firmato da una Certification Authority, quindi per validare le credenziali del proxy si crea una catena, fig.4.7, di firme che riferiscono comunque ad una CA. La catena può comunque espandersi ulteriormente poichè niente impedisce ad un proxy di firmare un altro proxy e così via, permettendo così di ampliare maggiormente il meccanismo di delega. 4.3 simple-ca e KCA Come abbiamo visto nella sezioni precedenti la security di Globus è demandata ad un sistema di certificati SSL del tipo X.509. Nella sezione del capitolo 3 abbiamo specificato quale fosse il sistema installato di default sul Globus Toolkit, simple-ca.

Griglie computazionali

Griglie computazionali Griglie computazionali Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno IL MIDDLEWARE Richiami sulla caratterizzazione dei sistemi GRID Il Concetto di Virtual

Dettagli

Organizzazioni nel Grid Computing

Organizzazioni nel Grid Computing Il ruolo delle Organizzazioni nel Grid Computing Un primo sguardo a Globus - Parte 5 Organizzazioni di Grid Computing Panoramica sui prodotti software Primo sguardo a Globus Dott. Marcello CASTELLANO La

Dettagli

Griglie computazionali LEZIONE N. 14. Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno

Griglie computazionali LEZIONE N. 14. Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno Griglie computazionali Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno LEZIONE N. 14 OGSA, OGSI e WSRF Gli Standard OGF Griglie computazionali - a.a. 2009-10

Dettagli

Architetture software. Virtualizzazione

Architetture software. Virtualizzazione Sistemi Distribuiti Architetture software 1 Virtualizzazione 2 1 Virtualizzazione (motivazioni) Sullo stesso elaboratore possono essere eseguiti indipendentemente d t e simultaneamente t sistemi i operativi

Dettagli

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

Presentazione NIS Network Integration & Solutions s.r.l. Autore: nome Cognome Data: Evento

Presentazione NIS Network Integration & Solutions s.r.l. Autore: nome Cognome Data: Evento Presentazione NIS Network Integration & Solutions s.r.l. Autore: nome Cognome Data: Evento Chi siamo NIS nasce nel 1993 come spin-off dalla Università di Genova (DIST) Nel 1996 viene aperta una unità operativa

Dettagli

Problemi di schedulazione distribuita su Grid

Problemi di schedulazione distribuita su Grid Problemi di schedulazione distribuita su Grid Ivan Porro Università degli Studi di Genova, DIST, Laboratorio BioLab pivan@unige.it 010-3532789 Si ringrazia per il materiale il Dr. Andrea Clematis dell

Dettagli

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGNERIA

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGNERIA UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGNERIA Corso di Sistemi Operativi Prof. Stefano Berretti SEMINARIO: VIRTUALIZZAZIONE DI INFRASTRUTTURE INFORMATICHE a cura di: Nicola Fusari A.A. 2012/2013

Dettagli

Sicurezza nei Sistemi Distribuiti

Sicurezza nei Sistemi Distribuiti Sicurezza nei Sistemi Distribuiti Aspetti di Sicurezza La sicurezza nei sistemi distribuiti deve riguardare tutti i componenti del sistema e coinvolge due aspetti principali: Le comunicazioni tra utenti

Dettagli

Sicurezza nei Sistemi Distribuiti

Sicurezza nei Sistemi Distribuiti Sicurezza nei Sistemi Distribuiti Aspetti di Sicurezza La sicurezza nei sistemi distribuiti deve riguardare tutti i componenti del sistema e coinvolge due aspetti principali: Le comunicazioni tra utenti

Dettagli

Protezione del Kernel Tramite Macchine Virtuali

Protezione del Kernel Tramite Macchine Virtuali Protezione del Kernel Tramite Macchine Virtuali Fabio Campisi Daniele Sgandurra Università di Pisa 27 Novembre 2007 1/44 Protezione del Kernel Tramite Macchine Virtuali Università di Pisa Sommario della

Dettagli

Sicurezza nelle Grid. Sommario. Page 1. Il Problema della Sicurezza nelle Grid. Grid Security Infrastructure Autorizzazione

Sicurezza nelle Grid. Sommario. Page 1. Il Problema della Sicurezza nelle Grid. Grid Security Infrastructure Autorizzazione Sommario Il Problema della Sicurezza nelle Grid Sicurezza nelle Grid Grid Security Infrastructure Autorizzazione 2 Page 1 Il Problema della Sicurezza nelle Grid (1) Le risorse sono presenti domini amministrativi

Dettagli

Virtualizzazione e Macchine Virtuali

Virtualizzazione e Macchine Virtuali Virtualizzazione e Macchine Virtuali Gabriele D Angelo, Ludovico Gardenghi {gda, garden}@cs.unibo.it http://www.cs.unibo.it/~gdangelo/ http://www.cs.unibo.it/~gardengl/ Università di Bologna Corso di Laurea

Dettagli

EGRID MIDDLEWARE OVERVIEW. Angelo Leto Abdus Salam I.C.T.P. aleto@ictp.trieste.it 08/10/2004

EGRID MIDDLEWARE OVERVIEW. Angelo Leto Abdus Salam I.C.T.P. aleto@ictp.trieste.it 08/10/2004 EGRID MIDDLEWARE OVERVIEW Angelo Leto Abdus Salam I.C.T.P. aleto@ictp.trieste.it 08/10/2004 Introduzione al concetto di GRID Sulla base dell implementazione GLOBUS-EDG-EGRID What is the GRID? What is the

Dettagli

Web Services e Grid Services. OGSA e WSRF. Sommario. Page 1

Web Services e Grid Services. OGSA e WSRF. Sommario. Page 1 Sommario Web Services e Grid Services OGSA e WSRF SOA Grid: Evoluzione OGSA - Open Grid Services Architecture WSRF Web Services Resource Framework Web services Servizi stateless Gestione dello stato Grid

Dettagli

Web Services e Grid Services. OGSA e WSRF

Web Services e Grid Services. OGSA e WSRF Web Services e Grid Services OGSA e WSRF Sommario SOA Grid: Evoluzione OGSA - Open Grid Services Architecture WSRF Web Services Resource Framework Web services Servizi stateless Gestione dello stato Grid

Dettagli

Grid Middleware: L interazione con IPv6. Valentino R. Carcione valentino.carcione@garr.it GARR. [GARR WS7-Roma-16-11-2006]

Grid Middleware: L interazione con IPv6. Valentino R. Carcione valentino.carcione@garr.it GARR. [GARR WS7-Roma-16-11-2006] Grid Middleware: L interazione con IPv6 Valentino R. Carcione valentino.carcione@garr.it GARR [GARR WS7-Roma-16-11-2006] Grid e IPv6, quali vantaggi? IPv6 offre uno spazio di indirizzamento molto ampio

Dettagli

Reti di Calcolatori GRIGLIE COMPUTAZIONALI

Reti di Calcolatori GRIGLIE COMPUTAZIONALI D. Talia RETI DI CALCOLATORI - UNICAL 10-1 Reti di Calcolatori GRIGLIE COMPUTAZIONALI D. Talia RETI DI CALCOLATORI - UNICAL 10-2 Griglie Computazionali Cosa è il Grid Computing? Architettura Ambienti Globus

Dettagli

GRIGLIE COMPUTAZIONALI

GRIGLIE COMPUTAZIONALI Reti di Calcolatori GRIGLIE COMPUTAZIONALI D. Talia RETI DI CALCOLATORI - UNICAL 10-1 Griglie Computazionali Cosa è il Grid Computing? Architettura Ambienti Globus D. Talia RETI DI CALCOLATORI - UNICAL

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

Virtualizzazione. Orazio Battaglia

Virtualizzazione. Orazio Battaglia Virtualizzazione Orazio Battaglia Definizione di virtualizzazione In informatica il termine virtualizzazione si riferisce alla possibilità di astrarre le componenti hardware, cioè fisiche, degli elaboratori

Dettagli

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Dopo anni di innovazioni nel settore dell Information Technology, è in atto una profonda trasformazione.

Dettagli

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche Il Cloud Computing La visualizzazione nella Cloud Problematiche Virtualizzazione della GPU Front end Virtualization

Dettagli

Single Sign On sul web

Single Sign On sul web Single Sign On sul web Abstract Un Sigle Sign On (SSO) è un sistema di autenticazione centralizzata che consente a un utente di fornire le proprie credenziali una sola volta e di accedere a molteplici

Dettagli

Identity Access Management nel web 2.0

Identity Access Management nel web 2.0 Identity Access Management nel web 2.0 Single Sign On in applicazioni eterogenee Carlo Bonamico, NIS s.r.l. carlo.bonamico@nispro.it 1 Sommario Problematiche di autenticazione in infrastrutture IT complesse

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

Lezione 4 La Struttura dei Sistemi Operativi. Introduzione

Lezione 4 La Struttura dei Sistemi Operativi. Introduzione Lezione 4 La Struttura dei Sistemi Operativi Introduzione Funzionamento di un SO La Struttura di un SO Sistemi Operativi con Struttura Monolitica Progettazione a Livelli di un SO 4.2 1 Introduzione (cont.)

Dettagli

RETI PEER-TO-PEER. Reti di Calcolatori. Applicazioni di Rete avanzate: Reti di Calcolatori. Sistemi Peer to Peer Griglie Computazionali

RETI PEER-TO-PEER. Reti di Calcolatori. Applicazioni di Rete avanzate: Reti di Calcolatori. Sistemi Peer to Peer Griglie Computazionali Reti di Calcolatori Applicazioni di Rete avanzate: Sistemi Peer to Peer Griglie Computazionali Corso di Reti di Calcolatori Carlo Mastroianni Reti di Calcolatori RETI PEER-TO-PEER Sistemi P2P In una rete

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

Strutture dei Sistemi Operativi

Strutture dei Sistemi Operativi Strutture dei Sistemi Operativi Componenti di sistema Servizi del sistema operativo Chiamate di sistema Programmi di sistema Struttura del sistema Macchine virtuali Progetto e implementazione di sistemi

Dettagli

Service Level Agreement Management Framework

Service Level Agreement Management Framework Facoltà di Ingegneria Università degli studi di Catania Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Workshop su QoS e SLA Service Level Agreement Management Framework Giovanni Morana

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli

2. VIRTUALIZZAZIONE MEDIANTE PARTIZIONAMENTO

2. VIRTUALIZZAZIONE MEDIANTE PARTIZIONAMENTO 2. VIRTUALIZZAZIONE MEDIANTE PARTIZIONAMENTO In questo capitolo verranno prese in considerazione le soluzioni tecnologiche e gli approcci implementativi della virtualizzazione basata su partizionamento

Dettagli

Virtualizzazione e Privacy

Virtualizzazione e Privacy Virtualizzazione e Privacy Outline Virtualizzazione Paravirtualizzazione e Xen Virtualizzazione e anonimato (Mix Network) Virtualizzazione e privacy Isolamento servizi utente Virtual Service Domains Virtualizzazione

Dettagli

Architettura di un sistema operativo

Architettura di un sistema operativo Architettura di un sistema operativo Dipartimento di Informatica Università di Verona, Italy Struttura di un S.O. Sistemi monolitici Sistemi a struttura semplice Sistemi a livelli Virtual Machine Sistemi

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione BANCA VIRTUALE/1 Il termine indica un entità finanziaria che vende servizi finanziari alla clientela tramite le tecnologie dell informazione e della comunicazione, senza ricorrere al personale di filiale

Dettagli

Indice. 1 Introduzione 7 1.1 Introduzione... 7 1.2 Cos è un impianto informatico enterprise... 8

Indice. 1 Introduzione 7 1.1 Introduzione... 7 1.2 Cos è un impianto informatico enterprise... 8 Indice 1 Introduzione 7 1.1 Introduzione............................. 7 1.2 Cos è un impianto informatico enterprise............. 8 2 Affidabilità 11 2.1 Introduzione............................. 12 2.1.1

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Condor-G: Un Agente per la Gestione dell Elaborazione in Multi-Institutional Grids

Condor-G: Un Agente per la Gestione dell Elaborazione in Multi-Institutional Grids Condor-G: Un Agente per la Gestione dell Elaborazione in Multi-Institutional Grids James Frey, Todd Tannenbaum, Miron Livny, Ian Foster, Steven Tuecke Condor-G Sfrutta: Security, comunicazioni, resource

Dettagli

Introduzione ai Web Services Alberto Polzonetti

Introduzione ai Web Services Alberto Polzonetti PROGRAMMAZIONE di RETE A.A. 2003-2004 Corso di laurea in INFORMATICA Introduzione ai Web Services alberto.polzonetti@unicam.it Introduzione al problema della comunicazione fra applicazioni 2 1 Il Problema

Dettagli

Sicurezza nei modelli peer-to-peer. F.Baiardi Dipartimento di Informatica, Centro Serra Università di Pisa f.baiardi@unipi.it

Sicurezza nei modelli peer-to-peer. F.Baiardi Dipartimento di Informatica, Centro Serra Università di Pisa f.baiardi@unipi.it Sicurezza nei modelli peer-to-peer Dipartimento di Informatica, Centro Serra Università di Pisa f.baiardi@unipi.it Credits Stefano Suin (unipi serra) Claudio Telmon Laura Ricci (di unipi) Paolo Mori (iit

Dettagli

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori

Appl. di emissione PKCS#11. API (Metacomandi) Resource Manager Windows. Drivers PC/SC dei lettori Roma, 30 gennaio 2003 La realtà della carta di identità elettronica (nel seguito CIE) e della carta nazionale dei servizi (nel seguito CNS) rende ineluttabile l individuazione di servizi da erogare in

Dettagli

confinamento e virtualizzazione 2006-2009 maurizio pizzonia sicurezza dei sistemi informatici e delle reti

confinamento e virtualizzazione 2006-2009 maurizio pizzonia sicurezza dei sistemi informatici e delle reti confinamento e virtualizzazione 1 oltre i permessi dei file... nei sistemi operativi standard il supporto per il confinamento è abbastanza flessibile per quanto riguarda i files scarso per quanto riguarda

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni White paper Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni Panoramica Questo documento analizza il supporto alla programmabilità nell'infrastruttura ACI (Application Centric

Dettagli

Cos'é una (Computing) GRID?

Cos'é una (Computing) GRID? Incontro Borsisti Progetto Lauree Scientifiche Perugia, 26 agosto 1 settembre 2007 Cos'é una (Computing) GRID? Istituto Nazionale Fisica Nucleare Sezione di Perugia Università Studi di Perugia Perché il

Dettagli

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On

Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Elementi di Sicurezza e Privatezza Lezione 18 Autenticazione: Single Sign On Chiara Braghin chiara.braghin@unimi.it Lab 8 Visti i problemi con la macchina virtuale e la rete, l assignment è sospeso 1 Autenticazione

Dettagli

Calcolo numerico e programmazione. Sistemi operativi

Calcolo numerico e programmazione. Sistemi operativi Calcolo numerico e programmazione Sistemi operativi Tullio Facchinetti 25 maggio 2012 13:47 http://robot.unipv.it/toolleeo Sistemi operativi insieme di programmi che rendono

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata

Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata Manuale Servizi di Virtualizzazione e Porta di Accesso Virtualizzata COD. PROD. D.6.3 1 Indice Considerazioni sulla virtualizzazione... 3 Vantaggi della virtualizzazione:... 3 Piattaforma di virtualizzazione...

Dettagli

Introduzione alla Virtualizzazione

Introduzione alla Virtualizzazione Introduzione alla Virtualizzazione Dott. Luca Tasquier E-mail: luca.tasquier@unina2.it Virtualizzazione - 1 La virtualizzazione è una tecnologia software che sta cambiando il metodo d utilizzo delle risorse

Dettagli

2006-2011 maurizio pizzonia sicurezza dei sistemi informatici e delle reti. confinamento e virtualizzazione

2006-2011 maurizio pizzonia sicurezza dei sistemi informatici e delle reti. confinamento e virtualizzazione confinamento e virtualizzazione 1 oltre i permessi dei file... nei sistemi operativi standard il supporto per il confinamento è abbastanza flessibile per quanto riguarda i files scarso per quanto riguarda

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Security by Virtualization

Security by Virtualization Metro Olografix Hacking Party Security by Virtualization 19 Maggio 2007 Pescara Marco Balduzzi Le ragioni della sfida I convenzionali meccanismi di protezione vengono alterati ed evasi

Dettagli

CRESCO. Centro computazionale di RicErca sui Sistemi COmplessi. Dipartimento di Ingegneria dell Informazione e Matematica Applicata

CRESCO. Centro computazionale di RicErca sui Sistemi COmplessi. Dipartimento di Ingegneria dell Informazione e Matematica Applicata CRESCO Centro computazionale di RicErca sui Sistemi COmplessi Dipartimento di Ingegneria dell Informazione e Matematica Applicata Università di Salerno Responsabile Unità Operativa Prof. Ciro D Apice Attività

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Architettura di un sistema operativo

Architettura di un sistema operativo Architettura di un sistema operativo Struttura di un S.O. Sistemi monolitici Sistemi a struttura semplice Sistemi a livelli Virtual Machine Sistemi basati su kernel Sistemi con microkernel Sistemi con

Dettagli

Web services. 25/01/10 Web services

Web services. 25/01/10 Web services Web services Tecnologia per il computing distribuito standard W3C non dissimile da RMI, CORBA, EJB... Relazione con il Web Websites for humans, Web Services for software :-) un Web service ha un indirizzo

Dettagli

Ambienti di calcolo a griglia - Parte 3

Ambienti di calcolo a griglia - Parte 3 TOC Ambienti di calcolo a griglia - Parte 3 Obiettivo Formativo Un software di griglia può essere installato con una certa facilità da programmatori. Al crescere dell uso e della dipendenza dell utenza,

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

Tecnologie Gnu Linux per la sicurezza della rete aziendale

Tecnologie Gnu Linux per la sicurezza della rete aziendale Tecnologie Gnu Linux per la sicurezza della rete aziendale Massimiliano Dal Cero, Stefano Fratepietro ERLUG 1 Chi siamo Massimiliano Dal Cero CTO presso Tesla Consulting Sicurezza applicativa e sistemistica

Dettagli

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security

Dettagli

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS Il modello SaaS Architettura 3D Cloud Il protocollo DCV Benefici Il portale Web EnginFrame EnginFrame

Dettagli

Corso di Web programming Modulo T3 A2 - Web server

Corso di Web programming Modulo T3 A2 - Web server Corso di Web programming Modulo T3 A2 - Web server 1 Prerequisiti Pagine statiche e dinamiche Pagine HTML Server e client Cenni ai database e all SQL 2 1 Introduzione In questa Unità si illustra il concetto

Dettagli

Infrastrutture Software

Infrastrutture Software Infrastrutture Software I componenti fisici di un sistema informatico sono resi accessibili agli utenti attraverso un complesso di strumenti software finalizzati all utilizzo dell architettura. Si tratta

Dettagli

CATALOGO CORSI DI FORMAZIONE INFORMATICA

CATALOGO CORSI DI FORMAZIONE INFORMATICA CATALOGO CORSI DI FORMAZIONE INFORMATICA La Dialuma propone a catalogo 22 corsi di Informatica che spaziano tra vari argomenti e livelli. TITOLI E ARGOMENTI I001 - Informatica generale Concetti generali

Dettagli

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali

Sistemi Operativi. Funzioni e strategie di progettazione: dai kernel monolitici alle macchine virtuali Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Funzioni e strategie di progettazione: dai kernel monolitici

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

UBUNTU: gli strumenti di condivisione risorse

UBUNTU: gli strumenti di condivisione risorse UBUNTU: gli strumenti di condivisione risorse condivisione 1o1 a cura di Danio Campolunghi La condivisione di risorse Verranno qui proposti gli strumenti grafici di serie messi a disposizione da Ubuntu

Dettagli

Architetture software

Architetture software Sistemi Distribuiti Architetture software 1 Sistemi distribuiti: Architetture software Il software di gestione di un sistema distribuito ha funzionalità analoghe ad un sistema operativo Gestione delle

Dettagli

Sistemi Distribuiti. Libri di Testo

Sistemi Distribuiti. Libri di Testo Sistemi Distribuiti Rocco Aversa Tel. 0815010268 rocco.aversa@unina2.it it Ricevimento: Martedì 14:16 Giovedì 14:16 1 Libri di Testo Testo Principale A.S. Tanenbaum, M. van Steen, Distributed Systems (2

Dettagli

Il middleware INFNGRID Certification Authority Virtual Organization Servizi core Servizi collective Servizi di supporto al deployment e per la

Il middleware INFNGRID Certification Authority Virtual Organization Servizi core Servizi collective Servizi di supporto al deployment e per la Architettura del middleware INFNGRID e piano di deployment sull'infrastruttura SCoPE Gennaro Tortone INFN Napoli 21 febbraio 2007 Indice Il middleware INFNGRID Certification Authority Virtual Organization

Dettagli

Come funziona un sistema di elaborazione

Come funziona un sistema di elaborazione Introduzione Cosa è un Sistema Sste aoperativo? Come funziona un sistema di elaborazione Proprietà dei Sistemi Operativi Storia dei Sistemi di Elaborazione Sistemi Mainframe Sistemi Desktop Sistemi i Multiprocessori

Dettagli

Virtualizzazione di macchine Linux tramite XEN

Virtualizzazione di macchine Linux tramite XEN 26 Novembre 2005 Struttura Introduzione alla virtualizzazione Cos è la virtualizzazione La virtualizzazione è un processo di astrazione in cui alcune risorse a livello più basso vengono presentate in maniera

Dettagli

Analisi di prestazioni di applicazioni web in ambiente virtualizzato

Analisi di prestazioni di applicazioni web in ambiente virtualizzato tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Porfirio Tramontana correlatore Ing. Andrea Toigo in collaborazione con candidato Antonio Trapanese Matr. 534/1485 La virtualizzazione è un

Dettagli

3 Capitolo primo Informatica e calcolatori

3 Capitolo primo Informatica e calcolatori I n d i c e 3 Capitolo primo Informatica e calcolatori 7 Capitolo secondo La rappresentazione delle informazioni 11 2.1 La codifica dei caratteri 2.1.1 Il codice ASCII, p. 11-2.1.2 Codifiche universali,

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009)

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) CeBAS Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) Introduzione Il progetto CEBAS: la finalità è di migliorare l efficienza operativa interna dell Ente rispondere alle aspettative

Dettagli

La genealogia di Windows. Windows NT e Windows 95/98. Dimensioni del codice. Parte IX. Windows

La genealogia di Windows. Windows NT e Windows 95/98. Dimensioni del codice. Parte IX. Windows La genealogia di Windows Parte IX Windows Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1 DOS: sistema operativo monoutente Windows 3.1 interfaccia a finestre che gira su DOS Windows 95/98

Dettagli

Parte IX. Windows. Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1

Parte IX. Windows. Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1 Parte IX Windows Sistemi Operativi - prof. Silvio Salza - a.a. 2008-2009 IX - 1 La genealogia di Windows DOS: sistema operativo monoutente Windows 3.1 interfaccia a finestre che gira su DOS Windows 95/98

Dettagli

Applicazioni per l autenticazione Sicurezza nelle reti di TLC - Prof. Marco Listanti - A.A. 2008/2009

Applicazioni per l autenticazione Sicurezza nelle reti di TLC - Prof. Marco Listanti - A.A. 2008/2009 Applicazioni per l autenticazione Kerberos Kerberos Servizio di autenticazione sviluppato dal MIT Fornisce un server di autenticazione centralizzato Basato su crittografia simmetrica (chiave privata) Permette

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

Introduzione ad Active Directory. Orazio Battaglia

Introduzione ad Active Directory. Orazio Battaglia Introduzione ad Active Directory Orazio Battaglia Introduzione al DNS Il DNS (Domain Name System) è un sistema utilizzato per la risoluzione dei nomi dei nodi della rete (host) in indirizzi IP e viceversa.

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

Interoperabilità e cooperazione applicativa tra sistemi informativi

Interoperabilità e cooperazione applicativa tra sistemi informativi Interoperabilità e cooperazione applicativa tra sistemi informativi Michele Ruta Dipartimento di Ingegneria Elettrica e dell Informazione Politecnico di Bari 1di 29 Indice Introduzione ai Port Community

Dettagli

8. Sistemi Distribuiti e Middleware

8. Sistemi Distribuiti e Middleware 8. Sistemi Distribuiti e Middleware Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 32 Sommario 1 Sistemi distribuiti

Dettagli

3. PRODOTTI PER LA VIRTUALIZZAZIONE

3. PRODOTTI PER LA VIRTUALIZZAZIONE 3. PRODOTTI PER LA VIRTUALIZZAZIONE In questo capitolo verranno descritti alcuni dei prodotti commerciali e dei progetti opensource più noti; in particolare verrà presa in considerazione la soluzione SUN

Dettagli

The Design and Implementation of a Transparent Cryptographic Filesystem for UNIX

The Design and Implementation of a Transparent Cryptographic Filesystem for UNIX The Design and Implementation of a Transparent Cryptographic Filesystem for UNIX Ciro Amati, Stefania Cardamone Universitá degli Studi di Salerno December 5, 2014 1 / 47 Introduzione Conoscenze scientifiche

Dettagli

Soluzioni di firma remota. con PkBox

Soluzioni di firma remota. con PkBox Soluzioni di firma remota con PkBox 18 aprile 2013 Le informazioni contenute in questo documento sono da considerarsi CONFIDENZIALI e non possono essere utilizzate o riprodotte - sia in parte che interamente

Dettagli

Approccio stratificato

Approccio stratificato Approccio stratificato Il sistema operativo è suddiviso in strati (livelli), ciascuno costruito sopra quelli inferiori. Il livello più basso (strato 0) è l hardware, il più alto (strato N) è l interfaccia

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

REQUIREMENTS. http://www.liveboxcloud.com

REQUIREMENTS. http://www.liveboxcloud.com 2014 REQUIREMENTS http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di

Dettagli

i5/os per processi di business efficienti e flessibili

i5/os per processi di business efficienti e flessibili L ambiente operativo integrato leader nel settore i5/os per processi di business efficienti e flessibili Caratteristiche principali Middleware integrato per processi di business efficienti. Funzioni integrate

Dettagli

Sistemi in grado di gestirsi in modo autonomo e dinamico La strategia di virtualizzazione di Microsoft

Sistemi in grado di gestirsi in modo autonomo e dinamico La strategia di virtualizzazione di Microsoft Disponibile anche sul sito: www.microsoft.com/italy/eclub/ OTTIMIZZAZIONE DELL INFRASTRUTTURA E SICUREZZA MICROSOFT Sistemi in grado di gestirsi in modo autonomo e dinamico La strategia di virtualizzazione

Dettagli

Fisciano, 24 ottobre 2008

Fisciano, 24 ottobre 2008 Virtualizzazione applicazioni per la sicurezza Luigi Catuogno Fisciano, 24 ottobre 2008 Sommario Virtualizzazione e para-virtualizzazione Sicurezza Separazione delle applicazioni Virtual data center Trusted

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

GoCloud just google consulting

GoCloud just google consulting La visione Cloud di Google: cosa cambia per i profili tecnici? GoCloud just google consulting Workshop sulle competenze ed il lavoro degli IT Systems Architect Vincenzo Gianferrari Pini

Dettagli