RHCS: GFS2 dans un cluster A / A avec stockage commun. Configuration de GFS avec rgmanager

Je configure un cluster A / A à deux noeuds avec un stockage commun attaché via iSCSI, qui utilise GFS2 sur le LVM en cluster. Jusqu'à présent, j'ai préparé une configuration simple, mais je ne sais pas quel est le bon moyen de configurer la ressource gfs.

Voici la section rm de /etc/cluster/cluster.conf:

<rm> <failoverdomains> <failoverdomain name="node1" nofailback="0" ordered="0" ressortingcted="1"> <failoverdomainnode name="rhc-n1"/> </failoverdomain> <failoverdomain name="node2" nofailback="0" ordered="0" ressortingcted="1"> <failoverdomainnode name="rhc-n2"/> </failoverdomain> </failoverdomains> <resources> <script file="/etc/init.d/clvm" name="clvmd"/> <clusterfs name="gfs" fstype="gfs2" mountpoint="/mnt/gfs" device="/dev/vg-cs/lv-gfs"/> </resources> <service name="shared-storage-inst1" autostart="0" domain="node1" exclusive="0" recovery="restart"> <script ref="clvmd"> <clusterfs ref="gfs"/> </script> </service> <service name="shared-storage-inst2" autostart="0" domain="node2" exclusive="0" recovery="restart"> <script ref="clvmd"> <clusterfs ref="gfs"/> </script> </service> </rm> 

C'est ce que je veux dire: lors de l'utilisation de l'agent de ressources clusterfs pour gérer la partition GFS, il n'est pas dégressif par défaut (sauf si l'option force_unmount est donnée). De cette façon, lorsque je cause

clusvcadm -s shared-storage-inst1

clvm est arrêté, mais GFS n'est pas démonté, donc un nœud ne peut plus modifier la structure LVM sur le stockage partagé, mais peut toujours accéder aux données. Et même si un nœud peut le faire assez en toute security (dlm fonctionne toujours), cela semble plutôt inapproprié pour moi, car clustat signale que le service sur un nœud particulier est arrêté. De plus, si je tente plus tard de cman sur ce noeud, il finda un verrou dlm, produit par GFS, et ne parviendra pas à arrêter.

J'aurais simplement ajouté force_unmount = "1", mais j'aimerais savoir quelle est la raison du comportement par défaut. Pourquoi n'est-il pas démonté? La plupart des exemples utilisent silencieusement force_unmount = "0", d'autres ne le font pas, mais aucun d'entre eux n'indique comment la décision a été prise.

En dehors de cela, j'ai trouvé des exemples de configurations, où les personnes gèrent les partitions GFS avec le script d'initialisation gfs2 – https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial#Defining_The_Resources

ou même aussi simplement que de permettre aux services tels que clvm et gfs2 de démarrer automatiquement au démarrage ( http://pbraun.nethence.com/doc/filesystems/gfs2.html ), comme:

chkconfig gfs2 on

Si je comprends correctement la dernière approche, ce cluster contrôle uniquement si les noeuds sont encore en vie et peuvent se fermer chez eux, mais ce cluster n'a aucun contrôle sur l'état de ses ressources.

J'ai une certaine expérience avec Pacemaker et je suis habitué à ce que toutes les ressources sont contrôlées par un cluster et une action peut être prise quand non seulement il existe des problèmes de connectivité, mais l'une des ressources se détériore mal.

Donc, quel est le bon path pour moi?

  1. Quittez la partition GFS (des raisons pour le faire?)
  2. définissez force_unmount = "1". Cela ne brisra rien? Pourquoi ce n'est pas le défaut?
  3. utiliser la ressource de script <script file="/etc/init.d/gfs2" name="gfs"/> pour gérer la partition GFS.
  4. commencez-le au démarrage et n'incluez pas dans cluster.conf (des raisons pour le faire?)

C'est peut-être une sorte de question qui ne peut être répondu sans ambiguïté, de sorte qu'il serait également très utile pour moi si vous partagez votre expérience ou avez exprimé votre opinion sur le problème. Comment apparait-on par exemple /etc/cluster/cluster.conf lors de la configuration de gfs avec Conga ou ccs (ils ne sont pas disponibles pour moi car, pour l'instant, je dois utiliser Ubuntu pour le cluster)?

Merci beaucoup!

J'ai travaillé un peu avec des grappes. Ce sont mes opinions sur le sujet.

 could have simply added force_unmount="1", but I would like to know what is the reason behind the default behavior. Why is it not unmounted? 

Si vous choisissez de configurer gfs en tant que ressource en cluster, et ajoutez le disque clvmd et gfs en tant que ressources, alors lorsque vous rgmanager avec rgmanager il essayera d'élever le disque, alors, ce que je ferais dans votre cas d'abord, c'est vérifier les journaux (ou lsof / fuser etc.) pour une indication de la faiblesse du paramétrage. Il est probable qu'il y ait un process ayant un file ouvert ou quelque chose comme ça, empêchant un "propre".

Peut-être parce que vous n'utilisez pas rgmanager pour démarrer votre application en cluster? Je ne le vois pas dans votre cluster.conf. Cela serait vrai si cela expliquait le comportement.

Si vous choisissez force_unmount , ce que rgmanager fera en cas de défaillance / de récupération est de tuer avec force tout recours à l'aide du disque avant d'assembler le disque. Le time qui est une bonne idée ou ne dépend pas.

 clvm is stopped, but GFS is not unmounted, so a node cannot alter LVM structure on shared storage anymore, but can still access data. And even though a node can do it quite safely (dlm is still running), [...] Moreover if I later try to stop cman on that node, it will find a dlm locking, produced by GFS, and fail to stop. 

Si vous souhaitez modifier la structure LVM dans ce scénario, vous pouvez démarrer manuellement le démon clvmd. Si vous débrouillez le disque gfs avant d'arrêter cman, cela devrait fonctionner. D'autre part, dans un scénario de production, je me retrouve rarement dans une situation où je voudrais arrêter CMAN sur un noeud en cluster.

Ma preference est d'aller avec l'option 4.

 If I understand the latest approach correctly, such cluster only controls whether nodes are still alive and can fence errant ones, but such cluster has no control over the status of its resources. 

Il est vrai que si vous n'ajoutez pas de ressource gfs2 et clvmd comme ressource de cluster, rgmanager ne pourra pas le contrôler. Ce que je fais habituellement lors du réglage des grappes A / A upp (selon le cas bien sûr), c'est que j'ajoute le script de démarrage de mon service en tant que ressource en cluster . (rgmanager appellera régulièrement le script avec un argument d' status pour déterminer la météo, il doit prendre une action configurée). Puisque mon script a une dépendance sur le système de files gfs, il échouera s'il n'est monté.

L'approche 4 implique l'activation manuelle de clvmd, cman et gfs2 (et éventuellement d'autres démons en fonction de la situation).

Étant donné que le système de files GFS se trouve sur un périphérique iSCSI, l'ajout de l'option _netdev au assembly dans /etc/fstab est une exigence pour qu'il fonctionne.

  • De cette façon, je n'obtiens pas une configuration de cluster trop compliquée, append plus de services plus tard sera less un mal de tête (disons, par exemple, deux services utilisant le même disque ou quoi de jamais)
  • Quand quelque chose arrive, mon expérience est que l'intervention manuelle est beaucoup plus facile avec des ressources qui ne sont pas gérées par rgmanager
  • Selon mon expérience, ce ne sont pas les services gfs2 ou clvmd qui dérangent le plus dans un cluster, mais les services sur le haut, afin de les relancer / les assembler souvent ne vous prendra plus de time.

Il y a quelques inconvénients que je peux penser aussi:

  • Comme vous l'avez dit, rgmanager ne gérera pas ces ressources et ne prendra aucune action si, par exemple, le système de files gfs échouerait ou se findait en quelque sorte
  • avoir un système de files gfs monté beaucoup peut générer une charge inutile sur le périphérique, par exemple, updatedb et d'autres travaux qui pourraient vouloir traverser le système de files, ce qui entraînerait la latence du lecteur (locking du trafic)

Peu importe ce que vous décidez

J'appendais le script init en tant que ressource en cluster, et si vous choisissez d'append gfs et clvm au cluster en tant que ressources, je considérerais l'ajout de l'atsortingbut __independent_subtree , donc s'il échoue, rgmanager ne remonte pas le système de files gfs. Cela dépend évidemment de votre situation particulière. Notez la configuration nestede dans le lien, marquant une sorte d'arborescence de dépendance.