Hadoop HA

  Hadoop集群设计部署在通用商用硬件集群上，而不是运行在昂贵的中型大型机以及专有硬件设备上，节约成本的同时，相对低廉的商业级机器也意味着Hadoop集群节点会出现故障宕机的情况。因此，在集群架构设计时需充分考虑Hadoop集群的可靠性，Hadoop HA架构主要采用hot standby（热备）和failover（失效转移）的技术手段。

HDFS HA

  没有实现HA的HDFS中NameNode节点是整个Hadoop集群的中心服务节点，如果NameNode节点故障宕机或者数据丢失，整个集群的服务将不能正常工作。在Hadoop1.0和2.0中，先后出现Secondary NameNode、Backup Node和Checkpoint Node等技术手段试图解决NameNode的单点制约问题。
  Secondary NameNode并不如其名称所呈现的含义那样，是Hadoop集群中的第二个NameNode节点，Secondary NameNode的作用只是辅助NameNode节点管理Namespace，在NameNode服务不可用时，它不能够接替NameNode向Hadoop集群提供服务。Secondary NameNode在dfs.namenode.checkpoint.period参数所配置的时间间隔执行checkpoint过程，定期从NameNode节点上获取EditLog日志文件，将EditLog日志中的事务合并到本地所维护的FsImage中，生成一个新镜像文件，并将其发送给NameNode节点，提高NameNode节点的服务能力。如果使用Secondary NameNode来恢复NameNode节点，将会导致上一次checkpoint之后的EditLog事务丢失。Checkpoint Node作用与Secondary NameNode类似，都是辅助NameNode节点管理Namespace。
  Backup Node是NameNode的备份节点，在内存中维护了一份Namespace的备份，与Secondary NameNode定期去NameNode节点上获取EditLog日志不同，Backup Node持续接收NameNode数据流推送的EditLog日志，并将其保存到本地磁盘上。定期执行checkpoint时将事务日志应用到本地所维护的FsImage中，复制NameNode的当前状态。当NameNode服务不可用时，需要手动failover切换数据服务到Backup Node，而Backup Node需要从DataNode获取整个HDFS中数据块的最新位置信息，Backup Node根据DataNode节点上所存储的数据块数量多少会有一定的启动时延。
  Hadoop官方2.2.0版本中发布了HDFS HA机制。在Hadoop集群中同时部署两个NameNode节点，采用隔离(Fencing)机制保证任何时刻都只有一个NameNode节点处于Active状态，即保证只有一个节点对外提供服务，防止脑裂情况的发生，造成整个集群中数据状态的混乱。为了实现Active状态的NameNode不可用时，备用NameNode节点能够无缝接管数据服务，减少因获取DataNode上数据块最新位置信息所带来的时延。HDFS中所有的DataNode节点需同时与主备NameNode保持heartbeat实时汇报数据块使用情况。
  主备NameNode节点之间通过共享存储系统同步命名空间元数据。处于Active状态的NameNode将事务操作记录到共享存储上，备用NameNode节点定期将共享存储中的EditLog拉取到本地执行，与FsImage合并后生成新的镜像FsImage，并通知Active状态的NameNode节点来获取这个新生成的FsImage文件，可以看到，引入HA机制后，用户无需配置任何Secondary NameNode或Backup Node和Checkpoint Node。当Active状态的NameNode宕机后，备用NameNode节点会在接管数据服务之前读取共享存储中记录的所有事务记录，并在本地执行，保证与停机的NameNode节点拥有完全一致的命名空间，快速可靠的接管数据服务提升为新的Active NameNode。
  Hadoop2.0以后，存在基于NFS（Network File System）、HDFS、Zookeeper以及QJM（Quorum Journal Manager）的常用共享存储方案。本博文介绍基于QJM和Zookeeper集群的HA架构，整个方案如图所示。

  QJM共享存储方案基于Paxos算法实现。主备NameNode节点之间通过2N+1个轻量级守护进程JournalNode进行数据同步，任意时刻只允许一个NameNode往这一组JournalNodes上写EditLog。当Active状态的NameNode节点向这组JournalNodes上写入事务操作记录时，至少有N+1个JournalNode返回结果则NameNode认为本次写操作成功，QJM方案的容错机制能够容忍N个JournalNode节点的失效。
  HA架构中通过Zookeeper集群和在每个NameNode节点上部署ZKFailoverController客户端进程自动完成主备NameNode节点间服务的失效转移。Zookeeper通过维护一个Ephemeral类型的ZNode来提供分布式锁服务，控制整个集群中任意时刻只有一个持有此排它锁的NameNode节点，此NameNode处于Active状态。
  ZKFailoverController客户端进程主要包括HealthMonitor组件和ActiveStandbyElector组件，ZKFailoverController通过协调两个核心组件之间的操作，来完成主备NameNode服务之间的自动failover过程。其中HealthMonitor组件通过向本地的NameNode节点发送heartbeat来监测NameNode节点的健康状态，如果NameNode节点失效处于无响应或不健康状态，那么HealthMonitor会将其标记为相应状态，ZKFailoverController会根据HealthMonitor的标记状态进行不同回调处理。ActiveStandbyElector组件主要负责ZKFailoverController与ZooKeeper之间的交互。当处于Active状态的NameNode节点被标记为不健康或者无响应状态时此NameNode节点将会退出选举，ActiveStandbyElector对象与Zookeeper交互将之前创建的Znode删除，触发新一轮的选举。所有健康状态的NameNode节点参与选举，尝试获得排它锁，这些NameNode节点上的ActiveStandbyElector对象与Zookeeper交互，如果某个ActiveStandbyElector能够在Zookeeper上创建新的Znode，获得排它锁，那么其所在的NameNode节点将赢得选举成为新的Active服务节点。ActiveStandbyElector调用失效NameNode节点的fencing method将其隔离，并将本地NameNode节点标记为Active。可以采用sshfence隔离机制，通过SSH（Secure Shell Client）连接到旧的Active状态的NameNode节点，kill掉NameNode进程，防止脑裂情况发生，避免失效的NameNode节点任然向保持连接DataNode和客户端提供错误的数据服务。核心配置如下。

YARN HA

  YARN负责Hadoop集群中资源的管理与调度，为MapReduce和Spark计算任务合理分配资源，提高资源利用率，降低管理成本，YARN中ResourceManager存在单点故障。YARN的HA方案与HDFS的HA方案类似，都是采用基于共享存储和Zookeeper的技术手段实现服务节点间的热备和自动失效转移，规避因单点故障所导致的服务不可用，HA方案如图。

  ZKRMStateStore作为共享存储方案，相比于需要维护大量元数据，且元数据信息不可重构而需要使用高容错的QJM方案而言，ResourceManager仅需要记录少量的Application数据。因此ResourceManager节点间的数据同步基于轻量级Zookeeper，而不是FileSystemRMStateStore。
  YRAN HA方案同样使用ZKFailoverController来实现集群中ResourceManager节点的健康状态监控与自动故障转移，所不同的是ZKFailoverController作为RescouceManager中的一个内嵌线程运行，而不是独立的客户端进程。核心配置如下。