大数据---7.高可用介绍

学无止境的大象

于 2021-08-18 19:08:03 发布

阅读量1k

点赞数 1

分类专栏： # 大数据文章标签：大数据分布式 hadoop zookeeper big data

本文链接：https://blog.csdn.net/u014579001/article/details/119786959

版权

大数据专栏收录该内容

29 篇文章 7 订阅

订阅专栏

大数据技术—HA 高可用

高可用性H.A.（High Availability）指的是通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。HA系统是企业防止核心计算机系统因故障停机的最有效手段。

高可用程序的类型

主从方式(冷备)

两个相同的应用程序,一个对外提供服务,成为主程序,另一个平时不运行为备程序,就是一个主程序的备份,一旦主程序出现问题,备份提供恢复操作

双主互备(热备)

两个相同的应用程序,同时对外提供服务(两个程序相互为对方备份的存在,双主热备),当启动一个出现问题时,另一个可以对外提供服务,不会造成服务器宕机

HDFS HA高可用（主要针对的是hdfs数据存储的高可用；解决单点故障问题）

1.1 HA概述

1）所谓HA（High Available），即高可用（7*24小时不中断服务）。

2）实现高可用最关键的策略是消除单点故障。HA严格来说应该分成各个组件的HA机制：HDFS的HA和YARN的HA。

3）Hadoop2.0之前，在HDFS集群中NameNode存在单点故障（SPOF）。

4）NameNode主要在以下两个方面影响HDFS集群

NameNode机器发生意外，如宕机，集群将无法使用，直到管理员重启

NameNode机器需要升级，包括软件、硬件升级，此时集群也将无法使用

HDFS HA功能通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode很快的切换到另外一台机器。

1.2 HDFS-HA工作机制

通过双NameNode消除单点故障；

1.2.1 hadoop1.x和hadoop2 .x的区别

hadoop1.x版本:
SecondaryNameNode他不是HA,他只是用来阶段性合并edits和fsimage以及缩短集群启动是啊金所使用,默认是1小时进行一次整合,当NN失效的时候,SNN并无法立即提供服务,SNN是无法保证数据完整性

hadoop2.x

2.x版本中，HDFS架构解决了单点故障问题，即引入双NameNode架构，同时借助共享存储系统来进行元数据的同步，共享存储系统类型一般有几类，如：Shared NAS+NFS、BookKeeper、BackupNode 和 Quorum Journal Manager(QJM)，上图中用的是QJM作为共享存储组件，通过搭建奇数结点的JournalNode实现主备NameNode元数据操作信息同步。

提供了JQM系统来解决当前NameNode的单点故障问题
1.QJM的基本原理是基于2N+1每次需要对数据进行操作需要完成一个过半机制会返回成功,数据不会丢失
2.在HA框架中SNN这个冷备已经不存在了,为了保持standbyNN实时的和ActiveNN的数据保持一致,他们会开启一个进程

实时监控JN(JournalNode)
3,任何更改操作在ActiveNN上执行,JN进程同时记录并会修改log
这是StandbyNN检测JN终有数据同步log发生变化,就会同步当前数据
4,当发生故障的时候,ActiveNN挂了,StandbyNN会提升成为新的ActiveNN
读取会签JN里面修改的日志,这样就提供了可靠性
5.Quorum Journal Manager(JQM)技术

JQM作为共享存储组件，通过搭建奇数结点的JournalNode实现主备NameNode元数据操作信息同步。

5.1不需要配置额外的高共享存储,减少复杂度和成本
5,2系统健壮性得到了增强
5.3JN不会疑问启动一台延迟而影响整体,亦不会因为JN增多而影响性能

后期的部署不再是我们每个进行部署：

CDH是Cloudera的100％开放源代码平台发行版，包括Apache Hadoop，是专门为满足企业需求而构建的。CDH可立即提供企业使用所需的一切。通过将Hadoop与十几个其他关键的开源项目集成在一起，Cloudera创建了功能先进的系统，可以帮助您执行端到端的大数据工作流程。

1.2 Hadoop 2.x元数据

Hadoop的元数据主要作用是维护HDFS文件系统中文件和目录相关信息

元数据的存储形式主要有3类：内存镜像、磁盘镜像(FSImage)、日志(EditLog)。

(1) 在Namenode启动时，会加载磁盘镜像到内存中以进行元数据的管理，存储在NameNode内存；

(2) 磁盘镜像是某一时刻HDFS的元数据信息的快照，包含所有相关Datanode节点文件块映射关系和命名空间(Namespace)信息，存储在NameNode本地文件系统；

(3) 日志文件记录client发起的每一次操作信息，即保存所有对文件系统的修改操作，用于定期和磁盘镜像合并成最新镜像，保证NameNode元数据信息的完整，存储在NameNode本地和共享存储系统(QJM)中。

(4) 如下所示为NameNode本地的EditLog和FSImage文件格式，EditLog文件有两种状态： inprocess和finalized, inprocess表示正在写的日志文件，文件名形式:editsinprocess[start-txid]

(5) finalized表示已经写完的日志文件,文件名形式：edits*[start-txid]*[end-txid]； FSImage文件也有两种状态, finalized和checkpoint， finalized表示已经持久化磁盘的文件，文件名形式: fsimage_[end-txid], checkpoint表示合并中的fsimage

(6) 2.x版本checkpoint过程在Standby Namenode(SNN)上进行，SNN会定期将本地FSImage和从QJM上拉回的ANN的EditLog进行合并，合并完后再通过RPC传回ANN。

data/hbase/runtime/namespace
├── current
│ ├── VERSION
│ ├── edits_0000000003619794209-0000000003619813881
│ ├── edits_0000000003619813882-0000000003619831665
│ ├── edits_0000000003619831666-0000000003619852153
│ ├── edits_0000000003619852154-0000000003619871027
│ ├── edits_0000000003619871028-0000000003619880765
│ ├── edits_0000000003619880766-0000000003620060869
│ ├── edits_inprogress_0000000003620060870
│ ├── fsimage_0000000003618370058
│ ├── fsimage_0000000003618370058.md5
│ ├── fsimage_0000000003620060869
│ ├── fsimage_0000000003620060869.md5
│ └── seen_txid
└── in_use.lock

(7) 上面所示的还有一个很重要的文件就是seen_txid,保存的是一个事务ID，这个事务ID是EditLog最新的一个结束事务id，当NameNode重启时，会顺序遍历从edits_0000000000000000001到seen_txid所记录的txid所在的日志文件，进行元数据恢复，如果该文件丢失或记录的事务ID有问题，会造成数据块信息的丢失。

(8) HA其本质上就是要保证主备NN元数据是保持一致的，即保证fsimage和editlog在备NN上也是完整的。元数据的同步很大程度取决于EditLog的同步，而这步骤的关键就是共享文件系统，下面开始介绍一下关于QJM共享存储机制。