35

最近我发现了 Apache Mesos 之类的东西。

在所有演示和示例中，这一切看起来都令人惊讶。我可以很容易地想象一个人将如何从事无国籍的工作——这自然符合整个想法。

Bot 如何处理有状态的长时间运行的作业？

比如说，我有一个由 N 台机器组成的集群（并且是通过 Marathon 安排的）。我想在那里运行一个 postgresql 服务器。

就是这样 - 起初我什至不希望它具有高可用性，而只是一个托管 postgresql 服务器的单个作业（实际上是 Dockerized）。

1-如何组织它？将服务器约束到特定的集群节点？使用一些分布式FS？

2- DRBD、MooseFS、GlusterFS、NFS、CephFS，其中哪一个与 Mesos 和 postgres 等服务配合得很好？（我在这里考虑 Mesos/marathon 可能会在出现故障时重新定位服务）

3-请告诉我我的方法在哲学方面是否错误（数据服务器的 DFS 和 Mesos 顶部的 postgres 等服务器的某种切换）

zerkms在Programmers Stack Exchange上提出的问题主要复制自Apache Mesos 的持久存储。

4

1 回答 1

45

很好的问题。以下是 Mesos 中一些即将推出的功能，用于改进对有状态服务的支持，以及相应的当前解决方法。

  1. 持久卷（0.23）：启动任务时，您可以创建一个存在于任务沙箱之外的卷，并且即使在任务终止/完成后也会在节点上持久存在。当任务退出时，它的资源（包括持久卷）可以返回给框架，以便框架可以再次启动相同的任务、启动恢复任务或启动消耗前一个任务输出的新任务作为其输入。
    • 当前的解决方法：将您的状态保留在沙箱外的某个已知位置，并让您的任务尝试手动恢复它。也许将它保存在分布式文件系统/数据库中，以便可以从任何节点访问它。
  2. 磁盘 隔离(0.22)：对沙盒和持久卷实施磁盘配额限制。这可确保您的存储密集型框架不会堵塞磁盘并阻止其他任务运行。
    • 当前解决方法：带外监控磁盘使用情况，并运行定期清理作业。
  3. 动态保留(0.23)：启动任务时，您可以保留任务使用的资源（包括持久卷），以确保在任务退出时将它们提供给您，而不是转到最低于其公平份额的任何框架。
    • 当前解决方法：使用从属--resources标志在从属启动时为您的框架静态保留资源。

至于您的具体用例和问题：

1a)如何组织它？您可以使用 Marathon 执行此操作，也许为您的有状态服务创建一个单独的 Marathon 实例，以便您可以为“有状态”角色创建静态预留，这样只有有状态的 Marathon 才能获得这些资源。

1b)将服务器约束到特定的集群节点？您可以在 Marathon 中轻松做到这一点，将应用程序限制在特定主机名或具有特定属性值（例如 NFS_Access=true）的任何节点。请参阅马拉松限制。如果您只想在一组特定节点上运行任务，则只需在这些节点上创建静态预留。如果您需要这些节点的可发现性，您应该查看Mesos-DNS和/或Marathon 的 HAProxy 集成。

1c）使用一些分布式FS？许多分布式文件系统提供的数据复制将保证您的数据可以在任何单个节点的故障中幸存下来。坚持使用 DFS 还可以为您安排任务的位置提供更大的灵活性，尽管以网络和本地磁盘之间的延迟差异为代价。Mesos 内置支持从 HDFS uris 获取二进制文件，许多客户使用 HDFS 将执行程序二进制文件、配置文件和输入数据传递给将运行其任务的从属服务器。

2) DRBD、MooseFS、GlusterFS、NFS、CephFS？我听说有客户在 Mesos 中使用 CephFS、HDFS 和 MapRFS。NFS 似乎也很适合。只要您的任务知道如何从放置它的任何节点访问它，对于 Mesos 来说，您使用什么并不重要。

希望有帮助！

于 2015-02-13T06:41:38.163 回答