专属az异常测试实践

异常测试，是检测系统对异常情况的处理，测试人员通过人为制造错误，测试系统是否能有效处理异常。

引入专属az后，ceph部署变成计算和存储混布，因此也大大增加了系统的复杂度，异常测试由原先的云主机io影响变成云主机io和云主机带宽均可能受影响的情况。

测试分析：

1.       模拟用户场景，原则上要尽可能的占用资源，因为线下测试环境规模远远不如线上，因此要充分使用资源，且保证系统的整体负载较高，同时覆盖多种操作系统及镜像：

按照目前的部署方案，实际资源如下：

a.每个节点插4*800G的ssd盘，共计6个节点插盘，ceph按照3副本部署，因此ceph总容量不含超售为 3.2T*6/3*0.75=4.8T，按最大2倍超售为9.6T。

b.cpu核数非超售情况下每台为48核，一个osd独占2个物理核。

c.网络为单台物理机10G网卡

非超售情况下每个节点的稳定性场景如下：

镜像	Flavor大小	云主机数量	是否挂载ceph盘
debian_7_x86_64_pub_static_36840.qcow2	8v*8g	4	否
centos_7.2_x86_64_pub.qcow2	1v*1g	2	是
window7_amd64	4v*4g	1	否
ubuntu_14.04_amd64	2v*2g	2	是
windows_2012r2	4v*4g	1	否

 每个节点按照上述表格部署10台云主机，共计90台云主机，每个节点占用36vcpu，每个云主机系统盘用fio随机读写10G数据；其中每个节点4台云主机每台挂载100G ceph云硬盘，每块云硬盘读写50G数据；ceph总分配量为5.4T，ceph实际写数据量为3T左右；按照带宽负载，100G的ceph盘QoS限制为82Mbps，云主机默认最大速率为500Mbps，按最大带宽的50%，无超售情况下带宽最大负载在400Mbps。这样，非超售情况下，负载基本都在50%以上，如果在2倍超售情况下，将上述规模扩大一倍，系统接近满载。

2.异常项注入可以从以下几个方面展开：

a.       物理机及openstack服务异常

1.       计算及ceph混布节点宕机

2.       计算及ceph混布节点网络异常

3.       验证nova-compute等主要服务被kill等的情况

b.       ceph集群扩容或者异常（由于是与线上公用mon，因此不开展对mon的异常操作）

1.添加硬盘（新加osd），测试rebalance的速度，以及对正常业务io及带宽的影响；

2.集群扩容（新加机器），测试rebalance速度，及对io及带宽的影响；

3.重启一个osd，测试修复速度，以及对正常业务io及开开的影响；

4.拔盘，测试修复及对正常业务io及带宽的影响

5.kill掉一个osd，测试对修复以及对正常业务io及带宽的影响

6.停掉一个osd，间隔20分钟后再次启动osd

7.停掉一个节点的所有osd，间隔20分钟后再次启动osd

c.  机柜及集群异常

       1.对机柜断电，间隔20分钟后上电，验证集群是否能够恢复正常

       2.对集群断电，间隔20分钟后上电，验证集群是否能够恢复正常

测试执行：

异常测试整个环境构建及检查项都是明确的，而且是一致的，且集群中有90台云主机，依赖人工检查并不现实，因此可以考虑自动化测试。而针对这里的异常项也可以进行简单分类：部分异常依赖机房人工操作（断电、断网、拔盘），部分异常获取相应权限后可自动化运行（重启osd、重启服务等）。

总体设计如下：

1.       环境部署时，使用带工具及部分测试脚本的镜像，创建云主机，环境可复用

2.       异常注入时，考虑将能够自动化的异常自动化执行，不能自动化的异常单独执行（整体自动化测试不变，仅异常注入部分依赖人工操作）

3.       数据收集时，考虑将所有数据获取后取异常前后的io及带宽的平均值进行比较，并统计受影响云主机数量、各项指标恢复正常的耗时

4.       用哨兵监控物理机、集群的整体负载情况

5.       收集测试过程中warning及error的log

6.       检查环境整体情况，保证不影响下一轮测试

本文来自网易实践者社区，经作者罗泽文授权发布。