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

本座强子
96 阅读9分钟

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

这节课的重点内容包括四部分：元数据高可用、数据存储高可用、元数据高扩展性、数据存储高扩展性。

一、元数据服务高可用

1.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 高可用的形式

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

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

1.2.1 HDFS NameNode高可用架构

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

image.png

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

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

组件：

  • 状态机以及其副本
  • 变更日志
  • 共识协议

image.png

1.2.3 NameNode状态持久化

FSImage和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 State状态

  • 主备切换后，避免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>QQ_r+Q_w>Q
  2. Qw>Q/2Q_w>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.1.1 回到单机存储——RAID

提供RAID功能的NAS设备↓

image.png

特点：

  • 廉价
  • 高性能
  • 大容量
  • 高可用

2.1.2 RAID方案讲解

RAID 0：条带化

RAID 1：冗余

RAID 3：容错校验

image.png

2.2.1 HDFS多副本

HDFS版本的RAID 1

Hadoop的多副本放置↓

image.png

优点：

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

2.2.2 Erasure Coding 原理

HDFS版本的RAID 2/3

业界常用的Reed Solomon算法

算法原理↓

image.png

2.2.3 HDFS Erasure Coding

HDFS版本的RAID 2

直接保存的EC和Stripe（条带化）后保存的EC↓

image.png

和多副本比较：

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

2.3.1 网络架构

机架（Rack）：放服务器的架子

image.png

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 多机房容灾实践

多机房部署的组件：

  • ZookKeeper
  • BookKeeper
  • NameNode
  • DataNode

容灾期间的策略：

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

image.png

三、元数据高扩展性

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

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

scale up vs scale out

  • 扩容单个服务器的能力
  • 部署多个服务器来服务

image.png

挑战

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

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年开源
  • 开源社区的Router Based Federation在2017年上线

NNProxy主要实现了路由管理和RPC转发

  • 以及鉴权、限流、查询缓存等额外能力

下图是NNProxy所在系统上下游

image.png

3.3.2 NNProxy路由规则保存

回顾：三种数据路由方式

  • 服务端侧
  • 路由层
  • 客户端侧

考虑点：扩展性、运维性

下图是路由规则的保存

image.png

3.3.3 NNProxy路由转发实现

下图是目录树视图

image.png

路径最长匹配规则：

  • /
  • /home
  • /user/bob
  • /user/tiger/warehouse
  • /user/tiger/dump

3.4 案例：小文件问题

小文件问题：大小不到一个HDFS Block大小的文件过多

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

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

image.png

解决方案：

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

四、存储数据高扩展性

延迟的分布：

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

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

延迟的长尾

image.png

延迟的分布

image.png

4.1.2 尾部延迟放大

木桶原理：

尾部延迟方法：访问的服务变多，尾部的请求就会越发的慢。

如何变慢

  • 固定延迟阈值
  • 固定延迟百分位

image.png

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

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

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

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

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

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

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

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

image.png

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

  • 条件一：超大集群下，有一部分机器是损坏来不及修理的
  • 条件二：副本放置策略完全随机
  • 条件三：DN的容量足够大

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

数据丢失的发生率

image.png

4.2.2 Copyset

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

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

image.png

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到目标BlockPool，没有数据拷贝
  • hardlink：直接让两个路径指向同一块数据

image.png

4.4.2 数据迁移工具——Balancer

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

场景：

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

评价标准：

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

image.png

总结

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

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

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

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

avatar
文章
阅读
粉丝