VOMS Roles support at CMS GRID sites

Introduction

  • Summary of VOMS Roles that need to be supported at CMS GRID sites
  • Percentage of resources assigned for every VOMS role
    • Additional free resources should be awarded to other roles according to the resource percentage or priority
    • A single role should be able to take over all resources if all other roles don't have any work to do
  • Pool accounts for the mapping of various VOMS groups and roles are strongly recommended
    • The lcgadmin Role can be mapped to a single account (this a legacy from the times when we installed CMSSW with this role, and that only supported a single account)
  • The lcgadmin role is used to send most SAM tests
    • Needs almost no fair share (about 1 short job per hour and CE)
    • Needs highest priority to claim the next available slot in order to run SAM test as quickly as possible
  • A note about national VOMS groups, e.g. cms:/cms/dcms (Germany), cms:/cms/escms (Spain) and many others
    • Used by various sites to treat their national users, e.g. to gain write access to the storage
    • Proxies with national groups are valid and must not fail at any site
    • For sites not implementing any special functionality for national VOMS groups should treat them like cms:/cms (just plain CMS voms "user" proxy")
    • The VOMS-admin interface provides
  • The following rules are addressing the pledged resources

Tier-1 sites

  • Last major update June 2015:
    • Main T1 usage pattern:
      • At least half of the pledges resources should be reachable via multi-core pilots
        • The present "standard WLCG multi-core pilot" takes 8 cores
      • With disk/tape migration in place we want a low but ~continues flux of analysis jobs at Tier-1s
      • Analysis jobs sent via GlideinWMS (VOMS role=pilot) should take about 10% of the pledged slots, min 50 slots
        • This should allow for regular execution of glexec SAM test
      • t1production role is not used anymore after the GlideIn WMS frontends were merged, only the production role is used from now on
        • prioritization is done on the frontend level => fractional shares within the CMS T1 allocation are not needed anymore
      • disk/tape separation allows to open the T1 CPU resources for analysis accessing samples on the disk endpoints
    • Remarks on share policy:
      • available CPU resources should be assigned 90% to production role work and 10% to jobs sent via VOMS role pilot (those pilots are taking actually both production and analysis payloads 50/50
      • remaining share can be given to no role with lower priority

Priority order Share in % VOMS role FQAN Comment
highest priority "small" /cms/Role=lcgadmin role for SAM tests, a few short jobs only, needs (almost) no fair share
default priority 90 /cms/Role=production role for production workflows
default priority 10 /cms/Role=pilot pilot role used for analysis jobs sent by Glidein
lower priority 0 any other role and no role Should get resources only when the above roles are not active

Tier-2 sites

Resource Percentage VOMS role FQAN Comment
80% /cms/Role=pilot pilot role currently used by the Global Pool for Analyis and Production jobs
10% /cms/Role=production role for some legacy stuff still using that role
9% any other role and no role analyzers through gLite WMS
about 1% /cms/Role=lcgadmin Almost no share but highest priority to execute SAM tests
Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r12 - 2015-06-17 - ChristophWissing
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback