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重新加载元数据。但此方案涉及到代码的修改，相对于伪热备方案部署更复杂。