请注意本文部分内容经过AI辅助生成虽然经过笔者检查但是并不保证内容的正确性请自行判断准确性本文对相关后果不承担责任本次测试基于 EMR 7.12.0 HA 集群实际配置在创建集群时配置如下external metastore并开启HA[{Classification:hive-site,Properties:{javax.jdo.option.ConnectionURL:jdbc:mysql://172.31.14.46:3306/hive_metastore?createDatabaseIfNotExisttrue,javax.jdo.option.ConnectionDriverName:org.mariadb.jdbc.Driver,javax.jdo.option.ConnectionUserName:hive,javax.jdo.option.ConnectionPassword:hive}}]EMR HA 集群通过部署 3 个 Master 节点为 HDFS、YARN、HBase、Hive 等核心组件提供高可用能力。当任一 Master 节点故障时服务可自动切换到其他节点避免单点故障导致集群不可用。节点拓扑角色实例类型数量Masterm5.xlarge3Corem5.xlarge2Taskc5.xlarge13 个 Master 节点信息节点私有 IP私有 DNSMaster 1192.168.31.118ip-192-168-31-118.cn-north-1.compute.internalMaster 2192.168.18.219ip-192-168-18-219.cn-north-1.compute.internalMaster 3192.168.17.6ip-192-168-17-6.cn-north-1.compute.internalHA 组件角色分布各组件的 Active 角色分散在不同节点上避免单节点承载所有 Active 服务组件Active 节点Standby/Backup 节点HDFS NameNode192.168.31.118 (nn1)192.168.18.219 (nn2), 192.168.17.6 (nn3)YARN ResourceManager192.168.18.219 (rm2)192.168.31.118 (rm1), 192.168.17.6 (rm3)HBase Master192.168.31.118192.168.18.219, 192.168.17.6ZooKeeper192.168.18.219 (leader)192.168.31.118 (follower), 192.168.17.6 (follower)Hive Metastore3 节点均运行Active-Active—HiveServer23 节点均运行Active-Active—HA 架构总览组件依赖关系┌─────────────────────────┐ │ ZooKeeper (3节点集群) │ │ HA 架构的选举基础 │ └──────┬──────┬──────┬─────┘ │ │ │ ┌──────────┘ │ └──────────┐ ▼ ▼ ▼ ┌───────────┐ ┌─────────────┐ ┌─────────────┐ │ ZKFC │ │ YARN RM │ │ HBase Master│ │ NN 选举 │ │ 内嵌选举 │ │ ZK 选举 │ └─────┬─────┘ └─────────────┘ └─────────────┘ ▼ ┌───────────┐ │ NameNode │ │ HA 切换 │ └─────┬─────┘ │ ┌─────▼─────┐ │JournalNode│ │ EditLog │ │ 同步(3节点) │ └───────────┘ External MySQL (172.31.14.46:3306) └── Hive Metastore 元数据存储3 个 Metastore 实例共享各组件 HA 模式对比组件HA 模式选举/协调方式故障转移HDFS NameNodeActive-Standby (12)ZKFC ZooKeeper自动YARN ResourceManagerActive-Standby (12)内嵌 ZooKeeper 选举自动HBase MasterActive-Backup (12)ZooKeeper自动ZooKeeperLeader-Follower (12)ZAB 协议内部选举自动Hive MetastoreActive-Active (3)无需选举多实例并行客户端重连HiveServer2Active-Active (3)无需选举多实例并行客户端重连HDFS NameNode HAHDFS NameNode HA 是整个 HA 架构中最复杂的部分涉及 ZKFC、JournalNode、Fencing 等多个机制协同工作。配置详情/etc/hadoop/conf/hdfs-site.xml关键配置!-- 逻辑名称 --propertynamedfs.nameservices/namevalueha-nn-uri/value/property!-- 3 个 NameNode --propertynamedfs.ha.namenodes.ha-nn-uri/namevaluenn1,nn2,nn3/value/property!-- 各 NameNode RPC 地址 --propertynamedfs.namenode.rpc-address.ha-nn-uri.nn1/namevalueip-192-168-31-118.cn-north-1.compute.internal:8020/value/propertypropertynamedfs.namenode.rpc-address.ha-nn-uri.nn2/namevalueip-192-168-18-219.cn-north-1.compute.internal:8020/value/propertypropertynamedfs.namenode.rpc-address.ha-nn-uri.nn3/namevalueip-192-168-17-6.cn-north-1.compute.internal:8020/value/property!-- 客户端自动故障转移 --propertynamedfs.client.failover.proxy.provider.ha-nn-uri/namevalueorg.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider/value/property客户端使用逻辑名称hdfs://ha-nn-uri/访问 HDFS通过ConfiguredFailoverProxyProvider自动发现并连接 Active NameNode无需关心具体哪个节点是 Active。ZKFCZooKeeper Failover ControllerZKFC 是 Hadoop 原生组件属于hadoop-hdfs模块org.apache.hadoop.hdfs.tools.DFSZKFailoverController在 Hadoop 2.0 引入 HDFS HA 时一起加入。每个 NameNode 旁边运行一个 ZKFC 进程负责三件事健康监控— 通过HealthMonitor线程定期调用 NameNode 的monitorHealth()RPC判断 NameNode 是否正常ZooKeeper 会话管理— 在 ZooKeeper 中维护临时节点ephemeral znodeActiveStandbyElectorLock持有锁的 ZKFC 对应的 NameNode 为 Active触发故障转移— 检测到 Active NameNode 不健康时触发自动切换注意只有 HDFS NameNode 使用 ZKFC。YARN ResourceManager 的故障转移是内嵌在 RM 进程里的automatic-failover.embeddedtrue不需要额外的 ZKFC 进程。JournalNodeJournalNode 负责在 Active 和 Standby NameNode 之间同步 EditLog编辑日志。3 个 Master 节点各运行一个 JournalNode。HDFS 元数据由两部分组成FsImage— 某个时间点的完整命名空间快照EditLog— 快照之后的所有变更操作创建文件、删除目录、修改权限等工作方式客户端写操作 → Active NameNode ↓ 并行写 EditLog JournalNode 集群 (3节点Quorum 多数派写入2/3 成功即可) ↑ 持续读 EditLog Standby NameNode (回放到内存保持状态同步)为什么不让 Active 直接把 EditLog 发给 Standby因为如果 Active 挂了正在传输的 EditLog 可能丢失。JournalNode 作为独立的第三方存储即使 Active 挂了已写入的 EditLog 不会丢。Quorum 机制保证即使一个 JournalNode 挂了数据仍然完整。JournalNode 没有主从之分所有节点完全对等对比ZooKeeperJournalNode角色Leader / Follower有主从全对等无主从写入方式写请求必须经过 Leader 转发各节点独立接受写入节点间通信Leader 同步到 Follower节点之间不互相通信一致性保证Leader 负责排序NameNode 侧 Quorum 写入 epoch number节点故障需要重新选举 Leader无需选举多数派存活即可故障转移完整流程当 Active NameNode 发生故障时自动切换流程如下1. 旧 Active NN 故障 ↓ 2. 旧 ZKFC 检测到 monitorHealth() 失败 ↓ 3. 释放 ZK 锁或 ZKFC 也挂了则 session 超时自动释放 ephemeral znode ↓ 4. Standby ZKFC 竞争创建 /hadoop-ha/ha-nn-uri/ActiveStandbyElectorLock ZooKeeper 保证只有一个 ZKFC 创建成功赢得选举 ↓ 5. Fencing 隔离旧 Activesshfence kill 旧 NN 进程防止脑裂 如果 fencing 失败不会继续提升宁可无 Active 也不允许双 Active ↓ 6. 调用 transitionToActive() RPC 提升 Standby 为新 Active ↓ 7. 新 Active 从 JournalNode 同步完所有未回放的 EditLog ↓ 8. 开始接受客户端读写请求写新的 EditLog 到 JournalNode其中 Fencing 是关键步骤保证任何时刻最多只有一个 Active NameNode避免脑裂split-brain导致数据不一致。YARN ResourceManager HA配置详情/etc/hadoop/conf/yarn-site.xml关键配置propertynameyarn.resourcemanager.ha.enabled/namevaluetrue/value/propertypropertynameyarn.resourcemanager.cluster-id/namevalueha-rm-uri/value/propertypropertynameyarn.resourcemanager.ha.automatic-failover.enabled/namevaluetrue/value/propertypropertynameyarn.resourcemanager.ha.automatic-failover.embedded/namevaluetrue/value/propertypropertynameyarn.resourcemanager.ha.rm-ids/namevaluerm1,rm2,rm3/value/propertypropertynameyarn.resourcemanager.hostname.rm1/namevalueip-192-168-31-118.cn-north-1.compute.internal/value/propertypropertynameyarn.resourcemanager.hostname.rm2/namevalueip-192-168-18-219.cn-north-1.compute.internal/value/propertypropertynameyarn.resourcemanager.hostname.rm3/namevalueip-192-168-17-6.cn-north-1.compute.internal/value/propertyHA 机制3 个 ResourceManager1 Active 2 Standby故障转移内嵌在 RM 进程中automatic-failover.embeddedtrue基于 ZooKeeper 选举不需要像 NameNode 那样额外运行 ZKFC 进程使用ha-rm-uri作为集群逻辑名称内嵌选举Embedded FailoverYARN RM 的故障转移选举逻辑直接写在 RM 进程代码里automatic-failover.embeddedtrue不需要像 HDFS NameNode 那样额外启动独立的 ZKFC 进程HDFS NameNode — 外部选举两个独立进程: NameNode 进程只管 HDFS 服务 ZKFC 进程独立进程负责健康检查 ZK 选举 故障转移 YARN ResourceManager — 内嵌选举单进程: ResourceManager 进程YARN 服务 健康检查 ZK 选举 故障转移全在一个进程里RM 启动时自己去 ZooKeeper 抢锁抢到就是 Active没抢到就是 Standby。Active RM 挂了ZK session 超时其他 Standby RM 自动竞争成为新 Active。设计不同是历史原因HDFS NameNode HA 先实现选择了外部 ZKFC 保持 NameNode 代码简洁后来 YARN RM HA 实现时把选举逻辑直接嵌入 RM 进程内部。功能上没有区别都是通过 ZooKeeper 做选举只是代码放的位置不同。ZooKeeper 集群3 个 Master 节点各运行一个 ZooKeeper 实例组成 3 节点集群节点角色192.168.31.118follower192.168.18.219leader192.168.17.6followerLeader-Follower 模式ZooKeeper 采用 Leader-Follower 模式不是传统的主从复制Leader— 处理所有写请求负责将写操作广播给 Follower 并确保多数派确认后才提交Follower— 可以直接处理读请求收到写请求时转发给 LeaderFollower 不是被动复制的从节点它们主动参与写入投票也能独立处理读请求。只是写操作的协调权集中在 Leader 上。与 HDFS NameNode Active-Standby 的区别对比HDFS NameNodeZooKeeper模式Active-StandbyLeader-FollowerStandby/Follower 能否服务不能Standby 不接受客户端请求能Follower 可以处理读请求写入只有 Active 写写请求都经过 Leader但 Follower 参与确认选举由外部 ZKFC 触发Leader 故障时 Follower 通过 ZAB 协议自动选举在 HA 架构中的角色ZooKeeper 是整个 HA 架构的选举基础负责HDFS NameNode 的 Active 选举通过 ZKFCYARN ResourceManager 的 Active 选举内嵌HBase Master 的 Active 选举HBase RegionServer 的注册和监控3 节点集群容忍 1 个节点故障多数派 2。Leader 挂了剩余 Follower 通过 ZABZooKeeper Atomic Broadcast协议自动选出新 Leader不需要外部组件介入。HBase HA配置详情/etc/hbase/conf/hbase-site.xml关键配置propertynamehbase.zookeeper.quorum/namevalueip-192-168-31-118...,ip-192-168-18-219...,ip-192-168-17-6.../value/propertypropertynamehbase.rootdir/namevaluehdfs://ha-nn-uri/user/hbase/value/propertyHA 机制1 Active Master 2 Backup Masters通过 ZooKeeper 选举Active Master 负责 Region 分配和负载均衡hbase.rootdir使用 HDFS HA 逻辑名称ha-nn-uri不绑定单个 NameNode集群状态1 active master, 2 backup masters, 2 servers, 0 dead, 1.0000 average loadHive HAHive 的 HA 模式与其他组件不同采用多实例并行运行服务192.168.31.118192.168.18.219192.168.17.6hive-hcatalog-server (Metastore)✅ running✅ running✅ runninghive-server2 (HiveServer2)✅ running✅ running✅ running3 个 Metastore 实例都可以接受请求共享同一个外部 MySQL 数据库3 个 HiveServer2 实例都可以接受客户端连接不需要选举任一实例故障时客户端重连到其他实例即可与非 HA 集群的对比对比项非 HA 集群HA 集群Master 节点数13HDFS NameNode单点1 Active 2 Standby自动故障转移YARN ResourceManager单点1 Active 2 Standby自动故障转移HBase Master单点1 Active 2 BackupZooKeeper单节点3 节点集群Hive Metastore单实例3 实例 Active-ActiveHiveServer2单实例3 实例 Active-ActiveJournalNode无3 节点EditLog 同步ZKFC无3 节点NameNode 故障转移控制终止保护默认关闭默认开启Master 放置策略无SPREAD分散到不同硬件HA 状态检查命令# HDFS NameNode 状态sudo-uhdfs hdfs haadmin-getAllServiceState# YARN ResourceManager 状态yarnrmadmin-getAllServiceState# ZooKeeper 角色echosrvr|nclocalhost2181|grepMode# HBase Master 状态echostatus|sudo-uhbase hbase shell# ZKFC 服务状态sudosystemctl status hadoop-hdfs-zkfc# JournalNode 服务状态sudosystemctl status hadoop-hdfs-journalnode# Hive Metastore 服务状态sudosystemctl status hive-hcatalog-server# HiveServer2 服务状态sudosystemctl status hive-server2