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

张鱼哥z
162 阅读9分钟

这是我参与「第四届青训营」笔记创作活动的的第9天，以下是我的课堂笔记。 本次课程主要分为四个大板块：
1. 元数据高可用
2. 数据存储高可用
3. 元数据高扩展性
4. 数据存储高扩展性

1. 元数据高可用

1.1.1服务高可用的需求

  • 故障类型:
    更件故障
    软件故障
    人为故障
  • 灾难:数据中心级别不可用
    机房断电
    机房空调停机
    机房间网络故障、拥塞

而如果 HDFS系统不可用。
·无法核算广告账单，直接引发收入损失
·无法生产数据报表，数据驱动无从谈起
·无法进行模型训练，用户体验越来越差
业务停止的损失极大，所以HDFS 系统的高可用性就至关重要。

1.1.2高可用的衡量

服务可用性指标

  • MTTR
  • MTTF
  • MTBF image.png

1.1.3可用性的年化

可用性：image.png
全年不可用时间
·可用性99.9%，全年8.76小时不可用
·可用性99.99%，全年52.6分钟不可用
·可用性99.999%，全年5.26分钟不可用

1.1.4高可用的形式

  • 服务高可用
    ·热备份
    ·冷备份
  • 故障恢复操作
    ·人工切换
    ·自动切换

人工的反应、决策时间都更长，高可用需要让系统自动决策。
HDFS的设计中，采用了中心化的元数据管理节点NameNode。
NameNode容易成为故障中的单点(single point of failure).

1.2.1 HDFS NameNode高可用架构

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

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

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

  • 组件
    状态机以及其副本
    变更日志
    共识协议 image.png

1.2.3 NameNode状态持久化

FSlmage和EditLog image.png Checkpoint机制 image.png

1.2.4 NameNode操作日志的生产消费

Active生产，Standby (可能有多个）消费
物理日志与逻辑日志

日志系统

  • 高可用
  • 高扩展性
  • 高性能
  • 强一致(有序) image.png

1.2.5 NameNode块状态维护

回顾:

  • DataNode Heartbeat
  • DataNode Block Report

区别

  • Active即接收，也发起变更
  • Standby只接收，不发起变更

Content Stale状态

  • 主备切换后，避免DN的不确定状态 image.png

1.3.1分布式协调组件– ZooKeeper

一般用于提供选主、协调、元数据存储。 使用它的组件:

  • HDFS、YARN、HBase
  • Kafka、 ClickHouse·等等

HA核心机制:Watch image.png

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

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

1.3.3自动主备切换流程一Client侧

核心机制:StandbyException
Client自动处理 image.png

1.4.1 BookKeeper 架构

BookKeeper存储日志

  • 低延时
  • 持久性
  • 强一致性
  • 读写高可用

对比:日志系统和文件系统的复杂度

image.png

1.4.2 Quorum机制

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

image.png

1.4.3 BookKeeper Quorum

Sloppy Quorum机制
日志场景:顺序追加、只写

Write Quorum:写入副本数
Ack Quorum:响应副本数

image.png

1.4.4 BookKeeper Ensemble

Ensemble机制
Round-Robin Load Balancer

  • 第一轮:1,2,3
  • 第二轮:2,3,4
  • 第三轮:3，4，1
  • 第四轮:4，1,2

优势:数据均衡 image.png

2.数据存储高可用

2.1.1回到单机存储-RAID

Redundant Array of Independent Disks
图:提供RAID 功能的NAS设备
特点 ·廉价
·高性能
·大容量
·高可用

2.1.2 RAID方案讲解

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

2.2.1 HDFS 多副本

HDFS版本的RAID 1
图: Hadoop的多副本放置
优点

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

image.png

2.2.2 Erasure Coding原理

HDFS版本的RAID 2/3
业界常用Reed Solomon算法
图:Reed Solomon算法原理

image.png

2.2.3 HDFS Erasure Coding

HDFS版本的RAID 2
图:直接保存的EC和Stripe(条带化)后保存的EC
和多副本比较

  • 读写速度
  • 成本
  • 修复速度
  • 读写路径的实现 image.png

2.3.1网络架构

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

image.png

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

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

image.png

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

字节跳动的HDFS集群，从单机房演进到双机房，再从双机房演进到更多的机房。
多机房解决的问题
·容量问题
·容灾问题

HDFS 双机房放置的设计
·写入时，每个数据块在两个机房至少各有一个副本，数据实时写入 到两个机房
·读取时，优先读本地的副本，避免了大量的跨机房读取。

image.png

2.4.2多机房容灾实践

多机房部署的组件
. ZooKeeper
. BookKeeper
. NameNode
. DataNode

容灾期间的策略
·容灾期间，限制跨机房写入
.容灾期间，限制跨机w房副本复制

image.png

2.4.2多机房容灾实践

多机房部署的组件
. zooKeeper
·BookKeeper
.NameNode
·DataNode

容灾期间的策略 ·容灾期间，限制跨机房写入
·容灾期间，限制跨机房副本复制

image.png

3. 元数据高扩展性

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

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

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

image.png

3.1.2常见的Scale Out 方案

KV模型的系统可以使用partition
. Redis
· Kafka
· MySQL(分库分表)

下图:三种数据路由方式
服务端侧
路由层
客户端侧

image.png

3.2.1社区解决方案-BlockPool

解决DN同时服务多组NN的问题
文件服务分层
.Namespace
.Block Storage

用blockpool来区分DN的服务
·数据块存储
·心跳和块上报

image.png

3.2.2社区解决方案- viewfs

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

image.png

3.3.1字节跳动的NNProxy

NNProxy是ByteDance自研的HDFS代理层，提供了路由服务。
·于2016年开源，项目地址:github.com/bytedance/n…
·开源社区的 Router Based Federation在2017 年上线。

NNProxy主要实现了路由管理和RPC 转发
·以及鉴权、限流、查询缓存等额外能力 下图:NNProxy所在系统上下游

image.png

3.3.2 NNProxy路由规则保存

回顾:三种数据路由方式
服务端侧
路由层
客户端侧

考虑点:扩展性、运维性

图:路由规则的保存

image.png

3.3.3 NNProxy路由转发实现

图:目录树视图

路径最长匹配规则
. /
. /home
. /user/bob
. /user/tigerlwarehouse
. /user/tigerldump

image.png

3.4案例:小文件问题

小文件问题(LSOF，lots of small files) :大小不到一个HDFS Block 大小的文件过多
· NameNode瓶颈
. I/O变小，数据访问变慢·计算任务启动慢

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

解决方案:
· 后台任务合并小文件
. Shuffle Service

image.png

4. 存储数据高扩展性

4.1.1延迟的分布和长尾延迟

延迟的分布:
·用百分数来表示访i问的延迟的统计特征
例如p95延迟为1ms，代表95%的请求延迟要低于1ms,但后5%的请求延迟会大于1ms

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

image.png
上图:延迟的长尾
下图:延迟的分布

image.png

4.1.2尾部延迟放大

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

如何变慢
.固定延迟阈值
·固定延迟百分位

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

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

慢节点:读取速度过慢，导致客户端阻塞。
慢节点的发生难以避免和预测\

  • 共享资源、后台维护活动、请求多级排队、功率限制
  • 固定的损耗:机器损坏率
  • 混沌现象

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

  • 全部任务完成时间取决于最慢的任务什么时候完成。
  • 集群规模变大，任务的数据量变大。
  • 只要任何数据块的读取受到长尾影响，整个任务就会因此停滞。
    集群扩大10倍，问题扩大N(>10)倍

image.png

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

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

4.2.2 Copyset

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

image.png

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

image.png

4.3.2数据写入不均

数据的不均匀

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

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

4.3.3 DN冷热不均

数据的不均匀

  • 节点容量不均匀
  • 数据新旧不均匀
  • 访问类型不均匀

资源负载不均匀

图:DN的访问不均匀

image.png

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

image.png

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

DistCopy
√基于MapReduce，通过一个个任务，将数据从一个NameNode拷 贝到另一个NameNode。
√需要拷贝数据，流量较大，速度较慢。

FastCopy
√开源社区的无需拷贝数据的快速元数据迁移方案
√前提条件:新旧集群的DN列表吻合
√对于元数据，直接复制目录树的结构和块信息。
√对于数据块，直接要求DataNode从源 BlockPool hardlink 到目标BlookPool，没有数据拷贝。
√hardlink:直接让两个路径指向同一块数据。

image.png

4.4.2数据迁移工具-Balancer

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

场景

  • 单机房使用、多机房使用
  • 限流措施

评价标准

  • 稳定性成本
  • 可运维性
  • 执行效率

image.png

avatar
文章
阅读
粉丝