Cluster GPFS

From Atlmiwiki

Per maggiori informazioni sui comandi gpfs, consultare il sito IBM:
GPFS commands

In ogni caso si ricordi sempre:

      Usare se possibile SOLO i comandi della serie mmxxxxxx, propri di gpfs, che oltre a indicare l'operazione svolta, controllano molti 
      altri comportamenti del demone mmfsd (l'esecutore di gpfs). Si dimentichi in questo caso che esiste un service, o un /etc/init.d/xxxxxx
      I comandi gpfs sono tutti graceful, possono essere interrotti con ctrl+C senza troncare le transazioni, esiste un file di lock amministrativo 
      che impedisce l'esecuzione di certi comandi, se la precedente operazione non è terminata. Raramente inoltre è necessario un intervento manuale
      sul mount dei filesystems, come sullo stato di un demone.
      Spesso le transazioni vengono lanciate in differita e in parallelo su tutti i managers del clusters, condizione indicata dal messaggio di uscita del 
      comando, che riporta "...This is an asynchronous process..."

Contents

Installazione di GPFS

Gli RPM per l'installazione di GPFS sono in una repository su atlfarm015. E' possibile scaricare il file .rep con il comando

 wget http://atlfarm015.mi.infn.it/private/gpfs/gpfs.repo

Installazione e configurazione di Nagios

  • Installare i pacchetti nrpe e nagios-plugins
  • Creare il file /usr/lib/nagios/plugins/check_gpfs.sh o /usr/lib64/nagios/plugins/check_gpfs.sh con il seguente contenuto:
#!/bin/sh
##########################################################################
#
# Filename: check_gpfs.sh
# Author:   Michele Bensi <michele.bensi@fisica.unimi.it>
# Date:     2009-06-23
# Purpose:  check if gpfs daemon is active
# WARNING:  user nagios must be allowed to run mmgetstate as root
#           without password in sudoers file
#
# UPDATES:  With recent RHEL releases and derivatives, nrpe runs
#           as 'nrpe' and not as 'nagios', be sure to configure
#           sudoers accordingly. 2014-08-11 dr.
#           Added version info in status report. 2014-08-13 dr.
#########################################################################

/usr/bin/sudo /usr/lpp/mmfs/bin/mmgetstate | /bin/awk '
BEGIN {
  OK       = 0
  WARNING  = 1
  CRITICAL = 2
  UNKNOWN  = 3
}
NR == 4 {
  if ( $3 == "active" ) {
      printf "OK - "
      system("/usr/bin/sudo /usr/lpp/mmfs/bin/mmdiag --version | grep ^[CR] | paste -sd\\  -")
      exit OK
  }
  else if ( $3 == "arbitrating" ) {
      printf "WARNING - GPFS is arbitrating"
      exit WARNING
  }
  else if ( $3 == "down" ) {
      printf "CRITICAL - GPFS down"
      exit CRITICAL
  }
  else {
      printf "UNKNOWN - GPFS unkown state"
      exit UNKNOWN
  }
}'
  • Aggiungere il server nagios (atlfarm011.mi.infn.it al momento in cui scrivo) al parametro allowed_hosts in /etc/nagios/nrpe.cfg
  • Creare il file /etc/nrpe.d/gpfs.cfg con il seguente contenuto:
# GPFS commands
command[check_gpfs]=/usr/lib/nagios/plugins/check_gpfs.sh
  • Creare il file /etc/sudoers.d/nagios con il seguente contenuto (sostituire 'nrpe' con l'utente effettivo sotto cui gira il demone nrpe):
# Allow sudo via ssh (i.e. without a tty)
Defaults:nrpe   !requiretty

# Allowed commands
Cmnd_Alias      GPFS_COMMANDS = /usr/lpp/mmfs/bin/mmdiag, /usr/lpp/mmfs/bin/mmgetstate

# Nagios check
nrpe            ALL=(root) NOPASSWD: GPFS_COMMANDS
  • Riavviare il servizio nrpe

Ovviamente, se non è già presente occorre aggiungere il check per GPFS nella definizione dell'host sul server Nagios.

Operazioni Preliminari e MANDATORY

  • Creare una chiave ssh per l'utente root comune per tutte le macchine che faranno parte del cluster gpfs, e distribuirla.
  • Modificare /etc/ssh/ssh_config, togliendo la richiesta obbligatoria della chiave
 -> 'StrictHostKeyChecking no'
  • Sincronizzare TUTTE le macchine via ntp.
  • Impostare i jumboframe sulle interfacce di rete coinvolte (naturalmente anche lato switch)
  • Configurare le interfacce di rete in bonding sulle macchine dove si preveda un forte afflusso di dati
  • stabilire una lan comune di appartenenza di un cluster. Non è indispensabile, ma assicura buone prestazioni. Clusters gpfs diversi possono anche non avere la stessa lan.
  • Eseguire questa ottimizzazione di rete su tutte le macchine:
cat >> /etc/sysctl.conf <<set

# GPFS Settings
net.core.rmem_max = 8388608 
net.core.wmem_max = 8388608
net.ipv4.tcp_rmem = 4096 262144 8388608
net.ipv4.tcp_wmem = 4096 262144 8388608
net.core.netdev_max_backlog = 2500
set
  • per SL5 non è stato previsto lo use-case specifico per compilare modulo mmfsd del kernel. Prima di compilare, occorre customizzare il file

/usr/lpp/mmfs/src/config/site.mcr con questa riga

       SITE_DEFINES += -DREDHAT_AS_LINUX -DRHEL_RELEASE_CODE=1282

questo renderà il caso SL5 simile a RedHat Enterprise Edition, normalmente contemplato da gpfs.

  • Per procedere con l'installazione occorre:
    • installare gli rpm di gpfs
    • installare cpp.x86_64, gcc-c++*, compat-gcc* kernel-devel-*
    • per i nodi a 64bit eseguire questi comandi, per compilare il modulo mmfsd (il demone gpfs):
#!/bin/bash

cd /usr/lpp/mmfs/src
export SHARKCLONEROOT=/usr/lpp/mmfs/src

# specifico del kernel in dotazione, cambiare a seconda delle esigenze
os=$(uname -r)
if [ "${os:0:8}" == "2.6.9-89" ]
then
        ext=2060989
elif [ "${os:0:10}" == "2.6.18-164" ]
then
        ext=2061899
fi

# GPFS_ARCH_XXXXX può ovviamente variare a seconda dell'architettura hardware a disposizione
sed -i -e "s/LINUX_DISTRIBUTION =.*/LINUX_DISTRIBUTION = REDHAT_LINUX/g" config/site.mcr
sed -i -e "s/define GPFS_ARCH_I386/define GPFS_ARCH_X86_64/g" config/site.mcr
sed -i -e "s/define LINUX_KERNEL_VERSION .*/define LINUX_KERNEL_VERSION $ext/g" config/site.mcr
echo "SITE_DEFINES += -DREDHAT_AS_LINUX -DRHEL_RELEASE_CODE=1282" >> config/site.mcr

make World InstallImages


Creazione Cluster

Quello che segue è un esempio che illustra le operazioni necessarie a creare una gerarchia di cluster gpfs:

       mmcrcluster -n nodelist.txt -R /usr/bin/scp -r /usr/bin/ssh -p ts-b1-1.mi.infn.it -s ts-b1-2.mi.infn.it -A -C clustername.mi.infn.it -U mi.infn.it

la lista di nodi specificata con -n ha questo formato:

<hostname>:<usage= client, manager-quorum, manager-nonquorum>

occorre scegliere due nodi come cluster configuration manager primary (-p) e secondary (-s). In caso di maintenance che coinvolgano questi nodi è necessario trasferirne il ruolo ad altre macchine:

       mmchcluster -p <other nodename> (o -s)

Questo cambio di ruolo funziona sempre, anche in caso di spegnimento o arresto critico dei precedenti configuration manager, perché è critico per la sopravvivenza del cluster. Anche i ruoli per gli altri nodi possono essere ruotati al volo. Alcuni esempi:

      mmchnode -N <a nodename> --quorum --manager
      mmchnode -N <a nodename> --nonquorum --manager
      mmchnode -N <a nodename> --quorum --manager
      mmchnode -N <a nodename> --client

Un nodo manager può non essere quorum, ma non è vero il viceversa. Un nodo manager può assolvere alle funzioni di filesystem manager, token manager. Consultare IBM Il cambio ruolo viene in aiuto durante le operazioni di maintenance a caldo. Si consiglia per questo di trasformare uno o più nodi in client, togliendoli dal pool di managers del cluster.

mmchconfig pagepool=2048M,unmountOnDiskFail=no,tiebreakerdisks=no,mmsdrservTimeout=20,idleSocketTimeout=72000,totalPingTimeout=180,maxMissedPingTimeout=120,maxMBps=250

Alcuni di questi cambiamenti alla configurazione (es. il pagepool) possono essere effettuati a caldo mentre il cluster è operativo. IBM Il pagepool è l'area di memoria riservata a gpfs per le operazioni di buffering dati. Può essere determinate per le prestazioni.

Tra i nodi specificati possono esserci delle macchine scelte per essere NSD servers (network shared disk), che quindi condividono l'area disco ad essi fisicamente collegata con le altre macchine del cluster. Gli nsd possono anche non essere managers del cluster.Non è indispensabile, ma si consiglia anzi di lasciare in bianco il ruolo per queste macchine (di default: client), affinché servano solo il dato e non debbano anche far parte di un quorum.


      se si usa multipath, occorre controllare che su tutti i server il binding multipath sia uguale :
      /var/lib/multipath/bindings, altrimenti i dischi avranno nomi diversi su ogni macchina
      e non potranno essere usati nella configurazione nsd
      modificare inoltre il file /var/mmfs/etc/nsddevices, 
      per dare a gpfs indicazione dei dischi validi da poter usare nel mmnsddiscover 
      (va eseguito su tutti i manager). Nel caso di multipath le lun non risultano in /proc/partitions e gpfs 
      non puo' trovarle in automatico. (Una simile impostazione si trova su ts-b1-5/6)


      se usano regole di udev per rimappare il nome dei drives occorre modificare il predetto nsddevices per leggere da /dev/ 
      il nome aggiornato dei dispositivi. (Una simile impostazione si trova sull tripletta ts-a1-9/10/11)


Aggiunta/Rimozione di macchine ad un cluster

Una volta preparata una macchina con gpfs e compilato il modulo del kernel, è possibile aggiungerla, previa copia della adegauta chiave ssh su di essa, col comando:

      mmaddnode <nome macchina>

Il comando può essere eseguito da qualunque macchina del cluster a cui dovrà appartenere il nuovo nodo. Per togliere un nodo dal cluster:

      mmdelnode -N <nome macchina>

Quest'ultima operazione è utile anche nel caso di spostamento di un nodo da un cluster ad un altro. Può essere fatta anche in caso di guasto/spegnimento del nodo, in ogni caso funziona solo se il suo demone gpfs è spento.

Se occorre spostare una macchina da un cluster all'altro, occorre sempre eseguire mmdelnode sul cluster di provenienza, prima. Esiste una condizione particolare per cui si può realizzare uno stato anomalo: l'intersezione fra due cluster. Se una macchina viene spenta, reinstallata (quindi i suoi files di configurazione gpfs risultano azzerati), ma nel cluster di cui faceva parte risulta ancora presente, al termine della sua configurazione gpfs questa macchina figurerà in entrambi i cluster. Potrebbero esserci conflitti durante le più comuni operazioni globali.

E' possibile re-introdurre una macchina nello stesso cluster, dopo aver fatto la reinstallazione, l'upgrade o altro, senza doverla rimuovere con mmdelnode.
Ad una macchina solo client non viene richiesta obbligatoriamente la presenza online per la sussistenza del cluster, quindi la si può spegnere e reinstallare. Al termine delle operazioni basta lanciare su di essa il comando:

      mmsdrrestore -p <template-node> -R /usr/bin/scp

Questo comando copia la configurazione gpfs da un nodo qualsiasi (-p) del cluster a cui lo si vuole agganciare. Dal momento che il nome di questa macchina era già presente nel cluster, i cluster manager non troveranno niente di strano a ripristinarvi la configurazione attuale.
La macchina nuova si troverà ad avere quindi le stesse impostazioni del cluster gpfs che aveva in precedenza, senza alcuna variazione di sorta.
Il presupposto è sempre che il nome con cui era stata dichiarata (in mmaddnode) al principio sia rimasto lo stesso.


creazione dischi logici gpfs

mmcrnsd -F nsd-list.txt -v no


dove i file specificati con -F hanno questo formato:

<device>:<server list>::<usage>:<failure group>:<name>

sdb:ts-b1-2,ts-b1-1,ts-b1-4,ts-b1-3::dataAndMetadata:1:c2

sdc:ts-b1-3,ts-b1-4,ts-b1-1,ts-b1-2::dataAndMetadata:1:c3

sdd:ts-b1-4,ts-b1-3,ts-b1-2,ts-b1-1::dataAndMetadata:1:c4

sde:ts-b1-1,ts-b1-2,ts-b1-3,ts-b1-4::dataAndMetadata:1:c5

Occorre specificare quindi il nome del drive fisico, solitamente trovato da gpfs dentro /proc/partitions, a meno che non sia installato lo script /var/mmfs/etc/nsddevices.

   N.B. se si usa multipath, il nome del device creato in /dev/mpath non compare in /proc/partitions.
L'unico modo per far digerire il nome "composto" mpath/wwid è usare lo script /var/mmfs/etc/nsddevices, come spiegato (circa) qui.

Gli nsd servers preposti, ovvero quelli che possono fisicamente raggiungere i drives, tutti i servers devono leggere lo stesso nome per lo stesso drive.
L'utilizzo del drive, che può essere: dataOnly, metadataOnly, dataAndMetadata. Per grandi installazioni si consiglia di dividere i dischi in base allo scopo alle loro caratteristiche fisiche. Leggere in tal senso la documentazione sugli storage pools IBM
Numero di Failure group di appartenenza. A meno di creare un filesystem con replicazione integrata, settare sempre allo stesso numero tutti i drives.
Nome del nsd associato al drive fisico. D'ora in avanti gpfs tratterà il disco con questo nome.

      ATTENZIONE! Al nome del device fisico nel primo campo, se viene ripetuto inavvertitamente nelle righe del file di configurazione, gpfs lo sostituirà
      alla precedente definizione, cancellandone di fatto l'esistenza. In assenza della replicazione builtin di gpfs, questo provoca 
      un arresto critico del filesystem. Controllare sempre le dichiarazioni nel file di configurazione.

creazione cluster slave

mmcrcluster -n wn.txt -R /usr/bin/scp -r /usr/bin/ssh -p wn-b1-1.mi.infn.it -s wn-b1-10.mi.infn.it -A -C glite-condor-nodes.mi.infn.it -U mi.infn.it

Il clustering gpfs è fondamentale per governare separatamente macchine aventi le stesse caratteristiche funzionali e controllare la visibilità di determinati filesystems da parte di esse. Nel sito sono presenti i seguenti clusters:

  • master 1
  • master 2
  • glite-condor-nodes
  • glite-pbs-nodes
  • glite-UI-nodes
  • storm-nodes
  • glite-tier3-nodes
  • glite-proof-nodes
  • glite-x86_64-condor-nodes

l'immagine seguente illustra la situazione:

Image:milan-clustering.jpg


creazione filesystems

     mmcrfs /dev/storage_2 -F nsd-list.txt -B 256K -m 1 -M 2 -r 1 -R 2 -Q yes -n 512 -A yes -v no

I parametri -m -M -r -R stabiliscono i coefficienti di replicazione. Se:

  • si impostano maggiori di 1
  • esistono più failure groups per gli nsd

gpfs sarà abilitato alla replicazione dei files, che è difficile da annullare. Si consiglia quindi di stabilire a priori se sia il caso di far ridondare a gpfs i blocchi dati o meno.

     mmmount storage_2 -a
     mmumount storage_2 

Questi comandi montano/smontano il filesystem su tutti i nodi di un cluster. Il mount esplicito non è necessario se il filesystem viene creato, oppure linkato da un cluster slave, con l'opzione -A yes. In caso di failures di rete o altro, tutti i nodi di qualsiasi cluster tendono a recuperare autonomamente i filesystems importati.
Quindi non è generalmente necessario montare/smontare manualmente, a meno di interventi o di condizioni di particolare urgenza.


creazione sistema di quote

I comandi, da lanciare da una qualsiasi macchina manager GPFS, sono i seguenti. In generale si crea un fileset GPFS (mmcrfileset) e poi lo si collega ad un filesystem prescelto (mmlinkfileset). NON creare la directory manualmente, altrimenti resterà sconnessa dal sistema quote, questo verrà invece fatto in automatico da GPFS. ATTENZIONE! Se si usano i fileset come tokens di StoRM, occorre cambiare l'owner delle directories in "storm", altrimenti il backend non riuscirà ad accedervi Es.

mmcrfileset /dev/storage_2 atlasdatadisk

mmcrfileset /dev/storage_2 atlasmcdisk
...
...

mmlinkfileset /dev/storage_2 atlasdatadisk -J /gpfs/storage_2/atlas/atlasdatadisk

mmlinkfileset /dev/storage_2 atlasmcdisk -J /gpfs/storage_2/atlas/atlasmcdisk

mmquotaon -a

Per editare le quote assegnate ai singoli fileset usare l'editor gpfs

         mmedquota -j <device>:<fileset> (Es. mmedquota -j storage_2:atlasmcdisk)

Impostare in questo modo i limits (soft e hard) sui valori desiderati. Salvare e chiudere. Il sistema si adatterà automaticamente

Per un report sulle quote attualmente in essere per i filesets, e sullo spazio fisicamente occupato dai singoli, usare il comando:

         mmrepquota -j <device>

per il remote mount dal master cluster agli slaves

Occorre creare preliminarmente sui clusters coinvolti le chiavi di sicurezza: mmauth genkey new

mmauth update . -l AUTHONLY

e copiarle su un manager del cluster partner

sul cluster master

       mmauth add clusterN  -k <chiave mmauth generata sullo slave>
       mmauth grant clusterN -f /dev/storage_1

sul cluster slave:

scambiare le chiavi publiche tra master e slave (file /var/mmfs/ssl/id_rsa.pub)

       mmremotecluster add clusterMaster -k <chiave generata sul master> -n <lista almeno due nodi del master da contattare>
       mmremotefs add /dev/storage_1 -f /dev/storage_1 -C clusterMaster

Sui cluster slave il mount dei filesystems è automatico alla partenza del demone gpfs solo se mmremotefs viene lanciato con l'opzione -A yes

waiters

Esistono dei thread, generati dal demone mmfsd, che gestiscono le varie operazioni di accesso ai filesystems.
C'è una coda che regola le priorità. Nel caso la cloud gpfs non riesca ad evadere tutte le request, i threads rimangono in waiting su una o più macchine del cluster. Per monitorare la situazione, da qualsiasi macchina del cluster sospetto di processi waiting:

       mmlsnode -N waiters

Con l'opzione -L, mostra il dettaglio di quale macchina aspetta, con quale tempistica e l'operazione rimasta ancora in sospeso.
I waiters non sono un evento negativo, ma possono essere un sintomo di qualche anomalia (timeout di rete, nodi in down, nsd offline, sovraccarico di memoria)
Generalmente valori fino al secondo di attesa sono normali e non critici per il corretto funzionamento. L'insorgenza di un problema risulta evidente a partire dai 60 secondi in su. In tal caso significa che esistono anomalie su una macchina in particolare che non riesce ad accedere al dato. Il messaggio descritto dal waiter indica solitamente quale ip o macchina sta avendo difficoltà. Esiste anche un comando specifico di mmfsd:

       mmfsadm dump waiters

che agisce però solo sulla macchina corrente.

monitoring performance

Il comando mmpmon fornisce una statistica dell'utilizzo e della banda usata da gpfs:

       mmpmon -i command-file -p -d 1000 -r 10 | awk -f parsing-file

dove command-file ha questa forma:

       once nlist new ts-b1-1 ts-b1-2 ts-b1-3 ts-b1-4 ts-b1-5 ts-b1-6 ts-b1-7 ts-b1-8
       fs_io_s

questo compila una lista dei nodi da monitorare, estrae le statistiche in riferimento ai filesystem e a tutte le macchine listate
Il comando poi esce con un output in formato da parsing (-p), eseguendo 10 ripetizioni (-r) con un ritardo di 1 secondo (-d) tra un'iterazione e l'altra
Se si desidera un output human-readable, omettere -p Qualunque sia il programma che effettua il parsing, è possibile ottenere una statistica della banda utilizzata per differenze tra i valori di un'iterazione e l'altra.

Clustered NFS

Il clustered NFS è un sistema di parallelizzazione del servizio nfs, che prepone al demone nfsd un layer gestito da gpfs.
E' utile per ridondare nfs aumentando la banda disponibile per l'export remoto dei filesystems.
E' presente nel core di ogni installazione gpfs ma non è auspicabile attivarlo sullo stesso cluster che serve i dati, poiché ogni anomalia del servizio causata da irraggiungibilità delle macchine o timeout di rete causa instabilità nella gestione dei managers o dei disk-servers, e provoca il blocco di gpfs a catena anche su tutti i cluster slave remoti che utilizzano i filesystems gpfs normali. La configurazione ideale per CNFS è su un cluster slave distinto, in modo da disaccoppiarlo dai filesystems gpfs cui è agganciato, formato da macchine che non debbano accedere fisicamente a degli storage. Oppure in un cluster stand-alone, anche connesso a degli storage, il cui unico scopo però sia di fornire l'area CNFS.
In ogni caso se possibile è opportuno che le macchine del cluster su cui viene acceso il cnfs non siano anche quorum-managers del cluster. Poi, a seconda della disponibilità di macchine, si possono comunque rilassare i requirements, purché appunto lo scopo sia solo questo, perché un eventuale disservizio non provoca il collasso dell'intero sistema.

  • associare sul dns N indirizzi ad un vip comune:
nslookup ts-b1-nfs
Server:         192.135.14.3
Address:        192.135.14.3#53

Name:   ts-b1-nfs.mi.infn.it
Address: 192.168.127.238
Name:   ts-b1-nfs.mi.infn.it
Address: 192.168.127.239
Name:   ts-b1-nfs.mi.infn.it
Address: 192.168.127.240
Name:   ts-b1-nfs.mi.infn.it
Address: 192.168.127.237
  • creare un file temporaneo /tmp/nfs-server-list con la lista dei nodi che serviranno il filesystem via nfs:
ts-b1-1.mi.infn.it --cnfs-interface=ts-b1-1-nfs.mi.infn.it<br/>
...<br/>
...<br/>
ts-b1-4.mi.infn.it --cnfs-interface=ts-b1-4-nfs.mi.infn.it
  • creare il file /etc/exports su tutte le N macchine coinvolte, specificando un sid prescelto per il filesystem:
      /gpfs/software/exp_software 192.168.125.0/24(ro,no_root_squash,fsid=666)
  • configurare il cluster di cui i nodi CNFS prescelti fanno parte:
      mmchconfig cnfsSharedRoot=/gpfs/sharedVolume/mydir,cnfsVIP=ts-b1-nfs.mi.infn.it
  • attivare:
      mmchnode -S /tmp/nfs-server-list


Per listare i nodi del cluster, che hanno anche il servizio cnfs attivato:

     mmlscluster --cnfs

Per disattivare temporaneamente una macchina cnfs:

      mmchnode -N <node> --cnfs-disable

gpfs garantisce il failover sulle altre cnfs. Per riattivarla:

      mmchnode -N <node> --cnfs-enable


Per togliere definitivamente una macchina dal pool cnfs:

      mmchnode -N <node> --cnfs-interface=DELETE

anche in questo caso gpfs attua un failover sulle altre macchine cnfs, ma questa non verrà mai più considerata
Eliminato anche l'ultimo nodo cnfs, il pool nfs si dissolve.

Alcuni comandi

visualizzare i dischi logici di gpfs

mmlsnsd

visualizzare un filesystem

mmdf <fsname> (es. storage_2)

questa è un'operazione di dettaglio, che può essere time-consuming. Se appare lenta è normale

oppure per la sua configurazione:

mmlsfs <fsname>

visualizzare i componenti di un cluster

mmlscluster

per la sua configurazione:

mmlsconfig

Quest'ultimo visualizza solo l'ultima configurazione del cluster impostata, ma non quella operativamente presente sulla macchina corrente.
Per verificare quest'ultima:

mmfsadm dump config

questo mostrerà tutti i parametri realmente funzionanti allo stato attuale sulla macchina. Se non appaiono come in mmlsconfig, significa che è necessario un restart locale di gpfs:

mmfsadm cleanup

che risulta sempre l'opzione migliore, in quanto il restart è immediato.

Oppure:

mmshutdown
seguito da
mmstartup

aggiungere dischi logici a un filesystem

mmadddisk <fsname> -F nsd-extra.txt

eliminare dischi logici da un filesystem

mmdeldisk <fsname> -F nsd-to-remove.txt
oppure: mmdeldisk <fsname> "diskname;diskname;..."

       Le precedenti 2 operazioni possono essere effettuate anche a caldo, se si desidera che gpfs provveda a 
       ridistribuire i dati sui dischi effettivi rimasti, si usi l'opzione -r. Si consiglia comunque di aggiungere anche l'opzione -N 
       per limitare il numero di nodi del cluster che partecipa all'operazione, e di cambiare il ruolo di questi nodi prescelti
       a client, così da non rallentare le operazioni del pool di managers gpfs.

start e shutdown del demone gpfs

mmstartup

mmshutdown (su singola macchina)

aggiungere l'opzione "-a", per operare su tutto il cluster

variazione delle quote associate a un token

Esempi riferiti al caso di quote allocate per fileset. Nel caso presente, ogni fileset gpfs equivale a un token atlas, ed è associato ad una storage-area di StoRM.
Per ottenere informazioni sul sistema di quote impostato sui filesets del filesystem storage_5:

mmrepquota -j storage_5

per modificare la quota del fileset atlaslocalgroupdisk

mmedquota -j storage_5:atlaslocalgroupdisk

Le quote gpfs sono nominali, il sistema presume cioè che entro il limite prestabilito ci sarà spazio fisico ulteriore. Esiste per questo un softlimit, oltre il quale è sicuramente meglio aggiungere altri nsd al filesystem col comando mmadddisk. In ogni caso, quando la quota arriva al hardlimit, il sistema risponde con un messaggio appropriato ad eventuali altri tentativi di scrittura.

report dei cluster remoti

da un nodo di un cluster slave è possibile conoscere quali sono i cluster master che gli esportano dati con:

mmremotecluster show

Cluster name:    glite-condor.mi.infn.it
Contact nodes:   ts-b1-1,ts-b1-2,ts-b1-5,ts-b1-7
SHA digest:      ef44efa441c75d8c0d869a43c46ad2d0b888ba59
File systems:    storage_1 (storage_1)  storage_2 (storage_2)  

Cluster name:    infn-mi-cluster.mi.infn.it
Contact nodes:   ts-a1-1.mi.infn.it,ts-a1-3.mi.infn.it,ts-a1-5.mi.infn.it
SHA digest:      a3b202a2bcb2c7b0f10589700a012a4633036ef3
File systems:    storage_4 (storage_4)  storage_5 (storage_5)  

Da un cluster master è possibile visualizzare gli slaves:

mmauth show

Cluster name:        glite-UI-nodes.mi.infn.it
Cipher list:         AUTHONLY
SHA digest:          f64d844ca7b48754708168f31c4195695a514ce8
File system access:  sharedVolume (rw, root allowed)
                     storage_2 (rw, root allowed)

Cluster name:        glite-condor-nodes.mi.infn.it
Cipher list:         AUTHONLY
SHA digest:          9ba4c748ca0412dd90079a63dd2d9b2e7d3f022d
File system access:  sharedVolume (rw, root allowed)
                     software  (rw, root allowed)
                     storage_2 (rw, root allowed)

Cluster name:        glite-pbs-nodes.mi.infn.it
Cipher list:         AUTHONLY
SHA digest:          c09c680ae886c39b852797c7c8ad08d4d8b2ca6e
File system access:  sharedVolume (rw, root allowed)
                     storage_2 (rw, root allowed)

Cluster name:        glite-proof-nodes.mi.infn.it
Cipher list:         AUTHONLY
SHA digest:          2bc02dbff580aa9547b3e7b155bfde77e0ed7f31
File system access:  storage_2 (ro, root allowed)

Cluster name:        glite-tier3-nodes.mi.infn.it
Cipher list:         AUTHONLY
SHA digest:          35001093a365dcdb08304c2a6b810600acf64740
File system access:  sharedVolume (rw, root allowed)
                     storage_2 (rw, root allowed)

Cluster name:        glite-x86_64-condor-nodes.mi.infn.it
Cipher list:         AUTHONLY
SHA digest:          d577fca07f1662d247ac5e81592de14d9d4c9cd1
File system access:  sharedVolume (rw, root allowed)
                     storage_2 (rw, root allowed)

Cluster name:        storm-nodes.mi.infn.it
Cipher list:         AUTHONLY
SHA digest:          c7cfd9664b214aed811134df085d0ae3806e125e
File system access:  sharedVolume (rw, root allowed)
                     storage_2 (rw, root allowed)

Cluster name:        glite-condor.mi.infn.it (this cluster)
Cipher list:         AUTHONLY
SHA digest:          ef44efa441c75d8c0d869a43c46ad2d0b888ba59
File system access:  (all rw)

restripe dei filesystems

Si tratta di un'operazione volta a distribuire i dati su tutti i NSD gpfs, in modo tale da sfruttare la banda complessiva di tutti i disk servers.
Benché tutti i dischi associati ad un filesytems siano visibili a gpfs, che ne fa sempre un corretto striping, se ne vengono aggiunti altri in un secondo momento la distribuzione dei blocchi rimane asimmetrica. L'operatore può quindi effettuare un restripe a valle della configurazione di spazio addizionale.

       mmrestripefs <fileystem> -b -N <node1>,<node2>,...,<nodeN>

in questo modo si ribilancia il contenuto del filesytem, usando come nodi esecutori la lista indicata con -N Come riprova della loro attività è sufficiente lanciare da una qualsiasi macchina del cluster il comando

       mmlsnode -N waiters -L

che mostrerà come effettivamente ci siano delle operazioni di I/O sui nodi indicati. Tempistiche inferiori al secondo indicano delle buone prestazioni durante l'accesso.
La procedura è:

  • scegliere N macchine su cui parallelizzare il restripe, togliere loro ogni possibile ruolo amministrativo, bastano dei client sullo stesso cluster che serve il filesystem
  • togliere se possibile ogni ruolo amministrativo dalle macchine che servono fisicamente il filesystem. Si ricorda che i managers del cluster non devono essere necessariamente anche disk-server (connessi cioè allo storage) o viceversa.
  • lanciare il suddetto comando

Esistono più modalità per eseguire il restripe. L'opzione -b si limita a ridistribuire. Leggere le istruzioni.
Il restripe può essere fatto anche contestualmente all'aggiunta di nsd, con mmadddisk, leggere il manuale relativo.
L'operazione può durare molte ore, ma in condizioni operative normali non influisce più di tanto sulla banda del servizio o sulle prestazioni delle macchine coinvolte, se fatta contestualmente a mmadddisk esiste un'opzione con cui può essere anche eseguita in background.
I files restano comunque disponibili, gpfs garantisce un sistema di lock and wait che impedisce l'accesso simultaneo di un file in fase di spostamento (motivo per cui il restripe dura molto tempo, quando il sistema è in servizio)

        ATTENZIONE: 
        è possibile interrompere il comando mmrestripefs con ctrl+C, ma il restripe fisico dei blocchi del filesystem cesserà realmente solo 
        quando tutte le transazioni in corso sono terminate. 
        Monitorare con mmlsnode -N waiters -L
        NON effettuare mmshutdown ne pianificare spegnimenti del cluster servente, finché compaiono ancora threads relativi a I/O sui dischi. Esempio di messaggio tipico:
        ts-a1-14.mi.infn.it:  0x5EA1A5D0 waiting 0.294530000 seconds, NSD I/O Worker: for I/O completion on disk dm-25

suddivisione dati/metadati

Nei casi di grossi storage, si consiglia sempre di dedicare dei dischi all'uso esclusivo dei metadati e altri ai soli dati.
In questo modo mmdf darà la quota parte precisa di ciascuna tipologia, e sarà possibile anche replicare i soli metadati o costituire storage-pools distinti.
La perdita di un nsd inoltre potrebbe in questo caso non influire sulla stabilità del sistema, in quanto gpfs potrà perlomeno ricostruire la struttura del file, o indicare con esattezza quali errori ci sono e su quali files. Ci sono anche miglioramenti nelle prestazioni durante l'accesso ai files, in quanto si restringe il range di ricerca per i metadati (gli inodes per esempio) ad un numero limitato di dischi fisici.
E' possibile cambiare l'attribuzione degli nsd a caldo su uno o più dischi. Per esempio, si decide di cambiare l'architettura dei dischi da dataAndMetadata a usage distinti, dataOnly e metadataOnly:

      mmchdisk storage_2 change -d "c13:::dataOnly"
      mmrestripefs storage_2 -b -N <node1>,<node2>,...,<nodeN>

Le due operazioni sono indipendenti, il restripe può anche essere rimandato, fermo restando però che i metadati vecchi non verranno ridistribuiti automaticamente.
Quelli relativi a nuove scritture invece saranno d'ora in avanti deviati su altri dischi.

Documenti

diagramma sito

presentazione