第一阶段: 先说说伪分布式
不管是 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.
第四阶段: HDFS 故障自动转移
两个 NameNode, 我们需要自动切换故障转移, 那么我们需要借助 HDFS 的 ZKFC 进程, 这个进程是给予 ZooKeeper 的. 首先我们需要配置好 ZooKeeper.
这个配置很简单
第五阶段: YARN 的 HA
其实 YARN 的 HA 配置比 HDFS 要简单的多, YARN 的 HA 只是基于 ZooKeeper 来配置它的高可用性. 在 Hadoop2.4 版本之前是单节点故障.
我们说故障转移, 是不是跟 HDFS 一样需要有个 ZKFC 的进程呢, 其实它是有的. 只不过 RM 中的 ZKFC 是以线程的方式存在于 RM 的进程中. 所以, 在配置故障转移的时候, 我们不需要像 HDFS 一样单独去启动一个 ZKFC 进程.
来源: http://www.jianshu.com/p/adf95eb61bfc