M. Biasotto – INFN Legnaro

Slides:



Advertisements
Presentazioni simili
EGEE is a project funded by the European Union under contract IST Test di performance su dCache G.Donvito,V.Spinoso INFN Bari
Advertisements

1 Introduzione ai calcolatori Parte II Software di base.
E835 & Hera-B Concezio Pisa, 21/12/2004. E835 (aka Jet-FNAL) timeline dell'esperimento –Presa dati conclusa nel Alcune analisi tuttora in corso.
A.Fanfani - C.Grandi CMS Bologna 10 febbraio 2009 La nuova farm di CMS Bologna al CNAF Alessandra Fanfani Claudio Grandi.
IL COMPUTER: l'HARDWARE
File System Cos’è un File System File e Directory
Frontespizio Economia Monetaria Anno Accademico
La scelta del paniere preferito
Glossario. AGP Accelerated Graphics Port: architettura di bus che permette alle schede grafiche laccesso diretto al bus di sitema (fino a 100MHz), invece.
Aspetti critici rete LAN e WAN per i Tier-2
WP 2.4 al Cnaf Cnaf 13/11/00 P.M Hardware: - 12 PC Rack mountable IBM XSeries 330 (1U) 2 processori Pentium III 800 Mhz, FSB 133 Mhz 512 MB Mem Ecc, Controller.
Disco magnetico (2) Ciascuna traccia è divisa in settori
Test del Monitoraggio del Tracker usando un Tier2 M.S. Mennea, G. Zito, N. De Filippis Università & INFN di Bari Riunione Consorzio – Torino 18 Novembre.
Michele Michelotto INFN-Padova
LNL M.Biasotto, Bologna, 13 dicembre La farm di Legnaro Massimo Biasotto – INFN LNL.
LNL M.Biasotto, Bologna, 13 dicembre Installazione automatica Massimo Biasotto – INFN LNL.
LNL M.Biasotto, Bologna, 18 ottobre La farm CMS di Padova - Legnaro Proposta di acquisto hardware 2° semestre 2001.
M.Biasotto, Padova, 18 gennaio Sviluppo futuro di LCFG per la Release 2 di Datagrid Massimo Biasotto - LNL.
LNL M.Biasotto, Bologna, 19 marzo La farm CMS di Padova - Legnaro Proposta di acquisto hardware 1° semestre 2001.
LNL CMS M.Biasotto, Firenze, 22 maggio Hardware e tools di installazione Massimo Biasotto INFN – Lab. Naz. di Legnaro.
1 M. Biasotto – Legnaro, 22 Dicembre 2005 Prototipo Tier 2 di Legnaro-Padova INFN Legnaro.
5 Feb 2002Stefano Belforte – INFN Trieste calcolo per CDF in Italia1 Calcolo per CDF in Italia Prime idee per lanalisi di CDF al CNAF Numeri utili e concetti.
Case study Maiora srl.
Benvenuti a Un incontro informativo di grande valore ed alto contenuto sulla Virtualizzazione e sistemi ad alta disponibiltà per le PMI.
Scheda Ente Ente Privato Ente Pubblico. 2ROL - Richieste On Line.
TISB - Pisa - P. Capiluppi Tier1-CNAF DC04 Activities and Status.
1 Questionario di soddisfazione ATA - a. sc. 2008/09 Il questionario è stato somministrato nel mese di aprile Sono stati restituiti 29 questionari.
Benigno Gobbo – INFN Trieste 1 CSNI 21 maggio 2001 Stato della farm di COMPASS-TS CSNI Roma, 21 maggio 2001 Benigno Gobbo INFN Trieste
Stefano Zani e Pierpaolo Ricci (INFN CNAF)
Architettura di storage ad alta affidabilita e bilanciamento di carico per volumi centrali e di esperimento A.Brunengo, M.Corosu INFN Sezione di Genova.
Riunione CCR 20/10/2005 Gruppo Storage Relazione attivita primo semestre 2005 e pianificazione 2006 Alessandro Brunengo.
EGEE is a project funded by the European Union under contract IST Using SRM: DPM and dCache G.Donvito,V.Spinoso INFN Bari
Alessia Tricomi Università & INFN Catania
Corsi di informatica ICCARBONERA.
lun mar mer gio ven SAB DOM FEBBRAIO.
Dischi in RAID  Redundant Array of Independent Disk Configurazione che permette di combinare più dischi secondo obiettivi di performance e ridondanza.
Works in progress.  Semplificazione e maggiore efficienza della gestione  Risparmio (nel medio periodo)  Riallocazione delle risorse (hardware e timesheet)
CCR 14-15/03/2006 Status Report Gruppo Storage CCR.
Riunione gruppo storage – Roma 05/05/2005 Test di affidabilita’ e performance a Genova Alessandro Brunengo.
Servizio Sistema Informativo - Area Gestione Sistemi e Sicurezza – LNF – Dael Maselli Area Gestione Sistemi e Sicurezza LNF Plenaria Servizio Sistema Informativo.
Test Storage Resource Manager per SC4 Giacinto Donvito Vincenzo Spinoso.
Servizio Sistema Informativo - Area Gestione Sistemi e Sicurezza – LNF – Dael Maselli Area Gestione Sistemi e Sicurezza LNF Plenaria Servizio Sistema Informativo.
LNL CMS M.Biasotto, Roma, 22 novembre I Tier2 in CMS Italia Massimo Biasotto - LNL.
Calcolo LHC - F. Ferroni, P. Lubrano, M. SozziCSN1 - Catania Calcolo LHC 2003 (F. Ferroni, P. Lubrano, M. Sozzi)
LNF Farm E. V. 9/8/2006. Hardware CE, LCFG, HLR, 3 WN: DL 360 1U; SE: DL 380 2U 5 WN: BL 25 P In totale 25 jobs general purpuse (coda Atlas) + una coda.
Workshop CCR Otranto - giugno 2006 Gruppo storage CCR Status Report Alessandro Brunengo.
Alessandro Tirel - Sezione di Trieste Storage Area Network Riunione gruppo Storage Padova, 5 ottobre 2005.
La Farm di Alice a Torino Workshop sulle problematiche di calcolo e reti Isola d’Elba 6-9 maggio 2002 Mario Sitta (Università del Piemonte Orientale e.
LNL CMS M.Biasotto, Bologna, 28 maggio Upgrade farm a RH-7.3  Due anni fa la farm era stata installata usando una versione customizzata di ANIS.
M.Biasotto, Bologna, 28 giugno 2004 M.Biasotto, Bologna, 28 giugno LNL CMS T2 Legnaro Stato attuale e richieste 2004/2005.
Riunione CCR 21/12/2005 Gruppo Storage Relazione sulla analisi di infrastrutture Fibre Channel e presentazione attivita’ per il 2006 Alessandro Brunengo.
Nuovo Ambiente CS7402. Attività Principali Gli obiettivi principali della migrazione sono stati quelli di ottenere: –Un’infrastruttura di produzione (Mainframe.
Dischi magnetici e scheduling del braccio del disco Pag. 216 – 224.
CNAF 6 Novembre Layout del testbed  wn a OS SL5.0 8 GB RAM kernel xen_3.1.0 SMP  wn a OS SL5.0 8 GB RAM kernel.
Roberto Covati – Roberto Alfieri INFN di Parma. Incontri di lavoro CCR dicembre Sommario VmWare Server (in produzione dal 2004) VmWare ESX.
Brunengo - Padova - 18/12/2007 Infrastrutture di storage per Tier2 Gruppo storage CCR.
CCR - Frascati 29 settembre 2008 Gruppo storage CCR Status Report Alessandro Brunengo.
Utilizzo della VO di theophys per il calcolo lattice QCD G. Andronico M. Serra L. Giusti S. Petrarca B. Taglienti.
Progetto iSCSI Report alla CCR 12-13/12/2006 Alessandro Tirel – Sezione di Trieste.
Server & Storage Urgenze e anticipazioni seconde priorità CCR Marzo 2009 AG MM LC.
1 ALICE I ITER2 DI ALICE IN ITALIA Bologna, 6 marzo 2007 M. Masera
Test di storage a 10 Gbps proposta. Storage server a 10Gbps Si vuole vedere quali prestazioni si possano ottenere da server connessi a 10 GE –capacita’
20-21/03/2006Workshop sullo storage - CNAF Storage nei Servizi Calcolo delle sezioni INFN Alessandro Brunengo.
CCR - Frascati 29 settembre 2008 Gruppo storage CCR Status Report Alessandro Brunengo.
CCR - Roma 15 marzo 2007 Gruppo storage CCR Report sulle attivita’ Alessandro Brunengo.
Il calcolo per l’esperimento GERDA Luciano Pandola INFN, Laboratori del Gran Sasso Riunione della CSN2, LNF Frascati, 29 Novembre 2011.
1 Le macchine di questo pool fanno parte di una lan privata (la 125 illustrata a pag.2), di cui t2cmcondor è il gateway. Sono presenti 3 macchine su rete.
Care and Feeding of the ALICE Grid
Transcript della presentazione:

M. Biasotto – INFN Legnaro CMS T2 Storage M. Biasotto – INFN Legnaro

Hardware

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

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

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

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

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)

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

Costi Costi a fine 2005: Server: 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

configurazione ridondante Configurazione usata Switch GigaEthernet SERVER (HP DL385) SERVER (ex WN) SERVER (ex WN) SERVER 3ware StorageTek FLX 210 Ctrl A Ctrl B I due controller non sono stati usati in configurazione ridondante

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)

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)

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

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

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

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)

Configurazione SAN Switch GigaEthernet Switch FC SERVER SERVER SERVER 1U 2-AMD 275 4GB RM (ex WN) SERVER SERVER SERVER SERVER SERVER 3ware Switch FC STK FLX-210 (CMS) SUN 6140 (CMS) Apple XServe (Alice) STK FLX-210 (LNL)

DPM

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

Configurazione DPM StorageTek FLX 210 In totale 8 DPM Pools: Head Node Dual Xeon 2.4GHz 2GB RAM SERVER (HP DL385) SERVER (ex WN) SERVER (ex WN) SERVER 3ware SERVER 3ware SERVER 3ware StorageTek FLX 210 4TB CMS 1TB Others 1TB Atlas 1TB Atlas Ctrl A Ctrl B In totale 8 DPM Pools: 2 CMS (cmsprd + general): 13TB Atlas: 2TB Alice: 0.6TB Lhcb, dteam, ops, infngrid: 0.4TB 9TB CMS

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

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)

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

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

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

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)

Problema degrado prestazioni Problema dovuto al crescere delle dimensioni del database, soprattutto a causa della mancata cancellazione delle vecchie get e put request 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 Contattato il supporto, risolto il problema con la creazione di nuovi indici nel DB, in attesa dello script per la cancellazione dei dati inutili

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

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?