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

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

相关文章
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
255 2
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
11月前
|
监控 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注册中心服务 构建商品
1492 3
|
人工智能 安全 Java
智慧工地源码,Java语言开发,微服务架构,支持分布式和集群部署,多端覆盖
智慧工地是“互联网+建筑工地”的创新模式,基于物联网、移动互联网、BIM、大数据、人工智能等技术,实现对施工现场人员、设备、材料、安全等环节的智能化管理。其解决方案涵盖数据大屏、移动APP和PC管理端,采用高性能Java微服务架构,支持分布式与集群部署,结合Redis、消息队列等技术确保系统稳定高效。通过大数据驱动决策、物联网实时监测预警及AI智能视频监控,消除数据孤岛,提升项目可控性与安全性。智慧工地提供专家级远程管理服务,助力施工质量和安全管理升级,同时依托可扩展平台、多端应用和丰富设备接口,满足多样化需求,推动建筑行业数字化转型。
465 5
|
9月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
9月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
623 1
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
638 61
|
10月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的&quot;神经网络&quot;,强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
4102 57
|
机器学习/深度学习 数据采集 算法
大数据加持的预测性维护:让设备故障“未卜先知”
大数据加持的预测性维护:让设备故障“未卜先知”
737 2
|
并行计算 PyTorch 算法框架/工具
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
本文探讨了如何通过技术手段混合使用AMD与NVIDIA GPU集群以支持PyTorch分布式训练。面对CUDA与ROCm框架互操作性不足的问题,文章提出利用UCC和UCX等统一通信框架实现高效数据传输,并在异构Kubernetes集群中部署任务。通过解决轻度与强度异构环境下的挑战,如计算能力不平衡、内存容量差异及通信性能优化,文章展示了如何无需重构代码即可充分利用异构硬件资源。尽管存在RDMA验证不足、通信性能次优等局限性,但该方案为最大化GPU资源利用率、降低供应商锁定提供了可行路径。源代码已公开,供读者参考实践。
1491 3
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践