hadoop的namenode, secondarynamenode, standbynamenode, journalnode

namenode

最初hadoop只有namenode一人保管datanode的元数据.
namenode包括fsimage(文件系统快照)和edit logs(编辑日志)两部分.
fsimage看名字就知道是个臃肿的东西, 而对文件系统的编辑又是快而频繁的, 所以需要一个内存中存储的edit logs, 以便频繁地修改写入.
namenode启动之初, 会将edit logs合并入fsimage中. 也就是说, 新备份会在namenode启动时产生.

但一般来说namenode一开就要很久, 导致edit logs越滚越大, 内存可没有这么大. 所以出现了secondary namenode.

secondary namenode(辅助namenode)

它跑在除namenode所在机器外的另一台机器上.
它会定时获取namenode的edit logs, 将edit logs更新在自己机器上的fsimage里, 再把fsimage传给namenode.
这样, 就省去了namenode启动时自己合并的麻烦, 加快了启动时间.

standby namenode(备份namenode)和journalnode

即使有了secondary namenode这个方案, 它定时备份的特点还是会让fsimage有一定滞后性. 我们有更高的要求.
standby namenode是和namenode同时更新的, 但它不是主namenode, 只是standby.
standby namenode会和namenode共享edit logs, 并在namenode宕机时热切换, 接替namenode的工作.
datanode会将修改信息同时告诉两个namenode, 但standby namenode不会进行edit logs的操作, 除非namenode坏掉.

对于standby namenode的实现, 有两种方案

1. 使用NFS过滤器

Network Filesystem(NFS, 网络文件系统).
通过linux共享的文件系统实现共享存储, 可以实现主从namenode的edit logs共享. 但这种操作被证实有很大风险. 假如系统抽风, 网络延迟, 心跳出错, standby namenode就被骗到了, 会在namenode没坏的情况下把自己转为主节点, 就存在了两个往edit logs里写东西的namenode.这会导致文件损坏.
这种两个namenode同时生效的状况叫做脑裂(split-brain), 意为一个大脑两种思想.
所以需要配置fencing脚本来实现两个功能:

1. 关闭namenode
2. 禁止namenode访问edit logs的权限.
   这种方案下, 管理员就拥有了手动触发namenode切换的能力. 但它特别麻烦, 容易出错. 诸多细节不再详述.

2. 使用QJM

quorum journal manager(QJM, 群体日志管理器)
QJM包括奇数数量的journalnode, 一个namenode, 一个standbynamenode.
datanode将修改信息同时告诉给namenode和standbynamenode. 因为standbynamenode在standby状态, 所以无动于衷.
namenode, standbynamenode, journalnode这三边都有一个值epoch, 它用于解决脑裂问题.
namenode会将修改操作告诉给所有journalnode, 并带上自身的epoch值. 当然, 因为网络或者其他奇怪的原因, 小部分journalnode可能没有回应, 但大部分journalnode接收到了信息, 并拿着namenode传来的epoch和自己保存的epoch比对, 如果不比自己的小, 就认为传来的确实是主namenode的信息, 并更新自己的edit logs.
standby namenode在standby时会探查journalnode上是否有edit logs更新, 如果有就读取并更新自己.
假如standby namenode被触发了, 它会给自己分配一个比以往所有namenode的epoch值更高的epoch值, 以声明自己才是主namenode.
journalnode接收namenode来的信息时, 会将二者的epoch比较, 如果对方的较小, 就拒绝他写入.
只有大部分的journalnode都写入了,才算成功. 之所以这么说, 是因为可能出现如下情况

• 某一时刻, standbynamenode被激活, 开始向journalnode里写数据. 但网络太差导致有小部分数据写入失败.此时的namenode还没有关闭, 还在尝试往journalnode里写数据, 但由于大部分的journalnode已经被standbynamenode写过了, 拥有了更大的epoch, namenode就只能往那些"失联"的journalnode里写入. 这些只写入小部分journalnode的数据应该不算数.

TODO: zookeeper