我正在配置一个双节点 A/A 集群，该集群通过 iSCSI 连接一个公共存储，该集群在集群 LVM 上使用 GFS2。到目前为止，我已经准备好了一个简单的配置，但不确定哪种方式才是配置 gfs 资源的正确方法。
以下是 /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 生成的 dlm 锁定，并且无法停止。
我本来可以简单地添加 force_unmount="1"，但我想知道默认行为背后的原因是什么。为什么不卸载？大多数示例都默默地使用了 force_unmount="0"，有些则没有，但它们都没有给出任何关于如何做出决定的线索。
除此之外，我还找到了一些示例配置，人们使用 gfs2 init 脚本来管理 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 有一些经验，我习惯于所有资源都由集群控制，并且当不仅存在连接问题，而且任何资源出现故障时都可以采取行动。
那么，对我来说，哪条路才是正确的：
- 保持 GFS 分区挂载（有什么理由这样做？）
- 设置 force_unmount="1"。这不会破坏任何东西吗？为什么这不是默认设置？
- 使用脚本资源
<script file="/etc/init.d/gfs2" name="gfs"/>来管理GFS分区。 - 在启动时启动它并且不包含在 cluster.conf 中（这样做有什么理由吗？）
这可能是一个无法明确回答的问题，因此如果您能分享您的经验或表达您对这个问题的看法，对我来说也会非常有价值。例如，当使用 Conga 或 ccs 配置 gfs 时，/etc/cluster/cluster.conf 是什么样子的（它们对我来说不可用，因为目前我必须使用 Ubuntu 来构建集群）？
非常感谢你！
答案1
我曾与集群打过交道。以下是我对这个主题的看法。
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?
如果您选择将 gfs 配置为群集资源，并添加clvmd和gfs磁盘作为资源，那么当您使用rgmanager它进行故障转移时将要尝试卸载磁盘，因此对于您的情况，我首先要做的是检查日志（或lsof/fuser等）以了解卸载失败的原因。可能存在某个进程正在打开文件或类似情况，从而阻止“干净”卸载。
可能是因为您没有使用 rgmanager 来启动集群应用程序吗？我在您的 cluster.conf 中没有看到它。如果这是真的，那将解释这种行为。
如果您选择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 磁盘，则应该可以。另一方面，在生产场景中，我很少遇到想要在集群节点上停止 CMAN 的情况。
我倾向于选择选项 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.
确实，如果你不添加gfs2资源clvmd作为集群资源，rgmanager您将无法控制它。在设置 A/A 集群时（当然，视情况而定），我通常会这样做将我的服务的启动脚本添加为集群资源status.（rgmanager 随后会定期使用参数调用该脚本，以确定是否需要执行已配置的操作）。由于我的脚本依赖于 gfs 文件系统，因此除非挂载该文件系统，否则它将失败。
方法 4 意味着手动启用clvmd、cman和gfs2（并且可能根据情况启用其他守护进程）。
由于 GFS 文件系统位于 iSCSI 设备之上，因此添加_netdev挂载选项/etc/fstab是其工作的必要条件。
- 这样，我就不会得到过于复杂的集群配置，以后添加更多服务就不会那么麻烦了（比如两个服务使用同一个磁盘或者其他什么）
- 当事情真的发生时，我的经验是，有了资源，人工干预会容易得多不是由管理
rgmanager - 根据我的经验，集群中最容易出错的不是 gfs2 或 clvmd 服务，而是顶层服务，因此经常重新启动/安装它们只会花费您额外的时间。
我也能想到一些缺点：
- 就像你说的，rgmanager 不会管理这些资源，并且如果 gfs 文件系统以某种方式出现故障/被卸载，它不会采取任何措施
- 大量安装 gfs 文件系统可能会给设备带来不必要的负载，例如
updatedb其他可能需要遍历文件系统的作业，从而导致驱动器延迟（锁定流量）
无论你做什么决定
我会将 init 脚本添加为集群资源，如果您选择将gfs和clvm作为资源添加到集群，我会考虑添加__independent_subtree属性，因此如果失败，rgmanager 将不会重新挂载 gfs 文件系统。这当然取决于您的具体情况。请注意链接中的嵌套配置，标记一种依赖关系树。