HDFS NameNode HA框架设计文档(HDFS-1623:High Availability Framework for HDFS NN)
openkk
12年前
原文请参
译文如下:
</div> 1 Problem Statement
2 Terminology有很多方式可以使得NN更加的Available,例如:减少启动时间,配置热刷选,减少升级时间,NN的手动或自动的Failover。本文档通过Failover来解决NN的SPOF问题有很多种方式可以提供NN的Failover,例如Shared-Storage,IP-Failover,smart-client,Zookeeper,linxu-ha。这些不同的方式作为HA框架的构建积木,本文定义了各个积木块及其实现。
ActiveNN 提供读写服务的NNStandbyNN 等待成为ActiveNN的NN,0.21中的BackupNode可以用来实现为Standby为了避免混淆,PrimaryNN和SecondaryNN将不会在这里使用。Hot, Warm, Cold failover这三个Failover,依赖于StandbyNN中存储的ActiveNN运行时状态决定:
</blockquote> 3 High Level Use CasesCold Standby: StandbyNN不存储任何状态,在ActiveNN失效后它才开始启动Warm Standby: StandbyNN具有部分状态,包括Fsimage,Editlogs,但没有Blockreport信息。或者含有Fsimage和rolled logs以及BlockreportsHot Standby: StandbyNN具有几乎所有的ActiveNN的状态,能够立即启动4 Out of scopePlanned Downtime:Hadoop经常需要升级软件和更新配置而重启集群。在一个4000个节点的集群大概需要2个小时来重启,在release23内,大概需要半个小时UnplannedDowntime:NN的Failover可能由于硬件,OS,NN自身等各种原因。由于不确定性,导致NN在某些领域很难达到SLA的要求这两者都可以通过warm/hot的Failover来减少宕机时间。实践表明,有计划的升级是hdfs的宕机最大的原因。Active-ActiveNN 这种模式太难搞了,这个设计真值讨论Acitve-StandbyNN的模式More-than-2 NN 现在只讨论一个namespace,最多两个NN的情况Cross-cole Failover或者称为BCP5 Failures Supported支持一个HW失效如disk,nic,links等等,多重失效不会处理,仅仅保证数据不会丢失软件失效如NN及NN的lockup都会支持,但是同样的错误在StandbyNN变成ActiveNN时再次发生,可能不会处理好NN的GC是一个比较郁闷的问题,GC的时候可能会是的ActiveNN被认为是dead的6 Requirements1、只有一个NN是Active的并且 只有这个ActiveNN能提供服务,改变namespace。以后可以考虑让StandbyNN提供读服务2、提供手动Failover,在升级过程中,Failover在NN-DN之间写一部不变的情况下才能生效3、在之前的NN重新恢复之后,不能提供failback4、数据一致性比Failover更重要5、尽量少用特殊的硬件6、HA的设置和Failover都应该保证在两者操作错误或者配置错误的时候,不得导致数据损坏7、NN的短期GC不应该触发Failover7 Detailed Use Cases1、单一NN的配置,没有Failover2、Active-Standby配置手动Failover,Standby可以是cold/warm/hot3、Active-Standby配置自动Failover:</blockquote>1、两个NN启动,一个自动成为ActiveNN,一个为Standby2、Active失效或者状态未知,Standby接管并成为ActiveNN
3、Active和Standby度运行的情况,Standby失效,Active不受影响4、 Standby没启动且 Active失效不能启动时候,Standby应该可以启动成为ActiveNN。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就是这样),以下是一些考虑点:8、2 Parallel Block reports to Active & Standby1、shared-storage的 server就是一个spof,也需要能够做到HA。bookkeeper是一个好的解决方案,但是目前仍不成熟。使用bookkeeper,NN不需要 将状态保存到本地disk就可让NN完全"stateless"。有些实现已经将NFS作为方案实现了2、BackupNode可以不要使用shared-storage,但是不支持usecase3.43、只要shared-storage不用在BackupNode的方式去解决usecase3.4,那么BackupNode不需要去做fencing,shared-store必须要考虑fencing,如果用STONITH,那么所有的fencing问题都解决了4、BackupNode只有在full-sync的情况下才能接管变成ActiveNN5、但是当BackupNode宕机了,还需要使用外部的存储设备来获取ActiveNN的状态,这又会到了shared-storage的情况
本设计中,DN要么同时向Active&Standby都发送Blockreport,通过一个中间层来完成将Blockreport变成两个分支发现Active&Standby
8、3 Client redirection after failover
当ActiveNN失效时,client需要重连到新的ActiveNN,这也称为client-Failover,一般通过以下方式来完成:</blockquote>1、修改DNS绑定:但是很多os,lib库,都会缓存DNS。</blockquote>
2、Smart-Client:和server-based重定向一起,通过重试或者re-lookup到ActiveNN,但需要考虑:1、注意:使用server-based重定向时,如果发生split-brain,两个server都不会做重定向。所以在任何shared-storage情况下必须要有一个很好的fencing机制确保只有一个server在写editlog3、使用in-band负载均衡去通知client定位到正确的NN,但是client太多了就很难扩展了
2、能够和http以及JMX很好的协作否?
3、Failover时间拉长,因为Client必须要和第一个NN(可能死了)联系,才能去重新获取新的NN
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作为 FailoverControllerFailoverController主要完成以下功能:监控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需要考虑fencing1、当使用share-storage来存储NN的metadata的时候,必须确保只有一个ActiveNN来写入editlog2、Datanodes:必须确保只有一个NN能够发布delete操作来管理replica3、 Clients:clients虽然不会受限制于一个被NN写入的share-storage的设备,但是当client发送数据更新到两个NN的时候, 必须要确保只有一个NN来响应这个请求。当NN端已经通过share-storage来fencing时,那么就只有一个NN能够正确的响应到 client</blockquote>8、7 Other failover issuesFailover过程中的lease Recovery-TBDFailover过程中的pipeline Recovery9 Detailed Design9、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></blockquote> </blockquote>1、WITH-NFS:fencing解决方案需要被调查2、WITH-BOOKKEEPER:当前正和bookkeeper的开发者商量开发fencing的事情3、WITH-Share-Disk(scsi/san):这些设备都有内置的fencing,但不一定在Hadoop的环境下合适</blockquote>9、1、2 Fencing DataNodes两个解决方案:Solution 1:在heartbeat的响应中,NN表名自己的状态是Active/Standby。</blockquote> </blockquote>Solution 2: </blockquote> </blockquote>如果DN发现了状态更改,再次检查zk中去发现ActiveNN如果Active从A->B->A,那么DN将无法检查到,可以通过FailoverController来通知DN,但是DN太多了,所以必须要将这个机制内建在协议中。每个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 SolutionStonith经常是一个比较粗鲁的fencing的一个解决方案,当没有其他fencing解决方案的时候,Stonith一般通过控制电源来关闭节点。9、2 Leader Election and FailoverController Deamon上面已经说了独立的 FailoverController的优点了,另外,LinuxHA中的ResourceManager已经可以作为 FailoverController来使用了。所以,如果采用LinuxHA方案时,直接用ResourceManager来作为 FailoverController,采用zk时候,可以自己写一个类似的FailoverController,或者利用LinuxHA的 ResourceManager作为妨碍了,zk作为Leader Elector</blockquote>9、2、1 FailoverController Daemon‘s Operatuions:Heartbeat:确保ActiveNN的监控状况,一旦丢失,立即初始化一个LeaderElectionHealthMonitor: </blockquote> </blockquote>For ZK:FailoverController定期向ZK发送HeartbeatFor LinuxHA:ResourceManager向Standby发送Heartbeats查看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></blockquote> </blockquote>更新client的地址或者放弃VIP通知ActiveNN要么转换为Standby,要么退出,如果不响应,则kill掉9、3 NN Startup and Active-Standby State Changes在NN启动时,首先进入到Standby,只有FailoverController通知变成Active的情况下,才回变成Active9、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. TBD9、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转自:http://blog.csdn.net/chenpingbupt10.1 Automatic FailbackExplain the problem and how it can occur10.2 AmnesiaLoss of state that was already communicated to clients – can occur if fencing is poor or if and older state is read by Standby.Explain details10.3 GCHow do we differential from NN that does not response when it hung versus one that is in short GC phase?Investigate