La clessidra di Globus
• Focus su problemi architetturali
Applicazioni
– Propone un insieme di servizi di base
Diversi servizi globali
come nucleo dell’infrastruttura
– Utilizzo per la costruzione di
soluzioni ad alto livello
Servizi di
• Principi progettuali
– Permettere il controllo locale
– Supporto per l’adattatività
– Modello “IP hourglass”
base
Globus
SO locali
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 2119. 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 server
GRAM client
PROXY
Job
request
GSI
GATEKEEPER
JOB
MANAGER
JOB
MANAGER
JOB
MANAGER
RSL
GASS
LOCAL
RESOURCE
MANAGER
FIle_stage_in, out
GASS
Process
Process
Process
DUROC
Quando è necessario allocare più risorse contemporaneamente è necessario un
coallocatore che smisti le richieste alle varie risorse, scomponendo le richieste e
riassemblando il risultato.
DUROC
Local
resource
managers
GRAM
GRAM
GRAM
LSF
Condor
PBS
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