Hadoop HA 高可用

目录

 

1、 HA概述

2、 HDFS-HA工作机制

2.1 HDFS-HA工作要点

2.2 HDFS-HA自动故障转移工作机制

3、 HDFS Federation架构设计

3.1 NameNode架构的局限性

3.2 HDFS Federation架构设计

3.3 HDFS Federation应用思考

---

1、 HA概述

（1）所谓HA（High Availablity），即高可用（7*24小时不中断服务）。

（2）实现高可用最关键的策略是消除单点故障。HA严格来说应该分成各个组件的HA机制：HDFS的HA和YARN的HA。

（3）Hadoop2.0之前，在HDFS集群中NameNode存在单点故障（SPOF）。

（4）NameNode主要在以下两个方面影响HDFS集群

• NameNode机器发生意外，如宕机，集群将无法使用，直到管理员重启
• NameNode机器需要升级，包括软件、硬件升级，此时集群也将无法使用

        HDFS HA功能通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode很快的切换到另外一台机器。

2、 HDFS-HA工作机制

       通过双NameNode消除单点故障

2.1 HDFS-HA工作要点

1）元数据管理方式需要改变

• 内存中各自保存一份元数据；
• Edits日志只有Active状态的NameNode节点可以做写操作；
• 两个NameNode都可以读取Edits；
• 共享的Edits放在一个共享存储中管理（qjournal和NFS两个主流实现）；

2）需要一个状态管理功能模块

• 实现了一个zkfailover，常驻在每一个namenode所在的节点，每一个zkfailover负责监控自己所在NameNode节点，利用zk进行状态标识，当需要进行状态切换时，由zkfailover来负责切换，切换时需要防止brain split现象的发生。
• Split-Brain问题说的是1个集群如果发生了网络故障，很可能出现1个集群分成了两部分，而这两个部分都不知道对方是否存活，不知道到底是网络问题还是直接机器down了，所以这两部分都要选举1个Leader，而一旦两部分都选出了Leader, 并且网络又恢复了，那么就会出现两个Brain的情况，整个集群的行为不一致了。

     3）必须保证两个NameNode之间能够ssh无密码登录

4）隔离（Fence），即同一时刻仅仅有一个NameNode对外提供服务

2.2 HDFS-HA自动故障转移工作机制

       使用命令hdfs haadmin -failover手动进行故障转移，在该模式下，即使现役NameNode已经失效，系统也不会自动从现役NameNode转移到待机NameNode。自动故障转移为HDFS部署增加了两个新组件：ZooKeeper和ZKFailoverController（ZKFC）进程。ZooKeeper是维护少量协调数据，通知客户端这些数据的改变和监视客户端故障的高可用服务。HA的自动故障转移依赖于ZooKeeper的以下功能：

1）故障检测

集群中的每个NameNode在ZooKeeper中维护了一个持久会话，如果机器崩溃，ZooKeeper中的会话将终止，ZooKeeper通知另一个NameNode需要触发故障转移。

2）现役NameNode选择

ZooKeeper提供了一个简单的机制用于唯一的选择一个节点为active状态。如果目前现役NameNode崩溃，另一个节点可能从ZooKeeper获得特殊的排外锁以表明它应该成为现役NameNode。

ZKFC是自动故障转移中的另一个新组件，是ZooKeeper的客户端，也监视和管理NameNode的状态。每个运行NameNode的主机也运行了一个ZKFC进程，ZKFC负责：

3）健康监测

ZKFC使用一个健康检查命令定期地ping与之在相同主机的NameNode，只要该NameNode及时地回复健康状态，ZKFC认为该节点是健康的。如果该节点崩溃，冻结或进入不健康状态，健康监测器标识该节点为非健康的。

4）ZooKeeper会话管理

当本地NameNode是健康的，ZKFC保持一个在ZooKeeper中打开的会话。如果本地NameNode处于active状态，ZKFC也保持一个特殊的znode锁，该锁使用了ZooKeeper对短暂节点的支持，如果会话终止，锁节点将自动删除。

5）基于ZooKeeper的选择

如果本地NameNode是健康的，且ZKFC发现没有其它的节点当前持有znode锁，它将为自己获取该锁。如果成功，则它已经赢得了选择，并负责运行故障转移进程以使它的本地NameNode为Active。故障转移进程与前面描述的手动故障转移相似，首先如果必要保护之前的现役NameNode，然后本地NameNode转换为Active状态。

3、 HDFS Federation架构设计

3.1 NameNode架构的局限性

1）Namespace（命名空间）的限制

由于NameNode在内存中存储所有的元数据（metadata），因此单个NameNode所能存储的对象（文件+块）数目受到NameNode所在JVM的heap size的限制。50G的heap能够存储20亿（200million）个对象，这20亿个对象支持4000个DataNode，12PB的存储（假设文件平均大小为40MB）。随着数据的飞速增长，存储的需求也随之增长。单个DataNode从4T增长到36T，集群的尺寸增长到8000个DataNode。存储的需求从12PB增长到大于100PB。

2）隔离问题

由于HDFS仅有一个NameNode，无法隔离各个程序，因此HDFS上的一个实验程序就很有可能影响整个HDFS上运行的程序。

3）性能的瓶颈

由于是单个NameNode的HDFS架构，因此整个HDFS文件系统的吞吐量受限于单个NameNode的吞吐量。

3.2 HDFS Federation架构设计

能不能有多个NameNode

NameNode	NameNode	NameNode
元数据	元数据	元数据
Log	machine	电商数据/话单数据

 

3.3 HDFS Federation应用思考

不同应用可以使用不同NameNode进行数据管理图片业务、爬虫业务、日志审计业务。Hadoop生态系统中，不同的框架使用不同的NameNode进行管理NameSpace。（隔离性）