This website requires JavaScript.

HDFS的高可用性

本文为CDH官方文档HDFS High Availability的译文,有不足之处还请指正。

HDFS HA介绍(Introduction to HDFS High Availability)

该章节架设读者对HDFS组件有所了解,更多内请查看Apache HDFS Architecture Guide

背景

在标准配置中,HDFS群集中Namenode是一个单点故障(SPOF)。每个集群都有一个节点,如果主机或进程变得不可用,整个群集就不可用,直到Namenode重启或有一台新机器加入。Secondary NameNode并不提供故障转移功能。

标准配置降低可用性的情况主要有两个方面:减少的方式主要有两个HDFS集群的总的可用性:

  • 在一个意外事件如主机死机的情况下,群集不可用直到操作员重启NameNode。
  • 停机维护事件,如软件或硬件升级。

HDFS的HA提供了在同一个集群上运行的两节点的选项,来解决上述问题。这些被称为主动节点和备份节点。不同于Secondary Namenode,备用NameNode是热备,允许快速自动故障转移至另一个点或由管理员手动发起的维护计划的故障转移。 你不能有两个以上的NameNode节点。

实现

Cloudera Manager 5 及 CDH 5 只支持基于Quorum存储HA实现。相比之下支持Quorum存储和共享NFS,要切换到Quorum存储请查看Converting From an NFS-mounted Shared Edits Directory to Quorum-based Storage

**重要:**当你想从CDH4 NFS配置HA的方式升级到Cloudera Manager 5: •如果你在升级前没有关掉HA,那么你的HA配置可以继续工作,只是会提醒你切换到Quorum存储 •如果你在升级前关掉了HA,那你就升级后就没法继续用NFS方式而且必须用Quorum存储开启HA

基于Quorum的存储

Quorum-based Storage也就是HA实现的Quorum Journal Manager (QJM机制).

备用NameNode为保持与主动NameNode的同步状态,通过一组为journalnodes的守护进行进行通信。当主动NameNode的namespace有任何修改的时候都会把修改记录存储大部分JournalNodes.备用NameNode读取JournalNodes的修改记录, 并不断地监视日志的变化。当备用节点看到变化时,会应用到自己的Namespace。在发生故障转移,备用节点需要在激活之前确保已经阅读JournalNodes的所有改动。这确保在故障转移之前namespace的状态是完全同步的。

要提供快速故障转义,备用节点的快位置信息得是最新的。要做到这一点DataNode配置两个NameNode的位置,把块位置信息和心跳同时发给它们。

对于HA集群,同一时间只有一个节点是活跃的是至关重要的。否则,namespace状态将在两个之间迅速发散,可能会导致数据丢失或其他不正确的结果。为确保这个特性并防止"脑裂(split-brain)", JournalNodes一次允许一个节点写入(作为Writer).故障转移期间,被激活的NameNode会代替原来的Writer,有效防止了另一个NameNode继续写数据,让新的激活节点安全地进行故障转移。

**Note:**正因为如此, 屏障(fencin)不是必须的,但它仍然是有用的; 查看Enabling HDFS HA

使用NFS共享存储

为保持备用节点与主动节点的同步状态,这需要实现两个节点都有一个共享的存储设备的目录(例如,挂在一个NFS)。

当NameNode namespace发生修改的时候他会把改动写入共享目录的edit log文件中。备用NameNode时刻注意该目录的变化,当变动出现的时候,备用NameNode将他们应用到自己的namespace。 在发生故障转移时,备用节点需要在激活之前确保已经读取JournalNodes的所有改动。这确保在故障转移之前namespace的状态是完全同步的。

为防止两个NameNode发生"脑裂(split-brain)"情况, 管理员至少要为共享存储配置一个屏障(fencing)方法。 如果故障转移期间,它不能证实先前的活动节点已经放弃了其活性状态,则屏障负责切断先前的活动节点访问共享存储。这样可以防止进一步的修改命名空间,允许新的主动节点安全地进行故障转移。

自动故障转移功能的实现

自动故障转移依赖于HDFS的另外两个组件:ZooKeeper quorum和zkfailovercontroller进程(简称zkfc)。在Cloudera Manager中zkfc对应HDFS的Failover Controller角色。

Apache ZooKeeper是维持少量的协调数据高可用的服务,通知客户端数据的变化,并监测故障。HDFS自动故障转移功能的实现依赖于ZooKeeper以下的功能:

  • 故障检测(Failure detection) - 群集中的每个NameNode在ZooKeeper中都有一个持久会话。如果宕机,Zookeeper会话就会过期,通知其他节点,应触发故障转移。
  • 主动NameNode选举(Active NameNode election) - ZooKeeper提供一个简单的机制进行排他主动节点的选择。当主动(活动)节点宕机,另一个节点可以在ZooKeeper中采取特殊的排他锁来指示它应成为下一个活动节点。

ZKFailoverController (ZKFC) 是ZooKeeper的客户端,同样监控和管理NameNode的状态。每个运行NameNode的主机都会运行一个ZKFC,负责以下内容:

  • 健康监测(Health monitoring) - ZKFC定期发送一个健康检查命令给本机Namenode。只要NameNode返回‘健康’状态,ZKFC就人为NameNode是健康的.如果NameNode宕机,没响应或以其他方式进入一个不健康的状态,健康监控就认为他是不健康的。
  • ZooKeeper会话管理(ZooKeeper session management) - 当本地NameNode为健康状态,ZKFC保持在ZooKeeper中开启的会话。如果本机NameNode为激活状态,还会保持一个特殊锁。该锁使用ZooKeeper提供的“ephemeral”节点支持;如果session过期,锁结自动删除。
  • 基于ZooKeeper的‘选举’(ZooKeeper-based election) - 如果本地NameNode健康,并且ZKFC没有看到其他NameNode占用锁, 它自自己会试图获得锁。如果成功了,它就“赢得选择”,然后负责运行故障转移使它的本地NameNode处于活动状态。故障转移过程类似于上述的手动故障转移:首先先前活动的NodeName会被屏蔽(如果必要的话),然后本地NameNode过渡到活动状态。

HDFS HA 硬件配置

要部署基于Quorum存储的HA群集,您需要做如下准备:

  • NameNode 节点 - 该节点运行你的活动NameNode及备用NameNode。他们的硬件配置应该相同。
  • JournalNode - 该节点运行JournalNode. Cloudera 建议你将JournalNode放在主要服务器,或NameNode, Standby NameNode, JobTracker这类的。这样JournalNodes的本地目录就比较可靠。
  • 如果放在一起,JournalNode进程和NameNode进程应该使用各自的硬盘,请不要使用SAN或者NAS.
  • JournalNode服务至少需要三个,修改日志必须写入大多数JournalNode.这将允许系统容忍一个单一主机的故障。你也可以运行三个以上的JournalNodes,增加系统故障冗余, JournalNodes必须为奇数, (3, 5, 7等). 注意,当运行N个JournalNode, 系统允许 (N - 1) / 2 个注意,当运行N个JournalNode发生故障。如果quorum存储无效,那么NameNode无法格式化和启动,你会看到类似下面的错误:

    12/10/01 17:34:18 WARN namenode.FSEditLog: Unable to determine input streams from QJM to [10.0.1.10:8485, 10.0.1.10:8486, 10.0.1.10:8487]. Skipping. java.io.IOException: Timed out waiting 20000ms for a quorum of nodes to respond.

注意: 在HA的环境中,备用的NameNode也会执行checkpoint,因此 Secondary NameNode是不需要的。如果你从在HDFS群集上开启HA,原来指定Secondary NameNod的机器可以复用。

参考

分布式系统理论之Quorum机制

0条评论
avatar