双机热备高可用方案heartbeat与keepalived

高可用方案+heartbeat与keepalived

1.nginx-(tomcat1,tomcat2)

当nginx挂掉之后 一切都无法进行

方案 热备 nginx_master nginx_slave(backup)+(heartbeat与orkeepalived)

2.heartbeat与keepalived选型

Keepalived使用的vrrp协议方式，虚拟路由冗余协议 (Virtual Router Redundancy Protocol，简称VRRP)；
Heartbeat是基于主机或网络的服务的高可用方式；
keepalived的目的是模拟路由器的双机
heartbeat的目的是用户service的双机
lvs的高可用建议用keepavlived
业务的高可用建议heartbeat

 

两款高可用开源方案：Keepalived和Heartbeat。两者都很流行，但差异还是很大的，现将试用过程中的感受以及相关知识点简单总结一下，供大家选择方案的时候参考。

1）Keepalived使用更简单：从安装、配置、使用、维护等角度上对比，Keepalived都比Heartbeat要简单得多，尤其是Heartbeat
2.1.4后拆分成3个子项目，安装、配置、使用都比较复杂，尤其是出问题的时候，都不知道具体是哪个子系统出问题了；而Keepalived只有1个安装文件、1个配置文件，配置文件也简单很多；

2）Heartbeat功能更强大：Heartbeat虽然复杂，但功能更强大，配套工具更全，适合做大型集群管理，而Keepalived主要用于集群倒换，基本没有管理功能；

3）协议不同：Keepalived使用VRRP协议进行通信和选举，Heartbeat使用心跳进行通信和选举；Heartbeat除了走网络外，还可以通过串口通信，貌似更可靠；

4）使用方式基本类似：如果要基于两者设计高可用方案，最终都要根据业务需要写自定义的脚本，Keepalived的脚本没有任何约束，随便怎么写都可以；Heartbeat的脚本有约束，即要支持service
start/stop/restart这种方式，而且Heartbeart提供了很多默认脚本，简单的绑定ip，启动apache等操作都已经有了；

 

使用建议：优先使用Keepalived，当Keepalived不够用的时候才选择Heartbeat

Keepalived使用的vrrp协议方式，虚拟路由冗余协议 (Virtual Router Redundancy Protocol，简称VRRP)；
Heartbeat是基于主机或网络的服务的高可用方式；
keepalived的目的是模拟路由器的双机
heartbeat的目的是用户service的双机
lvs的高可用建议用keepavlived
业务的高可用用heartbeat

keepavlived
lvs_sync_daemon_inteface。负载均衡器之间的监控接口，类似于 HA HeartBeat的心跳线。但它的机制优于 Heartbeat，因为它没有“裂脑”这个问题，它是以优先级这个机制来规避这个麻烦的。在 DR 模式中，lvs_sync_daemon_inteface  与服务接口 interface  使用同一个网络接口。

Heartbeat
运行于备用主机上的Heartbeat可以通过以太网连接检测主服务器的运行状态，一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。通常情况下，主、备服务器间的心跳连接是一个独立的物理连接，这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态，而其只要能通过其中一个连接收到主服务器处于活动状态的信息，就会认为主服务器处于正常状态。从实践经验的角度来说，建议为Heartbeat配置多条独立的物理连接，以避免Heartbeat通信线路本身存在单点故障。
1、串行电缆：被认为是比以太网连接安全性稍好些的连接方式，因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序，从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度，因此主、备服务器的距离必须非常短。
2、以太网连接：使用此方式可以消除串行线缆的在长度方面限制，并且可以通过此连接在主备服务器间同步文件系统，从而减少了从正常通信连接带宽的占用。
基于冗余的角度考虑，应该在主、备服务器使用两个物理连接传输heartbeat的控制信息；这样可以避免在一个网络或线缆故障时导致两个节点同时认为自已是唯一处于活动状态的服务器从而出现争用资源的情况，这种争用资源的场景即是所谓的“脑裂”（split-brain）或“partitioned cluster”。在两个节点共享同一个物理设备资源的情况下，脑裂会产生相当可怕的后果。
为了避免出现脑裂，可采用下面的预防措施：
1、如前所述，在主、备节点间建立一个冗余的、可靠的物理连接来同时传送控制信息；
2、如前所述，在主、备节点间建立一个冗余的、可靠的物理连接来同时传送控制信息；
3、一旦发生脑裂时，借助额外设备强制性地关闭其中一个节点；
第二种方式即是俗称的“将其它节点‘爆头’（shoot the other node in the head）”，简称为STONITH。基于能够通过软件指令关闭某节点特殊的硬件设备，Heartbeat即可实现可配置的Stonith。但当主、备服务器是基于WAN进行通信时，则很难避免“脑裂”情景的出现。因此，当构建异地“容灾”的应用时，应尽量避免主、备节点共享物理资源。
Heartbeat的控制信息：
“心跳”信息: （也称为状态信息）仅150 bytes大小的广播、组播或多播数据包。可为以每个节点配置其向其它节点通报“心跳”信息的频率，以及其它节点上的heartbeat进程为了确认主节点出节点出现了运行等错误之前的等待时间。
集群变动事务（transition）信息：ip-request和ip-request-rest是相对较常见的两种集群变动信息，它们在节点间需要进行资源迁移时为不同节点上heartbeat进程间会话传递信息。比如，当修复了主节点并且使其重新“上线”后，主节点会使用ip-request要求备用节点释放其此前从因主节点故障而从主节点那里接管的资源。此时，备用节点则关闭服务并使用ip-request-resp通知主节点其已经不再占用此前接管的资源。主接点收到ip-request-resp后就会重新启动服务。
重传请求：在某集群节点发现其从其它节点接收到的heartbeat控制信息“失序”（heartbeat进程使用序列号来确保数据包在传输过程中没有被丢弃或出现错误）时，会要求对方重新传送此控制信息。 Heartbeat一般每一秒发送一次重传请求，以避免洪泛。
上面三种控制信息均基于UDP协议进行传送，可以在/etc/ha.d/ha.cf中指定其使用的UDP端口或者多播地址（使用以太网连接的情况下）。
此外，除了使用“序列号/确认”机制来确保控制信息的可靠传输外，Heartbeat还会使用MD5或SHA1为每个数据包进行签名以确保传输中的控制信息的安全性。
资源脚本（resource scripts）即Heartbeat控制下的脚本。这些脚本可以添加或移除IP别名（IP alias)或从属IP地址（secondary IP address），或者包含了可以启动/停止服务能力之外数据包的处理功能等。通常，Heartbeat会到/etc/init.d/或/etc/ha.d/resource.d/目录中读取脚本文件。Heartbeat需要一直明确了解“资源”归哪个节点拥