Hadoop高可用集群原理

最新推荐文章于 2024-07-21 22:44:45 发布

Herb6876

最新推荐文章于 2024-07-21 22:44:45 发布

阅读量2k

点赞数 2

本文链接：https://blog.csdn.net/weixin_43557605/article/details/106731760

版权

大数据专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1. Hadoop是什么

Hadoop 是一个开源软件框架，用于在商用硬件集群上存储数据和运行应用程序。它为任何类型的数据提供海量存储，巨大的处理能力以及处理几乎无限的并发任务或作业的能力。

像IT圈的其他服务一样 Hadoop也有自己的吉祥物，是一个黄色小象如下
在这里插入图片描述

2. Hadoop的特点和组件

2.1 优点和缺点

Hadoop的优点

Hadoop通过可用的计算机集群分配数据，完成存储和计算任务，这些集群可以方便地扩展到数以千计的节点中，具有高扩展性。
Hadoop能够在节点之间进行动态地移动数据，并保证各个节点的动态平衡，处理速度非常快，具有高效性。
Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配，具有高容错性。

Hadoop的缺点

Hadoop不适用于低延迟数据访问。
Hadoop不能高效存储大量小文件。
Hadoop不支持多用户写入并任意修改文件。

2.2 Hadoop组件

Hadoop Common：为其他Hadoop模块提供基础设施。
HDFS：具有高可靠性、高吞吐量的分布式文件系统。
MapReduce：基于Yarn系统，分布式离线并行计算框架。
Yarn：负责作业调度与集群资源管理的框架

在这里插入图片描述

HDFS组件说明

如下是HDFS架构图包含3种节点,NameNode(NN),secondary NameNode(SNN),DataNode(DN)
在这里插入图片描述

NN节点功能和特点

接收客户端的读写请求,NN中保存文件的metadata数据，包括除文件内容外的文件信息，文件包含哪些block、Block保存在哪个DN上。

NN中的metadata信息在启动后会加载到内存,metadata存储在磁盘的文件名为fsimage,block的位置信息不会保存到fsimage,edits记录对metadata的操作日志.比如有一个插入文件的操作,hadoop不会直接修改fsimage,而是记录到edits日志记录文件中,但是NN内存中的数据是实时修改的.隔断时间后会合并edits和fsimage,生成新的fsimage,edits的机制和关系型数据库事务的预提交是一样的机制.

SNN节点功能

它的主要工作是帮助NN合并edits log,减少NN启动时间,另一方面合并会有大量的IO操作,但是NN最主要的作用是接收用户的读写服务的,所以大量的资源不能用来干这个。SNN它不是NN的备份,但可以做一部分的元数据备份,不是实时备份

SNN的合并流程如下
在这里插入图片描述
满足合并时机后(合并时机:配置设置时间间隔fs.checkpoint.period,默认3600秒;或者配置edit log大小,最大64M),SNN会拷贝NN的edits日志记录文件和fsimage元数据文件到SNN中,可能会跨网络拷贝,这时同时NN会创建一个新的edits文件来记录用户的读写请求操作,然后SNN就会进行合并为一个新的fsimage文件,然后SNN会把这个文件推送给NN,最后NN会用新的fsimage替换旧的fsimage,然后如此反复…

SNN节点合并edits log的必要性：

当NameNode启动的时候,首先装载fsimage文件,然后再应用edits文件,最后还会将最新的目录树信息到新的fsimage文件中,然后启用新的edits文件.如果NameNode在启动后发生的改变过多,会导致edit文件变得非常大,大得程度与NameNode的更新频率有关系.那么在下一次NameNode启动的过程中,读取了fsimage文件后,会应用这个无比大的edits文件,导致启动时间变长,并且不可能控,可能需要启动几个小时.NameNode的edits文件过大的问题,就是SecondeNameNode要解决的主要问题.

DN节点功能

存储数据
启动DN线程的时候向NN汇报block信息
通过向NN发送心跳保持与其联系,如果NN10分钟没有收到DN心跳,则认为其lost,并copy其上的block到其它DN

3. Hadoop高可用原理

这里我们先上图下边是Hadoop2 高可用集群的架构图图中有一些新组件功能如下
在这里插入图片描述
JournalNode
提供一个简易的RPC接口，供NameNode读写EditLog到JN本地磁盘

Zookeeper集群
提供集群信息同步和NameNode失败切换

3.1 JournalNode和QJM

HA其本质上就是要保证主备NN元数据是保持一致的，即保证fsimage和editlog在备NN上也是完整的。元数据的同步很大程度取决于EditLog的同步，QJM可以做好元数据在各NamenNode之间的同步

QJM全称是Quorum Journal Manager, 由JournalNode（JN）组成，一般是奇数点节点组成。每个JournalNode对外有一个简易的RPC接口，以供NameNode读写EditLog到JN本地磁盘。当写EditLog时，NameNode会同时向所有JournalNode并行写文件，只要有N/2+1节点写成功则认为此次写操作成功。其内部实现框架如下：

在这里插入图片描述
上图中各个部分的功能

FSEditLog：所有EditLog操作的入口
JournalSet: 集成本地磁盘和JournalNode集群上EditLog的相关操作
FileJournalManager: 实现本地磁盘上 EditLog 操作
QuorumJournalManager: 实现JournalNode 集群EditLog操作
AsyncLoggerSet: 实现JournalNode 集群 EditLog 的写操作集合
AsyncLogger：发起RPC请求到JN，执行具体的日志同步功能
JournalNodeRpcServer：运行在 JournalNode 节点进程中的 RPC 服务，接收 NameNode 端的 AsyncLogger 的 RPC 请求。
JournalNodeHttpServer：运行在 JournalNode 节点进程中的 Http 服务，用于接收处于 Standby 状态的 NameNode 和其它 JournalNode 的同步 EditLog 文件流的请求。

QJM实现并发写入的大致流程：
NN通过JournalSet 在将元数据写入本地的同时想QJM发送信号 QJM接收到信号后会将并发写的请求交给AsyncLoggerSet 并由它调用AsyncLogger 发起RPC请求到JN 各个JN的JournalNodeRpcServer接收到rpc请求后进行数据的写入

总结： Hadoop的高可用核心在于主备NameNode的元数据一致，而QJM机制的出现，可以让NameNode借助于JournalNode实现editslog的并发写入和同步，元数据相同，失败切换后集群数据不会有任何损失

3.2 主备切换机制

上边说了HA的核心所在和流程除了元数据同步外，还得有一个完备的主备切换机制，Hadoop的主备选举依赖于ZooKeeper。

下面是主备切换的状态图

在这里插入图片描述

这个图里又增加了一个新成员ZKFC 其实就是zookeeper failover controller 翻译成中文就是zookeeper 失败切换控制器
另外 ANN SNN 其实就是active NameNode / secondary NameNode 主和备NameNode

ZKFC的组件和作用

ZKFailoverController: 是HealthMontior和ActiveStandbyElector的母体，执行具体的切换操作
HealthMonitor: 监控NameNode健康状态，若状态异常会触发回调ZKFailoverController进行自动主备切换
ActiveStandbyElector: 通知ZK执行主备选举，若ZK完成变更，会回调ZKFailoverController相应方法进行主备状态切换

在故障切换期间，ZooKeeper的作用：

失败保护：集群中每一个NameNode都会在ZooKeeper维护一个持久的session,机器一旦挂掉，session就会过期，故障迁移就会触发
Active NameNode选择：ZooKeeper有一个选择ActiveNN的机制，一旦现有的ANN宕机，其他NameNode可以向ZooKeeper申请排他成为下一个Active节点
防脑裂： ZK本身是强一致和高可用的，可以用它来保证同一时刻只有一个活动节点

会发生自动切换的场景：

ANN JVM崩溃：ANN上HealthMonitor状态上报会有连接超时异常，HealthMonitor会触发状态迁移至SERVICE_NOT_RESPONDING, 然后ANN上的ZKFC会退出选举，SNN上的ZKFC会获得Active Lock, 作相应隔离后成为Active节点。
ActiveNN JVM冻结：这个是JVM没崩溃，但也无法响应，同崩溃一样，会触发自动切换。
ActiveNN 机器宕机：此时ActiveStandbyElector会失去同ZK的心跳，会话超时，SNN上的ZKFC会通知ZK删除ANN的活动锁，作相应隔离后完成主备切换。
ActiveNN 健康状态异常：此时HealthMonitor会收到一个HealthCheckFailedException，并触发自动切换。
Active ZKFC崩溃：虽然ZKFC是一个独立的进程，但因设计简单也容易出问题，一旦ZKFC进程挂掉，虽然此时NameNode是OK的，但系统也认为需要切换，此时SNN会发一个请求到ANN要求ANN放弃主节点位置，ANN收到请求后，会触发完成自动切换。
ZooKeeper崩溃：如果ZK崩溃了，主备NN上的ZKFC都会感知断连，此时主备NN会进入一个NeutralMode模式，同时不改变主备NN的状态，继续发挥作用，只不过此时，如果ANN也故障了，那集群无法发挥Failover, 也就不可用了，所以对于此种场景，ZK一般是不允许挂掉到多台，至少要有N/2+1台保持服务才算是安全的，这也是使用zookeeper集群的原因。