La clessidra di Globus Focus su problemi architetturali –Propone un insieme di servizi di base come nucleo dell’infrastruttura –Utilizzo per la costruzione di soluzioni ad alto livello Principi progettuali –Permettere il controllo locale –Supporto per l’adattatività –Modello “IP hourglass” SO locali Diversi servizi globali Servizi di base Globus Applicazioni

Globus Toolkit Esistono varie versioni del Globus Toolkit –GT2.4, GT3.0 GT3.2 sono le ultime Cominciamo con GT2.4 –si basa su quattro moduli Security Resource Management Information Service Data Management

Servizi di base del Globus Toolkit Sicurezza (GSI) Gestione delle risorse (GRAM) Servizi di informazione (GIS) Gestione dei dati (GASS, GridFTP, GRM) Comunicazione (I/O, Nexus)

GT2: Protocolli Chiave Il Globus Toolkit v2 è basato su quattro protocolli chiave Collective layer –Security: Grid Security Infrastructure (GSI) Resource layer –Resource management: Grid Resource Allocation Management (GRAM) –Information Service: Monitoring and Discovery Service (GRIP) –Data Transfer: Grid File Transfer Protocol (GridFTP) Anche protocolli chiave del collective layer –Info Services, Replica Management, etc

Globus Toolkit 2 La visione d’insieme

Resource Management GRAM (Globus Resource Allocation Manager) È il componente di più basso livello del modulo Sistema di tipo client-server Permette di eseguire programmi su risorse remote DUROC (Dynamically-Updated Request Online Coallocator) Co-allocatore di richieste GASS (Globus Access to Secondary Storage) Accesso a file remoti

GRAM Permette di eseguire i job in remoto Interpreta le richieste in linguaggio RSL Permette di monitorare lo stato dei job Aggiorna l’Information Service Fornisce un’interfaccia comune per l’interazione con i sistemi di gestione locali

GRAM: il server Sul server agisce il Gatekeeper, in ascolto sulla porta E’ un processo di root avviato dal demone xinetd solo all’arrivo di una richiesta. I suoi compiti sono: –Mutua autenticazione con il proxy del client –Mappa client in un utente locale (gridmap-file) –Istanzia Job-manager con diritti utente locale, passando gli argomenti necessari ai processi

GRAM: il server Il Job Manager avvia processi del job interfacciandosi con il sistema locale e comunica lo stato dei processi all’esterno. I suoi compiti sono –Parsing RSL –Interfacciamento con il sistema locale –Comunicazione diretta con il client per stato dei processi

GRAM GRAM client PROXY GRAM server GATEKEEPER GASS GSI GASS RSL LOCAL RESOURCE MANAGER JOB MANAGER JOB MANAGER JOB MANAGER Process Job request FIle_stage_in, out

GRAM LSFCondorPBS Local resource managers DUROC Quando è necessario allocare più risorse contemporaneamente è necessario un coallocatore che smisti le richieste alle varie risorse, scomponendo le richieste e riassemblando il risultato. Il gram-reporter si occupa di aggiornare l’Information Service con le informazioni riguardo le risorse utilizzate.

GASS Quest’utility semplifica lo spostamento di file necessari ad un eseguibile Elimina il bisogno di:  effettuare il login su ogni risorsa sulla quale è presente un file necessario e trasferirlo tramite FTP  installare un filesystem distribuito Mette a disposizione un protocollo tramite il quale accedere alle risorse remote

Information Service La natura dinamica del GRID implica che le applicazioni devono essere in grado di adattarsi ai cambiamenti dei componenti Il Globus Metacomputing Directory Service (MDS) supporta questo fornendo un’informazione continuamente disponibile ed aggiornata sui componenti, quali:  architettura, tipo e versione di SO, quantità di memoria  larghezza di banda e latenza  …

Information Service GRIS (grid resource information service): Database LDAP che risiede su una risorsa e provvede a raccoglierne tutte le caratteristiche dinamiche e permanenti GIIS (grid index information service) Server di livello superiore che contiene le informazioni relative a diversi GRIS. Gerarchia di GIIS server IP (information provider) Componente che risiede sulla risorsa e viene consultato da un GRIS quando ha bisogno di informazioni su un aspetto di essa, puo’ essere personalizzato

Information Service

Lungo la via La base eterogenea di protocolli era troppo complessa (LDAP, GRAM, GridFTP,…) I servizi base non bastavano più: troppi nuovi servizi troppo complessi da gestire Comparsa dei Web Services (WSDL, SOAP)…che però non bastano per realizzare una base comune di servizi Grid!

Evoluzione del GT2 nel GT3 Cosa è successo ai protocolli base del GT2? –Sicurezza: adattamento dei certificati proxy X.509 per l’integrazione degli standard dei WS –LDAP: integrato come astrazione di serviceData –GRAM: ManagementJobFactory e relativi servizi –GridFTP: immutato nel GT3, ma evolverà Realizzazione di servizi collettivi in termini di OGSI: Reliable File Transfert, Replica Location Service, etc

OGSA ed il GT Tecnicamente, OGSA permette di: –Riscrivere i protocolli (GRAM, MDS, GridFTP), conservando tutti i principi base del GT –Integrazione di molti hosting environment: componentizzazione, distribuzione, etc –Insieme di servizi standard Praticamente, il Globus Project procede così: –Sviluppo di un’implementazione OGSA open source –Partnership con varie istituzioni per lo sviluppo dei servizi (OGSA-DAI) –Verifica dell’interesse delle industrie

GT3 Core

GT3 Core - OGSI Specification La specifica definisce come le entità possono creare, scoprire ed interagire con un Grid Service

GT3 Core - OGSI Specification GT3 include un insieme di primitive che implementano interfacce e comportamenti definiti dall’ultima versione delle specifiche OGSI L’implementazione supporta programmazione di tipo dichiarativo in cui un utente GT3 può comporre Grid Service utilizzando le primitive che desiderano nel loro codice

GT3 Core - OGSI Specification GridService portType definisce il comportamento fondamentale di un Grid Service –Introspezione –Scoperta –Gestione del ciclo di vita “soft state” Necessario in base alle specifiche

GT3 Core - OGSI Specification Factory portType Le factory creano i servizi Le factory sono tipicamente servizi persistenti La factory è un’interfaccia OGSI opzionale (I Grid Service possono essere istanziati anche con altri meccanismi)

GT3 Core - OGSI Specification Notification portType Una sottoscrizione al notification crea un NotificationSubscription service NotificationSink non sono richieste per implementare la GridService portType Notifiche possono essere associate ai service Data Element Le Notification portType sono opzionali

GT3 Core - OGSI Specification Service group portType Un ServiceGroup è un Grid service che mantiene informazioni su un gruppo di Grid services Il modello classico del registro può essere implementato tramite ServiceGroup portType Un Grid service può appartenere a più di un ServiceGroup I membri di un ServiceGroup possono essere omogenei o eterogenei ServiceGroup portType è un’interfaccia OGSI opzionale

GT3 Core - OGSI Specification HaldleResolver portType Definisce un meccanismo per risolvere un GSH in un GSR –Un GSH punta ad un Grid Service –Un GSR specifica come comunicare con il Grid Service HandleResolver portType è un’interfaccia OGSI opzionale