我想使用Apache Marathon来管理集群产品中的资源。 Mesos和Marathon解决了一些＆＃34;集群资源管理器＆＃34;需要保持运行HA，故障转移等的其他组件的问题。
但是，有许多服务需要保持运行以保持mesos和马拉松运行（如zookeeper，mesos本身等）。我们可以使用什么来保持运行HA，故障转移等的服务？
似乎在集群中解决这个问题（管理zookeeper等的实例数量，以及它们运行的位置以及它们如何进行故障转移）正是mesos / marathon试图解决的问题。
答案 0 :(得分：3)
正如Mesos HA doc所解释的那样，你可以启动多个Mesos主人并让ZK选出领导者。然后，如果你的领导大师失败了，你仍然至少剩下2个来处理事情。通常使用像systemd这样的东西来自动重启同一主机上的mesos-master，如果它仍然健康，或者像Amazon AutoScalingGroups那样，以确保即使主机死了也总是有3台主机。
对于Marathon的HA mode也可以这样做（默认情况下，如果启动指向同一znode的多个实例，则为on）。许多用户在与Mesos主服务器相同的3个节点上启动这些节点，使用systemd重新启动失败的Marathon服务，并使用相同的ASG确保有3个Mesos / Marathon主节点。
这些相同的3个节点通常也被配置为ZK仲裁，因此在Mesos之外运行的所有这些服务只需要管理3个节点。
可以想象，你可以将Mesos-master和Marathon作为Marathon / Mesos任务引导到集群中。启动单个Mesos + Marathon主机以启动集群，然后在Marathon中创建一个Mesos-master应用程序以启动2-3个主人作为Mesos任务，并在Marathon中创建一个Marathon-master应用程序以启动几个HA Marathon实例（作为Mesos任务）。一旦它们健康，你可以杀死原始的独立Mesos / Marathon主机，集群将故障转移到自托管的Mesos和Marathon主机，如果它们发生故障，它们将自动重新启动到集群的其他地方。也许这也适用于ZK。您可能需要Mesos-DNS和/或ELB之类的东西让其他服务找到Mesos / Marathon。我怀疑是否有人以这种方式运行Mesos，但它足够疯狂它可能会起作用！
答案 1 :(得分：0)
为了理解这一点，我建议您花几分钟时间阅读官方Mesos文档中的architecture和HA part。在那里，它清楚地解释了如何处理Mesos核心中的HA /故障转移（也就是说，BTW，没有什么神奇的 - 我知道很多系统使用这个模型，包括HBase，Storm，Kafka等）。
另外，请注意 - 自然地保持少数Mesos主人/ Zk活着的挑战与在群集中保持可能的10000个进程活着，驱逐它们或使它们失败（在扇出方面，内存占用，吞吐量等。）。