关于面试--【Standby Namenode Checkpoint】&【namenodeHA】

 Standby Namenode

 Standby Namenode(sbn)在进入standby状态后FSNamesystem调用startStandbyServices(final Configuration conf)，该方法会创建两个重要的对象：EditLogTailer 和 StandbyCheckpointer，前者有两个功能：

1. 触发Active Namenode(nn) edits log roll
2. 从JournalNodes拉取edit log供fsimage合并

后者有三个功能：

1. 对namespace进行checkpoint

2. 清理陈旧的fsimage文件和edits文件(sbn并不会将拉取的edit log保存到磁盘，所以就不存在清理。nn将edit log写到本地和JournalNodes，所以就涉及到陈旧edits文件的清理)，详细清理过程后续博客会继续分析。

3. 上传新checkpoint出的fsimaeg文件到nn

       

     StandbyCheckpointer内部维护一个CheckpointerThread线程，该线程负责周期性检查checkpoint条件是否满足，如果满足就进行checkpoint。

• 检测周期(checkpointPeriod)：1000*Math.min(dfs.namenode.checkpoint.period, dfs.namenode.checkpoint.check.period)秒

• 条件1：最近一次合并到namespace的edit log的 txid 和最近一次做了checkpoint的txid的差值大于或者等于dfs.namenode.checkpoint.txns配置的数量(默认1000000)

• 条件2：当前时间距离最近一次checkpoint的时间间隔大于或者等于dfs.namenode.checkpoint.period (默认3600秒)

        CheckpointerThread每隔checkpointPeriod 秒检查一次。优先检查条件1是否满足，如果满足就进行checkpoint，否则检查条件2，如果条件2满足就进行checkpoint，否则就等待下一个检查周期。一旦条件满足，就进入doCheckpoint()方法进行checkpoint，流程如下： 

                                                                checkpoint流程【请点击查看原图】

        checkpoint过程本质就是将维护在内存中的namespace全量inode树导出到磁盘保存为fsimage_txid文件，并生成fsimage_txid文件的md5保存到fsimage_txid.md5文件。考虑到磁盘故障等问题，sbn 和 nn都可以配置多个目录保存fsimage文件和edits文件【通常建议将fsimsge和edits分开保存到不同磁盘，这样可以缓解磁盘压力，毕竟运行中的nn会频繁刷editlog到磁盘，checkpoint也会写大文件到磁盘】，所以就需要将fsimage导出到多个目录。导出过程由FSImageSaver完成，FSImageSaver实现了Runnable接口，内部根据_Protocol Buffer_定义好的fsimage的数据格式和压缩格式将namespace写入fsimage_txid.ckpt文件，写入完成后再将此文件重名字为fsimage_txid文件，并生成文件的md5码保存到fsimage_txid.md5文件。对应于每个保存目录都会创建一个线程和一个FSImageSaver对象，多个目录并行导出。

        待新的fsimage文件生成之后，sbn会将磁盘上保留的陈旧的fsimage文件清理掉。历史fsimage文件通常只会在元数据损坏的时候被用来做恢复用，适当保留几份就够了，太多了不仅没用反而浪费磁盘空间。有关清理过程，后续会分析。

        最后一步，sbn将新的fsimage文件上传给nn，这也是sbn除ha外的另一个存在意义。为了在文件传输过程中也能快速完成transition to active(HDFS-4816)，StandbyCheckpointer会单独启动一个线程，在其内部由TransferFsImage用http协议(nn 用jetty维护了一个ImageServlet 用于 fsimage文件的上传、下载)完成fsimage传输。

        涉及到的几个重要参数：

参数名称	说明	默认值
dfs.namenode.checkpoint.period	checkpoint的时间间隔	3600（秒）
dfs.namenode.checkpoint.check.period	检查周期	60（秒）
dfs.namenode.checkpoint.txns	两次checkpoint间的txid数量，超过该值就应该checkpoint	1000000
dfs.image.compress	是否压缩生成的fsimage文件	false
dfs.image.compression.codec	压缩格式	org.apache.hadoop.io.compress.DefaultCodec

前三个参数关系到checkpoint的频率，如果过于频繁会导致频繁上传fsimaeg文件、频繁写磁盘，给nn造成压力，影响正常服务。如果频率低，则会导致过多事务得不到持久化，最终nn重启时间延长，sbn也就失去了意义。

--------------------------------------------------------------------------------------------------------------

HA（高可用）介绍

Hadoop2.0的HA 机制有两个NameNode，一个是Active状态，另一个是Standby状态。两者的状态可以切换，但同时最多只有1个是Active状态。只有Active Namenode提供对外的服务。Active NameNode和Standby NameNode之间通过NFS或者JN（JournalNode，QJM方式）来同步数据。

Active NameNode会把最近的操作记录写到本地的一个edits文件中（edits file），并传输到NFS或者JN中。Standby NameNode定期的检查，从NFS或者JN把最近的edit文件读过来，然后把edits文件和fsimage文件合并成一个新的fsimage，合并完成之后会通知Active NameNode获取这个新fsimage。Active NameNode获得这个新的fsimage文件之后，替换原来旧的fsimage文件。

这样，保持了Active NameNode和Standby NameNode的数据实时同步，Standby NameNode可以随时切换成Active NameNode（譬如Active NameNode挂了）。而且还有一个原来Hadoop1.0的SecondaryNameNode，CheckpointNode，BackupNode的功能：合并edits文件和fsimage文件，使fsimage文件一直保持更新。所以启动了hadoop2.0的HA机制之后，SecondaryNameNode，CheckpointNode，BackupNode这些都不需要了。

数据同步方式：NFS与 QJM（Quorum Journal Manager ）

1、NFS

NFS作为Active NameNode和Standby NameNode之间数据共享的存储。Active NameNode会把最近的edits文件写到NFS，而Standby NameNode从NFS中把数据读过来。这个方式的缺点是，如果Active NameNode或者Standby Namenode有一个和NFS之间网络有问题，则会造成他们之前数据的同步出问题。

2、 QJM（Quorum Journal Manager ）

QJM的方式可以解决上述NFS容错机制不足的问题。Active NameNode和Standby NameNode之间是通过一组JournalNode（数量是奇数，可以是3,5,7…,2n+1）来共享数据。Active NameNode把最近的edits文件写到2n+1个JournalNode上，只要有n+1个写入成功就认为这次写入操作成功了，然后Standby NameNode就可以从JournalNode上读取了。可以看到，QJM方式有容错机制，可以容忍n个JournalNode的失败。

Active和Standby两个NameNode之间的数据交互流程为：

1）NameNode在启动后，会先加载FSImage文件和共享目录上的EditLog Segment文件；

2）Standby NameNode会启动EditLogTailer线程和StandbyCheckpointer线程，正式进入Standby模式；

3）Active NameNode把EditLog提交到JournalNode集群；

4）Standby NameNode上的EditLogTailer 线程定时从JournalNode集群上同步EditLog；

5）Standby NameNode上的StandbyCheckpointer线程定时进行Checkpoint，并将Checkpoint之后的FSImage文件上传到Active NameNode。（在Hadoop 2.0中不再有Secondary NameNode这个角色了，StandbyCheckpointer线程的作用其实是为了替代 Hadoop 1.0版本中的Secondary NameNode的功能。）

QJM方式有明显的优点，一是本身就有fencing的功能，二是通过多个Journal节点增强了系统的健壮性，所以建议在生产环境中采用QJM的方式。JournalNode消耗的资源很少，不需要额外的机器专门来启动JournalNode，可以从Hadoop集群中选几台机器同时作为JournalNode。

主备NameNode切换

Active NameNode和Standby NameNode可以随时切换，可以人工和自动。人工切换是通过执行HA管理命令来改变NameNode的状态，从Standby到Active，或从Active到Standby。自动切换则在Active NameNode挂掉的时候，Standby NameNode自动切换成Active状态。

主备NameNode的自动切换需要配置Zookeeper。Active NameNode和Standby NameNode把他们的状态实时记录到Zookeeper中，Zookeeper监视他们的状态变化。当Zookeeper发现Active NameNode挂掉后，会自动把Standby NameNode切换成Active NameNode。