heartbeat(尽量保持唯一性存储)和keepalived (尽量保持可用)区别

http://www.formilux.org/archives/haproxy/1003/3259.html

无论如何，我想说，我对使用心跳获得冗余的haproxy设置的人数感到惊讶。它不是* this *工作的最佳工具，它被设计为构建集群，这与拥有两个冗余无状态网络设备有很大的不同。面向网络的工具（如keepalived或ucarp）是最适合该任务的工具。

这两个家庭之间的区别很简单：

诸如心跳之类的面向簇的产品将确保共享资源最多存在于*一个位置。这对于共享文件系统，磁盘等非常重要。它被设计为在切换期间在一个节点上运行服务，另一个节点上运行服务。这样，共享资源可能永远不会被同时访问。这是一项非常艰巨的任务，而且它做得很好。
一个面向网络的产品（如keepalived）将确保共享的IP地址至少在*一个地方出现。请注意，我不是在谈论一个服务或资源，它只是播放IP地址。它不会尝试降低或升级任何服务，它只会考虑一定数量的标准来决定哪个节点最适合提供服务。但服务必须已经在两个节点上。因此，它非常适用于冗余路由器，防火墙和代理，但对于磁盘阵列或文件系统而言都不是这样。

在发生肮脏的故障（如分裂脑）的情况下，差异是非常明显的。基于群集的产品很可能最终没有提供服务的节点，以确保共享资源不会被并发访问损坏。面向网络的产品最终可能会出现在两个节点上，从而导致两者都可以使用该服务。(phil 注:既然是无状态的,那么为什么不让客户端来进行负载均衡呢,直接提供两个 ip. 但有时候就是提供一个,简化客户端逻辑.) 这就是为什么你不想使用ucarp或keepalived从共享阵列提供文件系统的原因。

控制和更改的性质也会对切换时间和离线测试服务的能力产生影响。例如，通过keepalived，如果发生脏故障，可以在短时间内将IP从一个节点切换到另一个节点，或者在志愿者切换的情况下为零延迟，因为不需要启动

Anyway, I’d like to say that I’m amazed by the number of people who use heartbeat to get a redundant haproxy setup. It is not the best tool for this job, it was designed to build clusters, which is a lot different from having two redundant stateless network equipments. Network oriented tools such as keepalived or ucarp are the best suited for that task.

The difference between those two families is simple :

a cluster-oriented product such as heartbeat will ensure that a shared resource will be present at *at most* one place. This is very important for shared filesystems, disks, etc... It is designed to take a service down on one node and up on another one during a switchover. That way, the shared resource may never be concurrently accessed. This is a very hard task to accomplish and it does it well.
a network-oriented product such as keepalived will ensure that a shared IP address will be present at *at least* one place. Please note that I'm not talking about a service or resource anymore, it just plays with IP addresses. It will not try to down or up any service, it will just consider a certain number of criteria to decide which node is the most suited to offer the service. But the service must already be up on both nodes. As such, it is very well suited for redundant routers, firewalls and proxies, but not at all for disk arrays nor filesystems. 

The difference is very visible in case of a dirty failure such as a split brain. A cluster-based product may very well end up with none of the nodes offering the service, to ensure that the shared resource is never corrupted by concurrent accesses. A network-oriented product may end up with the IP present on both nodes, resulting in the service being available on both of them. This is the reason why you don’t want to serve file-systems from shared arrays with ucarp or keepalived.

The nature of the controls and changes also has an impact on the switch time and the ability to test the service offline. For instance, with keepalived, you can switch the IP from one node to another one in just one second in case of a dirty failure, or in zero delay in case of volunteer switch, because there is no need to start/stop anything. That also means that even if you’re experiencing flapping, it’s not a problem because even if the IP constantly moves, it moves between places where the service is offered. And since the service is permanently available on the backup nodes, you can test your configs there without impacting the master node.

So in short, I would not like to have my router/firewall/load balancer running on heartbeat, as well as I would not like to have my fileserver/ disk storage/database run on keepalived.

With keepalived, your setup above is trivial. Just configure two interfaces with their shared IP addresses, enumerate the interfaces you want to track, declare scripts to check the services if you want and that’s all. If any interface fails or if haproxy dies, the IP immediately switches to the other node. If both nodes lose the same interface (eg: shared switch failure), you still have part of the service running on one of the nodes on the other interface.

Hoping this helps understanding the different types of architectures one might encounter,

Willy