1M. Biasotto

CMS T2 Storage

M. Biasotto – INFN Legnaro

2M. Biasotto

Hardware

3M. Biasotto

3ware

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

4M. Biasotto

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

• 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

5M. Biasotto

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’

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

6M. Biasotto

SAN con dischi SATA-FC

Vantaggi della soluzione Storage Area Network SATA-FC

Affidabilita’

• 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?)

7M. Biasotto

LNL Storage Area Network

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)

8M. Biasotto

Acquisti fine 2005

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 dischi3000 I/O p.s. (SATA), 12000 I/O p.s. (FC)

9M. Biasotto

Costi

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

10M. Biasotto

Configurazione usata

Ctrl A

SERVER(HP DL385)

SERVER(ex WN)

SERVER(ex WN)

SERVER3ware

Switch GigaEthernet

Ctrl BStorageTekFLX 210

I due controller nonsono stati usati in

configurazione ridondante

11M. Biasotto

Esperienza col nuovo hardware

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)

12M. Biasotto

Prestazioni

Problema di prestazioni nella configurazione iniziale

• 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)

13M. Biasotto

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:

• ~120 MB/s read+write

14M. Biasotto

Acquisti fine 2006

Switch FC 16 porte Brocade Silkworm 200E: 5 Keuro (i.c.)

Previsto upgrade STK FLX-210 non piu’ possibile:

• StorageTek acquisita da SUN

• nuove normative europee (RHOS compliancy)

• => nuova linea di prodotti storage

15M. Biasotto

Acquisti fine 2006

Nuova testa STK-Sun 6140 con doppio controller e 16HD da 500GB+ 2 disk-arrays addizionali+ 24HD 500GBin totale 20 TB lordi: 37 Keuro (i.c.)

• 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)

16M. Biasotto

Acquisti fine 2006 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)

17M. Biasotto

Configurazione SAN

Switch FC

STKFLX-210(CMS)

SUN6140

(CMS)

AppleXServe(Alice)

STKFLX-210

(LNL)

SERVER SERVER SERVER SERVERSERVER

3ware

Switch GigaEthernet

SERVER:1U 2-AMD 275

4GB RM (ex WN)

18M. Biasotto

DPM

19M. Biasotto

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

• 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

20M. Biasotto

Configurazione DPM

Ctrl A

SERVER(HP DL385)

SERVER(ex WN)

SERVER(ex WN)

SERVER3ware

Ctrl B

StorageTekFLX 210

SERVER3ware

SERVER3ware

4TBCMS

9TBCMS

1TBAtlas

1TBAtlas

1TBOthers

DPMHead Node

Dual Xeon 2.4GHz2GB RAM

In totale 8 DPM Pools:2 CMS (cmsprd + general): 13TBAtlas: 2TBAlice: 0.6TBLhcb, dteam, ops, infngrid: 0.4TB

21M. Biasotto

SC4

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

22M. Biasotto

SC4

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)

23M. Biasotto

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

24M. Biasotto

CSA06

CSA06 e’ stata di scarsa utilita’ al fine di stressare e valutare il sistema di storage

• 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

25M. Biasotto

CSA06

Legnaro, 20 Oct 2006: a bunch of ~90 JobRobot jobs running

26M. Biasotto

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)

27M. Biasotto

Problema degrado prestazioni

Contattato il supporto, risolto il problema con la creazione di nuovi indici nel DB, in attesa dello script per la cancellazione dei dati inutili

table # 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

Problema dovuto al crescere delle dimensioni del database, soprattutto a causa della mancata cancellazione delle vecchie get e put request

28M. Biasotto

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...

• 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

29M. Biasotto

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

• DPM in uso nella maggior parte dei T2 di LCG, le funzionalita’ arriveranno

Problemi di “compatibilita’” in CMS (sw e tools cms-specific)

• 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?