第一阶段：先说说伪分布式
不管是HDFS和YARN，在我们之前的文章中已经说过关于伪分布式的部署和安装。也就是我们把HDFS的两个节点NameNode和DataNode，YARN的ResourceManger和NodeManager都放在同一个机器上。
机器1：bigdata-senior01.kfk.com
进程包括：
NameNode
DataNode
ResourceManager
NodeManager
互联网科技发展蓬勃兴起，人工智能时代来临，抓住下一个风口。为帮助那些往想互联网方向转行想学习，却因为时间不够，资源不足而放弃的人。我自己整理的一份最新的大数据进阶资料和高级开发教程，大数据学习群：199加上【427】最后加上210就可以找到组织学习 欢迎进阶中和进想深入大数据的小伙伴加入。
第二阶段：Hadoop分布式初级设计
既然是分布式，我们说分布式是主从架构，也就是说至少要一个主节点，多个从节点吧。所以不管是HDFS或者YARN，对于DataNode节点和NodeManager节点必须是多台，最少也要是3台。我们自己玩，机器资源不富裕的情况下，搞个3台机器没有问题，效果一样能达到。所以，接下来我们做一个分布式集群机器的规划设计。
机器规划
机器1：bigdata-senior01.kfk.com
进程包括：
NameNode
DataNode
NodeManager
机器2：bigdata-senior02.kfk.com
进程包括：
ResouceManager
NodeManger
DataNode
机器3：bigdata-senior03.kfk.com
进程包括：
DataNode
NodeManager
SecondaryNameNode
首先我们保证每天机器上分别有一个DataNode节点和NodeManager节点。因为都是从节点，真正干活的。在数量上我们要保证。那么NameNode和ResourceManager是两个非常重要的管理者，在我们架构设计的时候，尽可能的把它们分开，不要放在一台机器上。我们客户端的请求，第一时间与NameNode和ResourceManager打交道。NameNode负责管理HDFS文件系统的元数据，客户端不管是读文件还是写文件，都要首先找到NameNode获取文件的元数据，再进行文件的操作。ResourceManager也是如此，它负责管理集群中的资源和任务调度，你也可以把它视为“大数据操作系统”。客户端能否提交应用并运行，就看你的ResourceManager是否正常。
SecondaryNameNode的作用
还有一个进程，就是下图中的SecondaryNameNode,它是干什么的呢。我们可以这么来理解，比如NameNode就好比是我们一本书的目录，它就像一本书内容的管理员，当用户需要看书的时候，他可以告诉用户这个书的标题是什么，内容 在哪一页，用户通过书的目录直奔某一页的内容。假如有一天，这个书的内容发生了变化，增加了好多内容，前天张三加了内容，昨天王四加了内容，今天李二加了内容，如果这个书的内容在不断的变化，那我的目录是不是要变化？这是一定的。如果你的书目录与书的内容同步，那这个书就没有意义了，对于用户来说，不会看你这本书。我们只是举个例子，当然现实中不可能存在，除非是电子WORD文档，还是有这个场景的。
其实中这个例子中我们可以看出，如果书的内容要与目录同步，我们必须要不停的跟进修改内容的日志信息来重新改编我们的书目录，也就是只要书的内容变化了，我们就要对书的目录做一个合并，永远保证与内容同步一致。那么SecondaryNameNode这个进程做的工作就如同根据书的内容不停的重新合并书目录一样，在HDFS文件系统中，它会根据用户对文件的操作日志，来合并NameNode中文件元数据，永远保证元数据与DataNode节点上存储的文件信息一致。
为什么要HA
从我们上一步的集群设计规划中可以看出，我们只有一个NameNode节点。我们说NameNode的节点是非常重要的，如果只有一个NameNode并且出现故障，那整个HDFS集群将无法使用，直到NameNode重新启动。那我们是否可以考虑部署两个NameNode节点呢？从现实意义上来说，这是必须的。这也就是我们要说的HDFS的HA设计。
NameNode主要在以下两个方面影响HDFS集群：
NameNode集群发生意外，如宕机，集群将无法使用，直到管理员重启
NameNode机器需要升级，包括软件、硬件升级，此时集群将无法使用
其实在Hadoop2.0之前，在HDFS集群中NameNode是存在单点故障的。
HA的重要性
那么什么是HDFS的HA呢，也就是说HA的功能通过配置Active/Standby两个NameNodes来解决在集群中NameNode单点故障的问题。如果对外提供服务的Active节点出现故障或者需要升级，这时我们可以通过HA将NameNode很快的切换到另一台机器上，继续对外服务。从而达到HDFS的高可用性。
HA的架构设计中，我们设计了两台NameNode节点。当然对于客户端访问来说，我们也是需要做一个代理的。为什么要代理？对于客户端访问来说，HDFS是透明的，你有多少台NameNode节点，客户端并不关心，你HDFS只要保证一点，能让我正常访问HDFS系统就OK。但对于HDFS系统来说，两个NameNode，你得选择哪个提供给客户端访问，所以必须要有代理机制。也就是在NameNode的上层必须要有一个代理层。那这个代理层就需要我们之前说的协同服务框架Zookeeper来做。
基于上面的架构图，我们来思考一个问题：
如何保证edit日志文件的安全和完整
我们两个NameNode节点，如果Active节点宕机，我Standby节点要接着继续对服务，那么这个正常对外服务源自与文件元数据的完整性，也就是说Active节点要实时非常安全、完整的记录文件的操作日志信息，这样Standby在读取的时候，读取的日志信息是完整的，当Active节点宕机，Standby才能接手继续工作。
方案一：一个好的文件系统
找一台比较好的服务器，作为外部的文件存储设备，Active节点的NameNode将edit日志文件写入，Standby节点的NameNode将读取写入的日志文件。那么这种方案需要好的企业级服务。成本上来说代价昂贵，与我们小成本、大集群的分布式理念相违背。
方案二：分布式存储日志信息QJM
NameNode管理文件的元数据，包括fsimage和edits，在开始启动的时候NameNode的Active节点和Standby节点元数据是一样的。但是启动之后，Active节点提供对外服务，那么它的edits日志文件在不停的变化，这个时候两个NameNode节点上的日志文件肯定是不一样的。那么就需要一种机制，保证Active节点的日志安全的写入某个地方，并且让Standby节点能完整的读取。
我们说HDFS文件的安全性和完整性是通过DataNode节点副本的方式来保证的，每一个文件的存储默认至少是3份。那么我们的edit日志文件为了保证安全性，也类似于DataNode文件的存储方式，以2n+1副本的方式进行存储。n表示允许损坏的机器节点数量。也就是说Active的NameNode节点将edit日志存三份，允许其中一个节点写入edit日志失败。那么负责存储edit日志文件节点进程是谁呢？就是JournalNode。它的节点数必须是奇数。JournalNode负责管理edit日志文件的安全性和完整性，从而达到NameNode的Active节点与Standby节点之间元数据的同步。
“use HDFS HA using the Quorum Journal Manager (QJM) to share edit logs between the Active and Standby NameNodes“这是官网的一句话。QJM，分布式的日志管理，节点名称就是JournalNode。
方案三：使用ZooKeeper进行数据存储
edits文件数据量不是很大，所以我们也可以采用ZooKeeper进行存储。
那么一般架构设计中，还是采用QJM分布式日志存储来达到两个NameNode节点之间元数据的同步。
不管是Active节点还是Standby节点，每个DataNode服务必须报告自己的块信息。
一下说明来自官方：
Note that, in an HA cluster, the Standby NameNode also performs checkpoints of the namespace state, and thus it is not necessary to run a Secondary NameNode, CheckpointNode, or BackupNode in an HA cluster. In fact, to do so would be an error. This also allows one who is reconfiguring a non-HA-enabled HDFS cluster to be HA-enabled to reuse the hardware which they had previously dedicated to the Secondary NameNode。
两个NameNode，我们需要自动切换故障转移，那么我们需要借助HDFS的ZKFC进程，这个进程是给予ZooKeeper的。首先我们需要配置好ZooKeeper。
这个配置很简单
第五阶段：YARN的HA
其实YARN的HA配置比HDFS要简单的多，YARN的HA只是基于ZooKeeper来配置它的高可用性。在Hadoop2.4版本之前是单节点故障。
我们说故障转移，是不是跟HDFS一样需要有个ZKFC的进程呢，其实它是有的。只不过RM中的ZKFC是以线程的方式存在于RM的进程中。所以，在配置故障转移的时候，我们不需要像HDFS一样单独去启动一个ZKFC进程。
网友评论