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

作者 韩陆 > 【编者按】Mesos是Apache下的开源分布式资源管理框架，它被称为是分布式系统的内核。Mesos最初是由加州大学伯克利分校的AMPLab开发的，后在Twitter得到广泛使用。InfoQ接下来将会策划系列文章来为读者剖析Mesos。本文是整个系列的第一篇，简单介绍了Mesos的背景、历史以及架构。 注：本文翻译自[Cloud Architect Musings](http://cloudarchitectmusings.com/2015/03/23/apache-mesos-the-true-os-for-the-software-defined-data-center/)，InfoQ中文站在获得作者授权的基础上对文章进行了翻译。 * * * 在深入浅出Mesos系列的[第一篇文章](http://www.infoq.com/cn/articles/analyse-mesos-part-01)中，我对相关的技术做了简要概述，在[第二篇](http://www.infoq.com/cn/articles/analyse-mesos-part-02)文章中，我深入介绍了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配置，访问永久化数据存储。关于这个建议的功能的更多信息可以从[此处](https://issues.apache.org/jira/browse/MESOS-2018)获得。 * **持久化卷**。该功能可以创建一个卷，作为Slave节点上任务的一部分被启动，即使在任务完成后其持久化依然存在。Mesos为需要访问相同的数据后续任务，提供在可以访问该持久化卷的节点集合上相同的Framework来初始化。关于这个建议的功能的更多信息可以从[此处](https://issues.apache.org/jira/browse/MESOS-1554)获得。 ## 容错 接下来，我们来谈谈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](https://twitter.com/hui_kenneth)响应你的反馈，请关注 @hui_kenneth。