1 介绍
为提高CMS服务器提供成熟的高可用(故障切换)能力，需要对其进行双机主从备份，这样当一台机器出现故障（死掉或者该机器上的CMS服务死掉）时，能够快速的切换到另外一台机器上来；
2 典型应用组网
![]()
图1 典型应用组网 – 基于心跳和集中数据库的双机热备
基于串口，UDP和PPP/UDP的心跳信号传输。两个主备CMS后台共用一个数据库（数据库虽然自身也是主备两台，但对于CMS可见的是一台虚拟
出的固定的数据库服务器），通过串口线或者网线传输的心跳信号判别对方的状态，进而来启动或停止自身服务。其中还可以添加一些硬件以应对更复杂的情况，如
电子开关(power
switch)，它可以用来防止心跳故障产生的裂脑现象；又如硬件看门狗，它可以在服务器故障时重启操作系统。而对于各个前端和用户端设备而言，它们注册
到处于active状态的主服务器上，进行业务。
3 相关技术说明
能够实现主从备份的软件有很多，目前也没有确定使用哪一种软件，但它们的共性是使用对终端设备提供一个虚拟IP地址来供访问，主从之间使用心跳机制来保活。
4 CMS主从备份原理
首先，整个主备系统需要设置心跳物理链接，以获得高可用性（HA），因此需要避免单点失效。需要在主从机器上配置两条（包括）以上的物理链接，可以
是串口线和网卡（NIC）/
交叉线，这样能够保证在一条物理链接出现问题的情况下，还有另外一条物理链接可用，有两种介质类型传输heartbeat信号比较好。
在连接好心跳线后，需要配置好心跳鉴权密码，因为为保证安全性，心跳消息是需要鉴权密码的，如果使用串口线和网卡交叉线的话，则可以不配置鉴权密码；
为了保证平台对于前端与客户端而言是不变的，需要生成一个固定的虚拟IP：首先确定主服务器，主服务器确定后就在主服务器上生成供终端和客户端访问
的IP地址，该地址的生存周期是该服务器确定为主服务器期间，当确定了新的主服务器后，会去除原来主服务器上的的虚拟IP地址，在新的主服务器上生成该虚
拟IP地址。
下面进行异常处理配置，设定心跳保活时间和判断服务器死掉的时间：可以精确到毫秒，这样当主服务器在在设定的时间内没有向从服务器发送心跳消息后，从服务器就会将其标识为主服务器，开始广播虚拟IP地址，接收终端和客户端的请求；
上面大致就构建好了主从环境，下面应针对具体情况设置主从切换的条件---从服务器收不到主服务器的心跳消息时进行切换，或者判断某个特定的服务死掉时即进行切换，或者在某个设定特殊时间点（比如晚上或周末）；
在整个过程中应该注意：在使用ping节点之前，最好检查他们的可用性。如果不能从所有的HA节点上ping通该ping节点，便不能使用它。
对于我们的系统，主从备份服务是一个高可用(故障切换)框架，我们的CMS服务器作为一个服务在这个框架下运行，通过该服务我们并不能够实现主从
CMS之间无缝的平移，而是保证了在主服务死掉后较短的时间内从服务器接管，如果需要实现热备，还需要CMS和终端及客户端作进一步的处理，此处就不讨论
这个问题了。
5 配置举例
![]()
图2 配置说明
两台CMS服务器都各自备有两块以上的网卡：一块配置心跳，一块用于实际应用，分别配不同网段地址。
如上图所示，CMS的112网段的ip地址用于心跳，通过串口线相连；71网段的地址接受业务。心跳服务先启动，侦测两台服务器状态；如果两台服务
器都可用，就将它们作为两个节点，并让它们知道对方的存在。HA软件将虚地址资源分配给CMS1，让这个虚地址的某些端口接收CMS1服务的各种业务，这
时的CMS1就是active状态；如果CMS1服务器出现问题，比如服务器宕机，心跳服务会侦测到，然后它会告知CMS2，CMS1出现问题；然后HA
软件将虚地址资源从CMS1收回，将它再分配给CMS2；从而CMS2的服务接替起CMS1上所有业务，变为active状态。如果CMS1排除故障后又
变为可用，心跳服务侦测到后，会将它重新作为一个节点，并通知CMS2，这样当CMS2出现故障后，CMS1便可接替。
对于外部设备而言，相当于只见到一个具有不变地址的CMS服务器，CMS的主从备份对于它们而言是透明的。
=====================================================================
#何谓"脑裂"?
在“双机热备”高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作
协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障，2个节点上的HA软件像“裂脑人”一样，“本能”地争抢“共享资
源”、争起“应用服务”，就会发生严重后果：或者共享资源被瓜分、2边“服务”都起不来了；或者2边“服务”都起来了，但同时读写“共享存储”，导致数据
损坏（常见如数据库轮询着的联机日志出错）。
对付HA系统“裂脑”的对策，目前有以下几条：
1）添加冗余的心跳线，例如双线条线。尽量减少“裂脑”发生机会。
2）启用磁盘锁。正在服务一方锁住共享磁盘，“裂脑”发生时，让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共
享盘的一方不主动“解锁”，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用
服务。于是有人在HA中设计了“智能”锁。即，正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。
3）设置仲裁机制。例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下 参考IP，不通则表明断点就出在本端，
不仅“心跳”、还兼对外“服务”的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。
#何谓"看门狗"(watchdog)?
Watchdog在实现上可以是硬件电路也可以是软件定时器，能够在系统出现故障时自动重新启动系统。在Linux 内核下,
watchdog的基本工作原理是：当watchdog启动后(即/dev/watchdog
设备被打开后)，如果在某一设定的时间间隔内/dev/watchdog没有被执行写操作, 硬件watchdog电路或软件定时器就会重新启动系统。
/dev/watchdog 是一个主设备号为10， 从设备号130的字符设备节点。
Linux内核不仅为各种不同类型的watchdog硬件电路提供了驱动，还提供了一个基于定时器的纯软件watchdog驱动。
驱动源码位于内核源码树drivers\char\watchdog\目录下。
硬件watchdog必须有硬件电路支持, 设备节点/dev/watchdog对应着真实的物理设备，
不同类型的硬件watchdog设备由相应的硬件驱动管理。软件watchdog由一内核模块softdog.ko
通过定时器机制实现，/dev/watchdog并不对应着真实的物理设备，只是为应用提供了一个与操作硬件watchdog相同的接口。
硬件watchdog比软件watchdog有更好的可靠性。
软件watchdog基于内核的定时器实现，当内核或中断出现异常时，软件watchdog将会失效。而硬件watchdog由自身的硬件电路控制,
独立于内核。无论当前系统状态如何，硬件watchdog在设定的时间间隔内没有被执行写操作，仍会重新启动系统。
一些硬件watchdog卡如WDT501P 以及一些Berkshire卡还可以监测系统温度，提供了 /dev/temperature接口。
对于应用程序而言, 操作软件、硬件watchdog的方式基本相同：打开设备/dev/watchdog,
在重启时间间隔内对/dev/watchdog执行写操作。即软件、硬件watchdog对应用程序而言基本是透明的。
在任一时刻， 只能有一个watchdog驱动模块被加载，管理/dev/watchdog 设备节点。如果系统没有硬件watchdog电路，可以加载软件watchdog驱动softdog.ko。
