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

Rainbow_Sea
221 阅读10分钟

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

今天是大数据专场基础班的第九次课，主要内容是介绍HDFS 高可用与高扩展性机制分析，主要分为下面四个板块。

一、 元数据高可用

1. 高可用的需求

1.1 服务高可用的需求

  • 故障类型:
    • 硬件故障
    • 软件故障
    • 人为故障
  • 灾难:数据中心级别不可用
    • 机房断电
    • 机房空调停机
    • 机房间网络故障、拥塞 **故障不可避免，灾难时有发生
  • 而如果HDFS 系统不可用
    • 无法核算广告账单，直接引发收入损失
    • 无法生产数据报表，数据驱动无从谈起
    • 无法进行模型训练，用户体验越来越差
  • 业务停止的损失极大，所以 HDFS 系统的高可用性就至关重要

1.2 高可用的衡量

  • 服务可用性指标
    • MTTR
    • MTTF
    • MTBF

image.png

1.3 可用性的年化

可用性:

image.png

  • 全年不可用时间
    • 可用性99.9%，全年8.76小时不可用
    • 可用性99.99%，全年52.6分钟不可用
    • 可用性99.999%，全年5.26分钟不可用

1.4 高可用的形式

  • 服务高可用
    • 热备份
    • 冷备份
  • 故障恢复操作
    • 人工切换
    • 自动切换 人工的反应、决策时间都更长，高可用需要让系统自动决策。

HDFS的设计中，采用了中心化的元数据管理节点NameNode。

NameNode容易成为故障中的单点(single point of failure) .

2. HDFS主备同步实现

2.1 HDFS NameNode高可用架构

  • 组件介绍
    • ActiveNamenode:主节点，提供服务，生产日志
    • StandbyNamenode:备节点，消费日志
    • ZooKeeper:为自动选主提供统─协调服务
    • BookKeeper:提供日志存储服务
    • ZKFC: NameNode 探活、触发主备切换
    • HA Client:提供了自动切换的客户端
    • edit log:操作的日志
  • 围绕三个问题来看高可用
    • 节点状态如何保存
    • 操作日志如何同步
    • 如何做到自动切换

image.png

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

  • 状态机复制是实现容错的常规方法
  • 组件
    • 状态机以及其副本
    • 变更日志
    • 共识协议

image.png

2.3 NameNode状态持久化

image.png

image.png

2.4 NameNode 操作日志的生产消费

  • Active生产，Standby (可能有多个)消费
  • 物理日志与逻辑日志
  • 日志系统
    • 高可用
    • 高扩展性
    • 高性能
    • 强一致(有序)

image.png

2.5 NameNode块状态维护

  • 回顾:
    • DataNode Heartbeat
    • DataNode Block Report
  • 区别
    • Active即接收，也发起变更
    • Standby只接收，不发起变更
  • Content Stale状态
    • 主备切换后，避免 DN的不确定状态

image.png

3. HDFS自动主备切换

3.1 自动主备切换流程一Server侧

  • ZKFailoverController作为外部组件，驱动HDFS NameNode的主备切换
  • 轮询探活
  • 脑裂问题
  • Fence机制

image.png

3.2 自动主备切换流程-Client侧

  • 核心机制: StandbyException
  • Client自动处理

4. 日志系统 BookKeeper简介

4.1 BookKeeper 架构

  • BookKeeper 存储曰志
    • 低延时
    • 持久性
    • 强一致性。读写高可用
  • 对比:日志系统和文件系统的复杂度

image.png

4.2 Quorum机制

  • Quorum机制:多副本一致性读写
  • 场景:多副本对象存储，用版本号标识数据新旧
  • 规则
    1. Qr+ Qw> Q
    2. Qw > Q/2
  • 思考:日志场景比对象保存更简单

image.png

4.3 BookKeeper Quorum

  • Sloppy Quorum机制

  • 日志场景:顺序追加、只写

  • Write Quorum:写入副本数

  • Ack Quorum:响应副本数

  • 思考: Client 挂掉导致不确认写入了多少数据，如何恢复?

image.png

4.4 BookKeeper Ensemble

  • Ensemble机制
  • Round-Robin Load Balancer
    • 第一轮:1，2，3
    • 第二轮:2，3，4
    • 第三轮:3，4，1
    • 第四轮:4，1，2
  • 优势:数据均衡

image.png

二、 数据存储高可用

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

1.1 回到单机存储–RAID

  • Redundant Array of Independent Disks
  • 特点
    • 廉价
    • 高性能
    • 大容量
    • 高可用

1.2 RAID方案讲解

  • RAID 0:条带化
  • RAID 1:冗余
  • RAID 3:容错校验

image.png

2. HDFS的数据高可用机制

2.1 HDFS 多副本

  • HDFS版本的RAID 1
  • 优点
    • 读写路径简单
    • 副本修复简单
    • 高可用

image.png 图: Hadoop的多副本放置

2.2 Erasure Coding原理

  • HDFS版本的RAID 2/3
  • 业界常用Reed Solomon算法

image.png 图:Reed Solomon算法原理

2.3 HDFS Erasure Coding

  • HDFS版本的 RAID 2
  • 和多副本比较
    • 读写速度
    • 成本
    • 修复速度
    • 读写路径的实现

image.png 图:直接保存的EC和Stripe(条带化)后保存的EC

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

3.1 网络架构

  • 机架(Rack):放服务器的架子。
  • TOR(Top of Rack):机架顶部的交换机。
  • 数据中心(Data Center):集中部署服务器的场所

image.png

图:网络拓扑

3.2 副本放置策略―机架感知

  • 一个TOR故障导致整个机架不可用vs降低跨rack流量
  • trade-off :一个本地、一个远端

image.png 图:HDFS的多机架放置

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

4.1 案例:字节跳动的HDFS 多机房实践

  • 字节跳动的HDFS集群，从单机房演进到双机房，再从双机房演进到更多的机房。
  • 多机房解决的问题
    • 容量问题
    • 容灾问题
  • HDFS 双机房放置的设计
    • 写入时，每个数据块在两个机房至少各有一个副本，数据实时写入到两个机房
    • 读取时，优先读本地的副本，避免了大量的跨机房读取

image.png

4.2 多机房容灾实践

  • 多机房部署的组件
    • ZooKeeper
    • BookKeeper
    • NameNode
    • DataNode
  • 容灾期间的策略
    • 容灾期间，限制跨机房写入
    • 容灾期间，限制跨机房副本复制

三、 元数据高扩展性

1. 元数据扩展性挑战

1.1 元数据节点扩展性的挑战

  • HDFS NameNode是个集中式服务，部署在单个机器上，内存和磁盘的容量、CPU的计算力都不能无限扩展
  • scale up vs.scale out
    • 扩容单个服务器的能力·部署多个服务器来服务
  • 挑战
    • 名字空间分裂
    • DataNode汇报
    • 目录树结构本身复杂

image.png

1.2 常见的Scale Out方案

  • KV模型的系统可以使用partition
    • Redis
    • Kafka
    • MySQL(分库分表)
  • 下图:三种数据路由方式
    • 服务端侧
    • 路由层
    • 客户端侧

image.png

2. 社区的解决方案

2.1 社区解决方案-BlockPool

  • 解决DN同时服务多组NN的问题
  • 文件服务分层
    • Namespace
    • Block Storage
  • 用blockpool来区分DN的服务
    • 数据块存储
    • 心跳和块上报

image.png

2.2 社区解决方案- viewfs

  • Federation架构:将多个不同集群组合起来，对外表现像一个集群一样
  • 下图:viewfs通过在client-side的配置，指定不同的目录访问不同的NameNode

image.png

  • 局限性:运维复杂

3. 字节跳动的NNProxy方案

3.1 字节跳动的NNProxy

  • NNProxy是ByteDance自研的HDFS代理层，提供了路由服务
  • 于2016年开源，项目地址:github.com/bytedance/n… Based Federation在2017年上线
  • NNProxy主要实现了路由管理和RPC转发、以及鉴权、限流、查询缓存等额外能力
  • 下图:NNProxy所在系统上下游

image.png

3.2 NNProxy路由规则保存

  • 回顾:三种数据路由方式
    • 服务端侧
    • 路由层
    • 客户端侧
  • 考虑点:扩展性、运维性

image.png 图:路由规则的保存

3.3 NNProxy路由转发实现

  • 路径最长匹配规则
    • /
    • /home
    • /user/bob
    • /user/tigerlwarehouse
    • /user/tiger/dump

image.png 图:目录树视图

4. 案例:小文件问题

  • 小文件问题(LSOF, lots of small files) :大小不到一个HDFS Block 大小的文件过多

    • NameNode瓶颈
    • I/O变小，数据访问变慢
    • 计算任务启动慢

  • 解决方案:

    • 后台任务合并小文件
    • Shuffle Service

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

image.png

四、 数据存储高扩展性

1. 超大集群的长尾问题

1.1 延迟的分布和长尾延迟

  • 延迟的分布:
    • 用百分数来表示访问的延迟的统计特征
    • 例如p95延迟为1ms，代表95%的请求延迟要低于1ms,但后5%的请求延迟会大于1ms
  • 长尾延迟:尾部(p99/p999/p999)的延迟，衡量系统最差的请求的情况。会显著的要差于平均值

下图:延迟的长尾

image.png

下图:延迟的分布

image.png

1.2 尾部延迟放大

  • 木桶原理
    • 尾部延迟放大:访问的服务变多，尾部的请求就会越发的慢
  • 如何变慢
    • 固定延迟阈值
    • 固定延迟百分位

image.png 图:尾部延迟放大，整个服务被Backend 6拖累

1.3 长尾问题的表现-慢节点

  • 慢节点:读取速度过慢，导致客户端阻塞
  • 慢节点的发生难以避免和预测
    • 共享资源、后台维护活动、请求多级排队、功率限制
    • 固定的损耗:机器损坏率
    • 混沌现象
  • 离线任务也会遇到长尾问题
    • 全部任务完成时间取决于最慢的任务什么时候完成
    • 集群规模变大，任务的数据量变大。
    • 只要任何数据块的读取受到长尾影响，整个任务就会因此停滞 集群扩大10倍，问题扩大N(>10)倍

image.png

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

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

  • 条件一:超大集群下，有一部分机器是损坏来不及修理的
  • 条件二:副本放置策略完全随机
  • 条件三:DN的容量足够大 推论:必然有部分数据全部副本在损坏的机器上，发生数据丢失
  • 估算:三副本，10000台机器，每台一百万副本
    • 有多少种放置的组合数?
    • 损坏100台机器,会有多少副本丢失?
  • 叠加长尾问题，容易导致整个任务无法执行下去

image.png 图:数据丢失的发生率

2.2 Copyset

  • 将DataNode分为若干个Copyset选块在copyset内部选择
  • 原理:减少了副本放置的组合数，从而降低副本丢失的概率

image.png

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

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

image.png

3.2 数据写入不均

  • 数据的不均匀
    • 节点容量不均匀
    • 数据新旧不均匀
    • 访问类型不均匀
  • 资源负载不均匀

image.png 图:DN的写入量不均匀

3.3 DN冷热不均

  • 数据的不均匀
    • 节点容量不均匀
    • 数据新旧不均匀
    • 访问类型不均匀
  • 资源负载不均匀

image.png 图:DN的访问不均匀

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

image.png

4. 数据迁移工具速览

4.1 数据迁移工具-跨NN迁移

  • DistCopy
    • 基于MapReduce，通过一个个任务，将数据从一个NameNode拷贝到另一个 NameNode
    • 需要拷贝数据，流量较大，速度较慢
  • FastCopy
    • 开源社区的无需拷贝数据的快速元数据迁移方案
    • 前提条件:新旧集群的DN列表吻合
    • 对于元数据，直接复制目录树的结构和块信息
    • 对于数据块，直接要求DataNode 从源 BlockPool hardlink 到目标BlookPool，没有数据拷贝
    • hardlink:直接让两个路径指向同一块数据

4.2 数据迁移工具- Balancer

  • 工具向DataNode 发起迁移命令，平衡各个DataNode的容量
  • 场景
    • 单机房使用、多机房使用
    • 限流措施
  • 评价标准
    • 稳定性成本
    • 可运维性
    • 执行效率

image.png

五、 总结

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

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

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

  • 字节跳动HDFS依然在持续迭代，在元数据扩展性、数据治理与调度、数据生态体系、单机存储引擎、云上存储等方向依然大有可为

引用参考

内容主要参考了熊睦老师在「HDFS 高可用与高扩展性机制分析」课程里所教授的内容，同时也参考了学员手册里第三节的内容，图片来自于老师的PPT，链接如下：

  1. 【大数据专场 学习资料三】第四届字节跳动青训营 - 掘金 (juejin.cn)
  2. ​‌‍‬⁠⁡⁢⁣⁤HDFS 高可用与高扩展机制 - 熊睦 - ppt.pptx - 飞书文档 (feishu.cn)
avatar
文章
阅读
粉丝