HDFS High Availability（HA）高可用

1.1 High Availability背景知识

1.1.1 单点故障、高可用

单点故障（英语：single point of failure，缩写SPOF）是指系统中某一点一旦失效，就会让整个系统无法运作，换句话说，单点故障即会整体故障。

高可用性（英语：high availability，缩写为 HA），IT术语，指系统无中断地执行其功能的能力，代表系统的可用性程度。是进行系统设计时的准则之一。高可用性系统意味着系统服务可以更长时间运行，通常通过提高系统的容错能力来实现。

高可用性或者高可靠度的系统不会希望有单点故障造成整体故障的情形。一般可以透过冗余的方式增加多个相同机能的部件，只要这些部件没有同时失效，系统（或至少部分系统）仍可运作，这会让可靠度提高。

1.1.2 高可用如何实现

1.1.2.1 主备集群

解决单点故障，实现系统服务高可用的核心并不是让故障永不发生，而是让故障的发生对业务的影响降到最小。因为软硬件故障是难以避免的问题。

当下企业中成熟的做法就是给单点故障的位置设置备份，形成主备架构。通俗描述就是当主挂掉，备份顶上，短暂的中断之后继续提供服务。

常见的是一主一备架构，当然也可以一主多备。备份越多，容错能力越强，与此同时，冗余也越大，浪费资源。

1.1.2.2 Active、Standby

Active：主角色。活跃的角色，代表正在对外提供服务的角色服务。任意时间有且只有一个active对外提供服务。

Standby：备份角色。需要和主角色保持数据、状态同步，并且时刻准备切换成主角色（当主角色挂掉或者出现故障时），对外提供服务，保持服务的可用性。

1.1.3 可用性评判标准—x个9

在系统的高可用性里有个衡量其可靠性的标准——X****个9，这个X是代表数字3-5。X个9表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比。

Ø 3****个9：(1-99.9%)36524=8.76小时，表示该系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。
Ø 4****个9：(1-99.99%)36524=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
Ø 5****个9：(1-99.999%)36524*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。

可以看出，9越多，系统的可靠性越强，能够容忍的业务中断时间越少，但是要付出的成本更高。

1.1.4 HA系统设计核心问题

1.1.4.1 脑裂问题

脑裂(split-brain)是指“大脑分裂”,本是医学名词。在HA集群中，脑裂指的是当联系主备节点的"心跳线"断开时(即两个节点断开联系时)，本来为一个整体、动作协调的HA系统，就分裂成为两个独立的节点。由于相互失去了联系，主备节点之间像"裂脑人"一样，使得整个集群处于混乱状态。脑裂的严重后果：

1）集群无主：都认为对方是状态好的，自己是备份角色，后果是无服务；

2）集群多主：都认为对方是故障的，自己是主角色。相互争抢共享资源，结果会导致系统混乱，数据损坏。此外对于客户端访问也是一头雾水，找谁呢？

避免脑裂问题的核心是：保持任意时刻系统有且只有一个主角色提供服务。

1.1.4.2 数据同步问题

主备切换保证服务持续可用性的前提是主备节点之间的状态、数据是一致的，或者说准一致的。如果说备用的节点和主节点之间的数据差距过大，即使完成了主备切换的动作，那也是没有意义的。

数据同步常见做法是：通过日志重演操作记录。主角色正常提供服务，发生的事务性操作通过日志记录，备用角色读取日志重演操作。

HDFS NAMENODE单点故障问题

在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。每个群集只有一个NameNode，如果该计算机或进程不可用，则整个群集在整个NameNode重新启动或在另一台计算机上启动之前将不可用。

NameNode的单点故障从两个方面影响了HDFS群集的总可用性：

Ø 如果发生意外事件（例如机器崩溃），则在重新启动NameNode之前，群集将不可用。
Ø 计划内的维护事件，例如NameNode计算机上的软件或硬件升级，将导致群集停机时间的延长。

HDFS高可用性解决方案：在同一群集中运行两个（从3.0.0起，超过两个）冗余NameNode。这样可以在机器崩溃的情况下快速故障转移到新的NameNode，或者出于计划维护的目的由管理员发起的正常故障转移。

1.2 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jnFkGaqq-1639055057902)(D:##myFile##learning\A-BIgData\mdfileImgPath\clip_image012.png)]HDFS HA解决方案—QJM

QJM全称Quorum Journal Manager，由cloudera公司提出，是Hadoop官方推荐的HDFS HA解决方案之一。

QJM中，使用zookeeper中ZKFC来实现主备切换；使用Journal Node（JN）集群实现edits log的共享以达到数据同步的目的。

1.2.1 QJM—主备切换、脑裂问题解决

1.2.1.1 ZKFailoverController（zkfc）

Apache ZooKeeper是一款高可用分布式协调服务软件，用于维护少量的协调数据。 Zookeeper的下列特性功能参与了HDFS的HA解决方案中：

Ø 临时znode

如果一个znode节点是临时的，那么该znode的生命周期将和创建它的客户端的session绑定。客户端断开连接session结束，znode将会被自动删除。

Ø Path路径唯一性

zookeeper中维持了一份类似目录树的数据结构。每个节点称之为Znode。Znode具有唯一性，不会重名。也可以理解为排他性。

Ø 监听机制

客户端可以针对znode上发生的事件设置监听，当事件发生触发条件，zk服务会把事件通知给设置监听的客户端。

ZKFailoverController（ZKFC）是一个新组件，它是一个ZooKeeper客户端。运行NameNode的每台计算机也都运行ZKFC，ZKFC的主要职责：

Ø 监视和管理NameNode健康状态

ZKFC通过命令定期ping本地负责监视的NameNode节点。
Ø 维持和ZooKeeper集群联系

如果本地NameNode运行状况良好，并且ZKFC看到当前没有其他节点持有锁znode，它将自己尝试获取该锁。如果成功，则表明它“赢得了选举”，并负责运行故障转移以使其本地NameNode处于Active状态。如果已经有其他节点持有锁，zkfc选举失败，则会对该节点注册监听，等待下次继续选举。

1.2.1.2 Fencing隔离机制

故障转移过程也就是俗称的主备角色切换的过程，切换过程中最怕的就是脑裂的发送。因此需要Fencing机制来避免，将先前的Active节点隔离，然后将本地NameNode转换为Active状态。

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

1.2.2 QJM—主备数据同步问题解决

Journal Node（JN）集群是轻量级分布式系统，主要用于高速读写数据、存储数据。通常使用2N+1**台JournalNode存储共享Edits Log（编辑日志）。

任何修改操作在 Active NN上执行时，JournalNode进程同时也会记录edits log到至少半数以上的JN中，这时 Standby NN 监测到JN 里面的同步log发生变化了会读取JN里面的edits log，然后重演操作记录同步到自己的目录镜像树里面，

当发生故障Active NN挂掉后，Standby NN 会在它成为Active NN 前，读取所有的JN里面的修改日志，这样就能高可靠的保证与挂掉的NN的目录镜像树一致，然后无缝的接替它的职责，维护来自客户端请求，从而达到一个高可用的目的。

同步到自己的目录镜像树里面，