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

柏杨921
113 阅读3分钟

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

一、元数据服务高可用

1.高可用的需求

高可用的需求

  • 故障类型：硬件/软件/人为
  • 灾难：数据中心级别不可用：比如机房断电；空调停机；机房之间的网络故障或者拥塞

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

如果HDFS系统不可用：

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

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

image.png

  • 服务可用性指标：

    • MTTR：故障恢复时间
    • MTTF：平均无故障时间
    • MTBF：两次故障时间

  • 可用性:A=MTBF(MTBF+MTTR)\frac{MTBF}{(MTBF+MTTR)}(MTBF+MTTR)MTBF​

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

  • 服务高可用：

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

  • 故障恢复:人工切换和自动切换

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

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

1.2 HDFS 的高可用架构

组件介绍：

image.png

  • Active NameNode：提供服务的 NameNode 主节点，提供服务，生产 editlog。
  • Standby NameNode：不提供服务，起备份作用的 NameNode 备节点，消费 editlog
  • editlog：用户变更操作的记录，具有全局顺序，是 HDFS 的变更日志。
  • ZooKeeper：开源的分布式协调组件，主要功能有节点注册、主节点选举、元数据存储。为自动选主提供统一协调服务
  • BookKeeper：开源的日志存储组件，存储 editlog
  • ZKFC：和 ZK、NN 通信，进行 NameNode 探活和自动主备切换。
  • HA Client：处理 StandbyException，在主备节点间挑选到提供服务的主节点。
  • EditLog：操作的日志 三个问题
  1. 节点状态如何更新
  2. 操作日志如何同步
  3. 如何做到自动切换

理论基础

image.png

  • 状态机复制和日志：实现容错的常规方法

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

image.png

  • NameNode操作日志的生产消费：active生产，standy消费

    • 将状态持久化，存FSImage文件，代表整个目录树，子节点，父节点，块的id;EditLog存在分布式系统上，一开始Active和Standby不想立即应用到FSIamge，会将日志临时保存成本地的变更日志，会在后台任务中定期合并得到更新的FSIamge。

  • 块状态维护：active既接收也发起变更，要求DataNode做一些传递或者删除块操作；standy消费只接受，不发起变更；不通过日志系统做更新，有一致性问题。

    • Content State状态：主备切换后，新上任的Active也就是原来的Standby不可以做操作，要等待一次块上报，避免DN的不确定状态

1.3 自动主备切换——zooKeeper

  • watch：允许多个 client 一起监听一个 znode 的状态变更，并在状态变化时收到一条消息回调（callback）

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

    • 处理方式：轮训探活，避免脑裂，fence机制（阻止多个节点写同样的日志）

  • client侧：StandbyException，Client自动处理

avatar
文章
阅读
粉丝