如何做好容灾测试

概述：容灾，也是灾难恢复，是一个综合很多技术使用的一个系统性工程，对于容灾测试除了具备扎实的测试技能，同时也要有系统性的分析思维来拆解，将难度降低到一个个小小的场景和用例中去，以下做一些简单的介绍，只做抛砖引玉，最终还是要看具体的实践。

一、容灾概念理解：

1、灾难恢复概念（Disaster recovery，也称灾备），是指在相隔较远的异地，建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外(如火灾、地震等)停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。容灾技术是系统的高可用性技术的一个组成部分，容灾系统更加强调处理外界环境对系统的影响，特别是灾难性事件对整个IT节点的影响，提供节点级别的系统恢复功能。

2、容灾系统的类型：从对系统的保护程度来分，可以将容灾系统分为：数据容灾和应用容灾。

数据容灾就是指建立一个异地的数据系统，该系统是本地关键应用数据的一个实时复制。采用的主要技术是数据备份和数据复制技术，可以分为同步传输方式、半同步传输和异步传输方式。

应用容灾是在数据容灾的基础上，在异地建立一套完整的与本地生产系统相当的备份应用系统(可以是互为备份)，在灾难情况下，远程系统迅速接管业务运行。数据容灾是抗御灾难的保障，而应用容灾则是容灾系统建设的目标。主要的技术包括负载均衡、集群技术及对应的故障切换机制。

3、容灾系统的等级：参照国际灾难备份行业的通行灾难备份等级划分原则，根据异地数据的多寡，异地数据与生产数据的差异程度，以及灾难恢复环境的完备程度，将灾难备份系统从低到高划分为如下四个等级：

• 第0级：没有备援中心：这一级容灾备份，实际上没有灾难恢复能力，它只在本地进行数据备份，并且被备份的数据只在本地保存，没有送往异地。
• 第1级：本地磁带备份，异地保存：在本地将关键数据备份，然后送到异地保存。灾难发生后，按预定数据恢复程序恢复系统和数据。这种方案成本低、易于配置。但当数据量增大时，存在存储介质难管理的问题，并且当灾难发生时存在大量数据难以及时恢复的问题。为了解决此问题，灾难发生时，先恢复关键数据，后恢复非关键数据。
• 第2级：热备份站点备份：异地建立一个热备份点，通过网络进行数据备份。也就是通过网络以同步或异步方式，把主站点的数据备份到备份站点，备份站点一般只备份数据，不承担业务。当出现灾难时，备份站点接替主站点的业务，从而维护业务运行的连续性。
• 第3级：活动备援中心，在相隔较远的地方分别建立两个数据中心，它们都处于工作状态，并进行相互数据备份。当某个数据中心发生灾难时，另一个数据中心接替其工作任务。这种级别的备份根据实际要求和投入资金的多少，又可分为两种：①两个数据中心之间只限于关键数据的相互备份；②两个数据中心之间互为镜像，即零数据丢失等。零数据丢失是目前要求最高的一种容灾备份方式，它要求不管什么灾难发生，系统都能保证数据的安全。所以，它需要配置复杂的管理软件和专用的硬件设备，需要投资相对而言是最大的，但恢复速度也是最快的。
• 容灾系统的衡量指标

       RPO（Recovery Point Objective）：即数据恢复点目标，主要指的是业务系统所能容忍的数据丢失量。

       RTO（Recovery Time Objective）：即恢复时间目标，主要指的是所能容忍的业务停止服务的最长时间，也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。

        RPO针对的是数据丢失，而RTO针对的是服务丢失，二者没有必然的关联性。RTO和RPO的确定必须在进行风险分析和业务影响分析后根据不同的业务需求确定。对于不同企业的同一种业务，RTO和RPO的需求也会有所不同。

二、如何做容灾测试：

1、确认整体跨城架构，逐层分析交易数据流；

2、了解和分析跨城容灾触发的条件和步骤，分析跨城容灾步骤的合理性，从流程上分析是否存在哪些不足。

3、掌握跨城容灾的实现原理，逐层逐系统分析，哪些是做了容灾，哪些是没有做的（系统不同阶段，满足容灾的等级要求是不一样的，有些系统可能还是属于单点，但是一般要设计合理的应急措施），梳理测试风险点和关注点。

4、编写测试方案，方案包括：系统架构图、跨城切换步骤、测试计划（什么人、什么时间、负责什么内容，达到什么效果）、测试环境准备部署图、测试准备（对应工具及脚本开发、数据准备、数据依赖等）、测试策略（哪些要验证、哪些不验证、验证到什么程度）、测试关注点、风险点列表及应对措施等。

5、编写测试用例，重点对测试关注点、测试风险逐个扩展编写用例，主要关注点有如下一些要素：

• 模拟触发容灾切换的条件，一般触发容灾切换的要素：交易成功率下降到某个阈值、网络中断、服务异常（服务请求没反应，服务请求拒绝、进程假死等）、机器异常（硬件故障、CPU打满、内存耗尽、网络拥堵请求不可达等）。这些条件，系统要能监控到，并根据一定策略来触发容灾处理（成功率、请求数是否小于定义最小、对等set是否正常、仲裁计算是否满足切换条件）；
• 容灾切换一般做法：
  • 单机异常：从负载均衡策略中，摘除该机器（自动or人工or策略触发）、系统自动扩容、机器重启，如果是DB机器异常，做主备切换或者切换到其他备机，数据同步策略变化；
  • 机房级别异常：整个机房做切换或者触发同城切换，切换要看设计方案中涉及到具体网络部署和服务、数据库部署切换，需要结合实际部署来看。
  • 城市级异常：触发跨城切换，跨城切换会导致整个系统耗时增加、服务整体切换、跨城数据同步和后续数据回补，由于切换后节点减少，系统压力骤增，这个要逐个节点来考虑系统切换完备性及系统系统承受能力。
  • 切换层次：目前大部分系统是分层架构，比如分布式缓存、接入层、控制层、集成层、服务层、数据层、相关第三方依赖和关联系统。在分层架构下，为了减少跨城耗时，会做到条带化，即城市内的烟囱式条带化访问，同时增加跨城备份访问。为避免切换带来的业务连续性问题，切换不一定会触发整体切换，会实现层级切换，通过跨城访问来降低切换风险。比如A城数据库异常，如果A城做了数据跨城备（B城），那么上层服务层直接连到B城数据库即可。
  • 其他的容灾做法有：系统限流、业务降级、功能依赖切换等
• 容灾效果验证：容灾后，需要对容灾后的效果做验证，需要结合业务场景来验证，比如：
  • 切换前：切换前发起的订单未到终态，切换后，这些业务处理方式，是直接失败，还是会有补偿机制？这里又区分联机实时业务、批量业务、事务相关处理；
  • 切换中：切换过程会有个延时，多个系统切换不是瞬间完成的，这个瞬间的切换，测试时把过程拉长时间，以便验证每个切换步骤和系统的兼容性；
  • 切换后：需要验证切换后的业务连续性是否能保证，实时交易、批量交易、事务是否能正常处理；
  • 回切：系统恢复后，需要做回切处理，这个回切后业务连续性验证，回切前业务是否能正常处理，回切后业务数据流是否正常。
  • 数据回补验证：数据回补和校验逻辑验证，切换前业务交易，数据回补后是否能继续处理等，数据回补是有损还是无损，对应补偿机制及应对措施验证。
• 容灾演练配合：容灾系统建设之后，容灾演习就要变成常态化动作，需要在生产环境模拟触发容灾切换的场景，来模拟真实容灾切换，需要做的内容主要有以下几种：
  1. 灾难场景模拟：需要对场景做细分，比如交易成功率下降，这个可以通过对某台机器的网络端口进行网络限制或者协议层阻塞来模拟；网络丢包，也可以通过iptable来模拟。
  2. 触发场景后的业务验证：触发切换后，发起对应自动化业务用例，用例中需要对数据进行核对和检查，确保业务验证是否符合需求。

三、容灾测试的异常模拟方法：

•  使用iptbables直接模拟系统和某系统之间的网络不通：

sudo iptables -A OUTPUT -o eth0 -d <依赖系统的IP>  -j DROP

• 使用iptables直接模拟系统的某个端口不通

sudo iptables -A OUTPUT -o eth0 -p tcp  --dport <端口号> -j DROP

•  清除所有设置的iptables规则：iptables –F
• 查看当前设置的所有iptables规则：iptables –L
• 模拟应用变慢和超时：添加对某个依赖系统的流量控制，下面的命令需要按照顺序执行。
• 使用ifconfig查看默认的网卡信息，一般默认为eth0
•  使用tc流量控制命令对eth0网口过来的数据包添加一个排列规则，延迟1000ms 

         sudo tc qdisc add dev eth0 root handle 1: prio

          sudo tc qdisc add dev eth0 parent 1:3 handle 30: tbf rate 20kbit buffer 1600 limit  3000

           sudo tc qdisc add dev eth0 parent 30:1 handle 31: netem delay 1000ms 10ms distribution normal

• 添加从某ip过来的流控规则(替换**.**.**.**为需要流控的ip)

        sudo tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst **.**.**.**/32 flowid 1:3

• 查看已经设置的限流规则: sudo tc filter list dev eth0 parent 1:0
•         删除已经设置的所有的限流规则: sudo tc filter del dev eth0 parent 1:0 prio 3 u32

• 删除已经设置的从某ip过来的流控规则（直接替换添加流控规则命令中的add为del即可）：

               sudo tc filter del dev eth0 protocol ip parent 1:0 prio 3 u32 match ip dst **.**.**.**/32 flowid 1:3