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

您完全不改Bug是嗎
57 阅读6分钟

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

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

课程回顾

有关 HDFS 的架构和读写流程。

HDFS 通过将文件分块来存储大文件，HDFS 的组件有 NameNode 和 DataNode，分别负责提供元数据和数据服务。

在读/写数据时，HDFS 客户端需要先从 NameNode 上获取数据读取/写入的 DataNode 地址，然后和 DataNode 交互来完成数据读/写。

一个“可以用”的系统和“好用”的系统，差距就是“高可用”和“高扩展性”。

一、本堂课重点内容

  • 主备系统：基于日志、自动切换、实时热备

  • 数据备份：多副本、纠删码、网络架构

  • 水平扩展：邦联架构、请求路由、完整名字空间

  • 超大集群：数据可靠、数据均衡、长尾问题

二、详细知识点介绍

1. 元数据高可用

1.1 高可用的需求

1.1.1 服务高可用的需求

故障类型分硬件、软件和人为，而类似数据中心级别不可用的灾难有时发生，故障却是不可避免的，如果 HDFS 系统不可用，业务停止的损失极大，所以 HDFS 系统的高可用性就至关重要。

1.1.2 高可用的衡量

服务可用性指标：MTTR、MTTF、MTBF。

1.1.3 可用性的年化

可用性： 71.jpg

1.1.4 高可用的形式

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

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

NameNode 容易成为故障中的单点（single point of failure）。

1.2 HDFS 主备同步实现

1.2.1 HDFS NameNode 高可用架构

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

72.JPG

图源：教学PPT

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

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

组件：状态机以及其副本、变更日志、共识协议。

日志系统：高可用、高扩展、高性能、强一致（有序）。

1.2.5 NameNode 块状态维护

区别：

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

Content Stale 状态：主备切换后，避免 DN 的不确定状态。

1.3 HDFS 主动主备切换

1.3.1 分布式协调组件 - ZooKeeper

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

HA 核心机制：Watch

1.3.2 主动主备切换流程

—— Server 侧

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

—— Client 侧

核心机制：StandbyException

2. 数据存储高可用

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

2.1.1 回到单机存储 - RAID

特点：廉价、性能高、大容量、高可用。

2.1.2 RAID 方案

  • RAID 0：条带化

  • RAID 1：冗余

  • RAID 3：容错校验

2.2 HDFS的数据高可用机制

2.2.1 HDFS 多副本

优点：读写路径简单；副本修复简单；高可用。

2.2.3 HDFS Erasure Coding

和多副本相比：读写速度、成本、修复速度、读写路径的实现。

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

2.3.1 初识网络架构

Server：一台服务器。

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

TOR（Top of Rack）：机架顶部的交换机。

POD（Point of Delivery）：数据中心中的一个物理区域。

数据中心（Data Center）：集中部署服务器的场所。

3. 元数据高扩展性

3.1 元数据扩展性挑战

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

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

scale up vs. scale out

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

挑战

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

3.1.2 常见的 Scale Out 方案

KV 模型的系统可以使用 partition

  • Redis
  • Kafka
  • MySQL（分库分表）
3.2 社区的解决方案

3.2.1 BlockPool

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

3.3.2 viewfs

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

3.3 字节跳动的 NNProxy 方案

3.3.3 NNProxy 路由转发实现

路径最长匹配规则，可以进一步划分目录树。

3.4 案例：小文件问题

小文件问题（LSOF，lots of small files）：大小不到一个 HDFS Block 大小的文件过多。

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

解决方案：后台任务合并小文件；Shuffle Service。

4. 数据存储高扩展性

4.1 超大集群的长尾问题

4.1.1 延迟的分布和长尾问题

延迟的分布：

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

长尾延退：尾部（p99/p999/p999）的延迟，衡量系统最差的情况。会显者的要差子平值。

4.1.2 尾部延迟放大

访问的服务变多，尾部的请求就会越发的慢。

如何变慢： 固定延迟阈值；固定延迟百分位。

4.1.3 长尾问题的表现

—— 慢节点

读取速度过慢，导致客户端阻塞。

慢节点的发生难以避免和预测，离线任务也会遇到长尾问题。

4.2 超大集群的可靠性问题

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

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

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

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

4.2.2 Copyset

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

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

4.3 超大集群的不均匀问题

4.3.2 数据写入不均

数据的不均匀：节点容量、数据新旧、访问类型不均匀。

资源负载不均匀。

4.4 数据迁移工具速览

4.4.1 跨 NN 迁移

DistCopy

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

FastCopy

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

4.4.2 Balancer

三、课程小结

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

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

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

avatar
文章
阅读
粉丝