Hadoop HA机制

太过爱你忘了你带给我的痛 2022-05-28 02:07 189阅读 0赞

## Hadoop1.0版本容易引发单点故障 ##

HDFS：Hadoop1.x版本中单NameNode设计，其单点处理能力成为HDFS的主要瓶颈  
单点故障、内存受限，制约集群扩展性和缺乏隔离机制（不同业务使用同一个NameNode导致业务相互影响）等

因为客户端对HDFS的读、写操作之前都要访问NameNode服务器。存在【单点故障问题】

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

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

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

## 可靠性/可用性/可服务性简介 ##

RAS是三个词的缩写：起源于IBM对其主机质量的定义

1.  可靠性（Reliability）：一般与安全有关，发生错误后可以进行恢复。
2.  可用性（Availability）：一般与用户体验有关，通过对不可靠的单节点冗余来换取整体系统的稳定可用。
3.  可服务性（Serviceability/Maintainability）：用来描述系统出问题时被修复的速度，越快修复则系统可用性越大。

可靠性和可用性在字面上理解感觉很相似，但是有区别：系统或许是可用的，但并不一定是可靠的。举例来说，一个系统可能从不宕机，但运行时数据经常发生损坏。

不同系统对二者要求是不同的，例如对那些航空航天产品，可靠性要求就很高，可用性肯定次之，相反对于手机等民用产品可用性要求就比可靠性高些，飞机不可靠的话，道理你懂的。可靠性的增加会显著增加费用，如果手机做成象飞机那么可靠，费用就不是一般高了， 用户肯定也接受不了，再说也没有必要，大不了换个手机，而手机可用性不好会更影响用户情绪。

## HA高可用机制 ##

在Hadoop2.0之前,在HDFS集群中NameNode存在单点故障 (SPOF)。对于只有一个NameNode的集群，如果NameNode机器出现故障(比如宕机或是软件、硬件升级)，HA通过配置Active/Standby两个NameNode实现在集群中对NameNode的热备份来解决上述问题。

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

**HA （High Availability）机制简介**  
高可用性：提供了一种最小化网络中由于单点故障而带来的风险的方法  
通过尽量缩短因【日常维护操作】和【突发的系统崩溃】所导致的停机时间。以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。HA系统是目前企业防止核心计算机系统因故障停机的最有效手段

在活动namenode失效之后，备用namenode能够快速实现任务结果，因为最新的状态存储在内存中，包括最新的编辑日志条目和最新的数据块映射信息，实际开发环境中观察到的失效时间会略长一些（1分钟左右），这是因为系统需要保守确定活动namenode是否真的失效了。

namenode之间需要通过高可用的共享存储实现编辑日志的共享。当备用namenode接管工作后，它将通读共享编辑日志直至末尾，以实现与活动namenode的状态同步，并继续读取由活动namenode写入的新条目  
DataNode需要同时向两个namenode发送数据块处理报告，因为数据块的映射信息存储在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这些都不需要了

**NFS与QJM**

1.  NFS（Network File System 网络文件系统）  
    NFS作为active namenode和standby namenode之间数据共享的存储。  
    active namenode会把最近的edits文件写到NFS，而standby namenode从NFS中把数据读过来。  
    这个方式的缺点是，如果active或standby有一个和NFS之间网络有问题，则会造成他们之前数据的同步出问题。  
    并且不能保证同一时间只有一个namenode向NFS中写入数据
2.  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的失败。

![这里写图片描述][70]

**failover故障切换**

系统中有一个称谓故障转移控制器（failover controller），管理着将活动namenode转移为备用namenode的转换过程。有多重故障转移控制器，但默认的一种是使用了zookeeper来确保有且仅有一个活动namenode。每一个namenode运行着一个轻量级的故障转移控制器。

其工作就是监视宿主namenode是否失效（通过一个简单的心跳机制实现）并在namenode失效时进行故障转移。管理员也可以手动发起故障转移，例如在日常维护时。

Failover机制

Failover字面意思是失效转移，这是HA的一项简单的容错功能
    在早期简单的HA系统一般是AS(A: Active，S: Standby)双节点结构，即一主一备
    
    两个节点之间通过一个串口或网线作为心跳线互相连接，平时只有Active节点工作
    心跳断了后，主节点不管正不正常，都自动关闭，备份节点自动接管，并且升级为主节点，从而保持系统正常运行。
    当失效节点修好重新集成进来后，仍然保持为从节点。这样的切换过程被称为Failover

**自动failover**

Automatic Failover中，增加了2个新的组件：zookeeper集群，ZKFailoverController进程(简称为ZKFC)。HDFS的自动故障转移主要由Zookeeper和ZKFC两个组件组成。

1、Zookeeper

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将会强制下线

2、ZKFC

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。

![这里写图片描述][70 1]

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

解决脑裂问题，通常采用隔离(Fencing)机制，包括三个方面：

1.  共享存储fencing：确保只有一个Master往共享存储中写数据。
2.  客户端fencing：确保只有一个Master可以响应客户端的请求。
3.  DataNode fencing：确保只有一个Master可以向DataNode下发命令。

**fencing脑裂隔离**

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

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

【同一时间QJM仅允许一个namenode向编辑日志汇总写入数据】【而NFS不能保证】

fencing隔离机制：

1.  共享存储fencing：确保只有一 个Master往共享存储中写数据。
2.  客户端fencing：确保只有一个Master可以响应客户端的请求。
3.  DataNode fencing：确保只有一个Master可以向DataNode下发命令。

隔离手段：

1.  撤销namenode访问共享存储目录的权限（通常使用供应商指定的NFS命令）
2.  通过远程管理命令屏蔽响应的网络端口。
3.  终极手段：  
    通过STONITH（一枪爆头：shoot the other node in the head）的技术进行隔离  
    该方法主要通过一个特定的供电单元对响应主机进行断电操作。

[70]: /images/20220528/8fe5813cada34022b885e61b1ffa135a.png
[70 1]: /images/20220528/dead46d8d5c54a6f94ce211f0ad7bd1c.png