除了典型的Heartbeat / Pacemaker / CoroSync组合以外，Linux上是否还有其他主要的自动故障转移替代方案？特别是，我正在EC2实例上设置故障转移，该实例仅支持单播-不支持多播或广播。我专门尝试处理我们拥有的几套软件，这些软件还没有自动故障转移功能，并且不支持多主机环境。这包括HAProxy和Solr之类的工具。
我有Heartbeat + Pacemaker，但是我对此并不感到兴奋。这是我的一些问题：
尽管Pacemaker的功能强大，但安装起来很困难，因此效果很好。Pacemaker的真正问题在于，没有简单的方法可以自动执行配置。我真的很想启动EC2实例，安装Chef / Puppet，并在没有我干预的情况下启动整个集群。
Answers:
我更喜欢使用keepalived来获得高可用性。我发现它比心跳和公司更容易设置（一个守护程序和一个配置）。我遇到的唯一缺点是，默认情况下keepalived没有单播选项，并且仅使用VRRP进行通信（但是HAProxy的作者为keepalived 编写了一个单播补丁）
我实际上正在从事与您所描述的（EC2上的故障转移群集）非常相似的事情，并且在尝试了Heartbeat之后，选择了Corosync作为我的消息传递层。从1.3.0版开始（从2010年11月开始），Corosync将在多台服务器上运行，并且确实支持单播（UDPU）。我已经在Amazon的EC2云上安装和测试了Corosync（使用Amazon的Linux AMI），并且可以确认它正常工作。
样本udpu文件已安装到/ etc / corosync。
在每个节点的接口部分添加一个成员块，并将传输指定为updu。（在下面的示例中，我使用了与心跳相同的端口，但是您可以根据需要更改它）。
例如：
totem {
version: 2
secauth: off
interface {
member {
memberaddr: 10.xxx.xxx.xxx
}
member {
memberaddr: 10.xxx.xxx.xxx
}
ringnumber: 0
bindnetaddr: 10.xxx.xxx.xxx
mcastport: 694
}
transport: udpu
}
（Heartbeat应该在1.2.3+版本中支持3个以上的节点群集，尽管我从来没有亲自尝试过，也不知道它是否可以与Unicast一起使用）。
抱歉，关于Pacemaker的部分不正确。Pacemaker回归和发布测试广泛使用了自动化。
要在没有活动集群的情况下进行配置，请为所有命令添加前缀CIB_file=/var/lib/heartbeat/crm/cib.xml或在您的环境中进行设置。只需确保在启动群集之前删除.sig文件即可。
对于没有仲裁的群集，大多数（如果不是全部）工具应支持，-f否则大多数工具--force都会指示群集接受更改。如果您找到了无法使用的工具-请提交错误。
在开源世界中，有RedHat Cluster Suite。自从我实施RHCS已经有好几年了，所以今天我没有太多要说的相关内容。
商业上有Veritas Cluster Server。没有经验。
UCARP是一个更简单且开源的HA工具。UCARP不能提供与Heartbeat / Pacemaker / CoroSync几乎相同的“基础结构”，但是您可以围绕它构建HA解决方案。
您还可以使用虚拟化技术构建高度可用的基础架构，但是这些解决方案往往侧重于主机级别的可用性，而不是应用程序级别的可用性。
如果您已经在使用EC2，为什么不使用Elastic Load Balancing？它可以让您实现应用程序级别的可用性，而不必自己配置故障转移。
我在posix shell中编写了一个故障转移群集管理器：https : //github.com/nackstein/back-to-work
看一下它，我正在寻找想要尝试并帮助开发的人。
opensvc（https://www.opensvc.com）支持多个心跳驱动程序：
并且在脑裂的情况下也具有法定机制。
我设法自动设置了一个由2个Google Cloud实例+ 2个具有Terraform + Ansible的Amazon实例组成的4节点群集。