wind520

Hadoop中Namenode单点故障的解决方案及详细介绍

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

下载源码

https://github.com/facebook/hadoop-20

部署环境

机器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)

Hadoop中Namenode单点故障的解决方案及详细介绍

你可能感兴趣的:(hadoop,单点故障)