| 官方网址：http://linux-ha.org/wiki/Main_Page | ||
|
Hearbeat 简介 |
Hearbaet 一款开源高可用（Highly-Available）服务的软件，通过hearbeat, 可以将资源（ip及程序服务等资源）从一台已故障的计算机快速转移到另一台正常运转的机器上继续提供服务，一般称之为高可用服务。在实际成产应用场景中，heartbeat的功能和另一个高可用开源软件keeplived有很多相同之处，但在生产中，对应实际的业务应用也是有区别的，例如：keeplived主要是控制ip的漂移，配置、应用简单，而hearbeat则不但可以控制ip的漂移，更擅长对资源服务的控制（mysql的重启），配置，应用比较复杂。 | |
|
Heatbeat工作原理： keeplived和hearbeat高可用是操作系统级别的，不是（软件级别的），可以通过简单的脚本，实现软件级别的高可用。 |
hearbeat的主备模式 ，通过修改heatbeat软件的配置文件，可以指定那一台hearbeat服务器为主服务器，则另一台将自动成为热备服务器。然后再热备服务器上配置Hearbeat守护程序来监听自服务器的心跳信息。如果热备服务器在指定时间内未监听到来自主服务器的心跳，就会启动故障转移程序，并取得主服务器的相关资源服务的权限，接替主服务器继续不间断的提供服务，从而达到资源及服务高可用性的目的。 | |
| hearbeat还支持主主模式（可以针对不同的业务），及两台服务器互为主备，这时他们之间会相互发送报文来告诉对方自己的当前的状态，如果在指定的时间内未收到对方发送的心跳报文，那么一方就会认为对方实效或者宕机，这时美个运行正常的主机就会启动自身的资源接管模块来接管运行在对方主机上的资源或者服务，继续为用户提供服务。一般情况下，可以较好的实现一台主机故障后，企业服务仍能够不间断的持续运行。注意，所谓的业务不间断，在故障转移期间也是需要切换时间的（例如：停止数据库及存储服务等），hearbeat的主备高可用的切换时间一般是在5-20秒左右（服务器的宕机比人工切换服务快）。 | ||
|
高可用服务器切换 常见条件场景： |
1）、服务器物理宕机（硬件损坏，操作系统故障）。 此为主要解决目标！ 2）、hearbeat服务软件本身故障。 3）、两台主备服务器之间心跳连接故障。 服务故障不会导致切换。可以通过服务宕机把hearbeat服务宕掉。 |
|
|
Hearbeat心跳链接方法（至少需要两台主机来完成） |
1、利用串行电缆，即所谓的串口线连接两台服务器（可选）｜常用 |
串口线信号不会和以太网网络交集，也不需要单独配置ip地址等信息，因此传输稳定不容易出问题，使用串口的缺点时两个服务器之间距离不能太远。 串口线对应服务端的设备为／dev／ttyS0 |
| 2、一根以太网电缆两网卡直连（可选）｜常用 | 使用以太网网线（无需特殊的交叉线）直连网卡的方式，配置也比较简单，只需对这两块直连网线的网卡配置好独立的ip段地址能够互相通信即可，普通的网线就可以。 | |
| 3、以太网电缆，通过交换机等网络设备连接（次选） | 使用联网以太网线和网卡作为心跳线时次选方案，因为这个链路里增加了交换机设备这样的故障点，且这个线路不是专用心跳线路，容易受以太网其他数据传输的影响，导致心跳报文发送延迟活着无法送达问题。 | |
|
心跳选择方案： 提示：以上连接可同时使用，来加大保险系数防止裂脑问题发生。 |
1、和数据相关的业务，要求较高，可以串口和网线直连的方式并用。 | |
| 2、web、http业务，可以网线直连的方式或者局域网通信方式也可以。 | ||
|
Hearbeat 裂脑： （无法接收主备节点心跳，导致节点各自启动资源和服务） |
由于某些原因，导致两台高可用服务器之间在指定时间内，无法互相检测到对方心跳而各自启动故障转移功能，取得了资源及服务的所有权，而此时两台高可用服务器都还从活并正常运行，这样就会导致同一个ip或者服务在两端同时启动从而发生冲突的严重问题，最严重的是两台主机占用同一个vip地址，当用户写入数据时可能会分别写入到两端，导致服务器两端数据不一致或者造成数据丢失，这种情况称之为裂脑。 | |
|
裂脑发生原因总结： |
1、高可用服务器之间心跳链路故障，导致无法正常通信。（包括线路故障、网卡驱动损坏，ip配置冲突、冲裁机制等）｜常见 | |
| 2、高可用服务器开启iptables防火墙阻止心跳消息传输；｜常见 | ||
| 3、高可用服务器上心跳网卡地址信息配置不正确，导致发送心跳失败。｜常见 | ||
| 4、其他服务配置不当等原因，如心跳方式不同，心跳广播冲突、软件bug等； | ||
|
防止裂脑 方式总结 |
1、同时使用串行电缆和以太网电缆，同时使用两条心跳线。 常用 | |
|
2、当检测到裂脑时强行关闭心跳节点。 相当于程序上备节点发现心跳线故障，发送关机命令到主节点 （场景使用较少，银行使用较多，需要特殊设备支持，如stonith 杀死其它节点、fence） |
||
|
3、监控报警 （依赖报警） 方式1：探测备节点是否有vip，然后探测主服务是否有异常） （ 人工介入冲裁，对网站常规业务，例如百度报警监控上下行） 或者在报警在服务器接管之前，给人员处理留足够的时间。 |
||
|
4、启用磁盘锁。（使用较少） 即：正在服务的一方只在发现心跳全部断开时才启用磁盘锁，平时不上锁，此功能适用于共享场景；比如oracle |
||
|
5、增加仲裁机制 （仲裁一般是网关，不可能挂） |
当心跳全部断开时，两个节点各自ping参考ip，不通主动放弃竞争或自我重启，让通的一端接管服务。 | |
| 通过第三方软件仲裁获得资源 | ||
|
名词解释：fence |
1、fence是集群环境下的术语； 2、fence设备在硬件领域是智能电源管理设备； （俗称：智能电源管理设备或远程管理卡，带有以太网口，用来在ha切换触发时通过网络重启提供资源服务，在不知道就百度） |
|
|
名词解释：仲裁 |
在RHCS下有仲裁机制是有一个叫仲裁盘的东西，通过额外的存储实现，比如SAN , 通过mkqdisk 命令来制作的一个特殊块设备。默认情况在双节点的ha架构，主从服务器的投票数都是1，双方时平等的，当心跳有问题的时候就会发生裂脑。这个仲裁在RHCS可以设置投票数，节点双方使用ping网关的方式将自己的存活状态写入仲裁盘内，一旦节点心跳发生问题，并且仲裁盘没有收到节点存活信息，则启动fence关闭或重启故障节点 。 注意： 前提都是主备无法通信（心跳）的时候发生； 例如ping网关、主备和仲裁设备连接、由仲裁设备控制主备服务器电源 |
|
|
名词解释：stonith |
它是hearbeat软件包的一个组件，它允许使用一个远程或“智能的”连接到健康服务器的电源设备自动重启实效服务器的电源，sthonith设备可以关闭电源并响应软件命令，运行hearbeat的服务器可以通过串口线或网线向stonith设备发送命令，它控制高可用服务器对中其他服务器的电力供应。（理论上对服务器数量没有限制，但最好是两台）
|
|
心跳参考博文：http://blog.chinaunix.net/uid-7921481-id-1617030.html
|
Hearbeat消息类型： |
心跳消息 | 心跳消息为约150字节数据包，可能为串口，单播、广播或多播的方式，控制心跳频率及出现故障等待多久进行故障转移。 |
| 集群转换消息 |
ip_request和ip_request_resp 当主服务器恢复在线状态时，通过ip_requset 消息要求备机释放主服务器失败时报备服务器取得资源，；备服务器释放主服务器失败时取得的资源及服务后，通过ip_request——resp消息通知主服务器它不再拥有该资源及服务。 |
|
| 重传请求 | rexmit－request控制重传心跳请求（不重要） |
Heatbeat IP地址接管和故障转移：
Hearbeat是通过IP地址接管和arp广播进行故障转移的。
arp广播：在主服务器故障时，备用节点接管资源后，会立即强制更新所有客户端本地的arp表
（清除客户端本地缓存的失败服务器的vip地址和mac地址的解析纪录，确保客户端和新的主服务器对话）
vip / ip 别名／辅助别名ip
| 真实ip | 为物理网卡配置的实际ip，称为管理ip |
| 虚拟ip ／vip | 临时绑定在物理网卡上的ip |
配置vip的常见方法
| 别名ip alias IP |
ifconfig eth0:1 10.0.0.10 netmask 255.255.255.254 up 删除：ifconfig eth0:1 down 永久生效： 写成配置文件 ，这个别名ip 以后遗弃了，用辅助 |
| 辅助ip secondary ip address 注意！ |
添加：ip addr add 10.0.0.2/24 dev eth0 查看：ip a 删除： ip add del 10.0.0.2/24 dev eth0 |
注意：hearbeat 2.1.4 以前使用的是别名ip，hearbeat 2.1.4使用辅助ip，提供vip服务，但keeplived一直都是辅助ip提供服务。