跨 AZ 部署最佳实践之 Zookeeper

作者：焦振清

跨 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 部署方案（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，既有上面提到的隔离域的考量，也有成本和可用性之间的平衡，以及当下采用的技术方案对网络延时的要求等。所以，只有最适合的方案，而没有标准答案。

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

公众号介绍

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