美好的一周又开始了，今天小数带来的文章里将讨论 Mesos的不同存储选项以及如何利用Flocker简化自动持久任务流程——精彩多多，不容错过：）
小数预告：从明天开始，数人云微信群将进行Dockercon西雅图盛会的精彩直播，敬请期待~
目录
• Apache Mesos是什么?
• 使用永久存储
• 本地文件系统
• 永久分卷
• 动态预留
• Docker容器化工具与Docker分卷插件
• 框架、模块与隔离器
• 数据存储框架
• 总结
Apache Mesos是什么?
“Apache Mesos能够将CPU、内存、存储以及其它计算资源由设备（物理或虚拟）中抽象出来，从而实现高容错与弹性分布式系统的轻松构建与高效运行。”
Apache Mesos的任务运行方式在于，其允许框架在Mesos基础之上接收CPU、内存、网络与存储资源，并对资源加以调度从而执行任务。值得注意的是，各任务可通过调度在容器内运行，而部分任务可能需要永久存储作为配合。需要配合永久存储机制的任务包括MySQL、MongoDB等数据库，以及Nginx缓存、日志记录目录和博客软件用于存储数据的数据目录等Web缓存机制。框架始终需要依靠Mesos为其提供执行任务所必需的物理或虚拟资源。
使用永久存储
Apache Mesos的主要工作就是为任务提供并管理资源。一般来讲，这些任务会从节点中解耦出来以实现故障转移、灵活性与可扩展性。然而，在运行需要永久存储的服务时，我们可以在任务中引入依赖性以指定服务运行时是否使用该节点的本地存储。需要访问容器外存储的应用一般包括数据库（NoSQL/SQL）、Web缓存、应用日志以及秘密存储等。我们将在以下示意图中列举一项任务与数据示例：
大家可以使用多种不同方案与架构以实现数据可用性、安全性与任务一致性。在接下来的内容中，我们将探讨Apache Mesos中的现有存储处理方式，并了解如何解决其中存在的技术陷阱。
本地文件系统
普通本地文件系统
这类方案最易于实现，但却拥有多种缺陷。首先，任务会引用主机节点上的本地文件系统，而数据则存储在任务运行所在的节点磁盘当中。因此，该任务不具备灵活性，即无法实现故障转移或者在集群中往来迁移。有鉴于此，Mesos将对该节点进行重新调度，并将任务“pin”至此节点内的已知数据存储位置。我们可以使用指向其它存储位置的定期备份来实现故障转移，但配置过程非常复杂，且无法发挥Mesos自身的诸多优势。
使用复制或分布式文件系统
解决上述缺陷的一种可行途径就是采用NFS及GLusterFS等共享或分布式文件系统。这两种选项都会为节点提供基于PSIX的存储访问合规性，且可以集中方式或者立足单一节点进行管理。以下示意图说明了这两种选项的基本原理。
这类实现方案中存在着一些陷阱，可能会带来极为沉重的管理强度，由于网络依赖性而导致崩溃或者当机，或者导致任务更适合运行在本地、iSCSI或者光纤通道系统上而非基于外部网络的POSIX文件存储之上。
其优势在于，我们可以将各任务重新调度至其它Mesos节点上，而且NFS实际上较其它分布式文件系统更易于安装及配置。
永久分卷
Mesos中的永久分卷（即Persistent Volumes）负责在任务创建时指定其所使用的磁盘（存储）资源。
从Mesos的角度来看，这些磁盘利用Mesos从节点中的存储资源创建而成，并将在任务结束后继续存在。在任务存在时，这些存储资源可被分配至系统其余位置，保证其它任务也能够使用其中的永久数据。这意味着数据不会根据具体任务进行垃圾回收。Mesos确保用户可在任务调度之前预留磁盘资源。
Mesos中的这种永久分卷使用方式与本地文件系统类似，二者的区别在于Mesos会指定视角来规划如何为任务生成此类存储资源。但有一点需要注意，如果运维人员利用本地SSD创建Path或者Mount磁盘，则与之相关的附加存储或者分布式存储也会受到影响。除了无法实现系统管理自动化且磁盘必须进行附加之外，我们需要首先在其上创建并启用文件系统，而后才能将其分配给Mesos。另外，Path磁盘必须保证各磁盘由单一后端磁盘root路径创建得来，而Mount磁盘则需要全盘专用于某一任务。
动态预留
动态预留（即Dynamic Reservations）相较于静态预留更进一步，使得各框架能够在Mesos从进程已经启动之后预留存储资源。
如此一来，Mesos就能够为某一框架预留特定数量的资源并在随后进行交付。举例来说，一套专门针对MySQL部署设计的框架可以确保其使用动态预留存储资源，同时保证这些存储资源只供MySQL永久服务使用。
这套方案对于原始存储资源的灵活性影响不大，而且成为Mesos中的一大特殊功能。不过其仍然存在着优势与缺点，我们已经在之前的本地文件系统与永久分卷章节中进行了讨论。
Docker容器化工具与Docker分卷插件
确保永久服务实现灵活性的方法之一在于使用Docker分卷插件，其不仅能够实现与本地文件系统类似的用例，同时也能够实现共享式存储集成体系——其中附加有块存储设备，且会在任务启动前被安装于Mesos从节点当中。
利用这种方法，大家可以通过Docker获得对驱动程序的原生支持能力，同时得以发挥SAN或软件定义存储（简称SDS）平台等现有系统的既有优势。
部分SDS系统可被部署为超融合形式，其中存储资源以池化方式存在，且可跨越不同SDS解决方案进行复制以实现冗余。如此一来，存储体系所占用的网络传输能力将远低于传统集中化SAN。目前每种方法可谓各有优劣，具体选择要根据实际用例而定。
以下示图为多节点场景下的SDS层，其中各分卷表现为“本地”形式，且可利用网络在不同Mesos从节点间往来复制。另外，这也是一套基于SAN的方案，各分卷由外部SAN设备通过网络接入Mesos从节点。
其积极因素包括出色的灵活性——这主要贡献于各分卷能够在任务动态启动时同时创建、安装并可用于文件系统——故障转移以及高可用性。而负面因素则包括负载较重且配置较为复杂。
Docker插件包括：
• Flocker
• Convoy
• Blockbridge
• REX-Ray
• OpenStorage
• GlusterFS
以及更多。
框架、模块与隔离器
与之前提到的SAN与SDS用例一样，Mesos也提供模块、框架与隔离器以帮助用户在无需使用Docker容器化工具的前提下运用分卷插件。这意味着任务能够享受到之前提到的各种助益，包括无需Docker实现联网块存储与本地Mesos的配合。
另有多种模块及隔离器面向共享式存储。
Flocker框架
Mesos Flocker项目旨在为Mesos添加云存储机制。在它的帮助下，我们可以利用冗余数据存储支持有状态应用。
该框架以透明化方式处理与采用Flocker的云服务供应商间的通信。Mesos-Flocker能够确保我们的数据在面向容器时始终具备可用性——即使是在故障转移期间。
Mesos模块DVDI
DVDI Mesos模块是一款用于为Mesos容纳Docker分卷驱动隔离器模块（即Docker Volume Driver Isolator Module）的工具。它的作用是创建一个驻留在Mesos从节点中的模块，并为每个被分配至从节点的任务创建/安装/反安装外部存储资源。
其独特之处在于，我们可以利用它适应Docker分卷驱动所提供的多种不同存储平台，同时允许用户利用任务中的分卷选项进行配置。
数据存储框架
我们可以利用多种数据存储框架对服务或者平台进行管理，从而为Mesos中的应用提供数据存储。数据存储框架与前面提到的、能够给应用实际提供原始存储资源的示例不同，但这里仍然有必要对其进行说明。
面向特定数据服务的主要数据存储框架包括：
-
Cassandra（https://github.com/mesosphere/cassandra-mesos）
-
ElasticSearch（http://mesos-elasticsearch.readthedocs.io/en/latest/）
-
HyperTable（https://code.google.com/archive/p/hypertable/wikis/Mesos.wiki）
-
A lluxio （原名Tachyon，http://www.alluxio.org/）
这份清单没有列入Apache Cotton，其此前曾名为Mysos且负责将MySQL实例作为框架运行在Mesos当中。不过根据孵化器项目网站上的说明，Apache Cotton似乎已经被放弃。
总结
总体来讲，Mesos拥有丰富的可选方案供用户使用。预计未来还将有更多新型框架及架构与大家见面，因此在从中选取正确方案时，大家请注意结合应用与用例的实际情况。
（本文源自：ClusterHQ，作者Ryan Wallner）