cdh-HDFS高可用性简介

背景

在标准配置中,NameNode是HDFS集群中的单点故障(SPOF)。每个群集都有一个NameNode,如果该主机或进程不可用,整个群集将不可用,直到NameNode重新启动或在新主机上启动为止。 Secondary NameNode不提供故障转移功能。
标准配置通过两种主要方式来降低HDFS集群的总可用性:
- 在发生主机崩溃等意外事件时,直到操作员重新启动NameNode,集群才可用。
- 计划的维护事件(如NameNode计算机上的软件或硬件升级)会导致群集停机时间。

HDFS HA通过在主动/被动配置中提供在同一集群中运行两个NameNode的选项来解决上述问题。这些被称为活动NameNode和备用NameNode。与Secondary NameNode不同的是,备用NameNode是热备用,允许在主机崩溃的情况下快速自动故障转移到新的NameNode,或者为了计划维护的目的而进行正常的管理员启动的故障转移。您不能有两个以上的NameNode。

实现

Cloudera Manager 5和CDH 5支持基于Quorum的存储来实施HA。

Quorum-based Storage

Quorum-based Storage是指使用Quorum Journal Manager(QJM)的HA实施。
为使备用NameNode在此实现中保持其状态与活动NameNode同步,两个节点都与一组名为JournalNodes的独立守护进程进行通信。当活动的NameNode执行任何名称空间修改时,它会将修改记录持久记录到大多数JournalNode。备用NameNode能够读取来自JournalNodes的编辑,并持续监视它们以更改编辑日志。当备用节点看到编辑时,它将它们应用到它自己的名称空间。如果发生故障转移,备用服务器会确保它在将自己提升为活动状态之前从JournalNodes中读取所有编辑。这确保了在故障转移发生之前命名空间状态已完全同步。

为了提供快速故障转移,备用NameNode还需要有关于群集中块的位置的最新信息。为此,DataNode配置了两个NameNode的位置,并将块位置信息和心跳发送给两者。
HA群集的正确操作对于一次只有一个NameNode处于活动状态至关重要。否则,命名空间状态将很快在两者之间发生分歧,从而可能导致数据丢失或其他不正确的结果。为了确保这种属性并防止所谓的“裂脑情景”,JournalNodes一次只允许一个NameNode成为作者。在故障转移期间,要成为活动状态的NameNode只需接管写入JournalNodes的角色,这有效地防止另一个NameNode继续处于活动状态,从而允许新的活动NameNode安全地继续进行故障转移。

Automatic Failover自动故障转移

自动故障转移依赖于HDFS中的两个附加组件:一个ZooKeeper quorum和ZKFailoverController进程(缩写为ZKFC)。在Cloudera Manager中,ZKFC进程映射到HDFS故障切换控制器角色。
Apache ZooKeeper是一种高度可用的服务,用于维护少量的协调数据,通知客户端数据发生变化,并监视客户端的故障。 HDFS自动故障转移的实现依赖ZooKeeper提供以下功能:

  • 失败检测 - 集群中的每个NameNode机器都在ZooKeeper中维护一个持久会话。如果机器崩溃,ZooKeeper会话将过期,并通知其他NameNode应该触发故障转移。

  • 活动NameNode选举 - ZooKeeper提供了一种简单的机制来独占选择节点为活动状态。如果当前活动的NameNode崩溃,另一个节点可以在ZooKeeper中使用一个特殊的独占锁,表明它应该成为下一个活动的NameNode。

ZKFailoverController(ZKFC)是一个ZooKeeper客户端,它也监视和管理NameNode的状态。每个运行NameNode的主机也运行一个ZKFC。 ZKFC负责:

  • 健康监控 - ZKFC定期与健康检查命令联系其本地NameNode。只要NameNode以健康状态及时响应,ZKFC就认为NameNode健康。如果NameNode崩溃,冻结或以其他方式进入不健康状态,健康监视器将其标记为不健康。

  • ZooKeeper会话管理 - 当本地NameNode健康时,ZKFC在ZooKeeper中保持会话打开状态。如果本地NameNode处于活动状态,则它还包含特殊的锁定znode。该锁使用ZooKeeper对“短暂”节点的支持;如果会话过期,锁定节点会自动删除。

    扫描二维码关注公众号,回复: 1671694 查看本文章
  • 基于ZooKeeper的选举 - 如果本地NameNode健康,并且ZKFC发现没有其他NameNode当前拥有锁定znode,它将自己尝试获取锁定。如果成功,则它“赢得选举”,并负责运行故障转移以使其本地NameNode处于活动状态。故障切换过程与上述手动故障切换类似:首先,如果必要,先前的活动将被隔离,然后本地NameNode转换为活动状态。

猜你喜欢

转载自blog.csdn.net/m0_37618809/article/details/80747992