深刻浅出Mesos（三）：持久化存储和容错

【编者按】Mesos是Apache下的开源分布式资源管理框架，它被称为是分布式系统的内核。Mesos最初是由加州大学伯克利分校的AMPLab开发的，后在Twitter获得普遍使用。InfoQ接下来将会策划系列文章来为读者剖析Mesos。本文是整个系列的第一篇，简单介绍了Mesos的背景、历史以及架构。

注：本文翻译自Cloud Architect Musings，InfoQ中文站在得到做者受权的基础上对文章进行了翻译。

---

在深刻浅出Mesos系列的第一篇文章中，我对相关的技术作了简要概述，在第二篇文章中，我深刻介绍了Mesos的架构。完成第二篇文章以后，我本想开始着手写一篇Mesos如何处理资源分配的文章。不过，我收到一些读者的反馈，因而决定在谈资源分配以前，先完成这篇关于Mesos持久化存储和容错的文章。

持久化存储的问题

正如我在前文中讨论过的，使用Mesos的主要好处是能够在同一组计算节点集合上运行多种类型的应用程序（调度以及经过Framework初始化任务）。这些任务使用隔离模块（目前是某些类型的容器技术）从实际节点中抽象出来，以便它们能够根据须要在不一样的节点上移动和从新启动。

由此咱们会思考一个问题，Mesos是如何处理持久化存储的呢？若是我在运行一个数据库做业，Mesos如何确保当任务被调度时，分配的节点能够访问其所需的数据？如图所示，在Hindman的示例中，使用Hadoop文件系统（HDFS）做为Mesos的持久层，这是HDFS常见的使用方式，也是Mesos的执行器传递分配指定任务的配置数据给Slave常用的方式。实际上，Mesos的持久化存储可使用多种类型的文件系统，HDFS只是其中之一，但也是Mesos最常用的，它使得Mesos具有了与高性能计算的亲缘关系。其实Mesos能够有多种选择来处理持久化存储的问题：

• 分布式文件系统。如上所述，Mesos可使用DFS（好比HDFS或者Lustre）来保证数据能够被Mesos集群中的每一个节点访问。这种方式的缺点是会有网络延迟，对于某些应用程序来讲，这样的网络文件系统或许并不适合。

• 使用数据存储复制的本地文件系统。另外一种方法是利用应用程序级别的复制来确保数据可被多个节点访问。提供数据存储复制的应用程序能够是NoSQL数据库，好比Cassandra和MongoDB。这种方式的优势是再也不须要考虑网络延迟问题。缺点是必须配置Mesos，使特定的任务只运行在持有复制数据的节点上，由于你不会但愿数据中心的全部节点都复制相同的数据。为此，可使用一个Framework，静态地为其预留特定的节点做为复制数据的存储。

• 不使用复制的本地文件系统。也能够将持久化数据存储在指定节点的文件系统上，而且将该节点预留给指定的应用程序。和前面的选择同样，能够静态地为指定应用程序预留节点，但此时只能预留给单个节点而不是节点集合。后面两种显然不是理想的选择，由于实质上都须要建立静态分区。然而，在不容许延时或者应用程序不能复制它的数据存储等特殊状况下，咱们须要这样的选择。

Mesos项目还在发展中，它会按期增长新功能。如今我已经发现了两个能够帮助解决持久化存储问题的新特性：

• 动态预留。Framework可使用这个功能框架保留指定的资源，好比持久化存储，以便在须要启动另外一个任务时，资源邀约只会发送给那个Framework。这能够在单节点和节点集合中结合使用Framework配置，访问永久化数据存储。关于这个建议的功能的更多信息能够从此处得到。

• 持久化卷。该功能能够建立一个卷，做为Slave节点上任务的一部分被启动，即便在任务完成后其持久化依然存在。Mesos为须要访问相同的数据后续任务，提供在能够访问该持久化卷的节点集合上相同的Framework来初始化。关于这个建议的功能的更多信息能够从此处得到。

容错

接下来，咱们来谈谈Mesos在其协议栈上是如何提供容错能力的。恕我直言，Mesos的优点之一即是将容错设计到架构之中，并以可扩展的分布式系统的方式来实现。

• Master。故障处理机制和特定的架构设计实现了Master的容错。

  首先，Mesos决定使用热备份（hot-standby）设计来实现Master节点集合。正如Tomas Barton对上图的说明，一个Master节点与多个备用（standby）节点运行在同一集群中，并由开源软件Zookeeper来监控。Zookeeper会监控Master集群中全部的节点，并在Master节点发生故障时管理新Master的选举。建议的节点总数是5个，实际上，生产环境至少须要3个Master节点。 Mesos决定将Master设计为持有软件状态，这意味着当Master节点发生故障时，其状态能够很快地在新选举的Master节点上重建。 Mesos的状态信息实际上驻留在Framework调度器和Slave节点集合之中。当一个新的Master当选后，Zookeeper会通知Framework和选举后的Slave节点集合，以便使其在新的Master上注册。彼时，新的 Master能够根据Framework和Slave节点集合发送过来的信息，重建内部状态。

• Framework调度器。Framework调度器的容错是经过Framework将调度器注册2份或者更多份到Master来实现。当一个调度器发生故障时，Master会通知另外一个调度来接管。须要注意的是Framework自身负责实现调度器之间共享状态的机制。

• Slave。Mesos实现了Slave的恢复功能，当Slave节点上的进程失败时，可让执行器/任务继续运行，并为那个Slave进程从新链接那台Slave节点上运行的执行器/任务。当任务执行时，Slave会将任务的监测点元数据存入本地磁盘。若是Slave进程失败，任务会继续运行，当Master从新启动Slave进程后，由于此时没有能够响应的消息，因此从新启动的Slave进程会使用检查点数据来恢复状态，并从新与执行器/任务链接。

以下状况则大相径庭，计算节点上Slave正常运行而任务执行失败。在此，Master负责监控全部Slave节点的状态。

当计算节点/Slave节点没法响应多个连续的消息后，Master会从可用资源的列表中删除该节点，并会尝试关闭该节点。

而后，Master会向分配任务的Framework调度器汇报执行器/任务失败，并容许调度器根据其配置策略作任务失败处理。一般状况下，Framework会从新启动任务到新的Slave节点，假设它接收并接受来自Master的相应的资源邀约。

• 执行器/任务。与计算节点/Slave节点故障相似，Master会向分配任务的Framework调度器汇报执行器/任务失败，并容许调度器根据其配置策略在任务失败时作出相应的处理。一般状况下，Framework在接收并接受来自Master的相应的资源邀约后，会在新的Slave节点上从新启动任务。

结论

在接下来的文章中，我将更深刻到资源分配模块。同时，我很是期待读者的反馈，特别是关于若是我打标的地方，若是你发现哪里不对，请反馈给我。我非全知，虚心求教，因此期待读者的校订和启示。我也会在twitter响应你的反馈，请关注 @hui_kenneth。