构建AZ故障感知和切换能力，实现分钟级故障自愈

      OWS是一款华为GTS自研的工具平台，部署在公有云上，我们面向全球多项目、多客户提供服务，要求提供4个9以上的可用性能力。而机房和数据中心级故障对云租户应用的可靠性影响是灾难级的，历史上TOP云服务厂商均发生过多起机房或数据中心故障，导致客户业务受损。为应对此类故障，我们需要从应用部署形态、微服务耦合依赖关系、资源冗余度、故障检测与切换能力等方面构建高可用系统架构，提升业务高可用能力。

      二、业务现状

      OWS业务在全球多个Region上都有部署，每个Region上都是一套独立的OWS环境。在单个Region内，OWS微服务采用集群跨AZ部署，例如OWS的GAM用户鉴权服务是一个3节点集群，这三个节点分别部署在3个AZ上。根据历史数据分析，导致OWS宕机的重大事件中，单AZ故障占比80%。因此，提升单AZ故障场景下业务可用性是改进的重点。

      在保障集群跨AZ部署方案的可靠性，存在如下几个挑战：

      1. 上层应用难以感知云资源亚健康状态

      云主机可用性依赖底层资源如网络、存储、计算等资源状态。而这些底层资源故障，尤其是亚健康状态，往往无法体现到云主机的状态上，进而无法传递给上层业务应用感知。这就导致上层应用误以为云主机是健康可用的，将业务请求转发到故障节点后，出现请求超时或无响应等问题。

      2. 故障爆炸半径从单AZ蔓延到全局

      由于微服务集群节点是跨AZ部署的，微服务之间的调用存在跨AZ转发的情况，一旦单AZ的部分主机出现亚健康且未被有效隔离，会导致业务请求经过层层转发后无响应，故障会蔓延到全局。

      3. 资源冗余量评估难度加大

      单AZ的资源冗余量未被有效评估，当单AZ云主机故障后，在3AZ部署场景中100%业务压力由其他AZ66%的资源来承载。如果资源冗余不足，将导致系统过载，故障进一步恶化，亟需构建有效的资源冗余评估方法。

      三、方案实践

     整体优化方案

      经过系统性分析，OWS产品确定了以“在3个9的云基础设施上，构建5个9的产品可用性”为能力导向，分阶段牵引产品和SRE能力持续建设，以实现年度可用度 ≥99.999% 的长期目标。

      目标分三个阶段达成：

      第一阶段，实现跨AZ集群可靠性增强，使集群内具备单AZ故障的快速感知和切换能力，实现系统可用性达到99.95%。

      第二阶段，实现跨AZ多活能力，使集群间具备单AZ故障的快速感知和切换能力，实现系统可用性达到99.99%。

      第三阶段，实现跨Region容灾能力，使集群间具备单Region故障的快速感知和切换能力，实现系统可用性达到99.999%。

      当前已经完成阶段一优化，详细方案步骤如下：。

      1)  识别单AZ部署隐患：通过高可用面板，实现多部署形态可管、可视。

      2)  微服务跨AZ均衡分布：利用Kubernetes标签能力，实现微服务跨AZ自动均衡分布，保证资源利用均衡。

      3)  单AZ故障检测与自动隔离：发生单AZ故障后，微服务集群可以检测到故障节点，并进行隔离。

      4）明确容量管理规则：通过规则约束，合理规划集群资源容量，确保故障AZ被隔离后业务平稳运行。

      详细方案如下：

      1.  识别单AZ部署隐患

      微服务在部署阶段，由于资源满足度不高、人为配置错误等原因，可能会出现单AZ部署的情况。后续整改过程中，又可能因为可视化能力不足出现遗漏，因此需要识别单AZ部署的隐患。在OWS的运维平台iDOE上，通过CMDB建立环境、微服务、主机、AZ标签的映射关系，实现环境和微服务粒度的跨AZ高可用的满足度可管可视，有效解决微服务单AZ部署的隐患识别问题。

微服务跨AZ均衡分布看板

      2.  微服务跨AZ均衡分布

      微服务在运行过程中，为避免资源利用不均衡问题，会把多个微服务放到一个大的云主机资源池内按照负载情况任意调度。假设云主机资源池有9个ECS节点，均衡分布在3个AZ上，每个AZ部署3个ECS。例如某个微服务只需要启动2个POD就可以满足业务诉求，如果存在该微服务的全部POD节点都运行在单个AZ的情况，单个AZ机房故障时，微服务的节点会全部不可用。为了解决这个问题，我们利用Kubernetes的Topology Spread Constraints特性控制POD在可用区间的分布。

      1)  纳管数据面节点时，给node打上zone的标签。如：zone=AZ-1。Kubernetes会根据node上的zone标签值，划分出可用域。

      2)  POD中通过Topology Spread Constraints字段配置，指导pod在可用区间的分布。并根据app标签，将pod均匀调度到不同的可用域，可用域间pod数量差为1。

      下图中，微服务M将被优先调度到打了不同Zone（可用区域）标签的虚拟机A、B、C上。而虚拟机D因为跟虚拟机A属于相同的Zone标签，在调度策略（优先进行跨AZ标签调度）上优先级低于虚机B和虚机C。

      3.  单AZ故障检测与自动隔离

      当出现单AZ机房故障时，网络、中间件、数据库等云服务的故障感知和切换由云厂商来保证，而对于ECS主机资源的故障，由于云上只提供单机能力，跨AZ集群切换能力则需要业务侧来完成。

      OWS基于OS层的Hang-Handler机制，完善了主机CPU、内存、磁盘、IO等故障场景下集群主动故障隔离能力。Hang-Handler的总体思路是设定内核定时器，如果定时器超时得不到刷新，则触发系统KDUMP/LKCD，将OS系统重启。当OS系统重启后，ECS上运行的业务POD将从服务队列中被移除掉，这样就实现了故障的感知和隔离，当故障恢复后，业务POD将重新被分配，实现故障自愈。

Hang-Handler机制原理图

      4.  明确容量管理规则

      在集群跨3AZ部署场景，当单个AZ机房发生故障时，故障AZ的ECS节点资源将全部不可用，此时业务压力会全部切换到另外两个AZ，如果这两个AZ没有足够的资源冗余，业务过载就会产生雪崩现象，导致业务再次受损。

为合理管控平台运行环境的计算资源容量配置，特制定《GTS云服务计算资源容量管理规范》，明确部署规划和运行两个阶段的计算容量管理要求，实现如下目标：

      1）合理规划业务类计算资源，确保多AZ部署场景单AZ故障切换后业务功能正常，性能不恶化。

      2）合理管控运维和安全类占用的计算资源，避免抢占业务类计算资源，确保运维或安全类进程、线程异常不影响业务功能。

      规则举例：

     【规则】宿主机上容器进程的CPU Request之和不能超过（宿主机CPU规格-非业务类进程CPU预留）*60%。

     【规则】宿主机或容器CPU 利用率和宿主机CPU load/CPU核数的 24小时P95值高于70%应采取措施进行消减，优选选择横向扩容。

     【规则】宿主机内存利用率24小时P95值高于90%，应采取措施进行消减。