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

01.元数据高可用

服务高可用的需求

故障类型:

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

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

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

故障不可避免，灾难时有发生。

而如果HDFS系统不可用。

• 无法核算广告账单，直接引发收入损失
• 无法生产数据报表，数据驱动无从谈起
• 无法进行模型训练，用户体验越来越差

业务停止的损失极大，所以HDFS系统的高可用性就至关重要。

高可用的衡量

服务可用性指标

• MTTR（Mean Time To Repair）：平均修复时间，系统能多快恢复。
• MTTF（Mean Time To Failure）：平均失效时间，运行到故障间的时间，一般用于不可修复的系统（制造业）。
• MTBF（Mean Time Between Failures）：平均无故障时间，两次故障间的间隔，一般用于可修复的系统（软件）。

可用性的年化

• 可用性:

A=MTBF / MTBF + MTTR

全年不可用时间

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

高可用的形式

• 服务高可用

  • 冷备份：备份服务的数据，可以和数据归档相结合。在主服务故障时，利用备份的数据重启。
  • 热备份：主服务和备服务同时运行，在主服务故障时，随时可以切换到备服务。

• 故障恢复操作

  • 人工切换
  • 自动切换

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

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

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

HDFS NameNode高可用架构

• 组件介绍

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

• 围绕三个问题来看高可用

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

• 

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

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

• 组件

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

• 

NameNode状态持久化

FSImage和EditLog

Checkpoint机制

NameNode操作日志的生产消费

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

日志系统

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

NameNode块状态维护

• 回顾:

  • DataNode Heartbeat
  • DataNode Block Report

• 区别

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

• Content Stale状态

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

分布式协调组件ZooKeeper

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

使用它的组件:

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

HA核心机制: Watch

自动主备切换流程-Server侧

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

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

自动主备切换流程-Client侧

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

BookKeeper 架构

Bookkeeper存储日志

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

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

Quorum机制

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

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

规则:

0. Q,+ Qw> Q
1. Qw> Q/2

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

BookKeeper Quorum

• Sloppy Quorum机制
• 日志场景:顺序追加、只写
• Write Quorum:写入副本数
• Ack Quorum:响应副本数
• 思考: Client 挂掉导致不确认写入了多少数据，如何恢复?

BookKeeper Ensemble

• Ensemble机制

• Round-Robin Load Balancer

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

• 优势:数据均衡

02.数据存储高可用

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

回到单机存储一RAID

• Redundant Array of Independent Disks

• 图:提供RAID功能的NAS设备

• 特点

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

RAID方案讲解

• RAID 0:条带化
• RAID 1:冗余
• RAID 3:容错校验
• 其他RAID方案可以课后了解

HDFS的数据高可用机制

HDFS多副本

• HDFS版本的RAID 1

• 图: Hadoop 的多副本放置

• 优点

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

Erasure Coding原理

HDFS版本的RAID 2/3

业界常用Reed Solomon算法

图:Reed Solomon算法原理

HDFS Erasure Coding

HDFS版本的RAID 2

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

和多副本比较

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

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

网络架构

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

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

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

图:机架的样子

图:网络拓扑

副本放置策略 机架感知

**一个TOR故障导致整个机架不可用 VS 降低跨rack流量

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

图: HDFS的多机架放置

字节跳动的HDFS多机房实践

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

• 多机房解决的问题

  • 容量问题
  • 容灾问题

HDFS双机房放置的设计

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

多机房容灾实践

• 多机房部署的组件

  • ZooKeeper
  • BookKeeper
  • NameNode
  • DataNode

• 容灾期间的策略

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

03.元数据高扩展性

元数据节点扩展性的挑战

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

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

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

• scale up ​Vs. scale ou

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

• 挑战

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

常见的Scale Out方案

社区解决方案

BlockPool

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

• 文件服务分层

  • Namespace
  • Block Storage

• 用blockpool来区分DN的服务

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

viewfs

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

字节跳动的NNProxy

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

  • 于2016年开源，项目地址: github.com/bytedance/n…
  • 开源社区的Router Based Federation在2017年上线。

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

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

• 右图: NNProxy 所在系统上下游

NNProxy路由规则保存

• 回顾:三种数据路由方式

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

• 考虑点:扩展性、运维性

• 图:路由规则的保存

NNProxy路由转发实现

• 图:目录树视图

  • 

• 路径最长匹配规则

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

• 进一步思考:

  • 单个NN不会遇到瓶颈了么?
  • 跨集群rename

案例:小文件问题

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

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

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

  • 

• 解决方案:

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

04.存储数据高扩展性

超大集群的长尾问题

延迟的分布和长尾延迟

延迟的分布:

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

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

图:延迟的长尾

图:延迟的分布

尾部延迟放大

• 木桶原理

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

• 如何变慢

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

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

长尾问题的表现-慢节点

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

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

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

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

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

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

超大集群的可靠性问题

超大集群下的数据可靠性

• 条件一:超大集群下，有一部分机器是损坏来不及修理的。
• 条件二:副本放置策略完全随机。
• 条件三: DN的容量足够大
• 推论:必然有部分数据全部副本在损坏的机器上，发生数据丢失。

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

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

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

Copyset

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

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

负载均衡

• 可靠性
• 降低成本
• 避免热点

数据写入不均

数据的不均匀图: （DN的访问不均匀）

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

资源负载不均匀

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

数据迁移工具速览

数据迁移工具-跨NN迁移

• DistCopy

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

• FastCopy

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

数据迁移工具- Balancer

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

• 场景

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

• 评价标准

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