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

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

通过双NameNode消除单点故障

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

内存中各自保存一份元数据；

共享的Edits放在一个共享存储中管理（qjournal和NFS两个主流实现）；

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

实现了一个zkfailover，常驻在每一个namenode所在的节點每一个zkfailover负责监控自己所在NameNode节点，利用zk进行状态标识当需要进行状态切换时，由zkfailover来负责切换切换时需要防止brain split现象的发生。

自动故障轉移为HDFS部署增加了两个新组件：ZooKeeper和ZKFailoverController（ZKFC）进程ZooKeeper是维护少量协调数据，通知客户端这些数据的改变和监视客户端故障的高可用服务HA的自动故障转移依赖于ZooKeeper的以下功能：

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

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

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

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

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

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

单节点相当不可靠,所以用多节点来解决.多节點就会涉及到两个问题--谁是主谁是从(一个写多个读),以及如何确保通信.

既然每个节点都会宕机,所以写出去的edits.log就要放到一个第三方上--qjournal,而且qjournal也是┅个hadoop集群yarn,对外提供一致性接口.

NameNode之间直接通信不可靠,所以需要一个ZooKeeper来作为中介,实时监控状态.状态为Active的才可以写,其他的只能读,以及更频繁的做原本2NN做的备份的事情

Zkfc的出现,是为了不破坏已有的代码健壮性和稳定性

如果不确定Active节点是宕机还是网络问题,千万不要贸然让另外的节点上位為Active.如果是之间的网络通信问题而贸然上位,将会产生非常严重的脑裂现象,让数据全部都不可靠

5). 重新配置hdfs-site.xml,如果没有配置机器间的无密登录,需要先去生成和设置.注意hadoop集群yarn名称是要对应的,以及每个节点的host名称,以及路径,不要搞错咯~~

2. 茬[nn1]上，对其进行格式化并启动

xsync同步配置文件

关闭所有HDFS服务：

xsync配置文件到其他机器

下面我们来介绍启动hdfs和yarn的一些命囹

1.启动hdfshadoop集群yarn（使用hadoop的批量启动脚本）

2.停止hdfshadoop集群yarn（使用hadoop的批量启动脚本）

 分别查看启动后3台虚拟机上的进程情况：

3.启动yarnhadoop集群yarn（使用hadoop的批量啟动脚本）

如果觉得本文对您有帮助，不妨扫描下方微信二维码打赏点您的鼓励是我前进最大的动力：