Hadoop2.x的安装与部署

Hadoop2-NameNode的HA模式的2种实现方式

NFS模式

Quorum Journal Node 模式

我们可以看出HA的大致架构，其设计上的考虑包括：

• 利用共享存储来在两个NN间同步edits信息。 以前的HDFS是share nothing but NN，现在NN又share storage，这样其实是转移了单点故障的位置，但中高端的存储设备内部都有各种RAID以及冗余硬件包括电源以及网卡等，比服务器的可靠性还是略有提高。通过NN内部每次元数据变动后的flush操作，加上NFS的close-to-open，数据的一致性得到了保证。社区现在也试图把元数据存储放到BookKeeper上，以去除对共享存储的依赖，Cloudera也提供了Quorum Journal Manager的实现和代码，这篇中文的blog有详尽分析：基于QJM/Qurom Journal Manager/Paxos的HDFS HA原理及代码分析

• DataNode(以下简称DN)同时向两个NN汇报块信息。 这是让Standby NN保持集群最新状态的必需步骤，不赘述。

• 用于监视和控制NN进程的FailoverController进程 显然，我们不能在NN进程内进行心跳等信息同步，最简单的原因，一次FullGC就可以让NN挂起十几分钟，所以，必须要有一个独立的短小精悍的watchdog来专门负责监控。这也是一个松耦合的设计，便于扩展或更改，目前版本里是用ZooKeeper(以下简称ZK)来做同步锁，但用户可以方便的把这个ZooKeeper FailoverController(以下简称ZKFC)替换为其他的HA方案或leader选举方案。
• 隔离(Fencing))，防止脑裂)，就是保证在任何时候只有一个主NN，包括三个方面： 共享存储fencing，确保只有一个NN可以写入edits。 客户端fencing，确保只有一个NN可以响应客户端的请求。 DataNode fencing，确保只有一个NN可以向DN下发命令，譬如删除块，复制块，等等。

Hadoop2-NameNode的Federation模式实现方式

这个图过于简明，许多设计上的考虑并不那么直观，我们稍微总结一下

• 多个NN共用一个集群里DN上的存储资源，每个NN都可以单独对外提供服务

• 每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储

• DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况
• 如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录

这样设计的好处大致有：

• 改动最小，向前兼容
  1. 现有的NN无需任何配置改动.
  2. 如果现有的客户端只连某台NN的话，代码和配置也无需改动。
• 分离命名空间管理和块存储管理
  1. 提供良好扩展性的同时允许其他文件系统或应用直接使用块存储池
  2. 统一的块存储管理保证了资源利用率
  3. 可以只通过防火墙配置达到一定的文件访问隔离，而无需使用复杂的Kerberos认证
• 客户端挂载表
  1. 通过路径自动对应NN
  2. 使Federation的配置改动对应用透明

复杂完整的Hadoop2的部署模式