我刚刚给了this Hadoop tuorial在 JobTracker 中读取 Hadoop 有跟腱(单点故障)的状态:
The JobTracker is a single point of failure for the Hadoop MapReduce service which means if JobTracker goes down, all running jobs are halted.
还有this article其中指出 NameNode 是 SPOF:
The single point of failure in a Hadoop cluster is the NameNode.
单点故障很糟糕，对吗？ 什么策略/技术/工具/等等。可以做些什么来规避这些 SPOF 并使 Hadoop 变得冗余、容错和有弹性(流行语警告!)？
最佳答案
HDFS和Mapreduce是Hadoop中的核心组件，在早期的Apache Hadoop版本中，Namenode和Jobtracker是SPOF(只能配置一个实例)。此问题已从 Hadoop 2.X 中修复。
Jobtracker HA。
Jobtracker HA可以通过在两个节点上以Active - Standby模式配置2个Jobtracker(JT)实例来实现。如果一个 JT 出现故障，第二个 Jobtracker 将可用于处理请求。一次只有一个 jobtracker(Active) 可用于服务请求，第二个 JT(Standby) 将以只读模式运行。 Jobtracker HA 需要 zookeeper 实例，故障转移(切换)可以配置为 Manaul 或 Automcatic。自动故障转移需要另一个称为 Failover Controller (FC) 的进程。在当前版本中，如果 Activity JT 发生故障，所有正在运行的作业都将停止，但是新作业将自动提交给新 JT。此功能在当前版本中不可用。
MR2是使用YARN的第二代mapreduce，Resource Manager(RM)是YARN中的master服务，RM也可以配置成Active-Standby模式. RM 失败不会影响正在运行的作业/应用程序。
名称节点高可用性
Namenode HA 很重要。 Namenode HA 也可以配置为 Active-Standby 模式(最多 2 个 namenode 实例)。 Quorum based Journaling 是被广泛接受的方法，它在内部使用了 zookeeper。一次只有一个名称节点处于 Activity 状态。
Secondary Namenode(SNN) 不是Standby Namenode(SN)，反之亦然，SNN 在非 HA 配置中具有不同的功能，Namenode HA 设置没有t 需要 SNN，因为 SN 名称节点执行检查点(SNN 的功能)
进程 Namenode HA
- 活跃的名称节点
- 备用名称节点
- 故障转移 Controller :用于 Fencing 以避免出现裂脑情况。
- Jounalnodes(至少需要 3 个实例):命名空间修改将 被记录到 Journal 节点，Standby namenode 从那里读取。为了避免脑裂问题，一次只允许一个名称节点写入。
关于java - 缓解 Hadoop 的跟腱问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31053103/