什么是高可用性集群系统

通常，可用性采用“每年故障时间”进行衡量。常规的容错系统可以达到 99.99% 的可靠度，即相当于每年故障 1 小时 ( 每天故障 10 秒钟 )。但高可用性系统则有望达到 99.999% 的业务时间内系统可靠的运行，即每天故障 1 秒钟。这意味着当故障出现时，系统必须能自动处理 ，无需人为干预即可管理故障检测和纠错。因为操作人员难以在很短的时间内移除或掩盖任何故障。

高可用性集群系统是基于两个或两个以上节点的环境，用于合作处理同一任务的系统。在系统中某一节点出现故障时，集群服务器会自动把某些资源转移到其它节点，使得客户机可以继续访问这些资源，以达到提供不间断服务的目的，用以提高系统的稳定性、可靠性等。

高可用性集群系统支持多种操作系统平台，本文着重介绍在 Linux 上高可用性集群系统测试的最佳实践。

在 Linux 集群系统中实现对高可用性支持的常用方法

并不是所有的 Linux 集群系统都具有高可用性的功能，这需要提供额外的设计来支持。高可用性解决方案用于监控系统和应用程序服务，并在硬件或软件出现故障时重新启动这些服务。通常，可通过增加冗余硬件或软件的方式来实现。下面介绍几种常用的实现高可用性支持的方法，以便针对这些常用方法来进行自动化测试的最佳实践。

多机就绪模式

所谓多机，即集群中的多台机器都是主服务器，共享文件系统，各自运行着一些服务。以包含两个主服务器节点的环境为例，在这两个主服务器节点上，安装着完全相同的软件且共享文件系统。主服务器节点 node1 和 node2 的 CNFS 服务分别在两个节点上各自运行着。可以在 Linux 的命令行利用 ifconfig 命令查看 CNFS IP：

由上面的输出我们可以看到，主服务器节点 node1 上的 CNFS 服务可以通过 9.11.124.11 从客户端访问，node2 上的 CNFS 服务可以通过 9.11.124.12 从客户端访问。用户在客户机上可以通过任一 CNFS IP 对该 Linux 集群环境上的文件系统进行访问，效果是一样的。例如，在名为 client 的客户机上通过 CNFS IP 访问共享文件系统 /collection/data 目录的操作如下：

在系统不出现故障的情况下，两个 CNFS 服务各自独立的运行着。但这两台服务器又同时监控着对方的健康状况，如果 node1 出现了问题，node2 就会接管 node1 上的 CNFS 服务。此时，在 node2 上会同时运行着两个 CNFS 服务。以至于保证正在通过 9.11.124.11 访问 /collection/data 目录的用户感觉不到 node1 出现了问题。在 node2 上可通过 ifconfig 命令查看到有两个 CNFS IP:

如果 node2 出现了问题，node1 也会接管 node2 上的 cNFS 服务。因此，这种多机就绪、互为冗余的模式可以很好的利用健康节点来接管问题节点上的资源，使得客户机可以继续访问这些资源，从而感觉不到节点出现故障，以此达到系统高可用性的目的。

利用 Linux 中的 bonding 技术配置冗余网络

Linux 下的 bonding 技术，将多块网卡接口通过绑定虚拟成为一块网卡，在用户看来这个聚合起来的设备好像是一个单独的以太网接口设备，或者说就是多块网卡具有相同的 IP 地址而并行连接聚合成一个逻辑链路工作。

Bonding 技术用于高可靠性，提供最大网络可靠性的配置，通过在主机和其他设备间的冗余或备份设备、链路或交换机，目标是提供最大的网络链接可靠性（要求网络一直可用）。

以每个节点上面有四个网卡接口 (eth10,eth11,eth12,eth13) 为例，它们可被虚拟成两个绑定设备：bond0 和 bond1。bond0 为外部网卡 , 被绑定的网卡接口（也称为 slave 设备）是 eth10 和 eth12；bond1 为内部网卡，被绑定的网卡接口是 eth11 和 eth13。其中 bond0 用于外部通信，bond1 用于节点之间通信。其网络结构如图所示：

绑定配置

绑定设备 bond0 和 bond1 分别对应配置信息文件 /proc/net/bonding/bond0 和 /proc/net/bonding/bond1。以 /proc/net/bonding/bond0 为例，其内容如下：

其中，包含 bonding 设备和 slave 设备的配置信息。Bonding Mode 是绑定的策略或模式，可用于优化可靠性的绑定模式有 fault-tolerance( 或者称为 active-backup) 和 broadcast 模式，fault-tolerance 通常是推荐的模式，尤其是如果交换机间存在 ISL 并能一起很好的工作。如果一个交换机被配置为备份交换机 ( 比如，有更低的处理能力，更高的费用等等 )，则可以使用 primary 选项来保证期望的链路在它可用时总是用它。

Primary Slave 指定哪个 slave 成为主设备 (primary device)，取值为字符串，如 eth0，eth1 等。只要指定的设备可用，它将一直是激活的 slave。只有在主设备（primary device）断线时才会切换设备。这在希望某个 slave 设备优先使用的情形下很有用，比如，某个 slave 设备有更高的吞吐率。

Currently Active Slave 为当前被激活的 slave 设备。bond0 设备有两个 slave 设备：eth10 和 eth12。当前被激活的 slave 设备是 eth10。

MII Status 为 MII 监控状态。MII 监控通过监控本地网络接口的载波状态来实现监控链路状态。可以通过 3 种方法之一来实现：通过依赖设备驱动来维护载波状态；通过查询设备的 MII 寄存器；或者通过给设备发送 ethtool 查询。

MII Polling Interval 指定 MII 链路监控频率，这将决定驱动检查每个 slave 链路状态频率，100 为初始参考值。

Up Delay 指定当发现一个链路恢复时，在激活该链路之前的等待时间。

Down Delay 指定一个时间，用于在发现链路故障后，等待一段时间然后禁止一个 slave 设备。

网络配置

网络配置可以通过 ifconfig 命令查看，Bonding 设备会被标上 MASTER 标记，slave 设备会被标上 SLAVE 标记。ifconfig 的输出不包含哪个 slave 设备关联于哪个 Bonding 设备的关系。

可以看到 bond0 接口是 master（MASTER），而 eth10 和 eth12 是 slave（SLAVE），所有 bond0 的 slave 和 bond0 有着同样的 MAC 地址 (00:21:5E:09:61:06)。Bond1 接口是 master(MASTER)，而 eth11 和 eth13 是 slave（SLAVE），所有 bond1 的 slave 和 bond1 有着同样的 MAC 地址 (00:21:5E:09:61:04)。

综上，冗余的网络结构可以保证在某节点出现故障或网卡出现问题时，网络一直可用。

安装远程管理卡 (RSA Card)

远程管理卡提供警告和远程监控等功能。它本身并不会实现高可用性功能，而是利用其远程监控功能，用以恢复不健康节点。

远程管理卡需要被安装在被管理服务器空的 PCI 插槽中，然后在 BIOS 里做相应的配置。以 IBM RSA II 为例来进行配置说明：

• 重启机器，按”F1”进入 BIOS 设置；
• 选择“Advanced Steup”->“RSA II Settings”：
  
  图 2. RSA II Settings 界面
  
  
  
• 在“RSA II Settings”页面，选择用静态 IP 的方式，填入你想分配给该远程管理卡的 IP 地址、子网掩码和网关等信息。
• 填写完后选择“Save Values and Reboot RSA II”退出配置并使其生效。
• 编辑 /etc/hosts 文件，加入远程管理卡的 IP 地址。

配好了远程管理卡对应的 IP 地址后，就可以通过网页或 telnet 方式在 Linux 集群环境中任一机器上访问该远程管理卡了。

• 网页方式：

  打开浏览器，在地址栏里输入要连接的远程管理卡的 IP 地址。RSA II 的 http 访问端口默认为 80，所以在地址栏中可不输入端口直接访问。输入用户名和密码，默认值为 USERID 和 PASSW0RD：
  

  图 3. 连接远程管理卡的安全验证窗口
  
  
  

  登陆后的管理台页面如下：
  

  图 4. 远程管理卡的图形化管理界面
  
  
  

  可点击左侧导航条中“Tasks”下面的各链接对该机器进行远程操作。
  

• telnet 方式：
  node1:~ # telnet 9.11.125.243
  Trying 9.11.125.243...
  Connected to 9.11.125.243.
  Escape character is '^]'.
  username: USERID
  password: ********
  SN# K106086T2NC>
  

  
  

  根据不同需求，执行如下常用命令可以完成远程操作：
  

  power cycle -s: 重启
  

  power cycle: 马上重启
  

  power off -s: 关闭机器
  

  power off: 马上关闭机器
  

  power state: 查看 RSA 卡的状态
  

  reset -s: 软重启
  

  reset： 马上软重启
  

  power off: 马上关闭机器
  

  power on: 启动机器
  

  例如：SN# K106086T2NC>reset
  

  该服务器将被重启。
  

增加冗余监控进程

在“多机就绪模式”中我们曾提到健康节点会识别出问题节点，从而接管问题节点上的服务。但如何识别出问题节点呢？这就需要在每个节点上都增加一个监控进程，它的作用就是每隔一段时间去检查邻节点的健康状况。例如一个包含三个节点的 Linux 集群环境，节点 A 上监控进程检查结点 B 的健康状况，节点 B 上的监控进程检查节点 C 的健康状况 , 节点 C 上的监控进程检查节点 A 的健康状况。如下图所示：

当发现出现问题时，会修复问题结点。所谓修复问题结点，包括如下一些操作：

• 重启问题结点：

  通过远程管理卡，重启机器以到达恢复此节点的目的。
  

• 转移问题结点上运行的一些应用或资源（如 CNFS）到健康的节点：

  为了用户对于问题节点上运行的一些服务能够在节点被重启的过程中还可用，需要在问题节点不可获得的时间里，把这些服务转移到其他节点上。以至于用户感觉不到问题节点的存在，可继续访问这些服务。
  

• 在节点恢复健康后，把原来运行在它上面的应用或资源转移回去。

另外，监控进程本身需具有自动修复功能。当监控进程由于某些原因被停掉后，它可自动被重启以保持正常运行。

判断节点健康的标准有：

• 该节点是否可 ping 通；
• 该节点是否可通过 SSH 访问；
• watchdog 的监控进程是否运行着；

其中任一条不满足，我们都认为该节点不健康。

利用错误注入策略进行高可用性测试

高可用性测试的方法有很多，比如可通过手工方式拔掉网线、重启机器等，也可通过自动的错误注入策略，把破坏系统健康的操作写到脚本中。结合上一章节中提到的实现高可用性的常用方法，下面主要讲解在实现了这些方法的 Linux 集群环境中如何利用自动错误注入策略来进行自动化的高可用性测试。

所谓自动错误注入策略，就是利用关闭某个节点或杀掉监控进程来模拟机器故障，以此触发系统实施切换功能。根据上面提到的几种判断节点是否健康的标准，我们可以采用如下几种方法模拟节点不健康情况的发生：

• 杀掉监控进程；
• 执行"power cycle"命令，让节点重启；
• 执行"reset -s" 命令，让节点首先关闭所有进程然后重启；

下面以“杀掉监控进程”来模拟机器故障为例 , 分为俩部分来详细讲解如何进行高可用性测试，同时配以 Perl 语句说明如何实现相应操作：

Failover 的过程

检查应用（资源）是否能够在节点失效后被转移到其他节点。通常我们称这个过程为 Failover。

去掉监控进程的执行权限：

由于监控进程具有自我修复能力，能够在停掉后自动重启，因此在采用“杀掉监控进程”这种方式来模拟机器故障前，需要把监控进程的执行权限去掉。我们假设监控进程名为 watchdog, 便于在命令中进行说明：

杀掉监控进程：

得到监控进程的进程 ID，然后杀掉，以此来模拟机器不健康状况的发生：

邻结点检测并重启该不健康节点：

根据上面提到的判断节点健康的标准，可以采用如下对应的方法进行检测：

• 该节点是否可 ping 通：/bin/ping -c 3 <IP>
• 该节点是否可通过 SSH 访问 : /usr/bin/ssh -l root <IP>
• 监控进程是否运行着 : ps – ef|grep watchdog

在以上任一条件不满足时，即认为该节点不健康。本例中我们采用的是杀掉监控进程致使不满足第三点。在检测出监控进程没有运行时，首先会执行启动监控进程的命令去自我修复，而不是马上重启机器。但由于我们在之前的步骤中已经去掉了监控进程的执行权限，因此在系统尝试几次重启监控进程失败后，就会重启该节点。重启的方法是采用 RSA 卡进行 powercycle, 实现的语句如下：

检查应用（资源）是否能够在节点失效后被转移到其他节点：

本例中被转移的资源为 CNFS IP，在不健康节点被重启后， 运行在其上面的 CNFS IP 不会马上切换到别的节点。需要等待一段时间后，才会由集群中的其它节点进行接管。至于由集群中的哪个节点来接管，是随机的，所以需要在每个健康节点上进行判断。

判断它是否被成功转移到其他节点可通过如下方法实现：

Failback 的过程

在修复好后，检查这些应用（资源）是否能再迁移回原先运行的节点。通常我们称这个过程为 Failback。

检查问题节点是否重启成功：

可通过是否能 ping 的方式检查：

恢复监控进程的执行权限：

前面的过程中我们曾经去掉了监控进程的执行权限，目的是不让监控进程在停掉后自动重启，用以模拟机器故障，以此触发系统实施切换功能。现在在问题节点被修复后，需要恢复监控进程的执行权限。以便在节点重启后，该进程也能够被自动重启。

检查监控进程是否能够自动重启成功：

检查产品需要的其它进程是否恢复运行：

不同的产品有不同产品进程需要在节点被修复好后保持正常运行。这也是判断高可用性产品是否成功的重要标准之一。下面仅用一个通用的程序框架来实现检验各进程是否恢复运行：

检查应用（资源）是否能再迁移回原先运行的节点：

以被转移走的 CNFS IP 为例，在原来的问题节点上执行：

若返回值不为空，说明被转移走的 cNFS IP 在该节点被修复好了又迁移回来了。

结束语

高可用性测试，作为系统测试中一个很重要的测试类型，用来确保产品可以提供不间断的服务。测试高可用性的方法有很多，即可手工也可自动。为了提高测试效率，如何根据产品自身对高可用性支持的实现方法进行自动化测试是十分重要的。本文就是基于一些常见的高可用性支持的实现方法，通过自动错误注入策略来把破坏系统健康的操作写到脚本中，以此实现高可用测试的自动化。需要注意的是，该脚本并不适用于所以产品的高可用性测试，本文只是提供了一个理念，还需要读者结合实际产品情况，结合您系统采用的高可用性实现方法，对该脚本进行修改。