1. ELFms status and deployment, 25/5/2004 ELFms, status, deployment Germán Cancio for CERN IT/FIO HEPiX spring 2004 Edinburgh 25/5/2004

2. ELFms – German Cancio - n° 2 Outline u ELFms and its subsystems: n Quattor n Lemon n LEAF u Deployment status

3. ELFms – German Cancio - n° 3 ELFms in a nutshell ELFms stands for Extremely Large Fabric management system Subsystems: u : configuration, installation and management of nodes u : system / service monitoring u : hardware / state management u ELFms manages and controls most of the nodes in the CERN CC n ~2100 nodes out of ~ 2400 n Multiple functionality and cluster size (batch nodes, disk servers, tape servers, DB, web, …) n Heterogeneous hardware (CPU, memory, HD size,..) n Linux (RH) and Solaris (9) Node Configuration Management Node Management

4. ELFms – German Cancio - n° 4 http://quattor.org

5. ELFms – German Cancio - n° 5 Quattor Quattor takes care of the configuration, installation and management of fabric nodes A Configuration Database holds the desired state of all fabric elements Node setup (CPU, HD, memory, software RPMs/PKGs, network, system services, location, audit info…) Cluster (name and type, batch system, load balancing info…) Defined in templates arranged in hierarchies – common properties set only once Autonomous management agents running on the node for Base installation Service (re-)configuration Software installation and management Quattor was developed in the scope of EU DataGrid. Development and maintenance now coordinated by CERN/IT

6. ELFms – German Cancio - n° 6 Configuration Database CDB pan GUI Scripts CLI Node CCM Cache XML RDBMS SQLSQL SOAPSOAP HTTPHTTP Node Management Agents LEAF, LEMON, others

7. ELFms – German Cancio - n° 7 Node Management Agents Configuration Database CDB GUI Scripts CLI Node CCM Cache RDBMS SQLSQL SOAPSOAP pan XML HTTPHTTP CERN CC name_srv1: 137.138.16.5 time_srv1: ip-time-1 lxbatch cluster/name: lxbatch master: lxmaster01 pkg_add (lsf5.1) lxplus cluster/name: lxplus pkg_add (lsf5.1) disk_srv lxplus001 eth0/ip: 137.138.4.246 pkg_add (lsf6_beta) lxplus020 eth0/ip: 137.138.4.225 lxplus029

8. ELFms – German Cancio - n° 8 Configuration Database CDB pan Node CCM Cache XML RDBMS SQLSQL HTTPHTTP GUI Scripts CLI SOAPSOAP

9. ELFms – German Cancio - n° 9 Configuration Database CDB pan GUI Scripts CLI Node XML RDBMS SQLSQL SOAPSOAP HTTPHTTP CCM Cache Node Management Agents

10. ELFms – German Cancio - n° 10 Configuration Database CDB pan GUI Scripts CLI Node CCM Cache XML SOAPSOAP HTTPHTTP RDBMS SQLSQL LEAF, LEMON, others

11. ELFms – German Cancio - n° 11 Configuration Database CDB pan GUI Scripts CLI XML RDBMS SQLSQL SOAPSOAP HTTPHTTP Node CCM Cache Node Management Agents

12. ELFms – German Cancio - n° 12 Managing (cluster) nodes Install server base OS dhcp pxe nfs/http Vendor System installer RH73, RHES, Fedora,… System services AFS,LSF,SSH,accounting.. Installed software kernel, system, applications.. CCM Node Configuration Manager (NCM) RPM, PKG nfs http ftp Software Servers packages (RPM, PKG) SWRep packages CDB Standard nodesManaged nodes Install Manager Node (re)install cache SW package Manager (SPMA)

13. ELFms – German Cancio - n° 13 Node Management Agents u NCM (Node Configuration Manager): framework system, where service specific plug-ins called Components make the necessary system changes to bring the node to its CDB desired state Regenerate local config files (eg. /etc/sshd/sshd_config ), restart/reload services (SysV scripts) n Large number of components available (system and Grid services) u SPMA (Software Package Mgmt Agent) and SWRep: Manage all or a subset of packages on the nodes n Full control on production nodes: full control - on development nodes: non-intrusive, configurable management of system and security updates. n Package manager, not only upgrader (roll-back and transactions) u Portability: Generic framework; plug-ins for NCM and SPMA available for RHL (RH7, RHES3) and Solaris 9 u Scalability to O(10K) n Automated replication for redundant / load balanced CDB/SWRep servers n Use scalable protocols eg. HTTP and replication/proxy/caching technology (slides here)slides here

14. ELFms – German Cancio - n° 14 http://cern.ch/lemon

15. ELFms – German Cancio - n° 15 Lemon – LHC Era Monitoring

16. ELFms – German Cancio - n° 16 LEMON u MSA Agent available since early 2002 n Continuous functionality improvements, specially in the sensor and repository interface n Large amount of sensors n Ported to and tested on Solaris u Stable Oracle-backend MR since Sept 2003 n Keeps current and historical samples – no aging out of data but archiving n Flat-file MR available as well u The Correlation Engine framework allows plug-in correlations accessing collected metrics and external information (eg. quattor CDB, LSF) n Eg. average number of users on LXPLUS, total number of active LCG batch nodes u An actuator sensor is being developed for local fault recovery n Eg. cleaning up /tmp if occupancy > x %, restart daemon D if dead u RRD based status display pages n See Miros talk (next!) for more details u As with Quattor, LEMON is an EDG development now maintained by CERN/IT

17. ELFms – German Cancio - n° 17 http://cern.ch/leaf

18. ELFms – German Cancio - n° 18 LEAF – LHC Era Automated Fabric LEAF (LHC Era Automated Fabric): Collection of workflows for automated node hardware and state management n HMS: Hardware Management System n SMS: State Management System u HMS and SMS interface to Quattor and LEMON (or rather: sit on top!) for setting/getting node information respectivel u HMS and SMS report desired and current state of the nodes, and progress trough the workflows

19. ELFms – German Cancio - n° 19 LEAF: HMS and SMS u HMS (Hardware Management System): n Track systems trough all steps in lifecycle eg. installation, moves, vendor calls, retirement n Handle multiple nodes at a time (eg. racks) n Automatically requests installs, retires etc. to technicians n PC finder to locate equipment physically n HMS implementation is CERN specific, but concepts and design should be generic u SMS (State Management System): n Automated handling high-level configuration steps, eg. s Reconfigure and reboot all LXPLUS nodes for new kernel s Reallocate nodes inside LXBATCH for Data Challenges s Drain and reconfig node X for diagnosis / repair operations n extensible framework – plug-ins for site-specific operations possible n Issues all necessary (re)configuration commands on top of quattor CDB and NCM s Uses a state transition engine

20. ELFms – German Cancio - n° 20 LEAF screenshots

21. ELFms – German Cancio - n° 21 ELFms status – Quattor (I) u Manages (almost) all Linux boxes in the computer centre n ~ 2100 nodes, to grow to ~ 8000 in 2006-8 n LXPLUS, LXBATCH, LXBUILD, disk and tape servers, Oracle DB servers n Solaris clusters, server nodes and desktops to come for Solaris9 u Starting: head nodes using Apache proxy technology for software and configuration distribution u Misc developments pending, like n Fine-grained ACL protection to templates n HTTPS instead of HTTP for CDB profile and SW transport

22. ELFms – German Cancio - n° 22 ELFms status – Quattor (II) u LCG-2 WN configuration components available n Configuration components for RM, EDG/LCG setup, Globus n Progressive reconfiguration of LXBATCH nodes as LCG-2 WNs u Community driven effort to use quattor for general LCG-2 configuration n Coordinated by staff from IN2P3 and NIKHEF n Aim is to provide a complete porting of EDG-LCFG config components to Quattor n CERN and UAM Madrid providing generic installation instructions and site- independent packaging, as well as a Savannah development portalSavannah development portal u EGEE has chosen quattor for managing their integration testbeds u Tier1/2 sites as well as LHC experiments evaluating using quattor for managing their own farms

23. ELFms – German Cancio - n° 23 ELFms status – LEMON (I) u Smooth production running of MSA agent and Oracle-based repository at CERN-CC n 150 metrics sampled every 30s -> 1d n ~ 1 GB of monitoring data / day on ~ 2100 nodes n New sensors and metrics, eg. tape robots, temperature, SMART disk info u GridICE project uses LEMON for data collection u Gathering experiment requirements and interfacing to grid-wide monitoring systems (MonaLisa, GridICE) n Good interaction with, and gathered feedback from CMS DC04 n Archived raw monitoring data will be used for CMS computing TDR u Visualization: n Operators - Test interface to new generation alarm systems (LHC control alarm system) n Sys managers - Finish status display pages (Miros talk)

24. ELFms – German Cancio - n° 24 ELFms status – LEMON (II) u Work on redundancy solutions for Monitoring Repository (homegrown and/or Oracle Streams) u Quality of Service indicators, correlations and actuators (in collaboration with BARC India) n Ie. tell LEAF to reassign two more nodes from LXBATCH to LXPLUS since capacity insufficient) n Provide batch job mix indicators for improved I/O and CPU load equilibrium

25. ELFms – German Cancio - n° 25 ELFms status - LEAF u HMS in full production for all nodes in CC n HMS heavily used during CC node migration u SMS in production for LXBATCH u Next steps: n Deploy SMS across more clusters n Tighter HMS/SMS integration (automatic put nodes in and out production during eg. rack moves) u Developing asset management GUI replacing PC finder n Client of HMS and SMS n Drag&drop nodes to automatically initiate HMS moves n Multiple select nodes, then initiate action eg. kernel upgrade

26. ELFms – German Cancio - n° 26 Summary u ELFms is deployed in production at CERN n Stabilized results from 3-year developments within EDG and LCG n Established technology n Providing real added-on value for day-to-day operations u Quattor and LEMON are generic software n Other projects and sites getting involved u Site-specific workflows and glue scripts can be put on top for smooth integration with existing fabric environments n LEAF HMS and SMS u CERN will help with Quattor (and LEMON) deployment at other sites n We provide site-independent software and installation instructions n Collaboration for providing missing pieces, eg. configuration components, GUIs, beginners user guides? u More information: http://cern.ch/elfmshttp://cern.ch/elfms

27. ELFms – German Cancio - n° 27 Improvements wrt EDG-LCFG u New and powerful configuration language n True hierarchical structures n Extendable data manipulation language n (user defined) typing and validation u SQL query backend u Portability n Plug-in architecture -> Linux and Solaris u Enhanced components n Sharing of configuration data between components now possible n New component support libraries n Native configuration access API (NVA-API) u Stick to the standards where possible n Installation subsystem uses system installer n Components dont replace SysV init.d subsystem u Modularity n Clearly defined interfaces and protocols n Mostly independent modules n light functionality built in (eg. package management) u Improved scalability n Enabled for proxy technology n NFS mounts not necessary any longer u Enhanced management of software packages n ACLs for SWRep n Multiple versions installable n No need for RPM header files u Last but not least…: Support! n EDG-LCFG is frozen and obsoleted (no ports to newer Linux versions) n LCFG -> EDG-LCFGng -> quattor

28. ELFms – German Cancio - n° 28 Differences with ASIS/SUE SUE: u Focus on configuration, not installation u Powerful configuration language n True hierarchical structures n Extendable data manipulation language n (user defined) typing and validation n Sharing of configuration data between components now possible u Central Configuration Database u Supports unconfiguring services u Improved depenency model n Pre/post dependencies u Revamped component support libraries ASIS: u Scalability n HTTP vs. shared file system u Supports native packaging system (RPM, PKG) u Manages all software on the node u real Central Configuration database u (But: no end-user GUI, no package generation tool)

29. ELFms – German Cancio - n° 29 Differences with ROCKS u Rocks: better documentation, nice GUI, easy to setup u Design principle: reinstall nodes in case of configuration changes n No configuration or software updates on running systems n Suited for production? Efficiency on batch nodes, upgrades / reconfigs on 24/24,7/7 servers (eg. gzip security fix, reconfig of CE address on WNs) u Assumptions on network structure (private,public parts) and node naming u No indication on how to extend the predefined node types or extend the configured services u Limited configuration capacities (key/value) u No multiple package versions (neither on repository, nor simultaneously on a single node) n Eg. different kernel versions on specific node types u Works only for RH Linux (Anaconda installer extensions)

30. ELFms – German Cancio - n° 30 NCM Component example [...] sub Configure { my ($self,$config) = @_; # access configuration information my $arch=$config->getValue('/system/architecture); # CDB API $self->Fail (not supported") unless ($arch eq i386); # (re)generate and/or update local config file(s) open (myconfig,/etc/myconfig); … # notify affected (SysV) services if required if ($changed) { system(/sbin/service myservice reload); … } sub Unconfigure {... }

31. ELFms – German Cancio - n° 31 Key concepts behind quattor u Autonomous nodes: n Local configuration files n No remote management scripts n No reliance on global file systems AFS/NFS u Central control: n Primary configuration is kept centrally (and replicated on the nodes) n A single source for all configuration information u Reproducibility: n Idempotent operations n Atomicity of operations u Scalability: n Load balanced servers, scalable protocols u Use of standards: n HTTP, XML, RPM/PKG, SysV init scripts, … u Portability: n Linux, Solaris