写点什么

跨 AZ 部署最佳实践之 Zookeeper

  • 2019-08-23
  • 本文字数:1913 字

    阅读完需:约 6 分钟

跨 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 的标准。



2019-08-23 11:0713167

评论 2 条评论

发布
用户头像
az是什么?
2021-09-23 13:33
回复
Available zone 可用区。某个云厂商某个地区机房下的逻辑分组。
2022-03-08 15:33
回复
没有更多了
发现更多内容

Ipfs未来价值怎么样?Ipfs值得投资吗?

区块链 分布式存储 IPFS fil IPFS未来价值

第一次凡尔赛,字节跳动3面+腾讯6面一次过,谈谈我的大厂面经

Java~~~

Java 面试 微服务 多线程 架构师

维护数据隐私和增强竞争优势的秘密

九河云安全

写作7堂课——【1.框架式写作】

LeifChen

框架 结构化思维 写作技巧 8月日更

为什么拥抱能源的数字未来意味着在云上全力以赴

九河云安全

Linux内核分析学习路线总结(内核人员必看)

Linux服务器开发

操作系统 Linux内核 内核源码 内核开发 驱动开发

5 分钟,快速入门 Python JWT 接口认证

星安果

Python JWT

百度智能云遇到三一重机,工程机械维保有了新方案

百度大脑

人工智能 三一重工

番外1. OpenCV 图像处理之图片加载与视频加载

梦想橡皮擦

8月日更

开放搜索电商行业模版驱动业务增长实践

阿里云大数据AI技术

不愧为京东内部Spring Boot全解笔记,真的是把精髓全总结出来了

Java~~~

Java 面试 Spring Boot 架构师 京东

最全总结 | 聊聊 Python 数据处理全家桶(存储过程篇)

星安果

Python 数据库

在阿里晋升3次,5年拿下P8岗位,这份pdf记录了我的整个成长过程

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

Spark 架构剖析:一个任务是怎么运行的

程序员赤小豆

大数据 spark 架构

阿里首席官珍藏,SpringCloud精通日记,血汗全在这了

Java~~~

Java 面试 微服务 Spring Cloud 架构师

632页!我熬夜读完这份“高分宝典”,竟4面拿下字节跳动offer

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

一个弱鸡管理者如何带领一支牛逼的队伍?

弱鸡管理者

安全 技术人 创新 技术人应知的创新思维模型 管理经验

云计算以及云计算周边词概念简单介绍-行云管家

行云管家

云计算 服务器 云服务

50 亿观众的 “云上奥运”,顶级媒体背后的数智化力量

阿里云视频云

阿里云 直播技术 视频制作 视频云 奥运

FIL分币平台|FIL算力系统软件开发技术

量化系统19942438797

#区块链# fil币

面试阿里P6,过关斩将直通2面,结果3面找了个架构师来吊打我?

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

看完字节大佬的算法刷题宝典,我直接手撕了500道算法算法题

Java~~~

Java 面试 算法 二叉树 架构师

华为大神珍藏版:SpringBoot全优笔记,面面俱到太全了

Java~~~

Java 面试 微服务 Spring Boot 架构师

【共识专栏】Quorum机制与PBFT

趣链科技

区块链 共识机制 PBFT 共识算法

三面阿里被挂,竟获内推名额,历经5面拿下口碑offer(Java后台)

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

去中心化市值管理机器人开发|去中心化做市机器人

Geek_23f0c3

量化交易机器人系统开发 市值管理机器人系统开发 去中心化市值管理机器人

镜像是什么意思?分类有哪些?

行云管家

网络安全 镜像 堡垒机 云厂商

Python RPC 不会?不妨看看这篇文章

星安果

Python RPC RPC架构

跨 AZ 部署最佳实践之 Zookeeper_运维_焦振清_InfoQ精选文章