环境准备

集群名称和版本

tidb 集群: tidb-h

版本：v6.6.0

集群拓扑：单中心模拟部署两中心部署拓扑，延时要求如下：

?

?

?

?

模拟场景

源

目标

延时

同城

172.16.x.71,72

172.16.x.73,74

1.5ms

异地

172.16.x.66~68,71~74,77

172.16.x.67

200ms

软件版本：chaosd

x86 平台：

curl -fsSL -o chaosd-v1.2.0-linux-amd64.tar.gz https://mirrors.chaos-mesh.org/chaosd-v1.2.0-linux-amd64.tar.gz$ ./chaosd version Chaosd Version: version.Info{ GitVersion:"v1.2.0", GitCommit:"38e871fbcc62ab74dda45f65e13b35aa3b6ee8a8", BuildDate:"2022-04-28T06:18:30Z", GoVersion:"go1.16.2", Compiler:"gc", Platform:"linux/amd64"}

arm 平台：

链接: https://pan.baidu.com/s/1dS4OcJgmZCy2iq1rEC286w?pwd=ps8s 提取码: ps8s

$ ./chaosd version Chaosd Version: version.Info{ GitVersion:"v1.2.0-5+62d573059cf5bc", GitCommit:"62d573059cf5bcd2a7621aa5846774401791e573", BuildDate:"2022-06-07T09:59:46Z", GoVersion:"go1.18.2", Compiler:"gc", Platform:"linux/arm64"}

依赖库 Glibc 版本 >= v2.17：

# rpm -qa |grep glibc glibc-common-2.17-260.el7.x86_64 glibc-2.17-260.el7.x86_64 glibc-devel-2.17-260.el7.x86_64 glibc-headers-2.17-260.el7.x86_64

软件推送

172.16.x.67 TiUP 节点上全局推送的 chaosd 二进制。

tiup cluster push tidb-h /home/tidb/chaosd-v1.2.0-linux-amd64/chaosd /home/tidb/chaosd tiup cluster exec tidb-h --command "chmod +x /home/tidb/chaosd"

配置拓扑

到同城站点节点

同城双中心延时 1.5ms 模拟场景（同城 172.x.71,72 到 73,74）的故障注入命令如下：

# vi lat7172.sh tiup cluster exec tidb-h --command "/home/tidb/chaosd attack network delay -H 172.16.x.73,172.16.x.74 --device enp2s0f0 --latency 1.5ms" -N 172.16.x.71 --sudo tiup cluster exec tidb-h --command "/home/tidb/chaosd attack network delay -H 172.16.x.73,172.16.x.74 --device enp1s0f0 --latency 1.5ms" -N 172.16.x.72 --sudo

注意：

因为 172.16.x.71~72 节点的网卡实例名不同，所以需要单独的命令指定。如果环境中所有节点的网卡实例名一样，可以用 tiup -N 172.16.x.71,172.16.x.72 同时指定多台。

网络延时故障配置不需要配置双边。

如果注入丢包等场景，请注意消除故障的网络是到达的，如 TiUP 操作机的 IP 不应该在 IP 列表里面。

同城双中心延时模拟场景的 Ping 验证命令如下，故障注入后进行测试测试，参数 -c 指定 Ping 包数量，需要根据注入故障场景指定。

# vi ping7172.sh tiup cluster exec tidb-h --command "ping 172.16.x.73 -c 2" -N 172,17.45.71,172.16.x.72 |grep -Ei bytes|outputs tiup cluster exec tidb-h --command "ping 172.16.x.74 -c 2" -N 172,17.45.71,172.16.x.72 |grep -Ei bytes|outputs tiup cluster exec tidb-h --command "ping 172.16.x.71 -c 2" -N 172,17.45.73,172.16.x.74 |grep -Ei bytes|outputs tiup cluster exec tidb-h --command "ping 172.16.x.72 -c 2" -N 172,17.45.73,172.16.x.74 |grep -Ei bytes|outputs

同城 172.x.71~72 到 73~74 的 ping 的结果大概会到 1.6 毫秒。

到远程站点节点

异地中心延时 200ms 模拟场景（ 67 节点模拟远程）的故障注入命令如下：

# vi lat67.sh tiup cluster exec tidb-h --command "/home/tidb/chaosd attack network delay -H 172.16.x.67 --device enp2s0f0 --latency 200ms" -N 172.16.x.66 --sudo ...

Ping 67 节点的脚本如下，故障注入后进行测试测试，参数 -c 指定 Ping 包数量，需要根据注入故障场景指定。

vi ping67.sh tiup cluster exec tidb-h --command "ping 172.16.x.67 -c 1" |grep -Ei bytes|outputs

同城 172.16.x.71~74 到 的 ping 172.16.x.67 的结果大概会到 200 毫秒。

全局关闭注入

每次测试结束后，完成一次全局删除注入故障，再进入下一轮测试。

先编写单机的恢复脚本。

# vi a.sh home/tidb/chaosd search --all |grep success |awk {print "/home/tidb/chaosd recover "$1}|bash

全局推送的恢复脚本。

tiup cluster push tidb-h /home/tidb/a.sh /home/tidb/recoverlat.sh tiup cluster exec tidb-h --command "chmod +x /home/tidb/recoverlat.sh"

通过全局执行单机的恢复脚本，实现全局删除注入故障。

vi recoverall.sh tiup cluster exec tidb-h --command "/home/tidb/recoverlat.sh" --sudo

建议 recoverall.sh 执行两次，第二次执行应该无输出。

全局验证

Ping 所有节点的脚本如下，建设每次测试结束后，完成一次全局网络验证防止影响下一轮测试，参数 -c 指定 Ping 包数量，需要根据注入故障场景指定。

tiup cluster exec tidb-h --command "ping 172.16.x.66 -c 1" |grep -Ei bytes|outputs ... tiup cluster exec tidb-h --command "ping 172.16.x.68 -c 1" |grep -Ei bytes|outputs tiup cluster exec tidb-h --command "ping 172.16.x.71 -c 1" |grep -Ei bytes|outputs ... tiup cluster exec tidb-h --command "ping 172.16.x.74 -c 1" |grep -Ei bytes|outputs tiup cluster exec tidb-h --command "ping 172.16.x.77 -c 1" |grep -Ei bytes|outputs

总结

Chaosd 可以支持网络延时、丢包等模拟场景，通过统一控制网络模拟操作，可以实现两地三中心的网络条件的快速模拟和销毁。