170 likes | 347 Views
ASIS et le projet EU DataGrid (EDG). Germán Cancio IT/FIO. Outline. ASIS reminder EDG WP4 and software distribution Comparison. ASIS: reminder. ASIS: stands for ‘Application Software Installation Service’ Started 1993; joint project between CERN/IT and EPF Lausanne Package generation:
E N D
ASIS et le projet EU DataGrid (EDG) Germán Cancio IT/FIO
Outline • ASIS reminder • EDG WP4 and software distribution • Comparison
ASIS: reminder • ASIS: stands for ‘Application Software Installation Service’ • Started 1993; joint project between CERN/IT and EPF Lausanne • Package generation: • assisted multiplatform application compilation (HAPPI) • Repository management: • Adding/removing/upgrading packages (HAPPI, ASIStm) • Repository replication (ASISlcm) • Client access (over shared file system) • Configurable agent (ASISwsm/p) • Repository contents at CERN: • CERNLIB, CASTOR, Compilers, GNU tools, LaTeX, editors… • Focus on providing an uniform application layer on multiple UN*X platforms
Clients 3/03: 3710 ASIS at CERN: evolution … Clients 10/99: 1680
… today’s changed environment… Since ASIS was designed… • RISC phaseout: • Only 2 CERN-IT supported Un*x OS (Linux & Solaris) • Large scale farms (LXBATCH scaling up to O(10K)) • Mature and reliable vendor package managers • RPM (RH Linux), PKG (Solaris) • Large number of default packages shipped with OS distros • RH73: ~ 700 packages, Solaris 8: ~ 410 packages • Availability of large local disks • Packages don’t have to be ‘links only’ to application servers
… and its impact on ASIS • ASIS cannot easily handle ‘foreign’ packages (packages not generated by ASIShappi) • More and more applications already bundled with Linux distros -> no need for generating them with ASIS • RH61: 510 packages provided via ASIS, RH73: 160 • ASIS is built around a shared file system between repository, configuration database and clients. • File system scalability issues • Inside the ASIS project, the decision taken was to minimize further development efforts, and to participate in the design of the EDG fabric management work package.
EDG WP4 • WP4 is the ‘fabric management’ work package of the EU DataGrid project. • Objective: • To develop system management tools for enabling the deployment of very large computing fabrics […] with reduced sysadmin and operation costs. • Includes solutions for • automated from scratch node installation • node configuration/reconfiguration • software storage, distribution and installation • storing, maintaining and retrieving configuration information.
WP4 tools used for SW distribution (I) SWRep (Software Repository): • Client-server toolsuite for the management of software packages • Universal repository: • Extendable to multiple platforms and package formats (RHLinux/RPM, Solaris/PKG,… others like Debian dpkg) • Multiple package versions/releases • Management (“product maintainers”) interface: • ACL based mechanism to grant/deny modification rights • Current implementation using SSH • Client access: via standard protocols • HTTP (scalability), but also AFS/NFS, FTP • Replication: using standard tools (eg. rsync)
Linux Base packages LXBATCH CC packages EDG/LCG m/ware lxbatch444 lxbatch445 lxbatch446 WP4 tools used for SW distribution (II) Central Configuration Database (CDB): • Common store for configuration information • …including what software packages to deploy from which repository on which nodes • Configuration information can be arranged in templates: • Possible to create template combinations/hierarchies to match service structures • Each template can be maintained (using a GUI) by a different person • Configuration information is validated and kept under version control using transactions
WP4 tools used for SW distribution (III) Software Package Management Agent (SPMA): • Runs on every target node • Configurable locally or via CDB • Multiple repositories can be accessed (eg. division/experiment specific) • Plug-in framework allows for portability • System packager specific transactional interface (RPMT, PKGT) • Can 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…) • Addresses scalability • Packages can be stored ahead in a local cache, avoiding peak loads on software repository servers (simultaneous upgrades of large farms)
Mgmt API Mgmt API SUE/ NCM http ftp nfs afs Packages Repository B WP4 SW distribution architecture inventory Repository A CDB CLI packages config (RPM, PKG) GUI Client nodes SPMA.cfg cache SPMA
Comparison: Software Repository Management access: • Both ASIStm and WP4’s SWRep provide authentication, and authorization mechanisms (using ACL’s) Client access: • ASIS: shared file system required. • WP4: Can be any of HTTP, NFS, AFS, FTP Replication: • The ASIS replication tool (ASISlcm) replicates both the repository contents and the default configuration. • WP4 does not require a specific tool for repository replication: standard tools (eg. rsync) already exist.
Comparison: Software update client • SPMA can do everything ASISwsm(p) can do • Almost same design team… • SPMA can do more: • Manage all packages (system and applications) • Designed to use the system packagers (RPM, PKG) • Multiple repository access protocols • Cache management • Configuration: • In ASIS, only one default configuration profile • WP4 CDB: any number of profiles, version control • Configuration GUI: • ASIS provides a end-user GUI (tkwsm) • The WP4 CDB GUI (PanGUIn) is targeted towards sysadmins, but end-user GUI feasible
Comparison: Package generation Package generation: • ASIShappi can build applications for any UN*X platform. • Application building is not addressed by WP4. • EDG uses the standard RPM build mechanisms • No equivalent build mechanism available for Solaris
Status and Documentation • > 700 nodes using SPMA at CERN (LXPLUS and LXBATCH) • To become >1000 before the end of the summer • Software Repository: HTTP based server clustering solution • Load balanced using DNS round robin • Replication done using rsync • Two platforms: RH73 and RH Enterprise Server 2.1 • WP4 home page: • http://cern.ch/hep-proj-grid-fabric • WP4 installation task: • http://cern.ch/wp4-install