作者:焦振清

跨 AZ 部署是实现服务高可用较为有效的方法,同时也极具性价比。如果实现了跨 AZ 部署,不仅可以消除服务中的单点,同时还可以逐步建设如下能力:服务隔离,灰度发布,N+1 冗余,可谓一举多得。因此,接下来我们会对有状态的开源软件进行一系列的跨 AZ 部署的介绍,本次介绍 Zookeeper。

ZK 容错数

Zookeeper 有这样一个特性:集群中只要有过半的机器是正常工作的,那么整个集群对外就是可用的(完整机器列表是预先定义在 ZK 的配置文件中)。也就是说,一个 ZK 集群有 3 个实例,一个死了,还剩下 2 个正常的,过半了,所以 3 实例的 Zookeeper 的容忍度为 1。同理,一个 ZK 集群有 5 个实例,2 个死了,还剩下 3 个正常的,过半了,所以 5 实例的 Zookeeper 的容忍度为 2。因此可以用 2n+1 来描述 ZK 集群的容忍度。考虑到 3 实例的集群只能故障一个实例,因此,线上集群一般都是五个实例的。

按照上述的逻辑,七个实例甚至更多的实例不是更好吗?从实践角度看,如果一个集群 5 个实例扛不住的情况下,基本就需要做集群拆分了。7 个实例的集群也许没啥问题,但是这么大压力的集群,一旦故障,影响面也是非常严重的,因此,更多的采用集群拆分而不是持续扩容的方式。

最佳实践

以线上最为常见的 5 实例的 ZK 集群为例进行说明,5 实例的 ZK 集群主要有如下两种部署方式:

延时敏感型:单 AZ 部署方案(AZ1:5),这种部署模式适用于 Zookeeper 服务的系统全部集中在同一个 AZ 内。在这种情况下,如果该 AZ 故障,那么系统必然不可用,这时,ZK 即使可用也没有意义,因此也就没有必要去做跨 AZ 的部署了,并且跨 AZ 后,还会增加常态下的网络延时

高可用型:三 AZ 部署方案(AZ1:2 + AZ2:2+ AZ3:1),这种部署模式适用于 Zookeeer 服务的系统做了 2-3 个 AZ 的部署,从而确保业务系统所在的 AZ,任意一个故障,ZK 服务自身依然可用

跨 AZ 部署最佳实践之 Zookeeper

其他部署形式的缺点

除去上述推荐的两种部署形式外,不推荐的部署方式有两 AZ 部署方案(AZ1:2 + AZ2:3),这种部署方式,仅能保证 AZ1 故障后整体服务的可用性,而三 AZ 部署方案则可以接受任意一个 AZ 的故障,本质上等同于单 AZ 部署的效果,因此不做推荐和介绍。

AZ 数量是不是越多越好

如此类推,是不是说采用五个 AZ 每个 AZ 部署一个实例的方式是最好的呢?答案是否定的,有如下几点考虑:

  • 从故障域角度讲,如果一个 Region 有较多的 AZ,一般会拆分为两个故障域从而获得更好的可用性。例如华北区域有 6 个 AZ,将这 6 个 AZ 分为两个故障域,每个故障域 3 个 AZ,这样,任意机房的故障其影响范围只会在一个故障域的三个 AZ 内,而不会扩散到整个区域。这样对服务能力来讲,损失面得到更好的控制。

  • 从服务质量角度讲,在冗余度确定的情况下(5 实例),且都能满足业务可用性的同时(业务部署 2-3 个 AZ),ZK 部署在 5 个 AZ,并不会带来更高的可用性,相反,却需要面对更多的机房抖动,延时和故障。假设一个机房一年平均故障一次,那么五个机房一年就会故障五次,单个机房的故障时,服务会发生请求超时和重连,服务质量会略降低

  • 从成本角度讲,在冗余度确定的情况下(5 实例),且都能满足业务可用性的同时(业务部署 2-3 个 AZ),ZK 部署在 5 个 AZ,任意机房的故障都需要干预和关注,同比 3AZ 的情况,会增加更多的干扰,消耗人员的精力

关于机房规划

在公有云的一个 Region 里,往往有多个 AZ 可供选择,抛开 ZK 泛泛的讲一个服务应该部署在几个 AZ,主要是成本和可用性之间的平衡,在不同的环境下,得出的结果不尽相同,因此这里只能给一些分析的思路:

  • 如果部署 2 个 AZ,按照 N+1 的冗余要求,可以故障 1 个 AZ,冗余度是 50%,虽然达成了可用性的要求,但成本较高,有一半的机器是冗余的

  • 如果部署 3 个 AZ,按照 N+1 的冗余要求,冗余度为 33.33%,和 2 个 AZ 相比,成本节省 16.67%

  • 如果部署 10 个 AZ,按照 N+1 的冗余要求,冗余度为 10.00%,从成本角度看,非常不错。但是和 8 个 AZ 的情况相比,成本仅仅节省了 2.50%,而多维护两个机房的成本,可能会远远高于成本节省的 2.50%,且服务可能大量进行跨 AZ 交互,延时增加

跨 AZ 部署最佳实践之 Zookeeper

因此,一个服务应该选择几个 AZ,既有上面提到的隔离域的考量,也有成本和可用性之间的平衡,以及当下采用的技术方案对网络延时的要求等。所以,只有最适合的方案,而没有标准答案。

对于实现了异地多活部署能力的业务,一般来讲,其部署形式为:华北、华中、华南三个 Region,每个 Region 部署两个服务单元,整体形成六个服务单元。华北、华中、华南三个 Region 之间可以实现较好的隔离性,地震,洪水等各种严重自然灾害都不大会在三个 Region 间同时发生,因此从冗余度角度讲,可以防止任一单个 Region 的故障,因此从 Region 的冗余度看,依然还是 N+1 的标准。

跨 AZ 部署最佳实践之 Zookeeper

公众号介绍

智能运维公众号聚焦于运维领域,由一群BATJ的资深运维工程师所创建,在监控,部署,预案,混沌工程和故障分析等方向进行方法论和最佳实践的持续输出,目前有超20篇原创文章发表在InfoQ上,并在其他渠道广泛转载。

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐