1 背景

在Hadoop 2.0.0之前，NN是HDFS集群中的单点故障(SPOF)。每一个集群只有一个NN,如果这个机器或进程不可用，整个集群就无法使用。
这主要从如下两个方面影响了HDFS集群的可用性:

  • 在发生意外事件(如机器崩溃)时，集群将不可用，直到重新启动NN。
  • 计划好的集群运维事件(如NN机器上的软件或硬件升级)将导致集群的窗口停机。

HDFS的高可用性解决了上述问题，通过在同一个集群中运行2个以上的NN，其中一个作为active, 其它作为standby。这允许在active NN的机器崩溃或进程不可用时快速故障转移到新的NN，或者在进行计划维护时，将NN转移到standby上。

HDFS的高可用，有2种方案：基于共享NFS的HA、基于QJM/Qurom Journal Manager的HA
HDFS的HA机制，主要分为两块：元数据同步和主备选举。

  • 元数据同步依赖于NFS 或 QJM 的共享存储
  • 主备选举依赖于ZKFC和Zookeeper

为了方便描述，文中针对一些名称使用缩写表示

缩写

描述

NN

NameNode

ANN

Active NameNode

SNN

Standby NameNode

HA

High Availability

QJM

Qurom Journal Manager

ZKFC

ZKFailoverController

SPOF

a single point of failure

JN

JournalNode

ZK

zookeeper

2 HDFS HA

2.1 基于QJM的HA

hadoop2.x之后，Clouera提出了QJM/Qurom Journal Manager的HA方案。
这是一个基于Paxos算法（分布式一致性算法）实现的HDFS HA方案，主要优势如下：

  • 不需要配置额外的高性能共享存储，降低了系统复杂度和维护成本。
  • 消除SPOF(单点故障)
  • 系统鲁棒性(Robust)的程度可配置、可扩展。

基本原理: 使用用2N+1台 JournalNode 存储EditLog，每次写数据操作有>=N+1返回成功时即认为该次写成功，保证数据不会丢失。

HA 架构图

  • 高可用方案中NN有>=2个，只有一个是Active状态，表示正在对外提供服务的，是活跃的NN，其它的NN是StandBy状态，不对外提供服务的，随时准备替换Active NN.
  • JournalNode（JN） : 高效的存储系统，能够实现数据的超快速写入与读取。JN是一个小的文件系统集群，节点数需要是2N+1台
  • 当Active NN执行任何命名空间修改时，它会持续地将修改记录记录到大多数这些JN上。StandBy NN实时读取JN内部的数据，实现两个节点的实时元数据同步。

s3和hdfs区别 hdfs ha_HDFS HA



  • 配置参数
  • dfs.namenode.shared.edits.dir: 配置JournalNodes 地址，由JournalNodes 集群提供共享的编辑存储，由Active NN写入，由Standby NN读取，以保持与Active NN所做的所有文件系统更改同步
  • dfs.journalnode.edits.dir: JournalNode守护进程存储本地状态的路径。JournalNode机器上的绝对路径且只能配置一个路径。
<property>
  <name>dfs.namenode.shared.edits.dir</name>
  <value>qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster</value>
</property>
<property>
  <name>dfs.journalnode.edits.dir</name>
  <value>/path/to/journal/node/local/data</value>
</property>

2.2 基于共享NFS的HA

与QJM的区别是：使用高性能共享存储存储HDFS的元数据，但只有Active NN的才能写，Standby NN只能读

配置如下：

  • dfs.namenode.shared.edits.dir : 远程共享编辑目录的路径，备用NN使用同一个目录，以保持与Active NN所做的所有文件系统更改同步。这个目录应该以r/w的方式挂载在NN机器上，且需要配置为绝对路径
<property>
  <name>dfs.namenode.shared.edits.dir</name>
  <value>file:///mnt/filer1/dfs/ha-name-dir-shared</value>
</property>

3 HDFS HA自动切换

HA自动切换NN, 需要增加了两个新的组件:ZooKeeper集群和ZKFailoverController进程(简称ZKFC)

  • 集群启动 >= 2个NN, 每个NN都会有一个ZKFC,每个ZKFC到Zookeeper上lock节点下创建临时有序的子节点，节点最小的为Active NN, 其它变为standby的ZKFC会监控lock节点（若节点发生变化，表示Active出现异常）
  • ZKFC的作用是监视和管理NN的状态，管理与ZK的会话，并在active NN不可用时，启动基于ZK的选举。

3.1 ZK集群的作用

  • 失败保护——集群中的每个NN机器在ZooKeeper中维护一个持久的会话。如果机器崩溃，ZooKeeper会话将过期，通知其他NN应该触发故障转移。
  • NN主动选举——ZooKeeper提供了一种简单的机制，专门选举一个节点为Active。如果当前Active NN崩溃，另一个节点可能会在ZooKeeper中获得一个特殊的排他锁，指示它应该成为下一个Active NN。
  • 防脑裂： ZK本身是强一致和高可用的，可以用它来保证同一时刻只有一个活动节点

3.2 ZKFC的作用

  • 健康检测: ZKFC使用健康检查命令定期ping其本地NN。只要NN以健康状态及时响应，ZKFC就认为该节点是健康的。如果节点已崩溃、冻结或以其他方式进入不正常状态，运行状况监视器将将其标记为不正常状态，并触发回调ZKFailoverController进行自动主备切换
  • ZK会话管理 : 当本地NN处于健康状态时，ZKFC在ZooKeeper中保持一个会话打开。如果本地NN是Active，它还持有一个特殊的“锁”znode。这个锁使用了ZooKeeper对临时节点的支持;如果会话超时，锁节点将被自动删除。
  • 基于ZK的选举：如果本地NN是健康的，并且ZKFC看到当前没有其他节点持有锁znode，它自己将尝试获取锁。如果它成功了，那么它就“赢得了选举”，并负责运行故障转移以使其本地NN处于Active。

3.3 故障转移过程

  • 当Active NN出现异常【崩溃、假死】，Active NN的ZKFC得知异常后断开与Zookeeper的连接，此时Zokeeper上的临时节点就会消失
  • Standby 的ZKFC收到Zokeeper的断开信息，通知standby NN, standby NN远程登录到原始Active NN节点，强行kill NN进程。
  • 通知standby ZKFC抢占Zookeeper上的临时节点，抢占成功，将状态从standby变为active
  • 当原始Active NN重新恢复后，ZKFC到Zookeeper上lock节点下创建临时有序的子节点, 但因为节点不是最小的，所以作为standby NN.

s3和hdfs区别 hdfs ha_s3和hdfs区别_02

s3和hdfs区别 hdfs ha_s3和hdfs区别_03

3.4 触发HDFS NN自动切换的场景

  • Active NN JVM崩溃： Active NN不能及时响应ZKFC的健康检测命令，HealthMonitor会触发状态迁移SERVICE_NOT_RESPONDING, 然后Active NN上的ZKFC会断开与ZK的连接，Standby NN上的ZKFC会获得Active Lock, 作相应隔离后成为Active NN。
  • Active NN JVM冻结：这个是JVM没崩溃，但也无法响应，同崩溃一样，会触发自动切换。
  • Active NN 机器宕机：此时ActiveStandbyElector会失去同ZK的心跳，会话超时，Standby NN上的ZKFC会通知ZK删除Active NN的活动锁，作相应隔离后完成主备切换。
  • Active NN 健康状态异常： 此时HealthMonitor会收到一个HealthCheckFailedException，并触发自动切换。
  • Active ZKFC崩溃：虽然ZKFC是一个独立的进程，但因设计简单也容易出问题，一旦ZKFC进程挂掉，虽然此时NN是OK的，但系统也认为需要切换，此时Standby NN会发一个请求到Active NN要求Active NN放弃主结点位置，Active NN收到请求后，会触发完成自动切换。
  • ZooKeeper崩溃：如果ZK崩溃了，主备NN上的ZKFC都会感知断连，此时主备NN会进入一个中立模式【NeutralMode】，同时不改变主备NN的状态，继续发挥作用，只不过此时，如果ANN也故障了，那集群无法发挥Failover, 也就不可用了，所以对于此种场景，ZK一般是不允许挂掉到多台，至少要有N/2+1台保持服务才算是安全的。

参考

HDFS High AvailabilityHDFS High Availability Using the Quorum Journal ManagerIntroduction to HDFS High Availability