大数据分布式架构单点故障详解(Hdfs+Yarn+HBase+Spark+Storm)构建HA高可用架构

简介: 本文梳理了常见的hadoop生态圈中的组件:Hdfs+Yarn+HBase+Spark+Storm的单点故障问题,出现原因以及单点故障的原理和解决方案(构建HA(High Available)高可用架构)。阅读本文之前,最好了解清楚各组件的架构原理。

本文来源于公众号【胖滚猪学编程】,转载请注明出处。

本文整合梳理了主流大数据生态圈中的组件:Hdfs+Yarn+HBase+Spark+Storm的单点故障问题的解决方案:构建HA(High Available)高可用架构。阅读本文之前,最好需要了解清楚各组件的架构原理。

单点故障的出现原因

首先一张图来了解下这些组件的架构:_1

我们可以发现:它们的共同特点就是都是主从结构。HDFS中的NameNode,Yarn中ResourceManager,Hbase中HMaster,Spark中Master,Storm中Nimbus起着“老大”的角色,那么“老大”挂了怎么办呢?这可就麻烦了,只要老大挂了,等于整个集群的服务都用不了了,NameNode挂了整个集群的HDFS就用不了了,HBase的HMaster挂了整个集群的Hbase都用不了了,等等。这就是所谓的单点故障问题。单点指只有一个主节点

单点故障的解决方案

既然只有一个主节点就会发生单点故障,那么我们很容易可以想到,我来两个不就行了!对的,HA的思想就是多弄几个主节点,一个死了另一个上。但这样也不够啊!必须有个东西能够使得发生故障的时候自动切换啊!这东西就是Zookeeper。所以有了下面这张图:_2

由于这些组件的HA原理类似,我们只以最难的HDFS的HA高可用架构原理为例讲解。而其他组件,不讲解原理,只上配置文件。

Zookeeper在HA架构中的作用

Zookeeper是一个开源的分布式协调服务,分布式应用程序可以基于ZooKeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。
ZK在Hadoop生态圈中的主要功能有:

  • 选举功能,比如HDFS中Active NameNode的选举、YARN中Active ResourceManager的选举和HBase中Active HMaster的选举。
  • ZooKeeper具有在各个节点同步数据的功能,能保证高度的一致性,因此它能够保证在任何时候只有一个节点为Active。
  • ZooKeeper分布式协调/通知功能,可用于心跳检测,不同进程之间需要检测到彼此是否在正常运行,比如HDFS中NameNode需要知道DataNode是否正常。基本原理是创建一个临时znode,如果连接超时就删除这个节点,不同的进程直接可以根据这个临时子节点来判断对应的进程是否存活。

HDFS基于Zookeeper的HA高可用架构原理

HDFS预备知识:

namenode职责
(1)负责客户端的请求和响应
(2)负责元数据的管理(查询,修改。。)
(3)维护元信息(fsimage文件),fsimage是磁盘元数据镜像文件,存储元数据信息。
(4)维护操作日志(edits文件),edits是数据操作日志文件,当客户端操作文件的时候,操作记录首先会被记录到edits日志文件中。
我们可以在$dfs.namenode.name.dir/current目录下看到如下的文件结构
image

出现HA之后,(3)和(4)交给了另一个叫做JournalNode的东东。JournalNode在HA故障转移中起到了重要的作用!

HDFA HA原理图解

_

  • 在两个NN(NameNode简写,下同)间选举出一个Active NN,Active NN会在ZK上创建临时节点Znode
  • 两个NN都会向ZK发送心跳检测信息,让ZK实时知道它们的状态。
  • 任何修改操作在 Active NN上执行时,JN进程同时也会记录修改log到至少半数以上的JN中,这时 Standby NN 监测到JN 里面的同步log发生变化了会读取 JN 里面的修改log,然后同步到自己的的目录镜像树里面。
  • Active NN挂了之后,连接超时,ZK收不到心跳信息了,就把对应的临时znode进行删除,znode的删除事件会主动触发到下一次的Active NamNode的选择。
  • 原来的StandbyNN准备要上位了,它会在成为Active NN 前,读取所有的JN里面的日志,这样就能高可靠的保证与挂掉的NN的目录镜像树一致,然后无缝的接替它的职责,维护来自客户端请求,从而达到一个高可用的目的。
    注:故障切换是通过ZKFC(FailOverController)完成。

HDFS的HA高可用架构配置

  • core-site.xml
<configuration>
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://mycluster</value>
    </property>
    <property>
        <name>hadoop.tmp.dir</name>
        <value>/usr/local/hadoop-2.6.0-cdh5.11.1/data/tmp</value>
    </property>
    <property>
        <name>hadoop.http.staticuser.user</name>
        <value>master</value>
    </property>
    <property>
        <name>ha.zookeeper.quorum</name>
        <value>master:2181,slave1:2181,slave2:2181</value>
    </property>
</configuration>
  • hdfs-site.xml
<configuration>
    <property>
        <name>dfs.replication</name>
        <value>2</value>
    </property>
    <property>
        <name>dfs.http.address</name>
        <value>0.0.0.0:50070</value>
    </property>
    <property>
        <name>dfs.permissions.enabled</name>
        <value>false</value>
    </property>
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>/usr/local/hadoop-2.6.0-cdh5.11.1/data/tmp/dfs/name</value>
    </property>
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>/usr/local/hadoop-2.6.0-cdh5.11.1/data/tmp/dfs/data</value>
    </property>
    <!-- service name,the same as core-site.xml-->
    <property>
        <name>dfs.nameservices</name>
        <value>mycluster</value>
    </property>
    <property>
        <name>dfs.ha.namenodes.mycluster</name>
        <value>nn1,nn2</value>
    </property>
    <!-- RPC address-->
    <property>
        <name>dfs.namenode.rpc-address.mycluster.nn1</name>
        <value>master:8020</value>
    </property>
    <property>
        <name>dfs.namenode.rpc-address.mycluster.nn2</name>
        <value>slave1:8020</value>
    </property>
    <!-- http address web service -->
    <property>
        <name>dfs.namenode.http-address.mycluster.nn1</name>
        <value>master:50070</value>
    </property>
    <property>
        <name>dfs.namenode.http-address.mycluster.nn2</name>
        <value>slave1:50070</value>
    </property>
    <!--journalnode dir -->
    <property>
        <name>dfs.namenode.shared.edits.dir</name>
        <value>qjournal://master:8485;slave1:8485;slave2:8485/mycluster</value>
    </property>
    <!--journalnode dir -->
    <property>
        <name>dfs.journalnode.edits.dir</name>
        <value>/usr/local/hadoop-2.6.0-cdh5.11.1/data/jn</value>
    </property>
    <property>
        <name>dfs.client.failover.proxy.provider.mycluster</name>
        <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
    </property>
    <property>
        <name>dfs.ha.fencing.methods</name>
        <value>sshfence</value>
    </property>
    <property>
        <name>dfs.ha.fencing.ssh.private-key-files</name>
        <value>/root/.ssh/id_rsa</value>
    </property>
    <property>
        <name>dfs.ha.automatic-failover.enabled</name>
        <value>true</value>
    </property>
    <property>
        <name>dfs.webhdfs.enabled</name>
        <value>true</value>
    </property>
</configuration>

搭建HDFS HA的步骤

(1)启动zookeeper集群(分别在slave1、slave2和slave3上执行)
zkServer.sh start
(2)格式化ZKFC(在master1上执行)
hdfs zkfc -formatZK
(3)启动journalnode(分别在slave1、slave2和slave3上执行)
sbin/hadoop-daemon.sh start journalnode
(4)格式化HDFS(在master1上执行)
hdfs namenode -format
(5)启动nn1
sbin/hadoop-daemon.sh start namenode
(6)第二个namenode机器同步元数据信息
bin/hdfs namenode -bootstrapStandby
(7)启动nn2
sbin/hadoop-daemon.sh start namenode
(6)启动所有datanode
sbin/hadoop-daemons.sh start datanode
(7)在master机器上先启动zkfc(自动故障转移) 它就变成active了 sbin/hadoop-daemon.sh start zkfc
(8)再在slave1机器上启动zkfc.它就变成standby了

测试自动故障转移

(1)启动服务
image

image

image

(2)kill命令杀死active nn的进程

image
(3)在web UI界面上会发现Standby自动变成了Active

Yarn的HA高可用架构

原理与HDFS的非常类似,也是通过Zookeeper心跳检测,自动切换,非常简单,就是配置一下配置文件。

<configuration>

    <property>
        <name>yarn.resourcemanager.ha.enabled</name>
        <value>true</value>
    </property>
    <property>
        <name>yarn.resourcemanager.cluster-id</name>
        <value>rs</value>
    </property>
    <property>
        <name>yarn.resourcemanager.ha.rm-ids</name>
        <value>rm1,rm2</value>
    </property>
    <property>
        <name>yarn.resourcemanager.hostname.rm1</name>
        <value>master</value>
    </property>
    <property>
        <name>yarn.resourcemanager.hostname.rm2</name>
        <value>slave1</value>
    </property>
    <property>
        <name>yarn.resourcemanager.zk-address</name>
        <value>master:2181,slave1:2181,slave2:2181</value>
    </property>
    <property>
        <name>yarn.resourcemanager.recovery.enabled</name>
        <value>true</value>
    </property>

</configuration>

本文来源于公众号【胖滚猪学编程】,一个集颜值与才华于一身的女程序媛,欢迎关注。

HBase的HA高可用架构

Hbase其实是无单点故障的,你可以手动启动多个HMaster,比如在master机器上启动hbase(bin/start-hbase.sh)之后,可以到slave1机器上也启动master(bin/hbase-daemon.sh start master),无需任何配置。但是手工启动这样有点麻烦,可以通过配置文件,使得每次启动hbase时候自动的帮你启动两个HMaster。
touch backup-masters在此文件上输入你要作为备份HMaster的机器主机名。

image
image

本文来源于公众号【胖滚猪学编程】,一个集颜值与才华于一身的女程序媛,欢迎关注。

Spark的HA高可用架构

Spark同样是用ZooKeeper来实现HA。ZooKeeper提供了一个Leader Election机制,由于ZK的高度一致性,可以保证虽有多个Master但是只有一个是Active的,当Active的Master出现故障时,另外的一个Standby Master会被选举出来。

配置方法

vim conf/spark-env.sh

注释掉原本的SPARK_MASTER_HOST,如果它存在,就会默认只以它为Master。
-Dspark.deploy.recoveryMode: 表明整个集群的恢复和维护都是Zookeeper.
-Dspark.deploy.zookeeper.url: 所有做HA机器,其中端口2181是默认端口。
-Dspark.deploy.zookeeper.dir: 指定Spark在Zookeeper注册的信息

#SPARK_MASTER_HOST=master
export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER -Dspark.deploy.zookeeper.url=master:2181,slave1:2181,slave2:2181 -Dspark.deploy.zookeeper.dir=/spark"

需要将它分发给需要做备份Master的机器。

scp conf/spark-env.sh slave1:/usr/local/spark-2.2.0-bin-hadoop2.6.0-cdh5.11.1/conf/

启动方法

在一台机器上:sbin/start-all.sh

另一台机器上启动第二个Master:sbin/start-master.sh

image

image

image

image

测试故障转移:

image

image

本文来源于公众号【胖滚猪学编程】,转载请注明出处。

相关文章
|
8月前
|
SQL 监控 关系型数据库
MySQL主从复制:构建高可用架构
本文深入解析MySQL主从复制原理与实战配置,涵盖复制架构、监控管理、高可用设计及性能优化,助你构建企业级数据库高可用方案。
|
9月前
|
运维 监控 搜索推荐
MSE ZooKeeper:Flink 高可用架构的企业级选择
本文深入解析了 Apache Flink 架构中 ZooKeeper 的核心作用,包括 Leader 选举、Checkpoint 管理、作业协调及配置管理等关键功能,并结合金融风控与电商推荐等典型场景,分析了 ZooKeeper 在实际应用中的技术实现。
|
11月前
|
人工智能 分布式计算 大数据
大数据≠大样本:基于Spark的特征降维实战(提升10倍训练效率)
本文探讨了大数据场景下降维的核心问题与解决方案,重点分析了“维度灾难”对模型性能的影响及特征冗余的陷阱。通过数学证明与实际案例,揭示高维空间中样本稀疏性问题,并提出基于Spark的分布式降维技术选型与优化策略。文章详细展示了PCA在亿级用户画像中的应用,包括数据准备、核心实现与效果评估,同时深入探讨了协方差矩阵计算与特征值分解的并行优化方法。此外,还介绍了动态维度调整、非线性特征处理及降维与其他AI技术的协同效应,为生产环境提供了最佳实践指南。最终总结出降维的本质与工程实践原则,展望未来发展方向。
619 0
|
7月前
|
运维 监控 安全
公链开发中的高可用架构设计要点
本指南提供公链高可用架构的可复用流程与模板,涵盖目标拆解、先决条件、分步执行、故障排查及验收标准,结合跨链DApp与量化机器人案例,提升落地效率与系统稳定性。
|
8月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
3833 57
|
存储 分布式计算 Hadoop
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
711 79
|
10月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
414 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
消息中间件 存储 设计模式
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
3527 21
RocketMQ原理—5.高可用+高并发+高性能架构

热门文章

最新文章