====== GPFS (General Parallel File System) ======

===== Généralités =====

  * http://fr.wikipedia.org/wiki/GPFS

Version GPFS couvertes par cette documentation :
  * 3.2.1-2
  * 3.3

===== Documentation =====

  * Documentations officielles IBM : http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs31.advanceadm.doc%2Fbl1adv_chnamip.html

===== Scénario =====

Matériel.
  * 4 serveurs et 4 clients.
  * 4 serveurs dont 1 serveur principal et 1 serveur secondaire GPFS qui sont tous quorum, et 4 postes membres du cluster sans être quorum (mais cela pourrait et serait conseillé).

Les serveurs ont accès aux volumes en accès SAN alors que les postes accèdent aux volumes via le réseau ethernet.

Toutes les étapes suivantes nécessite d'être root sur les machines et décrivent dans l'ordre la création d'un cluster complet.

===== Mise en place des clés SSH =====

Le bon fonctionnement du cluster GPFS repose sur les communications SSH en clés privées / clés publiques en root. Il faut donc générer déployer les clés SSH de la manière suivante.

==== Tableau disposition clés SSH ====

FIXME tableau disposition clés SSH

  * Serveur principal : clés publiques de toutes les machines du cluster y compris du serveur secondaire et de lui-même dans son ~/.ssh/authorized_keys.
  * Serveur secondaire : clés publiques de toutes les machines du cluster y compris du serveur principal et de lui-même dans son ~/.ssh/authorized_keys.
  * autres noeuds du cluster : clés publiques uniquement du serveur principal et secondaire dans les ~/.ssh/authorized_keys.

==== Générer le couple clé publique/clé privée SSH ====

<code>
ssh-keygen -t rsa -b 4096
</code>

<code>
Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.
</code>

Ne pas entrer de passphrase parce que les connexions doivent être directes entre les machines du cluster.

Les clés privées/publiques sur chaque lame sont stockées dans ''/root/.ssh/'' dans les fichiers suivants.

  * id_rsa pour la clé privée.
  * id_rsa.pub pour la clé publique.

Vérifier et éventuellement positionner les droits 600 pour la clé privée et 644 pour la clé publique.

<code>
chmod 600 /root/.ssh/id_rsa
chmod 644 /root/.ssh/id_rsa.pub
</code>

Copier ensuite le contenu des fichiers ''/root/.ssh/id_rsa.pub'' de chaque lame dans le fichier ''/root/.ssh/authorized_keys'' des machines correspondant aux serveurs primaire et secondaire et valider la connexion ssh.

Sur toutes les machines autres que le serveur principal et secondaire.

<code>
ssh-copy-id -i /root/.ssh/id_rsa.pub root@srvprincipal.domaine.fr

ssh-copy-id -i /root/.ssh/id_rsa.pub root@srvsecondaire.domaine.fr

ssh root@srvprincipal.domaine.fr (Répondre yes sur la question éventuelle, une fois la connexion réussie, faite "Ctrl + D" pour se déconnecter).

ssh root@srvsecondaire.domaine.fr (Répondre yes sur la question éventuelle, une fois la connexion réussie, faite "Ctrl + D" pour se déconnecter).
</code>

Copier le contenu des fichiers ''/root/.ssh/id_rsa.pub'' des serveurs primaire et secondaire dans le fichier ''/root/.ssh/authorized_keys'' des machines correspondantes aux autres serveurs faisant parti du cluster GPFS et sur lui-même.

Depuis le serveur primaire du cluster GPFS (srvprincipal).
<code>
ssh-copy-id -i /root/.ssh/id_rsa.pub root@<machines>.domaine.fr
ssh-copy-id -i /root/.ssh/id_rsa.pub root@srvsecondaire.domaine.fr
ssh-copy-id -i /root/.ssh/id_rsa.pub root@srvprincipal.domaine.fr
</code>

Depuis le serveur secondaire du cluster GPFS (srvsecondaire).
<code>
ssh-copy-id -i /root/.ssh/id_rsa.pub root@<machines>.domaine.fr
ssh-copy-id -i /root/.ssh/id_rsa.pub root@srvprincipal.domaine.fr
ssh-copy-id -i /root/.ssh/id_rsa.pub root@srvsecondaire.domaine.fr
</code>

===== Création du cluster GPFS =====

Maintenant que les clés publiques sont partagées, le cluster GPFS peut être créé.

Attention : vérifier au préalable que le nom de la machine (sur les machines du cluster) n'est pas déclaré dans le fichier ''/etc/hosts'' sur la ligne localhost, sinon enlever le nom du fichier.
Il est nécessaire à cette étape que les nodes à intégrer au cluster soient accessible par leurs noms DNS.

Sur le serveur primaire (srvprincipal), créer un fichier décrivant le cluster comme suit.
<code>
vi  /tmp/nodes.txt
</code>

<code>
srvprincipal.domaine.fr:quorum

srv3.domaine.fr:quorum

srvsecoondaire.domaine.fr:quorum

srv4.domaine.fr:quorum
</code>

Remarque sur le mode quorum et manager.

Type possible : quorum, quorum manager, manager

  * Le quorum maintien le cluster actif. Pour qu'il le reste il faut que la moitié + 1 des machines quorum soit active sinon le cluster s'arrête.
  * Une machine quorum participe au bon fonctionnement du cluster.
  * Une machine manager supporte le fonctionnement d'un nsd (= un volume qui est supporté par un couple de noeud ou machines).
  * Une machine peut être les deux (quorum-manager).

Créer le cluster GPFS via la commande suivante.
<code>
mmcrcluster -N /tmp/nodes.txt -p srvprincipal.domaine.fr -s srvsecondaire.domaine.fr -C "CLUSTER_PROD" -A -r /usr/bin/ssh -R /usr/bin/scp
</code>

Une fois le cluster créé, vérifier sa bonne création via la commande suivante.
<code>
mmlscluster
</code>

<code>
GPFS cluster information

========================

  GPFS cluster name:         CLUSTER_PROD.domaine.fr

  GPFS cluster id:           13882477815451679276

  GPFS UID domain:           CLUSTER_PROD.domaine.fr

  Remote shell command:      /usr/bin/ssh

  Remote file copy command:  /usr/bin/scp



GPFS cluster configuration servers:

-----------------------------------

  Primary server:    srvprincipal.domaine.fr

  Secondary server:  srvsecondaire.domaine.fr



 Node  Daemon node name            IP address       Admin node name             Designation

-----------------------------------------------------------------------------------------------

      1   srvprincipal.domaine.fr         192.168.0.1    srvprincipal.domaine.fr          quorum

      2   srv3.domaine.fr         192.168.0.3    srv3.domaine.fr                 quorum

      3   srvsecondaire.domaine.fr         192.168.0.2   srvsecondaire.domaine.fr                 quorum

      4   srv4.domaine.fr         192.168.0.4   srv4.domaine.fr
</code>

Démarrer le cluster via la commande.
<code>
mmstartup -a
</code>

<code>
mmstartup: Starting GPFS ...
</code>

Vérifier sur toutes les lames que GPFS tourne bien.
<code>
ps aux | grep gpfs
</code>

<code>
root     18353     1  0 06:36 ?        00:00:00 [gpfsSwapdKproc]
</code>

Sur le serveur principal, vérifier l'état de tous les nodes du cluster via la commande suivante.
<code>
mmgetstate -a -L
</code>

===== Création d'un nsd =====

Il faut maintenant créer et ajouter le volume à partager en GPFS. Sur le serveur primaire du cluster GPFS (srvprincipal), créer le disque correspondant au disque GPFS (LUN=2 sur le SAN qui correspond à /dev/sdd sur la machine) en suivant la procédure ci-dessous.

Créer le fichier ''/tmp/nsd.txt'' et ajouter la ligne suivante.
<code>
vi /tmp/nsd.txt
</code>

<code>
/dev/sdd:srvprincipal.domaine.fr:srvsecondaire.domaine.fr:dataAndMetadata:-1:data_work
</code>

Créer et ajouter le disque GPFS via la commande.
<code>
mmcrnsd -F /tmp/nsd.txt -v no
</code>

<code>
mmcrnsd: Processing disk sdd

mmcrnsd: Propagating the cluster configuration data to all affected nodes. This is an asynchronous process.
</code>

Vérifier la bonne création du disque GPFS.
<code>
mmlsnsd
</code>

<code>
File system   Disk name    NSD servers

---------------------------------------------------------------------------

(free disk)   data_work  srvprincipal.domaine.fr,srvsecondaire.domaine.fr
</code>

===== Ajout éventuel d'un tiebreaker disk =====

Le tiebreaker disk permet de s'affranchir de la limite du (nb node/2)+1 quorum en fonctionnement qui doit fonctionner pour faire tourner le cluster. Dans le cas d'un cluster GPFS qui est fonctionnel avec uniquement un serveur GPFS principal et un secondaire, seul deux nodes quorum maintiennent le cluster.
Si on redémarre un des serveurs le cluster tombe. Pour éviter ce phénomène, on peut utiliser un tiebreaker disk qui permet de faire fonctionner le cluster avec un seul node quorum actif. Le tiebreaker se chargeant de maintenir le cluster avec le second node encore actif.

Pour ajouter un tiebreaker disk sur trois nsd (le maximum).
<code>
# mmchconfig tiebreakerdisks="nsd01;nsd02;nsd03"
Verifying GPFS is stopped on all nodes ...
mmchconfig: Command successfully completed
mmchconfig: Propagating the cluster configuration data to all affected nodes.  This is an asynchronous process.
</code>

Dans le schéma qui suit, GPFS reste actif avec le minimum de node quorum actif et deux tiebreaker disks disponibles.

{{:gpfs:gpfs_tiebreaker.gif|}}

===== Création du FileSystem GPFS =====

Maintenant que le disque GPFS est créé et partagé, il faut créer le filesystem correspondant.

Dupliquer le fichier ''/tmp/nsd.txt'' et renommer le fichier dupliqué en ''/tmp/fs.txt''.
<code>
cat /tmp/nsd.txt > /tmp/fs.txt
</code>

Créer le filesystem via la commande.
<code>
mmcrfs /dev/data_work -F /tmp/fs.txt -A yes -T /data_work -v no
</code>

<code>
The following disks of data_work will be formatted on node srvprincipal.domaine.fr:

data_work: size 52428800 KB

Formatting file system ...

Disks up to size 111 GB can be added to storage pool 'system'.

Creating Inode File

Creating Allocation Maps

Clearing Inode Allocation Map

Clearing Block Allocation Map

Formatting Allocation Map for storage pool 'system'

Completed creation of file system /dev/data_work.

mmcrfs: Propagating the cluster configuration data to all

 affected nodes.  This is an asynchronous process.
</code>

Vérifier la bonne création du filesystem GPFS ''data_work''.
<code>
mmlsfs /dev/data_work
</code>

<code>
flag value            description

---- ---------------- -----------------------------------------------------

 -f  8192             Minimum fragment size in bytes

 -i  512              Inode size in bytes

 -I  16384            Indirect block size in bytes

 -m  1                Default number of metadata replicas

 -M  2                Maximum number of metadata replicas

 -r  1                Default number of data replicas

 -R  2                Maximum number of data replicas

 -j  cluster          Block allocation type

 -D  nfs4             File locking semantics in effect

 -k  all              ACL semantics in effect

 -a  1048576          Estimated average file size

 -n  32               Estimated number of nodes that will mount file system

 -B  262144           Block size

 -Q  none             Quotas enforced

     none             Default quotas enabled

 -F  51712            Maximum number of inodes

 -V  10.00 (3.2.0.0)  File system version

 -u  yes              Support for large LUNs?

 -z  no               Is DMAPI enabled?

 -L  4194304          Logfile size

 -E  yes              Exact mtime mount option

 -S  no               Suppress atime mount option

 -K  whenpossible     Strict replica allocation option

 -P  system           Disk storage pools in file system

 -d  data_work    Disks in file system

 -A  yes              Automatic mount option

 -o  none             Additional mount options

 -T  /data_work     Default mount point
</code>

Vérifier que le fichier ''/etc/fstab'' contient bien la ligne suivante.
<code>
cat /etc/fstab
</code>

<code>
[...]

/dev/data_work     /data_work         gpfs rw,mtime,atime,dev=data_work,autostart 0 0

[...]
</code>

Sur le serveur primaire du cluster, effectuer le montage GPFS sur la totalité du cluster.
<code>
mmmount all -a
</code>

Vérifier que le montage GPFS est bien monté sur chaque machine.
<code>
mount
</code>

<code>
/dev/data_work on /data_work type gpfs (rw,mtime,dev=data_work,autostart)
</code>

Sur le serveur primaire du cluster GPFS (srvprincipal), définir la plage de port de communication TCP.

<code>
mmchconfig  tscCmdPortRange="35000-35200"
</code>

Vérifier que la plage de port TCP a bien été prise en compte sur chaque lame faisant parti du cluster GPFS
<code>
mmlsconfig
</code>

<code>
tscCmdPortRange  35000-35200
</code>

Afin de prendre en compte de façon effective la plage de port TCP défini ci-dessus, arrêter et redémarrer le cluster GPFS sur le serveur primaire (srvprincipal)
<code>
mmshutdown -a
mmstartup -a
</code>

===== Log cluster =====

Le fichier de log du cluster se trouve dans le fichier suivant. C'est un lien symbolique qui pointe vers le dernier log.
<code>
/var/adm/ras/mmfs.log.latest
</code>

===== Ajout machines au cluster =====

Prenons le cas d'un poste qu'on veut ajouter au cluster GPFS créé préalablement afin qu'il accède au volume data_work.

==== Générer le couple clé publique/clé privée SSH ====

Se connecter en root sur le poste.
Générer les couples clé privées/publiques SSH via la commande.
<code>
ssh-keygen -b 4096 -q -t rsa
</code>

<code>
Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.
</code>

Ne pas entrer de passphrase car les machines du cluster GPFS doivent pouvoir communiquer directement.

Vérifier et éventuellement positionner les droits 600 pour la clé privée et 644 pour la clé publique.
<code>
chmod 600 /root/.ssh/id_rsa
chmod 644 /root/.ssh/id_rsa.pub
</code>

Copier ensuite le contenu du fichier ''/root/.ssh/id_rsa.pub'' du poste dans le fichier ''/root/.ssh/authorized_keys'' des serveurs principal et secondaire GPFS (srvprincipal et srvsecondaire) et valider la connexion ssh.

Sur le poste opérateur.
<code>
ssh-copy-id -i /root/.ssh/id_rsa.pub root@srvprincipal.domaine.fr

ssh-copy-id -i /root/.ssh/id_rsa.pub root@srvsecondaire.domaine.fr

ssh root@srvprincipal.domaine.fr (répondre yes sur la question éventuelle).

ssh root@srvsecondaire.domaine.fr (Une fois la connexion réussie, faite "Ctrl + D"  pour vous déconnecter).
</code>

Copier le contenu des fichiers ''/root/.ssh/id_rsa.pub'' des serveurs principal et secondaire dans le fichier ''/root/.ssh/authorized_keys'' du poste opérateur.

Depuis le serveur primaire du cluster GPFS (srvprincipal).
<code>
ssh-copy-id -i /root/.ssh/id_rsa.pub root@<nom_poste>.domaine.fr
</code>

Depuis le serveur secondaire du cluster GPFS (srvsecondaire).
<code>
ssh-copy-id -i /root/.ssh/id_rsa.pub root@<nom_poste>.domaine.fr
</code>

==== Intégration au cluster ====

Se connecter sur le serveur primaire du cluster GPFS (srvprincipal) en root.

Intégrer le poste opérateur au sein du cluster GPFS.
<code>
mmaddnode <nom_machine>.domaine.fr
</code>

Vérifier la bonne intégration du poste opérateur.
<code>
mmlsnode
</code>

<code>
Renvoie CLUSTER_PROD avec le nouveau ajouté en fin de liste.
</code>

==== Montage du volume ====

Sur le poste opérateur, vérifier le contenu du fichier ''/etc/fstab''.
<code>
cat /etc/fstab
</code>

Le montage ''/dev/data_work'' doit apparaître en fin de fichier.
<code>
[...]

/dev/data_work     /data_work         gpfs    rw,mtime,atime,dev=data_work,autostart 0 0

[...]
</code>

Sur le poste opérateur, démarrer GPFS et vérifier son bon démarrage.
<code>
mmstartup
</code>

<code>
ps -aef | grep  gpfs
</code>

<code>
root     3674     1  0 12:05 ?        00:00:00 [gpfsSwapdKproc]
</code>

Sur le poste opérateur, monter le filesystem.
<code>
mmmount all
</code>

Vérifier le bon montage du filesystem ''/dev/data_work''.
<code>
mount
</code>

Sur le poste opérateur, paramétrer le démarrage de GPFS au boot de la machine.
<code>
chkconfig gpfs on
chkconfig --list gpfs
</code>

Sur le poste opérateur, vérifier dans la configuration GPFS l'option ''autoload''.
<code>
mmlsconfig  ----> l'option "autoload" doit être égale à "yes".
</code>

===== Ignorer le montage d'un volume pour certaines machines =====

Il est possible de sélectionner les volumes qui doivent être montés en fonction de la machine. Il arrive des cas où l'on ne souhaite pas monter certains volumes sur certaines machines qui font parties d'un même cluster et qui ont donc accès à de nombreux volumes.

Pour cela, se rendre sur chaque machine où l'on souhaite restreindre les montages et configurer les volumes (qui sont alloués à toutes les machines du cluster par défaut) pour qu'ils ne soient pas montés automatiquement.

La simple présence d'un fichier (vide)avec la bonne syntaxe pour chaque volume suffit à désactiver au démarrage le volume nommé.
<code>
/var/mmfs/etc/ignoreStartupMount.<nom_volume> 
</code>

Éventuellement ajouter dans le fichier un commentaire de la fonction du fichier.
<code>
Disable automount for <nom_volume>
</code>

===== Suppression d'un node (machine HS) =====

FIXME cette méthode est soumise à caution et n'a pas été testée par mes soins.

S'assurer que la machine n'est plus sur le réseau (plus joignable), et qu'elle n'est pas quorum, ni manager de volumes.

Sur le serveur principal GPFS, supprimer le node.
<code>
mmdelnode -N <nom_du_serveur>
</code>

Une méthode pas des plus propre mais fonctionnelle permet de supprimer un node même lorsque la commande mmdelnode ne fonctionne pas.

Il faut supprimer le node en question du fichier ''/var/mmfs/gen/mmsdrfs'' sur le serveur principal et certainement redémarrer le cluster GPFS. Attention, action à réaliser avec prudence.

Après une réinstallation du poste, supprimer les anciennes clés SSH dans authorized_keys et le contenu des fichiers known_hosts qui concernent la machine défaillante, puis rejouer la création et le positionnement d'une nouvelle clé générée.

===== Suppression d'un NSD et d'un Filesystem =====

Ce paragraphe a été créé lors de la nécessité d'intervertir deux volumes SAN utilisés par deux nsd GPFS. Lors de la création une invertion a été opéré. Les tailles des volumes n'était pas bonnes.

Arrêter les services qui se servent des volumes GPFS sur les machines en question.

Sauvegarder l'existant.
<code>
mmlsfs all >> ./save_fs.txt

mmlsnsd >> ./save_fs.txt
</code>

Sur le serveur principal GPFS.
<code>
mmumount all -N all
</code>

Vérifier sur chaque noeud que cela est bien démonté avec la commande ''mount''.
<code>
mmdelfs /dev/DATA

mmdelfs /dev/WSreq
</code>

<code>
mmdelnsd DATA

mmdelnsd WSreq
</code>

Créer un fichier de création des nsd correspondant à ce qu'on veut obtenir.
<code>
vi DATA.nsd

/dev/sdc:<nom_noeud1_fqdn>:<nom_noeud2_fqdn>:dataAndMetadata:-1:DATA
</code>

Remarque. Mettre autant de noeud (machine) qu'on souhaite si elles ont besoin d'avoir accès au volume.

Création du nsd.

<code>
mmcrnsd -F DATA.nsd
</code>

Création du filesystem GPFS DATA sur trois noeuds (machine).
<code>
mmcrfs /DATA /dev/DATA -F DATA.nsd -n 3 -A yes
</code>

Pour changer le point de montage en /DONNEES.
<code>
mmchfs /dev/DATA /DONNEES
</code>

Remonter le volume sur le cluster.
<code>
mmmount all
</code>

===== Cas particulier de réinstallation ou migration d'un serveur =====

Lors de la réinstallation ou de la migration d'un serveur (ex : passer de la RHEL4 à la RHEL5 sans "casser" le cluster GPFS et les données des NSD), son intégration dans GPFS doit être refaite. Or il est connu du cluster et existe dans un ou plusieurs NSD.

Il doit sortir des NSD dont il est le serveur primaire ou backup. Puis il doit sortir du cluster.

Enfin on réintègre dans le cluster et on modifie les NSD dont il doit être le serveur primaire ou backup.

==== Sortir un serveur d'un NSD ====

Démonter de tous les serveurs le NSD.
<code>
mmumount DATA -a

où DATA est le nom du NSD concerné.
</code>

Modifier le fichier ''desc_file.NSD'' pour remplacer le "nom du serveur" par un autre serveur (s'il est primaire) ou le retirer (s'il est backup).

Lancer la commande pour modifier la configuration du NSD.

<code>
mmchnsd -F desc_file.nsd
</code>

Vérifier la bonne prise en compte.
<code>
mmlsnsd
</code>

Arreter GPFS sur tous les serveurs du cluster. Se positionner pour cela sur le serveur de cluster.
<code>
mmshutdown -a
</code>

==== Sortir le "nom du serveur" du cluster ====

Pour empêcher la communication entre le serveur de cluster et le "nom du serveur" que l'on souhaite installer, il faut arrêter les services réseau sur le "nom du serveur" à installer.
<code>
/etc/init.d/network stop
</code>

==== Sortir "nom du serveur" du quorum ====

Si le "nom du serveur" fait partie du quorum, il faut le sortir du quorum. Se positionner pour cela sur le serveur de cluster.

<code>
mmchconfig designation=nonquorum <nom_du_serveur>
</code>

===== Suppression d'un node (machine toujours online) =====

==== Règles à suivre pour la suppression d'un node ====

  * Un node a supprimer ne peut pas être le serveur principal ou secondaire GPFS à moins qu'on supprime le cluster en entier. Vérfifier au préalable avec la commande ''mmlscluster''. Dans le cas où le node à supprimer est l'un des ces serveurs et qu'on veut conserver le cluster, il faut assigner un autre node en tant que principal ou secondaire à l'aide de la commande ''mmchcluster'' avant de supprimer le node.

  * Un node à supprimer ne peut pas être un serveur primaire ou backup NSD pour un quelquconque volume du cluster GPFS à moins qu'on souhaite supprimer le cluster. Vérifier que ce n'est pas le cas avec la commande ''mmlsnsd''. Dans le cas où le node à supprimer est primaire ou backup NSD pour un ou plusieurs volumes, déplacer les volumes sur un autre node du cluster à l'aide de la commande ''mmchnsd'' avant de supprimer le node.

  * GPFS doit être arrêté sur le node qui doit être supprimé. Utiliser la commande ''mmshutdown'' pour cette opération.

==== Suppression du node ====

<code>
mmdelnode -N <nom_du_serveur>
</code>

==== Rentrer le "nom du serveur" dans le cluster ====

Réactiver la communication entre le serveur de cluster et le "nom du serveur" que l'on souhaite installer.

<code>
/etc/init.d/network start
</code>

Si le "nom du serveur" fait partie du quorum, le repositionner en tant que tel.

<code>
mmaddnode -N <nom_du_serveur> :quorum:
</code>

Sinon
<code>
mmaddnode -N <nom_du_serveur> ::
</code>

==== Ajouter de nouveau le NSD au node ====

Modification de la structure du NSD pour intégrer "nom du serveur". Pour cela modifier le fichier desc_file.NSD pour rajouter le "nom du serveur" et appliquer le fichier avec la commande qui suit.

<code>
mmchnsd -F desc_file.NSD
</code>

Vérifier la bonne prise en compte.
<code>
mmlsnsd
</code>

Relancer GPFS.
<code>
mmstartup -a
</code>

===== Changer IP d'un node =====

  * Méthode pour GPFS 3.3 extraite de la doc IBM suivante : http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs31.advanceadm.doc%2Fbl1adv_chnamip.html

GPFS assumes that IP addresses and host names remain constant. In the rare event that such a change becomes necessary or is inadvertently introduced by reinstalling a node with a disk image from a different node for example, follow the steps in this topic.

If all of the nodes in the cluster are affected and all the conditions in step 2 below are met:

  - Use the mmshutdown -a command to stop GPFS on all nodes.
  - Using the documented procedures for the operating system, add the new host names or IP addressees, but do not remove the old ones yet. This can be achieved, for example, by creating temporary alias entries in /etc/hosts. Avoid rebooting the nodes until the mmchnode command in step 3 is executed successfully. If any of these conditions cannot be met, utilize the alternate procedure described below.
  - Use mmchnode --daemon-interface and --admin-interface to update the GPFS configuration information.
  - If the IP addresses over which the subnet attribute is defined are changed, you need to update your configuration by using the mmchconfig command with the subnets attribute.
  - Start GPFS on all nodes with mmstartup -a.
  - Remove the unneeded old host names and IP addresses.

If only a subset of the nodes are affected, it may be easier to make the changes using these steps:

  - Before any of the host names or IP addresses are changed:
    * Use the mmshutdown command to stop GPFS on all affected nodes.
    * If the host names or IP addresses of the primary or secondary GPFS cluster configuration server nodes must change, use the mmchcluster command to specify another node to serve as the primary or secondary GPFS cluster configuration server.
    * If the host names or IP addresses of an NSD server node must change, temporarily remove the node from being a server with the mmchnsd command. Then, after the node has been added back to the cluster, use the mmchnsd command to change the NSDs to their original configuration. Use the mmlsnsd command to obtain the NSD server node names.
    * Use the mmdelnode command to delete all affected nodes from the GPFS cluster.
  - Change the node names and IP addresses using the documented procedures for the operating system.
  - If the IP addresses over which the subnet attribute is defined are changed, you need to update your configuration by using the mmchconfig command with the subnets attribute.
  - Issue the mmaddnode command to restore the nodes to the GPFS cluster.
  - If necessary, use the mmchcluster and mmchnsd commands to restore the original configuration and the NSD servers.

===== Configuration d'un cluster GPFS de grande taille =====

<code>
mmchconfig tscCmdPortRange=35000-35200,maxFilesToCache=10000, pagepool=1G,maxMBpS=1600,prefetchThreads=200,worker1Threads=200
</code>

Pour chaque poste opérateur.
<code>
mmchconfig pagepool=256M -N <nom_poste>
</code>

Attribuer le rôle "manager" à chaque machine.
<code>
mmchnode -N <liste des machines séparées par des virgules> --manager
</code>

==== NSD sur un couple de node manager ====

Par défaut les nsd sont gérés par le quorum mais on peut ajouter des managers qui auront cette tâche de gestion des volumes. De manière précise chaque volume est associé à un couple de deux machines manager, l'une primaire et l'autre backup.

Creation d'un nsd composé de deux volumes SAN physiques attachés.

Commande pour afficher les noms des devices locaux par rapport aux LUN attachées.
<code>
/opt/mpp/lsvdev
</code>

La commande précédente est utile pour récupérer les noms des devices locaux (''/dev/sdao'' par exemple) qui correspondent aux numéros des LUN SAN attachées.

Après avoir attaché les deux volumes SAN, aux machines, noter les noms des devices sur la machines, ils sont utiles pour les commandes qui suivent.

Pour le filesystem ''/data/save''.
<code>
vi save1.nsd
</code>

<code>
/dev/sdao:srv3.domaine.fr:srv4.domaine.fr:dataAndMetadata:-1:data_save_1
</code>

<code>
mmcrnsd -F ./save1.nsd -v no
</code>

<code>
vi save2.nsd
</code>

<code>
/dev/sdap:srv4.domaine.fr:srv3.domaine.fr:dataAndMetadata:-1:data_save_2
</code>

<code>
mmcrnsd -F ./save1.nsd -v no
</code>

<code>
vi save.fs
</code>

<code>
/dev/sdao:srv3.domaine.fr:srv4.domaine.fr:dataAndMetadata:-1:data_save_1
/dev/sdap:srv4.domaine.fr:srv3.domaine.fr:dataAndMetadata:-1:data_save_2
</code>

<code>
mmcrfs /dev/save -F save.fs -T /data/save -B 1M -A yes
</code>

Les couples de serveurs primaires et backups choisis doivent être réparti de façon équitable pour gérer les multiples filesystems.

==== NSD composé de 10 volumes physiques ====

En prenant exemple d'un volume GPFS composé de 10 volumes physiques SAN. Ils constitueront un seul volume GPFS.

Les machines srv3.domaine.fr et srv4.domaine.fr doivent être manager.

==== Creation du nsd ''/data/archive'' ====

<code>
cat > /tmp/gpfs/data_archive.nsd <<EOF

/dev/sdt:srv3.domaine.fr:srv4.domaine.fr:dataOnly::data_archive_1:bigdata

/dev/sdu:srv4.domaine.fr:srv3.domaine.fr:dataOnly::data_archive_2:bigdata

/dev/sdv:srv3.domaine.fr:srv4.domaine.fr:dataOnly::data_archive_3:bigdata

/dev/sdw:srv4.domaine.fr:srv3.domaine.fr:dataOnly::data_archive_4:bigdata

/dev/sdx:srv3.domaine.fr:srv4.domaine.fr:dataOnly::data_archive_5:bigdata

/dev/sdy:srv4.domaine.fr:srv3.domaine.fr:dataOnly::data_archive_6:bigdata

/dev/sdak:srv3.domaine.fr:srv4.domaine.fr:dataAndMetadata::data_archive_metadata1:

/dev/sdal:srv4.domaine.fr:srv3.domaine.fr:dataAndMetadata::data_archive_metadata2:

/dev/sdam:srv3.domaine.fr:srv4.domaine.fr:dataAndMetadata::data_archive_smallfiles1:

/dev/sdan:srv4.domaine.fr:srv3.domaine.fr:dataAndMetadata::data_archive_smallfiles2:

EOF
</code>

Les couples de serveurs primaires et backups choisis doivent être réparti de façon équitable pour gérer les multiples filesystems.

Créer le nsd composé des multiples volumes.
<code>
mmcrnsd -F /tmp/gpfs/data_archive.nsd
</code>

==== Création du filesystem ====

<code>
mmcrfs /dev/data_archive -F data_archive.nsd -T /data/archive -B 1M -n 100 -S yes
</code>

==== Création d'une policy pour le filesystem ====

<code>
cat > /tmp/gpfs/data_archive.policy <<EOF
</code>

/* stockage de petits fichiers sur storage pool "system" */
<code>
RULE 'CfgFiles' SET POOL 'system'

  WHERE NAME LIKE '%xml' OR NAME LIKE '%XML' OR NAME LIKE '%lock'

/* stockage fichiers METEO sur storage pool "system" */

RULE 'MeteoFiles' SET POOL 'system'

  FOR FILESET('METEO')

/* Autres fichiers sous "bigdata" */

RULE 'default' SET POOL 'bigdata'

EOF
</code>

<code>
mmchpolicy data_archive /tmp/gpfs/data_archive.policy -I yes
</code>

Création d'un fileset pour METEO.
<code>
mmcrfileset data_archive METEO
</code>

==== Augmentation nombre d'inodes ====

FIXME à compléter.
  * http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.doc%2Fgpfs_faqs%2Fgpfs_faqs.html
  * http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.v3r4.gpfs100.doc%2Fbl1ins_maxnfle.html&resultof=%22maximum%22%20%22inode%22%20%22inod%22
  * http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.v3r4.gpfs300.doc%2Fbl1adm_mmchfs.html&resultof=%22mmchfs%22%20%22mmchf%22%20%22-F%22%20%22f%22
  * http://fr.wikipedia.org/wiki/Inode

What is the architectural limit of the number of files in a file system? 
<code>
    The architectural limit of the number of files in a file system is determined by the file system format:

        For file system created with GPFS V3.4 or later, the architectural limit is 264.

        The current tested limit is 9,000,000,000.
        For file systems created with GPFS V2.3 or later, the limit is 2,147,483,648.
        For file systems created prior to GPFS V2.3, the limit is 268,435,456.

    Please note that the effective limit on the number of files in a file system is usually lower than the architectural limit, and could be adjusted using the mmchfs command (GPFS V3.4 and later use the --inode-limit option; GPFS V3.3 and lower use the -F option).
</code>

Méthode de calcul et modification avec mmchfs (extrait du man).
<code>
--inode-limit MaxNumInodes[:NumInodesToPreallocate]
    MaxNumInodes specifies the maximum number of files that can be created. Allowable values range from the current number of created inodes (determined by issuing the mmdf command with -F), through the maximum number of files possibly supported as constrained by the formula:

    maximum number of files = (total file system space) / (inode size + subblock size)

[You can determine the inode size (-i) and subblock size (value of the -B parameter / 32) of a file system by running the mmlsfs command.]

    If your file system has additional disks added or the number of inodes was insufficiently sized at file system creation, you can change the number of inodes and hence the maximum number of files that can be created.

    For file systems that will be doing parallel file creates, if the total number of free inodes is not greater than 5% of the total number of inodes, there is the potential for slowdown in file system access. Take this into consideration when changing your file system.

    NumInodesToPreallocate specifies the number of inodes that will be pre-allocated by the system right away. If this number is not specified, GPFS allocates inodes dynamically as needed.

    The MaxNumInodes and NumInodesToPreallocate values can be specified with a suffix, for example 100K or 2M. Note that in order to optimize file system operations, the number of inodes that are actually created may be greater than the specified value.

    This option applies only to the root fileset. When there are multiple inode spaces, use the --inode-space option of the mmchfileset command to alter the inode limits of independent filesets. The mmchfileset command can also be used to modify the root inode space. The --inode-space option of the mmlsfs command shows the sum of all inode spaces.
</code>

<code>
400Go
inode size : 512 bytes
Block size 524288
Maximum number of inode (actual value) : 100352
</code>

Calcul avec 400Go.
<code>
429496729600 / 512 + (524288 / 32) 
429496729600 / 16 896 = 25 420 024
</code>

Calcul avec 100Go.
<code>
107374182400 / 512 + (524288 /32)
107374182400 / 16 896 = 6 355 006
</code>

Changement de la valeur max inode. Cette commande fonctionne directement à chaud sans redémarrage.
<code>
mmchfs <filesystem_name ex: /dev/gpfs_data> -F <value>
</code>


===== Troobleshooting =====

Regarder log.
<code>
/var/adm/ras/mmfs.log.latest
</code>

<code>
gpfs.snap
mmfsadm
mmtracectl
</code>

==== mmfsck ====

  * http://blog.irwan.name/?p=2258
  * http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic=%2Fcom.ibm.cluster.gpfs.v3r50-3.gpfs100.doc%2Fbl1adm_mmfsck.htm


Check filesystem GPFS sur /dev/<volname>
Sur le serveur GPFS.
<code>
mmumount -a </dev/<device_name>
</code>

Si blocage du démontage car utilisé se rendre sur les machines qui utilisent le volume et entrer les commandes suivantes.
<code>
fuser -mv /<mount_point>
fuser -mkv /<mount_point>
Refaire le mmumount -a sur le serveur GPFS.
</code>

Sur le serveur GPFS.
<code>
mmumount /dev/gpfs_<volname> -a
mount
mmfsck /dev/gpfs_<volname> -v -n > mmfsck_check.out 2>&1
vi mmfsck_mpf_check.out
mmfsck /dev/gpfs_<volname> -v -y > mmfsck_fix.out 2>&1
vi mmfsck_mpf_fix.out
mmfsck /dev/gpfs_<volname> -v -y > mmfsck_fix2.out 2>&1
vi mmfsck_mpf_fix2.out
mount
mmmount /dev/gpfs_uc_mpf -a
</code>