使用 Pacemaker 与 Corosync 构建 FreeBSD 集群
作者：𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗
2020/09/03
我一直很想找到适合 FreeBSD 系统的“正统”集群软件。最近我有机会在 Linux 系统上运行几个基于 Pacemaker/Corosync 的集群。我开始思考如何在 FreeBSD 上实现类似的高可用性解决方案，当我发现 Pacemaker 和 Corosync 工具在 FreeBSD Ports 和包中分别可以通过 net/pacemaker2 和 net/corosync2 获得时，我真的非常震惊。
在本文中，我将检查 Pacemaker 和 Corosync 集群在 FreeBSD 上的运行情况。
集群，有很多定义。我最喜欢的定义是：集群是即使失去其中一个节点仍保持冗余的系统（仍然是集群）。这意味着根据这个定义，集群的最少节点数是 3 个。两节点集群存在较大问题，因为它们最容易出现脑裂问题。这就是为什么在两节点集群中，通常会添加额外的设备或系统，以确保不会发生脑裂。例如，可以添加第三个节点，不提供任何资源或服务，仅作为“见证者”角色。另一种方式是添加共享磁盘资源，其作用相同，通常是使用 SCSI-3 持久保留机制的原始卷。
搭建实验室
一如既往，整个实验将基于 VirtualBox，并由 3 台主机组成。为了不创建 3 个相同的 FreeBSD 安装，我直接使用了由 FreeBSD 项目提供的 12.1-RELEASE 虚拟机镜像：
有多种格式可选 – qcow2/raw/vhd/vmdk – 因为我将使用 VirtualBox，所以选择了格式 VMDK 。
下面是 GlusterFS 集群的主机列表：
10.0.10.111 node1
10.0.10.112 node2
10.0.10.113 node3
每个 VirtualBox 的 FreeBSD 虚拟机均为默认配置（如 VirtualBox 向导所建议），内存为 512 MB，网络模式为 NAT Network（NAT 网络），如下图所示。
下面是 VirtualBox 上 NAT Network（NAT 网络） 的配置。
在尝试连接 FreeBSD 主机之前，需要在每台虚拟机内进行最简网络配置。每台 FreeBSD 主机将具有如下示例的最简 /etc/rc.conf 文件（以 node1 为例）。
为了搭建实验环境，我们需要允许 root 登录这些 FreeBSD 主机，在 /etc/ssh/sshd_config 文件中设置 PermitRootLogin yes。更改以后，还需要重启 sshd(8) 服务。
通过使用带有 端口转发 的 NAT Network（NAT 网络），FreeBSD 主机可以通过本地主机端口访问。例如，可以通过端口 2211 访问 node1，可以通过端口 2212 访问 node2，依此类推。如下 sockstat 工具输出所示。
要从 VirtualBox 主机系统连接到这样的虚拟机，需要使用如下命令：
软件包
现在我们已经可以通过 ssh(1) 连接，需要安装所需的软件包。为了让我们的虚拟机能够解析 DNS 查询，还需要做最后一件事。同时，我们将切换 pkg(8) 软件包到 “quarterly” 分支。
请记得在 node2 和 node3 系统上重复执行上述两条命令。
现在我们将安装软件包 Pacemaker 和 Corosync。
下面是 pacemaker2 和 corosync2 的一些需要我们处理的信息。
我们需要修改 kern.ipc.maxsockbuf 参数。那就开始修改吧。
我们来查看这些软件包都包含了哪些可执行文件。
初始化集群
现在我们将初始化 FreeBSD 集群。
首先需要确保各节点的名称可以通过 DNS 解析。
现在我们将生成 Corosync 密钥。
现在是 Corosync 配置文件的部分。当然，软件包维护者已经提供了一些示例。
我们将使用第二个示例作为配置的基础。
现在我们需要将 Corosync 密钥和配置文件分发到集群中的各个节点。
可以使用一些专门为此创建的简单工具，例如 net/csync2 集群同步工具，但传统的 net/rsync 也同样可用。
现在我们来检查它们是否一致。
一致。
现在我们可以在 /etc/rc.conf 文件中添加 corosync_enable=YES 和 pacemaker_enable=YES。
那就启动这些服务吧。
在 node2 和 node3 系统上也执行同样操作。
由于 Pacemaker 还未运行，因此操作会失败。
现在我们将启动它。
需要给它一些启动时间，因为如果你立即执行 crm status 命令，会看到如下所示的 0 nodes configured 消息。
……但过一会儿，所有节点都会被检测到，一切按预期正常工作。
Pacemaker 运行正常。
我们可以查看 Corosync 如何识别其成员。
……或者查看 quorum 信息。
Corosync 日志文件中充满了以下信息。
配置如下。
由于我们不会配置 STONITH 机制，因此将其禁用。
禁用 STONITH 后的新配置。
STONITH 配置超出了本文的范围，但正确配置的 STONITH 如下所示。
第一个服务
现在我们将配置第一个高可用服务——经典示例——一个浮动 IP 地址 :🙂:
让我们看看它的运行情况。
看起来不错——我们来检查一下集群状态。
糟糕。Linux 思维模式。系统中预期存在 ip(8) 命令。但这是 FreeBSD，像所有 UNIX 系统一样，它提供的是 ifconfig(8) 命令。
我们必须另想办法。目前我们先删除这个无用的 IP 服务。
删除后的状态。
自定义资源
让我们查看默认 Pacemaker 安装提供了哪些资源。
资源不多……我们将尝试将 Dummy 服务修改为在 FreeBSD 上的 IP 切换器。
由于 WordPress 博客系统的限制，我不得不将这个 ifconfig 资源以图片形式发布……但别担心，文本版本也可在这里下载——ifconfig.odt。
此外，第一个版本的效果并不理想……
但在为其添加 755 权限并进行了若干（上百次）修改后，它终于可以使用了。
看起来可以使用。
这是 ifconfig 资源。目前它相当有限，而且 IP 地址是硬编码的。
让我们尝试向 FreeBSD 集群添加新的 IP 资源。
测试
已添加。
我们来看现在 status 命令显示的情况。
糟糕，我忘了将这个新的 ifconfig 资源复制到其他节点。现在来修复它。
现在我们先停止、删除，然后重新添加这个重要的资源。
祈祷顺利吧。
看起来运行正常。
让我们验证它是否确实在应该的节点上启动。
看起来确实在工作。
现在我们尝试将它移动到集群中的另一台节点。
已成功切换到 node3 系统。
现在我们将 关闭 node3 系统，以检查这个 IP 是否真的具备高可用性。
看起来故障切换进行得很顺利。
crm 命令还会对其输出的不同部分进行高亮显示。
很高兴知道 Pacemaker 和 Corosync 集群在 FreeBSD 上运行良好。
虽然需要一些工作来编写必要的资源文件，但只要有时间和决心，完全可以将 FreeBSD 打造成非常强大的高可用集群。
最后更新于
这有帮助吗？