RHCS: A/A集群中具有公共存储的GFS2。用rgmanager配置GFS

Question

我正在配置一个两个节点的A/A集群，通过iSCSI附加一个公共存储，它在集群LVM上使用GFS2。到目前为止，我已经准备了一个简单的配置，但不确定哪种方式是正确的配置gfs资源。

以下是/etc/群集/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脚本- https://alteeve.ca/w/2-Node_红色_帽子_KVM_集群_Tutorial#Defining_这个_资源管理GFS分区。

或者仅仅允许诸如clvm和gfs2这样的服务在引导(http://pbraun.nethence.com/doc/filesystems/gfs2.html)时自动启动，比如：

chkconfig gfs2 on

如果我正确地理解了最新的方法，这种集群只控制节点是否还活着，并且可以隔离错误的节点，但是这样的集群无法控制其资源的状态。

我有一些经验，并且我已经习惯了所有的资源都是由一个集群控制的，当不仅存在连接问题，而且任何资源行为不正常时，都可以采取相应的行动。

所以，这对我来说是正确的选择：

1. 让GFS分区挂载(有理由这样做吗？)
2. 设置force_unmount="1“。这不会破坏什么吗？为什么这不是默认的呢？
3. 使用脚本资源<script file="/etc/init.d/gfs2" name="gfs"/>管理GFS分区。
4. 在引导时启动它，而不包括在cluster.conf中(有理由这样做吗？)

这可能是一个无法明确回答的问题，因此，如果你能分享你的经验或表达你对这个问题的想法，对我来说也是很有价值的。例如，当使用Conga或ccs配置gfs时/etc/cluster.conf是什么样子(因为现在我不得不使用Ubuntu来实现集群)，所以我无法使用它们。

非常感谢你！

Answer 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等)，以了解为什么umounting可能失败。很可能有一个进程打开了一个文件或类似的东西，从而防止了一个“干净的”umount。

这可能是因为您没有使用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将无法控制它。在设置upp A/A集群(当然取决于情况)时，我通常所做的是将服务的开始脚本添加为集群资源。(rgmanager将定期调用带有status参数的脚本，以确定是否需要采取配置的操作)。由于我的脚本依赖于gfs文件系统，除非挂载，否则它将失败。

4种方法意味着手动标记clvmd、cman和gfs2 (可能还包括其他守护进程，这取决于具体情况)。

由于GFS文件系统位于iSCSI设备的顶部，因此在/etc/fstab中的挂载中添加_netdev选项是其工作的必要条件。

• 这样我就不会得到过于复杂的集群配置，以后添加更多的服务就不会那么麻烦了(例如，使用相同磁盘的两个服务，或者其他什么)。
• 当某些事情发生时，我的经验是，如果资源不是由rgmanager管理的，手动干预就容易得多。
• 根据我的经验，在集群中出错最多的不是gfs2或clvmd服务，而是顶部的服务，因此重新启动/挂载它们通常只会占用您额外的时间。

我也能想到一些缺点：

• 正如您所说的，rgmanager将不管理这些资源，如果gfs文件系统以某种方式失败/获得汇总，则不会采取任何行动。
• 大量安装gfs文件系统可以在设备上产生不必要的负载，例如updatedb和其他作业，这些作业可能需要遍历文件系统，从而导致驱动器延迟(锁定通信量)。

，不管你做什么决定，

我会将init脚本添加为集群资源，如果您选择将gfs和clvm作为资源添加到集群中，我将考虑向其添加__独立的_子树属性，因此如果失败，rgmanager将不会重新挂载gfs文件系统。这当然取决于你的特殊情况。注意链接中的嵌套配置，标记一种依赖树。