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

Trembling
165 阅读7分钟

字节跳动青训营第4期 第课 HDFS高可用和高扩展机制分析

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

[TOC]

元数据高可用

高可用的需求

  • 硬件故障
    • 人为
    • 非人为
    • 软件
  • 灾难
    • 机房断电
    • 机房空调停机
    • 网络故障

如何衡量高可用

衡量高可用.png

  • MTTR：发现一次故障，需要多久要恢复
  • MTTF：平均一次故障有多长时间
  • MTBF：两次故障的平均间隔

年化可用性.png

根据可用性公式，可以计算一年有多久是不可用的，通过年化计算公式更直观的反应高可用性能

高可用的形式

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

人工反应会需要更长的决策时间，很多切换可以交给机器来完成。

在HDFS的设计中，NameNode是中心化的，所以更可能称为故障中的单点，DataNode相对不惧怕这一点。

HDFS高可用架构

NameNode高可用架构.png

HDFS主备同步实现

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

状态机复制和日志.png

NameNode操作日志的生产和消费

Active NameNode向分布式的日志中进行写入，再由Standby NameNode进行消费，二者再分别进行持久化操作。NameNode会临时保存成FSImage，每隔一段时间，将FSImage和EditLog进行合并。

物理日志与逻辑日志

逻辑日志的示例形式：

rename /a/b /a/c

物理日志的实例形式（具体实现形式不一样）

nodeid:00000001 -> /a/c

NameNode块状态维护

NameNode块状态维护.png

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

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

HDFS自动主备同步

分布式管理组件 Zookeeper

一般用于提供主、协调元数据存储，基于ZAB协议进行使用

自动主备切换流程 - Server侧

自动主备切换Server侧流程.png

自动主备切换流程 - Client侧

核心机制: StandbyException

接收到异常后，自动去进行主备切换

日志系统BookKeeper

BookKeeper架构.png

Application 1和2即HDFS NameNode；元数据存放在Zookeeper上。对于HDFS需要维护目录树，这个操作开销比较大，而ZK的强一致性导致ZK无法适用于HDFS开销大的操作。

Quorum机制

多副本一致性读写。

Quorum机制.png

用版本号标识数据的新旧。

Writer必须要写到半数以上，Writer和Reader的读取和要大于总数量。

对于BookKeeper的Quorum，在写的时候只进行追加，不会进行修改，读也只是顺序读。

Ensemble机制

BookKeeperEnsemble.png

Round-Robin策略即轮询策略，每个Bookie轮询进行写入，这一做法的优势即可以达到一个数据均衡的效果。

数据存储高可用

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

单机存储时代，若有多块硬盘且希望多块硬盘同时发挥作用，则用到了RAID机制，即将多块硬盘看做是一块提供服务。即将多块物理盘组成一个逻辑盘。

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

常见RAID方案

RAID 0 条带化

数据写入时，各个物理盘轮流写，从而提升整体的吞吐能力，如同条带一样写在不同的物理盘上。

RAID 1 冗余

RAID提供的备份机制，多个物理盘写同一份数据。但是此类方案依然无法避免一些偶然的数据错误等。

RAID 3 容错校验

将数据进行分割，单独使用一个物理盘做容错校验，将每一块数据进行容错码计算，之后即可通过容错码判断数据是否正确，同时也可以通过容错码对丢失的部分数据进行反推，增强了安全性。

RAID3.png

HDFS的数据存储高可用机制

HDFS多副本

将同一个块的数据存放在多个DataNode上，从而实现多副本。

优点：

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

通过CheckSum算法进行容错校验，但是此算法不能进行错误恢复。

双副本的情况同时故障率约为百万分之一，但是大数据系统中可能会产生百万级的块，所以还是很容易出现错误的，即通常使用三副本。

Erasure Coding

ErasureCoding.png

HDFSEC.png

在HDFS的设计中，将每条数据条带式的存储在不同的块上，然后对每个条带计算纠删码，降低了使用开销。

和多副本比较，优点：

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

考虑网络架构的数据存储高可用机制 - Rack感知

在数据中心中，每个机架（Rack）存在一个交换机（TOR），若数据全部存放在一个Rack中，若发生故障，则高可用特性约等于没有。

HDFS常用3副本，将2比1的配置分别存储在两个Rack上，只存在一份Rack间流量，且保证了一定的Rack级容灾。

案例：字节跳动的HDFS多机房容灾方案简介

多机房解决的问题：

  • 容量问题
  • 容灾问题

存储时，将副本存储在不同机房；读取时，优先读本地副本，避免大量机房间流量。

多机房部署的组件：

  • ZooKeeper
  • BookKeeper
  • NameNode
  • DataNode

容灾期间的策略：

  • 限制跨机房写入
  • 限制跨机房副本复制

元数据高扩展性

面临的挑战

HDFS NameNode是个集中式服务，但部署在单机上，硬件资源必然收到限制。

两个方案：

  1. 增强硬件资源
  2. 部署多个NameNode服务

增强单机资源必然会有尽头，只能是组织多个NameNode，共同对外提供服务。

挑战：

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

社区解决方案

KV模型下使用partition方案

根据Key的值不同，去不同的NameNode上提供服务。

提供路由层

Client访问路由层，由路由自己提供数据节点

BlockPool

BlockPool.png

NNProxy方案

github.com/bytedance/n…

NNProxy为字节自研的HDFS的代理层，提供了路由功能

案例：小文件问题

小文件：不到一个Block Size的文件。

容易造成NameNode瓶颈，IO变成小的随机IO，数据访问变慢。

解决方案：

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

数据存储的高扩展性

超大集群的长尾问题

延迟的分布和长尾延迟

将所有的请求放在一起排序，用百分比标识其位置，由短到长。

尾部延迟（p95,999,p999）是最差的延迟情况，显著差于平均值，这一部分请求有可能造成用户体验变差。

长尾延迟适用于木桶原理，一个请求可能要对应很多的请求，即使只有很少的请求性能很差，但依然很容易造成大面积的影响。

超大集群的可靠性问题

在超大集群下，有一部分机器的损坏是来不及修理的，如果副本依然采用随机策略是难以满足要求的。

解决方案：Copyset 将全随机的选择方式改为有迹可循

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

超大集群的不均匀问题

负载均衡：

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

数据写入不均匀：

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

资源负载不均匀

数据迁移工具概览

元数据迁移：

  • DistCopy：基于MapReduce进行数据拷贝式的迁移
  • FastCopy：无需拷贝完成数据迁移

数据迁移：

  • Balancer
avatar
文章
阅读
粉丝