zk是如何实现hadoop集群的HA （高可用）

最新推荐文章于 2024-12-17 23:58:27 发布

zengxianglei

最新推荐文章于 2024-12-17 23:58:27 发布

阅读量1k

点赞数 1

CC 4.0 BY-SA版权

分类专栏： zk hadoop 文章标签： zk是如何实现hadoop集群的HA （高可用）

本文链接：https://blog.youkuaiyun.com/zengxianglei/article/details/94356578

本文介绍了Zookeeper如何确保Hadoop集群的高可用性。通过Active和Standby NameNode的角色切换，以及JournalNodes的协调，保证了数据的一致性和故障快速恢复。在故障发生时，Standby NN会确保读取全部edits，从而接替Active NN的角色，防止数据丢失和状态分歧。部署HA集群需要配置相同的硬件，并运行多个JournalNode以提高容错能力。

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

zk是如何实现hadoop集群的HA （高可用）

在典型的HA集群中，一般有倆台不同的机器充当nn,(note1 主机 nn ，note2 备用主机nn )。在任何时间，有且只有一台机器处于active状态；另一台机器处于standby状态。 active nn 负责所有客户端的操作，standby nn 主要用于备用，它的主要目的是 active nn宕机，可以提供备用并快速的故障恢复。

既然 standby nn 是用于备用，那它如何保持与active nn 数据同步（元数据保持一致）？

这里有一个JournalNodes 守护进程，他俩都会和这个进程通信，当 active nn 执行任何有关命名空间的修改操作，它需要持久化到一半以上的 JournalNodes 上(通过 edits log 持久化存储),而 Standby NN 负责观察 edits log的变化,它能够读取从 JNs 中读取 edits 信息,并更新其内部的命名空间。一旦 Active NN出现故障,Standby NN 将会保证从 JNs 中读出了全部的 Edits,然后切换成 Active 状态。Standby NN 读取全部的 edits 可确保发生故障转移之前,是和 Active NN 拥有完全同步的命名空间状态。
为了提供快速的故障恢复,Standby NN 也需要保存集群中各个文件块的存储位置。为了实现这个,集群中所有的 Database 将配置好 Active NN 和 Standby NN 的位置,并向它们发送块文件所在的位置及心跳,

在任何时候,集群中只有一个 NN 处于 Active 状态是极其重要的。否则,在两个 Active NN的状态下 NameSpace 状态将会出现分歧,这将会导致数据的丢失及其它不正确的结果。为了保证这种情况不会发生,在任何时间,JNs 只允