namenode和datanode的高可用性和故障处理

一、Hadoop单点故障问题如何解决

　　Hadoop 1.0内核主要由两个分支组成：MapReduce和HDFS，众所周知，这两个系统的设计缺陷是单点故障，即MR的JobTracker和HDFS的NameNode两个核心服务均存在单点问题，该问题在很长时间内没有解决，这使得Hadoop在相当长时间内仅适合离线存储和离线计算。

　　Hadoop 2.0内核由三个分支组成，分别是HDFS、MapReduce和YARN，而Hadoop生态系统中的其他系统，比如HBase、Hive、Pig等，均是基于这三个系统开发的。

　（1） HDFS：仿照google GFS实现的分布式存储系统，由NameNode和DataNode两种服务组成，其中NameNode是存储了元数据信息（fsimage）和操作日志（edits），由于它是唯一的，其可用性直接决定了整个存储系统的可用性；

　（2）YARN：Hadoop 2.0中新引入的资源管理系统，它的引入使得Hadoop不再局限于MapReduce一类计算，而是支持多样化的计算框架。它由两类服务组成，分别是ResourceManager和NodeManager，其中，ResourceManager作为整个系统的唯一组件，存在单点故障问题；

　（3）MapReduce：目前存在两种MapReduce实现，分别是可独立运行的MapReduce，它由两类服务组成，分别是JobTracker和TaskTraker，其中JobTracker存在单点故障问题，另一个是MapReduce On YARN，在这种实现中，每个作业独立使用一个作业跟踪器（ApplicationMaster），彼此之间不再相互影响，不存在单点故障问题。本文提到的单点故障实际上是第一种实现中JobTracker的单点故障。

　　Hadoop中的HDFS、MapReduce和YARN的单点故障解决方案架构是完全一致的，分为手动模式和自动模式，其中手动模式是指由管理员通过命令进行主备切换，这通常在服务升级时有用，自动模式可降低运维成本，但存在潜在危险。

　　在Hadoop HA中，主要由以下几个组件构成：

　　（1）MasterHADaemon：与Master服务运行在同一个进程中，可接收外部RPC命令，以控制Master服务的启动和停止；

　　（2）SharedStorage：共享存储系统，active master将信息写入共享存储系统，而standby master则读取该信息以保持与active master的同步，从而减少切换时间。常用的共享存储系统有zookeeper（被YARN HA采用）、NFS（被HDFS HA采用）、HDFS（被MapReduce HA采用）和类bookeeper系统（被HDFS HA采用）。

　　（3）ZKFailoverController：基于Zookeeper实现的切换控制器，主要由两个核心组件构成：ActiveStandbyElector和HealthMonitor，其中，ActiveStandbyElector负责与zookeeper集群交互，通过尝试获取全局锁，以判断所管理的master进入active还是standby状态；HealthMonitor负责监控各个活动master的状态，以根据它们状态进行状态切换。

　　（4）Zookeeper集群：核心功能通过维护一把全局锁控制整个集群有且仅有一个active master。当然，如果ShardStorge采用了zookeeper，则还会记录一些其他状态和运行时信息。

　　实现高可用性时，可能会出现的问题：

　　（1）脑裂（brain-split）：脑裂是指在主备切换时，由于切换不彻底或其他原因，导致客户端和Slave误以为出现两个active master，最终使得整个集群处于混乱状态。解决脑裂问题，通常采用隔离(Fencing)机制，包括三个方面：

　　　　共享存储fencing：确保只有一个Master往共享存储中写数据。

　　　　客户端fencing：确保只有一个Master可以响应客户端的请求。

　　　　Slave fencing：确保只有一个Master可以向Slave下发命令。

　　Hadoop公共库中对外提供了两种fenching实现，分别是sshfence和shellfence（缺省实现），其中sshfence是指通过ssh登陆目标Master节点上，使用命令fuser将进程杀死（通过tcp端口号定位进程pid，该方法比jps命令更准确），shellfence是指执行一个用户事先定义的shell命令（脚本）完成隔离。

　　（2）切换对外透明：为了保证整个切换是对外透明的，Hadoop应保证所有客户端和Slave能自动重定向到新的active master上，这通常是通过若干次尝试连接旧master不成功后，再重新尝试链接新master完成的，整个过程有一定延迟。在新版本的Hadoop RPC中，用户可自行设置RPC客户端尝试机制、尝试次数和尝试超时时间等参数。

　　HA解决的难度取决于Master自身记录信息的多少和信息可重构性，如果记录的信息非常庞大且不可动态重构，比如NameNode，则需要一个可靠性与性能均很高的共享存储系统，而如果Master保存有很多信息，但绝大多数可通过Slave动态重构，则HA解决方法则容易得多，典型代表是MapReduce和YARN。从另外一个角度看，由于计算框架对信息丢失不是非常敏感，比如一个已经完成的任务信息丢失，只需重算即可获取，使得计算框架的HA设计难度远低于存储类系统。

　　datanode损坏如何恢复：

　　关闭处于dead状态节点的相关hadoop进程：

　　　　1、关闭datanode进程；sbin/hadoop-daemon.sh stop datanode2、关闭该节点yarn资源管理进程sbin/yarn-daemon.sh stop nodemanager 

　　重启dead状态节点的相关hadoop进程（同样适用于动态新增节点启动）：

　　　　1、重启回复datanode进程；sbin/hadoop-daemon.sh start datanode2、重启回复该节点yarn资源管理进程sbin/yarn-daemon.sh start nodemanager 3、使用jps命令查看重启进程情况

二、Hadoop的高可用性(从单点故障问题解决)

　　（1）高可用性架构图如下所示。

 

 

 

　　1、JN实现主备NN 间的数据共享（解决单点故障）

 　　主NameNode对外提供服务，备NameNode同步主NameNode元数据，以待切换，所有DataNode同时向两个NameNode汇报数据块信息（位置）

standby：备用namenode，完成了edits.log文件的合并产生新的fsimage，推送回ActiveNN

　　2、基于Zookeeper自动切换方案

　　ZooKeeper Failover Controller（zkfc)：监控NameNode健康状态，并向Zookeeper注册NameNode,当主NameNode挂掉后，ZKFC(备)为NameNode竞争锁，获得ZKFC(备)锁的NameNode(备)变为active。

　　3、ZKFC的作用

　　健康检测：zkfc会周期性的向它监控的namenode（只有namenode才有zkfc进程，并且每个namenode各一个）发生健康探测命令，从而鉴定某个namenode是否处于正常工作状态，如果机器宕机，心跳失败，那么zkfc就会标记它处于不健康的状态；

　　会话管理：如果namenode是健康的，zkfc机会保持在zookeeper中保持一个打开的会话，如果namenode是active状态的，那么zkfc还会在zookeeper中占有一个类型为短暂类型的znode，当这个namenode挂掉时，这个znode将会被删除，然后备用的namenode得到这把锁，升级为主的namenode，同时标记状态为active,当宕机的namenode,重新启动，他会再次注册zookeeper,发现已经有znode了，就自动变为standby状态，如此往复循环，保证高可靠性，但是目前仅支持最多配置两个namenode.
　　master选举：如上所述，通过在zookeeper中维持一个短暂类型的znode,来实现抢占式的锁机制，从而判断哪个namenode为active状态。