Hadoop&Hbase 备份方案--AvatarNode

Hadoop&Hbase 备份方案

--AvatarNode

 

需求

实现namenode的双机热备，保证Hadoop&Hbase的高可用性（HA）。

 

方案描述

当主namenode所在服务器宕机的时候，其服务和数据可迅速，完整，无缝的迁移到备份namenode从而保证hadoop集群的高可用性，持续的向外提供服务。

 

测试环境

虚拟机5台（1G内存，40G硬盘，ubuntu操作系统，Hadoop-0.20.2）

hadoop1-virtual-machine1   10.10.11.250  AvatarNode(Primary)

hadoop2-virtual-machine5   10.10.11.152 AvatarDataNode

hadoop3-virtual-machine1   10.10.11.160  AvatarDataNode

hadoop4-virtual-machine5   10.10.11.184   AvatarDataNode

hadoop5-virtual-machine1   10.10.12.25   AvatarNode(Standby)

 

测试步骤

1．部署好Hadoop(AvatarNode部署详情见部署文档)集群环境，。

2．启动集群，此时AvatarNode(Primary)正常向外提供服务，AvatarNode(Standby)处于safemode状态，只可读，不可写。

3．存储数据，集群正常使用。

4．Kill掉AvatarNode(Primary)线程（模拟Primary节点宕机）。

5．升级AvatarNode(Standby)为Primary（切换时间很短只需几秒）。

6．集群正常服务，数据未丢失。

 

问题及可行性分析

 

1.   该方案可以实现AvatarNode(Primary)故障时与AvatarNode(Standby)的迅速切换，同时可以保证数据的完整性，切换过程中不会有数据丢失，称得上为真正意义上的热备。

2.     该方案虽然可以实现AvatarNode(Primary)与AvatarNode(Standby)的快速切换，但目前还不支持自动切换，可以借助于zookeeper的lease机制实现。同时由于Primary与Standby的转换只能是由Standby转换成Primary，并不支持由Primary降级为Standby，所以暂时不支持二次故障。也就是说由Standby升级为Primary的节点发生故障时，不支持切换。

3.     该方案必须借助于NFS实现AvatarNode(Primary)与AvatarNode(Standby)之间事务日志的共享，故存在NFS故障的问题。

4.     该方案AvatarDataNode并不使用VIP和AvatarNode通信，而是直接与Primary及Standby通信，故需要使用VIP漂移方案来屏蔽两个节点间切换过程中的IP变换问题，挂载Hbase时更需如此。