有很多方式可以使得NN更加的Available，例如：减少启动时间，配置热刷选，减少升级时间，NN的手动或自动的Failover。本文档通过Failover来解决NN的SPOF问题

有很多种方式可以提供NN的Failover，例如Shared-Storage，IP-Failover，smart-client，Zookeeper，linxu-ha。这些不同的方式作为HA框架的构建积木，本文定义了各个积木块及其实现。

ActiveNN     提供读写服务的NN

StandbyNN     等待成为ActiveNN的NN，0.21中的BackupNode可以用来实现为Standby

为了避免混淆，PrimaryNN和SecondaryNN将不会在这里使用。

Hot, Warm, Cold failover这三个Failover，依赖于StandbyNN中存储的ActiveNN运行时状态决定：

Cold Standby:      StandbyNN不存储任何状态，在ActiveNN失效后它才开始启动

Warm Standby:   StandbyNN具有部分状态，包括Fsimage，Editlogs，但没有Blockreport信息。或者含有Fsimage和rolled logs以及Blockreports

Hot Standby:        StandbyNN具有几乎所有的ActiveNN的状态，能够立即启动

</blockquote> 3     High Level Use Cases

Planned Downtime：Hadoop经常需要升级软件和更新配置而重启集群。在一个4000个节点的集群大概需要2个小时来重启，在release23内，大概需要半个小时

UnplannedDowntime：NN的Failover可能由于硬件，OS，NN自身等各种原因。由于不确定性，导致NN在某些领域很难达到SLA的要求

这两者都可以通过warm/hot的Failover来减少宕机时间。实践表明，有计划的升级是hdfs的宕机最大的原因。

4     Out of scope

Active-ActiveNN     这种模式太难搞了，这个设计真值讨论Acitve-StandbyNN的模式

More-than-2 NN     现在只讨论一个namespace，最多两个NN的情况

Cross-cole Failover或者称为BCP

5     Failures Supported

支持一个HW失效如disk，nic，links等等，多重失效不会处理，仅仅保证数据不会丢失

软件失效如NN及NN的lockup都会支持，但是同样的错误在StandbyNN变成ActiveNN时再次发生，可能不会处理好

NN的GC是一个比较郁闷的问题，GC的时候可能会是的ActiveNN被认为是dead的

6     Requirements

1、只有一个NN是Active的并且 只有这个ActiveNN能提供服务，改变namespace。以后可以考虑让StandbyNN提供读服务

2、提供手动Failover，在升级过程中，Failover在NN-DN之间写一部不变的情况下才能生效

3、在之前的NN重新恢复之后，不能提供failback

4、数据一致性比Failover更重要

5、尽量少用特殊的硬件

6、HA的设置和Failover都应该保证在两者操作错误或者配置错误的时候，不得导致数据损坏

7、NN的短期GC不应该触发Failover

7     Detailed Use Cases

1、单一NN的配置，没有Failover

2、Active-Standby配置手动Failover，Standby可以是cold/warm/hot

3、Active-Standby配置自动Failover：

1、两个NN启动，一个自动成为ActiveNN，一个为Standby

2、Active失效或者状态未知，Standby接管并成为ActiveNN

3、Active和Standby度运行的情况，Standby失效，Active不受影响

4、 Standby没启动且 Active失效不能启动时候，Standby应该可以启动成为ActiveNN。

</blockquote>

8     Design Considerations

以下是几个设计方案，有几个模块都有几 种方案供选择，如：是否启动Storage来存储NN的状态？如何进行leader election(Zookeeper/LinuxHA/其他)？如何实现fencing？其他部分基本一致。以下两个图分别描述Zookeeper和 LinuxHA来做shared-storage的情况，这个设计也可扩展到BackupNode

8、1     shared storage vs shared nothing storage for NN metadata

在Active和Standby之间，可以选择采用share-storage(NFS)或选择ActvieStream将edits导向StandbyNode(release21之后的BackupNode就是这样)，以下是一些考虑点：

1、shared-storage的 server就是一个spof，也需要能够做到HA。bookkeeper是一个好的解决方案，但是目前仍不成熟。使用bookkeeper，NN不需要 将状态保存到本地disk就可让NN完全"stateless"。有些实现已经将NFS作为方案实现了

2、BackupNode可以不要使用shared-storage，但是不支持usecase3.4

3、只要shared-storage不用在BackupNode的方式去解决usecase3.4，那么BackupNode不需要去做fencing，shared-store必须要考虑fencing，如果用STONITH，那么所有的fencing问题都解决了

4、BackupNode只有在full-sync的情况下才能接管变成ActiveNN

5、但是当BackupNode宕机了，还需要使用外部的存储设备来获取ActiveNN的状态，这又会到了shared-storage的情况

8、2      Parallel Block reports to Active & Standby
本设计中，DN要么同时向Active&Standby都发送Blockreport，通过一个中间层来完成将Blockreport变成两个分支发现Active&Standby
8、3      Client redirection after failover

当ActiveNN失效时，client需要重连到新的ActiveNN，这也称为client-Failover，一般通过以下方式来完成：

</blockquote>

1、修改DNS绑定：但是很多os，lib库，都会缓存DNS。

2、Smart-Client：和server-based重定向一起，通过重试或者re-lookup到ActiveNN，但需要考虑：

</blockquote>

1、注意：使用server-based重定向时，如果发生split-brain，两个server都不会做重定向。所以在任何shared-storage情况下必须要有一个很好的fencing机制确保只有一个server在写editlog
2、能够和http以及JMX很好的协作否？

3、Failover时间拉长，因为Client必须要和第一个NN（可能死了）联系，才能去重新获取新的NN

3、使用in-band负载均衡去通知client定位到正确的NN，但是client太多了就很难扩展了
4、IP-Failover，这是业界最常用的方式之一，通过vip的方式提供服务，vip的地址由ActiveNN来提供，在跨机架的情况需要使用VLAN来支持 </blockquote> 8、4      Client time‐out during NN startup </blockquote>

NN在需要一个相当长 的时间来进行start，load-fsimage，apply-eidts，接受Blockreport之后才提供服务。这也使得client以为NN 已经死了。因此，在ActiveNN启动时，应该向client响应一个"Startingup"的信息叫client进行wait。

8、5      Failover control outside NN using FailoverController(Watchdog)

FailoverController 被设计在独立于NN之外，类似与LinuxHA中的ResourceManager。所以如果使用LinuxHA的话，那么 ResourceManager直接作为FailoverController，如果使用Zookeeper的话，可以自己写一个 FailoverController，或者配置LinuxHA的ResourceManager来连接到Zookeeper作为 FailoverController

FailoverController主要完成以下功能：

监控NN的状态，OS，HW，以及网络

监控heartbeat，以便参与leader选决

在leader选举中，一旦一个NN被选择了，那么其FailoverController会通知NN从Standby转向Active，NN启动的时候都是Standby的，除非FailoverController通知了NN做状态转换到Active

让FailoverController独立出来，有以下几个优点： </blockquote>

1、对FailoverController进行heartbeat的监控更好，使得不会像NN那样做GC导致heartbeat过期。

2、FailoverController的代码少，从应用中隔离，更健壮

3、使得leader election可插拔

</blockquote>

8、6     Fencing

在Failover的 过程中，必须确保只有一个Active的NN能够写入到shared状态中去。尽管有leader election，但是老的Active实例可能被隔离但不一定能迅速的切换为Standby状态，所以会继续写入到shared状态中。Fencing 通过要求ActiveNN在发生IO错误时，不要再次试图重新获取Share-State的写权限。因为Fencing设备可以在老的ActiveNN上 发起一个IO错误。因此最好是让老的ActiveNN退出，变成standby都不行。

以下几个shared-resource需要考虑fencing

1、当使用share-storage来存储NN的metadata的时候，必须确保只有一个ActiveNN来写入editlog

2、Datanodes：必须确保只有一个NN能够发布delete操作来管理replica

3、 Clients：clients虽然不会受限制于一个被NN写入的share-storage的设备，但是当client发送数据更新到两个NN的时候， 必须要确保只有一个NN来响应这个请求。当NN端已经通过share-storage来fencing时，那么就只有一个NN能够正确的响应到 client

</blockquote>

8、7     Other failover issues

Failover过程中的lease Recovery-TBD

Failover过程中的pipeline Recovery

9     Detailed Design

9、1     Fencing

上面已经描述在share-storage中，fencing是必须的，fencing之后，NN应该退出

9、1、1      Fencing Shared Storage Containing NN Metadata

</blockquote>

在hdfs-1073之后，fsimage和editlog已经解耦，所以只有editlog需要fencing。NN启动时候，永远都会打开一个新的editlog，所以需要确保老的Active不会再次写入老的edit然后和client进行交互

</blockquote>

1、WITH-NFS：fencing解决方案需要被调查

2、WITH-BOOKKEEPER：当前正和bookkeeper的开发者商量开发fencing的事情

3、WITH-Share-Disk(scsi/san)：这些设备都有内置的fencing，但不一定在Hadoop的环境下合适

</blockquote> </blockquote>

9、1、2      Fencing DataNodes

两个解决方案：

Solution 1：

</blockquote>

在heartbeat的响应中，NN表名自己的状态是Active/Standby。

</blockquote> </blockquote>

如果DN发现了状态更改，再次检查zk中去发现ActiveNN

如果Active从A->B->A，那么DN将无法检查到，可以通过FailoverController来通知DN，但是DN太多了，所以必须要将这个机制内建在协议中。

Solution 2： </blockquote> </blockquote>

每个NN都一个数字，当状态发送改变时候，增加这个数字，这个数字在register和heartbeat中都携带

DN为每个NN都保存这个数字，并且监听最近的从Standby->Active的NN

如果之前Active回来并且自称是ActiveNN的时候(例如由于长GC)，DN应该拒绝它，因为之前那个数字已经stale，另外一个新的数字已经接管为Active了。

</blockquote> </blockquote>

9、1、3     Fencing Clients

当client向NN发送update的命令的时候，只有一个ActiveNN会响应。如果NN采用shared-storage的fencing，那么non-ActiveNN也没法写入editlog，所以也无法向client发回响应

9、1、4     Stonith as a Brute-Force Fencing Solution

Stonith经常是一个比较粗鲁的fencing的一个解决方案，当没有其他fencing解决方案的时候，Stonith一般通过控制电源来关闭节点。

9、2     Leader Election and FailoverController Deamon

上面已经说了独立的 FailoverController的优点了，另外，LinuxHA中的ResourceManager已经可以作为 FailoverController来使用了。所以，如果采用LinuxHA方案时，直接用ResourceManager来作为 FailoverController，采用zk时候，可以自己写一个类似的FailoverController，或者利用LinuxHA的 ResourceManager作为妨碍了，zk作为Leader Elector

9、2、1     FailoverController Daemon‘s  Operatuions：

Heartbeat：确保ActiveNN的监控状况，一旦丢失，立即初始化一个LeaderElection

</blockquote>

For ZK：FailoverController定期向ZK发送Heartbeat

For LinuxHA：ResourceManager向Standby发送Heartbeats

HealthMonitor： </blockquote> </blockquote>

查看NNprocess的状态

简单查询NN的响应(考虑到NN的GC问题)

OS健康检查

NIC健康检查

网关健康检查（有坑）

FailoverController需要容许NN在进行Active->Standby或者Standby->Active转换时，可以进行一系列的操作，而这些操作是可配置的。如LinuxHA容许个人配置一系列的操作在它管理的资源上执行 </blockquote>

在 Standby->Active的转换过程中，以下步骤是必须的

</blockquote>

Fencing shared-storage和DNs（Stonith是最后的选择）

更新client的地址并且接管vip

通知StandbyNN变成AcitveNN

</blockquote> </blockquote>

在Active->Standby的转换过程中，以下步骤是必须的

</blockquote>

更新client的地址或者放弃VIP

通知ActiveNN要么转换为Standby，要么退出，如果不响应，则kill掉

</blockquote> </blockquote>

9、3     NN Startup and Active-Standby State Changes

在NN启动时，首先进入到Standby，只有FailoverController通知变成Active的情况下，才回变成Active

9、3、1     NN in Standby

不响应任何请求

</blockquote>

读取image，处理edits（通过disk或者socket如果是Bnn）

</blockquote>

接收BRs并处理，但是不会发送Delete&Copy命令到DN

</blockquote>

9、3、2     NN become Active

当NN变成Active的时候，过程如下：

完成最后的edit处理

</blockquote>

通知client，目前自己处理Startup模式（safemode的一个变种）

</blockquote> </blockquote>

9、4     Client Redirection

上面已经描述了两种可行的方案，设计方案需讨论

9、4、1     Smart-Client Approach

需要讨论在NN进行Failover的时，Client通过另外的service(如：zk)进行lookup ActiveNN的地址。这种方式的优缺点在哪儿？和SecurityToken会不会冲突？

9、4、2     IP Failover Approach

业界标准做法-如何工作？TBD

优点在于： 对所有协议(HDFS,HTTP,JMX,ETC)透明。

问题在于：跨机架的vip

</blockquote>

9、5     Shared Storage Approach

Standby reads rolled edits from shared storage. i.e. is out of date only wrt to the current unrolled edits  (assuming hdfs‐1073). Add details. TBD

9、6     Non-share Approach: using the backup NN

考虑usecase3.4，并且介绍BN如何工作，另外如果ActiveNN由于nic问题和BN失去联系，而将BN剔除，如果此时Failover了，那么显然BN和ActiveNN不同步

10      Appendix A: Situations that resulting in problematic behavior

10.1 Automatic Failback

Explain the problem and how it can occur

10.2 Amnesia

Loss of state that was already communicated to clients – can occur if fencing is poor or if and older state is read by Standby.Explain details

10.3 GC

How do we differential from NN that does not response when it hung versus one that is in short GC phase？Investigate

转自：http://blog.csdn.net/chenpingbupt