这是我参与更文挑战的第15天，活动详情查看: 更文挑战
背景
今天把HDFS2.0的高可用机制的相关笔记汇总一下.
HDFS的高可用机制
- 早期HDFS版本,NameNode存在单点故障隐患,比如机器crash或者NameNode上软硬件升级都会导致整个系统一段时间不可用
- HDFS 2.0中引入了HA机制,用于解决NameNode单点故障问题，该特性通过热备的方式为主NameNode提供一个备用者，一旦主NameNode出现故障，可以迅速切换至备NameNode，从而实现不间断对外提供服务
- HDFS HA提供在一个集群中配置两台NameNode(NN)来解决上述问题，并让active和passive之间热备(hot standby)
- 在HA集群中，standby namenode还会对namespace进行checkpoint操作(继承Backup Namenode的特性)，因此，就不需要在HA集群中运行SecondaryNamenode、CheckpointNode或者BackupNode。事实上，HA架构中运行上述节点，将会出错(不允许)
HA策略机制
- hadoop2.x中的fsimage和edits的合并机制和hadoop1.x完全不同。在hadoop2.x中已经没有SecondaryNamenode，而是直接通过QJM方式配置若干奇数个JournalNode来实现NameNode热备HA策略。
- 在同一个集群当中同时运行着2个Namenode，一个处于Active状态，用于处理客户端的请求。另外一个处于standy状态，用于热备，其状态和active Namenode是维持一致的，当Active Namenode出现故障，Standy Namenode可以马上转化为Active Namenode。但是 2个Namenode中有且只有一个处于active状态来处理客户端的请求，否则将会产生脑裂情况。
- 为了让Standby NameNode的状态和Active NameNode保持同步，即元数据保持一致，它们都将会和JournalNodes守护进程通信。当Active NameNode执行任何有关命名空间的修改，它至少需要将产生的edits持久化到N-((N-1)/2)个JournalNodes上才能保证命名空间修改的安全性，换句话说：如果你的HA策略中启动了N个JournalNode进程那么整个QJM最多允许(N-1)/2个进程死掉，这样才能保证editLog成功完整地被写入。比如 3个 JournalNode 时，最多允许 1 个 JournalNode挂掉，5个 JournalNode 时，最多允许 2 个 JournalNode 挂掉。而Standby NameNode负责观察edits log的变化，它能够读取从JNs中读取edits信息，并更新其内部的命名空间
- 一旦Active NameNode出现故障，Standby NameNode将会保证从JNs中读出了全部的Edits，然后切换成Active状态,Standby NameNode读取全部的edits可确保发生故障转移之前，是和Active NameNode拥有完全同步的命名空间状态
共享存储
- NameNode主从节点间需要同步操作日志来达到主从节点元数据一致。最初业界均通过NFS来实现日志同步,它可以很方便地实现数据共享,但缺点是不能满足HDFS的在线存储业务：网络单点及其存储节点单点
- 在一个典型的 HDFS HA 场景中，通常由两个NameNode 组成，一个处于Active状态，另一个处于Standby状态。Active NameNode 对外提供服务，比如处理来自客户端的 RPC 请求，而 Standby NameNode 则不对外提供服务，仅同步 Active NameNode的状态，以便能够在它失败时快速进行切换
- 为了能够实时同步Active和Standby两个NameNode的元数据信息（实际上editlog），需提供一个共享存储系统，可以是NFS、QJM（Quorum Journal Manager）或者Bookeeper，Active Namenode将数据写入共享存储系统，而Standby监听该系统，一旦发现有新数据写入，则读取这些数据，并加载到自己内存中，以保证自己内存状态与Active NameNode保持基本一致
- bookkeeper由yahoo开发，实现了读写高可用性
心跳机制
StandByNameNode是不处理DataNode的RPC请求的，那么各个DataNode为什么还会同时向Active NameNode和StandBy NameNode同时发送心跳呢？
这是因为这2个心跳的用途是不同的，各个DataNode向Active NameNode发送心跳主要是汇报数据块的状态信息，而向StandBy NameNode发心跳的主要目的是通知StandBy NameNode告诉它Active NameNode元数据发生了改变，要求StandBy NameNode去QJM区下载更改过的Edit Log信息
脑裂情景和fencing method
任何时刻,都只能有一个处于Active的NN.若两个NN都是active,即所谓脑裂情景(split-brain scenario),因此管理员必须设置一个对共享存储的fencing method(绝缘方法)，当不能确定前Active NN不会自己重新变成active时，需要切断其对共享存储的访问权限，如此便能使新active NN安全的故障恢复
JNS(Journal Nodes)
- 为了让Standby Node与Active Node保持同步，这两个Node都与一组称为JNS的互相独立的进程保持通信(Journal Nodes)。当Active Node上更新了namespace，它将记录修改日志发送给JNS的多数派。Standby noes将会从JNS中读取这些edits，并持续关注它们对日志的变更。Standby Node将日志变更应用在自己的namespace中，当failover发生时，Standby将会在提升自己为Active之前，确保能够从JNS中读取所有的edits
- 对于JNS(Journal Nodes)而言，任何时候只允许一个Namenode作为writer；在failover期间，原来的Standby Node将会接管Active的所有职能，并负责向JNS写入日志记录，这就阻止了其他Namenode基于处于Active状态的问题
