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

豆豆酱
411 阅读10分钟

元数据高可用（主备系统：基于日志、自动切换、实时热备）

高可用的需求

1.1.1服务高可用的需求

故障类型:

  • 硬件故障
  • 软件故障
  • 人为故障

灾难: 数据中心 级别不可用

  • 机房断电
  • 机房空调停机
  • 机房间网络故障、拥塞

故障不可避免，灾难时有发生。业务停止的损失极大，所以HDFS系统的高可用性就至关重要。

1.1.2高可用的衡量

服务可用性指标

  • MTTR
  • MTTF
  • MTBF

1.1.3可用性的年化

可用性:

全年不可用时间

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

1.1.4高可用的形式

服务高可用：

  • 热备份
  • 冷备份

故障恢复操作：

  • 人工切换
  • 自动切换

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

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

HDFS主备同步实现

1.2.1 HDFS NameNode高可用架构

组件介绍

  • ActiveNamenode:主节点，提供服务，生产日志
  • StandbyNamenode:备节点，消费日志
  • ZooKeeper:为自动选主提供统一协调服务
  • BookKeeper:提供日志存储服务
  • ZKFC: NameNode 探活、触发主备切换
  • HA Client:提供了自动切换的客户端
  • edit log:操作的日志

围绕三个问题来看高可用

  • 节点状态如何保存？
  • 操作日志如何同步？
  • 如何做到自动切换？

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

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

组件

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

1.2.3 NameNode状态持久化

FSImage和EditLog + Checkpoint机制

1.2.4 NameNode操作日志的生产消费

Active生产，Standby 消费

物理日志与逻辑日志

日志系统

  1. 高可用
  2. 高扩展性
  3. 高性能
  4. 强一致(有序)

1.2.5 NameNode块状态维护

回顾:

  • DataNode Heartbeat
  • DataNode Block Report 块上报

区别：

  • Active即接收(心跳，块上报)，也发起变更（对datanode发起删除等操作）
  • Standby只接收，不发起变更

Content Stale状态

  • NameNode在主备切换后的状态，避免dataNode的不确定状态
  • 在全量dataNode块上报后，会解除这个状态

HDFS自动主备切换

1.3.1分布式协调组件 - ZooKeeper

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

使用它的组件: HDFS YARN HBase Kafka ClickHouse

HA（high available）核心机制: Watch

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

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

  • 轮询探活
  • 脑裂问题
  • Fence机制

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

核心机制: StandbyException

Client自动处理，当请求打到stand by 上，在配置里继续找，重新发请求找active

日志系统BookKeeper简介

1.4.1 BookKeeper架构

BookKeeper存储日志

1）低延时 2）持久性 3）强一致性 4）读写高可用

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

1.4.2 Quorum机制

Quorum机制:多副本一致性读写

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

规则：

  1. Qr + Qw> Q(整个集群数量)
  2. Qw> Q/2

思考:日志场景比对象保存更简单

1.4.3 BookKeeper Quorum

Sloppy Quorum机制

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

Write Quorum:写入副本数

Ack Quorum:响应副本数

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

1.4.4 BookKeeper Ensemble

Ensemble机制

Round-Robin Load Balancer， 4台机器，写入3个副本

第一轮: 1,2,3

第二轮: 2,3,4 . 第三轮: 3,4,1

第四轮: 4,1,2

优势:数据均衡

数据存储高可用（数据备份：多副本，纠删码，网络架构）

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

2.1.1回到单机存储一RAID

Redundant Array of Independent Disks

图:提供RAID功能的NAS设备

特点

1）廉价 2）高性能 3）大容量 4）高可用

2.1.2 RAID方案讲解

RAID0:条带化

RAID 1:冗余

RAID 3:容错校验

HDFS的数据高可用机制

2.2.1 HDFS多副本

HDFS版本的RAID 1

图: Hadoop 的多副本放置

优点

1）读写路径简单 2）副本修复简单（从其他node上拷贝一份） 3）高可用

2.2.2 Erasure Coding （纠删码）原理

HDFS 版本的 RAID 2/3，可用于做纠错恢复

业界常用Reed Solomon算法

图：Reed Solomon算法原理

2.2.3 HDFS Erasure Coding

HDFS版本的RAID 2

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

和多副本比较

1）读写速度 2）成本 3）修复速度 4）读写路径的实现

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

2.3.1网络架构

机架(Rack):放服务器的架子。

TOR(Top of Rack):机架顶部的交换机。

数据中心(Data Center):集中部署服务器的场所

图:机架的样子

图:网络拓扑

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

一个TOR（交换机）故障导致整个机架不可用 vs 降低跨rack流量

trade-off: 一个本地、一个远端

图: HDFS的多机架放置

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

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

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

多机房解决的问题

1)容量问题

2)容灾问题

HDFS双机房放置的设计

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

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

多机房部署的组件

1)ZooKeeper

2)BookKeeper

3)NameNode

4)DataNode

容灾期间的策略

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

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

元数据高扩展性（水平扩展：邦联架构，请求路由，完整名字空间）

元数据扩展性挑战

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

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

scale up Vs. scale out

1)扩容单个服务器的能力

2)部署多个服务器来服务

挑战

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

3.1.2常见的Scale Out方案

KV模型的系统可以使用partition

1)Redis 2)Kafka 3)MySQL (分库分表)

右图:三种数据路由方式

1)服务端侧 2)路由层 3)客户端侧

思考：目录树怎么拆分合理？

社区的解决方案

3.2.1社区解决方案一BlockPool

解决DN同时服务多组NN的问题， 比如同一个block id 在不同的NN上出现

文件服务分层

  • Namespace
  • Block Storage

用blockpool来区分DN的服务

  • 数据块存储
  • 心跳和块上报

3.2.2社区解决方案一viewfs

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

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

局限性：运维复杂

字节跳动的NNProxy方案

3.3.1 字节跳动的NNProxy

NNProxy是ByteDance自研的 HDFS 代理层，提供了路由服务

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

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

3.3.2 NNProxy路由规则保存

回顾:三种数据路由方式

1)服务端侧 2)路由层 3)客户端侧

考虑点:扩展性、运维性

图:路由规则的保存

3.3.3 NNProxy路由转发实现

图:目录树视图

路径最长匹配规则

● /

● /home

● /user/bob

● /user/tiger/warehouse

● /user/tiger/dump

进一步思考:

1)单个NN不会遇到瓶颈了么?

2)跨集群rename

案例: 小文件问题

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

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

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

解决方案:

  1. 后台任务合并小文件
  2. Shuffle Service

数据存储高扩展性（超大集群：数据可靠，数据均衡，长尾问题）

4.1.1延迟的分布和长尾延迟

延迟的分布:

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

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

上图:延迟的长尾

下图:延迟的分布

4.1.2尾部延迟放大

木桶原理

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

如何变慢

  1. 固定延迟阈值 2) 固定延迟百分位

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

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

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

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

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

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

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

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

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

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

➢条件三: DN的容量足够大

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

估算:三副本，10000 台机器，每台一百万副本。

  1. 有多少种放置的组合数?
  2. 损坏100台机器，会有多少副本丢失?

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

4.2.2 Copyset

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

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

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

4.3.2数据写入不均

数据的不均匀

  1. 节点容量不均匀 2) 数据新旧不均匀 3) 访问类型不均匀

资源负载不均匀

4.3.3 DN冷热不均

数据的不均匀

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

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

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

➢DistCopy

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

➢FastCopy

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

4.4.2数据迁移工具一Balancer

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

场景

  1. 单机房使用、多机房使用
  2. 限流措施

评价标准

  1. 稳定性成本 2) 可运维性 3) 执行效率

结语

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

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

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

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

avatar
文章
阅读
粉丝