Home file system

From Atlmiwiki

Le home per gli utenti delle farm ATLAS (ui, tier3 e proof) risiedono sul file system GPFS homes_fs, servito via cnfs dalle due macchine ts-a1-5 e ts-a1-6.
L'indirizzo virtuale del server NFS (bilanciato in round robin via DNS) è ts-a1-nfs.mi.infn.it e la directory esportata è /gpfs/homes_fs/home.
Le due macchine fanno parte del cluster delle user interface (glite-UI-nodes.mi.infn.it).

Contents

Configurazione delle macchine

Posizione
Sala N, ultimo rack a dx.
Motherboard
Supermicro X7DB8
CPU
2 x Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
RAM
16GB (8 x Samsung M395T5750EZ4-CE66 2GB DDR2-667 2Rx4 1.8V ECC)
HDD
6 dischi Seagate ST3000DM001-1CH166 da 3TB SATA/300 7200rpm collegati direttamente al controller onboard (GPFS Network Shared Disks, da sda a sdf)
2 dischi Hitachi Deskstar P7K500 (HDP725025GLA380) da 250GB collegati a un controller 3ware 9650SE in RAID1 (disco di sistema, sdg)
Posizione dei dischi:
      ----- ----- ----- -----
     | sda | sdb | sdc | sdd |
     |-----+-----+-----+-----|
     | sdg | sdg | sde | sdf |
      ----- ----- ----- -----
Aggiornamento del 25/03/2013: per rendere costante l'associazione baia/device, ho aggiunto sulle due macchine il file /etc/udev/rules.d/10-persistent-disk.rules:
    # Make the device name consistent to the scsi path, to make GPFS maintenance easier.
    
    # System disk
    SUBSYSTEM=="block", ENV{ID_PATH}=="pci-0000:08:00.0-scsi-0:0:0:0", ENV{ID_TYPE}=="disk", NAME="sdg"
    
    # GPFS disks
    SUBSYSTEM=="block", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", ENV{ID_TYPE}=="disk", NAME="sda"
    SUBSYSTEM=="block", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", ENV{ID_TYPE}=="disk", NAME="sdb"
    SUBSYSTEM=="block", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-2:0:0:0", ENV{ID_TYPE}=="disk", NAME="sdc"
    SUBSYSTEM=="block", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-3:0:0:0", ENV{ID_TYPE}=="disk", NAME="sdd"
    SUBSYSTEM=="block", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-4:0:0:0", ENV{ID_TYPE}=="disk", NAME="sde"
    SUBSYSTEM=="block", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-5:0:0:0", ENV{ID_TYPE}=="disk", NAME="sdf"
OS
Centos 6.6
GPFS
Versione 3.5.0.26

Configurazione del file system

Dischi

Il file system homes_fs utilizza i sei dischi interni da 3 TB (da sda a sdf) come network shared disks (NSD).
I dischi sda delle due macchine sono dedicati ai metadati, i restanti sono dedicati ai dati ed appartengono ad uno storage pool separato.
Oltre ai dischi interni dei due server, il file system utilizza una partizione di sda su atlfarm008 in modalità descOnly per conservare una copia del file system descriptor.
Tutti i dischi sono raggruppati in failure group a seconda della macchina di appartenenza, e sia i dati sia i metadati sono replicati.

Ciascuna delle due macchine è quindi in grado di servire il file system anche in assenza dell'altra, a patto che atlfarm008.mi.infn.it sia attiva.
Questo perché il quorum sui file system descriptor deve essere garantito (2 su 3).

Questo è lo stato dei dischi come mostrato da mmdf:

[root@ts-a1-6 ~]# mmdf homes_fs
disk                disk size  failure holds    holds              free KB             free KB
name                    in KB    group metadata data        in full blocks        in fragments
--------------- ------------- -------- -------- ----- -------------------- -------------------
Disks in storage pool: system (Maximum disk size allowed is 4.1 TB)
ts_a1_5_sda         488386584        1 yes      no        470299904 ( 96%)       4151224 ( 1%) 
ts_a1_6_sda         488386584        2 yes      no        470064384 ( 96%)       4145944 ( 1%) 
atlfarm008_sda9          8000        3 no       no                0 (  0%)             0 ( 0%) 
                -------------                         -------------------- -------------------
(pool total)        976781168                             940364288 ( 96%)       8297168 ( 1%)

Disks in storage pool: data (Maximum disk size allowed is 8.2 TB)
ts_a1_5_sdb        2930266584        1 no       yes      2207559424 ( 75%)       1454328 ( 0%) 
ts_a1_5_sdc        2930266584        1 no       yes      2343154432 ( 80%)        984784 ( 0%) 
ts_a1_5_sdd        2930266584        1 no       yes      2591218944 ( 88%)        599024 ( 0%) 
ts_a1_5_sde        2930266584        1 no       yes      2928450816 (100%)          1680 ( 0%) 
ts_a1_5_sdf        2930266584        1 no       yes      2928438528 (100%)          1776 ( 0%) 
ts_a1_6_sdb        2930266584        2 no       yes      2207147008 ( 75%)       1464696 ( 0%) 
ts_a1_6_sdc        2930266584        2 no       yes      2344005632 ( 80%)       1005536 ( 0%) 
ts_a1_6_sdd        2930266584        2 no       yes      2590754560 ( 88%)        611312 ( 0%) 
ts_a1_6_sde        2930266584        2 no       yes      2928439552 (100%)          1736 ( 0%) 
ts_a1_6_sdf        2930266584        2 no       yes      2928438528 (100%)          1600 ( 0%) 
                -------------                         -------------------- -------------------
(pool total)      29302665840                           25997607424 ( 89%)       6126472 ( 0%)

                =============                         ==================== ===================
(data)            29302665840                           25997607424 ( 89%)       6126472 ( 0%)
(metadata)          976773168                             940364288 ( 96%)       8297168 ( 1%)
                =============                         ==================== ===================
(total)           30279447008                           26937971712 ( 89%)      14423640 ( 0%)

Inode Information
-----------------
Number of used inodes:         4520601
Number of free inodes:         2704743
Number of allocated inodes:    7225344
Maximum number of inodes:      8000000

cNFS

  • Le due macchine ts-a1-5 e ts-a1-6 fungono anche da server cNFS, con gli indirizzi IP 192.168.127.247 e 192.168.127.248.
 !!! ATTENZIONE !!!
 I due indirizzi IP non devono essere assegnati staticamente ai server (no ifcfg-eth:0 script in /etc/sysconfig/network-scripts).
 L'interfaccia di rete virtuale viene attivata e disattivata direttamente da mmfsd secondo le necessità.
  • Il bilanciamento del carico avviene tramite l'indirizzo virtuale ts-a1-nfs, che viene risolto in round robin sui due indirizzi.
    È anche possibile (ma sconsigliato) bilanciare manualmente il carico montando l'area /home sui client usando direttamente gli indirizzi IP delle due macchine.
  • Il demone standard rpc.quotad installato di default sui server non è in grado di leggere le quote di un file system GPFS.
    Per fare in modo che il comando "quota" funzioni sulle macchine dove sono montate le home, l'eseguibile originale è stato rinominato (/usr/sbin/rpc.quotad.orig) e sostituito con un eseguibile compilato per gpfs. Il sorgente si trova in /root/src e potrebbe essere necessario ricompilarlo in caso di upgrade di GPFS.

Snapshots

Su ts-a1-6 è installato (in /etc/cron.daily) questo cron job per la creazione di snapshot giornalieri del file system. Sono conservati gli snapshot degli ultimi 5 giorni.

Gli snapshot sono accessibili nella directory speciale /gpfs/homes_fs/.snapshots. Non essendo standard, non la si vede con "ls -a" e non funziona l'autocompletamento col tasto 'tab', ma è accessibile scrivendone per esteso il nome. Al suo interno ci sono gli snapshot dell'intero file system.
Per comodità, in ogni sottodirectory dell'albero è presente un'altra directory speciale ".snapshots" che contiene gli snapshot del solo sottoalbero. Di conseguenza ogni file di un medesimo snapshot è accessibile in diversi modi, inserendo ".snapshot/<nome_dello_snapshot>/" in qualunque punto del path.
Ad esempio, i seguenti puntano tutti allo stesso file:

 /gpfs/homes_fs/.snapshots/autosnap_20120711/home/bertolucci/public/myMatch.cc
 /gpfs/homes_fs/home/bertolucci/.snapshots/autosnap_20120711/public/myMatch.cc
 /gpfs/homes_fs/home/bertolucci/public/.snapshots/autosnap_20120711/myMatch.cc

Per vedere l'elenco degli snapshot con relativa data di creazione si usa il comando mmlssnapshot homes_fs:

 [root@ts-a1-6 ~]# mmlssnapshot homes_fs
 Snapshots in file system homes_fs:
 Directory                SnapId    Status  Created
 autosnap_20120707        150       Valid   Sat Jul  7 04:49:09 2012
 autosnap_20120708        151       Valid   Sun Jul  8 03:40:21 2012
 autosnap_20120709        152       Valid   Mon Jul  9 03:09:23 2012
 autosnap_20120710        153       Valid   Tue Jul 10 03:39:57 2012
 autosnap_20120711        154       Valid   Wed Jul 11 03:46:49 2012

Quote

Sul file system è attiva la gestione delle quote. Gli utenti hanno per default una quota di 100GB (in realtà 200GB, ma essendo attiva la replicazione dei dati lo spazio effettivo è dimezzato).
Per verificare lo stato delle quote, si può usare il comando mmrepquota -u homes_fs:

[root@ts-a1-5 cron.daily]# mmrepquota -u homes_fs
                         Block Limits                                    |                     File Limits
Name       type             KB      quota      limit   in_doubt    grace |    files   quota    limit in_doubt    grace
18432      USR               0  207618048  209715200          0     none |        0       0        0        0     none
11008      USR               0  207618048  209715200          0     none |        0       0        0        0     none
13024      USR               0  207618048  209715200          0     none |        0       0        0        0     none
12512      USR         8508400  207618048  209715200          0     none |    54785       0        0        0     none
11552      USR       302873328  207618048  209715200          0  expired |    12738       0        0        0     none
[...]

Per assegnare una quota specifica ad un utente si usa il comando mmedquota -u <uid>, mentre per ripristinare la quota di default si usa mmedquota -d -u <uid>.
N.B.: a causa della replicazione dei dati, la quota inserita con mmedquota deve essere doppia rispetto a quella che si vuole assegnare.

Su ts-a1-5 è installato (in /etc/cron.daily) questo cron job per il controllo delle quote, che invia un alert automatico via e-mail agli utenti che superano la propia quota.

Amministrazione

Tutte le seguenti operazioni sono illustrate nella documentazione di GPFS.
Riporto qui eventuali caveat, difformità o passaggi poco chiari, in base alle esperienze "sul campo".

Problema di "permission denied" sui client

A causa del problema illustrato qui, dopo un riavvio di GPFS alcuni client potrebbero non riuscire a montare il file system via NFS ricevendo un "permission denied". La soluzione al momento e' quella di riavviare il servizio NFS (service nfs restart).

Risolto con la versione 3.4.0.22 di GPFS.

Rimozione temporanea di una macchina dal cluster

Prima di fermare un server per manutenzione, occorre verificare che sia l'altro server sia atlfarm008 siano up and running e che tutti i loro dischi siano available:

# mmlsdisk homes_fs
disk         driver   sector failure holds    holds                            storage
name         type       size   group metadata data  status        availability pool
------------ -------- ------ ------- -------- ----- ------------- ------------ ------------
ts_a1_5_sda  nsd         512       1 Yes      No    ready         up           system       
ts_a1_5_sdb  nsd         512       1 No       Yes   ready         up           data         
ts_a1_5_sdc  nsd         512       1 No       Yes   ready         up           data         
ts_a1_5_sdd  nsd         512       1 No       Yes   ready         up           data         
ts_a1_5_sde  nsd         512       1 No       Yes   ready         up           data         
ts_a1_5_sdf  nsd         512       1 No       Yes   ready         up           data         
ts_a1_6_sda  nsd         512       2 Yes      No    ready         up           system       
ts_a1_6_sdb  nsd         512       2 No       Yes   ready         up           data         
ts_a1_6_sdc  nsd         512       2 No       Yes   ready         up           data         
ts_a1_6_sdd  nsd         512       2 No       Yes   ready         up           data         
ts_a1_6_sde  nsd         512       2 No       Yes   ready         up           data         
ts_a1_6_sdf  nsd         512       2 No       Yes   ready         up           data         
atlfarm008_sda9 nsd         512       3 No       No    ready         up           system

Se la verifica è positiva, procedere allo shutdown di GPFS con mmshutdown. Assolutamente non stoppare NFS, né smontare il file system prima dello shutdown (mmfsd potrebbe tentare di riavviare la macchina). I dischi della macchina in manutenzione verranno marcati come down.

In caso di upgrade di GPFS, e' necessario ricompilare il compatibility layer prima di riavviare GPFS. Lo stesso vale in caso di upgrade del kernel, ma in questo caso è più semplice riavviare la macchina prima di ricompilare. Al riavvio, GPFS non riuscirà ad avviarsi finché il nuovo compatibility layer non è pronto. Se si vuole evitare di "sporcare" il log, è consigliabile evitare l'avvio automatico con chkconfig:

# mmshutdown
# yum update kernel
# chkconfig gpfs off
# reboot
# cd /usr/lpp/mmfs/src
# make clean && make LINUX_DISTRIBUTION=REDHAT_AS_LINUX Autoconfig && make World && make InstallImages
# chkconfig gpfs on
# mmstartup

Una volta riavviato GPFS è necessario resuscitare i dischi con mmchdisk. L'operazione può richiedere diversi minuti, potrebbe essere quindi utilile eseguirla con screen:

# screen -L mmchdisk homes_fs start -a

Il comando provvede automaticamente a riaggiustare la replicazione dei dati eventualmente scritti mentre i dischi erano down.

Sostituzione di un disco

Operazioni preliminari su GPFS

Eliminare il disco dal file system:

mmdeldisk homes_fs "<nome disco da rimuovere>" -N 10-11

GPFS sposterà i dati contenuti nel disco (se ancora leggibile) sugli altri dischi. L'opzione -N serve ad evitare di caricare le altre macchine del cluster con le operazioni di spostamento.

Eliminare la definizione dell'NSD dal disco:

mmdelnsd "<nome disco da rimuovere>"
"Eject" del disco

Recuperare l'identificativo scsi del disco:

lsscsi | grep /dev/<device>

Fermare il disco:

sg_start -v --stop /dev/<device>

Rimuovere il device:

echo "scsi remove-single-device x y z w" > /proc/scsi/scsi

dove x, y, z, w sono i valori restituiti dal comando lsscsi

Esempio:

[root@ts-a1-5 ~]# lsscsi | grep /dev/sdd
[7:0:0:0]    disk    ATA      ST3500630AS      3.AA  /dev/sdd
[root@ts-a1-5 ~]# sg_start -v --stop /dev/sdd
    Start stop unit command: 1b 00 00 00 00 00
[root@ts-a1-5 ~]# echo "scsi remove-single-device 7 0 0 0" > /proc/scsi/scsi
Sostituzione del disco

Utilizzare la tabella ad inizio pagina per identificare la posizione del disco da sostituire.

Riavvio del device
echo "scsi add-single-device x y z w" > /proc/scsi/scsi

dove x, y, z, w sono sempre i valori restituiti dal comando lsscsi

Reinserimento in GPFS

Utilizzare i comandi mmcrnsd e mmadddisk per ricreare l'NSD e reinserirlo nel file system




Ho postato qui la procedura che ho seguito per cambiare il primo disco che si è guastato.

Ribilanciamento del file system

todo

Configurazione di smartd

todo

Todo list

  • Backup
  • Monitoring e allarmistica (Ganglia, Nagios, smartd, 3ware...)
  • Notifica via e-mail del superamento quota
  • Valutazione e acquisto ricambi