CMS T2 Storage
M. Biasotto – INFN Legnaro
M. Biasotto
1
Hardware
M. Biasotto
2
3ware

M. Biasotto
Lunga esperienza con i disk-server 3ware
•
iniziata nel 2001 con 10 disk-server
•
negli anni successivi acquistati in totale altri 17 server per la farm
CMS e la farm LNL, di varia taglia (da 24 a 32 HDD) e modelli
•
attualmente ancora 10-15 server in produzione
3
Problemi server 3ware



Esperienza inizialmente positiva, ma continuo aumento di
problemi al crescere del numero di macchine
•
caso tipico: drive failure => array degradato => il rebuild fallisce
•
problemi hw nella parte server, in particolare per le macchine piu’
grosse (32 HDD)
Problemi aggravati dalla scarsa assistenza da parte dei
fornitori, tutti piccoli vendors dato che le grandi case non
offrivano prodotti di questo tipo
Nel periodo 2004-2005 i problemi di storage sono stati un
incubo continuo
•

M. Biasotto
Problemi hardware ma non solo (no fs distribuito => grosse difficolta’
di gestione)
A fine 2005 decisione di cercare di passare ad una
soluzione Storage Area Network di tipo SATA-FC
4
Alternativa DAS ai 3ware?

server Sun Fire X4500
•
cominciano ad esserci offerte di prodotti di questo tipo anche dalle
grandi case
•
potrebbe essere un’alternativa alle attuali soluzioni 3ware, con
maggiore affidabilita’




M. Biasotto
Case 4U, dual processor Opteron dual
core, alta ridondanza
10 PCI-X interni + 2 slot di espansione, 4
porte GE
48 HD SATA 500GB: 24 TB
ma supporto Linux ancora limitato, per
ora Solaris + file system ZFS
5
SAN con dischi SATA-FC

Vantaggi della soluzione Storage Area Network SATA-FC

Affidabilita’
•

M. Biasotto
non piu’ assemblati ma prodotti di marca, di buona qualita’ e
soprattutto con assistenza garantita
Flessibilita’
•
la separazione della parte dischi dalla parte server offre grandi
vantaggi nella gestione dello storage
•
nella gestione dei problemi
•
nella ricerca di ottimizzare il setup dello storage, soprattutto in una
fase come questa, con molte cose ancora in evoluzione e molte
incognite ed incertezze (ad es. quanti disk-server? quanti TB per
server?)
6
LNL Storage Area Network


M. Biasotto
Un’unica Storage Area Network in comune tra le due farm,
T2 CMS-Alice e farm LNL
•
nell’ottica di una graduale ‘fusione’ delle due farm (prima separate)
per ottimizzarne la gestione e l’utilizzo delle risorse
•
dal 2007 anche farm Agata
•
possibile utilizzo anche per i servizi di Calcolo
I maggiori costi della tecnologia SATA-FC possono essere
affrontati meglio sommando i finanziamenti del T2 (CMS e
Alice) con quelli della farm LNL (Laboratori Legnaro, CCR,
esperimenti locali)
7
Acquisti fine 2005

M. Biasotto
Acquistato a fine 2005 sistema costituito da
•
Testa StorageTek STK FLC-210
•
2 disk arrays da 14 HD SATA 250GB (in seguito altri 3 arrays con
HD da 400GB)
•
La testa comprende due controller ridondanti, ciascuno con 2 canali
FC (2Gb/s) verso i dischi e 2 verso gli host, ed un array da 14 HD (in
un case 3U)
•
Ogni cassetto addizionale ospita 14 HD
•
FLC-210 e’ (era) il sistema entry level:
1GB cache, max 112 dischi
3000 I/O p.s. (SATA), 12000 I/O p.s. (FC)
8
Costi


M. Biasotto
Costi a fine 2005:
•
testa con doppio controller e 14 HD 250GB: 18 Keuro (i.c.)
•
cassetto addizionale con 14 HD 250GB: 12 Keuro
Server:
•
1 nuovo server HP Proliant DL385 (2U, dual Opteron 285, 4GB
RAM, alimentazione ridondata, HD SCSI): 4.5 Keuro
•
per il resto riutilizzati come server dei vecchi WN dual Xeon 2.4GHz
(ma servono 4GB RAM!)
•
Scheda HBA Qlogic QLA 2340: 1 Keuro
9
Configurazione usata
Switch GigaEthernet
SERVER
(HP DL385)
StorageTek
FLX 210
SERVER
(ex WN)
Ctrl A
SERVER
(ex WN)
SERVER
3ware
Ctrl B
I due controller non
sono stati usati in
configurazione ridondante
M. Biasotto
10
Esperienza col nuovo hardware


M. Biasotto
Nuovo sistema utilizzato in produzione nel 2006 (SC4 +
Prod. MC + CSA06)
Esperienza positiva, ma e’ ancora presto per giudicare
l’affidabilita’ complessiva
•
un paio di guasti subito all’inizio (1 HD e 1 modulo batteria), subito
sostituiti da personale tecnico STK
•
buona l’impressione sulla gestione del sistema: software di
management, monitor, allarmi, flessibilita’ di gestione (possibilita’ di
modifiche ‘hot’ alla configurazione)
11
Prestazioni

Problema di prestazioni nella configurazione iniziale
•

M. Biasotto
max 50 MB/s in write e 65 MB/s in read sulla singola testa, anche
usando contemporaneamente piu’ arrays su entrambi i controller in
contemporanea.
Risolto modificando alcuni parametri del sistema
•
contattato anche il supporto tecnico di StorageTek, modificati vari
parametri, in particolare disabilitato il mirroring della cache
•
risultati ottenuti, misurati con ‘bonnie++’ e ‘dd’, usando 2 server (uno
per ciascun controller):
~160 MB/s write, ~180 MB/s read per controller
~330 MB/s aggregati sui due controller (sia read che write)
12


Nell’uso in produzione l’attivita’ piu’ stressante per il sistema
e’ stata la fase di merge della produzione MC
agosto 2006: ~110 jobs di merge contemporanei, read e
write su un singolo RAID array:
•
M. Biasotto
~120 MB/s read+write
13
Acquisti fine 2006

Switch FC 16 porte Brocade Silkworm 200E: 5 Keuro (i.c.)

M. Biasotto
Previsto upgrade STK FLX-210 non piu’ possibile:
•
StorageTek acquisita da SUN
•
nuove normative europee (RHOS compliancy)
•
=> nuova linea di prodotti storage
14
Acquisti fine 2006

Nuova testa STK-Sun 6140 con doppio controller e 16HD da
500GB
+ 2 disk-arrays addizionali
+ 24HD 500GB
in totale 20 TB lordi: 37 Keuro (i.c.)
M. Biasotto
•
come il FLX 210, doppio controller ma ora con canali FC da 4Gb/s e
prestazioni superiori, 2 o 4 GB cache
•
cassetti da 16 HD (da 500 GB)
15
Acquisti fine 2006

M. Biasotto
Sistema Apple XServe RAID 7TB (14 HD 500GB):
10 Keuro (i.c.), acquistato per Alice
•
in uso anche presso T2 CMS Winsconsin
•
economico, ma versione attuale ancora con dischi Parallel ATA
•
test di prestazioni effettuati su sistema in prova:
~200 MB/s write, ~110 MB/s read aggregati sui 2 controller
(ma con 1 solo server)
16
Configurazione SAN
Switch GigaEthernet
SERVER:
1U 2-AMD 275
4GB RM (ex WN)
SERVER
SERVER
SERVER
SERVER
SERVER
3ware
Switch FC
STK
FLX-210
(CMS)
M. Biasotto
SUN
6140
(CMS)
Apple
XServe
(Alice)
STK
FLX-210
(LNL)
17
DPM
M. Biasotto
18


DPM installato a Legnaro a meta’ 2005, non usato in
produzione
•
qualche test di prestazioni con rfcp
•
usato in SC3 (nella ‘throughput phase’)
Durante la fase di ‘service’ di SC3 scoperto il famigerato
problema della libreria RFIO/DPM/Castor
•

M. Biasotto
ancora irrisolto dopo un anno e mezzo
A marzo 2006 risistemato in una nuova configurazione, piu’
complessa, in vista di
•
SC4 + CSA06 per CMS
•
uso in produzione da parte di Atlas
•
usando il nuovo hardware di storage
19
Configurazione DPM
Dual Xeon 2.4GHz
2GB RAM
SERVER
(HP DL385)
SERVER
(ex WN)
SERVER
(ex WN)
StorageTek
FLX 210
Ctrl A
Ctrl B
9TB
CMS
M. Biasotto
DPM
Head Node
SERVER
3ware
SERVER
3ware
SERVER
3ware
4TB
CMS
1TB 1TB
Others Atlas
1TB
Atlas
In totale 8 DPM Pools:
2 CMS (cmsprd + general): 13TB
Atlas: 2TB
Alice: 0.6TB
Lhcb, dteam, ops, infngrid: 0.4TB
20
SC4

M. Biasotto
SC4 e’ stato un buon test di stabilita’
•
specialmente in giugno-luglio (usando srmcp), transfer sostenuto per
settimane a rate abbastanza significativi (>20MB/s di goal)
•
in totale trasferiti ~200TB in import (a 20-50 MB/s) e ~60TB in export
(a 5-20 MB/s)
•
complessivamente buona stabilita’ del sistema, nessun problema
relativo a DPM
21
SC4

M. Biasotto
Purtroppo non ci sono mai state le condizioni per un
throughput test
•
sample di dati troppo piccolo
•
in giugno-luglio avevamo il problema di config. hw che limitava max
50MB/s
•
a fine luglio passati da srmcp a FTS: 
•
a settembre runnato un weekend di nuovo con srmcp: >60 MB/s
(essenzialmente da FNAL e un po’ FZK, gli altri T1 non erano
available)
22
Produzione MC


La fase di merge della produzione e’ stata l’attivita’ piu’
‘demanding’ per lo storage delle farm
Nel nostro caso non ci sono stati particolari problemi
•
necessario creare pool apposito per cmsprd
•
evidenziato un bug (scrittura su un fs gia’ pieno)
•
pochi failures, nonostante il pool ridotto (spesso 1 solo server, con
una sola partizione)
110 jobs di merge, su una singola partizione: ~120 MB/s read+write
M. Biasotto
23
CSA06

CSA06 e’ stata di scarsa utilita’ al fine di stressare e valutare
il sistema di storage
M. Biasotto
•
data transfer con Phedex a rate e stabilita’ molto inferiori che
durante SC4
•
JobRobot quasi mai funzionante, e jobs molto inefficienti
nell’accesso allo storage
24
CSA06
Legnaro, 20 Oct 2006: a bunch of ~90 JobRobot jobs running
M. Biasotto
25
Problema degrado prestazioni


Alla ripresa della produzione,
dopo CSA06, evidenziato un
significativo calo di
prestazioni di DPM rispetto
ad alcuni mesi prima
Grafici dell’head node di
DPM durante due ‘ondate’ di
merge jobs:
•
load molto elevato e cpu al
100%, a differenza di quanto
accadeva in agosto (load e cpu
entrambi trascurabili)
M. Biasotto
26
Problema degrado prestazioni

Problema dovuto al crescere delle dimensioni del database,
soprattutto a causa della mancata cancellazione delle
vecchie get e put request
table

M. Biasotto
# rows
size (MB)
Cns_file_metadata
70.000
33
Cns_file_replica
38.000
23
dpm_get_filereq
350.000
230
dpm_put_filereq
410.000
270
dpm_req
610.000
170
Contattato il supporto, risolto il problema con la creazione di
nuovi indici nel DB, in attesa dello script per la cancellazione
dei dati inutili
27
DPM: conclusioni


Finora l’esperienza con DPM sarebbe anche positiva
•
problemi DPM pochi e non gravi
•
buona stabilita’ del sistema (una volta configurato non serve metterci
le mani continuamente)
I problemi maggiori sono stati quello della libreria RFIO...
•

M. Biasotto
non propriamente un problema di DPM (infatti e’ ancora irrisolto
dopo un anno e mezzo proprio perche’ sta nella “no man’s land” tra
DPM, Castor e CMS)
... e la mancanza di alcune funzionalita’ avanzate
•
drain di una partizione (c’e’ nell’ultima versione)
•
load balancing piu’ avanzato (configurabile)
•
selezione pool in base al path
28
DPM: conclusioni

Bugs e mancanza di funzionalita’ sono il segno che DPM
non e’ ancora un prodotto maturo, ma il vero problema non
e’ questo
•

Problemi di “compatibilita’” in CMS (sw e tools cms-specific)
•

M. Biasotto
DPM in uso nella maggior parte dei T2 di LCG, le funzionalita’
arriveranno
prima o poi si raggiungera’ una situazione di stabilita’, ma quando?
Ci sono limiti intrinseci di scalabilita’?
•
quando nel DB ci saranno 600-1000 TB (milioni di files)?
•
limiti ‘strutturali’ che non possono essere superati per quanto si
ottimizzi?
29