Esperienze con la farm CMS a LNL e prospettive del WP4 di DataGrid

1. Esperienze con la farm CMS a LNLe prospettive del WP4 di DataGrid Massimo Biasotto - LNL

2. Sommario • La farm CMS di Legnaro • Configurazione • Installazione e Management • Monitoring • Il WP4 (Fabric Management) del progetto Datagrid • Overview architettura • Installation & Node Management system • Il prototipo attuale: LCFG • Futuri sviluppi

3. Layout Farm CMS@LNL 1 8 2 2001-2-3 up to 190 Nodes N24 N24 N1 2001 34 Nodes 8 TB N24 N1 N1 FastEth FastEth FastEth SWITCH SWITCH SWITCH To WAN 34 Mbps 2001 ~ 1Gbps 2002 2001 4400 SI95 32 – GigaEth 1000 BT 2001 10 Servers 3 TB S16 S1 S10 Sx – Disk Server Node Dual PIII – 1 GHz Dual PCI (33/32 – 66/64) 512 MB 4x75 GB Eide Raid disks (exp up to 10) 1x20 GB disk O.S. Nx – Computational Node Dual PIII – 1 GHz 512 MB 3x75 GB Eide disk + 1x20 GB for O.S.

4. Farm CMS@LNL

5. Farm CMS@LNL 19” rack (5 kW) for network Equipments, Disks, etc. max 64 PC (20 kW) x shelf (4 modules) ~ 6 KSI95 Now max 30 1U PC (10 kW) x rack max 16 PC (5 kW) x shelf module ~ 3 KSI95 Now ~ 25 TB Now 7 m 2001 2002 T2+ Rif. ~ 70 KSI95 ~ 250 TB T2+ Evolution T2+ Prototype Replacing old shelfs with 19” racks Max 1000 Boxes Max 200 Box 10 m

6. Configurazione OS OS LOCAL DATA DATA RAID 0 HW RAID 0 SW COMPUTING NODES SERVERS NFS Users home App. software OS RAID 1 HW GATEWAY

7. Installazione • Procedura automatica di installazione • network boot (DHCP) • RedHat Kickstart (tftp + nfs) • script di configurazione iniziale • ANIS: script per automatizzare la gestione dei vari servizi necessari alla procedura (DHCP, tftp, nfs, kickstart files) • Kickstart file e script di installazione per ogni tipologia di nodo (attualmente cms_server e cms_client) • L’installazione da zero di un nodo è (quasi) completamente automatica

8. Management • Il Gateway è gestito manualmente • upgrades, installazione nuovi applicativi, utenti • Tutti gli altri nodi gestiti in maniera automatizzata • home utenti e software montati via NFS dal gateway • upgrades e modifiche di configurazione tramite scripts (con aggiornamento degli scripts di ANIS) • semplice tool (“distributed shell”) per esecuzione di comandi su tutti i nodi (o parte di essi) • files utenti (passwd, group) distribuiti dal gateway tramite rdist • Qualunque nodo può essere reinstallato da zero in ogni momento: in pochi minuti è pronto e configurato

9. Monitoring • Inizialmente con MRTG • pesante impatto sul server (gateway) • instabile: molti problemi quando un nodo non risponde • Investigati diversi altri sistemi di monitoring basati su RRDtool ( http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/ ): NRG, Orca, ... • Attualmente in uso ‘remstats’ • http://silverlock.dgim.crc.ca/remstats/release • molto più leggero di MRTG, più flessibilità nella creazione di grafici, impostazione di ‘alerts’, facilmente espandibile • però funziona in modalità sequenziale e non parallela • http://cmsfarmgw.lnl.infn.it/remstats/ • Ci manca un tool per il monitoraggio delle temperature delle CPU

10. Remstats

11. Remstats

12. Remstats vs MRTG

13. Sviluppi futuri • L’attuale gestione della farm è in parte manuale ed in parte automatizzata con tools non molto sofisticati • utilizzo di molti custom-scripts • molte delle soluzioni non sono scalabili • Con l’espansione della farm prevista per i prossimi anni questa modalità di gestione risulterà inadeguata • possibilità di utilizzare i tools di fabric management del WP4 di Datagrid?

14. Datagrid • Project structured in many “Work Packages”: • WP1: Workload Management • WP2: Data Management • WP3: Monitoring Services • WP4: Fabric Management • WP5: Mass Storage Management • WP6: Testbed • WP7: Network • WP8-10: Applications • 3 year project (2001-2003). • Milestones: month 9 (Sept 2001), month 21 (Sept 2002), month 33 (Sept 2003)

15. Other Wps Fabric Mgmt User job control - provides the tools for gathering and storing performance, functional and environmental changes for all fabric elements; - central measurement repository provides health and status view of services and resources; - fault tolerance correlation engines detect failures and trigger recovery actions. Architecture overview - Interface between Grid-wide services and local fabric; - Provides local authentication, authorization and mapping of grid credentials. ResourceBroker(WP1) Grid InfoServices(WP3) Grid User FabricGridification Data Mgmt(WP2) - provides transparent access to different cluster batch systems; - enhanced capabilities (extended scheduling policies, advanced reservation, local accounting). Monitoring &Fault Tolerance ResourceManagement Local User Farm A (LSF) Farm B (PBS) Grid DataStorage(WP5) ConfigurationManagement - provides the tools to install and manage all software running on the fabric nodes; - bootstrap services; software repositories; Node Management to install, upgrade, remove and configure software packages on the nodes. - provides a central storage and management of all fabric configuration information; - central DB and set of protocols and APIs to store and retrieve information. (Mass storage, Disk pools) Installation &Node Mgmt

16. MR MSA Monitoring & Fault Tolerance diagram Monitoring User Interface - graphical interface to the Measurement Repository Human operator host Measurement Repository - stores timestamped information; it consists of local caches on the nodes and a central repository server MS MS MS MUI Fault Tolerance Correlation Engine - processes measurements of metrics stored in MR to detect failures and possibly decide recovery actions Central repository Service master node Data Base MR server FTCE Actuator Dispatcher - used by FTCE to dispatch Fault Tolerance Actuators; it consists of an agent controlling all actuators on a local node Local node cache FTCE AD Control flow Fault Tolerance Actuator - executes automatic recovery actions Data flow Monitoring Sensor Agent - collects data from Monitoring Sensors and forwards them to the Measurement Repository FTA MS Monitoring Sensor - performs measurement of one or several metrics;

17. Configuration Management diagram Cache Configuration Manager: downloads node profiles from CDB and stores them locally Configuration Database: stores configuration information and manages modification and retrieval access Configuration Database Client Node Local Process Cache Configuration Manager A P I High Level Description Low Level Description

18. Configuration DataBase Low LevelDescription High LevelDescription cmsserver1 /etc/exports /app cmsnode1, cmsnode2, .. All computing nodes of CMS Farm #3 use cmsserver1 as Application Server cmsnode3 /etc/fstab cmsserver1:/app /app nfs.. cmsnode2 /etc/fstab cmsserver1:/app /app nfs.. cmsnode1 /etc/fstab cmsserver1:/app /app nfs..

19. Installation Management diagram Software Repository - central fabric store for Software Packages Bootstrap Service - service for initial installation of nodes Node Management Agent - manages installation, upgrade, removal and configuration of software packages

20. Installation & Software Mgmt Prototype • L’attuale prototipo è basato su un tool originariamente sviluppato all’Università di Edinburgo: LCFG (Large Scale Linux Configuration)http://www.dcs.ed.ac.uk/home/paul/publications/ALS2000/ • Funzionalità principali: • installazione automatica del S.O. • installazione/upgrade/remove di tutti i pacchetti software (rpm-based) • configurazione e gestione centralizzata delle macchine • estendibilità: configurazione e gestione di software applicativo custom

21. <inet> <allow cfg:template="allow_$ tag_$ daemon_$"> <allow_RECORD cfg:name="telnet"> <allow>192.168., 192.135.30.</allow> </allow_RECORD> ..... </auth> <user_RECORD cfg:name="mickey"> <userhome>/home/MickeyMouseHome</userhome> <usershell>/bin/tcsh</usershell> </user_RECORD> XML profiles Config files +inet.services telnet login ftp +inet.allow telnet login ftp sshd +inet.allow_telnet ALLOWED_NETWORKS +inet.allow_login ALLOWED_NETWORKS +inet.allow_ftp ALLOWED_NETWORKS +inet.allow_sshd ALL +inet.daemon_sshd yes ..... +auth.users myckey +auth.userhome_mickey /home/mickey +auth.usershell_mickey /bin/tcsh LCFG Config Files Read Profile Load Profile HTTP rdxprof ldxprof /etc/shadow Profile Generic /etc/group Object Make XML Profile Component /etc/passwd .... mickey:x:999:20::/home/Mickey:/bin/tcsh .... Web Server Local cache /etc/services XML Profile LCFG Objects /etc/inetd.conf Profile /etc/hosts.allow in.telnetd : 192.168., 192.135.30. in.rlogind : 192.168., 192.135.30. in.ftpd : 192.168., 192.135.30. sshd : ALL Object Client nodes Server inet auth LCFG diagram Abstract configuration parameters for all nodes stored in a central repository A collection of agents read configuration parameters and either generate traditional config files or directly manipulate various services

22. Cos’e’ un oggetto LCFG? • È un semplice shell script (ma in futuro sarà usato perl) • Ciascun oggetto fornisce un certo numero di “metodi” (start, stop, reconfig, query, ...) che sono invocati al momento opportuno • Funzionamento tipico di un semplice oggetto: • viene avviato dall’oggetto ‘profile’ a seguito di notifica di un cambiamento di configurazione • carica dalla cache locale la sua configurazione • configura gli opportuni servizi, o traducendo i parametri di config nei tradizionali files di config oppure controllando direttamente i servizi (ad es. avviando un demone con i parametri della command-line derivati dalla configurazione)

23. LCFG: oggetti custom • LCFG mette a disposizione gli oggetti per gestire tutti i servizi standard di una macchina: inet, syslog, nfs, cron, dns, ... • Un amministratore può creare nuovi oggetti custom per configurare e gestire le proprie applicazioni: • definisce le proprie “risorse” custom (parametri di configurazione) da aggiungere al profilo di un nodo • include nel nuovo script l’oggetto “generic”, in cui sono definite delle “common functions” usate da tutti gli oggetti (config loading, log, output, ...) • sovrascrive i metodi standard (start, stop, reconfig, ...) con il proprio codice custom • per oggetti semplici in genere si tratta di poche righe di codice

24. LCFG: summary • Pro: • A Edinburgo è in uso da anni in un ambiente complesso ed eterogeneo, con centinaia di nodi da gestire • Supporta la completa installazione e gestione di tutto il software (sia O.S. che applicazioni) • Molto flessibile e facile da estendere e customizzare • Contro: • Complesso: curva di apprendimento iniziale molto ripida • Nello stato attuale è ancora un prototipo: incompleto e probabilmente la versione futura non sarà del tutto compatibile • Mancanza di tools user-friendly per la creazione e gestione dei files di configurazione (ed eventuali errori possono essere molto pericolosi!)

25. Software Repository (RPMs) Read Profile Load Profile FTPHTTP DHCP HTTP Images PXETFTP rdxprof ldxprof Profile BootstrapService Generic Object Component Web Server Local cache XML Profile ConfigCacheManager NMA LCFG Objects UserInterface Configuration DataBase Client nodes NMA Objects LCFG: sviluppo futuro Software Repository (RPMs) Installation Server (DHCP, kernel images installroot) NFS LCFG Config Files Make XML Profile Server

26. Conclusioni • Il prototipo attuale non è ancora usabile in produzione • incompleto, bugs, mancanza del DB di configurazione, parzialmente incompatibile con la prossima release • Prossima milestone: settembre 2002 • il sistema di installazione e management dovrebbe essere sufficientemente completo e usabile • sarà integrato con il DB di configurazione, ma abbiamo dei dubbi su quest’ultimo (solo un prototipo, mancanza di adeguata interfaccia utente) • il sistema di monitoring sarà solo un prototipo (alcuni sensori, protocollo di trasporto dei dati, repository e display solo degli allarmi) • L’INFN nel WP4 sta spingendo per avere a Set. 2002 un sistema di Fabric Management realmente usabile nelle nostre farm