Esperienze con la farm CMS a LNL
e prospettive del WP4 di DataGrid
Massimo Biasotto - LNL
M.Biasotto, Padova, 6 dicembre 2001
1
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
M.Biasotto, Padova, 6 dicembre 2001
2
Layout Farm CMS@LNL
2001
34 Nodes
8 TB
N1
1
N1
2
8
FastEth
FastEth
SWITCH
SWITCH
SWITCH
S1
S10
N24 2001-2-3
up to 190
Nodes
To WAN
34 Mbps 2001
~ 1Gbps 2002
32 – GigaEth 1000 BT
Nx – Computational Node
Dual PIII – 1 GHz
512 MB
3x75 GB Eide disk + 1x20 GB for O.S.
M.Biasotto, Padova, 6 dicembre 2001
N1
N24
FastEth
2001
4400 SI95
2001
10 Servers
3 TB
N24
S16
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.
3
Farm CMS@LNL
M.Biasotto, Padova, 6 dicembre 2001
4
Farm CMS@LNL
19” rack (5 kW)
for network
Equipments,
Disks, etc.
max 16 PC (5 kW)
x shelf module
max 64 PC (20 kW)
x shelf (4 modules)
~ 6 KSI95 Now
max 30 1U
PC (10 kW) x rack
~ 3 KSI95 Now
T2+ Rif.
~ 70 KSI95
~ 250 TB
2002
2001
7m
~ 25 TB Now
T2+ Prototype
Max 200 Box
T2+ Evolution
Replacing old shelfs with 19” racks
Max 1000 Boxes
10 m
M.Biasotto, Padova, 6 dicembre 2001
5
Configurazione
OS
OS
LOCAL
DATA
RAID 0 SW
DATA
RAID 0 HW
COMPUTING NODES
SERVERS
NFS
Users home
App. software
OS
RAID 1 HW
GATEWAY
M.Biasotto, Padova, 6 dicembre 2001
6
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
M.Biasotto, Padova, 6 dicembre 2001
7
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
M.Biasotto, Padova, 6 dicembre 2001
8
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
M.Biasotto, Padova, 6 dicembre 2001
9
Remstats
M.Biasotto, Padova, 6 dicembre 2001
10
Remstats
M.Biasotto, Padova, 6 dicembre 2001
11
Remstats vs MRTG
M.Biasotto, Padova, 6 dicembre 2001
12
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?
M.Biasotto, Padova, 6 dicembre 2001
13
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)
M.Biasotto, Padova, 6 dicembre 2001
14
- provides the tools for
gathering and storing
performance, functional
and environmental
changes for all fabric
elements; User job control
Architecture overview
- Interface between Gridwide services and local
fabric;
- Provides local
authentication, Grid User
authorization and
mapping of grid
credentials.
Resource
Broker
(WP1)
Fabric
Gridification
Data Mgmt
- provides transparent
(WP2)
access to different
cluster batch systems;
- enhanced capabilities
(extended scheduling
policies, advanced Local User
reservation, local
accounting).
Resource
Management
Farm A (LSF)
M.Biasotto, Padova, 6 dicembre 2001
- central measurement
Mgmt
repository Fabric
provides
health
and status view of
services and
resources;
Other
Wps
- fault tolerance
correlation engines detect
failures and trigger
recovery actions.
Monitoring &
Fault Tolerance
Farm B (PBS)
Data
- provides theGrid
tools
to install
Storage
and manage all software
(WP5) nodes;
running on the fabric
(Mass storage,
- bootstrap services;
Disk pools)
software repositories;
Node
Management to install,
upgrade, remove and
configure software packages
on the nodes.
Grid Info
Services
(WP3)
Configuration
Management
Installation &
Node Mgmt
- provides a central storage
and management of all
fabric configuration
information;
- central DB and set of
protocols and APIs to store
and retrieve information. 15
Monitoring & Fault Tolerance diagram
Monitoring User
Interface - graphical
interface to the
Measurement Repository
Human operator host
Measurement Repository
MS MS
MS
stores timestamped
MUI
information; it consists of
local caches on the nodes and
a central repository server
Central repository
Data
Base
FTCE
Fault Tolerance Correlation
Engine - processes
measurements of metrics stored
in MR to detect failures and
possibly decide recovery actions
AD
Actuator Dispatcher - used
by FTCE to dispatch Fault
Tolerance Actuators; it
consists of an agent
controlling all actuators on a
local node
Service master node
MR
server
Local node
MR
FTCE
cache
MSA
Monitoring Sensor Agent collects data from
Monitoring Sensors and
forwards them to the
Measurement Repository
M.Biasotto, Padova, 6 dicembre 2001
Control
flow Tolerance Actuator Fault
Data flow
FTA
MS
executes automatic recovery
actions
Monitoring Sensor - performs
measurement of one or several metrics;
16
Configuration Management diagram
Configuration Database:
stores configuration
information and manages
modification and retrieval
access
Configuration
Cache Configuration Manager:
downloads node profiles from CDB
and stores them locally
Client Node
Database
High Level
Low Level
Description
Description
M.Biasotto, Padova, 6 dicembre 2001
Cache
Configuration
Manager
A
P
I
Local
Process
17
Configuration DataBase
Low Level
Description
High Level
Description
cmsserver1 /etc/exports
/app
All computing nodes of
CMS Farm #3 use
cmsserver1 as
Application Server
cmsnode1, cmsnode2, ..
cmsnode3 /etc/fstab
cmsnode2
/etc/fstab /app
cmsserver1:/app
cmsnode1
/etc/fstab /app
cmsserver1:/app
cmsserver1:/app
M.Biasotto, Padova, 6 dicembre 2001
/app
nfs..
nfs..
nfs..
18
Installation Management diagram
Software Repository - central
fabric store for Software
Packages
Administrative Scripting Layer Applications
Fabric Node
Bootstrap Service service for initial
installation of nodes
Actuator
Dispatcher
Monitoring
& Fault Tol.
NMA
SR
SP’s
SP’s
(local)
BS
System
images
Configuration Management Subsystem
Node Management Agent manages installation,
upgrade, removal and
configuration of software
packages
M.Biasotto, Padova, 6 dicembre 2001
Control Flow: function calls
Data Flow: Configuration, SP’s,
system images. monitoring
19
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
M.Biasotto, Padova, 6 dicembre 2001
20
LCFG diagram
Config files
LCFG Config Files
/etc/shadow
/etc/services
+inet.services
Make XML
Profile
ftp sshd
Read telnet loginLoad
ALLOWED_NETWORKS
rdxprof
ldxprof
HTTP+inet.allow_telnet
Profile
Profile
+inet.allow_login
+inet.allow_ftp
<inet>
....
in.ftpd : 192.168., 192.135.30.
sshd : ALL
Server
Abstract configuration
parameters for all nodes
stored in a central
repository
M.Biasotto, Padova, 6 dicembre 2001
ALLOWED_NETWORKS
ALLOWED_NETWORKS
Profile
Generic
+inet.allow_sshd
ALL
<allow
cfg:template="allow_$
tag_$ daemon_$">
Object
Component
Web Server
XML Profile
mickey:x:999:20::/home/Mickey:/bin/tcsh
in.rlogind : 192.168., 192.135.30.
....
in.telnetd : 192.168., 192.135.30.
XML profiles
+inet.allow
/etc/group
/etc/inetd.conf
/etc/passwd
/etc/hosts.allow
telnet login ftp
+inet.daemon_sshd
yes
<allow_RECORD
cfg:name="telnet">
.....
<allow>192.168., 192.135.30.</allow>
Local cache
+auth.users
</allow_RECORD> inet myckey
auth
+auth.userhome_mickey
.....
/home/mickey
LCFG
Objects
+auth.usershell_mickey
</auth>
/bin/tcsh
Client nodes
<user_RECORD cfg:name="mickey">
<userhome>/home/MickeyMouseHome</userhome>
<usershell>/bin/tcsh</usershell>
A collection
</user_RECORD>
of agents read
configuration parameters and
either generate traditional config
files or directly manipulate various
services
21
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)
M.Biasotto, Padova, 6 dicembre 2001
22
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
M.Biasotto, Padova, 6 dicembre 2001
23
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!)
M.Biasotto, Padova, 6 dicembre 2001
25
LCFG: sviluppo futuro
Software
Repository
(RPMs)
Installation Server
Images
PXE
(DHCP,
kernelDHCP
images
TFTP
installroot)
Bootstrap
Service
NFS
LCFG Config Files
HTTP
User
Interface
Configuration
Make XML
DataBase
Profile
Server
M.Biasotto, Padova, 6 dicembre 2001
Web Server
XML Profile
Read
Config
rdxprof
Profile
Cache
Manager
Local cache
FTP
HTTP
Load
ldxprof
Profile
NMA
Profile
Generic
Object
Component
NMA
Objects
LCFG Objects
Client nodes
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
M.Biasotto, Padova, 6 dicembre 2001
27