1 / 9

Architecture Review September Release

Architecture Review September Release. Piotr Poznanski Piotr.Poznanski@cern.ch. WP4 Priorities . LCAS 2.0 - July/August server implementation (does not require root privilege, one per many CEs) use of Policy Description Language (PDL) API plug-in upgraded to LCMAPS plug-in API,

graymary
Download Presentation

Architecture Review September Release

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architecture ReviewSeptember Release Piotr Poznanski Piotr.Poznanski@cern.ch

  2. WP4 Priorities • LCAS 2.0 - July/August • server implementation (does not require root privilege, one per many CEs) • use of Policy Description Language (PDL) • API plug-in upgraded to LCMAPS plug-in API, • VOMS plug-in (end of June) • authorization decision based on VO, (sub)group, role • LCMAPS 1.0 - end of June (with plug-ins) • plug-in framework, driven by PDL • supports standard UNIX credential (incl. pool accounts, VO affiliation, site local policy • RMS • support for LSF, Condor • advance reservations • Monitoring/Fault Tolerance • Relational DB backends (Oracle, MySQL) • GUIs (Alarm Display, AnaMon) • Fault Tolerance integrated • Installation & Configuration • outside main TB • No involvement of MW WPs

  3. Local Site Authorization Services • Local Centre Authorization Service (LCAS) • Handles authorization requests to local fabric • Authorization decisions based on proxy user certificate and job specification • Supports grid-mapfile mechanism • Plug-in framework (hooks for external authorization plug-ins) • Allowed users (grid-mapfile or allowed_users.db) • Banned users (ban_users.db) • Available timeslots (timeslots.db) • Plugin for VOMS (to process Authorization data) • Local Credential Mapping Service (LCMAPS) • Provides local credentials needed for jobs in fabric • Plug-in framework, driven by comprehensive policy language • Mapping based on user identity, VO affiliation, site-local policy • Supports standard UNIX credentials (incl. pool accounts), AFS tokens, Krb5

  4. C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy Ye Olde Gatekeeper TLS auth VOMSpseudo-cert assist_gridmap Jobmanager-* EDG Gatekeeper (release 2.1) Gatekeeper LCAS accept policy allowed GSI AuthN timeslot LCAS authZ call out banned • LCMAPS open, learn,&run: • … and return legacy uid Job Manager fork+exec args, submit script

  5. LCMAPS – requirements • Backward compatible with existing systems (grid-mapfile, k5cert) • Support for multiple VOs per user (and thus multiple UNIX groups) • Mimimum system administration • Poolaccounts • Pool”groups” • Understandable configuration • Extendible • Boundary conditions • Has to run in privileged mode • Has to run in process space of incoming connection (for fork jobs)

  6. LCMAPS – control flow GK LCMAPS • User authenticates using (VOMS) proxy • LCMAPS library invoked • Acquire all relevant credentials • Enforce credentials on current process tree at the end • Run job manager • Fork will be OK by default • Batch systems may need primary group explicitly • Batch systems will need updated (distributed) UNIX account info • Order and function: policy-based Credential Acquisition & Enforcement CREDs Job Mngr

  7. LCMAPS – modules • Modules represent atomic functionality • VOMS from role info and local mapfile assign gid (A) • PoolAccounts from username assign unique uid (A) • PoolGroups from (VOMS) groupname assign unique gid (A) • LocalAccount from username assign local existing unique uid (A) • AFS/Krb5 get token based on user DN info (A) • POSIX processsetuid() and setegid() (E) • POSIX LDAP update distributed user database (E) • Krb5 run job via k5cert (E) • …

  8. Decision unit Actuator agent Actuator Actuator Actuator Rule config Fabric Monitoring & Fault Tolerance Consumer DB Consumer Consumer Central Repository Sensor Collector agent Sensor Sensor Cache monitoring Consumer Consumer Local Node

  9. Packages (rpm, pkg) • Software Package Mgmt Agent (SPMA) • SPMA manages the installed packages • Runs on Linux (RPM) or Solaris (PKG) • SPMA configuration done via an NCM component • Can use a local cache for pre-fetching packages (simultaneous upgrades of large farms) Install & Config TB3 arch SWRep Servers http cache SPMA packages Mgmt API nfs SPMA.cfg (RPM, PKG) ACL’s • Automated Installation Infrastructure • DHCP and Kickstart (or JumpStart) are re-generated according to CDB contents • PXE can be set to reboot or reinstall by operator ftp SPMA SPMA NCM Components NCM Node (re)install? • Software Repository • Packages (in RPM or PKG format) can be uploaded into multiple Software Repositories • Client access is using HTTP, NFS/AFS or FTP • Management access subject to authentication/authorization Configuration Information is stored in the local cache. It is accessed via NVA-API Installation server Cdispd PXE CCM PXE handling Mgmt API Registration Notification ACL’s Node Install DHCP • Node Configuration Manager (NCM) • Configuration Management on the node is done by NCM Components • Each component is responsible for configuring a service (network, NFS, sendmail, PBS) • Components are notified by the Cdispd whenever there was a change in their configuration DHCP handling Configuration Data Base (CDB) Configuration Information store. The information is updated in transactions, it is validated and versioned. Pan Templates are compiled into XML profiles KS/JS KS/JS generator Client Nodes CCM CDB

More Related