La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

M.Biasotto, Padova, 6 dicembre 2001 1 Esperienze con la farm CMS a LNL e prospettive del WP4 di DataGrid Massimo Biasotto - LNL.

Presentazioni simili


Presentazione sul tema: "M.Biasotto, Padova, 6 dicembre 2001 1 Esperienze con la farm CMS a LNL e prospettive del WP4 di DataGrid Massimo Biasotto - LNL."— Transcript della presentazione:

1

2 M.Biasotto, Padova, 6 dicembre 2001 1 Esperienze con la farm CMS a LNL e prospettive del WP4 di DataGrid Massimo Biasotto - LNL

3 M.Biasotto, Padova, 6 dicembre 2001 2 Sommario La farm CMS di Legnaro La farm CMS di Legnaro –Configurazione –Installazione e Management –Monitoring Il WP4 (Fabric Management) del progetto Datagrid Il WP4 (Fabric Management) del progetto Datagrid –Overview architettura –Installation & Node Management system –Il prototipo attuale: LCFG –Futuri sviluppi

4 M.Biasotto, Padova, 6 dicembre 2001 3 Layout Farm CMS@LNL FastEth 32 – GigaEth 1000 BT SWITCH N1 FastEth SWITCH 1 8 S1 S16 N24 N1 Nx – Computational Node Dual PIII – 1 GHz 512 MB 3x75 GB Eide disk + 1x20 GB for O.S. 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. FastEth SWITCH N1 2 N24 2001 34 Nodes 8 TB 2001-2-3 up to 190 Nodes S10 2001 10 Servers 3 TB To WAN 34 Mbps 2001 ~ 1Gbps 2002 2001 4400 SI95

5 M.Biasotto, Padova, 6 dicembre 2001 4 Farm CMS@LNL

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

7 M.Biasotto, Padova, 6 dicembre 2001 6 Configurazione GATEWAY SERVERS COMPUTING NODES OS DATA OS LOCAL DATA RAID 0 HW Users home App. software OS RAID 1 HW RAID 0 SW NFS

8 M.Biasotto, Padova, 6 dicembre 2001 7 Installazione Procedura automatica di 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) 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) Kickstart file e script di installazione per ogni tipologia di nodo (attualmente cms_server e cms_client) Linstallazione da zero di un nodo è (quasi) completamente automatica Linstallazione da zero di un nodo è (quasi) completamente automatica

9 M.Biasotto, Padova, 6 dicembre 2001 8 Management Il Gateway è gestito manualmente Il Gateway è gestito manualmente –upgrades, installazione nuovi applicativi, utenti Tutti gli altri nodi gestiti in maniera automatizzata 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 Qualunque nodo può essere reinstallato da zero in ogni momento: in pochi minuti è pronto e configurato

10 M.Biasotto, Padova, 6 dicembre 2001 9 Monitoring Inizialmente con MRTG 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 ( NRG, Orca,... Investigati diversi altri sistemi di monitoring basati su RRDtool ( http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/ ) : NRG, Orca,... http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/ Attualmente in uso remstats 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/ http://cmsfarmgw.lnl.infn.it/remstats/ Ci manca un tool per il monitoraggio delle temperature delle CPU Ci manca un tool per il monitoraggio delle temperature delle CPU

11 M.Biasotto, Padova, 6 dicembre 2001 10 Remstats

12 M.Biasotto, Padova, 6 dicembre 2001 11 Remstats

13 M.Biasotto, Padova, 6 dicembre 2001 12 Remstats vs MRTG

14 M.Biasotto, Padova, 6 dicembre 2001 13 Sviluppi futuri Lattuale gestione della farm è in parte manuale ed in parte automatizzata con tools non molto sofisticati Lattuale 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 lespansione della farm prevista per i prossimi anni questa modalità di gestione risulterà inadeguata Con lespansione 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?

15 M.Biasotto, Padova, 6 dicembre 2001 14 Datagrid Project structured in many Work Packages: 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). 3 year project (2001-2003). Milestones: month 9 (Sept 2001), month 21 (Sept 2002), month 33 (Sept 2003) Milestones: month 9 (Sept 2001), month 21 (Sept 2002), month 33 (Sept 2003)

16 M.Biasotto, Padova, 6 dicembre 2001 15 Farm A (LSF)Farm B (PBS ) Grid User (Mass storage, Disk pools) Local User Installation & Node Mgmt Configuration Management Monitoring & Fault Tolerance Fabric Gridification Resource Management Grid Info Services (WP3) User job control Other Wps Resource Broker (WP1) Data Mgmt (WP2) Grid Data Storage (WP5) Architecture overview Fabric Mgmt - Interface between Grid- wide services and local fabric; - Provides local authentication, authorization and mapping of grid credentials. - Interface between Grid- wide services and local fabric; - Provides local authentication, authorization and mapping of grid credentials. - provides transparent access to different cluster batch systems; - enhanced capabilities (extended scheduling policies, advanced reservation, local accounting). - provides transparent access to different cluster batch systems; - enhanced capabilities (extended scheduling policies, advanced reservation, local accounting). - provides a central storage and management of all fabric configuration information; - central DB and set of protocols and APIs to store and retrieve information. - provides a central storage and management of all fabric configuration information; - central DB and set of protocols and APIs to store and retrieve information. - 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 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 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. - 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.

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

18 M.Biasotto, Padova, 6 dicembre 2001 17 Configuration Management diagram High Level Description High Level Description Low Level Description Low Level Description Cache Configuration Manager Cache Configuration Manager Local Process Local Process Configuration Database APIAPI Client Node Configuration Database: stores configuration information and manages modification and retrieval access Cache Configuration Manager: downloads node profiles from CDB and stores them locally

19 M.Biasotto, Padova, 6 dicembre 2001 18 Configuration DataBase All computing nodes of CMS Farm #3 use cmsserver1 as Application Server cmsserver1 /etc/exports /app cmsnode1, cmsnode2,.. cmsserver1 /etc/exports /app cmsnode1, cmsnode2,.. cmsnode3 /etc/fstab cmsserver1:/app /app nfs.. cmsnode3 /etc/fstab cmsserver1:/app /app nfs.. cmsnode2 /etc/fstab cmsserver1:/app /app nfs.. cmsnode2 /etc/fstab cmsserver1:/app /app nfs.. cmsnode1 /etc/fstab cmsserver1:/app /app nfs.. cmsnode1 /etc/fstab cmsserver1:/app /app nfs.. High Level Description Low Level Description

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

21 M.Biasotto, Padova, 6 dicembre 2001 20 Installation & Software Mgmt Prototype Lattuale prototipo è basato su un tool originariamente sviluppato allUniversità di Edinburgo: LCFG (Large Scale Linux Configuration) http://www.dcs.ed.ac.uk/home/paul/publications/ALS2000/ Lattuale prototipo è basato su un tool originariamente sviluppato allUniversità di Edinburgo: LCFG (Large Scale Linux Configuration) http://www.dcs.ed.ac.uk/home/paul/publications/ALS2000/ Funzionalità principali: 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

22 M.Biasotto, Padova, 6 dicembre 2001 21 A collection of agents read configuration parameters and either generate traditional config files or directly manipulate various services Abstract configuration parameters for all nodes stored in a central repository ldxprof Load Profile Generic Component Profile Object rdxprof Read Profile LCFG Objects Local cache Client nodes Web Server HTTP XML Profile LCFG Config Files Make XML Profile Server LCFG diagram +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 +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 Config files 192.168., 192.135.30...... /home/MickeyMouseHome /bin/tcsh 192.168., 192.135.30...... /home/MickeyMouseHome /bin/tcsh XML profiles Profile Object inet auth /etc/services /etc/inetd.conf /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 /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 /etc/shadow /etc/group /etc/passwd.... mickey:x:999:20::/home/Mickey:/bin/tcsh.... /etc/passwd.... mickey:x:999:20::/home/Mickey:/bin/tcsh....

23 M.Biasotto, Padova, 6 dicembre 2001 22 Cose un oggetto LCFG? È un semplice shell script (ma in futuro sarà usato perl) È 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 Ciascun oggetto fornisce un certo numero di metodi (start, stop, reconfig, query,...) che sono invocati al momento opportuno Funzionamento tipico di un semplice oggetto: Funzionamento tipico di un semplice oggetto: –viene avviato dalloggetto 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)

24 M.Biasotto, Padova, 6 dicembre 2001 23 LCFG: oggetti custom LCFG mette a disposizione gli oggetti per gestire tutti i servizi standard di una macchina: inet, syslog, nfs, cron, dns,... 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: 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 loggetto 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

25 M.Biasotto, Padova, 6 dicembre 2001 24 First boot via floppy or via network Initialization script starts First boot via floppy or via network Initialization script starts LCFG: node installation procedure DHCP Server Software Packages Software Packages IP address Config URL IP address Config URL Root Image with LCFG environment NFS Server LCFG Config Files LCFG Config Files XML Profiles XML Profiles LCFG ServerWEB Server Software Repository Client Node After reboot LCFG objects complete the node configuration Root Image complete with LCFG environment mounted via NFS Load minimal config data via DHCP: IP Address, Gateway, LCFG Config URL Load minimal config data via DHCP: IP Address, Gateway, LCFG Config URL Load complete configuration via HTTP Start object install: disk partitioning, network,... installation of required packages copy of LCFG configuration reboot Start object install: disk partitioning, network,... installation of required packages copy of LCFG configuration reboot

26 M.Biasotto, Padova, 6 dicembre 2001 25 LCFG: summary Pro: 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: 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!)

27 M.Biasotto, Padova, 6 dicembre 2001 26 LCFG: sviluppo futuro ldxprof Load Profile Generic Component Profile Object rdxprof Read Profile LCFG Objects Local cache Client nodes Web Server HTTP XML Profile LCFG Config Files Make XML Profile Server Software Repository (RPMs) Installation Server (DHCP, kernel images installroot) NFS Software Repository (RPMs) FTP HTTP NMA Objects NMA Config Cache Manager Configuration DataBase Bootstrap Service Images PXE TFTP DHCP User Interface

28 M.Biasotto, Padova, 6 dicembre 2001 27 Conclusioni Il prototipo attuale non è ancora usabile in produzione 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 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 questultimo (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) LINFN nel WP4 sta spingendo per avere a Set. 2002 un sistema di Fabric Management realmente usabile nelle nostre farm LINFN nel WP4 sta spingendo per avere a Set. 2002 un sistema di Fabric Management realmente usabile nelle nostre farm


Scaricare ppt "M.Biasotto, Padova, 6 dicembre 2001 1 Esperienze con la farm CMS a LNL e prospettive del WP4 di DataGrid Massimo Biasotto - LNL."

Presentazioni simili


Annunci Google