# databench-c

**Repository Path**: caict-databench/databench-c

## Basic Information

- **Project Name**: databench-c
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2023-07-24
- **Last Updated**: 2024-02-20

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 分布式系统混沌测试工具

## 介绍

本分布式系统混沌测试工具可自动化地按一定模式对分布式集群注入随机故障。

在进行混沌测试实验时，被注入故障的分布式集群中的节点称为托管节点，部署安装该工具的节点称为管理节点。只需要在管理节点安装本混沌测试工具。

## 目录说明

* start.yml：程序入口，定义故障注入模式。执行时完成实验部署，实验运行，环境清理三个步骤。
* clean.yml：用于实验结束后清理环境。
* testgroup.yml：故障注入实验基础模块的接口。通过选择不同的标签可以执行不同组合的实验模块。
* component.yml：用于各个故障注入模块的单元测试。
* roles：定义各故障注入模块，包括CPU负载，内存填充，磁盘填充，IO负载，网络延迟，网络丢包，网络恶化（包损坏），环境清理，工具部署。
* group_vars/all：定义故障注入实验配置。

## 安装方法

本混沌测试工具基于Ansible，需在管理节点上安装Ansible 2.7或以上版本。

安装Ansible完成后，用本项目文件中的ansible文件夹替换系统/etc/ansible文件夹。如果使用pip安装Ansible，则/etc/ansible文件夹不会被自动创建，直接将项目文件中的ansible文件夹移入/etc即可。

确定各托管节点的ip地址，并配置管理节点使用ssh以root用户免密登录各托管节点。

在/etc/ansible/hosts文件中test的条目下添加各托管节点的ip地址。例如托管节点的ip地址为192.168.56.11、192.168.56.12、192.168.56.13，则hosts文件的内容应为：

    [test]
    192.168.56.11
    192.168.56.12
    192.168.56.13

网络相关的故障注入实验需确定托管节点被注入故障的网卡名称，应保证各托管节点的网卡名称统一。确定网卡名称后需将group_var/all文件中的网卡名称修改为托管节点被注入故障的网卡名称。

## 使用方法

开始故障注入前，先于group_vars/all中配置参数。

在本项目目录下执行ansible-playbook start.yml开始故障注入。

如希望提前结束故障注入程序，输入ctrl+z，并运行ansible-playbook clean.yml清理环境。

## 参数配置说明

执行测试所用的Ansible脚本变量均位于文件grop_vars/all中。其中包括测试参数，需根据各组实验的扰动注入情况进行调整，以下将这些变量用**粗体**标出。

其他变量在测试过程中一般不需改动，但是为了保证程序的灵活性，方便调试并解决可能遇到的问题，这些变量也会进行介绍。

**test_case**：定义实验的扰动类别，可选择以下几种类型：

* cpu_load：cpu过载扰动实验
* disk_burn：重复读写（高IO负载）实验
* disk_fill：硬盘填充实验
* mem_load：内存过载实验
* network_delay：网络延迟（抖动）实验
* network_loss：网络丢包实验
* network_corrupt：网络恶化（包损坏）实验
* Random：随机实验，将会从计算，存储，网络扰动中分各选出一种

**injected_node_number**：定义随机注入扰动的节点数量。实验的每一批扰动注入都将从配置的节点中随机选取该数量的节点注入扰动。

cpu_load：CPU负载实验参数集合，包含以下几项

* command：chaosblade里对应的CPU负载命令名称
* asynctime：CPU负载开始命令的异步执行时间，超过该时间时Ansible将会检查命令的完成情况。
* runningtime：CPU负载持续时间
* **percent**：CPU负载百分比

disk_burn：硬盘重复读写（高IO负载）实验参数集合，包含以下几项

* command：chaosblade里对应硬盘重复读写命令名称
* asynctime：硬盘重复读写开始命令的异步执行时间，超过该时间时Ansible将会检查命令的完成情况。
* runningtime：硬盘重复读写持续时间

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。若想提前结束，可以执行ctrl+z提前终止实验，并运行clean脚本清理环境。

chaosblade_component：chaosblade组件相关信息

* src：本地chaosblade组件名称
* dest：复制到集群后的chaosblade路径及名称

chaos_combinations：随机测试（test_case设为random时）的扰动组合情况。

实验进行时，混沌测试工具将每隔一定的时间（period定义），随机选择特定数量的节点（injected_node_number定义）注入扰动（类型由test_case定义），每次扰动持续一定的时间（由响应扰动类型的runningtime变量定义）。

示例（injected_node_number：3，period：60，max_peak_number：5，test_case：cpu_load，cpu_load runningtime：30）：

![](./example1.png)

## 基本测试过程

在对分布式数据库系统进行稳定性测试时，要先进行一组基准实验。基准实验通常是一组压力测试，在不注入任何故障的情况下进行，模拟被测系统在生产环境中处于稳定状态的工作情况。基准实验的具体压力测试用例因被测数据库的类型而异，测试用例的详情请参考相关文档。通过基准实验可得出被测系统在无故障时的性能指标$E_0$。

基准实验完毕后，开始进行故障实验。在进行故障实验时，需在运行与基准实验相同的压力测试的同时使用混沌测试工具对被测系统注入规定的故障，目的是测试被测系统在相应故障场景下的工作情况。被测系统在故障场景下完成压力测试后可得出被测系统在相应故障场景下的性能指标$E_i$。

## 相对性能指标

相对性能指标（Relative Performance）可反映被测系统的性能受故障影响的程度。数值越高说明故障对被测系统的影响越小。

$RP_i=\frac{E_i}{E_0}$

* $RP_i$：第i组实验的相对性能指标
* $E_i$：第 i 组实验的性能指标
* $E_0$：基准实验的性能指标

对于恢复性验证，这个指标反映了被测系统移除故障后的恢复能力（系统恢复率）。

## 相对性价比指标

CPU、存储、网络丢包、网络包损坏部分的实验需计算相对性价比指标（Relative Cost Performance）。

各实验组的系统性价比指标由主要性能评估指标除以实验可用的硬件资源量得到。反映了单位时间，单位硬件资源所完成的工作总量。

基准实验组：

$CP_0=\frac{E_0}{NR}$

故障实验组：

$CP_i=\frac{E_i}{(N-{N_i}{P_i}{\Lambda})R}$

可计算相对性价比指标：

$RCP_i=\frac{CP_i}{CP_0}=\frac{E_iN}{E_0(N-{N_i}{P_i}{\Lambda})}$

* $RCP_i$：第i组实验的相对性价比指标
* $R$：各节点的系统资源总量
* $E_i$：第i组实验的性能指标
* $E_0$：基准实验的性能指标
* $N$：被测集群总节点数
* $N_i$：第i组实验注入故障的节点数
* $P_i$：第i组实验故障平均占用资源比率
* $\Lambda$：故障时间覆盖率（一般的故障实验中每分钟对节点注入一次持续30秒的故障，该值取${30s}/{60s}=0.5$）

相对性价比指标反映了各实验组的系统性价比（单位时间、单位硬件资源所完成的工作总量）相对于基准实验组的变化情况。该数值越高说明系统对相应的故障的韧性越强。

## 实验终止条件

单项实验中如出现以下状况，测试人员需考虑终止该项实验，该项的测试结果部分记录为“未完成”，后续实验仍正常进行。

* 单项实验的运行时间过长，被测系统无能够正常完成压力测试的迹象
* 被测产品发生故障导致实验终止，重复2次后仍有发生
* 基础功能指标错误，重复2次后仍有发生