(三)：持久化存储与容错.pdf

（三）：持久化存储和容错 来源：http://www .infoq .com/cn/articles/analyse-mesos-part-03 在深⼊浅出Mesos系列的第⼀篇⽂章中，我对相关的技术做了简要概述，在第⼆篇⽂ 章中，我深⼊ 绍了Mesos的架构。完成第⼆篇⽂章之后，我本想开始着⼿写⼀篇 Mesos如何处理资源分配的⽂章。不过，我收到⼀些读者的反馈，于是决定在谈资源 分配之前，先完成这篇关于Mesos持久化存储和容错的⽂章。 持久化存储的问题 正如我在前⽂中讨论过的，使⽤Mesos的主要好处是可以在同⼀组计算节点集合上运 ⾏多种类型的应⽤程序 （调度以及通过Framework初始化任务）。这些任务使⽤隔离 模块 （⽬前是某些类型的容器技术）从实际节点中抽象出来，以便它们可以根据需要 在不同的节点上移动和重新启动。 由此我们会思考⼀个问题，Mesos是如何处理持久化存储的呢？如果我在运⾏⼀个数 据库作业，Mesos如何确保当任务被调度时，分配的节点可以访问其所需的数据？如 图所⽰，在Hindman的⽰例中，使⽤Hadoop⽂件系统 （HDFS ）作为Mesos的持久层， 这是HDFS常见的使⽤⽅式，也是Mesos的执⾏器传递分配指定任务的配置数据给 Slave经常使⽤的⽅式。实际上，Mesos的持久化存储可以使⽤多种类型的⽂件系统， HDFS只是其中之⼀，但也是Mesos最经常使⽤的，它使得Mesos具备了与⾼性能计算 的亲缘关系。其实Mesos可以有多种选择来处理持久化存储的问题： 分布式⽂件系统。如上所述，Mesos可以使⽤DFS （⽐如HDFS或者 ustre ）来 保证数据可以被Mesos集群中的每个节点访问。这种⽅式的缺点是会有⽹络延 迟，对于某些应⽤程序来说，这样的⽹络⽂件系统或许并不适合。 使⽤数据存储复制的本地⽂件系统。另⼀种⽅法是利⽤应⽤程序级别的复制来 确保数据可被多个节点访问。提供数据存储复制的应⽤程序可以是NoSQ 数据 库，⽐如Cassandra和MongoDB 。这种⽅式的优点是不再需要考虑⽹络延迟问 题。缺点是必须配置Mesos ，使特定的任务只运⾏在持有复制数据的节点上， 因为你不会希望数据中⼼的所有节点都复制相同的数据。为此，可以使⽤⼀个 Framework ，静态地为其预留特定的节点作为复制数据的存储。 不使⽤复制的本地⽂件系统。也可以将持久化数据存储在指定节点的⽂件系统 上，并且将该节点预留给指定的应⽤程序。和前⾯的选择⼀样，可以静态地为 指定应⽤程序预留节点，但此时只能预留给单个节点⽽不是节点集合。后⾯两 种显然不是理想的选择，因为实质上都需要创建静态分区。然⽽，在不允许延 时或者应⽤程序不能复制它的数据存储等特殊情况下，我们需要这样的选择。 Mesos项⽬还在发展中，它会定期增加新功能。现在我已经发现了两个可以帮助解决 持久化存储问题的新特性： 态预留。Framework可以使⽤这个功能框架保留指定的资源，⽐如持久化存 储，以便在需要启动另⼀个任务时，资源邀约只会发送给那个Framework 。这 可以在单节点和节点集合中结合使⽤Framework配置，访问永久化数据存储。 关于这个建议的功能的更多信息可以从此处获得。 持久化卷。该功能可以创建⼀个卷，作为Slave节点上任务的⼀部分被启动，即 使在任务完成后其持久化依然存在。Mesos为需要访问相同的数据后续任务， 提供在可以访问该持久化卷的节点集合上相同的Framework来初始化。关于这 个建议的功能的更多信息可以从此处获得。 容错 接下来，我们来谈谈Mesos在其协议栈上是如何提供容错能⼒的。恕我直⾔，Mesos的 优势之⼀便是将容错设计到架构之中，并以可扩展的分布式系统的⽅式来实现。 Master。故障处理机制和特定的架构设计实现了Master 的容错。 ⾸先，Mesos决定使⽤热备份 （hot-standby ）设计来实现Master节点集合。正如 Tomas Barton对上图的说明，⼀个Master节点与多个备⽤ （standby ）节点运⾏