大数据分布式架构单点故障详解(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

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

相关文章
|
4月前
|
SQL 监控 关系型数据库
MySQL主从复制:构建高可用架构
本文深入解析MySQL主从复制原理与实战配置,涵盖复制架构、监控管理、高可用设计及性能优化,助你构建企业级数据库高可用方案。
|
4月前
|
数据采集 运维 监控
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
|
5月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
878 3
|
6月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
4月前
|
人工智能 监控 测试技术
告别只会写提示词:构建生产级LLM系统的完整架构图​
本文系统梳理了从提示词到生产级LLM产品的八大核心能力:提示词工程、上下文工程、微调、RAG、智能体开发、部署、优化与可观测性,助你构建可落地、可迭代的AI产品体系。
620 51
|
6月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
641 0
|
3月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
4月前
|
机器学习/深度学习 人工智能 搜索推荐
从零构建短视频推荐系统:双塔算法架构解析与代码实现
短视频推荐看似“读心”,实则依赖双塔推荐系统:用户塔与物品塔分别将行为与内容编码为向量,通过相似度匹配实现精准推送。本文解析其架构原理、技术实现与工程挑战,揭秘抖音等平台如何用AI抓住你的注意力。
978 7
从零构建短视频推荐系统:双塔算法架构解析与代码实现
|
7月前
|
存储 SQL 分布式计算
19章构建企业级大数据平台:从架构设计到数据治理的完整链路
开源社区: 贡献者路径:从提交Issue到成为Committer 会议演讲:通过DataWorks Summit提升影响力 标准制定: 白皮书撰写:通过DAMA数据治理框架认证 专利布局:通过架构设计专利构建技术壁垒
|
3月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
335 1

热门文章

最新文章