☰

使用 Heartbeat 和 Pacemaker 监控 Varnish

tag-icon • tag-icon varnish heartbeat pacemaker
使用 Heartbeat 和 Pacemaker 监控 Varnish

我有一对服务器设置为高可用性负载均衡器/反向代理。每台服务器都运行 Ubuntu 12.04 x64 Server、Varnish、Heartbeat 和 Pacemaker，其中 Varnish 将流量负载均衡到后端服务器。

如果其中一个负载平衡器发生故障，Heartbeat/Pacemaker 会将一组虚拟 IP 转移到另一台服务器，然后流量恢复。这个功能运行良好。

我没有考虑到如果 Varnish 未在两台服务器上运行。目前可以停止 Varnish 而不触发 Heartbeat/Pacemaker 的任何操作。我希望当前服务器上没有可运行的 Varnish 来触发移动到备份（而不是尝试重新启动 Varnish），但我很难在网上找到任何指导。有人能帮忙吗？

编辑Daff的协助后：

我最终得到的结果与我最初的要求略有不同：Pacemaker 尝试重新启动 Varnish 一次，如果失败，它会将所有资源移动到被动节点。

我的设置是两台服务器，serverA（主动）和 serverB（被动）。我假设消息传递层（Heartbeat 或 Corosync）已经设置并运行。为了允许 Pacemaker 控制 Varnish，我们需要修复 Ubuntu 的 Varnish 初始化脚本：

sudo vim /etc/init.d/varnish

代替：

--start --quiet --pidfile ${PIDFILE} --exec ${DAEMON} -- \

在 start_varnish_d() 函数中添加：

--start --quiet --pidfile ${PIDFILE} --oknodo --exec ${DAEMON} -- \

所以它按照概述的规则运作这里.现在在 serverA 上设置一个具有两个虚拟 IP 的基本 Pacemaker 集群：

sudo crm configure property no-quorum-policy=ignore
sudo crm configure property stonith-enabled=false
sudo crm configure primitive virtual_ip_1 ocf:heartbeat:IPaddr params ip="192.168.1.134" nic="eth1" cidr_netmask="24" broadcast="192.168.1.255" op monitor interval="10s" timeout="20s"
sudo crm configure primitive virtual_ip_2 ocf:heartbeat:IPaddr params ip="192.168.1.135" nic="eth1" cidr_netmask="24" broadcast="192.168.1.255" op monitor interval="10s" timeout="20s"

为 Varnish 添加一个原语，提供监控频率，以及启动和停止 Varnish 的充足时间：

sudo crm configure primitive varnish lsb:varnish op monitor interval="10s" timeout="20s" op
start interval="0" timeout="15s" op stop interval="0" timeout="15s"

将 varnish 原语与虚拟 IP 分组，以便 Pacemaker 在发生故障时将所有资源迁移到被动节点：

sudo crm configure group cluster virtual_ip_1 virtual_ip_2 varnish

设置迁移阈值，以便 Pacemaker 在将所有资源移至被动节点之前容忍两次故障。对于 Varnish，这意味着一次初始故障，加上一次失败的重启尝试：

sudo crm_attribute --type rsc_defaults --attr-name migration-threshold --attr-value 2

设置失败超时。这似乎做两件事：

  1. 在迁移到被动节点之前，为 Pacemaker 提供一次 Varnish 重启尝试的时间。

  2. 防止故障节点在 30 秒后被标记为故障，允许将资源移回该节点，而无需在故障后手动运行 crm resource cleanup varnish。这对我的设置来说是件好事，因为我没有在节点上设置任何权重，但在其他环境中，这可能是一个非常糟糕的主意。

sudo crm_attribute --type rsc_defaults --attr-name Failure-Timeout --attr-value 30s

就是这样，但请参阅下面 Daff 的回答，了解有关粘性的评论，我最终没有使用它。我能看到的唯一缺点是，如果您手动将节点置于待机状态，Pacemaker 将关闭该节点上的 Varnish，从而清除内存缓存。对我来说，这不是什么大问题。

答案1

您的集群架构让我感到困惑，因为看起来您正在同时在两个节点上独立运行应该由集群管理的服务（如 Varnish），并让集群资源管理器（CRM）只需调整 IP 地址即可。

您希望通过集群设置实现什么目标？容错？负载平衡？两者兼而有之？请注意，我指的是集群资源（Varnish、IP 地址等），而不是 Varnish 分配负载的后端服务器。

在我看来，您需要一个主动-被动双节点集群，它提供容错能力。一个节点是主动的，运行 Varnish、虚拟 IP 地址和可能的其他资源，另一个节点是被动的，不执行任何操作，直到集群资源管理器将资源移至被动节点，此时它变为主动的。这是一种久经考验的架构，历史悠久。但要使其发挥作用，您需要让 CRM 完全控制资源。我建议遵循从头开始构建集群并以此为基础对你的集群进行建模。

编辑在您更新问题之后：您的 CIB 看起来不错，并且一旦您修补了 Varnish 初始化脚本，以便重复调用“start”返回 0，您应该能够添加以下原语（根据您的喜好调整超时和间隔）：

primitive p_varnish lsb:varnish \
    op monitor interval="10s" timeout="15s" \
    op start interval="0" timeout="10s" \
    op stop interval="0" timeout="10s"

不要忘记将其添加到平衡器组（列表中的最后一个元素）：

group balancer eth0_gateway eth1_iceman_slider eth1_iceman_slider_ts \
    eth1_iceman_slider_pm eth1_iceman_slider_jy eth1_iceman eth1_slider \
    eth1_viper eth1_jester p_varnish

编辑2：要降低迁移阈值，请在 CIB 末尾添加资源默认部分，并将属性设置migration-threshold为较小的数字。将其设置为 1 表示资源将在一次故障后迁移。设置资源粘性也是一个好主意，这样由于节点故障（重新启动或关闭）而迁移的资源不会在节点再次可用时自动迁移回来。

rsc_defaults $id="rsc-options" \
    resource-stickiness="100" \
    migration-threshold="1"

相关内容