我对 DRBD 和 NFS 还很陌生，正在测试带有心跳的 DRDB 服务器，以用于我们公司的 NFS 共享。
整个设置运行良好，NFS 状态目录与实际共享一起在 DRDB 共享上运行。
我遇到的问题来自我正在测试的故障转移方案。在故障转移方案中，我创建了一个问题，即我在节点 1 上禁用网络连接 (ifconfig eth0 down)。故障转移工作得很好，大约 5 秒就能完成工作，但是当我将其重新启动时 (ifconfig eth0 up，如果它已停止，则启动服务心跳)，需要 3-5 分钟才能恢复，在此期间 NFS 共享不可用。
在网络环境中，这 3-5 分钟的停机时间相当长。这是正常的吗？我做错了什么？
我将我们的 drbd.conf 文件粘贴在下面。
resource r0 {
protocol C;
startup {
degr-wfc-timeout 60; # 1 minute.
}
disk {
on-io-error detach;
}
net {
}
syncer {
rate 10M;
al-extents 257;
}
on tsa-dev-nfstest1 { # ** EDIT ** the hostname of server 1 (un
device /dev/drbd0; #
disk /dev/sdc1; # ** EDIT ** data partition on server 1
address 10.61.2.176:7788; # ** EDIT ** IP address on server 1
meta-disk /dev/sdb1[0]; # ** EDIT ** 128MB partition for DRBD on serve
}
on tsa-dev-nfstest2 { # ** EDIT ** the hostname of server 2 (un
device /dev/drbd0; #
disk /dev/sdc1; # ** EDIT ** data partition on server 2
address 10.61.2.177:7788; # ** EDIT ** IP address on server 2
meta-disk /dev/sdb1[0]; # ** EDIT ** 128MB partition for DRBD on serve
}
}
答案1
您的心跳资源组是否包含 NFS 服务的逻辑 IP？
它应该是您最后一个“启动”的资源，也是第一个“关闭”的资源。您的客户端应该使用此 IP 来访问 NFS 服务。
如果您已定义 IP，您可以尝试使用其他资源类型作为 IPAddr（就我记得是 IPAddr2）。该资源类型在 IP 堆栈上的行为略有不同。
基本上，两种类型都应该在 IP 出现后进行 arp 广播 - 以确保连接的路由器和交换机重新学习它们的 mac 表，以便它们知道在故障转移发生后将数据包转发到哪里。
在某些 NFS 实现中，您还应该明确地对已连接的客户端进行 arp。为此，您还必须将连接的客户端数据镜像到备用节点。
答案2
在为我的公司开发 drbd 支持的高可用性 NFS 服务器时，我发现当集群 IP 在测试后返回原始节点时，客户端会出现几分钟（最多约 10 分钟）的停机时间。在这种情况下，新连接会被立即接受并提供服务，但已连接的客户端会经历几分钟的停机时间。
在使用 tcpdump 检查网络流量后，我发现这是 TCP 连接序列号不同步的问题，需要重置。
我建议您使用 Pacemaker 而不是 Heartbeat 来管理集群。如果您这样做，在实际情况下，Pacemaker 能够发出 STONITH（Shoot The Other Node In The Head）请求，从而防止这种情况发生。基本上它会重新启动另一个节点，这肯定会解决这个 TCP 问题。
此外，Pacemaker 在监测方面也比 Heartbeat 好得多。看看这些网站：