Post on 11-Jun-2020
transcript
Introduzione alle griglie computazionali - a.a. 2006-07 1
LEZIONE N. 2LEZIONE N. 2
• Sistemi distribuiti• Architettura di Grid• Generalità su livelli, protocolli e servizi di Grid
Introduzione alle griglie Introduzione alle griglie computazionalicomputazionali
Università degli Studi di Napoli Federico IICorso di Laurea in Informatica – III Anno
2
Che cosa Che cosa èè un sistema distribuito ?un sistema distribuito ?
E’ un sistema di molti processori distribuiti su rete locale o geografica, interconnessi tra loro, accessibili agli utenti nelmodo più trasparente possibile e capaci di cooperare tra loro alla soluzione di un problema (ad es. un’applicazione dell’utente).
Mass storagecondiviso
Cluster di PC
Utenti
Esempio
R e t e
3
““ ProPro”” e e ““ ControContro”” di un sistema distribuitodi un sistema distribuitorispetto a rispetto a MainframesMainframes o a PC indipendentio a PC indipendenti
Vantaggi:• Basso costo in rapporto alle prestazioni.• Potenza integrata scalabile.• Reti a banda larga e affidabili (100 Mb/s – 10 Gb/s).• Distribuzione delle risorse di calcolo su più sedi (es. banche,
aziende, industrie, istituzioni scientifiche, università).• Affidabilità dell’intero sistema (riduzione dei single points of
failure).• Condivisione di dati su più sedi (es. database comuni).• Lavoro collaborativo (es. video e audio conferenza, e-mail, web).Problemi:• Gestione “globale” e “controllata”.• Riservatezza e Sicurezza delle informazioni.• Disaster Recoverysu scala geografica.
4
Classificazione di un computer (Classificazione di un computer (FlynnFlynn, 1972), 1972)
SISD: Single Instruction Single Data(es. monoprocessori tradizionali).
SIMD: Single Instruction Multiple Data(es.array processors dove una singola instruzioneattiva il processamento parallelo di molti dati).
MISD: Multiple Instruction Single Data(nessun sistema attuale).
MIMD : Multiple Instruction Multiple Data(es. sistemi distribuiti e sistemi paralleli).
5
Struttura di un computer SISDStruttura di un computer SISD
MemoriaPrincipale(RAM)
ControlArithmeticand Logic
R0R1…Rn
General purposeregisters
ProgramCounter
CPUstatus
CPUUnità di Input e di Output
Memory bus
CacheMemory
Input e Output bus
6
Esecuzione di una istruzione
Prende l’istruzione dalla memoria all’indirizzo del PC e incrementa il PC (Program Counter)
Decodifica l’istruzione (determina il tipo di istruzione)
Carica sui registri gli operandi specificati dall’istruzione
Esegue l’operazione specificata dall’istruzione
Memorizza i risultati
7
P C I
Bus Adapter
Periferiche di I/O
ControlArithmeticand Logic
R0R1…Rn
General purposeregisters
ProgramCounter
CPUstatus
I/O bus Bus Adapter
Periferiche di I/O
I/O bus
Memoria RAM
Struttura a multi-bus
8
Multi-processors(shared memory)
Multi-computers(private memory)
Bus Switched
(es.UltracomputerRP3, APE)
Loosely coupled
Tightlycoupled
Livello di condivisionedelle risorse
Classificazione dei sistemi MIMDClassificazione dei sistemi MIMD
(es.PC su una LAN) (es.Hypercube, Transputer)
Bus Switched
9
Bus-basedMulti-processors
Memoriacondivisacache
CPU
cache
CPU
cache
CPU
bus
• High speed backplane (motherboard):basso delay e alta velocità, basato su un bus che normalmente ha 32 linee per i dati, 32 per l’indirizzo e 20 o 30 per ilcontrollo; tutte queste linee operano in parallelo.
• Memoria Coerente:tutte le CPU vedono gli stessi dati.
• Memoria Cache:per aumentare l’efficienza delle cpu, contiene i dati piu’ recenti e ha un accesso piu’ rapido del bus. (problema dell’aggiornamento della cache).
10
SwitchedMulti-processors
• Crossbar switch:elemento a matrice al posto del bus per metterein comunicazione contemporaneamente le CPU con elementi di memoria diversi.
• Vantaggio:sistemi con molte centinaia di processori.
• Problema:ridurre i tempi di accesso CPU-Memoria.
CPU
CPU
CPU
M M M
11
Bus-basedMulti-computers
PC o workstations su Local Area Nnetwork
• No shared memory.
• cpu-to-cpu communications:il volume dei dati da scambiarediminuisce e comunque e’ meno critico per l’efficienza delle cpu.
• LAN su bus o anello o matrice di switch.
cache
CPU
M cache
CPU
M cache
CPU
M cache
CPU
M
12
Dal punto di vista dei Sistemi OperativiDal punto di vista dei Sistemi Operativi
cpu tightly coupled: occorre gestire la memoria condivisa.
cpu loosely coupled:occorre disporre di network operatingsystemsin grado di eseguire:
• operazioni distribuite a bassa condivisione di risorse (es.loginremoto, file transfer).
• operazioni distribuite ad alta condivisione di risorse (es. file server e job manager).
13
Shared Memory
cache
CPU 1
cache
CPU 2
cache
CPU 3
bus
Esempio di tightly coupled SW su tightly coupled HW: Multiprocessor Operating System Multiprocessor Operating System (memoria condivisa)
Processo A Processo B Processo C
A runningB runningC runningD, E ready
Run Queue D,EOp. Syst.
• Una sola coda di run nella memoria condivisa.• Quando una CPU e’ libera carica un processo ready.
• Potenza di calcolo = 3* potenza di una cpu.
14
L A N
cache
CPU
M cache
CPU
M cache
CPU
M
File Server
export/dati/grafici/source(File server condiviso)
mount /etc/fileserver/dati/grafici/source /usr/pippo/grafici
Esempio di loosely coupled SW su loosely coupled HW: Network Operating System Network Operating System (file condivisi)
15
L A N
cache
CPU
M cache
CPU
M cache
CPU
M
File Server
Submit job LSF, PBS, …Job Manager
Run job
16
Problema:
Controllo centralizzato, mancanza di coordinameno per l’esecuzione dei processi e scarsa interazione tra i sistemi componenti.
Soluzione:
SistemaSistemaoperativooperativo distribuitodistribuito :: tightly-coupled SW su loosely-coupled HW come se fosse un singolo sistema invece che una collezione di singoli sistemi.
17
sinonoC’e’ una sola coda di run?
nosisiDevono concordare i protocolli di rete?
shared memory
messagesshared files
Come comunicano?
1nnQuante copie di OS?
sisi-nonoDeve avere lo stesso sistema
operativo?
sisinoAppare come un unicouniprocessore virtuale?
NetworkOperatingsystem
Distributed Operatingsystem
Multiprocessor Operatingsystem
Confronto tra vari sistemi distribuitiConfronto tra vari sistemi distribuiti
18
Obiettivi da raggiungere:
• Meccanismo unico di comunicazione fra i processi.
• Schema unico di protezione globale (Security).
• Unica gestione dei processi (Process management).
• Unico meccanismo di accesso ai dati (Data management).
• Sistema informativo globale (Information system).
• Autonomia di utilizzo delle risorse locali.
19
Requisiti di un sistema distribuitoRequisiti di un sistema distribuito
Trasparenza: Il sistema deve apparire come un sistema singolo. Si puo’ ottenere a due livelli:
• Trasparente all’utente, comandi invariati (shell)
• Trasparente al programma, system call interfaceindipendente dal numero di processori.
Activities can happen in parallel without users knowing
Parallelism transparency
Multiple users can share resources automatically
Concurrency transparency
The users cannot tell how many copies exist
Replication transparency
Resources can move at will without changing their names
Migration transparency
The user can not tell where resources are located
Location transparency
20
Flessibilità:Adattabilità a nuove esigenze.
Due tendenze:
• Macchina con kernel tradizionale (monolithic kernel) che esegue molti
servizi (a).
• Macchina con microkernel, che esegue un ridotto numero di servizi (Interprocess communication mechanism, Memory management, Low-level process management and scheduling, Low-level input/output) e il grosso dei servizi di un OS viene fornito da user-level server (b).
user
monolithickernel
File server
microkernel
Process server user
(a) (b)
microkernel microkernel
21
Affidabilità ( reliability):Caratteristica intrinseca del sistema distribuito: se una macchina ha problemi
il job può andare su altre.
Efficienza (performance):Parametri di efficienza (performance metrics):
• Response time.
• Throughput (numero di job in un’ora, strettamente dipendente dal tipo di job: cpu bound o I/O bound).
• Uso di banda trasmissiva sulla rete.
Granularita’ del calcolo (grain size):
• Fine-grain parallelism(difficile per un SD).
• Coarse-grain parallelism (si adatta meglio a un SD).
Scalabilità:
L’espandibilità è un requisito fondamentale di un sistema distribuito.
22
CHE COSA ECHE COSA E’’ UNA GRID ?UNA GRID ?
Si parla di molti tipi di griglie computazionali: Science Grid, Bio Grid, Campus Grid, Data Grid, Sensor Grid,Cluster Grid, ecc.
(In passato, analoga confusione di termini: SNA, DECNET erano parte di Internet o no ? Chiarimento: architettura basata su IP (Internet Protocol).
� Necessità di una definizione di GRID non ambigua !
1969 (Len Kleinrock) –Analogia con le reti elettriche e telefoniche.“We will probably see the spread of ‘computer utilities’, which, like present electric and telephone utilities, will service individual homes and offices across the country”.
23
1998 (Ian Foster e Carl Kesselman) –“A computational grid is a hardware and software infrastructure that providesdependable, consistent, pervasive and inexpensive access to high-end computational capabilities”.
2000 (Ian Foster, Carl Kesselman e Steve Tuecke) –Grid computing is concerned with “coordinated resourcesharing and problemsolving in dynamic, multi-istitutional virtual organizations”.
Punti chiave:
• Capacità di negoziare secondo regole stabilite la condivisione di risorse (computers, software, dati, ecc.) da parte di organizzazioni o istituzioni (scientifiche, industriali, governative, ecc.) cheagiscono da Virtual OrganizationsVirtual Organizations.
• Importanza di definire protocolli standard per consentire la interoperabilità e realizzare una infrastruttura comune .
24
DEFINIZIONE DI GRID IN 3 PUNTIDEFINIZIONE DI GRID IN 3 PUNTI
GRID è un sistema che:
1) Coordina risorse che non devono essere soggette ad alcun controllo centralizzato.
(es. PC desktop personali, nodi di calcolo e database di istituzioni sparse su territorio nazionale e nel mondo, senza lanecessità del controllo tipico di un sistema a gestione locale, pur garantendo la sicurezza e la realizzazione delle politiche di utilizzo all’interno di un’organizzazione virtuale).
25
2) Usa protocolli e interfacce standard, open, general-purpose.
(essenziali per assicurare in modo trasparente funzionalità di base quali autenticazione, autorizzazione, ricerca e accesso alle risorse).
3) Assicura un’elevata qualità di servizio (QoS -Quality of Service).
(es. tempi di risposta, throughput, disponibilità, sicurezza, co-allocazione di risorse).
26
Non sono GRID (ad esempio):
a) Un sistema di gestione di code batch che utilizzano le CPU di un computer multi-processore o di computer inseriti in un cluster o su una LAN: c’è controllo centralizzato delle risorse e conoscenza completa dello stato del sistema.
b) Il Web: benché usi protocolli standard, aperti e general-purpose, manca l’uso coordinato delle risorse per assicurare la migliore QoS.
Sono approssimativamente GRID (ad esempio):
c) I sistemi di schedulers multi-site(es. Condor, Entropia) o di database federati (es. Storage Resource Broker) che distribuiscono risorse in modo non centralizzato e assicurano seppur limitate QoS, pur non basandosi completamente su standards.
27
Sono GRID (ad esempio):
I progetti di “Data Grid” per il calcolo intensivo e distribuito in ambito accademico e scientifico in EU (EDG, CrossGRID, Data Tag, LCG, EGEE), in USA (GriPhyN, PPDG, iVDGL) e in Asia (ApGrid) e molti altri ancora.
Essi si propongono di:
• Integrare risorse anche non omogenee appartenenti a molte istituzioni che conservano in ogni caso le loro politiche di utilizzo. Accesso on-demandalle risorse.
• Usare protocolli aperti, standard e general-purpose per la gestione delle risorse (ad es. il Globus Toolkit, l’EDG Toolkit, l’Open GridService Architecture- OGSA).
• Garantire qualità di servizio in vari settori (sicurezza, affidabilità, prestazioni, ecc.).
28
IL PROBLEMA GRIDIL PROBLEMA GRID
Realizzare la condivisione coordinata di risorse su larga scalaRealizzare la condivisione coordinata di risorse su larga scalain un contesto di organizzazione virtuale, multiin un contesto di organizzazione virtuale, multi--instituzionaleinstituzionalee dinamicae dinamica..
Occorre una nuova architettura che:
• identifichi le componentiprincipali del sistema.• specifichi lo scopoe la funzionedi queste componenti.• indichi come queste componenti interagiscono fra di loro.• definisca servizi e protocolli comuni per garantire
l’ interoperabilità attraverso la rete (flessibilità di aggiungere nuovi utenti, servizi e piattaforme hw/sw in modo dinamico) e costituire così un sistema aperto.
Per rendere usabile la Grid, occorre anche sviluppare Application Programming Interfaces - API (insieme di routines per facilitare lo sviluppo di applicazioni) e Software Development Kits- SDK (particolare istanza di un API).
29
PROTOCOLLO:PROTOCOLLO:Insieme di regole e formati per lo scambio di Insieme di regole e formati per lo scambio di informazioni.informazioni.
Protocolli standard sono fondamentali per assicurare l’interoperabilità.Esempi:
• Internet Protocol (IP): trasferimento di pacchetti senza garanzia di affidabilità.
• Transmission Control Protocol (TCP):costruito su IP per definire un protocollo affidabile.
• Transport Layer Security Protocol (TLS): costruito su TCP, garantisce sicurezza e integrità dei dati.
• Lightweight Direct Access Protocol (LDAP):costruito su TCP, èun protocollo per l’accesso a directories (anche database).
DEFINIZIONIDEFINIZIONI
30
SERVIZIO: protocollo + funzione.SERVIZIO: protocollo + funzione.CapacitCapacit àà di svolgere una funzionalitdi svolgere una funzionalit àà sulla retesulla rete(ad es. muovere files, creare processi, verificare diritti di accesso). Un servizio è definito in base alla funzione che svolge ed al protocollo che “parla”.
Esempi:• FTP server: parla il File Transfer Protocol e gestisce l’accesso in
lettura e scrittura di files remoti. Opera il trasferimento di pacchetti senza garanzia di affidabilità.
• LDAP server: parla il protocollo LDAP e supporta le risposte alle interrogazioni (ad es. usando informazioni presenti in un database).
Più servizi possono parlare lo stesso protocollo: ad es. nel Globus Toolkit il Replica Catalog(RC) e l’Information Service (IS) usano entrambi LDAP.
31
L’ARCHITETTURA GRIDLL ’’ ARCHITETTURA GRIDARCHITETTURA GRIDSi tratta di un modello a strati (layers).Il modello di riferimento è la clessidra(hourglass):
• Il centro (neck) della clessidra definisce un piccolo insieme di astrazioni di base (core) e di protocolli (servizi di base).
• La parte superiore contiene high level services (o behaviors) che si basano sui servizi e protocolli sottostanti.
• La parte inferiore contiene le risorse della grid.
32
33
Fabric
Connectivity
Resource
Collective
Application
34
Fornisce le risorse per l’accesso condiviso da parte della Grid.Ad esempio:
• Risorse computazionali• Sistemi di storage• Cataloghi• Risorse di rete• Sensori
Le risorse devono assicurare un meccanismo di enquiry che consenta di scoprire la loro struttura, lo stato e la loro capacitàed un meccanismo di managementper il controllo della qualità del servizio offerto.
FABRIC Layer: Interfacce per il controllo locale
FABRIC FABRIC LayerLayer: : Interfacce per il controllo localeInterfacce per il controllo locale
35
Definisce i protocolli base per la comunicazione e l’autenticazione.
I protocolli di comunicazione abilitano lo scambio deidati fra le risorse del fabric layer e si basano sui protocolli dell’architettura Internet (IP, TCP, UDP, DNS, RSVP).
I protocolli di autenticazione sono costruiti sui servizidi comunicazione per fornire meccanismi crittograficisicuri per verificare l’identità di utenti e risorse.
CONNECTIVITY Layer: Comunicazione facile e sicura
CONNECTIVITY CONNECTIVITY LayerLayer: : Comunicazione facile e sicuraComunicazione facile e sicura
36
I protocolli di autenticazione devono avere le seguenti caratteristiche:
• Single sign on: l’utente si deve autenticare una volta sola.• Delegation: propagazione delle credenziali ai programmi• Integration with local security: non sostituiscono ma si mappano nell’environment locale.• User-based trust relationships: il sistema di security nondeve richiedere che i sistemi di security locali interagiscano tradi loro per configurare l’ambiente di sicurezza.
Il Globus Toolkit usa i protocolli GSI (Grid SecurityInfrastructure) per l’autenticazione (certificati con formato X.509), la protezione della comunicazione (estende i protocolli di TLS - Transport Layer Security) e l’autorizzazione.
37
Definisce i protocolli per negoziare, iniziare, monitorare, controllare, addebitare l’utilizzo di risorse singole, cioè non distribuite.
Questi protocolli utilizzano funzioni del Fabric peraccedere e controllare risorse locali.Due classi principali di protocolli dello strato Resource:
• Information protocols , per ottenere informazioni sulla configurazione e lo stato di una risorsa.
• Management protocols , per negoziare l’accesso alla risorsa condivisa.
RESOURCE Layer: Condivisione di risorse singole
RESOURCE RESOURCE LayerLayer: : Condivisione di risorse singoleCondivisione di risorse singole
38
Il Globus Toolkit usa protocolli standard:
• GRIP (Grid Resource Information Protocol), basato su LDAP per definire uno standard resource information protocole il relativo information model.
• GRRP (Grid Resource Registration Protocol), per registrare le risorse.
• GRAM (Grid Resource Access Management), basato su HTTP, per l’allocazione delle risorse di calcolo e per il monitoring e il controllo del calcolo su queste risorse. GRAM utilizza il linguaggio RSL (Resource Specification Language)per la specifica delle richieste.
• GridFTP (Grid File Transfer Protocol), basato su FTP, per l’accesso ai dati; ha funzionalità estese rispetto a FTP (usa i protocolli di sicurezza dello strato Connectivity, gestisce una sorta di parallelismo per i trasferimenti ad alta velocità, ecc.).
• LDAP (Lightweight Directory Access Protocol), per l’accesso a directories.
39
A ciò si aggiungono client-sideAPI, server-sideAPI e SDK e inoltre servizi quali: GIIS (Grid Index Information Service); GIS (Grid Information Service); GRIS(Grid Resource Information Service). GSS(Generic Security Service).
L’ Information Service ha un ruolo fondamentale nella grid perché sta alla base del resource discovery e del decision making.
40
41
Definisce protocolli e servizi (e API e SDK) che non sono associati a una singola risorsa ma a una collezione di risorse. Essi si basano sui protocolli definiti nel Resourcee nel Connectivity layer. Quindi possono implementare una vasta gamma di servizi senza porre nuovi requisiti sulle risorse condivise.
Esempi di servizi:
� Directory services: consentono ai membri di una VO di identificare le risorse a disposizione della VO. Utilizzano i protocolli GRRP e GRIP.� Co-allocation, scheduling and brokering services: consentono ai membri di una VO di richiedere e schedulare l’allocazione di una o più risorse (es. Condor-G).� Monitoring and diagnostics services: consentono il monitoraggio delle risorse di una VO, inclusi gli attacchi (intrusion detection).� Data replication services: consentono la gestione ottimizzata delle risorse distorage di una VO per massimizzarne le prestazioni (tempi di risposta, affidabilità, ecc.).
COLLECTIVE Layer: Coordinamento di collezioni di risorse
COLLECTIVE COLLECTIVE LayerLayer: : Coordinamento di collezioni di risorseCoordinamento di collezioni di risorse
42
� Grid-enabled programming systems: consentono l’utilizzo di modelli di programmazione utili in ambienti Grid per l’implementazione dei vari servizi Grid (es. Message Passing Interface).� Workload management systems and collaboration frameworks: chiamati anche PSE (Problem Solving Environments) per l’utilizzo e la gestione dei carichi di lavoro in ambienti collaborativi.� Software discovery services: consentono di scegliere software e piattaforme adatte per il problema specifico da risolvere (es. NetSolve).� Community authorization servers: consentono di gestire le politiche di accesso alle risorse di una comunità in modo da renderle fruibili all’utente.� Community accounting and payment services: consentono di raccogliere informazioni sull’utilizzo delle risorse ai fini di resoconti, pagamenti, limitazioni di uso.� Collaboratory services: consentono lo scambio di informazioni all’interno di vaste comunità di utenti (es. CavernSoft).
Il Globus Toolkit utilizza i servizi di cui sopra e altri, fra cui MDS (Meta Directory Service)per la gestione informativa delle risorse.
43
APPLICATIONS Layer APPLICATIONS APPLICATIONS Layer Layer
Comprende le applicazioni degli utenti appartenenti ad una Virtual Organization.Le applicazioni sono costruite sulla base dei servizi definiti in ciascuno strato.
44
45
46
Middleware INFNGRIDMiddleware INFNGRID
� Servizi “core” (presenti in ciascun sito)� Repository pacchetti del middleware
(YAIM - INFNGRID 3.0.0 - Scientific Linux CERN 3.x - Istallazione e aggiornamenti automatici via PXE – Framework Globus 2.x)
� Servizi di computing
(Computing Element � gestione dei Worker Node – Servizi Globus: globus-gatekeeper, globus-gridftp, GRIS – Batch system: PBS, Torque, LSF)
� Servizi di storage
(Storage Element � gestione dello storage – Servizi Globus: globus-gridftp, GRIS)
� User Interface
(sottomissione di job, visualizzazione stato di un job, cancellazione di un job, recupero dell'output di un job, via remota SSH o web GENIUS)
Piena compatibilità con il m/wEGEE (gLite/LCG) con releasee aggiornamenti frequentie controllati centralmente.
48
� Servizi “collective” (gestiti centralmente)
� Servizi di autenticazione/autorizzazione
(VOMS - Virtual Organization Membership Service)
� Servizi di allocazione dei job
(Resource Broker – allocazione job via matchmaking con le risorse)
� Servizi informativi
(GRIS Grid Resource Information Service � Information Index
� Cataloghi di file / repliche
(LFC LCG File Catalog � localizzazione dei dati, copia dei dati, gestione e replica dei dati, gestione dei meta-dati, MySQL)
� User interface
49
� Servizi aggiuntivi di supporto e gestione
dell’infrastruttura
� Certification Authority
(Certificati personali e server di una Registration Authority locale)
� Servizi di Monitoring
(GridIce � monitoring delle risorse, SAM Service Availability Monitoring �monitoring dei servizi)
� Servizi di Accounting
(DGAS - Distributed Grid Accounting: le informazioni sono raccolte in un database Home Location Register)
� Servizi di Ticketing per la risoluzione di problemi
(Gestione dei trouble ticket)
50
SE
WNCE
YAIM
UI
GRID
UI
DGAS
TS
SAM
MS
LFC
II
VOMS
RB
Grid Service Center
Grid Site
51
Il portale web GENIUS
52
Il laboratorio GILDA per la “dissemination”
53
Open Grid Services Architecture (OGSA) è un nuovo paradigmaconcettuale che vuole mettere insieme le potenzialità deiserviziWeb con il Grid computing. Le applicazioni invocheranno i Web services tramite il Web Services Description Language (WSDL).
Molti progetti (es. LCG ,EGEE) già prevedono il passaggio da un’architetturabasata su Globus ad unabasata su OGSA.
EVOLUZIONE EVOLUZIONE DELLDELL ’’ ARCHITETTURA GRIDARCHITETTURA GRID
Globus 2 based
OGSA based
EGEE-2EGEE-1LCG-2LCG-1
EDG
VDT
. . .
LCG EGEE
. . .
54
55
COME FUNZIONA UNA GRID ?COME FUNZIONA UNA GRID ?
� L’identità dell’utente deve essere certificata dalle CA (Certification Authorities) nazionali.
� Le risorse devono essere certificate dalle CA e sono rese accessibili solo agli utenti certificati ed identificati (X.509 Public Key Infrastructure).
� L’utente passa ai propri processi temporaneamente il diritto di essere eseguiti.
� Ciascuna organizzazione virtuale si dota di politiche per l’accesso dei propri utenti alle risorse appartenenti a domini differenti (diverse sedi).
56
Collective ServicesCollective Services
Information&
Monitoring
Information&
Monitoring
Replica ManagerReplica
ManagerGrid
SchedulerGrid
Scheduler
Local ApplicationLocal Application Local DatabaseLocal Database
Underlying Grid ServicesUnderlying Grid Services
Computing ElementServices
Computing ElementServices
AuthorizationAuthenticationand Accounting
AuthorizationAuthenticationand Accounting
Replica CatalogReplica Catalog
StorageElementServices
StorageElementServices
SQL Database Services
SQL Database Services
Fabric servicesFabric services
ConfigurationManagement
ConfigurationManagement
Node Installation &Management
Node Installation &Management
Monitoringand
Fault Tolerance
Monitoringand
Fault Tolerance
ResourceManagement
ResourceManagement
Fabric StorageManagement
Fabric StorageManagement
Grid
Fabric
Local Computing
Grid Grid Application LayerGrid Application Layer
Data Management
Data Management
Job Management
Job Management
MetadataManagement
MetadataManagement
Service Index
Service Index
APPLICATIONS
GLOBUS
M / W
LL ’’ ARCHITETTURA DEL M/WARCHITETTURA DEL M/W
57
Collective ServicesCollective Services
Information & Monitoring
Information & Monitoring Replica
ManagerReplica Manager Grid
SchedulerGrid
Scheduler
Local ApplicationLocal Application Local DatabaseLocal Database
Underlying Grid ServicesUnderlying Grid Services
Computing ElementServices
Computing ElementServices
AuthorizationAuthenticationand Accounting
AuthorizationAuthenticationand Accounting
Replica Catalog
Replica CatalogStorage
ElementServices
StorageElementServices
SQL Database Services
SQL Database Services
Fabric servicesFabric services
ConfigurationManagement
ConfigurationManagement
Node Installation &Management
Node Installation &Management
Monitoringand
Fault Tolerance
Monitoringand
Fault ToleranceResource
ManagementResource
ManagementFabric StorageManagement
Fabric StorageManagement
Grid Application LayerGrid Application Layer
Data Management
Data ManagementJob
ManagementJob
ManagementMetadata
ManagementMetadata
Management Object to File Mapping
Object to File Mapping
Service IndexService Index
ComputingComputing ElementsElements
SystemSystemManagersManagers
ScientistsScientists
OperatingOperatingSystemsSystems
FileFile SystemsSystems
StorageStorageElementsElementsMassMass Storage SystemsStorage Systems
HPSS, CastorHPSS, Castor
UserUser AccountsAccounts
CertificateCertificate AuthoritiesAuthorities
ApplicationApplicationDevelopersDevelopers
BatchBatch SystemsSystemsPBS, LSF, etc.PBS, LSF, etc.
I COMPONENTII COMPONENTI
58
Computing Element
Storage Element
Site X
Information System
submit
submit
queryretrieve
retrieve
Resource Broker
User Interface
publishstate
R-GMA
Replica LocationService
VOMS
query
updatecredential
ESEMPIO DI JOB SUBMISSIONESEMPIO DI JOB SUBMISSION
59
� User Interface (UI) : punto di accesso dell’utente al Workload Management System.
� Resource Broker(RB) : gestore delle risorse di GRID, ha il compito di trovare le migliori risorse dove sottomettere i jobs.
� Job Submission Service(JSS) :fornisce un sistemaaffidabile di sottomissione jobs.
� Information Index (II) : servizio specializzato usato dalResource Broker come filtro per l’Information Service per selezionare le risorse.
� Logging and Bookkeeping services (LB) :fornisce le informazioni sui jobs su richiesta degli utenti.
60
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
CE characts& status
SE characts& status
RB node
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager Inform.
Service
ComputingElement
StorageElement
RB node
CE characts& status
SE characts& status
submitted
UI: allows users to access the functionalitiesof the WMS
Job Status
RLS
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
ReplicaCatalog
Inform.Service
ComputingElement
StorageElement
RB node
CE characts& status
SE characts& status
edg-job-submit myjob.jdlMyjob.jdl
JobType = “Normal”;
Executable = "$(CMS)/exe/sum.exe";
InputSandbox = {"/home/user/WP1testC","/home/file*”, "/home/user/DATA/*"};
OutputSandbox = {“sim.err”, “test.out”, “sim.log"};
Requirements = other. GlueHostOperatingSystemName == “linux" &&
other. GlueHostOperatingSystemRelease == "Red Hat 6.2“ && other.GlueCEPolicyMaxWallClockTime > 10000;
Rank = other.GlueCEStateFreeCPUs;
submitted
Job Status
Job Description Language(JDL) to specify job characteristics and requirements
gliteglite--jobjob--submit submit file.jdlfile.jdl
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
CE characts& status
SE characts& status
RBstorage
Input Sandboxfiles
Job
waiting
submitted
NS: network daemon responsible for acceptingincoming requests
Job Status
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
CE characts& status
SE characts& status
RBstorage
waiting
submitted
WM: responsible to takethe appropriate actions to satisfy the request
Job
Job Status
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
CE characts& status
SE characts& status
RBstorage
waiting
submitted
Match-Maker/Broker
Where must thisjob be executed ?
Job Status
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
CE characts& status
SE characts& status
RBstorage
waiting
submitted
Match-Maker/ Broker
Matchmaker: responsible to find the “best” CE where to submit a job
Job Status
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
CE characts& status
SE characts& status
RBstorage
waiting
submitted
Match-Maker/ Broker
Where are (which SEs) the needed data ?
What is thestatus of the
Grid ?
Job Status
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
CE characts& status
SE characts& status
RBstorage
waiting
submitted
Match-Maker/Broker
CE choice
Job Status
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
CE characts& status
SE characts& status
RBstorage
waiting
submitted
JobAdapter
JA: responsible for the final “touches”to the job before performing submission(e.g. creation of wrapper script, etc.)
Job Status
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
CE characts& status
SE characts& status
RBstorage
JC: responsible for theactual job managementoperations (done via CondorG)
Job
submitted
waiting
ready
Job Status
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
CE characts& status
SE characts& status
RBstorage
Job
InputSandboxfiles
submitted
waiting
ready
scheduled
Job Status
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
StorageElement
RB node
RBstorage
InputSandbox
submitted
waiting
ready
scheduled
running
“Grid enabled”data transfers/
accesses
Job
Job Status
ComputingElement
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
RBstorage
OutputSandboxfiles
submitted
waiting
ready
scheduled
running
done
Job Status
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
RBstorage
OutputSandbox
submitted
waiting
ready
scheduled
running
done
edg-job-get-output <dg-job-id>
Job Status
gliteglite--jobjob--output output jobidjobid
UI
NetworkServer
Job Contr.-
CondorG
WorkloadManager
RLS
Inform.Service
ComputingElement
StorageElement
RB node
RBstorage
OutputSandboxfiles
Job Status
cleared
submitted
waiting
ready
scheduled
running
done
76
UI
Log Monitor
Logging &Bookkeeping
NetworkServer
Job Contr.-
CondorG
WorkloadManager
ComputingElement
RB node
LM: parses CondorG logfile (where CondorG logsinfo about jobs) and notifies LB
LB: receives and stores job events; processes corresponding job status
Log ofjob events
edg-job-status <dg-job-id>edg-job-get-logging-info <dg-job-id>
Job status
gliteglite--jobjob--status status jobidjobid
77
http://grid-it.cnaf.infn.it
Grid.IT Production Grid: Operations Portal
78
Access to the Grid
79
80
Grid Monitoring
81
82
83
84
85
Grid Service monitoring