Architectural Framework Presentation Vincenzo Ciaschini CNAF 15/5/06

Objective: To describe a flexible infrastructure for VO-based CE management. –Generalities only: Details will be given by the other presentations.

Requirements: VO should be able to: –Dynamically change the way groups/roles utilize resources. –Collect usage and historical informations. –Implement quotas Differentiate resource usage inside a VO. –Impossible with the current setup. Collect and use accounting informations.

Concepts: CE offer different service classes to different groups of users and to different VOs. –E.g: atlasgold, atlassilver, atlasbronze Users are mapped onto different groups. –E.g: /atlas/production, /atlas/analysis The internal configuration of a CE is a sensitive matter.

Components Needed VOMS –To define groups for users. G-PBox –To map users to service classes. –To dynamically change the association between users and classes. DGAS –Accounting information. WMS –Job brokering.

Architectural Schema VOMS RB VO G-PBox CESite G-PBoxSite HLR VO HLR

Job Submission VOMS RB VO G-PBox CESite G-PBoxSite HLR VO HLR Creds Job + Creds

Policy Manipulation VOMS VO G-PBox CESite G-PBox VO Admin

Setup of the CE Create one queue for VO. Create several local pools for VO, each with its own fair share. Publish the supported service classes.

Contents of the Site G-PBox Policies mapping service classes to the corresponding local accounts. (private) Policies mapping groups/roles to service classes. (public, from VO G-PBox)

Contents of the VO G-PBox Policies mapping groups/roles to service classes (public, transmitted to Site G- PBoxes) Policies to filter CEs on the base of the mapping policies and the service classes implemented by the CE

Advantages: Mapping of users to service classes can be changed dynamically. Easy to discover what service classes are supported by each CE. No need to rely on publication of FQAN for CE selection from RB. –IS is insecure. XACML semantics allow much more complex policies.