Introduzione alle griglie computazionali Università degli Studi di Napoli Federico II Corso di Laurea in Informatica – III Anno LEZIONE N. 2 Sistemi distribuiti Architettura di Grid Generalità su livelli, protocolli e servizi di Grid Introduzione alle griglie computazionali - a.a. 2005-06

Che cosa è un sistema distribuito ? E’ un sistema di molti processori distribuiti su rete locale o geografica, interconnessi tra loro, accessibili agli utenti nel modo più trasparente possibile e capaci di cooperare tra loro alla soluzione di un problema (ad es. un’applicazione dell’utente). Mass storage condiviso Cluster di PC Utenti Esempio R e t e

“Pro” e “Contro” di un sistema distribuito rispetto a Mainframes o 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 Recovery su scala geografica.

Classificazione di un computer (Flynn, 1972) SISD: Single Instruction Single Data (es. monoprocessori tradizionali). SIMD: Single Instruction Multiple Data (es. array processors dove una singola instruzione attiva 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).

Struttura di un computer SISD Memoria Principale (RAM) Unità di Input e di Output CPU Control Arithmetic and Logic R0 R1 … Rn General purpose registers Program Counter CPU status Input e Output bus Memory bus Cache Memory

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

Struttura a multi-bus P C I Control Arithmetic and Logic R0 R1 … Rn General purpose registers Program Counter CPU status Struttura a multi-bus Memoria RAM P C I Bus Adapter I/O bus Bus Adapter I/O bus Periferiche di I/O Periferiche di I/O

Classificazione dei sistemi MIMD Livello di condivisione delle risorse Tightly coupled Loosely coupled Multi-processors (shared memory) Multi-computers (private memory) Bus Switched Bus Switched (es. Hypercube, Transputer) (es. Ultracomputer RP3, APE) (es. PC su una LAN)

Bus-based Multi-processors Memoria condivisa 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 il controllo; 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).

Switched Multi-processors CPU CPU CPU Crossbar switch: elemento a matrice al posto del bus per mettere in comunicazione contemporaneamente le CPU con elementi di memoria diversi. Vantaggio: sistemi con molte centinaia di processori. Problema: ridurre i tempi di accesso CPU-Memoria.

Bus-based Multi-computers cache CPU M PC o workstations su Local Area Nnetwork No shared memory. cpu-to-cpu communications: il volume dei dati da scambiare diminuisce e comunque e’ meno critico per l’efficienza delle cpu. LAN su bus o anello o matrice di switch.

Dal punto di vista dei Sistemi Operativi cpu tightly coupled: occorre gestire la memoria condivisa. cpu loosely coupled: occorre disporre di network operating systems in grado di eseguire: operazioni distribuite a bassa condivisione di risorse (es. login remoto, file transfer). operazioni distribuite ad alta condivisione di risorse (es. file server e job manager).

Esempio di tightly coupled SW su tightly coupled HW: Multiprocessor Operating System (memoria condivisa) A running B running C running D, E ready Run Queue D,E Op. Syst. Shared Memory Processo A Processo B Processo C cache CPU 1 cache CPU 2 cache CPU 3 bus 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.

(File server condiviso) Esempio di loosely coupled SW su loosely coupled HW: Network Operating System (file condivisi) mount /etc/fileserver/dati/grafici/source /usr/pippo/grafici cache CPU M L A N File Server export /dati/grafici/source (File server condiviso)

LSF, PBS, … Submit job Job Manager Run job L A N File Server CPU M cache CPU M File Server Submit job LSF, PBS, … Job Manager Run job

Problema: Controllo centralizzato, mancanza di coordinameno per l’esecuzione dei processi e scarsa interazione tra i sistemi componenti. Soluzione: Sistema operativo distribuito: tightly-coupled SW su loosely-coupled HW come se fosse un singolo sistema invece che una collezione di singoli sistemi.

Confronto tra vari sistemi distribuiti Network Operating system Distributed Operating system Multiprocessor Operating system Appare come un unico uniprocessore virtuale? no si Deve avere lo stesso sistema operativo? si-no Quante copie di OS? n 1 Come comunicano? shared files messages shared memory Devono concordare i protocolli di rete? C’e’ una sola coda di run?

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.

Requisiti 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 interface indipendente dal numero di processori. Location transparency The user can not tell where resources are located Migration transparency Resources can move at will without changing their names Replication transparency The users cannot tell how many copies exist Concurrency transparency Multiple users can share resources automatically Parallelism transparency Activities can happen in parallel without users knowing

Flessibilità: (a) (b) 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 monolithic kernel File server microkernel Process server (a) (b)

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.

CHE COSA E’ 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”.

1998 (Ian Foster e Carl Kesselman) – “A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive and inexpensive access to high-end computational capabilities”. 2000 (Ian Foster, Carl Kesselman e Steve Tuecke) – Grid computing is concerned with “coordinated resource sharing and problem solving 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.) che agiscono da Virtual Organizations. Importanza di definire protocolli standard per consentire la interoperabilità e realizzare una infrastruttura comune.

DEFINIZIONE DI GRID IN 3 PUNTI GRID è un sistema che: 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 la necessità 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).

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).

Non sono GRID (ad esempio): 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. 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.

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-demand alle risorse. Usare protocolli aperti, standard e general-purpose per la gestione delle risorse (ad es. il Globus Toolkit, l’EDG Toolkit, l’Open Grid Service Architecture - OGSA). Garantire qualità di servizio in vari settori (sicurezza, affidabilità, prestazioni, ecc.).

IL PROBLEMA GRID Realizzare la condivisione coordinata di risorse su larga scala in un contesto di organizzazione virtuale, multi-instituzionale e dinamica. Occorre una nuova architettura che: identifichi le componenti principali del sistema. specifichi lo scopo e la funzione di 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).

DEFINIZIONI PROTOCOLLO: Insieme di regole e formati per lo scambio di 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).

SERVIZIO: protocollo + funzione. Capacità di svolgere una funzionalità sulla 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.

L’ARCHITETTURA GRID Si 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.

Fabric Connectivity Resource Collective Application

Interfacce per il controllo locale FABRIC Layer: Interfacce per il controllo locale 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 management per il controllo della qualità del servizio offerto.

Comunicazione facile e sicura CONNECTIVITY Layer: Comunicazione facile e sicura Definisce i protocolli base per la comunicazione e l’autenticazione. I protocolli di comunicazione abilitano lo scambio dei dati 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 servizi di comunicazione per fornire meccanismi crittografici sicuri per verificare l’identità di utenti e risorse.

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 non deve richiedere che i sistemi di security locali interagiscano tra di loro per configurare l’ambiente di sicurezza. Il Globus Toolkit usa i protocolli GSI (Grid Security Infrastructure) per l’autenticazione (certificati con formato X.509), la protezione della comunicazione (estende i protocolli di TLS - Transport Layer Security) e l’autorizzazione.

Condivisione di risorse singole RESOURCE Layer: Condivisione di risorse singole Definisce i protocolli per negoziare, iniziare, monitorare, controllare, addebitare l’utilizzo di risorse singole, cioè non distribuite. Questi protocolli utilizzano funzioni del Fabric per accedere 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.

Il Globus Toolkit usa protocolli standard: GRIP (Grid Resource Information Protocol), basato su LDAP per definire uno standard resource information protocol e 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.

A ciò si aggiungono client-side API, server-side API 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.

Coordinamento di collezioni di risorse COLLECTIVE Layer: Coordinamento di collezioni di risorse 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 Resource e 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 di storage di una VO per massimizzarne le prestazioni (tempi di risposta, affidabilità, ecc.).

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.

APPLICATIONS Layer Comprende le applicazioni degli utenti appartenenti ad una Virtual Organization. Le applicazioni sono costruite sulla base dei servizi definiti in ciascuno strato.

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).

L’ARCHITETTURA DEL M/W DI EDG Collective Services Information & Monitoring Replica Manager Grid Scheduler Local Application Local Database Underlying Grid Services Computing Element Services Authorization Authentication and Accounting Replica Catalog Storage Element Services SQL Database Services Fabric services Configuration Management Node Installation & Monitoring and Fault Tolerance Resource Management Fabric Storage Grid Fabric Local Computing Grid Application Layer Data Management Job Management Metadata Management Service Index APPLICATIONS GLOBUS M / W

I COMPONENTI DI EDG Computing Elements System Managers Scientists Collective Services Information & Monitoring Replica Manager Grid Scheduler Local Application Local Database Underlying Grid Services Computing Element Services Authorization Authentication and Accounting Replica Catalog Storage Element Services SQL Database Services Fabric services Configuration Management Node Installation & Monitoring and Fault Tolerance Resource Management Fabric Storage Grid Application Layer Data Management Job Management Metadata Management Object to File Mapping Service Index Computing Elements System Managers Scientists Operating Systems File Systems Storage Elements Mass Storage Systems HPSS, Castor User Accounts Certificate Authorities Application Developers Batch Systems PBS, LSF, etc.

ESEMPIO DI JOB SUBMISSION Computing Element Storage Element Site X Information System submit query retrieve Resource Broker User Interface publish state R-GMA Replica Location Service VOMS update credential

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 sistema affidabile di sottomissione jobs. Information Index (II) : servizio specializzato usato dal Resource 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. The EDG WMS is comprised of 5 major parts: The user interface which hosts all of the user level commands. This is the place where the user interacts with WMS (and thus with the Grid) The resource broker tries to schedule jobs on the grid allowing an efficient use of Grid resources The job submission system actually delivers jobs to the computing elements chosen by the resource broker. The information index, a “cache” to the Information Service (populated by the EDG Information Service providers), allows the resource broker to retrieve information about the status of the Grid Finally, the logging and bookkeeping services store job information and are used for job monitoring Introduzione alle griglie computazionali - a,a. 2003-04

RB node UI RLS Network Server Workload Manager Inform. Service Job Contr. - CondorG CE characts & status SE characts & status The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

access the functionalities of the WMS Job Status RB node submitted RLS Network Server UI Workload Manager Inform. Service UI: allows users to access the functionalities of the WMS Job Contr. - CondorG CE characts & status SE characts & status The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

edg-job-submit myjob.jdl RB node 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; Job Status RB node submitted Replica Catalog Network Server UI Workload Manager Inform. Service Job Description Language (JDL) to specify job characteristics and requirements Job Contr. - CondorG CE characts & status SE characts & status The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

responsible for accepting incoming requests RB node NS: network daemon responsible for accepting incoming requests Job Status RB node waiting submitted RLS Network Server Job UI Input Sandbox files Workload Manager Inform. Service RB storage Job Contr. - CondorG CE characts & status SE characts & status The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

WM: responsible to take the appropriate actions to satisfy the request Job Status RB node waiting submitted RLS Network Server UI Job Workload Manager Inform. Service RB storage WM: responsible to take the appropriate actions to satisfy the request Job Contr. - CondorG CE characts & status SE characts & status The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

RB node UI RB waiting submitted RLS Network Server Match- Maker/ Job Status RB node waiting submitted RLS Network Server UI Match- Maker/ Broker Workload Manager Inform. Service RB storage Where must this job be executed ? Job Contr. - CondorG CE characts & status SE characts & status The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

Matchmaker: responsible to find the “best” CE where to submit a job UI Status RB node waiting submitted RLS Network Server Matchmaker: responsible to find the “best” CE where to submit a job UI Match- Maker/ Broker Workload Manager Inform. Service RB storage Job Contr. - CondorG CE characts & status SE characts & status The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

RB node UI RB waiting submitted RLS Network Server Match- Maker/ Job Status RB node Where are (which SEs) the needed data ? waiting submitted RLS Network Server UI Match- Maker/ Broker Workload Manager Inform. Service RB storage What is the status of the Grid ? Job Contr. - CondorG CE characts & status SE characts & status The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

RB node UI RB waiting submitted RLS Network Server Match- Maker/ Job Status RB node waiting submitted RLS Network Server UI Match- Maker/ Broker Workload Manager Inform. Service RB storage CE choice Job Contr. - CondorG CE characts & status SE characts & status The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

JA: responsible for the final “touches” Job Status RB node waiting submitted RLS Network Server UI Workload Manager Inform. Service RB storage Job Adapter Job Contr. - CondorG CE characts & status JA: responsible for the final “touches” to the job before performing submission (e.g. creation of wrapper script, etc.) SE characts & status The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

JC: responsible for the actual job management operations (done via Status RB node submitted waiting ready RLS Network Server UI Workload Manager Inform. Service RB storage Job Job Contr. - CondorG JC: responsible for the actual job management operations (done via CondorG) CE characts & status SE characts & status The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

RB node UI RB submitted waiting ready scheduled RLS Network Server Job Status RB node submitted waiting ready scheduled RLS Network Server UI Workload Manager Inform. Service RB storage Job Contr. - CondorG Input Sandbox files CE characts & status SE characts & status The overall plan defined for the quality objectives is described here after : Job Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

RB node UI RB submitted waiting ready scheduled running RLS Network Job Status RB node submitted waiting ready scheduled running RLS Network Server UI Workload Manager Inform. Service RB storage Job Contr. - CondorG Input Sandbox The overall plan defined for the quality objectives is described here after : “Grid enabled” data transfers/ accesses Computing Element Storage Element Job Introduzione alle griglie computazionali - a,a. 2003-04

RB node UI RB submitted waiting ready scheduled running done RLS Job Status RB node submitted waiting ready scheduled running done RLS Network Server UI Workload Manager Inform. Service RB storage Job Contr. - CondorG Output Sandbox files The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

edg-job-get-output <dg-job-id> Status RB node edg-job-get-output <dg-job-id> submitted waiting ready scheduled running done RLS Network Server UI Workload Manager Inform. Service RB storage Job Contr. - CondorG Output Sandbox The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

RB node UI RB cleared submitted waiting ready scheduled running done Job Status RB node cleared submitted waiting ready scheduled running done RLS Network Server UI Output Sandbox files Workload Manager Inform. Service RB storage Job Contr. - CondorG The overall plan defined for the quality objectives is described here after : Computing Element Storage Element Introduzione alle griglie computazionali - a,a. 2003-04

edg-job-status <dg-job-id> RB node edg-job-status <dg-job-id> edg-job-get-logging-info <dg-job-id> Network Server UI LB: receives and stores job events; processes corresponding job status Workload Manager Job status Logging & Bookkeeping Job Contr. - CondorG Log Monitor The overall plan defined for the quality objectives is described here after : Log of job events LM: parses CondorG log file (where CondorG logs info about jobs) and notifies LB Computing Element Introduzione alle griglie computazionali - a,a. 2003-04

Grid.IT Production Grid: Operations Portal User documentation site managers documentation Software repository Monitoring Trouble tickets system Knowledge base http://grid-it.cnaf.infn.it Introduzione alle griglie computazionali - a,a. 2003-04

Get your personal certificate

How to register to a VO

Grid Service monitoring

EVOLUZIONE DELL’ARCHITETTURA GRID Open Grid Services Architecture (OGSA) è un nuovo paradigma concettuale che vuole mettere insieme le potenzialità dei servizi Web 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’architettura basata su Globus ad una basata su OGSA. Globus 2 based OGSA based EGEE-2 EGEE-1 LCG-2 LCG-1 EDG VDT . . . LCG EGEE