HDFS专项

HDFS概述

使用场景：一次写入，多次读取，且不支持文件的修改

1. 优缺点

2. 组织架构

3）Client：就是客户端。

​ （1）文件切分。文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行上传；

​ （2）与NameNode交互，获取文件的位置信息；

​ （3）与DataNode交互，读取或者写入数据；

​ （4）Client提供一些命令来管理HDFS，比如NameNode格式化；

​ （5）Client可以通过一些命令来访问HDFS，比如对HDFS增删查改操作；

4）Secondary NameNode：并非NameNode的热备。当NameNode挂掉的时候，它并不

能马上替换NameNode并提供服务。

​ （1）辅助NameNode，分担其工作量，比如定期合并Fsimage和Edits，并推送给NameNode ；

​ （2）在紧急情况下，可辅助恢复NameNode。

3. 文件块大小

思考：为什么块的大小不能设置太小，也不能设置太大？

（1）HDFS的块设置太小，会增加寻址时间，程序一直在找块的开始位置；

（2）如果块设置的太大，从磁盘传输数据的时间会明显大于定位这个块开

始位置所需的时间。导致程序在处理这块数据时，会非常慢。

总结： HDFS块的大小设置主要取决于磁盘传输速率。

4. 数据流（向Node里读写数据）

5. 节点距离和副本存储策略

节点距离：两个节点到达最近的共同祖先的距离总和。

每个集群有若干个机架，每个机架有若干个节点

第一个副本在Client所处的节点上。如果客户端在集群外，随机选一个。

第二个副本和第一个副本位于相同机架，随机节点。

第三个副本位于不同机架，随机节点。

6. NameNode和DataNode工作机制

以上主要是对尚硅谷的课件整理

7. HA高可用性

HDFS HA

HDFS HA 功能通过配置 Active/Stand-by 两个 NameNodes 实现在集群中对 NameNode 的

热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方

式将 NameNode 很快的切换到另外一台机器。

工作机制：通过双 NameNode 消除单点故障

工作要点：

1. 元数据管理方式发生改变

   • 内存中各自保存一份元数据
   • edit日志只有active状态的namenode可以做写操作
   • 两个namenode都可以读edit
   • 共享的edit放在一个共享存储中管理

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

   实现了一个 zkfailover，常驻在每一个 namenode 所在的节点，每一个 zkfailover 负责监

控自己所在 NameNode 节点，利用 zk 进行状态标识，当需要进行状态切换时，由 zk failover

来负责切换，切换时需要防止 brain split 现象的发生。

brain split 现象：脑裂现象，两个节点都以为自己是active状态，发生资源争夺

3. 需要保证两个NameNode之间能够ssh无密码登陆
4. 隔离，同一时刻仅有一个NameNode对外提供服务

自动故障转移工作机制

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

**1）故障检测：**集群中的每个 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 状态。

yarn-HA

RM (ResourceManager)负责跟踪集群中的资源，调度应用程序(如MapReduce任务)。在Hadoop 2.4之前，ResourceManager是YARN集群中的单点故障。高可用性以主备ResourceManager对的形式增加冗余，消除了这种单点故障。

RM故障转移

ResourceManager HA是通过主备架构实现的——在任何时间点，一个RMs是主用的，一个或多个RMs处于备用模式，当主用的RMs发生任何事情时，等待接管。当启用自动故障转移时，从管理员(通过CLI)或通过集成故障转移控制器触发转换到活动。

自动故障转移

RMs可以选择嵌入基于zookeeper的ActiveStandbyElector来决定哪个RM应该是active的。当处于active的RM关闭或失去响应时，另一个RM会自动被选为active，然后由它接管。

注意，不需要像HDFS那样运行一个单独的ZKFC守护进程。

因为嵌入在RMs中的ActiveStandbyElector充当故障检测器和leader elector，而不需要单独的ZKFC守护进程

RM故障转移上的Client、ApplicationMaster和NodeManager

当有多个RMs时，客户端和节点使用的配置(yarn-site.xml)将列出所有的RMs。Client、ApplicationMasters (AMs)和nodemanager (NMs)尝试以循环方式连接到RM，直到它们遇到active RM。如果active的RM活动停止，它们将恢复轮询，直到它们点击“新的”active RM为止。

恢复之前活动的RM状态（懒得看了）

启用ResourceManger重启后，被提升为活动状态的RM加载RM内部状态，并根据RM重启特性尽可能从上一个活动离开的地方继续操作。
对于以前提交给RM的每个托管应用程序，都会产生一个新的尝试。
应用程序可以定期检查，以避免丢失任何工作。
状态存储必须在两个主/备RMs中都可见。
目前，持久性有两种RMStateStore实现——FileSystemRMStateStore和ZKRMStateStore。
ZKRMStateStore隐式地允许在任何时间点对单个RM进行写访问，因此推荐在HA集群中使用该存储。
在使用ZKRMStateStore时，不需要单独的防御机制来解决可能出现的脑裂情况，即多个RMs可能扮演主动角色。
当使用ZKRMStateStore时，建议不要设置zookeeper.DigestAuthenticationProvider。
superDigest”属性，以确保Zookeeper管理员没有访问YARN应用程序/用户凭据信息的权限。

参考

http://hadoop.apache.org/docs/r2.7.2/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html