我有一对服务器设置为高可用性负载均衡器/反向代理。 每个运行Ubuntu 12.04 x64服务器，Varnish，心跳和Pacemaker，与清漆负载平衡stream量到后端服务器。
如果负载平衡器中的任何一个发生故障，Heartbeat / Pacemaker会将一组虚拟IP转移到另一台服务器上，并恢复stream量。 这一点工作正常。
我没有考虑的是，如果Varnish没有运行在任何一台服务器上。 目前可以停止清漆而不触发Heartbeat / Pacemaker的任何行动。 我想在当前的服务器上缺乏运行的Varnish来触发备份（而不是尝试重新启动Varnish），但是我正在努力寻找任何types的在线指导。 谁能帮忙？
我结束了一些与原始请求不同的事情：Pacemaker尝试重新启动Varnish，如果失败，它会将所有资源移动到被动节点。
我的设置是两个服务器，serverA（主动）和serverB（被动）。 我会假设消息层（Heartbeat或Corosync）已经安装并正在工作。 为了让Pacemaker控制Varnish，我们需要修复Ubuntu的Varnish init脚本：
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"
添加一个用于清漆的基元，提供一个监测频率，以及用于启动和停止清漆的大量计时：
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"
将虚拟原语与虚拟IP分组，所以Pacemaker在发生故障时将所有资源迁移到被动节点：
sudo crm configure group cluster virtual_ip_1 virtual_ip_2 varnish
设置迁移阈值，因此Pacemaker在将所有资源移动到被动节点之前将容忍两次失败。 对于清漆，这意味着一个初始故障，再加上一个失败的重启尝试：
sudo crm_attribute --type rsc_defaults --attr-name migration-threshold --attr-value 2
设置失败超时。 这似乎做了两件事：
在迁移到被动节点之前，为Pacemaker提供一次Varnish重启尝试的时间。
防止发生故障的节点在30秒后被标记为失败，从而允许将资源移回到该节点，而无需在发生故障后手动运行crm资源清理清漆。 这对我的设置是好事，因为我没有在节点上设置任何权重，但是在不同的环境中这可能是一个非常糟糕的主意。
sudo crm_attribute –type rsc_defaults –attr-name failure-timeout –attr-value 30s
就是这样，但是看到达夫的回答下面的粘性，我没有最终使用的意见。 我可以看到唯一的缺点是，如果手动将节点置于待机状态，Pacemaker将在该节点上closuresVarnish，从而清除内存中的caching。 对我来说，这不是一个特别大的事情。
您的集群体系结构让我感到困惑，因为您似乎在同时在两个节点上独立运行应该集群pipe理的服务（如Varnish），并让集群资源pipe理器（CRM）只是绕过IP地址。
你想用你的集群设置达到什么目的？ 容错？ 负载均衡？ 都？ 请注意，我在谈论集群资源（Varnish，IP地址等），而不是Varnish分配负载的后端服务器。
对我来说，这听起来像你想要一个主动 – 被动双节点群集，它提供容错。 一个节点处于活动状态并运行Varnish（虚拟IP地址和其他可能的资源），另一个节点处于被动状态，直到集群资源pipe理器将资源移动到被动节点（此时它变为活动状态）。 这是一个久经考验的架构，与时间本身一样古老。 但是为了工作，您需要让CRM完全控制资源。 之后，我build议从头开始遵循集群并为集群build模。
更新后的问题编辑 ：你的CIB看起来不错，一旦你修补光油初始化脚本，以便重复调用“开始”返回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意味着资源将在单个故障后迁移。 设置资源粘性也是一个好主意，以便在节点重新可用时，由于节点故障（重新启动或closures）而迁移的资源不会自动迁移回来。
rsc_defaults $id="rsc-options" \ resource-stickiness="100" \ migration-threshold="1"