Hadoop2.0 HA高可用机制

柔光的暖阳◎ 2022-05-28 02:07 217阅读 0赞

单点故障

HDFS：Hadoop1.x版本中单NameNode设计，其单点处理能力成为HDFS的主要瓶颈
    	单点故障、内存受限，制约集群扩展性和缺乏隔离机制（不同业务使用同一个NameNode导致业务相互影响）等
    	因为客户端对HDFS的读、写操作之前都要访问NameNode服务器。存在【单点故障问题】
    	  
    	1.计划内的软件或硬件升级，将导致集群在短时间范围内不可用。
    	2.NameNode出现故障导致集群无法使用，直到重启NameNode或者新启动一个NameNode节点 
    
    YARN：其中ResourceManager作为整个系统的唯一组件，存在【单点故障问题】
    
    MapReduce：目前存在两种MapReduce实现
    	1.可独立运行的MapReduce：
    		由JobTracker和TaskTraker两类服务组成。其中JobTracker存在【单点故障问题】
    		JobTracker完成了太多的任务，造成了过多的资源消耗
    		当 map-reduce job 非常多的时候，会造成很大的内存开销，也增加了JobTracker失效的风险
    	2.MapReduce On YARN：
    		每个作业独立使用一个作业跟踪器（ApplicationMaster）彼此之间不再相互影响，不存在单点故障问题。
    
    
    所以从Hadoop的2.x开始,社区试图使用Federation+HA的方案来解决hadoop-1.x中的容量扩展及可用性的问题

3.5.2 单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的内存使用性价比比较低。

3.5.3 可靠性/可用性/可服务性

RAS是三个词的缩写：起源于IBM对其主机质量的定义。
    	可靠性（Reliability）：一般与安全有关，发生错误后可以进行恢复
    	可用性（Availability）：一般与用户体验有关，通过对不可靠的单节点冗余来换取整体系统的稳定可用。
    	可服务性（Serviceability/Maintainability）
    		用来描述系统出问题时被修复的速度。由于这个时间会影响可用性，所以越快修复则系统可用性越大。
    
    可靠性和可用性在字面上理解感觉很相似，但是有区别的
    系统或许是可用的，但并不一定是可靠的。举例来说，一个系统可能从不宕机，但运行时数据经常发生损坏。
    
    不同系统对二者要求是不同的，例如对那些航空航天产品，可靠性要求就很高，可用性肯定次之，相反对于手机等民用产品可用性要求就比可靠性高些，飞机不可靠的话，道理你懂的。可靠性的增加会显著增加费用，如果手机做成象飞机那么可靠，费用就不是一般高了， 用户肯定也接受不了，再说也没有必要，大不了换个手机，而手机可用性不好会更影响用户情绪。
    
    现在RAS概念被用来评估一个系统，或一个软件层面，单纯强调一个特性没有意义。一个实际的系统应该根据应用场景在RAS和成本方面进行折中。

3.5.3 HA高可用机制

HA（High Availability）概念		
    	高可用性（High Availability）提供了一种最小化网络中由于单点故障而带来的风险的方法。
    	通过尽量缩短因【日常维护操作】和【突发的系统崩溃】所导致的停机时间。以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。HA系统是目前企业防止核心计算机系统因故障停机的最有效手段　　　
    	
    
    HA（High Availability）：高可用机制
    	在Hadoop2.0之前,在HDFS集群中NameNode存在单点故障 (SPOF)。
    	对于只有一个NameNode的集群，如果NameNode机器出现故障(比如宕机或是软件、硬件升级)，
    	HA通过配置Active/Standby两个NameNode实现在集群中对NameNode的热备份来解决上述问题。
    
    HA架构模式：
    	手动模式是指由管理员通过命令进行主备切换，这通常在服务升级时有用
    	自动模式可降低运维成本，但存在潜在危险。
    	
    	
    脑裂现象（brain-split）：
    	脑裂是指在主备切换时，由于切换不彻底或其他原因，导致客户端和DataNode看到两个active NameNode，最终使得整个集群处于混乱状态。那么两个NameNode将会分别有两种不同的数据状态，可能会导致数据丢失或状态异常
    	解决脑裂问题，通常采用隔离(Fencing)机制，包括三个方面：
            1.共享存储fencing：确保只有一个Master往共享存储中写数据。
            2.客户端fencing：确保只有一个Master可以响应客户端的请求。
            3.DataNode fencing：确保只有一个Master可以向DataNode下发命令。

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]

3.5.4 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]

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

[70]: /images/20220528/f0ba611dfbcc431a9042601d06bad24c.png
[70 1]: /images/20220528/a47cfe72d35a40edb600ad2128cb8c4c.png