在Hadoop 2.x中Secondary NameNode的使用率和高可用性

Question

您能否帮我解决以下情况。

1）在使用Hadoop V2时，我们是否在生产环境中使用Secondary NameNode？

2）对于Hadoop的V2，假设我们使用muliple NameNodes在高可用性和当编辑日志文件会变得十分巨大主动/被动连接，

怎样的编辑日志被应用到的FsImage？如果是这样，那么在启动Namenode期间，将巨大的编辑日志应用于Namenode会很耗时？ （我们有hadoop v1中的Secondary NameNode来解决这个问题）

Answer 1

解答您的疑问：

1）在使用Hadoop V2，我们在生产中使用的环境中学的NameNode？

如果您为“名为节点的高可用性”部署StandByName节点，则在生产环境中不需要次要名称节点。

2）在没有辅助节点的情况下，编辑日志如何应用于fsimage？

要回答此查询，您必须以两种不同方式了解Hadoop中实现的可用性如何。 ：High Availability with QJM和High Availability with NFS Federation

但在这两种方法，QJM（仲裁日志管理器）是优选的。

在典型的HA群集中，两台独立的机器配置为NameNode。在任何时候，只有一个NameNodes处于Active状态，另一个处于Standby状态。活动NameNode负责群集中的所有客户端操作，而Standby仅充当从服务器，并保持足够的状态以在必要时提供快速故障转移。

为了使备用节点保持其与活动节点的状态同步，两个节点都与一组称为“JournalNodes”（JN）的独立守护进程进行通信。

当活动节点执行任何名称空间修改时，它会将修改记录持久记录到大多数这些JN中。备用节点从JN读取这些编辑并应用于其自己的名称空间。

如果发生故障切换，备用服务器将确保在将自己提升为活动状态之前，它已从JounalNodes中读取所有编辑。这确保了在故障转移发生之前命名空间状态已完全同步。

对于一次只有一个NameNode处于活动状态的HA群集而言，至关重要。 ZooKeeper已被用于避免分裂大脑情况，因此名称节点状态不会因故障转移而发生分化。

我已经在我的其他的StackOverflow问题，在详细地解释故障转移过程的名称节点：How does Hadoop Namenode failover process works?

Answer 2

1）在使用Hadoop V2时，我们是否在生产环境中使用Secondary NameNode？

它完全取决于您的生产环境设置。如果您将Hadoop V2与HA一起使用，则您不需要生产中的Secondary NameNode，因为您的Slave NameNode将以最佳方式执行与Secondary NameNode相同的任务。但是如果您的生产设置不利用NameNode HA，则必须使用Secondary NameNode进行点校验。请参阅Understanding Hadoop 2.x Architecture和它的恶魔的更多信息。

2）对于Hadoop的V2，假设我们使用了高可用性和当编辑日志文件主动/被动连接muliple NameNodes越来越庞大，

按我这里是了解你的主要关注“Hadoop V2中的NameNode HA如何管理编辑日志？”

下面是答案：编辑日志管理可以通过仲裁日志管理器（QJM）或NFS共享存储

随着QJM来完成，有魔叫JournalNode（JN）的组活跃的NameNode进行通信。该组不断寻找由活动的NameNode完成的任何更新并保持该状态。 StandBy NameNode不断从JN获取编辑日志更新并维护更新后的editlog文件。

使用NFS共享存储，Active NameNode和StandBy NameNode都可以访问共享存储（即网络文件系统）上的特定目录。在由NameNode完成任何更新的情况下，它将事件记录到共享目录。另一方面StandBy NameNode正在寻找在同一共享目录上的更新，并同时更新编辑日志。

我希望这有助于...