我正在configuration一个具有通过iSCSI连接的公共存储的双节点A / A群集，该群集在集群LVM之上使用GFS2。 到目前为止，我已经准备了一个简单的configuration，但不知道哪个是正确的方式来configurationgfs资源。
这是/etc/cluster/cluster.conf的rm部分：
<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> 这就是我的意思：当使用clusterfs资源代理来处理GFS分区时，默认情况下它不会被卸载（除非给出了force_unmount选项）。 当我发出这种方式
clusvcadm -s shared-storage-inst1
clvm已停止，但GFS未卸载，因此节点不能再更改共享存储上的LVM结构，但仍可以访问数据。 即使一个节点可以很安全地执行（dlm仍在运行），这似乎对我来说是不合适的，因为clustat报告特定节点上的服务已停止。 此外，如果我稍后尝试在该节点上停止cman，则会发现由GFS生成的dlmlocking，并且无法停止。
我可以简单地添加force_unmount =“1”，但我想知道默认行为背后的原因是什么。 为什么不能卸载？ 这里的大部分例子默默地使用了force_unmount =“0”，有些则没有，但是他们没有提供任何关于如何做出决定的线索。
除此之外，我find了示例configuration，其中人们使用gfs2 init脚本pipe理GFS分区 – https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial#Defining_The_Resources
甚至可以简单地启用诸如clvm和gfs2之类的服务，在启动时自动启动（ http://pbraun.nethence.com/doc/filesystems/gfs2.html ），如下所示：
chkconfig gfs2 on
如果我正确理解了最新的方法，那么这个集群只能控制节点是否还活着，可以隔离错误的集群，但这样的集群无法控制其资源的状态。
我对Pacemaker有一些经验，我习惯了所有的资源都是由一个集群控制的，当不仅存在连接问题，而且任何一个资源行为不当时，都可以采取行动。
所以，这是我走的正确方法：
<script file="/etc/init.d/gfs2" name="gfs"/>来pipe理GFS分区。 这可能是一个不能毫不含糊地回答的问题，如果你分享了你的经验或者对这个问题expression了你的想法，这对我来说也是很有价值的。 在configurationgfs和conga或ccs时，如何configuration/etc/cluster/cluster.conf（它们不适用于我，因为现在我必须使用Ubuntu作为集群）？
非常感谢你！
我已经与群集工作了一点。 这些是我对这个问题的看法。
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?
如果您select将gfsconfiguration为集群资源，并将clvmd和gfs磁盘作为资源添加，那么当您使用rgmanager故障转移时， 它将尝试卸载磁盘，所以我在您的案例中首先执行的是检查日志（或lsof / fuser等），以指示为什么卸载可能失败。 可能有一个文件打开或类似的过程，防止“干净”卸载。
难道是因为你不使用rgmanager启动你的集群应用程序？ 我没有在你的cluster.conf中看到它。 如果真的，那会解释行为。
如果你select了force_unmount ，rgmanager在失败/恢复时会做的事情是在卸载磁盘之前用磁盘强制终止任何资源。 天气这是一个好主意或不依赖。
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.
如果您想在这种情况下更改LVM结构，则可以手动再次启动clvmd守护进程。 如果你在停止cman之前卸载gfs磁盘，那应该可以。 另一方面，在一个生产环境中，我很less发现自己处于一个想要在群集节点上停止CMAN的情况。
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.
确实，如果不将gfs2和clvmd资源添加为群集资源， rgmanager将无法控制它。 我通常在设置upp A / A集群时（根据当然情况），我会将我的服务的启动脚本添加为集群资源 。 （rgmanager会定期调用带有status参数的脚本来确定需要采取configuration操作的天气）。 由于我的脚本依赖于gfs文件系统，它将会失败，除非它被挂载。
第四种方法意味着手动启用clvmd ， cman和gfs2 （可能还有其他守护进程，视情况而定）。
由于GFS文件系统位于iSCSI设备_netdev ，因此在/etc/fstab _netdev选项添加到安装中是它的工作要求。
rgmanagerpipe理的资源来说，手动干预要容易rgmanager 我也能想到一些缺点：
updatedb和其他可能需要遍历文件系统的作业，从而导致驱动器延迟（lockingstream量） 我会将init脚本添加为集群资源，如果您select将gfs和clvm作为资源添加到集群，我会考虑向其添加__independent_subtree属性，所以如果失败，rgmanager将不会重新安装gfs文件系统。 这当然取决于你的特定情况。 请注意链接中的嵌套configuration，标记一种依赖关系树。