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

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生网关 MSE Higress,422元/月
简介: 本文梳理了常见的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

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

相关实践学习
lindorm多模间数据无缝流转
展现了Lindorm多模融合能力——用kafka API写入,无缝流转在各引擎内进行数据存储和计算的实验。
云数据库HBase版使用教程
&nbsp; 相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情:&nbsp;https://cn.aliyun.com/product/hbase &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
29天前
|
监控 网络协议 Nacos
Nacos:构建微服务架构的基石
Nacos:构建微服务架构的基石
85 2
|
1月前
|
前端开发 JavaScript 测试技术
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
31 3
|
10天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
130 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
1月前
|
运维 负载均衡 Shell
控制员工上网软件:高可用架构的构建方法
本文介绍了构建控制员工上网软件的高可用架构的方法,包括负载均衡、数据备份与恢复、故障检测与自动切换等关键机制,以确保企业网络管理系统的稳定运行。通过具体代码示例,展示了如何实现这些机制。
122 63
|
4天前
|
Serverless 决策智能 UED
构建全天候自动化智能导购助手:从部署者的视角审视Multi-Agent架构解决方案
在构建基于多代理系统(Multi-Agent System, MAS)的智能导购助手过程中,作为部署者,我体验到了从初步接触到深入理解再到实际应用的一系列步骤。整个部署过程得到了充分的引导和支持,文档详尽全面,使得部署顺利完成,未遇到明显的报错或异常情况。尽管初次尝试时对某些复杂配置环节需反复确认,但整体流程顺畅。
|
13天前
|
缓存 Kubernetes 容灾
如何基于服务网格构建高可用架构
分享如何利用服务网格构建更强更全面的高可用架构
|
22天前
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
21天前
|
负载均衡 Java 开发者
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
64 5
|
18天前
|
监控 安全 持续交付
构建高效微服务架构:策略与实践####
在数字化转型的浪潮中,微服务架构凭借其高度解耦、灵活扩展和易于维护的特点,成为现代企业应用开发的首选。本文深入探讨了构建高效微服务架构的关键策略与实战经验,从服务拆分的艺术到通信机制的选择,再到容器化部署与持续集成/持续部署(CI/CD)的实践,旨在为开发者提供一套全面的微服务设计与实现指南。通过具体案例分析,揭示如何避免常见陷阱,优化系统性能,确保系统的高可用性与可扩展性,助力企业在复杂多变的市场环境中保持竞争力。 ####
35 2
|
19天前
|
弹性计算 Kubernetes API
构建高效后端服务:微服务架构的深度剖析与实践####
本文深入探讨了微服务架构的核心理念、设计原则及实现策略,旨在为开发者提供一套系统化的方法论,助力其构建灵活、可扩展且易于维护的后端服务体系。通过案例分析与实战经验分享,揭示了微服务在提升开发效率、优化资源利用及增强系统稳定性方面的关键作用。文章首先概述了微服务架构的基本概念,随后详细阐述了其在后端开发中的应用优势与面临的挑战,最后结合具体实例,展示了如何从零开始规划并实施一个基于微服务的后端项目。 ####
下一篇
DataWorks