quattro architecture http cern chquattro German Cancio CERN

. quattro architecture http: //cern. ch/quattro German Cancio CERN IT

. quattro architecture - overview u Configuration Database n CDB (Central Configuration Database) n CCM (Configuration Cache Manager) u Installation: u n AII (Automated Installation Infrastructure) n NCM (Node Configuration Manager) n Software Repository (SWRep) n Software Package Management Agent (SPMA) . quattro home page (under construction) http: //cern. ch/quattro Quattro architecture / German Cancio CERN - n° 2

Configuration DB design Server Modules Configuration Data Base (CDB) Provide different access patterns to Configuration Information store. The information is updated in transactions, it is validated and versioned. Pan Templates are compiled into XML profiles Server Module SQL/LDAP/HTTP GUI CDB pan Pan XML AP I CLI Pan Templates with configuration information are input into CDB via GUI & CLI Cache N VA Installation. . . CCM Node HTTP + notifications • nodes are notified about changes of their configuration • nodes fetch the XML profiles via HTTP Configuration Information is stored in the local cache. It is accessed via NVA-API Quattro architecture / German Cancio CERN - n° 3

Configuration DB status u System in implemented (except for CLI and Server Modules), most of the components in 1. 0 production version, u Pilot deployment of the complete system for LCG 1 using the “panguin” GUI (screenshot next slide) In parallel: u System being consolidated, u Issues of scalability and security being studied and addressed, u Server Modules under development (SQL). More information: http: //cern. ch/hep-proj-grid-config/ Quattro architecture / German Cancio CERN - n° 4

panguin GUI for managing/editing PAN templates Quattro architecture / German Cancio CERN - n° 5

XML profile generated by PAN (lxplus 001) Quattro architecture / German Cancio CERN - n° 6

install design SWRep Servers SPMA NCM SPMA Components NCM Packages (rpm, pkg) SPMA. cfg http nfs ftp cache SPMA Mgmt API ACL’s packages (RPM, PKG) Node (re)install? Installation server Registration Notification CCM Node Install Client Nodes CDB PXE DHCPKS/JS Cdispd PXE handling Mgmt API ACL’s DHCP handling KS/JS generator CCM Quattro architecture / German Cancio CERN - n° 7

install design 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) Packages (rpm, pkg) SPMA. cfg http nfs ftp cache SPMA SWRep Servers Mgmt API ACL’s Automated Installation Infrastructure SPMA NCM Components NCM packages (RPM, PKG) • DHCP and Kickstart (or Jump. Start) are regenerated according to CDB contents • PXE can be set to reboot or reinstall by operator 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 Installation server Registration Notification CCM PXE DHCPKS/JS Cdispd PXE handling Mgmt API ACL’s Node Configuration Manager (NCM) Node DHCP • Configuration Management on the node is handling done by NCM Components • Each component is responsible for configuring a service (network, NFS, sendmail, PBS) KS/JS • Components are notified by the Cdispd generator whenever there was a change in their configuration Install Client Nodes CDB CCM Quattro architecture / German Cancio CERN - n° 8

AII (Automated Installation Infrastructure) u Subsystem u Layer to automate the node base installation via the network on top of existing technologies (base system installer, DHCP, PXE) u Modules: u AII-dhcp: n manage DHCP server for network installation information u AII-nbp n (network bootstrap program): manages the PXE configuration for each node (boot from HD/ start the installation via network) u AII-osinstall: n Manage OS configuration files required by the OS installation procedure (Kick. Start, Jump. Start) u More details in AII design document: http: //edms. cern. ch/document/374559 Quattro architecture / German Cancio CERN - n° 9

AII: current status u Architectural u Detailed u first design finished Design, implementation progressing alpha version expected mid July Quattro architecture / German Cancio CERN - n° 10

Node Configuration Management (NCM) u Client software running on the node which takes care of “implementing” what is in the configuration profile u Modules: n “Components” n Invocation and notification framework n Component support libraries Quattro architecture / German Cancio CERN - n° 11

NCM: Components u “Components” (like SUE “features” or LCFG ‘objects’) are responsible for updating local config files, and notifying services if needed u Components register their interest in configuration entries or subtrees, and get invoked in case of changes u Components n Usually, this implies regenerating and/or updating local config files (eg. /etc/sshd_config) u Use n standard system facilities (Sys. V scripts) for managing services Components can notify services using Sys. V scripts when their configuration changes. u Possible n do only configure the system to define configuration dependencies between components Eg. configure network before sendmail Quattro architecture / German Cancio CERN - n° 12

Component example sub Configure { my ($self) = @_; # access configuration information my $config=NVA: : Config->new(); my $arch=$config->get. Value('/system/architecture’); # NVA API $self->Fail (“not supported") unless ($arch eq ‘i 386’); # (re)generate and/or update local config file(s) open (myconfig, ’/etc/myconfig’); … # notify affected (Sys. V) services if required if ($changed) { system(‘/sbin/service myservice reload’); … } } Quattro architecture / German Cancio CERN - n° 13

NCM (contd. ) u cdispd n (Configuration Dispatch Daemon) Monitors the config profile, and invokes components via the ncd if there were changes u ncd (Node Configuration Deployer): n framework and front-end for executing components (via cron, cdispd, or manually) n Dependency ordering of components u Component n support libraries: For recurring system mgmt tasks (interfaces to system services, sysinfo), log handling, etc u More details in NCM design document http: //edms. cern. ch/document/372643 Quattro architecture / German Cancio CERN - n° 14

NCM: Status u Architectural u Detailed u First design finished (class) design progressing version expected end July u Porting/coding September n of base configuration components completed mid more than 60 components to be ported for having a complete EDG solution (configuring all EDG middleware services)! u Pilot deployment on CERN central interactive/batch facilities expected at the end of the year Quattro architecture / German Cancio CERN - n° 15

SPM (Software Package Mgmt) (I) SWRep (Software Repository): u Client-server u Universal n n repository: Extendable to multiple platforms and package formats (RHLinux/RPM, Solaris/PKG, … others like Debian dpkg) Multiple package versions/releases u Management n n Current implementation using SSH access: via standard protocols HTTP (scalability), but also AFS/NFS, FTP u Replication: n (“product maintainers”) interface: ACL based mechanism to grant/deny modification rights (packages associated to “areas”) u Client n toolsuite for the management of software packages using standard tools (eg. rsync) Availability, load balancing Quattro architecture / German Cancio CERN - n° 16

SPM (Software Package Mgmt) (II) Software Package Management Agent (SPMA): u Runs on every target node u Multiple u Plug-in n u Can n n repositories can be accessed (eg. division/experiment specific) framework allows for portability System packager specific transactional interface (RPMT, PKGT) manage either all or a subset of packages on the nodes Useful for add-on installations, and also for desktops Configurable policies (partial or full control, mandatory and unwanted packages, conflict resolution…) u Addresses n n scalability Packages can be stored ahead in a local cache, avoiding peak loads on software repository servers (simultaneous upgrades of large farms) HTTP protocol allows to use web proxy hierarchies Quattro architecture / German Cancio CERN - n° 17

SPM (Software Package Mgmt) (III) u SPMA functionality: 1. Compares the packages currently installed on the local node with the packages listed in the configuration 2. Computes the necessary install/deinstall/upgrade operations 3. Invokes the packager (rpmt/pkgt) with the right operation transaction set u The n n SPM is driven via a local configuration file For batch/servers: A NCM component generates/maintains this cf file out of CDB information For desktops: Possible to write a GUI for locally editing the cf file Quattro architecture / German Cancio CERN - n° 18

Software Package Manager (SPM) RPMT u RPMT (RPM transactions) is a small tool on top of the RPM libraries, which allows for multiple simultaneous package operations resolving dependencies (unlike RPM) n Example: ‘upgrade X, deinstall Y, downgrade Z, install T’ and verify/resolve appropriate dependencies u Does use basic RPM library calls, no added intelligence u Ports u Will 4. 2 available for RPM 3 and 4. 0. X try to feedback to rpm user community after porting to RPM u CERN IT/PS working on equivalent Solaris port (PKGT) Quattro architecture / German Cancio CERN - n° 19

SPMA & SWRep: current status u First production version available u Being deployed in the CERN Computer Centre (next slide) u Enhanced October u Solaris functionality (package cache management) for mid- port progressing Quattro architecture / German Cancio CERN - n° 20

SPMA/SWRep deployment @ CERN CC u Phased out legacy SW distribution systems (including ASIS) on the central batch/interactive servers (LXPLUS&LXBATCH) n n n Using HTTP as package access protocol (scalability) 1000 nodes currently running it in production Deployment page: http: //cern. ch/wp 4 -install/CERN/deploy u Server clustering solution n For CDB (XML profiles) and SWRep (RPM’s over HTTP) n Replication done with rsync n Load balancing done with simple DNS round-robin n n Currently, 3 servers in production (800 MHz, 500 MB RAM, Fast. Ethernet) giving ~ 3*12 Mbyte throughput Future: may include usage of hierarchical web proxys (eg. using squid) Quattro architecture / German Cancio CERN - n° 21