共计 1659 个字符，预计需要花费 5 分钟才能阅读完成。
这期内容当中丸趣 TV 小编将会给大家带来有关 Hadoop2.2.0 中的高可用性实现原理是什么，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
在 Hadoop2.0.0 之前，NameNode(NN) 在 HDFS 集群中存在单点故障（single point of failure），每一个集群中存在一个 NameNode，如果 NN 所在的机器出现了故障，那么将导致整个集群无法利用，直到 NN 重启或者在另一台主机上启动 NN 守护线程。
主要在两方面影响了 HDFS 的可用性：
（1）、在不可预测的情况下，如果 NN 所在的机器崩溃了，整个集群将无法利用，直到 NN 被重新启动；
（2）、在可预知的情况下，比如 NN 所在的机器硬件或者软件需要升级，将导致集群宕机。
HDFS 的高可用性将通过在同一个集群中运行两个 NN（active NN standby NN）来解决上面两个问题，这种方案允许在机器破溃或者机器维护快速地启用一个新的 NN 来恢复故障。
在典型的 HA 集 群中，通常有两台不同的机器充当 NN。在任何时间，只有一台机器处于 Active 状态；另一台机器是处于 Standby 状态。Active NN 负责集群中所有客户端的操作；而 Standby 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 的位置，并向它们发送块文件所在的位置及心跳，如下图所示：
Hadoop2.2.0 中 HDFS 的高可用性实现原理
在任何时候，集群中只有一个 NN 处于 Active 状态是极其重要的。否则，在两个 Active NN 的状态下 NameSpace 状态将会出现分歧，这将会导致数据的丢失及其它不正确的结果。为了保证这种情况不会发生，在任何时间，JNs 只允许一个 NN 充当 writer。在故障恢复期间，将要变成 Active 状态的 NN 将取得 writer 的角色，并阻止另外一个 NN 继续处于 Active 状态。
为了部署 HA 集群，你需要准备以下事项：
（1）、NameNode machines：运行 Active NN 和 Standby NN 的机器需要相同的硬件配置；
（2）、JournalNode machines：也就是运行 JN 的机器。JN 守护进程相对来说比较轻量，所以这些守护进程可以可其他守护线程（比如 NN，YARN ResourceManager）运行在同一台机器上。在一个集群中，最少要运行 3 个 JN 守护进程，这将使得系统有一定的容错能力。当然，你也可以运行 3 个以上的 JN，但是为了增加系统的容错能力，你应该运行奇数个 JN（3、5、7 等），当运行 N 个 JN，系统将最多容忍 (N-1)/ 2 个 JN 崩溃。
在 HA 集群中，Standby NN 也执行 namespace 状态的 checkpoints，所以不必要运行 Secondary NN、CheckpointNode 和 BackupNode；事实上，运行这些守护进程是错误的。
上述就是丸趣 TV 小编为大家分享的 Hadoop2.2.0 中的高可用性实现原理是什么了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注丸趣 TV 行业资讯频道。
