元数据的高可用

元数据包含两块，一个是静态的，一个是动态的

🚩静态的是fsimage和edits，其实fsimage是由edits文件合并生成的，所以只需要保证edits文件内容的一 致性。这个就是需要保证多个NameNode中edits文件内容的事务性同步。这块的工作是由JournalNodes 集群进行同步的。

🚩动态数据是指block和DataNode节点的信息，这个如何保证呢? 当DataNode启动的时候，上报数据信息的时候需要向每个NameNode都上报一份。 这样就可以保证多个NameNode的元数据信息都一样了，当一个NameNode down掉以后，立刻从 Standby NN中选择一个进行接管，没有影响，因为每个NameNode 的元数据时刻都是同步的。

💨高可用的需求

✔故障类型:

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

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

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

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

🎈而如果HDFS系统不可用。则引发

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

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

🎈高可用的衡量

服务可用性指标

• MTTR
• MTTF
• MTBF

🎈可用性的年化

可用性:

🎈高可用的形式

服务高可用

热备份

冷备份

故障恢复操作

人工切换

自动切换

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

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

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

🎈HDFS NameNode高可用架构

组件介绍:

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

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

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

🎈NameNode状态持久化

👇FSImage和EditLog

👇Checkpoint机制

🎈NameNode操作日志的生产消费

Active生产，Standby (可能有多个)消费

💨自动主备切换流程

Server侧

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

Client侧

核心机制: StandbyException

💨BookKeeper架构

BookKeeper存储日志

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

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

🎈Quorum机制

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

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

🎈BookKeeper Quorum

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

Write Quorum:写入副本数

Ack Quorum:响应副本数

数据存储高可用

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

🎈回到单机存储- RAID

特点

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

💨HDFS的数据高可用机制

🎈HDFS多副本
优点

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

🎈Erasure Coding原理

🎈HDFS Erasure Coding

和多副本比较

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

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

🎈网络架构

• 机架(Rack):放服务器的架子。
• TOR(Top of Rack):机架顶部的交换机。
• 数据中心(Data Center):集中部署服务器的场所

🎈副本放置策略-机架感知

💨自我思考

HDFS的数据高可用，是在一个集群中存在多个NameNode，分别运行在独立的物理节点上。在任何时间点，只有一个NameNode是处于Active状态，其它的是处于Standby状态。

元数据高扩展性

💨元数据扩展性挑战

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

挑战

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

🎈常见的Scale Out方案

KV模型的系统可以使用partition

• Redis
• Kafka
• MySQL (分库分表)

💨社区的解决方案

🎈BlockPool

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

🎈viewfs

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

存储数据高扩展性

💨延迟的分布和长尾延迟

🎈延迟的分布:

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

🎈长尾延迟:

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

💨自我思考

高扩展性可以解决单一命名空间存在的问题，使用多个NameNode，每个NameNode负责一个命令空间

💨数据迁移工具

🎈跨NN迁移

DistCopy

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

FastCopy

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

🎈Balancer

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

场景

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