NameNode 高可用整体架构概述

Hadoop1.0时代的HDFS NameNode存在单点故障问题,严重影响了Hadoop的应用场景。Hadoop2.0引入了NameNode高可用机制,通过ActiveNameNode和StandbyNameNode配合Zookeeper集群实现自动主备切换,解决了这一问题。本文详细分析了HDFS NameNode高可用的内部实现机制。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在 Hadoop 1.0 时代,Hadoop 的两大核心组件 HDFS NameNode 和 JobTracker 都存在着单点问题,这其中以 NameNode 的单点问题尤为严重。

因为 NameNode 保存了整个 HDFS 的元数据信息,一旦 NameNode 挂掉,整个 HDFS 就无法访问,同时 Hadoop 生态系统中依赖于 HDFS 的各个组件,包括 MapReduce、Hive、Pig 以及 HBase等也都无法正常工作,并且重新启动 NameNode 和进行数据恢复的过程也会比较耗时。

这些问题在给 Hadoop 的使用者带来困扰的同时,也极大地限制了 Hadoop 的使用场景,使得 Hadoop 在很长的时间内仅能用作离线存储和离线计算,

无法应用到对可用性和数据一致性要求很高的在线应用场景中。

所幸的是,在 Hadoop2.0 中,HDFS NameNode 和 YARN ResourceManger(JobTracker 在 2.0 中已经被整合到 YARN ResourceManger 之中) 的单点问题都得到了解决,经过多个版本的迭代和发展,目前已经能用于生产环境。HDFS NameNode 和 YARN ResourceManger 的高可用 (High Availability,HA) 方案基本类似,两者也复用了部分代码,但是由于 HDFS NameNode 对于数据存储和数据一致性的要求比 YARN ResourceManger 高得多,所以 HDFS NameNode 的高可用实现更为复杂一些,本文从内部实现的角度对 HDFS NameNode 的高可用机制进行详细的分析。

这里写图片描述

图 1.HDFS NameNode 高可用整体架构

从上图中,我们可以看出 NameNode 的高可用架构主要分为下面几个部分:

Active NameNode 和 Standby NameNode:两台 NameNode 形成互备,一台处于 Active 状态,为主 NameNode,

另外一台处于 Standby 状态,为备 NameNode,只有主 NameNode 才能对外提供读写服务。备 NameNode 只可以同步主 NameNode 的Editlog与接收 DataNode 的数据块汇报。

主备切换控制器 ZKFailoverController:ZKFailoverController 作为独立的进程运行(运行在 ActiveNameNode 和 StandByNameNode 上),对 NameNode 的主备切换进行总体控制。ZKFailoverController 能及时检测到 NameNode 的健康状况,在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换,当然 NameNode 目前也支持不依赖于 Zookeeper 的手动主备切换(但是在应用中倾向于依赖 Zookeeper 实现自动切换)。

Zookeeper 集群:为主备切换控制器提供主备选举支持。

共享存储系统:共享存储系统是实现 NameNode 的高可用最为关键的部分,共享存储系统保存了 NameNode 在运行过程中所产生的 HDFS 的元数据。主 NameNode 和 NameNode 通过共享存储系统实现元数据同步。在进行主备切换的时候,新的主 NameNode 在确认元数据完全同步之后才能继续对外提供服务。

DataNode 节点:除了通过共享存储系统共享 HDFS 的元数据信息之外,主 NameNode 和备 NameNode 还需要共享 HDFS 的数据块和 DataNode 之间的映射关系。DataNode 会同时向主 NameNode 和备 NameNode 上报数据块的位置信息。

下面开始分别介绍 NameNode 的主备切换实现和共享存储系统的实现,在文章的最后会结合笔者的实践介绍一下在 NameNode 的高可用运维中的一些注意事项。

NameNode 的主备切换实现

NameNode 主备切换主要由 ZKFailoverController、HealthMonitor 和 ActiveStandbyElector 这 3 个组件来协同实现:

ZKFailoverController 作为 NameNode 机器上一个独立的进程启动 (在 hdfs 启动脚本之中的进程名为 zkfc),启动的时候会创建 HealthMonitor 和 ActiveStandbyElector 这两个主要的内部组件,ZKFailoverController 在创建 HealthMonitor 和 ActiveStandbyElector 的同时,
也会向 HealthMonitor 和 ActiveStandbyElector 注册相应的回调方法。

zkfc进行名启动记录:

### Hadoop 高可用分布式集群 (HA) 的配置与实现 #### 1. 背景介绍 Hadoop 是种强大的分布式计算框架,能够高效地存储和处理大规模数据集。然而,默认情况下,Hadoop 存在单点故障问题,尤其是 NameNode 和 ResourceManager 的失效可能导致整个集群无法正常工作。为了提升系统的可靠性和可用性,可以采用高可用架构设计。 通过引入多个冗余节点以及自动化的故障切换机制,可以在节点发生故障时快速切换到用节点,从而保障服务的连续运行[^1]。 --- #### 2. 架构概述 Hadoop 高可用(High Availability, HA)的核心在于解决 NameNode 和 ResourceManager 的单点故障问题: - **NameNode HA**:通过设置个相互独立的 NameNode 实例来提供冗余支持,其中个处于 Active 状态,另个则作为 Standby。 - **ResourceManager HA**:类似于 NameNode,可以通过部署多实例并启用 ZooKeeper 协调器来进行状态管理。 这种双活模式依赖于共享存储系统(如 JournalNodes 或 NFS),以便同步元数据信息,并利用 ZooKeeper 来协调活动节点的状态转换[^2]。 --- #### 3. 要组件及其功能 以下是构建 Hadoop HA 所需的关键组件及作用说明: - **JournalNodes**:负责记录 NameNode 对命名空间所做的修改操作日志,确保NameNode 数据致性。 - **ZooKeeper Quorum**:充当仲裁者角色,在检测到当前活跃节点失败后触发选举过程选出新的领导者。 - **Failover Controller**:执行手动或自动化方式下的切换逻辑控制流程。 这些模块共同协作完成无缝衔接的任务调度和服务恢复目标。 --- #### 4. 具体实施步骤 以下是搭建 Hadoop HA 分布式集群的要技术要点: ##### (1)环境准 确保所有参与节点之间具无密码 SSH 登录权限,并将最新版本的 hadoop 安装包复制分发给各个子节点机器上[^3]。 ##### (2)编辑核心配置文件 需要调整如下几个重要参数项以适应新需求场景的要求: ###### a. hdfs-site.xml 文件更新 定义关于 namenode 地址及相关属性值设定部分代码片段展示如下所示: ```xml <property> <name>dfs.nameservices</name> <value>mynameservice</value> </property> <!-- 设置 name node id --> <property> <name>dfs.ha.namenodes.mynameservice</name> <value>nn1,nn2</value> </property> <!-- nn1 rpc地址 --> <property> <name>dfs.namenode.rpc-address.mynameservice.nn1</name> <value>namenode1:8020</value> </property> <!-- nn2 rpc地址 --> <property> <name>dfs.namenode.rpc-address.mynameservice.nn2</name> <value>namenode2:8020</value> </property> <!-- 指定 journalnode 列表 --> <property> <name>dfs.namenode.shared.edits.dir</name> <value>qjournal://jn1:8485;jn2:8485;jn3:8485/mynameservice</value> </property> <!-- 开启 ha 功能开关 --> <property> <name>dfs.client.failover.proxy.provider.mynameservice</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property> <!-- 自动 failover 启用标志位 --> <property> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value> </property> ``` 上述 XML 片段明确了如何指定名称服务 ID、各名字节点的身份标识符、它们对应的 RPC 访问端口位置以及其他关联细节等内容。 ###### b. core-site.xml 添加 zookeeper 属性 为了让客户端应用程序知道应该连接哪个 active Namenode ,还需要向 `core-site.xml` 中加入下面行内容: ```xml <property> <name>ha.zookeeper.quorum</name> <value>jn1:2181,jn2:2181,jn3:2181</value> </property> ``` 此条目指定了组成 quorum ensemble 的那些服务器成员列表及其监听通信端口号信息。 ##### (3)启动相关服务进程 依次开启 JournalNodes 及 ZooKeepers 这些辅助设施之后再分别初始化每个单独的名字节点实例最后才正式启动整体的服务链路结构即可。 --- #### 5. 测试验证环节 完成以上全部准工作以后就可以尝试模拟各种异常情况下来观察实际效果表现是否达到预期标准了比如故意关停正在工作的 primary component 查看 secondary 是否能及时接管过来继续维持业务运转等等测试手段都可以用来评估最终成果质量水平高低程度差异之处。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值