Hadoop中Namenode单点故障的解决方案分析

昵称18109326 2014-06-13

展开全文

Hadoop中Namenode单点故障的解决方案分析

cloudera 公司namenode的高可用处理分析

参考：http://blog.csdn.net/feelig/article/details/9463909

一、namenode的HA高可用初始化

注解： namenode:192.168.1.1

datanode:192.168.1.100 192.168.1.101

1.在namenode主服务器(192.168.1.1)执行zookeeper的failover功能格式化

sudo–u hdfs hdfs zkfc –format

2.把zookeeper集群服务启动(192.168.1.100 192.168.1.101 )

/etc/init.d/zookeeper-overstay

3.把namenode主备服务器的zkfc服务起来(192.168.1.1 192.168.1.2)

/etc/init.d/hadoop-hdfs-zkfcstart

4.在namenode主服务器(192.168.1.1)格式化hdfs

#确保是用hdfs用户格式化

sudo-u hdfs hadoop namenode –format

5.第一次搭建namenode高可用，需要把name.dir下面的数据复制到namenode备服务器（此坑花了好多时间）

a.在主服务器(192.168.1.1)执行

tar -zcvPf /tmp/namedir.tar.gz /data/hadoop/dfs/name/

nc -l 9999 </tmp/namedir.tar.gz

b.在备服务器(192.168.1.2)执行

wget 192.168.1.1:9999 -O /tmp/namedir.tar.gz

tar -zxvPf /tmp/namedir.tar.gz

6.主从服务都启动

/etc/init.d/hadoop-hdfs-namenodestart

/etc/init.d/hadoop-yarn-resourcemanagerstart

7.查看hdfs的web界面

http://192.168.1.1:9080

http://192.168.1.2:9080

#如果在web界面看到两个namenode都是backup状态，那就是auto fail over配置不成功

#查看zkfc日志(/var/log/hadoop-hdfs/hadoop-hdfs-zkfc-nn.dg.s.

kingsoft.net.log)

#查看zookeeper集群的日志(/var/log/zookeeper/zookeeper.log)

8.现在可以尝试关闭namenode主服务，看是否能主从切换

Hadoop官方和Facebook推荐处理方法分析及详细介绍AvatarNode

参考：http://www./thread-6799-1-1.html

http://www./storage/technology/94928.html

正如大家所知，NameNode在Hadoop系统中存在单点故障问题，这个对于标榜高可用性的Hadoop来说一直是个软肋。本文讨论一下为了解决这个问题而存在的几个solution。

1. Secondary NameNode

原理：Secondary NN会定期的从NN中读取editlog，与自己存储的Image进行合并形成新的metadata image

优点：Hadoop较早的版本都自带，配置简单，基本不需要额外资源（可以与datanode共享机器）

缺点：恢复时间慢，会有部分数据丢失

2. Backup NameNode

原理：backup NN实时得到editlog，当NN宕掉后，手动切换到Backup NN；

优点：从hadoop0.21开始提供这种方案，不会有数据的丢失

缺点：因为需要从DataNode中得到Block的location信息，在切换到Backup NN的时候比较慢（依赖于数据量）

3. Avatar NameNode

原理：这是Facebook提供的一种HA方案，将client访问hadoop的editlog放在NFS中，Standby NN能够实时拿到editlog；DataNode需要同时与Active NN和Standby NN report block信息；

优点：信息不会丢失，恢复快（秒级）

缺点：Facebook基于Hadoop0.2开发的，部署起来稍微麻烦；需要额外的机器资源，NFS成为又一个单点（不过故障率低）

4. Hadoop2.0直接支持StandBy NN，借鉴Facebook的Avatar，然后做了点改进

优点：信息不会丢失，恢复快（秒级），部署简单

详细介绍Hadoop NameNode单点问题解决方案之一 AvatarNode

需求：实现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本身会丢失数据的可能性，毕竟这种几率很小很小）。既然可以解决数据丢失的问题，说明这套方案在原理上是可行的。

部署环境

机器4台

hadoop1-192.168.64.41 AvatarNode(primary)

hadoop2-192.168.64.42 AvataDataNode

hadoop3-192.168.64.43 AvataDataNode

hadoop4- 192.168.64.67 AvatarNode(standby)

相关资源及描述

以下是Avatar方案部署相关的简单介绍。

1.首先关于Avatar方案对于Hadoop的备份是对Dfs的的单点备份，并不包括Mapred，因为Hadoop本身就不存在处理jobtracker单点故障的机制。

2.AvatarNode继承自Namenode，而并非对Namenode的修改，AvatarDataNode同样亦如此。故Avatar的启动机制是独立于Hadoop本身的启动机制。

3.在Avatar方案中，SecondaryNamenode的职责已包括在Standby节点中，故不需要再独立启动一个SecondaryNamenode。

4.AvatarNode必须有NFS的支持，用以实现两个节点间事务日志(editlog)的共享。

5.FB提供的Avatar源码中暂时并不能实现Primary和Standby之间的自动切换，可以借助于Zookeeper的lease机制来实现自动切换。

6.Primary和Standby之间的切换只包括从Standby切换到Primary，并不支持从Primary状态切换到Standby状态。

7.AvatarDataNode并不使用VIP和AvatarNode通信，而是直接与Primary及Standby通信，故需要使用VIP漂移方案来屏蔽两个节点间切换过程中的IP变换问题。有关与Zookeeper的整合，官方称将在之后的版本发布。

三、编译

1. 首先修改hadoop根目录下build.xml，注释掉996行和1000行。如下：

<targetname="forrest.check"unless="forrest.home"depends="java5.check">

</target>

</target>

2. 在根目录下输入ant jar（对于编译package可以参考build.xml的代码）编译hadoop，编译后的jar包会在build目录下（hadoop-0.20.3-dev-core.jar），拷贝该jar包到hadoop根目录下替换到原有的jar （啰嗦一句，hadoop启动时会先加载build目录下的class，所以当通过替换class修改jar包时请先把build目录暂时移除掉）。

3. 进入src/contrib/highavailability目录下编译Avatar，编译后的jar包会在build/contrib/highavailability目录下(hadoop-${version}-highavailability.jar)，拷贝该jar包到lib目录下。

4. 把2,3步中编译好的jar包分发到集群中所有机器的相应目录。

四、配置

1. 配置hdfs-site.xml

<?xmlversion="1.0"?>

<?xml-stylesheettype="text/xsl"href="configuration.xsl"?>

<value>/data/hadoop/hdfs/name</value>

<description>Determineswhereon the local filesystem the DFS name node shouldstore the name table. Ifthis is a comma-delimited list ofdirectories then the name tableis replicated in all of thedirectories, for redundancy

</description>

</property>

<name>dfs.data.dir</name> <value>/data/hadoop/facebook_hadoop_data/hdfs/data</value>

</property>

<name>dfs.datanode.address</name>

<description>默认为50010, 是datanode的监听端口</description>

</property>

<name>dfs.datanode.http.address</name>

<description>默认为50075，为datanode的http server端口</description>

</property>

<name>dfs.datanode.ipc.address</name>

<description>默认为50020, 为datanode的ipc server端口</description>

</property>

<name>dfs.http.address0</name>

</property>

<name>dfs.http.address1</name>

</property>

<name>dfs.name.dir.shared0</name>

<value>/data/hadoop/share/shared0</value>

</property>

<name>dfs.name.dir.shared1</name>

<value>/data/hadoop/share/shared1</value>

</property>

<name>dfs.name.edits.dir.shared0</name>

<value>/data/hadoop/share/shared0</value>

</property>

<name>dfs.name.edits.dir.shared1</name>

<value>/data/hadoop/share/shared1</value>

</property>

<name>dfs.replication</name>

Defaultblock replication. The actual number of replicationscan bespecified when the file is created. The default isused ifreplicationis not specified in create time

</description>

</property>

</configuration>

参数说明：

1) dfs.name.dir.shared0

AvatarNode(Primary)元数据存储目录,注意不能和dfs.name.dir目录相同

2) dfs.name.dir.shared1

AvatarNode(Standby)元数据存储目录,注意不能和dfs.name.dir目录相同

3) dfs.name.edits.dir.shared0

AvatarNode(Primary) edits文件存储目录，默认与 dfs.name.dir.shared0一致

4) dfs.name.edits.dir.shared1

AvatarNode(Standby) edits文件存储目录，默认与 dfs.name.dir.shared1一致

5) dfs.http.address0

AvatarNode(Primary) HTTP的监控地址

6) dfs.http.address1

AvatarNode(Standby) HTTP的监控地址

7) dfs.namenode.dn-address0/dfs.namenode.dn-address1

虽然在Avatar源码中有所涉及，但暂时并未用到

2. 配置core-site.xml

<?xmlversion="1.0"?>

<?xml-stylesheettype="text/xsl"href="configuration.xsl"?>

<name>hadoop.tmp.dir</name>

<value>/home/hadoop/tmp</value>

<description>A baseforother temporary directories.

</description>

</property>

<name>fs.default.name</name>

<description>The name ofthedefault file system. Eitherthe literal string"local" or a host:port for DFS.

</description>

</property>

<name>fs.default.name0</name>

<description>The name ofthedefault file system. Eitherthe literal string"local" or a host:port for DFS.

</description>

</property>

<name>fs.default.name1</name>

<description>The name ofthedefault file system. Eitherthe literal string"local" or a host:port for DFS.

</description>

</property>

</configuration>

参数说明：

1) fs.default.name

当前AvatarNode IP地址和端口号，即Primary和Standby的配置为各自的IP地址和端口号。

2) fs.default.name0

AvatarNode(Primary) IP地址和端口号

3) fs.default.name1

AvatarNode(Standby) IP地址和端口号

3.因为不涉及到mapred，故mapred-site.xml不用作修改，为原有集群配置即可。

4.分发修改后的配置文件到集群节点并在Primary和Standby节点上建立好配置文件中相应目录。

5.建立NFS，实现Primary与Standby shared0目录的数据共享。有关NFS的配置请参考http://blog.csdn.net/rzhzhz/article/details/7056732

6.格式化Primary与Standby，这里可以采用hadoop本身的格式化命令，也可以采用AvatarNode的格式化命令（bin/hadooporg.apache.hadoop.hdfs.AvatarShell -format），但此时shared1目录不能为空，此处有点多余。建议采用hadoop本身的格式化命令在Primary上格式化后，并且把name目录下的文件复制到shared0目录下。然后再在Standby上复制shared0目录下的文件到shared1目录下。

五、启动

1. 由于不涉及jobtracker的单点，在这里我们只启动hdfs相关线程。Primary，Standby两个namenode（此处Standby包括SecondaryNamenode的职责）和3个AvatarDataNode数据节点。

2. 在Primary节点hadoop根目录下启动AvatarNode（Primary）

bin/hadooporg.apache.hadoop.hdfs.server.namenode.AvatarNode–zero

3.在Standby节点hadoop根目录下启动AvatarNode（Standby）bin/hadooporg.apache.hadoop.hdfs.server.namenode.AvatarNode-one–standby

4.依次在数据节点hadoop根目录下启动AvatarDataNode

bin/hadoop org.apache.hadoop.hdfs.server.datanode.AvatarDataNode

5.其他相关命令

##查看当前AvatarNode的状态

1) bin/hadoop org.apache.hadoop.hdfs.AvatarShell –showAvatar

##primary 把当前Standby节点升级Primary节点

2) bin/hadooporg.apache.hadoop.hdfs.AvatarShell -setAvatar

3) bin/hadooporg.apache.hadoop.hdfs.AvatarShell -setAvatar standby

集群测试

1.访问集群的web页

(Primary)http://hadoop1-virtual-machine:50070

(Standby)http://hadoop5-virtual-machine:50070

可见所有的AvatarDataNode都已注册到两个namenode，Primary处于正常状态，而Standby处于Safemode状态，只可读不可写。可通过AvatarShell命令查看当前AvatarNode的状态（Primary或Standby）。

2.存储相关数据到集群，集群正常工作。

3. Kill掉Primary节点的AvatartNode线程，在Standby把当前升级为Prirmary,数据并未丢失，集群正常工作（此时web端不能正常访问文件系统，通过shell命令可查看集群数据）。但由于Avatar有转换限制，只能由Standby转换成Primary，故一次故障后,由Standby上升为Primary的节点并不能重新降级为Standby，所以不能实现像Master/Slave那种自由切换。

有关NFS的介绍

这里我简单的描述下如何给Hadoop的namenode做NFS灾备

1. 首先选定一台灾备机器作为NFS服务器

（1）安装如下：

apt-get install nfs-kernel-server (NFS服务器,提供nfs服务)

apt-get install portmap (端口映射服务器，主要是RPC程序号转化为Internet的端口号)

（2）在/etc/exports文件中设置需要挂载为nfs服务的目录

注： /home/hadoop/name 表示挂载的目录

*表示任意IP，这里大家可以根据需求配置，如10.10.*.*

(rw,sync,no_subtree_check)这里指挂载目录的相关设置（详细描述见文后备注），此处因为要提供给namenode写权限，故应该配置为rw

（3）重新启动NFS服务(使exports修改生效，当然还有另外的命令这里就不再多侃了)

udo /etc/init.d/nfs-kernel-server restart 或者 sudo service nfs-kernel-server restart, 另外start，stop，status就不详述了

至于portmap的相关命令同上

（4）查看挂载目录是否成功

showmount -e

2. 在namenode上安装NFS客服端

（1）apt-get install nfs-common (NFS客户端,访问nfs)

（2）挂载NFS目录到本地

1）mount IP:/home/hadoop/name /home/hadoop/nfs

挂载命令 NFS服务的IP及路径本地目录（必须为已存在的目录）

2）umount /home/hadoop/nfs

卸载目录如果出现device is busy错误可以另加 -l 参数强制卸载

3. 配置namenode下hdfs-site.xml文件的dfs.name.dir配置里加上挂载的路径/home/hadoop/nfs

如

4. 重启hadoop

然后去NFS服务器 /home/hadoop/name 目录下查看是否已经有namenode的fsimage等文件，有则证明配置成功，如出现不能访问指定目录（/home/hadoop/nfs）的错误，请检查NFS服务器端文件权限问题是否为只可读（ro）。

*以下是挂载文件的一些配置参数及含义，仅供参考

   ro                      只读访问
   rw                      读写访问
   sync                    所有数据在请求时写入共享
   async                   NFS在写入数据前可以相应请求
   secure                  NFS通过1024以下的安全TCP/IP端口发送
   insecure                NFS通过1024以上的端口发送
   wdelay                  如果多个用户要写入NFS目录，则归组写入（默认）
   no_wdelay               如果多个用户要写入NFS目录，则立即写入，当使用async时，无需此设置。
   hide                    在NFS共享目录中不共享其子目录
   no_hide                 共享NFS目录的子目录
   subtree_check           如果共享/usr/bin之类的子目录时，强制NFS检查父目录的权限（默认）
   no_subtree_check        和上面相对，不检查父目录权限
   all_squash              共享文件的UID和GID映射匿名用户anonymous，适合公用目录。
   no_all_squash           保留共享文件的UID和GID（默认）
   root_squash             root用户的所有请求映射成如anonymous用户一样的权限（默认）
   no_root_squas           root用户具有根目录的完全管理访问权限
   anonuid=xxx             指定NFS服务器/etc/passwd文件中匿名用户的UID
   anongid=xxx             指定NFS服务器/etc/passwd文件中匿名用户的GID