【问题标题】:Distributed system - master failure分布式系统 - 主故障
【发布时间】:2014-03-03 19:57:22
【问题描述】:

我最近阅读了一些关于分布式系统的文章,例如 Google 的 MapReduce 和 GSF 研究论文。这两个系统都依赖于存在Master 节点的事实,该节点协调其他“工作”节点。我想知道设计师如何保护自己免受大师失败的影响?在 MapReduce 论文中我们可以阅读:

It is easy to make the master write periodic checkpoints of the master data structures described above. 
If the master task dies, a new copy can be started from the last checkpointed state

我不清楚谁负责监控主故障?用户代码已经将控制权交给了分布式系统(实际上是 Master),并且只是等待结果。工作节点是否应该选举新的领导者?是否应该有一个不时 ping 主节点的休眠节点的优先级列表,如果失败,具有最高优先级 (ID) 的节点会启动?我不确定这是否有任何意义,因此我将不胜感激文章或任何更多技术答案的指针。

【问题讨论】:

    标签: hadoop mapreduce distributed failover master


    【解决方案1】:

    我没有文章,但我们先从两个方面来看:

    1. 您需要有一种可靠的方法来检测主节点是否真的发生故障或网络只是分区 - 不存在 100% 可靠的方法来做到这一点
    2. 您需要选择一个新的 master,这可以通过您描述的技术来完成,或者为了防止网络分区,您可以使用 paxos 算法找到一个新的 master

    这两点本身就很复杂,我认为这就是 MapReduce 和 GFS 论文中没有涵盖它们的原因,因为它们侧重于其他方面。

    转到 MapReduce 的开源实现 - Hadoop - 我相信 Zookeeper 正在负责监控主服务器并在它失败时选择一个新的主服务器的任务。我不是 100% 确定 Hadoop,但我知道 Giraph(pregel 的开源实现)正是以这种方式使用 Zookeeper。

    所以要了解它是如何解决的,您可能需要查找有关 Zookeeper 的论文。

    【讨论】:

    • 您需要有一种可靠的方法来检测主节点是否真的发生故障或网络只是分区 - 您的意思是什么?有一位大师,所以很明显,这个特定的一位失败了。除非您谈论的是环形拓扑的情况,否则这不是我的本意
    • 一个节点联系不上master,并不代表它就死了。其他节点可能能够与之通信,这称为网络分区。当您查看 CAP 定理时,您可以阅读更多相关信息
    猜你喜欢
    • 2011-03-06
    • 1970-01-01
    • 1970-01-01
    • 2020-12-29
    • 2020-10-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多