Hadoop高可用

参考博客 https://blog.csdn.net/lb812913059/article/details/79718413

一、单namenode架构局限性

1. NameSpace（命名空间的限制）
   由于Namenode在内存中存储所有的元数据（metadata）。NN在管理大规模的命名空间时，单个Namenode所能存储的对象（文件+块）数目受到Namenode所在JVM的堆【内存大小的限制】

   随着数据的飞速增长，存储的需求也随之增长。
   50G的heap能够存储20亿个对象—>4000个datanode—>12PB的存储（假设文件平均大小为40MB）。
   单个datanode从4T增长到36T，集群的尺寸增长到8000个datanode。存储的需求从12PB增长到大于100PB。

2. 性能的瓶颈
   由于是单个Namenode的HDFS架构，因此整个HDFS文件系统的吞吐量受限于单个NameNode的吞吐量。
   这将成为下一代MapReduce的瓶颈。

3. 隔离问题
   由于仅有一个Namenode，无法隔离各个程序，因此HDFS上的一个实验程序很可能影响整个HDFS上运行的程序。
   NN在内部用一把全局锁撸遍所有的元数据操作来保证数据的一致性

4. 集群的可用性
   在只有一个Namenode的HDFS中，此Namenode的宕机无疑会导致整个集群的不可用。（低可用性）

5. Namespace和Block Management(管理)的紧密耦合
   Hadoop 1.x在Namenode中的Namespace和Block Management组合的紧密耦合关系会导致如果想要实现另外一套Namenode方案比较困难，而且也限制了其他想要直接使用块存储的应用。

---

为什么纵向扩展目前的NameNode不可行？比如将NameNode的Heap堆空间扩大到512GB。

1. 启动时间太长。（Hadoop 1.x具有50GB Heap Namenode的HDFS启动一次大概需要30分钟到2小时）
2. Namenode在Full GC时，如果发生错误将会导致整个集群宕机。
3. 对大JVM Heap进行调试比较困难。优化Namenode的内存使用性价比比较低。

二、单点故障问题

HDFS：Hadoop1.x版本中单NameNode设计，其单点处理能力成为HDFS的主要瓶颈。
单点故障、内存受限，制约集群扩展性和缺乏隔离机制（不同业务使用同一个NameNode导致业务相互影响）等。
因为客户端对HDFS的读、写操作之前都要访问NameNode服务器。存在【单点故障问题】

• 计划内的软件或硬件升级，将导致集群在短时间范围内不可用。
• NameNode出现故障导致集群无法使用，直到重启NameNode或者新启动一个NameNode节点

YARN：其中ResourceManager作为整个系统的唯一组件，存在【单点故障问题】

MapReduce：目前存在两种MapReduce实现

• 可独立运行的MapReduce：
  由JobTracker和TaskTraker两类服务组成。其中JobTracker存在【单点故障问题】
  JobTracker完成了太多的任务，造成了过多的资源消耗
  当 map-reduce job 非常多的时候，会造成很大的内存开销，也增加了JobTracker失效的风险
• MapReduce On YARN：
  每个作业独立使用一个作业跟踪器（ApplicationMaster）彼此之间不再相互影响，不存在单点故障问题。

所以从Hadoop的2.x开始,社区试图使用Federation+HA的方案来解决hadoop-1.x中的容量扩展及可用性的问题

三、HA高可用机制

（1）HA机制简介

HA（High Availability）：高可用机制

在Hadoop2.0之前,在HDFS集群中NameNode存在单点故障 (SPOF)。

对于只有一个NameNode的集群，如果NameNode机器出现故障(比如宕机或是软件、硬件升级)，将导致集群在短时间范围内不可用。

HA通过配置Active/Standby两个NameNode实现在集群中对NameNode的热备份来解决上述问题。

1.在一个典型的HA集群中，使用两台单独的机器配置为NameNodes。在任何时间点，确保NameNodes中只有一个处于Active状态，其他的处在Standby状态。其中Active对外提供服务，负责集群中的所有客户端操作，Standby仅仅充当备机，仅同步Active NameNode的状态，以便能够在它失败时快速进行切换。

2.为了能够实时同步Active和Standby两个NameNode的元数据信息（editlog），需提供一个SharedStorage（共享存储系统），可以是NFS或QJM，Active将数据写入共享存储系统，而Standby监听该系统，一旦发现有日志变更，则读取这些数据并加载到自己内存中，以保证自己内存状态与Active保持一致，则在当failover(失效转移)发生时standby便可快速切为active。

3.为了实现快速切换，Standby节点获取集群中blocks的最新位置是非常必要的。为了实现这一目标，DataNodes上需要同时配置这两个Namenode的地址，并同时给他们发送文件块信息以及心跳检测。

4.为了实现热备，增加FailoverController（故障转移控制器）和Zookeeper，FailoverController与Zookeeper通信，通过Zookeeper选举机制，FailoverController通过RPC让NameNode转换为Active或Standby。

【备注】standby代替SNN的功能（edits-----fsimage）
启动了hadoop2.0的HA机制之后，secondarynamenode，checkpointnode，buckcupnode这些都不需要了。

（2）NFS与QJM

NFS（Network File System 网络文件系统）

NFS作为active namenode和standby namenode之间数据共享的存储。

active namenode会把最近的edits文件写到NFS，而standby namenode从NFS中把数据读过来。

这个方式的缺点是，如果active或standby有一个和NFS之间网络有问题，则会造成他们之前数据的同步出问题。
并且不能保证同一时间只有一个namenode向NFS中写入数据

QJM（Quorum Journal Manager 群体日志管理器）【目前hadoop2.x使用】
QJM是一个专用的HDFS实现，提供了一个高可用的编辑日志。这种方式可以解决上述NFS容错机制不足的问题。

同一时间QJM仅允许一个namenode向编辑日志中写入数据。

active和standby之间是通过一组日志节点journal node（数量是奇数，可以是3,5,7…,2n+1）来共享数据。

active把最近的edits文件写到2n+1个journal node上，只要有n+1个写入成功,就认为这次写入操作成功了

然后standby就可以从journalnode上读取了。QJM方式有容错的机制，可以容忍n个journalnode的失败。

（3）failover故障切换

Failover字面意思是失效转移，这是HA的一项简单的容错功能
在早期简单的HA系统一般是AS(A: Active，S: Standby)双节点结构，即一主一备

两个节点之间通过一个串口或网线作为心跳线互相连接，平时只有Active节点工作，心跳断了后，主节点不管正不正常，都自动关闭，备份节点自动接管，并且升级为主节点，从而保持系统正常运行。当失效节点修好重新集成进来后，仍然保持为从节点。这样的切换过程被称为Failover

HA架构模式：

• 手动模式是指由管理员通过命令进行主备切换，这通常在服务升级时有用
• 自动模式可降低运维成本，但存在潜在危险。

自动failover

Automatic Failover中，增加了2个新的组件：zookeeper集群，ZKFailoverController进程(简称为ZKFC)

HDFS的自动故障转移主要由Zookeeper和ZKFC两个组件组成。

Zookeeper是一个高可用的调度服务，可以保存一系列调度数据。当这些数据变更(notify)时通知Client，以及监控(montitor)Clients失效

自动failover的实现将依赖于Zookeeper的几个特性：
1、故障监控。每个NameNode将会和Zookeeper建立一个持久session，如果NameNode失效，那么此session将会过期失效，此后Zookeeper将会通知另一个Namenode，然后触发【Failover】

2、NameNode选举。ZooKeeper提供了简单的机制来实现Acitve Node选举，如果当前Active失效，Standby将会获取一个特定的排他锁(lock)，那么获取锁的Node接下来将会成为Active。原active状态的NameNode将会强制下线

ZKFailoverControllor(ZKFC) 是一个zookeeper客户端。它主要用来监测和管理Namenodes的状态，每个Namenode机器上都会运行一个ZKFC程序

它的职责为：
1、健康监控：ZKFC间歇性的使用health-check指令ping Namenode，Namenode也会及时反馈健康状况。
如果Namenode失效，或者unhealthy，或者无响应，那么ZKFS将会标记其为“unhealthy”。

2、Zookeeper会话管理：当本地Nanenode运行良好时，ZKFC将会持有一个zookeeper session
如果本地Namenode为Active，它同时也持有一个“排他锁”(znode)；那么该lock在zookeeper中为临时节点
如果session过期，那么次lock（锁）所对应的znode也将被删除。

3、Zookeeper选举：如果本地Namenode运行良好，并且ZKFS没有发现其他的的Namenode持有lock(比如Active失效后，释放了lock)，它将尝试获取锁，如果获取成功，即“赢得了选举”，此后将会把该Namenode标记为Active，然后触发Failover：首先，调用fencing method，然后提升本地Namenode为Active。

（4）脑裂及解决

脑裂现象（brain-split）：
脑裂是指在主备切换时，由于切换不彻底或其他原因，导致客户端和DataNode看到两个active NameNode，最终使得整个集群处于混乱状态。那么两个NameNode将会分别有两种不同的数据状态，可能会导致数据丢失或状态异常。

解决脑裂问题，通常采用隔离(Fencing)机制，包括三个方面：
1.共享存储fencing：确保只有一个Master往共享存储中写数据。
2.客户端fencing：确保只有一个Master可以响应客户端的请求。
3.DataNode fencing：确保只有一个Master可以向DataNode下发命令。

然而对于先前活动namenode而言，仍有可能响应并处理客户过时的读请求，因此，设置一个SSH规避命令用于杀死namenode的进程是一个好主意。当使用NFS过滤器实现共享编辑日志时，无法做到同一时间只允许一个namenode写入数据（所以推荐QJM）因此需要更有力的隔离方式。

隔离手段：
撤销namenode访问共享存储目录的权限（通常使用供应商指定的NFS命令）
通过远程管理命令屏蔽响应的网络端口。

终极手段：
通过STONITH（一枪爆头：shoot the other node in the head）的技术进行隔离
该方法主要通过一个特定的供电单元对响应主机进行断电操作。