这是我参与「第四届青训营」笔记创作活动的第八天

HDFS 高可用和高扩展机制分析

一、元数据高可用

高可用：系统在困境（adversity，比如硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）

容灾：在相隔较远的异地，建立两套或多套功能相同的系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外（如火灾、地震等）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。

1.1 高可用的需求

1.1.1 高可用的衡量——故障度量的指标

MTTR（Mean Time To Repair）：平均修复时间，系统能多快恢复。
MTTF（Mean Time To Failure）：平均失效时间，运行到故障间的时间，一般用于不可修复的系统（制造业）。
MTBF（Mean Time Between Failures）：平均无故障时间，两次故障间的间隔，一般用于可修复的系统（软件）。

1.1.2可用性的年化

全年不可用时间：系统运行一整年的不可用时间的目标。

1.1.3 高可用形式

1、备份方式

冷备份：备份服务的数据，可以和数据归档相结合。在主服务故障时，利用备份的数据重启。
热备份：主服务和备服务同时运行，在主服务故障时，随时可以切换到备服务。

2、切换方式

人工切换：在故障发生时，运维人员接收报警后，手动执行服务切主操作。一般较慢，难以满足全年不可用时间的目标。
自动切换：通过探活组件、分布式共识协议等手段，系统能自动发现主服务的故障，并切换到备份不符。

1.2 HDFS 的高可用架构

1.2.1 组件介绍

Active NameNode：提供服务的 NameNode 主节点，生产 editlog。
Standby NameNode：不提供服务，起备份作用的 NameNode 备节点，消费 editlog
editlog：用户变更操作的记录，具有全局顺序，是 HDFS 的变更日志。
ZooKeeper：开源的分布式协调组件，主要功能有节点注册、主节点选举、元数据存储。
BookKeeper：开源的日志存储组件，存储 editlog
ZKFC：和 ZK、NN 通信，进行 NN 探活和自动主备切换。
HA Client：处理 StandbyException，在主备节点间挑选到提供服务的主节点。

1.2.2 理论基础-状态机复制和日志

变更日志：触发状态机更新的变更操作，具有全局确定的顺序。
共识协议：确保每个副本都能收到相同的日志的共识协议，常见的有 Paxos、Raft、ZAB。
单点故障 SPOF：指系统中一旦失效，就会让整个系统无法运作的组件。
状态机复制模型：实现容错服务的一种常规方法，主要通过复制服务器，并协调客户端和这些服务器镜像间的交互来达到目标。这个方法也同时提供了理解和设计复制管理协议的一套基本框架。
状态机：一个状态机从“初始”状态开始，每一个输入都被传入转换函数和输出函数，以生成一个新的状态和输出。在新的输入被接收到前，状态保持不变，而输出同时被传输给恰当的接受者。
状态机复制：确定性的状态机具有「处理确定的输入后，状态唯一确定」的特性。状态机复制利用这个特性实现多个相同的状态机副本的同步更新。

1.2.3 NameNode状态持久化

FSImage 文件：较大的状态记录文件，是某一时刻 NN 全部需要持久化的数据的记录。大小一般在 GB 级别。
EditLog 文件：是某段时间发生的变更日志的存储文件。大小一般在 KB~MB 级别。
checkpoint 机制：将旧的 FSImage 和 EditLog 合并生成新的 FSImage 的流程，在完成后旧的数据可以被清理以释放空间。

1.2.4 NameNode操作日志的生产消费

物理日志：存储了物理单元（一般是磁盘的 page）变更的日志形式。
逻辑日志：存储了逻辑变更（例如 rename /a to /b）的日志形式。

1.3 自动主备切换

1.3.1 分布式协调组件 -ZooKeeper

ZooKeeper 是广泛使用的选主组件，它通过 ZAB 协议保证了多个 ZK Server 的状态一致，提供了自身的强一致和高可用。
ZooKeeper 的访问单位是 znode，并且可以确保 znode 创建的原子性和互斥性（CreateIfNotExist）。client 可以创建临时 znode，临时 znode 在 client 心跳过期后自动被删除。
ZK 提供了 Watch 机制，允许多个 client 一起监听一个 znode 的状态变更，并在状态变化时收到一条消息回调（callback）。
基于临时 znode 和 Watch 机制，多个客户端可以完成自动的主选举。

1.3.2 自动主备切换流程 -Server侧

ZKFailoverController：一般和 NN 部署在一起的进程，负责定时查询 NN 存活和状态、进行 ZK 侧主备选举、执行调用 NN 接口执行集群的主备状态切换、执行 fence 等能力。
脑裂问题：因为网络隔离、进程夯住（例如 Java GC）等原因，旧的 active NN 没有完成下主，新的 active NN 就已经上主，此时会存在双主。client 的请求发给两者都可能成功，但不能保证一致性（两个 NN 状态不再同步）和持久化（只能保留一个 NN 状态）。
fence 机制：在新 active NN 上主并正式处理请求之前，先要确保旧 active NN 已经退出主节点的状态。一般做法是先用 RPC 状态检测，发现超时或失败则调用系统命令杀死旧 active NN 的进程。
Hadoop 将集群主备选举的能力和 NN 的服务放在了不同的进程中，而更先进的系统一般会内置在服务进程中。

1.4 高可用日志系统 BookKeeper

1.4.1 BookKeeper架构

BookKeeper特点

高可靠：数据写入多个存储节点，数据写入就不会丢失。
高可用：日志存储本身是高可用的。因为日志流比文件系统本身的结构更为简单，日志系统高可用的实现也更为简单。
强一致：日志系统是追加写入的形式，Client 和日志系统的元数据可以明确目前已经成功的写入日志的序号（entry-id）。
可扩展：整个集群的读写能力可以随着添加存储节点 Bookie 而扩展。

1.4.2 Quorum机制 - 参考：Quorum 协议

基于鸽巢原理，在多个副本间确保高可用、高性能的多副本变更协议

多副本间一般通过 version-id 来描述状态的新旧。
高可用：多个副本确保了高可用（后文会再次介绍多副本高可用）。
高性能：不用等所有副本写入成功，降低了的长尾延迟（后文会再次介绍长尾延迟）。

1.4.3 BookKeeper Quorum

基于 Quorum 的多数派思想来提供高可用、高性能写入的日志写入

日志写入是追加，不是状态变更，只需要确认目前的 entry-id，相对更简单。
Write Quorum：一次写入需要写入到的存储节点数。
Ack Quorum：一次写入需要收到的响应数，小于 write quorum。
高性能：不用等所有副本写入成功，降低了的长尾延迟（后文会再次介绍长尾延迟）。
Ensemble：通过轮询（Round-Robin）来确认 write quorum 实际对应的存储节点实例，可以比较简单的完成副本放置和扩展。

1.4.4 BookKeeper Ensemble

优势：数据均衡

二、数据高可用

2.1 单机存储的数据高可用机制

2.1.1 回到单机存储RAID

RAID：将多个廉价、不可靠、低性能、容量小的磁盘组装在一起，提供高可靠、高性能、大容量逻辑磁盘服务的一组磁盘列阵方案。

2.1.2 RAID方案讲解

RAID 0 ：将数据分块后按条带化的形式分别存储在多个磁盘上，提供大容量、高性能。
RAID 1：将数据副本存储在多个磁盘上，提供高可靠。
RAID 3：在数据分块存储的基础上，将数据的校验码存储在独立的磁盘上，提供高可靠、高性能。
其他可以参考 RAID

2.2HDFS的数据高可用机制

2.2.1 HDFS多副本

将数据块存储在多个 DN 上优点：

读写路径简单
副本修复简单
高可用

2.2.2 Erasure Coding原理

将数据分段，通过特殊的编码方式存储额外的校验块，并条带化的组成块，存储在 DN 上。

条带化：原本块对应文件内连续的一大段数据。条带化后，连续的数据按条带（远小于整个块的单位）间隔交错的分布在不同的块中。
Reed Solomon 算法：参考 Reed-solomon codes

成本更低：多副本方案需要冗余存储整个块，EC 方案需要冗余存储的数据一般更少。

2.3考虑网络架构的数据高可用

2.3.1 网络架构

机架/机柜：将几个服务器统一供电、提供对外网络的固定的物理设备。
TOR （top of rack）：机架顶部（或底部）的交换机，负责机架内服务器和数据中心的其他服务器的网络通信。
机房：强调的基础设施建设，例如物理承重、空调、防水、消防。
数据中心：强调机房的业务属性。
网络拓扑：按数据中心->机架->机器的顺序，描述进程在网络空间中所处的位置。

跨机房专线：由网络服务商提供，连接机房的专用网络。
- 稳定性和安全性好于公网。
- 相比于数据中心内网络，吞吐更为有限、延迟更高、成本更高。

2.3.2 副本放置策略——机架感知

故障域是基础设施中可能发生故障的区域或组件。每一个域都有自己的风险和挑战，由个别几个因素决定整个故障域的服务能力，需要进行架构。
机架感知：以 TOR 为关键点，机架是一个故障域。数据副本全部放置在一个机架中，当相应 TOR 故障时数据就无法访问。
机房感知：以机房的基础设施（空调、电力）和跨机房专线为关键点，它们发生故障时整个机房会发生故障，导致不可用。

2.4案例：字节跳动的HDFS多机房容灾方案简介

多机房容灾：服务和数据需要存放在多个机房，并配合合理的架构。使得发生机房故障时依然可以提供服务。

多机房部署的组件

zookeeper
BookKeeper
NameNode
DataNode

三、元数据高扩展性

3.1 元数据扩展性的挑战

HDFS NameNode是个集中式服务，部署在单个机器上，内存和磁盘的容量、CPU 的计算力都不能无限扩展。

scale up：通过单机的 CPU、内存、磁盘、网卡能力的提升来提升系统服务能力，受到机器成本和物理定律的限制。
scale out：通过让多台机器组成集群，共同对外提供服务来提升系统服务能力。一般也称为高扩展、水平扩展。 scale up Vs. scale out
扩容单个服务器的能力
部署多个服务器来服务

挑战

名字空间分裂
DataNode汇报
目录树结构本身复杂

3.2 社区解决方案

3.2.1 BlockPool方案

将文件系统分为文件层和块存储层，对于块存储层，DN 集群对不同的 NN 提供不同的标识符，称为 block pool。
解决了多个 NN 可能生成同一个 block id，DN 无法区分的问题。

3.2.2 viewfs方案

邦联架构的一种实现，通过客户端配置决定某个路径的访问要发送给哪个 NN 集群。
缺点：客户端配置难以更新、本身配置方式存在设计（例如，只能在同一级目录区分；已经划分的子树不能再划分）。

3.3 Proxy 方案介绍

3.3.1 字节跳动的NNProxy

下图：NNProxy所在系统上下游

ByteDance 自研的 HDFS 代理层，于 2016 年开源，项目地址： github.com/bytedance/n…
主要提供了路由管理、RPC 转发，额外提供了鉴权、限流、查询缓存等能力。
开源社区有类似的方案 Router Based Federation，主要实现了路由管理和转发。

3.4 案例：小文件问题

HDFS 设计上是面向大文件的，小于一个 HDFS Block 的文件称为小文件。
元数据问题：多个小文件相对于一个大文件，使用了更多元数据服务的内存空间。
数据访问问题：多个小文件相对于一个大文件，I/O 更加的随机，无法顺序扫描磁盘。
计算任务启动慢：计算任务在启动时，一般会获得所有文件的地址来进行 MapReduce 的任务分配，小文件会使得这一流程变长。
典型的 MR 流程中，中间数据的文件数和数据量与 mapper*reducer 的数量成线性，而为了扩展性，一般 mapper 和 reducer 的数量和数据量成线性。于是，中间数据的文件数和数据量与原始的数据量成平方关系。
小文件合并任务：计算框架的数据访问模式确定，可以直接将小文件合并成大文件而任务读取不受影响。通过后台运行任务来合并小文件，可以有效缓解小文件问题。通过 MapReduce/Spark 框架，可以利用起大量的机器来进行小文件合并任务。
Shuffle service：shuffle 流程的中间文件数是平方级的，shuffle service 将 shuffle 的中间数据存储在独立的服务上，通过聚合后再写成 HDFS 文件，可以有效地缓解中间数据的小文件问题。

四、数据扩展性

4.1 超大集群的长尾问题

4.1.1 延迟的分布和长尾延迟

长尾

二八定律：在任何一组东西中，最重要的只占其中一小部分，约 20%，其余 80% 尽管是多数，却是次要的。
长尾：占绝大多数的，重要性低的东西就被称为长尾。下图为延迟的长尾

百分位延迟

将所有请求的响应速度从快到慢排序，取其中某百分位的请求的延迟时间。
例如 pct99 代表排在 99% 的请求的延迟。相对于平均值，能更好的衡量长尾的情况。

下图为延迟的分布

4.1.2 尾部延迟放大

木桶原理：并行执行的任务的耗时取决于最慢的一个子任务。
尾部延迟放大：一个请求或任务需要访问多个数据节点，只要其中有一个慢，则整个请求或任务的响应就会变慢。
固定延迟阈值，访问的集群越大，高于该延迟的请求占比越高。
固定延迟百分位，访问的集群越大，延迟越差。

4.1.3 长尾问题的表现

尾部延迟放大+集群规模变大，使得大集群中，尾部延迟对于整个服务的质量极为重要。
慢节点问题：网络不会直接断联，而是不能在预期的时间内返回。会导致最终请求不符合预期，而多副本机制无法直接应对这种问题。
高负载：单个节点处理的请求超过了其服务能力，会引发请求排队，导致响应速度慢。是常见的一个慢节点原因。

4.2 超大集群的可靠性问题

4.2.1 超大集群下的数据可靠性

超大集群下，一定有部分机器是损坏的，来不及修理的。
随机的副本放置策略，所有的放置组合都会出现。而 DN 容量够大，足够
三副本，单个 DN 视角：容量一百万，机器数量一万。那么另外两个副本的排列组合有一亿种，容量比放置方案大约百分之一。
三副本，全局视角：一万台机器，每台一百万副本，损坏 1%（100 台）。根据排列组合原理，大约有 1009998/(1000099999998) (100000010000)=9704 个坏块
callback 一下，叠加长尾问题。每个任务都要访问大量的块，只要一个块丢失就整个任务收到影响。导致任务层面的丢块频发，服务质量变差。

4.2.3 Copyset

降低副本放置的组合数，降低副本丢失的发生概率。
修复速度：DN 机器故障时，只能从少量的一些其他 DN 上拷贝数据修复副本。

4.3 超大集群的不均匀问题

4.3.1 超大集群的负载均衡和数据迁移

负载均衡的意义

避免热点
- 机器热点会叠加长尾问题，少数的不均衡的热点会影响大量的任务。
降低成本：
- 数据越均衡，CPU、磁盘、网络的利用率越高，成本更低。
- 集群需要为数据腾挪预留的空间、带宽更少，降低了成本。
可靠性
- 全速运行的机器和空置的机器，以及一会全速运行一会空置的机器，可靠性表现都有不同。负载均衡可以降低机器故障的发生。
- 同一批机器容易一起故障，数据腾挪快，机器下线快，可以提升可靠性。

负载均衡性影响因素：多个复杂因素共同影响负载均衡性

不同节点上的业务量的平衡
数据放置策略
数据搬迁工具的能力
系统环境

4.3.2 数据写入不均

数据的不均匀
- 节点容量不均匀
- 数据新旧不均匀
- 访问类型不均匀（见下图）

资源负载不均匀

4.3.3 DN冷热不均

DN 上线：新上线的机器没有任何数据，而且只会有新数据写入。需要迁移其他 DN 的旧数据到新 DN 上，使得负载和数据冷热均衡。
DN 下线：需要下线的机器，需要提前将数据迁移走再停止服务，避免数据丢失的风险。
机房间均衡：因为资源供应、新机房上线等外部条件，机房规划、业务分布等内部条件，不同机房的资源量和资源利用率都是不均衡的。需要结合供应和业务，全局性的进行资源均衡。
日常打散：作为日常任务运行，不断地从高负载、高容量的机器上搬迁数据到低负载、低容量的机器上，使得整个集群的负载均衡起来。

4.3.4 负载均衡和数据迁移的典型场景

4.4 数据迁移工具速览

目的：将数据从一部分节点搬迁到另一部分节点。
要求：高吞吐、不能影响前台的服务。
痛点：涉及到元数据操作，需要停止用户的写入。

4.4.1 数据迁移工具——跨NN迁移

DistCopy 工具
- 通过 MapReduce 任务来并行迁移数据，需要拷贝数据和元数据，流量较大，速度较慢。
- 网络流量较大，速度较慢。
FastCopy 工具
- 前提条件: 新旧集群的DN列表吻合
- 基于 hardlink 和 blockpool 的原理
- 元数据直接在 NN 集群间拷贝，而数据则在 DN 上的不同 blockpool（对应到 NN 集群）进行 hardlink，不用数据复制。
- 迁移速度要大大优于 DistCopy。

4.4.2 数据迁移工具 —— Balancer工具

代替 NN 向 DN 发起副本迁移的命令，批量执行副本迁移。
场景：大规模数据平衡、机器上下线。

HDFS 高可用和高扩展机制分析 | 青训营笔记