Pav*_*l A 5 rhcs shared-storage gfs2
我正在配置一个双节点 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 有一些经验，我习惯于所有资源都由一个集群控制，并且当不仅存在连接问题而且任何资源行为不当时都可以采取措施。
所以，这对我来说是正确的方式：
<script file="/etc/init.d/gfs2" name="gfs"/>来管理 GFS 分区。这可能是一种无法明确回答的问题，因此如果您分享您的经验或表达您对此问题的看法，对我来说也很有价值。例如，使用 Conga 或 ccs 配置 gfs 时 /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?
如果您选择将 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。
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我也能想到一些缺点：
updatedb可能需要遍历文件系统的其他作业，从而导致驱动器延迟（锁定流量）我会将 init 脚本添加为集群资源，如果您选择将gfs和clvm作为资源添加到集群，我会考虑向其添加__independent_subtree属性，因此如果失败，rgmanager 将不会重新挂载 gfs 文件系统。这当然取决于您的具体情况。请注意链接中的嵌套配置，标记了一种依赖关系树。