namenode失效后的处理方式以及故障切换与规避(HDFS的高可用性)

作者: admin 分类: Hadoop 发布时间: 2018-03-06 13:57  阅读: 417 views

通过联合使用在多个文件系统中备份namenode的元数据和通过备用namenode创建监测点能防止数据丢失,但是依旧无法实现文件系统的高可用性。

Namenode依旧存在单点失效(SPOF)问题。如果namenode失效了,那么所有的客户端-包括MapReduce作业均无法读、写或列文件,因为namenode是唯一存储元数据与文件到数据块映射的地方。hadoop系统无法提供服务直到有新的namenode上线。


这样,要想从一个失效的namenode恢复,系统管理员得启动一个拥有文件系统元数据副本的新的namenode,并配置datanode和客户端以便使用这个新的namenode。新的namenode直到满足以下情形才能相应服务。

1).将命名空间的映像导入内存中;

2).重做编辑日志;

3).接收到足够多的来自datanode的数据块报告并推出安全模式。

对于一个大型并拥有大量文件和数据块的集群,namenode的冷启动需要30分钟,甚至更长。


系统恢复时间过长,会影响到日常维护。in fact, namenode失效的可能性非常低,所以在实际应用中计划系统失效时间就尤为重要。
Hadoop2.X发行版本针对以上问题在HDFS中增加了对高可用性(HA)的支持,这一实现中,配置了一对活动-备用(active-standby)namenode。当活动namenode失效,备用namenode就会接管它的任务并开始服务于来自客户端的请求,不会有任何明显中断。实现这一目标需要在架构上做修改。

  1. namenode之间需要通过高可用的共享存储来实现编辑日志的共享。当备用namenode接管工作之后,它将通读共享编辑日志直至末尾,实现与活动namenode的状态同步,并继续读取由活动namenode写入的新条目。
  2. datanode需要同时向两个namenode发送数据块处理报告,因为数据块的映射信息存储在namenode的内存中,而非磁盘。
  3. 客户端需要使用特定的机制来处理namenode的失效问题。这一机制对用户是透明的。

在活动namenode失效后,备用的namenode能够快速实现任务接管,因为最新的状态存储在内存中:包括最新的编辑日志条目和最新的数据块映射信息。实际观察到的失效时间略长一点,因为系统需要保守确定活动namenode是否失效了。


在活动namenode失效且备用namenode也失效的情况下,管理员依旧可以声明一个备用namenode并实现冷启动。


一个称之为故障转移控制器(failover_controller)的系统中有一个新实体管理着将活动namenode转移为备用namenode的转换过程。故障转移控制器是可插拔的,但最初实现是基于Zookeeper的并由此确保有且仅有一个活动namenode。每个namenode运行着一个轻量级的故障转移控制器。其工作就是监控宿主namenode是否失效(通过简单的心跳机制实现)并在namenode失效时进行故障切换。管理员也可以手动发起故障转移。


HDFS高可用性做了进一步的优化,确保先前活动的namenode不会执行危害系统并导致系统奔溃的操作-称之为”规避(fencing).“ 系统引入了一系列的规避机制,包括杀死namenode进程,收回访问共享目录的权限,通过远程管理命令以屏蔽相应的网络端口。最后手段是通过特定的供电单元对相应主机进行断电操作。


客户端的故障切换通过客户端类库来实现透明处理。最简单是通过客户端的配置文件实现故障切换的控制。


   原创文章,转载请标明本文链接: namenode失效后的处理方式以及故障切换与规避(HDFS的高可用性)

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

更多阅读