浅谈高可用测试!

草帽路飞UU

前言

　　现今的互联网产品越来越注重可靠性，尤其是在生产环境中使用的系统，对高可用性都有一定的要求。而作为产品的提供方，在交付产品之前，也会对高可用进行验收测试。近期跟进过两个产品曾有高可

用测试的需求，在此简单的总结分享下。

　　在介绍产品之前，先简单的介绍下高可用和高可用测试：

　　高可用：指的是系统如何保证比较高的服务可用率。在系统的某个部分因为各种原因而失效时，能保证系统整体的服务正常运行。

　　高可用测试：通过模拟系统出现异常的情况，验证系统是否能正常提供服务（或降级提供服务），并验证系统在异常恢复后，能否恢复至异常出现之前的运行状态。

　　产品A：云计算PAAS层组件


　　产品A为云计算的PAAS层组件，各服务部署在云主机以及物理机上，大致架构如下：




从产品架构来看，对A产品做高可用测试，需要分别确保LVS集群和Tengine集群的高可用。因此，需要根据LVS集群和Tengine集群的原理以及运行特性，分别制定高可用测试方案

　　LVS运行物理机上，OSPF协议实现多节点互备，因此设计高可用测试方案如下：




从网络方面验证高可用，配置iptables规则实现端口丢包，模拟网络不可用的情况

　　在进程方面验证高可用，分别使用stop、kill -9、kill -19模拟进程停止、崩溃、假死时的情况

　　在机器方面验证高可用，通过关机、重启模拟物理机宕机时的情况

　　Tengine运行在云主机上，通过LVS的健康检查实现服务保证，因此设计高可用测试方案如下：



产品B：数据可视化产品
　　产品B为数据可视化产品，采用物理机+docker容易进行私有化部署，大致架构如下：




从产品架构来看，对B产品做高可用测试，主要分为功能容器不可用、基础设施容器不可用、节点网络异常、机器异常情况下的高可用：




由于功能容器无状态，因此对功能容器做高可用测试时只需要模拟容器不可用的情况即可。

　　而基础设施容器和功能容器不同，其中mysql等容器涉及到数据写入，因此在做高可用测试时需要考虑异常发生时的主从切换，以及异常恢复后的主从同步。

　　节点网络异常和物理机异常会影响到节点上的所有服务，因此也要验证节点出现网络异常和物理机异常以及异常恢复后的数据一致性。