标签: heartbeat

除了典型的 Heartbeat/Pacemaker/CoroSync 组合之外，在 Linux 上是否还有其他主要的自动故障转移替代方案？特别是，我正在 EC2 实例上设置故障转移，它只支持单播 - 没有多播或广播。我专门尝试处理我们拥有的少数软件，这些软件还没有自动故障转移功能并且不支持多主环境。这包括 HAProxy 和 Solr 等工具。

我有 Heartbeat+Pacemaker 工作，但我对此并不感到兴奋。以下是我的一些问题：

• 心跳 - 就其本身而言，仅限于两个节点。我想要 3+。
• 起搏器 - 无法自动配置。集群必须以法定人数运行，然后它仍然需要手动配置。
• CoroSync - 不支持单播。

起搏器工作得很好，尽管它的功率使其难以设置。Pacemaker 的真正问题在于没有简单的方法来自动化配置。我真的很想启动一个 EC2 实例，安装 Chef/Puppet 并在没有我干预的情况下启动整个集群。

我们需要一些比 ELB 提供的更高级的功能（主要是 L7 检查），但是如何使用 EC2 使用诸如 haproxy 之类的东西来处理诸如心跳和高可用性之类的事情并不明显。我们很有可能在集群中需要 3 个或更多 haproxy 节点，因此两个节点之间的简单心跳是行不通的。

似乎在 haproxy 节点前面有一个心跳层是可行的方法，可能使用 IPVS，但是随着 EC2 集群的变化处理配置更改（通过有意的更改，如扩展，或无意的，如丢失EC2 节点）似乎很重要。

优选地，该解决方案将跨越至少两个可用区。

回答问题：不，会话没有粘性。是的，我们需要 SSL，但理论上这可以完全由另一个设置处理 - 我们能够将 SSL 流量定向到与非 SSL 流量不同的位置。

我想构建一个高可用的服务器集群。现在我想知道关于keepalive和heartbeat的细节，两者有什么区别，以及如何选择一个。

刚刚完成我对设置 Web 服务器集群的研究，但我仍未决定与 Pacemaker 一起使用哪个消息传递层。我使用的服务器都是 Fedora，所以这两层都可以通过 YUM 获得，两者都有很好的文档记录，据说可以很好地与 Pacemaker 配合使用。我无法找到的是关于哪个更好的意见。有没有人对这两种方法都有经验，并且对哪一种更好有偏好？是否有更大的社区支持基础？一个比另一个更稳定吗？或者这是一个随意的决定？

我一直在研究数据中心之间 MySQL 的高可用性 (HA) 解决方案。

对于位于同一物理环境中的服务器，我更喜欢使用主动被动方法的带心跳的双主（浮动 VIP）。心跳通过串行连接和以太网连接。

最终，我的目标是在数据中心之间保持相同级别的可用性。我想在没有人工干预的情况下在两个数据中心之间进行动态故障转移，并且仍然保持数据完整性。

上面会有 BGP。两个位置的 Web 集群，这将有可能路由到双方之间的数据库。如果站点 1 上的 Internet 连接中断，则客户端将通过站点 2 路由到 Web 集群，如果两个站点之间的链接仍然存在，则路由到站点 1 中的数据库。

在这种情况下，由于缺乏物理链接（串行），更有可能发生脑裂。如果两个站点之间的 WAN 出现故障，VIP 最终会出现在两个站点上，在那里各种令人不快的情况可能会导致不同步。

我看到的另一个潜在问题是，将来难以将此基础设施扩展到第三个数据中心。

网络层不是重点。在这个阶段，架构是灵活的。同样，我的重点是维护数据完整性以及与 MySQL 数据库的自动故障转移的解决方案。我可能会围绕此设计其余部分。

您能否为两个物理上不同的站点之间的 MySQL HA 推荐一个经过验证的解决方案？

感谢您抽出时间来阅读。我期待着阅读您的建议。

在管理自己集群的人中（即不使用/支付 Amazon Autoscale、Rightscale、Scalr 等），您如何管理 EC2 上的实例并处理（例如）故障转移？我想知道是否大多数人最终会像我怀疑的那样针对 EC2 API 编写自己的大量脚本。

这当然是我们的方法：启动我们自己的基于 Python Boto 的监控/重启守护进程，该守护进程在异地运行，从我们的实例中监听 UDP 保持活动。失败时，我们对卷进行快照、注册映像、启动新实例、删除旧卷等。

每隔一段时间，当对我们的脚本进行黑客攻击时，我认为必须有一些开源工具已经可以处理这些问题，并且没有（比如）Scalr 的限制，但我总是从谷歌回来空手而归。（像 Scalr 这样的东西在支持的软件集/版本/配置方面非常有限，并且有专门的和 IMO 繁琐的方法来操纵这些设置。）

此外，Linux-HA/Pacemaker 生态系统（Heartbeat、ldirectord 等）听起来并不适合 EC2。（但后来我发现了这一点——尽管我不确定这是否真的是一个高质量的解决方案）。

我希望使用 Heartbeat/Squid/Varnish/etc 之类的东西来平衡内部 apache 实例之间的传入流量。这必须是软件而不是硬件，因为我所有的东西都在 VPS 上运行。我在这方面没有很多经验，如果我滥用术语并选择了错误的包，那么很抱歉。

我已经草拟了一些东西来说明我所追求的。绿色部分是初始设置的样子，蓝色部分是由于流量增加而添加更多 apache 实例后的样子。这可能不是这些事情的工作方式，但理想情况下，我会将平衡器的 IP 添加到域的 DNS 中。然后平衡器将查看每个 apache 实例上有多少连接（通过一些内部 IP 或永久 IP 的配置列表）并平均分配连接。蓝色部分有第二个平衡器，因为我确信在某些时候平衡器也需要帮助。

也许我正在解决这个错误，但我正在寻找关于“平衡器/s”应该是什么以及如何设置它们的最佳实践的帮助。

任何帮助都会很棒。

我们利用心跳实现高可用性。我想向心跳集群添加一个额外的 ip 地址，但我不想在此过程中完全重启集群。是否有我可以发送到 heartbeat 的信号来提示它重新解析“haresources”文件并对其采取行动？heartbeat -r 似乎不能解决问题。

我有一个带有心跳和 DRBD 的两节点集群管理 mysql 资源。如果我停止主服务器、重新启动它或断开网络连接，故障转移效果很好。

但是，如果主服务器遇到内核崩溃（通过运行模拟echo c > /proc/sysrq-trigger），则辅助服务器不会接管资源。

这是辅助节点上的心跳日志的样子：

Jul 11 21:33:32 rad11 heartbeat: [7519]: WARN: node rad10: is dead
Jul 11 21:33:32 rad11 heartbeat: [7519]: info: Link rad10:eth0 dead.
Jul 11 21:33:32 rad11 heartbeat: [8442]: info: Resetting node rad10 with [Meatware STONITH device]
Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: OPERATOR INTERVENTION REQUIRED to reset rad10.
Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: Run "meatclient -c rad10" AFTER power-cycling the machine.

有没有人知道为什么在这种情况下二级无法接管？通常故障转移效果很好，但我试图在主节点上模拟内核崩溃。

编辑：这是我的心跳配置，ha.cf

# …

我以前做过这样的设置，没有任何问题。现在我无法执行“crm 配置”，因为当前包中没有可用的 crm 命令。

我错过了什么吗？也许它被其他方式/命令取代？

[root@node1 src]# find / -name crm*|grep bin
/usr/sbin/crm_mon
/usr/sbin/crmadmin
/usr/sbin/crm_error
/usr/sbin/crm_shadow
/usr/sbin/crm_ticket
/usr/sbin/crm_failcount
/usr/sbin/crm_resource
/usr/sbin/crm_master
/usr/sbin/crm_diff
/usr/sbin/crm_attribute
/usr/sbin/crm_node
/usr/sbin/crm_simulate
/usr/sbin/crm_standby
/usr/sbin/crm_verify
/usr/sbin/crm_report