Brunengo - Padova - 18/12/2007 Infrastrutture di storage per Tier2 Gruppo storage CCR

Brunengo - Padova - 18/12/2007 Componenti Interfaccia SRM –dCache, DPM, StoRM Protocolli di accesso –dCache: (gsi)dCap, xrootd, (gsi)FTP –DPM: rfio (lan), xrootd (lan), gridFTP –StoRM: file, gridFTP (xrootd, rfio) File system –local FS (EXT3, XFS, ZFS) –file system parallelo (GPFS) Infrastruttura di accesso –DAS, SAN (switched, non switched) Ridondanza –sul disk server, sul controller, sul file (repliche), sul disco (raid sw/hw, raid level) Hard disk –SATA, SAS, FC Una elevata quantita’ di combinazioni possibili –non esiste una soluzione giusta –alcune scelte per una componente implicano scelte per altre componenti

Brunengo - Padova - 18/12/2007 Parametri Prestazioni, scalabilita’ –funzione dei requisiti –crescita progressiva dell’installato Affidabilita’ e solidita’ in occasione di failure –dipende dai requisiti sui tempi di downtime Flessibilita’ –modifica di configurazioni (aggiustamenti in corso) –impatto sulle riconfigurazioni hw/sw Complessita’ di management Costi

Brunengo - Padova - 18/12/2007 Requisiti Dimensione dello storage –oggi: ~ decine di TB –2008: ~ raddoppio –a regime: TB (??) Throughput aggregato (a regime) –read: ~1000 MB/s (WN), ~ 10 MB/s (verso T1) –write: ~ 60 MB/s (da T1), ~ 10 MB/s (da WN) Slot di calcolo: ~ 500 (50% per l’analisi?) Throughput per slot: 1-10 MB/s –requisito ridondante e non ben definito: (thr tot) = (thr per slot) * Nslot! Altri requisiti –protocolli di accesso locale e remoto: dipende dalle esigenze di esperimento –protocolli SRM: l’interfaccia e’ definita (V2.2 nel 2008) Considerazione: i requisiti sono omogenei tra gli esperimenti?

Brunengo - Padova - 18/12/2007 Dimensionamento Numero di disk server (quindi TB/server) –dipende dal throughput verso i WN; esempi: server in GE (100 MB/s/server), 10 MB/s/slot fanno 10 server/slot, per 250 slot fanno 25 server (20 TB/server) server in 2 * GE (200 MB/s), 1 MB/s/slot fanno 200 slot/server, per 250 slot fanno 3 server (200 TB/server) –in questo caso e’ probabile che il server non possa sostenere 100 sessioni contemporanee a piena banda –questi numeri nell’assunto che il carico sia completamente distribuito tra i server richiede attenzione nella collocazione fisica dei dati Numero di controller (quindi TB/controller) –anche questo funzione del throughput: tipicamente un controller di medio livello e’ capace di 400 MB/s in condizioni ottimali (sequenziale, poche sessioni) un elevato numero di accessi contemporanei randomizza la tipologia di accesso, riducendo il throughput complessivo (meglio considerare MB/s) –necessaria una misura sull’hardware da acquistare –puo’ anche dipendere dal numero di IOps per letture frequenti e piccole cresce il numero di I/O –c’e’ forte dipendenza dalla tipologia di accesso e dalla qualita’ del sistema controller+disco utilizzato

Brunengo - Padova - 18/12/2007 Considerazioni generali: disco Sostanzialmente due possibilita’: –SATA (mtbf ~ 0.6 Mh, size 1TB, 7.2 Krpm, ~ euro/TB) buone prestazioni per letture sequenziali –SAS/FC (mtbf ~ 1.5 Mh, size 400 GB, 15 Krpm, ~1.4 Keuro/TB) affidabili e veloci, costosi Volumi (quindi costi) e tipologia di accesso suggeriscono l’uso di dischi SATA –dischi SAS/FC forse per piccoli volumi ad accesso fortemente randomico che richieda alte prestazioni

Brunengo - Padova - 18/12/2007 Considerazioni generali: ridondanza Sul disco: assolutamente necessaria –i dischi si rompono troppo facilmente –e’ necessaria una ridondanza RAID hardware: tipicamente RAID5, molto meglio RAID6 (ma va valutato l’impatto sulle prestazioni in scrittura) –richiede un controller idoneo –controller di basso livello possono andare molto male software: ridondanza a livello di logical volume o di file system (ad esempio la soluzione SUN Thumper con ZFS) Sull’hardware del server: consigliabile –sicuramente in caso di soluzione priva di ridondanza alternativa –impatto non eccessivo sui costi ~ Keuro server non ridondato ~ Keuro server ridondato + 0.5/0.8 per HBA NOTA: numeri altamente variabili in funzione del brand, della soluzione tecnica e dei quantitativi

Brunengo - Padova - 18/12/2007 Infrastruttura di accesso DAS: il disco e’ direttamente conesso al singolo server (tipicamente integrato nel case) –una failure del server implica inaccessibilita’ ai volumi fino a ripristino del server SAN: il sistema e’ costituito da una rete a cui sono connessi disk server e controller di disco. La separazione server-disco permette di configurare features aggiuntive: –failover sul disk server: diversi server possono vedere lo stesso volume e possono essere configurati per sopperire alla failure del singolo server (tramite heart-bit o funzionalita’ del file system) –bilanciamento del carico: possono essere aggiunti volumi (sullo stesso controller o tramite nuovi controller) serviti dallo stesso disk server, o si possono spostare parte dei volumi di un controller su un altro (nuovo) disk server per scaricare i server attivi, il tutto senza muovere dati (modificando configurazioni della SAN o dei controller) –si può sostituire un disk server rotto con uno nuovo senza spostare dati (minore tempo di ripristino di funzionalita’) –si possono operare backup o migrazione di volumi senza impattare sull’I/O del server (tramite un altro server che vede gli stessi volumi, ad esempio, sfruttando features del file system o snapshot dei controller) –si possono applicare filtri per limitare la visibilita’ dei volumi –si può configurare un failover su controller e sul path verso i volumi Aspetti negativi sono essenzialmente i costi superiori ed il maggiore impegno per il management (in particolare per il setup)

Brunengo - Padova - 18/12/2007 Infrastruttura di accesso (2) SAN non switched: si puo’ utilizzare lo stesso hardware di una SAN senza usare switch per la connessione degli oggetti. Questo limita la flessibilita’ senza perdere tutte le features: tipicamente i controller sono dotati di due canali FC in uscita, quindi si possono costruire mini-SAN con (doppio) controller e due/quattro server. Per mantenere le funzionalita’di failover sul disk server, ogni controller deve essere connesso a due server; per mantenere failover sul controller, ogni coppia di controller deve essere connessa a due server. Funzionalita’ di backup o migrazione di volumi tra mini-SAN distinte devono necessariamente passare attraverso i server connessi, quindi in competizione con l’I/O dei server stessi.

Brunengo - Padova - 18/12/2007 GPFS GPFS e’un file system che aggrega diversi dischi potenzialmente connessi a diversi server in un unico file system. I diversi dischi (Network Shared Disk, o NSD) sono acceduti direttamente dalle macchine che li vedono (perche’ direttamente connessi o perche’ connessi ad una SAN), tramite NSD server altrimenti (l’NSD server deve vedere l’NSD). Le principali funzionalita’ sono: –striping dei dati: ogni file sufficientemente grande viene scritto/letto facendo striping sugli NSD che costituiscono il file system, quindi parallelizzando l’accesso su piu’ server, migliorando il throughput –il file system e’ espandibile/riducibile dinamicamente tramite aggiunta o rimozione di NSD (com migrazione automatica dei pezzi di file), ed e’ possibile creare file system di grosse dimensioni –ogni file system e’ montabile direttamente da tutti i nodi del cluster, ed accessibile tramite chiamate standard posix. –e’ possibile configurare failover sull’NSD server (fino ad 8) in configurazione SAN –e’ possibile configurare replica di dati e metadati –e’ possibile definire pool di dischi ed utilizzare policy per realizzare domini di striping/migrazione di volumi/spostamento di carico cluster size limit (linux): 2441 nodi file system size limit: 2^99 bytes (architetturale), testato fino a 2 PB numero di file system montati: 256

Brunengo - Padova - 18/12/2007 GPFS (2) Nell’utilizzo di GPFS si deve considerare come fattore negativo l’impatto che ha la perdita di un volume per inaccessibilita’ o corruzione. In caso di inaccessibilita’ di un NSD: –NSD metadata only: sara’ indisponibile il file system nel suo complesso, a meno di non replicare i metadati; in questo caso non ci sara’ effetto sulla funzionalita’ –NSD data only: il file system resta accessibile, ma saranno inaccessibili i file per i quali lo striping ha collocato sull’NSD parte dei dati, a meno di non replicare i dati; in quest’ultimo caso non ci sara’ effetto sulla funzionalita’ –NSD data and metadata: l’insieme dei due casi. Il disservizio sara’ permanente in caso di corruzione di un NSD. –restore da backup o altra sorgente Ne consegue che sembra assolutamente consigliabile, anche per motivi di prestazioni, dedicare NSD alla gestione dei metadati, e replicare almeno i metadati per non perdere di accessibilita’ del file system. In assenza di soluzioni di backup, e’anche consigliabile configurare repliche dei dati considerati importanti e non riproducibili. GPFS su infrastruttura DAS comporta la necessita’ di operare configurazioni opportune per limitare il downtime in occasione di failure –su DAS l’NDS risultera’inaccessibile anche per falure del server (alimentatore, RAM, disco sistema, rete...) –le configurazioni necessarie per limitare tali problemi comportano complessita’di configrazione e riduzione delle prestazioni (si limita il parallelismo)

Brunengo - Padova - 18/12/2007 File system locali Tipicamente XFS o EXT3 (XFS piu’veloce) Soluzione interessante il Thumper –Solaris con ZFS e raid software –buone prestazioni ( MB/s stime non pubblicate) –Impone interfaccia SRM dCache Soluzione migliore per infrastruttura DAS Non sfrutta completamente le caratteristiche di flessibilita’ di una infratruttura SAN –da valutare se vale la spesa

Brunengo - Padova - 18/12/2007 Interfacce SRM dCache –distribuzione del carico automatica sui server –funzionalita’ di replica a livello di directory –soluzione integrata per i diversi protocolli di accesso –soluzione diffusa in produzione da qualche anno –curva di apprendimento ripida –complessita’ nel management –sfrutta bene una infrastruttura DAS con file system locale –possibile usarlo su file system parallelo maggiore solidita’ del back end –prove di scala: in produzione a FNAL a parita’ di infrastruttura hw meno performante di GPFS

Brunengo - Padova - 18/12/2007 Interfacce SRM (2) DPM –semplicita’ di installazione e configurazione –supporto al CERN –in produzione su molti siti medio/piccoli –meno flessibile nel bilanciamento del carico –non fa replica puo’ godere proficuamente di tali funzionalita’ a livello di file system (GPFS) –problemi di compatibilita’ sw con CMS –non c’e’ esperienza di uso intenso su scala T2

Brunengo - Padova - 18/12/2007 Interfacce SRM (3) StoRM –Sfrutta al meglio le caratteristiche di GPFS bilanciamento del carico gestione dinamica dei volumi quote,... tutto nativo GPFS...piu’ semplice –per chi conosce GPFS e’ un piccolo step in piu’ –permette un accesso in modalita’ file –scala come GPFS –puo’ essere utilizzato su file system locale con qualche limitazione combinazione forse piu’ adatta su scala ridotta mai testato seriamente –Non adatto all’utilizzo su infrastruttura DAS (vedi GPFS) –Alternativa interessante, ma giovane molto utile verificarne solidita’ e prestazioni su Tier2 per qualche mese

Brunengo - Padova - 18/12/2007 Architetture possibili dCache –DAS Thumper + ZFS (costo medio (?), buona qualita’) DAS low level + local FS (costo e qualita’ basse) –SAN GPFS (buona qualita’, costi alti anche di gestione) local file system (buona qualita’, costi alti)

Brunengo - Padova - 18/12/2007 Architetture possibili (2) DPM –DAS DAS low level + local FS (costo e qualita’ basse) –SAN GPFS (buona qualita’, costi alti) local file system (buona qualita’, costi alti)

Brunengo - Padova - 18/12/2007 Architetture possibili (2) StoRM –DAS DAS low level + GPFS (costo e qualita’ basse) –SAN GPFS (buona qualita’, costi alti)

Brunengo - Padova - 18/12/2007 Costi (e qualita’) Soluzione DAS low level ~ 0.9 Keuro/TB (acquisti di piccole dimensioni) alta possibilita’ di failure va valutata eventuale replica dei dati, specie per dati preziosi, con incremento delle esigenze di spazio disco Soluzioni DAS high level ?? quanto costa un Thumper ?? non ci sono dati (da gara) per altre soluzioni di marca

Brunengo - Padova - 18/12/2007 Costi (2) Soluzioni SAN –costo di controller+disco dipende fortemente dal brand e dalla dimensione per acquisti dell’ordine dei 40 TB: Keuro/TB (low level), ma arriva a Keuro/TB per soluzioni di maggiore qualita’ (EMC2, StorageTeK,...) –si deve valutare attentamente l’assistenza: i migliori brand offrono garanzie che altri non possono dare acquisti di materiale di alta qualita’ dell’ordine di centinaia di TB: prezzi fino a Keuro/TB (vedi T1) –costo disk server (con HBA) da 3.0 a 4.0 Keuro in funzione della ridondanza hardware –costo dello switch low level: ~ euro/porta oggetti di grosse dimensioni: vedi T1 (ma servono?)

Brunengo - Padova - 18/12/2007 Considerazioni conclusive StoRM interessante –deve essere garantito supporto per StoRM –deve anche essere accessibile supporto per GPFS –deve essere provato in modalita’ di produzione in configurazione Tier2 DPM: da verificare prestazioni e scalabilita’ in condizioni di produzione su T2 a regime dCache: soluzione abbastanza consolidata, costosa in termini di management Sembra essere necessario eseguire test significativi, sia per tipologia di accesso che per carico –il T1, o un T2 sovradimensionato rispetto allo stato attuale

Brunengo - Padova - 18/12/2007 Considerazioni conclusive (2) Infrastruttura: SATA + RAID (sw/hw) –SAN molto meglio per flessibilita’ e soluzioni di failover soluzione SAN non switched: risparmio contenuto, ma scelta conservativa –DAS: piu’ economica sarebbero da evitare DAS di basso livello Costi: divergono al diminuire dei volumi da acquistare –consigliabile accorpare ordini per soluzioni omogenee (magari scegliendo soluzioni omogenee ove possibile) –da considerare oggetti di qualita’ aumenta il costo ma diminuisce il peso della gestione in startup e mantenimento