The middleware
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

The middleware PowerPoint PPT Presentation


  • 78 Views
  • Uploaded on
  • Presentation posted in: General

The middleware. Roberto Barbera University of Catania and INFN ISSGC’06 Ischia, 18.07.2006. Outline. Introduction Overview of gLite services especially security Summary and conclusions. Input “sandbox”. DataSets info. UI JDL. Output “sandbox”. voms-proxy-init.

Download Presentation

The middleware

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


The middleware

The middleware

Roberto Barbera

University of Catania and INFN

ISSGC’06

Ischia, 18.07.2006


Outline

Outline

  • Introduction

  • Overview of gLite services

    • especially security

  • Summary and conclusions

ISSGC’06, Ischia, 18.07.2006


Job workflow in glite

Input “sandbox”

DataSets info

UI

JDL

Output “sandbox”

voms-proxy-init

SE & CE info

Output “sandbox”

Expanded JDL

Job Submit Event

Job Query

Input “sandbox” + Broker Info

Publish

Job Status

Storage

Element

Globus RSL

Job Status

Job Status

Job Workflow in gLite

LFC

Catalog

Information

Service

Resource

Broker

Author.

&Authen.

Job Submission

Service

Logging &

Book-keeping

Computing

Element

ISSGC’06, Ischia, 18.07.2006


Job workflow in glite1

Input “sandbox”

DataSets info

UI

JDL

Output “sandbox”

voms-proxy-init

SE & CE info

Output “sandbox”

Expanded JDL

Job Submit Event

Job Query

Input “sandbox” + Broker Info

Publish

Job Status

Storage

Element

Globus RSL

Job Status

Job Status

Job Workflow in gLite

LFC

Catalog

Information

Service

Resource

Broker

Author.

&Authen.

Job Submission

Service

Logging &

Book-keeping

Computing

Element

ISSGC’06, Ischia, 18.07.2006


Glite services decomposition

gLite Services Decomposition

6 High Level Services

+ CLI & API

Legend:

  • Available

  • Soon Available

ISSGC’06, Ischia, 18.07.2006


Middleware structure

Middleware structure

  • Applications have access both to Higher-level Grid Services and to Foundation Grid Middleware

  • Higher-Level Grid Services are supposed to help the users building their computing infrastructure but should not be mandatory

  • Foundation Grid Middleware will be deployed on the EGEE infrastructure

    • Must be complete and robust

    • Should allow interoperation with other major grid infrastructures

    • Should not assume the use of Higher-Level Grid Services

ISSGC’06, Ischia, 18.07.2006


Grid foundation security

Grid Foundation: Security

  • Authentication based on X.509 PKI infrastructure

    • Certificate Authorities (CA) issue (long lived) certificates identifying individuals (much like a passport)

      • Commonly used in web browsers to authenticate to sites

    • Trust between CAs and sites is established (offline)

    • In order to reduce vulnerability, on the Grid user identification is done by using (short lived) proxies of their certificates

  • Proxies can

    • Be delegated to a service such that it can act on the user’s behalf

    • Include additional attributes (like VO information via the VO Membership Service VOMS)

    • Be stored in an external proxy store (MyProxy)

    • Be renewed (in case they are about to expire)

ISSGC’06, Ischia, 18.07.2006


The middleware

This is some

message

Digital Signature

This is some

message

Paul keys

= ?

Digital Signature

public

private

Digital Signature

Paul

  • Paul calculates the hash of the message (with a one-way hash function)

  • Paul encrypts the hash using his private key: the encrypted hash is the digital signature.

  • Paul sends the signed message to John.

  • John calculates the hash of the message and verifies it with A, decyphered with Paul’s publickey.

  • If hashes equal: message wasn’t modified; Paul cannot repudiate it.

This is some

message

Hash(A)

Digital Signature

John

Hash(B)

Hash(A)

ISSGC’06, Ischia, 18.07.2006


Digital certificates

Digital Certificates

  • Paul’s digital signature is safe if:

    • Paul’s private key is not compromised

    • John knows Paul’s public key

  • How can John be sure that Paul’s public key is really Paul’s public key and not someone else’s?

    • A third party guarantees the correspondence between public key and owner’s identity.

    • Both A and B must trust this third party

  • Two models:

    • X.509: hierarchical organization;

    • PGP: “web of trust”.

ISSGC’06, Ischia, 18.07.2006


The middleware

X.509

The “third party” is called Certification Authority (CA).

  • Issue Digital Certificates (containing public key and owner’s identity) for users, programs and machines (signed by the CA)

  • Check identity and the personal data of the requestor

    • Registration Authorities (RAs) do the actual identification/validation

  • CAs periodically publish a list of compromised certificates

    • Certificate Revocation Lists (CRL): contain all the revoked certificates yet to expire

  • CA certificates are self-signed

ISSGC’06, Ischia, 18.07.2006


The middleware

X.509 Certificates

  • An X.509 Certificate contains:

    • owner’s public key;

    • identity of the owner;

    • info on the CA;

    • time of validity;

    • Serial number;

    • digital signature of the CA

Structure of a X.509 certificate

Public key

Subject:C=CH, O=CERN, OU=GRID, CN=Andrea Sciaba 8968

Issuer: C=CH, O=CERN, OU=GRID, CN=CERN CA

Expiration date: Aug 26 08:08:14 2005 GMT

Serial number: 625 (0x271)

CA Digital signature

ISSGC’06, Ischia, 18.07.2006


Obtaining a certificate

Obtaining a Certificate

  • How to obtain a certificate:

Request

A certificate request

is performed

The user identify is

confirmed by the RA

The certificate is used as

a key to access the grid

The certificate is issued

by the CA

ISSGC’06, Ischia, 18.07.2006


Authn and authz pre voms

Authentication

User receives certificate signed by CA

Connects to “UI” by ssh

Downloads certificate

Single logon to Grid – create proxy - then Grid Security Infrastructure identifies user to other machines

Authorisation

User joins Virtual Organisation

VO negotiates access to Grid nodes and resources

Authorisation tested by CE

gridmapfile maps user to local account

UI

AuthN and AuthZ: pre-VOMS

1.

CA

Personal/once

2.

AUP

3.

VO mgr

VO service

VO database

GSI

Daily update

grid-mapfileson Grid services

ISSGC’06, Ischia, 18.07.2006


The middleware

VOs and authorization

  • Grid users MUST belong to virtual organizations

    • What we previously called “groups”

    • Sets of users belonging to a collaboration

    • User must sign the usage guidelines for the VO

    • You will be registered in the VO server (wait for notification)

  • VOs maintained a list of their members on a LDAP Server

    • The list is downloaded by grid machines to map user certificate subjects to local “pool” accounts

    • Sites decide which vos to accept

      • /etc/grid-security/grid-mapfile

...

"/C=CH/O=CERN/OU=GRID/CN=Simone Campana 7461" .dteam

"/C=CH/O=CERN/OU=GRID/CN=Andrea Sciaba 8968" .cms

"/C=CH/O=CERN/OU=GRID/CN=Patricia Mendez Lorenzo-ALICE" .alice

...

ISSGC’06, Ischia, 18.07.2006


Evolution of vo management

Before VOMS

User is authorised as a member of a single VO

All VO members have same rights

Gridmapfiles are updated by VO management software: map the user’s DN to a local account

grid-proxy-init – derives proxy from certificate – the “single sign-on to the grid”

VOMS

User can be in multiple VOs

Aggregate rights

VO can have groups

Different rights for each

Different groups of experimentalists

Nested groups

VO has roles

Assigned to specific purposes

E,g. system admin

When assume this role

Proxy certificate carries the additional attributes

voms-proxy-init

Evolution of VO management

ISSGC’06, Ischia, 18.07.2006


The middleware

Authentication

Request

OK

C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy

Query

AuthDB

VOMSAC

VOMSAC

VOMS

client

VOMS: concepts

Virtual Organization Membership Service:

  • Extends the proxy with info on VO membership, group, roles

  • Fully compatible with GSI

  • Each VO has a database containing

    group membership, roles and capabilities informations for each user

  • User contacts VOMS server requesting his authorization info

  • Server sends authorization info to the client, which includes it in a proxy certificate

[glite-tutor] /home/giorgio > voms-proxy-init --voms gilda

Cannot find file or dir: /home/giorgio/.glite/vomses

Your identity: /C=IT/O=GILDA/OU=Personal Certificate/L=INFN/CN=Emidio [email protected]

Enter GRID pass phrase:

Your proxy is valid until Mon Jan 30 23:35:51 2006

Creating temporary proxy.................................Done

Contacting voms.ct.infn.it:15001 [/C=IT/O=GILDA/OU=Host/L=INFN [email protected]] "gilda"

Creating proxy ...................................... Done

Your proxy is valid until Mon Jan 30 23:35:51 2006

ISSGC’06, Ischia, 18.07.2006


Grid foundation information systems

2171

LDAP

2172

LDAP

2173

LDAP

Update DB

&

Modify DB

Swap DBs

2170

Port Fwd

2170

Port Fwd

Grid foundation: Information Systems

GIP

Cache

  • Generic Information

    Provider (GIP)

    • Provides LDIF

      information about

      a grid service in

      accordance to the

      GLUE Schema

  • BDII: Information system in gLite 3.0 (by LCG)

    • LDAP database that is

      updated by a process

    • More than one DBs is used

      separate read and write

    • A port forwarder is used internally

      to select the correct DB

Provider

Plugin

LDIF

File

Config

File

ISSGC’06, Ischia, 18.07.2006


Grid foundation information systems1

Grid foundation: Information Systems

  • R-GMA: provides a uniform method to access and publish distributed information and monitoring data

    • Used for job and infrastructure monitoring in gLite 3.0

    • Working to

      add

      authorization

  • Service Discovery:

    • Provides a standard set of methods for locating Grid services

    • Currently supports R-GMA, BDII and XML files as backends

    • Will add local cache of information

    • Used by some DM and WMS components in gLite 3.0

ISSGC’06, Ischia, 18.07.2006


Grid foundation computing element

Grid foundation: Computing Element

  • LCG-CE: based on GT2 GRAM

    • To be replaced when other CEs prove to be reliable

  • gLite-CE: based on GSI enabled Condor-C

    • Supported by Condor. More efficient. Uses BLAH (see below)

    • Deployed for the first time in gLite 3.0

  • CREAM: new lightweight web service CE

    • Not in gLite 3 release. Will need exposure to users on dedicated system.

    • WSDL interface

    • Will support bulk submission of jobs from WMS and optimization of input/output file transfer. Uses BLAH

    • Plans are to have a CE with both Condor-C and CREAM interfaces

ISSGC’06, Ischia, 18.07.2006


Grid foundation computing element1

BLAH: interfaces the CE and the local batch system

May handle arbitrary information passing from CE to LRMS

patches to support this and logging for accounting being added now

Used by gLite-CE and CREAM

CEMon: Web service to publish status of a computing resource to clients

Supports synchronous queries and asynchronous notifications

Uses the same information (GIP) used by BDII

In gLite 3 CEMon will be available to the users but the baseline is thatthe WMS queries the BDII

Grid foundation: Computing Element

ISSGC’06, Ischia, 18.07.2006


Grid foundation accounting

Grid foundation: Accounting

  • APEL: Uses R-GMA to propagate and display job accounting information for infrastructure monitoring

    • Reads LRMS log files provided by LCG-CE and BLAH

    • Preparing an update for gLite 3.0 to use the files form BLAH

  • DGAS: Collects, stores and transfers accounting data. Compliant with privacy requirements

    • Reads LRMS log files provided by LCG-CE and BLAH.

    • Stores information in a site database (HLR) and optionally in a central HLR. Access granted to user, site and VO administrators

    • Not yet certified in gLite 3.0. Deployment plan:

      • certify and activate local sensors and site HLR in parallel with APEL

      • replace APEL sensors with DGAS (DGAS2APEL)

      • certify and activate central HLR; perform scalability tests

ISSGC’06, Ischia, 18.07.2006


Grid foundation storage element

Grid foundation: Storage Element

  • Storage Element

    • Common interface: SRMv1,migrating to SRMv2

    • Various implementation from LCG and other external projects

      • disk-based: DPM, dCache / tape-based: Castor, dCache

    • Support for ACLs in DPM (in future in Castor and dCache)

      • After the summer: synchronization of ACLs between SEs

    • Common rfio library for Castor and DPM being added

  • Posix-like file access:

    • Grid File Access Layer (GFAL) by LCG

      • Support for ACL in the SRM layer (currently in DPM only)

      • Support for SRMv2 being added now. In the summer add thread safety and interface to the information system.

    • gLite I/O

      • Support for ACLs from the file catalog and interfaced to Hydra for data encryption

      • Not certified in gLite 3.0. To be dismissed when all functionalities will be also available in GFAL.

ISSGC’06, Ischia, 18.07.2006


High level services catalogues

High Level Services: Catalogues

  • File Catalogs

    • LFC from LCG

      • In June: interface to POOL.

      • In the summer: LFC replication and backup.

    • Fireman

      • Not certified in gLite 3.0. To be dismissed when all functionalities will be available in LFC.

  • Hydra: stores keys for data encryption

    • Being interfaced to GFAL (done by July)

    • Currently only one instance, but in future there will be 3 instances: at least 2 need to be available for decryption.

    • Not yet certified in gLite 3.0. Certification will start soon.

  • AMGA Metadata Catalog: generic metadata catalogue

    • Joint JRA1-NA4 (ARDA) development. Used mainly by Biomed

    • Not yet certified in gLite 3.0. Certification will start soon.

ISSGC’06, Ischia, 18.07.2006


High level services file transfer

High Level Services: File transfer

  • FTS: Reliable, scalable and customizable file transfer

    • Manages transfers through channels

      • mono-directional network pipes

        between two sites

    • Web service interface

    • Automatic discovery of services

    • Support for different user and administrative roles

    • Adding support for

      pre-staging and new

      proxy renewal schema

    • In the medium term

      add support for SRMv2,

      delegation,

      VOMS-aware proxy

      renewal

ISSGC’06, Ischia, 18.07.2006


High level services workload mgmt

High Level Services: Workload mgmt.

  • WMS helps the user accessing computing resources

    • Resource brokering, management of job input/output, ...

  • LCG-RB: GT2 + Condor-G

    • To be replaced when the gLite WMS proves to be reliable

  • gLite WMS: Web service (WMProxy) + Condor-G

    • Management of complex workflows (DAGs) and compound jobs

      • bulk submission and shared input sandboxes

      • support for input files on different servers (scattered sandboxes)

    • Support for shallow resubmission of jobs

    • Job File Perusal: file peeking during job execution

    • Supports collection of information from CEMon, BDII, R-GMA and from DLI and StorageIndex data management interfaces

    • Support for parallel jobs (MPI) when the home dir is not shared

    • Deployed for the first time in gLite 3.0

ISSGC’06, Ischia, 18.07.2006


High level services workflows

Direct Acyclic Graph (DAG) is a set of jobs where the input, output, or execution of one or more jobs depends on one or more other jobs

A Collection is a group of jobs with no dependencies

basically a collection of JDL’s

A Parametric job is a job having one or more attributes in the JDL that vary their values according to parameters

Using compound jobs it is possible to have one shot submission of a (possibly very large, up to thousands) group of jobs

Submission time reduction

Single call to WMProxy server

Single Authentication and Authorization process

Sharing of files between jobs

Availability of both a single Job ID to manage the group as a whole and an ID for each single job in the group

nodeA

nodeB

nodeC

nodeE

nodeD

High Level Services: Workflows

ISSGC’06, Ischia, 18.07.2006


High level services job information

Logging and Bookkeeping service

Tracks jobs during their lifetime (in terms of events)

LBProxy for fast access

L&B API and CLI to query jobs

Support for “CE reputability ranking“: maintains recent statistics of job failures at CE’s and feeds back to WMS to aid planning

Job Provenance: stores long term job information

Supports job rerun

If deployed will also help unloading the L&B

Not yet certified in gLite 3.0.

High Level Services: Job Information

ISSGC’06, Ischia, 18.07.2006


High level services job priorities

High Level Services: Job Priorities

  • GPBOX: Interface to define, store and propagate fine-grained VO policies

    • Based on VOMS groups and roles

    • Enforcement of policies at sites: sites may accept/reject policies

    • Not yet certified in gLite 3.0.

ISSGC’06, Ischia, 18.07.2006


Glite process

gLite process

  • Process controlled by the Technical Coordination Group

  • Task Forces with developers, applications, testers and deployment experts

  • gLite 3.0 adopts a continuous release process:

    • No more big-bang releases with fixed deadlines for all

    • Develop components as requested by users and sites

    • Deploy or upgrade as soon as testing is satisfactory

  • Major releases synchronized with large scale activities of VOs (SCs)

    • Next major release foreseen in autumn

ISSGC’06, Ischia, 18.07.2006


Glite software process

gLite Software Process

JRA1 Development

Directives

Bug Fixing

Software

Serious problem

SA3 Integration

SA3 Testing & Certification

SA1 Pre-Production

Deployment Packages

Testbed Deployment

Problem

Fail

SA1 Production Infrastructure

Pre-Production Deployment

Fail

Integration Tests

Pass

Functional Tests

Pass

Fail

Installation Guide, Release Notes, etc

Scalability Tests

Release

Pass

ISSGC’06, Ischia, 18.07.2006


Summary

Summary

  • gLite 3 being deployed on the production infrastructure

    • Includes all of the well known middleware from LCG 2.7.0

  • New components deployed for the first time on the Production Infrastructure:

    • Address requirements in terms of functionality and scalability

    • Components deployed for the first time need extensive testing!

  • Developed according to a well defined process

    • Controlled by the EGEE Technical Coordination Group

  • Development is continuing to provide increased robustness, usability, and functionality

ISSGC’06, Ischia, 18.07.2006


The middleware

Questions ?

www.glite.org

ISSGC’06, Ischia, 18.07.2006


  • Login