Je suis en train de configurer un cluster A/A à deux nœuds avec un stockage commun attaché via iSCSI, qui utilise GFS2 au-dessus de LVM en cluster. Jusqu'à présent, j'ai préparé une configuration simple, mais je ne suis pas sûr de la bonne façon de configurer les ressources GFS.
Voici la section rm de /etc/cluster/cluster.conf :
<rm>
<failoverdomains>
<failoverdomain name="node1" nofailback="0" ordered="0" restricted="1">
<failoverdomainnode name="rhc-n1"/>
</failoverdomain>
<failoverdomain name="node2" nofailback="0" ordered="0" restricted="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>Voici ce que je veux dire : lorsque l'agent de ressources clusterfs est utilisé pour gérer une partition GFS, celle-ci n'est pas démontée par défaut (à moins que l'option force_unmount soit donnée). Ainsi, lorsque je lance
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 en toute sécurité (dlm est toujours en cours d'exécution), cela me semble plutôt inapproprié, puisque clustat signale que le service sur un nœud particulier est arrêté. De plus, si j'essaie ensuite d'arrêter cman sur ce nœud, il trouvera un verrouillage dlm, produit par GFS, et échouera à s'arrêter.
J'aurais pu simplement ajouter force_unmount="1", mais j'aimerais savoir quelle est la raison de ce comportement par défaut. Pourquoi n'est-il pas démonté ? La plupart des exemples qui existent utilisent silencieusement force_unmount="0", certains ne le font pas, mais aucun d'entre eux ne donne d'indice sur la façon dont la décision a été prise.
En dehors de cela, j'ai trouvé des exemples de configurations, où les gens gèrent les partitions GFS avec gfs2 init script -. https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial#Defining_The_Resources
ou même simplement en permettant 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 bien la dernière approche, un tel cluster contrôle uniquement si les nœuds sont toujours en vie et peut exclure les nœuds errants, mais il n'a aucun contrôle sur l'état de ses ressources.
J'ai une certaine expérience de Pacemaker et je suis habitué au fait que toutes les ressources sont contrôlées par un cluster et qu'une action peut être entreprise non seulement en cas de problèmes de connectivité, mais aussi lorsque l'une des ressources se comporte mal.
Donc, quelle est la bonne voie pour moi :
- laisser la partition GFS montée (y a-t-il des raisons de le faire ?)
- set force_unmount="1". Cela ne va-t-il pas casser quelque chose ? Pourquoi n'est-ce pas la valeur par défaut ?
- Utiliser la ressource script.
<script file="/etc/init.d/gfs2" name="gfs"/>pour gérer une partition GFS. - le lancer au démarrage et ne pas l'inclure dans cluster.conf (y a-t-il des raisons de le faire ?)
Il s'agit peut-être d'une question à laquelle il est impossible de répondre de manière univoque, et il serait donc très utile pour moi que vous partagiez votre expérience ou que vous exprimiez vos idées sur le sujet. Comment se présente par exemple le fichier /etc/cluster/cluster.conf lors de la configuration de gfs avec Conga ou ccs (ils ne sont pas disponibles pour moi puisque pour l'instant je dois utiliser Ubuntu pour le cluster) ?
Merci beaucoup !
