跨AZ高可用设计示例

跨AZ高可用是IDC上云最主要的价值之一。企业上云后最适合做跨AZ高可用，不仅成本低，而且很便利。下面以某大型零售电商平台为例，介绍上云后的跨AZ高可用设计方法。下图是总体架构图：

图1 高可用设计示例

• 接入层：Apisix双AZ均衡分布，当某个AZ出现故障时，ELB健康检查机制仍可将流量转发到正常AZ的Apisix实例处理。
• 应用层：容器化部署，业务节点跨AZ分布。即使某AZ异常，Apisix可以将流量转发到正常应用后端。
• 中间件层：Kafka、Solr和ES采用3AZ集群部署，任意一个AZ故障，服务仍然可用；Redis采用双AZ主备节点部署。
• 数据层：MySQL数据库采用双AZ主备部署实现HA；MongoDB使用副本集或Cluster集群，3AZ分布，某AZ故障，其他AZ正常提供服务。

• 应用层-容器集群高可用
  • Master高可用：容器集群Master 节点3AZ分布， 3节点（1+1+1）。
  • Ingress网关高可用：ELB实例开启多可用区，ELB Ingress即支持跨可用区高可用。
  • 应用高可用：K8S本身就支持应用高可用，可通过配置TopologyKey实现pod跨AZ分布。
  图2 应用层高可用设计示例
  

• 中间件层-Redis高可用
  • 主备实例配置了数据持久化，数据不仅会持久化到主节点磁盘，还会实时同步到备节点，同时备节点也会持久化一份数据。
  • 主备实例部署在不同的可用区内，不同可用区的电力、网络相互隔离，当主节点所在的机房因为电力或者网络出现故障，备节点将接管服务，客户端与备节点正常建立连接以及读写数据。
  • Redis集群搭配Keepalived生成VIP，提升业务可用性。
  图3 中间件层Redis高可用设计示例
  

• 中间件层-Kafka高可用
  • Zookeeper高可用：Zookeeper节点3AZ分布， 3节点（1+1+1）或5节点（2+2+1）。当某个AZ不可用时，集群依旧有超过半数的法定主节点选举个数，保证ZK leader的正常选主。
  • Kafka-Broker数据节点高可用：Kafka-Broker节点3AZ分布(2+2+1)。Topic副本至少设置3副本，设置unclean.leader.election.enable参数为true，在3AZ其中任意一个AZ整体宕机情况，确保集群始终最少有一份副本。
    图4 中间件层Kafka高可用设计示例
    

• 中间件层- Elasticsearch高可用
  • Master高可用：ES Master节点3AZ分布（2+2+1）。在任意一个可用区不可用时，集群依旧有超过半数的法定主节点选举个数，保证Master的正常选主。
  • 数据节点：ES Data节点3AZ分布（2+2+1）。索引shard分片至少设置2副本，加上主分片副本有3副本。假如3AZ中任意一个AZ整体宕机，集群始终都有1份完整的副本，确保数据节点高可用。
  • 图5 中间件层ES高可用设计示例
    

• 中间件层- Solr高可用
  • Zookeeper高可用：Zookeeper节点3AZ分布，3节点（1+1+1）或5节点（2+2+1）。当某个AZ不可用时，集群依旧有超过半数的法定主节点选举个数，保证ZK leader的正常选主。
  • Sorl数据节点：Sorl Data节点2AZ平均分布。索引分片至少设置（N/2）+1副本，在2AZ其中任意一个AZ整体宕机情况，确保集群始终有一份完整的副本确保数据高可用。
  • 图6 中间件层Sorl高可用设计示例
    

• 数据层- MySQL高可用

• 主备实例跨AZ部署，借助原生MySQL主从复制同步能力实现主备间数据同步。
• 主备实例以VIP对外提供服务，自身IP不对租户开放。
• 主备秒级切换，主备切换时VIP漂移至新的主节点，应用感知小（只在切换瞬间有秒级中断）。
• 支持挂载只读节点，只读节点亦可跨AZ部署
  图7 MySQL高可用设计示例
  

• 数据层- MongoDB高可用
  • DDS副本集支持跨三AZ部署、三个节点（默认为三节点、最多可支持七节点）分别部署在三个AZ，利用Mongo原生的复制能力进行数据同步。
  • Mongo Client原生支持配置多个Server地址，并支持探活。
  • 单AZ故障时，若Primary节点所在AZ故障，利用原生的Mongo选主机制选新主，当备节点不可用时，隐藏节点接管服务，保证高可用，当前支持三副本、五副本、七副本。
    图8 MongoDB高可用设计示例