Pacemaker 生态系统（Corosync 等）在 EC2 环境中是否有意义？到目前为止，Corosync 需要 IP 多播（在 EC2 上不可用），但我认为它现在已经广播了。不过，Pacemaker 等是否是集群在 EC2 上进行自我管理的合适工具，例如相互监视故障并触发启动新实例来替换故障实例？
我想部分问题在于我花了相当多的时间来理清这里的所有参与者（Heartbeat、Corosync、OpenAIS 等），而且我仍在试图弄清楚这些东西到底是什么是（超越模糊的术语，例如 Pacemaker 是一个“集群资源管理器”，而 Corosync 提供“可靠的消息传递和成员资格基础设施”）。
因此，如果我的问题本身有点混乱或没有完全意义，我深表歉意。任何见解都将不胜感激。谢谢。
答案1
EC2 是否监控客户机内部服务的运行状况？
如果不是，而这正是您想要的，那么 Pacemaker 就很适合。Corosync 可能还不是一个选项，因为它只支持 mcast 和 bcast，所以这将是一个起搏器+心跳的方案。
这里有一个关于如何使用 linode 实例进行操作的指南，其中大部分内容可能也与 EC2 相关：http://library.linode.com/linux-ha/
要回答这些部件是什么的问题，Pacemaker 是启动和停止服务的东西，它包含确保它们正在运行以及它们只在一个位置运行的逻辑（以避免数据损坏）。
但是，如果没有在其他节点上与自己对话的能力，它就无法做到这一点，这时心跳和/或 corosync 就派上用场了。
将心跳和 corosync 视为一条总线，任何节点都可以向其发送消息，并且知道所有对等节点都会收到这些消息。该总线还确保每个人都同意谁连接到总线（谁没有连接到总线），并在该列表发生变化时通知您。
对于两个节点，Pacemaker 可以轻松地使用套接字，但除此之外，复杂性会迅速增加，并且很难正确处理 - 因此使用已被证明可靠的现有组件确实很有意义。
答案2
我的直觉告诉我不，这些工具真的不适合用于 EC2 上的集群管理。我曾在独立硬件上使用过它们，发现只有具备非常具体的需求/故障情况，它们才真正有意义。我无法在脑海中想出一个用例，要求这些工具优于更具体的云监控系统和工具，例如在考虑平台的情况下开发的消息传递。
话虽如此，我不认为我的答案在这里具有权威性，我真的希望有人能对 ec2 云中的该工具集有更多的经验。
答案3
EC2 实例在管理方面与真实硬件非常相似。如果它发生故障，它就会发生故障（或者物理主机发生故障）。EC2 上没有固有的故障转移机制。您可以重新启动实例，它会“神奇地”重新出现，无需任何物理干预或维护，但您仍然必须手动或自动执行此操作（也许 EC2 会为您重新启动它，我不知道）。这可能意味着几分钟的中断。
如果您想要一个 HA 解决方案，它在恢复方面可能会更快，但您必须始终保持 2 个 EC2 实例处于运行状态。
但是 EC2 的理想架构是针对您需要的服务拥有多个实例，所有实例都并行运行并接受请求，并且如果一个实例崩溃了，其他实例将会弥补不足。