HDFS高可用完全分布式

HDFS高可用完全分布式存储，在完全分布式基础上增加了

1. 使用standbyNameNode代替SecondaryNameNode
2. ZooKeeper集群和 Zookeeper Failover Controller
3. journalnode

各个角色的功能

一、"standby"NameNode

在完全分布式和伪分布式的HDFS模式中，都有一个SecondaryNameNode角色，它只是协助NameNode工作，并不是NameNode的备份，不具备NameNode的所用功能，不能对外服务。当NameNode宕机了，这个集群群机无首，无法对外服务了。为了提高这个集群的可用性，就出现了"standby"NameNode，它的本质就是NameNode，状态是"standby"。它不仅要替"active"状态NameNode做持久化工作，还得在其宕机之后，接替其向外提供服务

二、Zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者。主要负责的工作是监控和选举NameNode

1.监控

实际上，ZooKeeper并不能直接去监控NameNode，NameNode也不可能花费资源去向ZooKeeper汇报工作。于是监控的任务就交由给Zookeeper Failover Controller控制类(zkfc)，zkfc负责监控NameNode的健康状态并向Zookeeper汇报

2.选举

触发可能：

1. 监控状态为"active"的NameNode的zkfc发现它监控的NameNode宕机了，它会向Zookeeper汇报
2. 监控状态为"active"的NameNode的zkfc它自己挂掉了，Zookeeper接收不到它的信息，这是Zookeeper会认为其监控的NameNode挂掉了

出现以上情况其一，Zookeeper就会选举出一个NameNode节点，并通知监控它的zkfc，将它的状态由"standby"调至"active"，然后检查之前为"active"状态的NameNode，确认它是否宕机，如果没有宕机就将它的状态由"active"调至"standby"

3.角色

[root@node02 ~]# zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /opt/software/zookeeper-3.4.10/bin/../conf/zoo.cfg
Mode: follower

在装有 ZooKeeper 的机器的终端执行 zkServer.sh status可以看当前节点的 ZooKeeper是什么角色（leader、follower）。
ZooKeeper默认只有leader和follower两种角色，还有一个Observer角色，具体作用不了解

三、journalnode

上面提到了"standby"NameNode会在"active"NameNode宕机之后成功上位，成为机首。但如果"active"NameNode真的宕机了，这台机器上的所有数据都暂时丢失了，"standby"NameNode该如何接替它的工作呢？这就要求NameNode之间必须保持数据的同步。active是对外服务的，会产生很多的数据，集群内一般只有一个，standby可以有多个。当active数据变动时，它不可能逐一告知standby。为了数据同步，会通过一组称作journalnode的独立进程进行相互通信。当active的数据有修改时，会写到半数以上的journalnode中。standby能读取journalnode中的变更信息，并且一直监控edits的变化。这样standby可以确保在集群出错时，命名空间状态已经完全同步了。

Q:为什么要写到半数以上的journalnode中？
A:防止集群脑裂¹ ,这里讲述到一个势力范围的概念，数据相同的节点能相互联系形成一个分区，当分区的大小小于势力范围，该分区的节点将会"自杀"。所以这个势力范围得是半数以上，假如势力范围不过半，则有可能形成网络分区，即是一部分journalnode获取了active的数据，其余的没有，他们形成两个分区同时服务，那么standby所访问的journalnode中的数据不一定为最新的，导致数据不同步

---

1. 脑裂(split-brain):指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。 ↩︎