字节跳动10万节点HDFS集群多机房架构演进之路 (字节跳动108亿美元贷款细节)

字节跳动10万节点HDFS集群多机房架构演进之路 (字节跳动108亿美元贷款细节)

背景

现状

HDFS 全称是 Hadoop Distributed File System,其本身是 Apache Hadoop 项目的一个模块,作为大数据存储的基石提供高吞吐的海量数据存储能力。自从 2006 年 4 月份发布以来,HDFS 目前依然有着非常广泛的应用,以字节跳动为例,随着公司业务的高速发展,目前 HDFS 服务的规模已经到达“双 10”的级别:

主要使用场景包括

业界很多公司在维护 HDFS 服务时,采用的都是小集群模式,即生产上部署多个隔离独立的 HDFS 集群满足业务的不同需求。字节跳动采用的是横跨多个机房的联邦大集群部署模式,即 HDFS 只有一个集群,这个集群有多个 nameservice,但是底层的 DN 是横跨 A/B/C 3 个机房的 ,由于社区版 HDFS 没有机房感知相关的支持,因此字节跳动 HDFS 团队在这个功能上做了专门的设计和实现,本文会介绍这部分的工作。

动机

业务的迅猛发展和业务场景的多样性给 HDFS 带来了很大的挑战,这里列几个比较有代表性的问题:

要回答这些问题需要 HDFS 从多个方向迭代优化,例如 DanceNN 的上线、运维平台的建设等,本文不会介绍字节跳动 HDFS 所有的演进方案,而是聚焦在 HDFS 多机房架构的演进策略上,它直接回答了上面提到的两个问题,即:

社区版架构

字节跳动的 HDFS 技术脱胎于 Apache 社区的 HDFS,为了方便大家理解内部版本的技术发展历程,本小节我们将先了解一下社区 HDFS 的架构。

图(1) Apache 社区 HDFS 架构

从图(1) 可以看出,社区 HDFS 从架构上划分可以分为 3 部分:

字节版架构

图(2) 字节跳动 HDFS 架构

对比图(1) 和 图(2), 我们可以发现,字节跳动的 HDFS 依然保留了社区 HDFS 的核心架构,同时也加入了一些特有的功能,包括:

值得一提的是,BookKeeper 本身提供了机房级别的保存配置策略,这是 HDFS 多机房容灾方案的基础,这个特性确保了 HDFS NameNode 提供跨机房容灾能力,后面我们将继续深入讨论。

演进

双机房

前面提到当前 HDFS 的大集群是横跨 A/B/C 的多机房模式,具体的演进顺序是 A -> A,B -> A,B,C ,现在也保持了直接扩展到更多机房的能力。本小节将着重介绍 A -> A,B 的双机房演进过程,后面的多机房架构的设计思想主要还是双机房架构的扩展。

数据放置

图(3) 字节跳动 HDFS 双机房>

HDFS 双机房数据放置方案在设计上总结起来可以描述如下:

这个设计的好处就是存储层对上层应用屏蔽了集群细节,计算资源可以直接无感分配。该设计结合离线数据一写多读的特点,充分考虑跨机房带宽的合理使用。

在实现上关键是 DanceNN 加入了机房的感知能力,DanceNN 在 client 进行数据操作时加入对机房拓扑的识别,由于 DanceNN 对外的协议没有改动,因此上层应用不需要做感知改动。

容灾设计

前面介绍了双机房架构里数据放置的设计,它解决了容量扩展的问题,但是并没有解决机房级别的容灾问题,尽管 NameNode 以一主多备的形式实现了高可用,但是所有 NameNode 还是放在一个机房,在字节跳动基础架构的容灾体系里,是需要做到机房级别的容灾。由于 HDFS 的数据已经实现了多机房数据副本的同步写入,为了达成容灾的目标,只需要把元数据也演进到双机房架构即可实现机房级别的容灾。前面我们所说的 HDFS 的元数据组件其实包含了两部分,即 NameNode 和 NameNode Proxy(NNProxy),由于 NNProxy 是无状态的转发服务,因此元数据的多机房架构我们只需要关注在 NameNode 设计上。

图(4) 字节跳动 HDFS NameNode 体系

从图(4) 可以看出 NameNode 包含了 3 个关键模块:

这 3 者构成一个分层的单向依赖关系链, DanceNN -> BookKeeper -> ZooKeeper,因此这 3 者可以独立完成双机房的容灾方案,最终在整体上呈现一个双机房容灾的 NameNode 元数据服务。

组件 多机房方案
一个 ZK ensemble 由 5 台 server 组成,这 5 台 server 分布在 3 个机房,分布比例为 A:B:C = 2:2:1
BookKeeper 一个 BK cluster 通常由 14 台 server 组成,分布在 2 个机房,分布比例为 1:1
一个 NameService 包含 5 个 DanceNN,这个 5 个 DanceNN 分布在 2 个机房,分布比例为 3:2,工作模式为 1 active + 4standby

在实现上,这里面的关键就是 DanceNN 的 editlog 机房写策略,因为 DanceNN 在做主备切换的时候,如果 editlog 没法保持同步,那么服务是不可用的,得益于 BookKeeper 的机房感知的数据放置功能,DanceNN 可以通过这些策略来完成双机房容灾方案。

旁路系统

前面已经介绍完了 HDFS 双机房方案的主体设计,但是事实上一个方案的推进落地除了架构上的迭代演进之外,还需要一系列的旁路系统来配合支持,包括:

限于篇幅,本文不会对这些展开细节描述,感兴趣的同学可以再交流。

多机房

HDFS 多机房架构是对双机房架构的扩展,其研发直接动机是机房的资源供应短缺问题,例如 2020 年 B 机房几乎就没有资源供应,但是在公司新的主机房 C 却有较为充裕的资源。一开始我们是尝试将 C 机房作为一个独立的集群提供服务,但是发现业务的血缘关系太过复杂,迁移成本太高,因此选择了基于双机房机房扩展到多机房的方法,该方案需要满足这些需求:

最终的设计方案为:

相应的旁路系统也做相应的调整,尽管 HDFS 底层提供了数据放置在多个机房的策略,但是在离线场景中,用户只能选择 2 个机房存放,例如 A/B, B/C,A/B,这个运营上的策略选择是综合考虑了稳定性、带宽使用的合理性以及资源的合理利用之后确定的,核心目标还是保障业务的平稳发展,从后续实践下来看,这个策略是一个非常正确的选择。

结语

根据我们的不完全调研,字节跳动 HDFS 的多机房架构在业界中是有自己独特的路线,这个中原因主要还是公司业务高速发展和机房建设方向在业界中也是独树一帜的,这些因素驱动 HDFS 进行自己独特迭代演进,从结果来看是达到预期,例如 2020 年 C 机房的充分使用,在 B 机房没有资源供应的情况下依然保障了业务的平稳;2021 春晚活动,为近线业务例如 ByteMQ、流式 CheckPoint 等提供了多机房的容灾策略保障。

最后,HDFS 的多机房架构依然在持续迭代,中长期来看,不排除有更多新机房的出现,这些都给 HDFS 多机房架构提出更多的挑战,原来多机房方案的基础条件不再具备,因此 HDFS 团队已经开启相关功能的迭代,敬请期待!

原文链接:字节跳动10万节点HDFS集群多机房架构演进之路

声明:本文来自用户分享和网络收集,仅供学习与参考,测试请备份。