使用信通院混沌测试工具databench-c对TiDB数据库进行混沌测试的操作

Tiit 651 2024-03-18

背景介绍

分布库数据库架构一般采用性价比较高的PC服务器作为底层硬件支撑，相比于传统昂贵的、高可靠的集中式架构(如IOE架构)，面临着节点故障、网络故障等多方面故障的挑战。混沌工程测试思想是通过工具模拟可稳定复现的故障场景，观察故障对业务功能及性能的影响，从而评估系统整体的高可用能力。

为给业界提供一种基于模拟真实生产场景检验分布式数据库系统稳定性的技术工具，中国信通院云计算与大数据研究所数据库团队基于混沌工程思想开发了一套针对分布式数据库系统的工具，旨在衡量分布式数据库在性能工具压测条件下的韧性表现。该工具(databench-c)已在Gitee平台开源，本文详细介绍如何使用databench-c对TiDB原生分布式数据库进行混沌测试。

image.png

环境准备

在使用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.gz
tar xf ansible-2.9.27.tar.gz
cd ansible-2.9.27
/* 编译安装Ansible */
python setup.py build
python setup.py install
mkdir /etc/ansible
cp -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.zip
unzip databench-c-master.zip

配置托管节点IP和网卡设备

主要需要修改两个文件：

（1）/etc/ansible/hosts，在此文件中添加托管节点的IP地址，如

[test]
172.20.12.1
172.20.12.2
172.20.12.3

（2）${databench-c_HOME} /group_vars/all，修改interface为托管节点实际网卡，如

注：网络相关的故障注入实验需确定托管节点被注入故障的网卡名称，应保证各托管节点的网卡名称统一。

[root@tidb80 group_vars]# grep -B 6 interface all
network_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路径及名称。

  • chaos_combinations：随机测试的扰动组件情况。

假如相关配置信息为（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=0
172.20.12.53               : ok=13   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
172.20.12.70               : ok=13   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

查看sysbench运行情况

查看sysbench输出日志，可以发现在运行混沌测试的过程中，TPS发生周期性的剧烈抖动，抖动周期约为60秒。

image.png

通过Grafana监控查看运行情况

下图为Overview->System Info->CPU Usage图表，可以看出，三个节点的CPU在测试过程中一共发生了5次周期性的波动，符合上述测试配置项。

image.png

进一步查看TiDB-Summary->Query Summary图表，发现无论从执行Duration还是QPS角度，也都能看到总共发生了5次周期性的波动，同样符合测试场景。

image.png

小结

本文详细介绍如何安装databench-c混沌测试工具，并使用这款工具对TiDB进行混沌测试。测试场景选取相对简单的基于CPU负载测试，用户想要进行更多更复杂场景的测试时，只需要根据实际情况编辑${databench-c_HOME}/group_vars/all文件并开启测试即可。

参考链接

一文读懂中国信通院云原生数据库稳定性测试体系


版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。

标签：数据库 TiDB 原生分布式数据库 云原生数据库 分布式数据库系统
上一篇:TIDB数据库在某省妇幼业务系统应用的实践
下一篇:TIKV 源码学习笔记--BatchSystem 创建初始化流程的方法
相关文章