Hadoop&Hbase 备份方案--Pacemaker&DRBD

Hadoop&Hbase 备份方案--Pacemaker&DRBD


需求


实现namenode的双机热备,保证Hadoop&Hbase的高可用性(HA)。


方案描述


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


测试环境


虚拟机5台(1G内存,40G硬盘,ubuntu操作系统,Hadoop-0.20.2,Zookeeper-3.3.2,Hbase-0.20.6)

hadoop1-virtual-machine1   10.10.11.250  主(Master)namenode

hadoop2-virtual-machine5   10.10.11.152  datanode

hadoop3-virtual-machine1   10.10.11.160  datanode

hadoop4-virtual-machine5   10.10.11.184  secondarynamenode

hadoop5-virtual-machine1   10.10.12.25   备份(Slave)namenode


测试步骤


1.部署好Hadoop,Zookeeper,Hbase集群环境和Pacemaker&DRBD环境(包括HA资源的配置),详情见部署文档。

2.启动集群,同时在备份(Slave)namenode上启动HMaster服务(Hbase本身的备份方案),存储数据。

3.关闭namenode主节点所在机器(模拟namenode主节点宕机)。

4.Slave节点自动切换成Master节点(切换时间大概在30s左右),此时集群处于不可访问状态。

5.自动切换成功后,访问测试集群,集群处于safe mode(只能读不能写)状态,之后才恢复正常使用,数据未丢失。

6.启动原Master节点(模拟namenode故障节点恢复)。该节点自动加入集群,且此时的角色由原来的Master变成了Slave,集群正常向外提供服务。

7.回到步骤2

8.关闭namenode主节点网络(模拟namenode主节点网络故障)。

9.Slave节点自动切换成Master节点(切换时间大概在30s左右),此时集群处于不可访问状态。

10.自动切换成功后,访问测试集群,集群处于safe mode(只能读不能写)状态,之后才恢复正常使用,数据未丢失。

11.启动原Master节点(模拟namenode故障节点网络恢复)。该节点自动加入集群,且此时的角色由原来的Master变成了Slave,集群正常向外提供服务。


问题及可行性分析


1. 该方案可以实现Master/Slave自动切换,同时可以保证数据的完整性,切换过程中不会有数据丢失。


2. 该方案基本可以保证服务的连续性。其实我们这里所说的双机热备对于Hadoop来说并不能算是真正的热备,因为单点故障的时候,首先Master/Slave的切换需要一段时间(大概30秒左右),这段时间hadoop不能向外提供服务,然后等namenode能迁移到备用主机上后,由于Hadoop重新构造namenode需要重新加载元数据到内存中,此时Hadoop处于safe mode(只能读不能写)状态(这一缺陷对于数据量大的集群来说尤为明显),所以在这我暂且称之为伪热备。如果实际项目中不能容忍切换过程中的时延问题,可以使用更严格意义上的热备方案-AvatarNode,这种方案相比伪热备方案可以实现故障节点的迅速切换,因为Standby Avatar的元数据和Primary Avatar的元数据是同步的,是最新状态,所以每次切换不用等待Standby Avatar重新加载元数据。但此方案涉及到代码的修改,相对于伪热备方案部署更复杂。

你可能感兴趣的:(hadoop,集群,网络,测试,ubuntu,hbase)