方案目标

将现有NameNode迁移到新的节点上,期间保证集群对外提供服务.

方案背景

随着集群数据量和规模的扩增,需要将NameNode迁移到性能更优的机器上,以此提高NameNode的请求处理效率.

传统方案的做法比较简单,主要步骤如下:

传统方案在操作上是比较容易执行的,但是它唯一的不足之处在于需要集群对外停止服务.如果集群使用方众多,这样的做法显然不是一个最佳的方案.简单用一句话来形容这种做法:简单了自己,麻烦了他人.所以更好的做法应该是将麻烦留给自己,尽可能对外界不造成影响.

当前节点:旧nn1:active; 旧nn2:standby; 新nn1; 新nn2

1.关闭旧nn2的 namenode服务.

cd  $HADOOP_HOME/sbin/;   ./hadoop-daemon.sh stop namenode

2.将旧nn2上面的元数据目录 ${dfs.namenode.name.dir}同步到新nn1节点的同样目录下.
3.修改旧nn2上的hdfs-site.xml 配置,新nn1 ip地址加入进去.
4.启动旧nn2的namenode服务.
```
./hadoop-daemon.sh start namenode
```
5.关闭旧nn1的namenode和zkfc服务(关闭旧nn1会触发一次failover切换,将旧nn2切为active). 然后将旧nn1上的元数据同步到新nn2的节点上.
```
./hadoop-daemon.sh stop zkfc 
```
6.重启旧nn2上的zkfc进程,修改hdfs-site.xml 配置文件,同步到 datanode和新nn1机器上
7.启动新的nn1上面的namenode和zkfc服务（等待datanode连接）.
8.启动所有datanode机器.
9.关闭旧nn2上面namenode和zkfc服务(关闭旧nn2会触发failover切换,使新nn1变为active).
10.等待新nn1上的namenode服务变成active,同时关闭其 zkfc服务.
11.修改hdfs-site.xml 配置文件,加入新nn2地址.
12.同步hdfs-site.xml 文件到所有 datanode机器和新nn1,新nn2.
13.启动新nn1上的zkfc服务.
14.启动新nn2上的namenode和zkfc服务.
15.重新启动所有datanode服务.

注:箭头表示对应颜色节点上的zkfc进程所维护的HA关系.

图1 初始状态

图2 步骤1

图3 步骤2

图4 步骤3

上述方案之所以可行,关键在于其灵活地利用了HDFS的HA机制以及zkfc的自动切换的原理.里面的操作原理大家可以反复阅读,体会其中的巧妙之处.下面来谈谈本人在操作此方案时遇到的3个问题:

1.HA关系变化时nn id的添加.因为在此过程中会涉及多次HA关系的变更,在其中需要注意nn id的设置,避免nn id出现重复的情况.
2.zkfc进程启动顺序出错导致Active/Stanby切换失败.这是很容易出错的点.zkfc只有在维护2个相同的NameNode的情况下,才能实现failover,这句话什么意思呢?比如说zkfc1进程在HA模式的nn1,nn2的nn2节点上启动,而另一个zkfc2进程却在HA模式的nn2,新nn1的新nn1上启动,则这个时候,如果停止nn2节点,zkfc将不会切换active状态到新nn1.
3.NameNode迁移导致对外服务地址的变更.尽管是集群的热迁移,但是迁移的过程中难免还是发生了NameNode的IP地址的变化,这个时候外部的一些客户端程序必然会出现异常,这个时候比较好的做法是用固定域名代替ip.以后不管NameNode Ip怎么变,域名永远都是同一个.