作者： 数据源的 TiDB 学习之路原文来源：https://tidb.net/blog/d4b34403
背景介绍
分布库数据库架构一般采用性价比较高的 PC 服务器作为底层硬件支撑，相比于传统昂贵的、高可靠的集中式架构 (如 IOE 架构)，面临着节点故障、网络故障等多方面故障的挑战。混沌工程测试思想是通过工具模拟可稳定复现的故障场景，观察故障对业务功能及性能的影响，从而评估系统整体的高可用能力。
为给业界提供一种基于模拟真实生产场景检验分布式数据库系统稳定性的技术工具，中国信通院云计算与大数据研究所数据库团队基于混沌工程思想开发了一套针对分布式数据库系统的工具，旨在衡量分布式数据库在性能工具压测条件下的韧性表现。该工具 (databench-c) 已在 Gitee 平台开源，本文详细介绍如何使用 databench-c 对 TiDB 原生分布式数据库进行混沌测试。
环境准备
在使用 databench-c 进行混沌测试之前，我们首先需要安装部署一套 TiDB 测试集群。同时，为了便于在混沌测试过程中模拟业务负载，需要准备 sysbench 压测工具模拟客户端向 TiDB 发送读写请求。建议将 sysbench、databench-c 以及 TiDB 集群部署在不同的节点，我们将 databench-c 所在节点称为控制节点，TiDB 集群节点称为托管节点。
安装并使用 databench-c
安装 Ansible
databench-c 测试工具基于 Ansible，因此首先需要在控制节点上安装 Ansible。Ansible 的安装有多种方式，如 Ansible 安装配置和基本使用 - 腾讯云开发者社区 描述，本文使用编译安装方式，Ansible 版本需要为 2.7 或以上版本。
/* 安装python环境 */yum -y install python-jinja2 PyYAML python-paramiko python-babel python-crypto/* 下载Ansible */wget https://releases.ansible.com/ansible/ansible-2.9.27.tar.gztar xf ansible-2.9.27.tar.gzcd ansible-2.9.27/* 编译安装Ansible */python setup.py buildpython setup.py installmkdir /etc/ansiblecp -r examples/* /etc/ansible
复制代码
配置免密登录
需要配置控制节点到各托管节点的 SSH 免密登录，假如 TiDB 集群是 3 个节点，则需要配置控制节点到所有 3 个节点的免密，具体配置方式本文不作详述。
下载并部署 databench-c
基于开源地址 中国信息通信研究院云计算与大数据研究所大数据与区块链部 /databench-c 下载 databench-c 到本地并解压。
wget https://gitee.com/caict-databench/databench-c/repository/archive/master.zipunzip databench-c-master.zip
复制代码
配置托管节点 IP 和网卡设备
主要需要修改两个文件：
（1）/etc/ansible/hosts，在此文件中添加托管节点的 IP 地址，如
[test]172.20.12.1172.20.12.2172.20.12.3
复制代码
（2）${databench-c_HOME} /group_vars/all，修改 interface 为托管节点实际网卡，如
注：网络相关的故障注入实验需确定托管节点被注入故障的网卡名称，应保证各托管节点的网卡名称统一。
[root@tidb80 group_vars]# grep -B 6 interface allnetwork_delay: command: 'network delay' asynctime: 3 runningtime: 30 time: 500 #need to be changed for different chaotic level, unit is ms. offset: 300 #need to be changed for different chaotic level, unit is ms. interface: 'em1' #The name of ethernet interface, the name of interface should be set as the same amoung the cluster.--#parameters for network loss experimentnetwork_loss: command: 'network loss' asynctime: 3 runningtime: 30 percent: 10 #need to be changed for different chaotic level interface: 'em1' #The name of ethernet interface, the name of interface should be set as the same amoung the cluster.--#parameters for network corrupt experimentnetwork_corrupt: command: 'network corrupt' asynctime: 3 runningtime: 30 percent: 10 #need to be changed for different chaotic level interface: 'em1' #The name of ethernet interface, the name of interface should be set as the same amoung the cluster.
复制代码
具体测试项配置
基于测试策略，进一步编辑 ${databench-c_HOME}/group_vars/all 文件，相关参数定义如下：
test_case：定义测试的扰动类型，取值如下。
random。默认值，表示从计算、存储、网络扰动中各选一种测试。
cpu_load。cpu 过载扰动测试。
disk_burn。指高 IO 负载测试。
disk_fill。硬盘填充测试。
mem_load。内存过载测试。
network_delay。网络延迟测试。
network_loss。网络丢包测试。
network_corrupt。网络恶化 (包损坏) 测试。
injected_node_number：定义随机注入扰动的节点数量。
cpu_load：CPU 负载测试参数，取值如下。
command。chaosblade 里对应的 CPU 负载命令名称
asynctime。CPU 负载开始命令的异步执行时间，超过该时间时 Ansible 将会检查命令的完成情况。
runningtime。CPU 负载持续时间。
percent。CPU 负载百分比。
disk_burn：硬盘高 IO 负载测试参数，取值如下。
command。chaosblade 里对应硬盘高 IO 负载命令名称。
asynctime。硬盘高 IO 负载开始命令的异步执行时间，超过该时间时 Ansible 将会检查命令的完成情况。
runningtime。硬盘高 IO 负载持续时间。
disk_fill：硬盘填充测试参数，取值如下。
command。chaosblade 里对应硬盘填充命令名称。
asynctime。硬盘填充开始命令的异步执行时间，超过该时间时 Ansible 将会检查命令的完成情况。
runningtime。硬盘填充持续时间。
percent。硬盘填充百分比。
mem_load：内存填充测试参数，取值如下。
command。chaosblade 里对应内存填充命令名称。
asynctime。内存填充开始命令的异步执行时间，超过该时间时 Ansible 将会检查命令的完成情况。
runningtime。内存填充持续时间。
percent。内存填充百分比。
network_delay：网络延迟测试参数，取值如下。
command。chaosblade 里对应网络延迟命令名称。
asynctime。网络延迟开始命令的异步执行时间，超过该时间时 Ansible 将会检查命令的完成情况。
runningtime。网络延迟持续时间。
time。网络延迟时间平均值，单位是毫秒。
offset。网络延迟时间浮动量，单位是毫秒。网络延迟区间为[time-offset,time+offset]。
interface。扰动注入的网卡设备名。
network_loss：网络丢包测试参数，取值如下。
command。chaosblade 里对应网络丢包命令名称。
asynctime。网络丢包开始命令的异步执行时间，超过该时间时 Ansible 将会检查命令的完成情况。
runningtime。网络丢包持续时间。
percent。网络丢包百分比。
interface。扰动注入的网卡设备名。
network_corrupt：网络包损坏测试参数，取值如下。
command。chaosblade 里对应网络包损坏命令名称。
asynctime。网络包损坏开始命令的异步执行时间，超过该时间时 Ansible 将会检查命令的完成情况。
runningtime。网络包损坏持续时间。
percent。网络包损坏百分比。
interface。扰动注入的网卡设备名。
period：扰动注入的时间周期，单位是秒。表示每隔多少秒注入一批扰动。
max_peak_number：注入扰动的总批数。测试持续时间 =period*max_peak_number。
chaosblade_component：chaosblade 组件信息。
src。本地 chaosblade 组件名称。
dest。复制到集群后的 chaosblade 路径及名称。
假如相关配置信息为（injected_node_number：3，period：60，max_peak_number：5，test_case：cpu_load，cpu_load runningtime：30，cpu_load percent:99），它的含义为：随机注入 3 个节点、每次扰动注入时间为 60 秒、注入扰动总次数为 5 次 (测试持续时间为 300 秒)、测试案例为 CPU 负载测试、每次扰动 CPU 负载时间为 30 秒。
执行混沌测试
提前执行 sysbench 压测工具并保持持续运行状态，并以上述 CPU 负载测试为例修改配置文件并启动测试命令。整个测试过程的命令行输出内容如下，可以看到，当测试执行完毕后，测试工具会自动进入清理状态，将环境恢复到测试前的状态。
注：如果想提前结束测试，可使用 ctrl+z 中止，然后手动执行 ansible-playbook clean.yml 清理环境。
[root@tidb80 databench-c-master]# ansible-playbook start.yml
PLAY [test] **************************************************************************************************************************************************
TASK [Gathering Facts] ***************************************************************************************************************************************ok: [172.20.12.70]ok: [172.20.12.53]ok: [172.20.12.52]
TASK [experiment_setup : deploying chaosblade components] ****************************************************************************************************ok: [172.20.12.53]ok: [172.20.12.52]ok: [172.20.12.70]
TASK [experiment_setup : unarchive] **************************************************************************************************************************changed: [172.20.12.70]changed: [172.20.12.53]changed: [172.20.12.52]
PLAY [localhost] *********************************************************************************************************************************************
TASK [Gathering Facts] ***************************************************************************************************************************************ok: [localhost]
TASK [executing test with random chaos] **********************************************************************************************************************skipping: [localhost] => (item=peak No.1 chaos type:cpu_load, number of nodes injected:3)skipping: [localhost] => (item=peak No.2 chaos type:cpu_load, number of nodes injected:3)skipping: [localhost] => (item=peak No.3 chaos type:cpu_load, number of nodes injected:3)skipping: [localhost] => (item=peak No.4 chaos type:cpu_load, number of nodes injected:3)skipping: [localhost] => (item=peak No.5 chaos type:cpu_load, number of nodes injected:3)
TASK [executing test with specific chaos] ********************************************************************************************************************changed: [localhost] => (item=peak No.1 chaos type:cpu_load, number of nodes injected:3)changed: [localhost] => (item=peak No.2 chaos type:cpu_load, number of nodes injected:3)changed: [localhost] => (item=peak No.3 chaos type:cpu_load, number of nodes injected:3)changed: [localhost] => (item=peak No.4 chaos type:cpu_load, number of nodes injected:3)changed: [localhost] => (item=peak No.5 chaos type:cpu_load, number of nodes injected:3)
PLAY [test] **************************************************************************************************************************************************
TASK [Gathering Facts] ***************************************************************************************************************************************ok: [172.20.12.70]ok: [172.20.12.52]ok: [172.20.12.53]
TASK [cleaning : ending cpu_load experiment] *****************************************************************************************************************changed: [172.20.12.70]changed: [172.20.12.53]changed: [172.20.12.52]
TASK [cleaning : ending disk_burn experiment] ****************************************************************************************************************changed: [172.20.12.70]changed: [172.20.12.53]changed: [172.20.12.52]
TASK [cleaning : ending disk_fill experiment] ****************************************************************************************************************changed: [172.20.12.70]changed: [172.20.12.53]changed: [172.20.12.52]
TASK [cleaning : ending mem_load experiment] *****************************************************************************************************************changed: [172.20.12.70]changed: [172.20.12.53]changed: [172.20.12.52]
TASK [cleaning : ending network_loss experiment] *************************************************************************************************************changed: [172.20.12.70]changed: [172.20.12.52]changed: [172.20.12.53]
TASK [cleaning : ending network_delay experiment] ************************************************************************************************************changed: [172.20.12.52]changed: [172.20.12.53]changed: [172.20.12.70]
TASK [cleaning : ending network_corrupt experiment] **********************************************************************************************************changed: [172.20.12.52]changed: [172.20.12.53]changed: [172.20.12.70]
TASK [cleaning] **********************************************************************************************************************************************changed: [172.20.12.52]changed: [172.20.12.53]changed: [172.20.12.70]
TASK [cleaning : restart network service] ********************************************************************************************************************changed: [172.20.12.53]changed: [172.20.12.70]changed: [172.20.12.52]
PLAY RECAP ***************************************************************************************************************************************************172.20.12.52 : ok=13 changed=10 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0172.20.12.53 : ok=13 changed=10 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0172.20.12.70 : ok=13 changed=10 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0localhost : ok=2 changed=1 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
复制代码
查看 sysbench 运行情况
查看 sysbench 输出日志，可以发现在运行混沌测试的过程中，TPS 发生周期性的剧烈抖动，抖动周期约为 60 秒。
通过 Grafana 监控查看运行情况
下图为 Overview->System Info->CPU Usage 图表，可以看出，三个节点的 CPU 在测试过程中一共发生了 5 次周期性的波动，符合上述测试配置项。
进一步查看 TiDB-Summary->Query Summary 图表，发现无论从执行 Duration 还是 QPS 角度，也都能看到总共发生了 5 次周期性的波动，同样符合测试场景。
小结
本文详细介绍如何安装 databench-c 混沌测试工具，并使用这款工具对 TiDB 进行混沌测试。测试场景选取相对简单的基于 CPU 负载测试，用户想要进行更多更复杂场景的测试时，只需要根据实际情况编辑 ${databench-c_HOME}/group_vars/all 文件并开启测试即可。
参考链接
一文读懂中国信通院云原生数据库稳定性测试体系
评论