Hadoop中NameNode单点故障解决方案
Hadoop 1.0内核主要由两个分支组成:MapReduce和HDFS,这两个系统的设计缺陷是单点故障,即MR的JobTracker和HDFS的NameNode两个核心服务均存在单点问题,这里只讨论HDFS的NameNode单点故障的解决方案。
需求:
实现namenode元数据的备份,解决namenode单点宕机导致集群不可用的问题。
方案描述:
当namenode所在服务器宕机的时候,我们可以利用namenode备份的元数据迅速重构新的namenode来投入使用。
1.Hadoop本身提供了可利用secondarynamenode的备份数据来恢复namenode的元数据的方案,但因为checkpoint(在每次 checkpoint的时候secondarynamenode才会合并并同步namenode的数据)的问题,secondarynamenode的备份数据并不能时刻保持与namenode同步,也就是说在namenode宕机的时候secondarynamenode可能会丢失一段时间的数据,这段 时间取决于checkpoint的周期。我们可以减小checkpoint的周期来减少数据的丢失量,但由于每次checkpoint很耗性能,而且这种方案也不能从根本上解决数据丢失的问题。所以如果需求上不允许这种数据的丢失,这种方案可直接不予考虑。
2.Hadoop提供的另一种方案就是NFS,一种即时备份namenode元数据的方案,设置多个data目录(包括NFS目录),让namenode在持 久化元数据的时候同时写入多个目录,这种方案较第一种方案的优势是能避免数据的丢失(这里我们暂时不讨论NFS本身会丢失数据的可能性,毕竟这种几率很小 很小)。既然可以解决数据丢失的问题,说明这套方案在原理上是可行的
[问题]
HDFS仿照google GFS实现的分布式存储系统,由NameNode和DataNode两种服务组成,其中NameNode是存储了元数据信息(fsimage)和操作日志(edits),由于它是唯一的,其可用性直接决定了整个存储系统的可用性。因为客户端对HDFS的读、写操作之前都要访问name node服务器,客户端只有从name node获取元数据之后才能继续进行读、写。一旦NameNode出现故障,将影响整个存储系统的使用。
[解决方案]
Hadoop官方提供了一种quorum journal manager来实现高可用,在高可用配置下,edit log不再存放在名称节点,而是存放在一个共享存储的地方,这个共享存储由若干Journal Node组成,一般是3个节点(JN小集群), 每个JN专门用于存放来自NN的编辑日志,编辑日志由活跃状态的名称节点写入。
要有2个NN节点,二者之中只能有一个处于活跃状态(active),另一个是待命状态(standby),只有active节点才能对外提供读写HDFS服务,也只有active态的NN才能向JN写入编辑日志;standby的名称节点只负责从JN小集群中的JN节点拷贝数据到本地存放。另外,各个DATA NODE也要同时向两个NameNode节点报告状态(心跳信息、块信息)。
一主一从的2个NameNode节点同时和3个JN构成的组保持通信,活跃的NameNode节点负责往JN集群写入编辑日志,待命的NN节点负责观察JN组中的编辑日志,并且把日志拉取到待命节点(接管Secondary NameNode的工作)。再加上两节点各自的fsimage镜像文件,这样一来就能确保两个NN的元数据保持同步。一旦active不可用,standby继续对外提供服。架构分为手动模式和自动模式,其中手动模式是指由管理员通过命令进行主备切换,这通常在服务升级时有用,自动模式可降低运维成本,但存在潜在危险。这两种模式下的架构如下。
[手动模式]
模拟流程:
1. 准备3台服务器分别用于运行JournalNode进程(也可以运行在date node服务器上),准备2台namenode服务器用于运行NameNode进程(两台配置 要一样),DataNode节点数量不限。
2. 分别启动3台JN服务器上的JournalNode进程,分别在date node服务器启动DataNode进程。
3. 需要同步2台name node之间的元数据。具体做法:从第一台NN拷贝元数据到放到另一台NN,然后启动第一台的NameNode进程,再到另一台名称节点上做standby引导。
4. 把第一台名节点的edit日志初始化到JN节点,以供standby节点到JN节点拉取数据。
5. 启动standby状态的NameNode节点,这样就能同步fsimage文件。
6. 模拟故障,手动把active状态的NN故障,转移到另一台NameNode。
[自动模式]
模拟流程:
在手动模式下引入了ZKFC(DFSZKFailoverController)和zookeeper集群
ZKFC主要负责: 健康监控、session管理、leader选举
zookeeper集群主要负责:服务同步
1-6步同手动模式
7. 准备3台主机安装zookeeper,3台主机形成一个小的zookeeper集群.
8. 启动ZK集群每个节点上的QuorumPeerMain进程
9. 登录其中一台NN, 在ZK中初始化HA状态
10. 模拟故障:停掉活跃的NameNode进程,提前配置的zookeeper会把standby节点自动变为active,继续提供服务。
脑裂
脑裂是指在主备切换时,由于切换不彻底或其他原因,导致客户端和Slave误以为出现两个active master,最终使得整个集群处于混乱状态。解决脑裂问题,通常采用隔离(Fencing)机制。
共享存储fencing:确保只有一个Master往共享存储中写数据,使用QJM实现fencing。
Qurom Journal Manager,基于Paxos(基于消息传递的一致性算法),Paxos算法是解决分布式环境中如何就某个值达成一致。
[原理]
a. 初始化后,Active把editlog日志写到JN上,每个editlog有一个编号,每次写editlog只要其中大多数JN返回成功(过半)即认定写成功。
b. Standby定期从JN读取一批editlog,并应用到内存中的FsImage中。
c. NameNode每次写Editlog都需要传递一个编号Epoch给JN,JN会对比Epoch,如果比自己保存的Epoch大或相同,则可以写,JN更新自己的Epoch到最新,否则拒绝操作。在切换时,Standby转换为Active时,会把Epoch+1,这样就防止即使之前的NameNode向JN写日志,也会失败。
客户端fencing:确保只有一个Master可以响应客户端的请求。
[原理]
在RPC层封装了一层,通过FailoverProxyProvider以重试的方式连接NN。通过若干次连接一个NN失败后尝试连接新的NN,对客户端的影响是重试的时候增加一定的延迟。客户端可以设置重试此时和时间
Slave fencing:确保只有一个Master可以向Slave下发命令。
[原理]
a. 每个NN改变状态的时候,向DN发送自己的状态和一个序列号。
b. DN在运行过程中维护此序列号,当failover时,新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回是认为该NN为新的active。
b. 如果这时原来的active(比如GC)恢复,返回给DN的心跳信息包含active状态和原来的序列号,这时DN就会拒绝这个NN的命令。