HDFS （Hadoop Distributed File System）的高可用需求和高扩展机制|青训营笔记

用户3654165348449
168 阅读4分钟

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

简单概述

HDFS （Hadoop Distributed File System）是 Hadoop 下的分布式文件系统，具有高容错、高吞吐量等特性，可以部署在低成本的硬件上。是 Hadoop 核心组件之一，作为最底层的分布式存储服务而存在。

分布式文件系统解决的问题就是大数据存储。它们是横跨在多台计算机上的存储系统。 HDFS使用Master和Slave结构对集群进行管理。一般一个 HDFS 集群只有一个 Namenode 和一定数目的Datanode 组成。Namenode 是 HDFS 集群主节点，Datanode 是 HDFS 集群从节 点，两种角色各司其职，共同协调完成分布式的文件存储服务。

可以存储超大文件

  • a. 这里的“超大文件”是指几百MB、GB甚至TB级别的文件。
  • b. 数据块（block）
  • c. 大文件会被分割成多个block进行存储，block大小默认为128MB。每一个block会在多个datanode上存储多份副本，默认是3份。

流式数据访问

  • a. 最高效的访问模式是 一次写入、多次读取 运行在普通廉价的服务器上
  • b. HDFS设计理念之一就是让它能运行在普通的硬件之上，即便硬件出现故障，也可以通过容错策略来保证数据的高可用。
  • c. 横向扩张

一、元数据服务高可用

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
文章
阅读
粉丝