目录
HDFS 2.x 中HA与联邦
解决HDFS 1.0中单点故障和内存受限问题,联邦 HA
HDFS2.x中Federation和HA分离,HA只能有两个NameNode
解决单点故障
HDFS HA:通过主备NameNode解决
如果主NameNode发生故障,则切换到备NameNode上。
解决内存受限问题
HDFS Federation(联邦);水平扩展,支持多个NameNode;
(1)所有NameNode共享所有DataNode存储资源
(2)每个NameNode分管一部分目录;
手动HA
示意图
CAP原则
在这里要提到一个CAP原则。
CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。
一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
可用性(A):保证每个请求不管成功或者失败都有响应。
分区容忍性(P):系统中任意信息的丢失或失败不会影响系统的继续运作。
因为CAP原则,JN集群(奇数节点最佳)采用了过半机制,只需要超过半数节点收到edits log记录就行。这样的话就可以实现可用性,分区容忍性,以及最终一致性(与CAP中一致性不同)。
fsimage+edits log合并
fsimage+edits log需要由StandbyNameNode做合并工作。
fsimage推送的时机可以通过参数来调整:
dfs.namenode.checkpoint.period //1小时
dfs.namenode.checkpoint.txns //100 0000事务
dfs.namenode.checkpoint.check.period //3s
dfs.namenode.num.checkpoints.retained
dfs.ha.tail-edits.period
- 一个NameNode进程处于Active状态,另1个NameNode进程处于Standby状态。Active的NameNode负责处理客户端的请求。
- Active的NN修改了元数据之后,会在JNs的半数以上的节点上记录这个日志。Standby状态的NameNode会监视任何对JNs上edit log的更改。一旦edits log出现更改,Standby的NN就会根据edits log更改自己记录的元数据。
- 当发生故障转移时,Standby主机会确保已经读取了JNs上所有的更改来同步它本身记录的元数据,然后由Standby状态切换为Active状态。
- 为了确保在发生故障转移操作时拥有相同的数据块位置信息,DNs向所有NN发送数据块位置信息和心跳数据。
- JNs只允许一台NameNode向JNs写edits log数据,这样就能保证不会发生“脑裂”。
自动HA
总结
主备NameNode
解决单点故障(属性,位置)→元数据
主NameNode对外提供服务,备NameNode同步主NameNode元数据,以待切换
所有DataNode同时向两个NameNode汇报数据块信息(位置)
JNN:集群(属性)同步edits log
standby:备,完成了edits.log文件的合并产生新的image,推送回ANN
两种切换选择
手动切换:通过命令实现主备之间的切换,可以用HDFS升级等场合
自动切换:基于Zookeeper实现
基于Zookeeper自动切换方案
ZooKeeper Failover Controller:监控NameNode健康状态,
并向Zookeeper注册NameNode
NameNode挂掉后,ZKFC为NameNode竞争锁,获得ZKFC 锁的NameNode变为active
zookeeper的分布式锁,keepalived
围栏机制
可能因网络原因或者其他原因,NN1失去了分布式锁,NN2就会成为ANN,但NN1依然在为客户端提供服务,这样的话就会发生“脑裂”。所以NN2要成为ANN的话,必须要先检测NN1是否在为客户端提供服务,如果是的话会先 ssh node1 kill -9 结束NN1的进程,NN2会获得分布式锁,成为ANN。