HDFS高可用与高扩展性机制分析｜青训营笔记

二个二个二
67 阅读15分钟

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

一、笔记内容 

1. HDFS元数据服务的高可用

2. HDFS数据存储高可用

3. HDFS元数据服务的高扩展性

4. HDFS数据存储的高扩展性

二、HDFS元数据服务的高可用

1.高可用的需求

1.高可用的作用

高可用：系统在困境（adversity）中仍可正常工作（正确完成功能，并能达到期望的性能水准）。

故障类型:

  • 硬件故障

  • 软件故障

  • 人为故障

灾难（数据中心级别不可用）

  • 机房断电

  • 机房空调停机

  • 机房间网络故障、拥塞

2.高可用的衡量

image.png

 

  • MTTR（Mean Time To Repair） ：平均修复时间，系统能多快恢复。【对应图中故障发生到恢复正常的阶段】

  • MTTF（Mean Time To Failure） ：平均失效时间，运行到故障间的时间，一般用于不可修复的系统（制造业）。

  • MTBF（Mean Time Between Failures） ：平均无故障时间，两次故障间的间隔，一般用于可修复的系统（软件）。

可用性的年化：

image.png

全年不可用时间

可用性99.9%，全年8.76小时不可用；

可用性 99.99%，全年52.6分钟不可用；

可用性99.999%，全年5.26分钟不可用。

3.高可用的形式

  • 备份方式

    • 冷备份：备份服务的数据，可以和数据归档相结合。在主服务故障时，利用备份的数据重启。

    • 热备份：主服务和备服务同时运行，在主服务故障时，随时可以切换到备服务。

  • 切换方式

    • 人工切换：在故障发生时，运维人员接收报警后，手动执行服务切主操作。一般较慢，难以满足全年不可用时间的目标。

    • 自动切换：通过探活组件、分布式共识协议等手段，系统能自动发现主服务的故障，并切换到备份不符。

人工的反应、决策时间都更长，高可用需要让系统自动决策。

HDFS的设计中，采用了中心化的元数据管理节点 NameNode。NameNode容易成为故障中的单点(single point of failure).

单点故障 SPOF：指系统中一旦失效，就会让整个系统无法运作的组件。

2.HDFS主备同步实现

1.HDFS高可用架构

image.png

1. Active NameNode：提供服务的 NameNode 主节点，生产 editlog。

2. Standby NameNode：不提供服务，起备份作用的 NameNode 备节点，消费 editlog

3. edit log：用户变更操作的记录，具有全局顺序，是 HDFS 的变更日志。

4. ZooKeeper：开源的分布式协调组件，主要功能有节点注册、主节点选举、元数据存储。

5. BookKeeper：开源的日志存储组件，存储 editlog

6. ZKFC：和 ZK、NN 通信，进行 NN 探活和自动主备切换。

7. HA Client：处理 StandbyException，在主备节点间挑选到提供服务的主节点。

2.理论基础：状态机复制和日志

状态机复制是实现容错的常规方法。

image.png

组件

  • 状态机以及其副本

  • 变更日志

  • 共识协议

3.NameNode 状态持久化

 

image.png

上图为目录树和文件信息的更新；Active生产、Standby消费。

物理日志：存储了物理单元（一般是磁盘的 page）变更的日志形式。

逻辑日志：存储了逻辑变更（例如 rename /a to /b）的日志形式。

日志文件：

  • FSImage 文件：较大的状态记录文件，是某一时刻 NN 全部需要持久化的数据的记录。大小一般在GB 级别。

  • EditLog 文件：是某段时间发生的变更日志的存储文件。大小一般在 KB~MB 级别。

  • checkpoint 机制：将旧的 FSImage 和 EditLog 合并生成新的 FSImage 的流程，在完成后旧的数据可以被清理以释放空间。

4.块状态维护

DataNode Heartbeat

DataNode Block Report

区别：

  • Active既接收，也发起变更。

  • Standby只接收，不发起变更。

问题：

DataNode 心跳与块汇报需要同时向 active NameNode和 standby NameNode上报，让两者可以同时维护块信息。但只有 active NameNode会下发 DN 的副本操作命令，这可能导致数据的不一致问题。

解决问题：Content Stale状态

主备切换后，避免DN的不确定状态。

在发生主备切换后，新 active NN 会标记所有 DN 为 content stale 状态，代表该 DN 上的副本是不确定的，某些操作不能执行。直到一个 DN 完成一次全量块上报，新 active NN 才标记它退出了 content stale 状态。

3.HDFS自动主备切换

1.分布式协调组件：ZooKeeper

一般用于提供选主、协调、元数据存储

使用 ZooKeeper 的组件:

  • HDFS、YARN、HBase

  • Kafka、ClickHouse

HA核心机制：Watch

2.自动主备切换流程：Server侧

ZKFailoverController： 作为外部组件，驱动HDFS NameNode的主备切换

  • 轮询探活

  • 脑裂问题：因为网络隔离、进程夯住（例如 Java GC）等原因，旧的 active NN 没有完成下主，新的 active NN 就已经上主，此时会存在双主。client 的请求发给两者都可能成功，但不能保证一致性（两个 NN 状态不再同步）和持久化（只能保留一个 NN 状态）。

  • Fence机制：在新 active NN 上主并正式处理请求之前，先要确保旧 active NN 已经退出主节点的状态。一般做法是先用 RPC 状态检测，发现超时或失败则调用系统命令杀死旧 active NN 的进程。

4.日志系统 BookKeeper 简介

1.BookKeeper架构

BookKeeper存储日志

  • 低延时

  • 持久性强

  • 一致性

  • 读写高可用

 

image.png

2.Quorum机制

image.png

Quorum机制：多副本—致性读写

场景：多副本对象存储，用版本号标识数据新旧

规则

1. Qr + Qw > Q

2. Qw > Q / 2

3.BookKeeper Quorum

image.png

Sloppy Quorum机制

日志场景：顺序追加、只写

  • Write Quorum：写入副本数，一次写入需要写入到的存储节点数。

  • Ack Quorum：响应副本数，一次写入需要收到的响应数，小于 write quorum。

3.BookKeeper Ensemble

Ensemble 机制： 通过轮询（Round-Robin）来确认 write quorum 实际对应的存储节点实例，可以比较简单的完成副本放置和扩展。

image.png

Round-Robin Load Balancer

第一轮:1,2,3

第二轮:2,3,4

第三轮:3,4,1

第四轮:4,1,2

优势：数据均衡。

三、HDFS数据存储高可用

1.单机存储的数据高可用机制

1.单机存储：RAID

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

特点

  • 廉价

  • 高性能大容量

  • 高可用

RAID方案

image.png

RAID 0：条带化，将数据分块后按条带化的形式分别存储在多个磁盘上，提供大容量、高性能。

image.png

RAID 1：冗余，将数据副本存储在多个磁盘上，提供高可靠。

image.png

RAID 3：容错校验，在数据分块存储的基础上，将数据的校验码存储在独立的磁盘上，提供高可靠、高性能。

2. HDFS的数据高可用机制

1.HDFS多副本

HDFS版本的RAID 1

Hadoop的多副本放置

image.png

优点：

  • 读写路径简单

  • 副本修复简单

  • 高可用

缺点：高成本

 

2.Erasure Coding

  HDFS版本的RAID 2/3

业界常用Reed Solomon算法

Reed Solomon算法原理

image.png

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

3.HDFS Erasure Coding

HDFS版本的RAID 2

直接保存的EC和Stripe(条带化)后保存的EC

image.png

条带化和多副本比较****

优点：

  • 读写速度更快

  • 成本更低

  • 修复速度更快

缺点：读写路径的实现更为复杂

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

1.网络架构

机架(Rack)：放服务器的架子，将几个服务器统一供电、提供对外网络的固定的物理设备。

TOR(Top of Rack)：机架顶部的交换机，架顶部（或底部）的交换机，负责机架内服务器和数据中心的其他服务器的网络通信。

数据中心(Data Center)：集中部署服务器的场所，强调机房的业务属性。

机房：强调的基础设施建设，例如物理承重、空调、防水、消防。

网络拓扑图

image.png

  ### 2.副本放置策略―机架感知

问题：

  • —个TOR故障导致整个机架不可用；

  • 降低跨rack流量

HDFS的多机架放置

image.png

4.案例:字节跳动的HDFS多机房容灾方案简介

1.字节跳动的HDFS 多机房实践

字节跳动的 HDFS集群，从单机房演进到双机房，再从双机房演进到更多的机房。

image.png

多机房解决的问题

  • 容量问题

  • 容灾问题

HDFS 双机房放置的设计

  • 写入时，每个数据块在两个机房至少各有一个副本，数据实时写入到两个机房。

  • 读取时，优先读本地的副本，避免了大量的跨机房读取。

2.多机房容灾实践

多机房部署的组件

  • ZooKeeper

  • BookKeeper

  • NameNode

  • DataNode

容灾期间的策略:

  • 容灾期间，限制跨机房写入

  • 容灾期间，限制跨机房副本复制

四、HDFS元数据服务的高扩展性

1.元数据扩展性挑战

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

image.png

Scale Up：单机，扩容单个服务器的能力。通过单机的 CPU、内存、磁盘、网卡能力的提升来提升系统服务能力，受到机器成本和物理定律的限制。

Scale Out：多机，部署多个服务器来服务。通过让多台机器组成集群，共同对外提供服务来提升系统服务能力。一般也称为高扩展、水平扩展。

挑战

  • 名字空间分裂

  • DataNode汇报

  • 目录树结构本身复杂

常见的Scale Out方案：

KV模型的系统可以使用partition，partition 一般都水平分区，又称 shard。

  • Redis

  • Kafka

  • MySQL(分库分表)

水平分区：按 key 来将数据划分到不同的存储上；

垂直分区：将一份数据的不同部分拆开存储，用 key 关联起来。

image.png

三种数据路由方式

  • 服务端侧

  • 路由层

  • 客户端则

2.社区的解决方案

1.blockpool

image.png

blockpool：将文件系统分为文件层和块存储层，对于块存储层，DN 集群对不同的 NN 提供不同的标识符，称为 block pool。

解决问题：解决DN同时服务多组NN的问题

文件服务分层

  • Namespace

  • Block Storage

用blockpool来区分DN的服务

  • 数据块存储

  • 心跳和块上报

2.viewfs

viewfs：邦联架构的一种实现，通过客户端配置决定某个路径的访问要发送给哪个 NN 集群。

Federation架构：将多个不同集群组合起来，对外表现像一个集群—样。

viewfs通过在client-side的配置,指定不同的目录访问不同的 NameNode。

image.png

局限性： 运维复杂，客户端配置难以更新、本身配置方式存在设计（例如，只能在同一级目录区分；已经划分的子树不能再划分）

3.字节跳动的NNProxy方案

NNProxy：ByteDance自研的HDFS代理层，提供了路由服务。主要实现了路由管理和RPC转发，以及鉴权、限流、查询缓存等额外能力。

NNProxy所在系统上下游

image.png

NNProxy路由规则保存考虑点：扩展性、运维性

路由规则的保存

image.png

NNProxy路由转发实现

目录树视图

image.png

路径最长匹配规则

1. /

2. /home/user/bob

3. /user/tiger/warehouse

4. /user/tiger/dump

4.案例:小文件问题

小文件问题(LSOF, lots of small files)  ：大小不到—个HDFS Block 大小的文件过。

  • NameNode瓶颈

  • 1/O变小，数据访问变慢

  • 计算任务启动慢

MapReduce 的 worker数量过多容易引起小文件问题

image.png

解决方案：

  • 后台任务合并小文件

  • Shuffle Service

五、HDFS数据存储的高扩展性

1.超大集群的长尾问题

1.延迟的分布和长尾延迟

image.png

延迟的分布 :

  • 用百分数来表示访问的延迟的统计特征

  • 例如 p95延迟为1ms，代表95%的请求延迟要低于1ms,但后5%的请求延迟会大于1ms.

长尾延迟：尾部(p99/p999/p999)的延迟，衡量系统最差的请求的情况。会显著的要差于平均值。

2.尾部延迟放大

[ 木桶原理 ] 尾部延迟放大：访问的服务变多，尾部的请求就会越发的慢。

尾部延迟放大，整个服务被Backend 6拖累

image.png

确定延迟（控制变量法）

  • 固定延迟阈值，访问的集群越大， 高于该延迟的请求占比越高。

  • 固定延迟百分位，访问的集群越大，延迟越差。

3.长尾问题的表现：慢节点

慢节点：读取速度过慢，导致客户端阻塞。

慢节点的发生难以避免和预测

  • 共享资源、后台维护活动、请求多级排队、功率限制

  • 固定的损耗:机器损坏率

  • 混沌现象

离线任务也会遇到长尾问题

  • 全部任务完成时间取决于最慢的任务什么时候完成。

  • 集群规模变大，任务的数据量变大。

  • 只要任何数据块的读取受到长尾影响，整个任务就会因此停滞。

集群扩大10倍，问题扩大N(>10)倍 

2.超大集群的可靠性问题

 

1.可靠性问题的产生 

条件一：超大集群下，有一部分机器是损坏来不及修理的。

条件二：副本放置策略完全随机。

条件三：DN的容量足够大。

推论 ：必然有部分数据全部副本在损坏的机器上，发生数据丢失。

叠加长尾问题，容易导致整个任务无法执行下去。

2.Copyset

image.png

将DataNode 分为若干个 Copyset选块在copyset内部选择。

原理：减少了副本放置的组合数，从而降低副本丢失的概率。

缺点：

  • 数据丢失后的影响面变大；

  • 修复速度变慢。

3.超大集群的不均匀问题

1.负载均衡的意义

1. 避免热点：机器热点会叠加长尾问题，少数的不均衡的热点会影响大量的任务。

2. 降低成本

  • 数据越均衡，CPU、磁盘、网络的利用率越高，成本更低。

  • 集群需要为数据腾挪预留的空间、带宽更少，降低了成本。

3. 可靠性

  • 全速运行的机器和空置的机器，以及一会全速运行一会空置的机器，可靠性表现都有不同。负载均衡可以降低机器故障的发生。

  • 同一批机器容易一起故障，数据腾挪快，机器下线快，可以提升可靠性。

2.集群的不均衡情况

数据的不均匀

  • 节点容量不均匀：机器上的数据量不均衡，可能是各种复杂情况导致，归根结底是混沌现象。。

  • 数据新旧不均匀：机器上的数据新旧不均匀，例如：新上线的机器，不做任何数据均衡的情况下，只会有新写入的数据。而一般新数据更容易被读取。

  • 访问类型不均匀：机器上的数据访问类型不均衡，例如：机器学习训练需要反复读取数据，小 I/O 更多。而大数据场景一般只扫描一次，大 I/O 为主。这两种模式的读写比不同，I/O pattern 不同，就来带访问冷热的不同。

资源负载不均匀：机器上的访问请求吞吐、IOPS 不均衡，导致最终机器冷热不均、负载不均。一般由于容量不均、新旧不均、模式不均导致。

3.集群的不均衡情况

image.png

4.数据迁移工具速览

1.DistCopy

  • 基于MapReduce，通过一个个任务，将数据从一个NameNode拷贝到另一个 NameNode。

  • 需要拷贝数据，流量较大，速度较慢。

2.FastCopy

1. 开源社区的无需拷贝数据的快速元数据迁移方案

2. 前提条件:新旧集群的DN列表吻合

3. 对于元数据，直接复制目录树的结构和块信息。

4. 对于数据块，直接要求DataNode从源 BlockPool hardlink 到目标BlookPool，没有数据拷贝。

5. hardlink:直接让两个路径指向同一块数据。

3.Balancer 

image.png

工具向DataNode 发起迁移命令，平衡各个DataNode的容量。

场景:

  • 单机房使用、多机房使用

  • 限流措施 

评价标准：

  • 稳定性成本

  • 可运维性

  • 执行效率

结语：

HDFS作为大数据离线分析场景的核心组件，高可用和高扩展性是架构设计的重中之重。

高可用确保了业务能稳定运行，HDFS上存储的数据随时可以访问。

高扩展性确保了HDFS能存储的数据星能随着资源投入无限扩展下去，业务发展不被基础组件拖累。

参考文章：juejin.cn/post/712494…

avatar
文章
阅读
粉丝