HDFS-HA模式概念

什么是HDFS-HA？

见名思义，HDFS-HA就是HDFS的高可用模式，其中HA的全称为High Avaliable，是为了解决单台NameNode所带来的单点故障问题而提出的机制。HDFS-HA功能通过配置Active/Standby两个nameNodes(2.0支持一主一备，3.0最多支持一主五备)实现在集群中对NameNode的热备份来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode很快的切换到另外一台机器。

为什么要提出HDFS-HA机制？

这个问题要从NameNode的单点产生的问题来解释。单点NameNode会带来以下两个问题：

• 单点故障，整个集群就会陷入瘫痪：如NameNode宕机、网络连接失败、以及内存溢出等情况都可能导致单点故障。而所有HDFS的读写流程第一步都要先去访问NameNode上的元数据，NameNode一挂，HDFS就挂了。
• 内存受限，压力过大：首先说一下什么是内存受限，NameNode的元数据是存储在内存中的，那么内存的大小就决定了NameNode所能存储的元数据的量的大小，假设我们有一个很大的集群，但是NameNode内存只有一小块，当NameNode存储的元数据到达了内存上限时，便不能再往DataNode里存储数据了，而此时集群的DataNode中还有大量的存储空间，这样就导致因为NameNode的内存受限而限制了HDFS的存储性能。其次解释一下压力过大，在大规模集群中，如果只有一台NameNode，那么所有的客户端进行读写操作时，都会与NameNode进行连接，以及数据包的请求、校验给NameNode带来了很大的压力，此时一台单点的NameNode的性能就会成为整个集群的瓶颈。

可能出现的问题及解决方案

如何保证两台NameNode元数据的同步？

我们期望在集群中，一台NameNode挂掉之后，另一台NameNode可以立刻对外提供服务，这个时候我们就要求另外一台NameNode能获取到与主NameNode节点一样的元数据，在NameNode当中，元数据按照来源可以分成两类，一类是client产生的信息，如mkdir /a这样的文件操作数据，另一类是由DataNode提交的Block信息，那么如何保证两台NameNode的元数据一致性呢？

• 可能的解决方案

1. 当一个client向主NameNode发送请求时，NameNode使用同步阻塞的机制将该请求发送给Standby NameNode，即只有2台NameNode都接收到该请求后，才返回请求成功，这样就保证了数据的强一致性，但是这样会破坏client的可用性(参考CAP理论)。
2. 引入一个消息中间件，当NameNode接收到来自client的请求后，将该请求更新到消息中间件中，消息中间件更新完成后返回成功消息，主NameNode接收到来自消息中间件的成功消息后，返回给client操作成功的消息。那么这个消息中间件又是什么呢？就是JournalNode。

• Journal Node：HDFS-HA引入了Journal Node(>3台)来作为消息中间件，Journal Node是一个有主从机制的消息中间件，一开始是无主状态，在JournalNode启动时会选举出主JournalNode，选举策略默认是选举ID最大的JournalNode作为主节点。NameNode与主JournalNode通信，将请求写入JournalNode，然后由主JournalNode将请求更新到其他节点，为保证更新的请求为最新，JournalNode采用了Paxos算法(与Zookeeper类似)，简单来说，就是当集群中超过一半的节点都更新完这条请求，就认为这条请求写入成功。这样就保证了Standby NameNode访问JournalNode时，可以访问到最新的元数据并进行同步。
  

使用ZKFC实现自动切换Active NameNode

上面的方法基本解决了数据一致性的问题，但是需要手动去切换NameNode，所以HDFS-HA引入了ZKFC来实现自动切换Active NameNode。在Active NameNode和Standby NameNode所在的物理机中，都会有一个叫FailoverController的进程，那么它是如何实现Active NameNode的切换的呢？
ps:为什么要把FailoverController和NameNode放到一台物理机上呢？因为如果放到不同的物理机，那么它们沟通就需要通过网络传输来进行，就会产生很多的不可靠性，加大了监控的风险。

ZKFC的功能

• 监控NameNode:监控NameNode的存活状态、操作系统和硬件信息。
• 连接Zookeeper并创建Active NameNode：Zookeeper中有目录树，当所有NameNode 和 ZKFC启动时，ZKFC首先向Zookeeper申请一个创建锁，谁拿到了创建锁，谁就能创建一个临时子节点，这意味着2个ZKFC只有一个能创建子节点，这个被ZKFC创建成功的子节点中包含的就是Active NameNode。
• 降级Active NameNode，升级Standby NameNode：假设Active NameNode存活但是ZKFC进程异常退出，这时候就会触发此机制，Zookeeper的临时子节点会被删除，然后触发callback机制，第二个ZKFC就会抢到创建锁，并自己将Active NameNode降级成Standby NameNode，升级Standby NameNode为Active NameNode。

Active NameNode切换过程

1. 首先，ZKFC在Zookeeper中创建的节点是一个临时节点，当ZKFC和Zookeeper保持连接时，节点会一直存在，一旦连接断开，节点就会被删除，节点删除会触发回调(callback)，当所有NameNode 和 ZKFC启动时，ZKFC首先向Zookeeper申请一个创建锁，谁拿到了创建锁，谁就能创建一个临时子节点，这意味着2个ZKFC只有一个能创建子节点，这个被ZKFC创建成功的子节点中包含的就是Active NameNode。
2. 此时若Active NameNode挂了，这时候第一个ZKFC将Active NameNode降级成Standby NameNode并将Zookeeper的临时子节点删除，然后触发callback机制，第二个ZKFC就会抢到创建锁，并去查看Active NameNode是否真的挂了，如果挂了，就升级Standby NameNode为Active NameNode。
3. 若Active NameNode还存活，但是当前Active NameNode主机的ZKFC挂了，Zookeeper的临时子节点会被删除，然后触发callback机制，第二个ZKFC就会抢到创建锁，并自己将Active NameNode降级成Standby NameNode，升级Standby NameNode为Active NameNode。
4. 极端现象：Active NameNode和ZKFC都没有问题，并且Active NameNode也能和DataNode通信，但是ZKFC和Zookeeper不能通信，且第二个ZKFC也不能访问Active NameNode来判断Active NameNode是否真的挂了，所以也不会把自己监控的NameNode升级为Active NameNode。此时Zookeeper的子节点被删除，又不能创建新节点，导致程序出错。这种情况出现的概率极其低，所以解决办法也较极端，一种办法是遇到此情况时触发一种机制将当前的Active NameNode的电源切断。