dCache --------------- Test effettuati al CNAF Techincal Board Milano dCache --------------- Test effettuati al CNAF Bologna, 5/5/04 felice.rosso@cnaf.infn.it

NFS: Facile da installare Facile da configurare ---------------- Le prestazioni non scalano al crescere del numero dei client Bologna, 5/5/04 felice.rosso@cnaf.infn.it

dCache: Relativamente facile da installare Attualmente non troppo facile da configurare -------------------- Le prestazioni scalano al crescere dei pool nodes Nessuno striping, quindi “mount point” > 2 TByte Bologna, 5/5/04 felice.rosso@cnaf.infn.it

Admin Node: Server dove vengono registrate le informazioni Struttura di dCache Admin Node: Server dove vengono registrate le informazioni dei files (nome, path, CRC, locazione nei PN) Pool Node: Computer con un volume (ext2/ext3/xfs) dedicato ai files di dati Richieste di sistema: Kernel > 2.4.19 (stabilità a cpu load elevate) RAM : 2 GB (meglio 4 GB per l’admin node) Java versione 1.4.2 Postgresql (gestione dei files di replica -Admin node-) Bologna, 5/5/04 felice.rosso@cnaf.infn.it

Macchina dedicata con HT disattivato Connessione di rete GigaBit Admin node Macchina dedicata con HT disattivato Connessione di rete GigaBit Possibilmente 4 GB di RAM Un disco da almeno 40 GByte E’ il server principale. Tutte le operazioni di amministrazione devono passare per l’admin node Gestisce: locazione e replica dei files privilegi di accesso (r/w) Bologna, 5/5/04 felice.rosso@cnaf.infn.it

Classico Worker Node dove viene utilizzata una partizione Pool node Classico Worker Node dove viene utilizzata una partizione per i files di dati. Di solito tale partizione equivale al secondo disco (esclusi i normali 2 GByte di swap file) In pieno regime di carico dCache necessita di circa 500 Mbytes di RAM (situazione rara) Job medio: 300 Mbytes di RAM Totale RAM consigliata: 2 Gbyte Quando più WN accedono ai dati su un PN dal 3 al 20% della CPU viene utilizzata da dCache (dipende dal numero delle connessioni) Enqueueing: Max 10 connessioni per PN Bologna, 5/5/04 felice.rosso@cnaf.infn.it

Affinchè un WN generico possa accedere ad un pool di Accesso a dCache Affinchè un WN generico possa accedere ad un pool di dCache è necessario che sull’admin node il WN stesso sia registrato come trusted (IP/sotto maschera di rete) Per accedere in lettura ai files tramite dCache non è necessario che il WN monti il volume (PNFS) di dCache. Il kernel del WN è quindi molto più snello quando non si accede ai pool dCache (nessun controllo o sincronizzazione) Per l’accesso in scrittura è necessario un ulteriore allow nell’admin node Bologna, 5/5/04 felice.rosso@cnaf.infn.it

Metodo di accesso a dCache Il job fa richiesta all’admin node di un file Se il WN è trusted l’AN comunica l’indirizzo IP del PN e relativo path del file di dati La connessione tra WN e AN viene chiusa Il WN apre una nuova connessione col PN 1) copia il file in locale (dccp) 2) tramite librerie dCap apre il file in maniera “classica” Una volta terminata la copia o alla chiusura del file la connessione viene chiusa. Con SRM tutto sarà trasparente all’utente. Bologna, 5/5/04 felice.rosso@cnaf.infn.it

Prestazioni NFS Bologna, 5/5/04 felice.rosso@cnaf.infn.it

Prestazioni dCache Bologna, 5/5/04 felice.rosso@cnaf.infn.it

Con dCache è possibile replicare il singolo file su uno Replica files Con dCache è possibile replicare il singolo file su uno o più PN differenti L’AN gestisce automaticamente le replice e decide di volta in volta da quale PN deve essere letto il file. (PN down o troppe richieste dello stesso file) Bologna, 5/5/04 felice.rosso@cnaf.infn.it

E’ valido? Oppure è una limitazione? Enqueueing E’ valido? Oppure è una limitazione? Più sono i PN e più I files sono distribuiti in maniera uniforme, quindi poche possibilità di colli di bottiglia. Bologna, 5/5/04 felice.rosso@cnaf.infn.it

Esempio di enqueueing con “buona” configurazione Bologna, 5/5/04 felice.rosso@cnaf.infn.it

Esempio di enqueueing con “buona” configurazione Bologna, 5/5/04 felice.rosso@cnaf.infn.it