LEZIONE N. 16LEZIONEpeople.na.infn.it/~merola/CORSO_GRID_2008-09/Lezione_16...Introduzione alle...

1Introduzione alle griglie computazionali aa 2006-07Griglie Computazionali - aa 2008-09

LEZIONELEZIONE N. 16

• FTS - File Transfer Service

• Grid Accounting: APEL e DGAS

Griglie computazionali Griglie computazionali

Università degli Studi di Napoli Federico IICorso di Laurea Magistrale in Informatica – I Anno


IntroduzioneIn questa lezione esaminimo due argomenti distinti:

• Il File Transfer Service, un servizio di trasferimento dei file che completa l’argomento della gestione dei dati (lez. 10 e 11)

• I sistemi per l’accounting in Grid, ossia i meccanismi per determinare l’utilizzo effettivo delle risorse da parte degli utenti e delle VO.


Trasferimento dati controllato dalclient

• Nei primi strumenti di trasferimento dati (gridftp) la copia ècontrollata dal client.

• Anche se I protocolli di trasferimento sono robusti, ciò pone dellelimitazioni: lo stato del trasferimento è “nascosto” .

• Il client conosce internamente lo stato locale, ma non sa nulla dellostato globale dei trasferimenti tra gli storage element coinvolti– Gli Storage elements posso essere sovraccaticati da richieste– Posso avvenire simultaneamente repliche multiple degli stessi dati– Non c’e controllo sull’utilizzo globale della rete

Client

Source Storage

Element Destination Storage

Element

Control

Channels

Data Flow

Channel


Servizio di Trasferimento Dati•È necessario un servizio per gestire il data transfer

– Il Client si connette al servizio per sottomettere una richiesta

– Il Service è a conscenza dellostato dei trasferimenti

– Il Client può periodicamentericonnettersi per controllare lo statoo cancellare una richiesta

– Il Servizio è a conscenza dellostato globale, non di una singolarichiesta, quindi puo’ effettuare:

•Load balancing•Scheduling

Transfer

Service

Source

Storage

Element

Destination

Storage

ElementData

Flow

Client

•Submit new request•Monitor progress•Cancel request

SOAP via https


File Transfer Service• File Transfer Service (FTS) e’ un servizio per il

trasferimento di datiE’ un servizio multi esperimento , utilizzato per bilanciare l’uso delle

risorse di un sito in accordo con le policy del sito stesso e delle Virtual Organizzation (VO) che supporta;

• Perche’ serve?– Lato utenti , il servizio permette il trasferimento dei file da una

sorgente ad una destinazione in modo affidabile;– Lato site manager , fornisce una soluzione affidabile ed

elastica per soddisfare le richieste di trasferimento dati provenienti dagli esperimenti supportati;

– Lato production manager , permette di controllare le richieste dei loro utenti (priorita’, re-schedule transfer, ….)

• Il focus e’ nel “servizio”:Deve permettere queste operazioni in maniera semplice e trasparente


Archiettura di File Transfer Service • I Client sottomettono jobs via

SOAP su https.

• I jobs sono liste di URLs in formato srm:// . Si possonospecificare alcuni paramtri del trasferimento (stream parallele, buffer sizes).

• I Client possono richiedereinformazioni sui cambiamenti distato del trasferimento.

• C command line clients. C, Java and Perl APIs available.

• Il servizio si presenta come un Web service in Tomcat5.

Transfer

Service

Client

Secure web service connection

Database

Well defined state

transitions/ checkpointing

Storage

Elements


NoteSOAP - The Simple Object Access Protocol provides a means of

messaging between a service provider and a service requestor. SOAP is a simple enveloping mechanism for XML payloads thatdefines a remote procedure call (RPC) convention and a messaging convention. SOAP is independent of the underlyingtransport protocol; SOAP payloads can be carried on HTTP, FTP, Java Messaging Service (JMS), and the like. We emphasize thatWeb services can describe multiple access mechanisms to the underlying software component. SOAP is just one means of formatting a Web service invocation.

Apache Tomcat is the servlet container that is used in the officialReference Implementation for the Java Servlet and JavaServerPages technologies.


Canali FTS• Il Servizio FTS ha il concetto

di canale• Un canale è una connessione

unidirezionale tra due siti.• Le richieste di trasferimento tra

questi I due siti sono assegnate al corrispondente canale

• I canali accettano le wildcards: – * to MY_SITE : All incoming– MY SITE to * : All outgoing– * to * : Catch all

• I canali a volte corrispondonoconnessioni di rete dedicate a unaparticolare produzione, ma non sonoconnessioni fisiche.

• Channels control certain transfer properties: transfer concurrency, gridftp streams.

• Channels can be controlled independently: started, stopped, drained.


File Transfer Service


gLite FTS: Agenti• Ogni job sottomesso a FTS

passa attraverso un VO Agent e un Channel Agent.

VO Agent• L’agente della VO autorizza il

job e cambia il suo stato in “Pending”

• I VO agents possono compierealtre operazioni specifichedella VO:– Scheduling– Interazione con il File

catalog della VO

Channel Agent• Gli effettivi trsferimenti sui

canali sono gestiti dal channel agent

• I Channel agents possono eseguireuno scheduling inter-VO


FTS schema generale


Utilizzo di FTS


Conclusioni• FTS offer an important and useful service on the grid – a

significant advance on client managed file transfers.

• FTS channel architecture offers very useful features to control transfers between sites or into a single site, though it may become overly complex in a grid without clear data flow patterns.

– The ability to control VO shares and transfer parameters on a channel is important for sites.

• FTS agent architecture allows VOs to connect the transfer service closely with their own data management stacks, a useful feature for HEP experiments.


Why Accounting ?In a distributed computing environment people want

to know who used the resources and how many resource have been used.

• Users : How many resources am I using ? • VO managers : how many resources is my VO

using ?• Site Managers : who is using my resources ?• ROC Managers : How many resources have

been used in my federation and who used them ?A good accounting system should be able to answer

these questions taking care of all the security and privacy issues.

15Introduzione alle griglie computazionali aa 2006-07

Grid accounting Una generica infrastruttura di grid accounting deve coprire i requirements

di tre tipi di utenti: Siti, VO ed amministratori grid .

Site accounting databaseSite layer

Usage MeteringResource’s layer

VO accounting databaseUsers/VO layer

grid accounting databasegrid layer Web reports: -Aggregate info-Sites load-Anonymised statistics

-Aggregate VO info-Group/Role info-Detailed User info-Job level info

-Aggregate site info-VO (with role/group) usage on the site.-Detailed Resource Usage info -Job level info


CPU Accounting• Consiste nel raccogliere e registrare secondo metrichepredefinite, informazioni sulla disponibilià e l’utilizzo delle risorsedi calcolo, o di grandezze derivate.• Le sorgenti di informazione primarie sono i log files di :

•CE gatekeeper + batch system

Storage Accounting• Consiste nel raccogliere e registrare secondo metrichepredefinite, informazioni sulla disponibilià e l’utilizzo delle risorsedi storage• Le sorgenti di informazione primarie sono i log files di :

• transfer services + storage system


Sistemi per l’accounting in grid: • DGAS (Distributed Grid Accounting System) è un sistema didistribuito capace di effettuare la misurazione dell’utilizzo dellerisorse ed eventualmente un Accounting Economico.

È basato su una infrastruttura client/server basata su una retedi server di accounting indipendenti.

Sviluppato nell’ambito EGEE dalla sezione di Torino dell’INFN.

• APEL (Accounting Processor for Event Logs) è un componente dell’ EGEE CPU Accounting system, distribuito come parte del gLite middleware.

APEL pubblica i record di utilizzo delle CPU in grid in una repository centralizzata, il GOC (Grid Operations Centre) usando R-GMA come meccanismo di transporto.

I records sono processati e possono essere acceduti attraverso l’EGEE Accounting Portal.


Requirements / Use casesHow much resource has been provided to each VO?Grid Level (High Level) How much resource has been provided to each VOGrid Level (High Level) Aggregation / Data Consolidation

Administrative Domains :-VOs, VOMS Groups, Countries (LHC), Regions (EGEE)Grids, (EGEE, OSG, TeraGrid, Nordic) Organisations (GridPP, INFNGrid, SEEGrid, …)

If 10,000 CPU hours were consumed by Atlas VO, who are the users that submitted the work?Finer Granularity (Low level)User Level, Job Level, Top Users within a VO and GroupConfidentiality

Quota enforcement / fairshare scheduling: how much resource has been provided to a particular user on a particular set o f CEs?User Level, Job LevelConfidentialityReliability


DGAS Components• Sensors on CEs

– Build usage records from LRMS accounting files

• Resource (site) HLRs (Home Location Registers)

– Collect usage records from one or more sites

• User (VO) HLRs

– Collect usage records for a whole VO

• Query clients and visualization tools

– Allow to retrieve data from HLRs


DGAS Workflow

job

job

Usage Record

Usage Record

CE

WN

Site HLRVO HLR

1

2

3

3L2 HLR

3


DGAS Features• Granularity

– Resource accounting at single job level or in aggregate form per user, per VO, per resource (site) or per infrastructure (collection of sites).

• Scalability

– Arbitrary number of Resource/VO HLRs can be deployed.

• Hierarchical Design

– HLRs can be interconnected, in order to have multiple levels of aggregation.


DGAS Features II• Completeness

– Capability to collect information both for grid and local jobs.

• Customization

– Possibility to choose which resource and/or type of jobs must be accounted.

• Designed to perform pricing (not used)

– Possibility to assign “computing credits” (something similar to quotas) that can be used as a basis for billing the resource consumptions.


DGAS features Site sensors• can build accounting records for grid jobs as well as local jobs

(accounted on different HLR accounts)• for grid jobs: integrates local usage information with grid-related

information (user DN, user FQAN (VOMS), CE ID, grid job ID).• supports PBS and LSF • “next-to-real-time” accounting (after job completion)

HLR service (accounting servers)• fully distributed architecture (scalability)• deployed as User (VO) HLRs and/or Resource (Site) HLRs• command line tools and C++ API for queries• strict authorization control (x509) for accessing private info

Data transport:• all communication between the components as well as between client

tools and servers is encrypted and secure (x509-based, GSI)

• mostly asynchronous data transport between the components for more robustness

VO HLR

CE

Site HLR

Client (UI)


Information retrieval

• Information are retrieved parsing the LRMS (batch system) accounting log files and the CE gatekeeper log file

• LRMS log files : •resource used (cpu-time,wall-time,lrmsid,user,group)

• Comuptin Element gatekeeper log files : •grid info (user DN, grid-jobid,VO)

• Some other config files are used in order to manage local jobs, for which the VO could not be defined through the proxycertificate.


Security and Privacy• Information confidentiality is guaranteed by the use of

different authorization levels to access the Usage Records.– Users (can access their own detailed records and aggregates)

– Site Managers (Can access their own site detailed records and aggregates)

– VO Managers (Can access detailed records and aggregates of all VO members)

• Full VOMS integration in query authorization is available (now on L2 HLR, on every HLR in future releases) – (e.g. /atlas/Role=vomanager/Group=NULL)

• Security and integrity of the data flow is guaranteed by the use of GSI and data encryption.

• No sensitive information sent in clear text


Accounting & policiesThe accounting information can be also used to implement dynamic

resource access policies and help in fair sharing of available resources.

It is clear that in order to reach this goal is necessary to have real time access to accounting information.

It is also necessary to be sure that the information contained in the accounting databases can’t be maliciously altered by the users (reliability).


APEL featuresThree Components:Sensors (Deployed at site) :-• Process log files; maps DN to Batch Usage; builds accounting records• Accounts from Grid Jobs Only• Supports PBS, SunGridEngine, Condor, and LSF• Not REAL-TIME accounting

Data Transport:-• Uses RGMA to send data to a central repository• 196 sites publishing, 7.5 Million Job records collected• Can use other transport protocols• Allows sites to control DN information from leaving site

Presentation (GOC and Regional Portal)• Reporting based on data aggregation• LHC View, EGEE View, GridPP View, Site View• Metrics (e.g. Time Integrated CPU Usage)

Tables, Pies, Gantt Charts,


APEL Issues Data Privacy and Confidentiality• Provides sites with the option to publish or suppress (default) DN

information – Many sites suppress DN, some sites publish DN.

• Any person with a trusted certificate and access to a UI can query RGMA and get Job Record information from APEL database– x509-based authorization features in RGMA in development

• Does not currently encrypt the usage record• Does not currently sign the data

General Issue For Accounting: Normalisation in Heterogeneous Farms

• APEL Uses SpecINT2000 published by sites in the information system because sites have different strategies/policies for setting up their batch systems– Some sites publish SI2K of slowest worker nodes– Other sites publish a weighted mean, because they use internal

scaling factors – Many Batch systems currently in use don’t report

performance/benchmark information of the worker nodes in the batch logs.


APEL + DGAS When used together APEL and DGAS can leverage each others

strengths and give to their customers the following benefits:• Fully distributed architecture• From single job to grid-level accounting information.• Web access to aggregate usage information.• VOMS based accounting (using VOMS FQAN in usage records).• Real time access to job accounting info for users and site

managers.• Security and authorisation mechanisms to guarantee information

integrity and confidentiality. • Possibility to access non-confidential information via RGMA.

APEL and DGAS, if used alone, have their own specific strengths and limitations.

None of the two can fulfill the previously highlighted requirements for grid accounting.

However, APEL and DGAS have complementary functionalities that if used in sinergy actually can fulfill the requirements.


APEL + DGAS (2) DGAS and APEL as components of the vertical

accounting infrastructure (DGAS2APEL example)

DGAS site HLRSite layer

Accounting Sensors (joint)Resource’s layer

DGAS VO HLRUsers/VO layer

APEL and GOC web interfacegrid layer Web reports: -Aggregate info-Sites load-Anonymised statistics

-Aggregate VO info-Group/Role info-Detailed User info-Job level info

-Aggregate site info- VO (with role/group) usage on the site.-Detailed Resource Usage info -Job level info


DGAS2APEL workflow

• Dgas2apel is a process that converts the Usage Records from the format adopted by DGAS to the one adopted by APEL. Converted records are then inserted in a RDBMS table known as LCGRecords.

• Such records are then forwarded to the GOC by APEL itself via its ‘apel-publisher’ process, which uses RGMA as a high level transport service toward the GOC.

HLR DB

dgas2apel

LCGRecordsHLR

apel-publisher

R-GMAR-GMA

GOC DB


ExamplesMulti Site Information from L2 HLR

Jobs per site (T1 included)

Jobs per VO (T1 included)


Examples

Multi Site Information from L2 HLR

Jobs per day

(T1 included)


Referenze

• File Transfer Service FTS:http://egee-jra1-dm.web.cern.ch/egee-jra1-dm/FTS/

• APEL accounting website: http://goc.grid.sinica.edu.tw/gocwiki/ApelHome

• DGAS website: http://www.to.infn.it/grid/accounting/main.html

• DGAS User Guides: https://edms.cern.ch/document/571271/1

LEZIONE N. 16LEZIONEpeople.na.infn.it/~merola/CORSO_GRID_2008-09/Lezione_16...Introduzione alle...

Documents

Transcript of LEZIONE N. 16LEZIONEpeople.na.infn.it/~merola/CORSO_GRID_2008-09/Lezione_16...Introduzione alle...