一．什么是高可用测试

1.高可用性：“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。
我们可以理解为高可用是为了保证 “系统足够稳定，能应对复杂考验”

2.高可用测试我们关注的两个维度：
①. 尽可能的保证系统大概率不出现问题
②. 出现问题后我们需要将其对业务的影响降到最低，也就是缩减故障域范围

3.高可用测试关注的两个点：
①. 模拟集群部分节点或者服务发生故障时，不影响集群整体对外提供的服务
②. 集群故障恢复以后，集群能否将服务恢复到原来的状态

二．如何做高可用测试？

1.与产研团队沟通，熟悉集群的架构部署，从设计角度分析集群部署方案的完善性
2.从架构上分析每层是否有单点情况，单点失效是否有替代方案
3.架构方案无明显缺陷后再梳理重点例如：
网络层面：网络是否可达，是否有丢包
机器层面：集群节点的宕机，重启等
基础服务：数据库，主从切换，主从同步等
进程层面：模拟进程假死，崩溃。强杀等多种 kill 信号模拟
负载均衡：节点多或者流量太大或者有特定策略部分用户就会丢包等
系统扩容的高可用性 --- 水平扩容等

三．实战案例

1.背景
❶.目的
测试集群环境的稳定性，用于后期项目可以稳定交付
❷.集群
OpenStack S 版本 超融合集群
❸.集群标签
kubernetes/docker//超融合/容器化/keepalived
❹.测试重点：
①. 高可用测试，单台服务器宕机异常不影响集群使用
②. 故障自愈，服务器发生重启或关机，启动后集群能够自动恢复
③. 数据库 mariadb 和 mysql 高可用测试
④. Openstack 服务和 web 服务异常后集群使用情况

2.部署方案
①.机器
三台机器同为计算节点，控制节点和网络节点

②.OpenStack
集群底层服务运行在 docker 环境
上述三台机器同为计算节点，控制节点和网络节点
OpenStack 服务如下：

③.K8S
kubernetes 基于 1.17.5 版本部署，多 master，高可用方案。
kubernetes 节点:10.x.x.10/10.x.x.20/10.x.x.30
ingress 服务

④.Keepalived vip
Keepalive 路径：etc/kolla/keepalived/keepalived.conf
vip 10.x.x.3

⑤.Web 服务

⑥.监控服务
moon-sproxy 只需部署在所有 Openstack 计算及网络节点宿主机上，
moon-agent 既可以在物理机上安装也可以在虚拟机内安装
moomagent 部署在物理机，namespace：infra-s3 deployment

⑦.数据库
Mariadb：openstack 服务使用，多主服务
Redis：支持高可用，statefuset 持久化运行
Mysql：一主两从模式部署在 k8s，支持高可用
memcached：以 deployment 运行在 k8s 集群上
reddismq ：statefuset 持久化运行

3.高可用方案设计和测试结论
从部署节点、服务、数据库中间件、硬件四大方面设计测试用例。整体测试方案如下图：

①.openstack 服务
针对 nova，keystone，neutron，cinder，glance，octavia，以及其他服务（keepalived，haproxy……）进行测试，主要关注点为
● 关闭单个节点上的 nova 等服务，系统功能正常，创建虚机，网络，云硬盘等模块都可以正常使用
● 关闭多个节点上子服务，如关闭了 ceph01 和 02 节点上的某个服务，ceph03 正常运行，需要保证系统功能正常
● 关闭所有节点上的某个子服务，如关闭了所有节点上的 nova 服务，则系统平台异常，无法进行虚机创建等操作
● 关闭子服务的子进程，如关闭单个节点上 nova 服务的部分子进程，系统功能正常

测试结论：openstack 服务—docker 部署，多副本运行，挂掉两个不影响系统功能。

②.WEB 服务
针对计算，存储，网络，监控等服务进行测试，主要关注点为：
● kill 掉 pod 服务，pod 可以重建，进程自动重启，系统可以正常使用
● 单个节点上停止 kubelet，节点上的 pod 可以漂移到其它节点，系统可以正常使用
● kill 掉计算，存储等每个服务的 pod，pod 可以重建，系统正常使用
● 循环删除 pod，停止后 pod 可以重建
● 挂起 pod 后释放，pod 可以自启动

测试结论：web 服务 — k8s 容错 5-10min 漂移自动恢复。

③.数据库和中间件
数据库需要关注服务端使用的 mysql 的高可用以及底层使用的 mariadb 的高可用
● 单节点 stop mariadb，系统数据正常
● 多节点 stop mariadb，保留一个节点正常，系统数据正常
● Mysql 主库挂掉
● Mysql 从库挂掉
● Mysql 所在 pod 的 kubelet 服务挂掉
● 进入某节点 mysql pod 的 container，kill 掉 mysql 进程
● pod 重建后的数据一致性

测试结论：mysql 数据库—主从切换失败，目前不支持高可用。
openstack 数据库，mariadb 不支持高可用，挂掉一台系统无法使用。

④.部署节点测试
需要关注计算节点，控制节点，网络节点，存储节点所在服务器挂掉单个和挂掉多个之后的高可用情况。以及服务器关机和重启时节点的高可用情况

测试结论：集群里一台机器关机，系统不可用。

⑤.硬件相关测试
● 物理机 cpu 打满时，系统的可用性及稳定性
● 物理机磁盘故障
● 物理机内存跑满
● 物理机网络故障等情况

测试结论：重启集群内机器偶尔出现网络配置问题，（网卡的 mac 改变，导致 DHCP 请求不到 IP 地址）。
重启集群机器偶尔出现 mariadb 数据同步异常，无法连接的问题导致网络服务启动失败。
集群关机后，部署在 k8s 上的 web 服务的 pod 目前需要 5 分钟后才会检测到挂掉的 pod 进行漂移，导致 5 分钟内服务不可用。

4.优化方案：
针对测试完成后遇到的问题，进行了部分优化，方案如下：
● Mysql 主从切换失败，不支持高可用
方案：排查是 keepalive 的配置错误导致，优化配置。
● 集群关机后 web 服务的 pod 需要 5 分钟才能漂移，5 分钟内服务不可用
方案：将 pod 优化成多个副本，设置成反亲和策略，每个服务有多个副本在不同的物理机上，宕机不影响服务使用。
● mariadb 不支持高可用
方案：当前方案的局限性无法支持高可用，haproxy keepalive 只能保证通过 haproxy 的只读 vip 高可用，读写主库的角色没办法同步跟随改变。将数据库迁移到 mysql8.0 以上版本可支持 mariadb 高可用。

实战方案总结：

通过对集群部署环境的梳理，整理出上述 5 大模块的测试：openstack 服务、web 服务、数据库、部署节点、硬件。全面的覆盖了集群软硬件的高可用指标，并且针对测试结论进行了优化，给业务方在系统的部署方案上提供了支持保障，提高了系统的稳定性和可用性，对于后续交付给用户使用也提供了部署参考及模板依据。