好问题。下面是mesos中即将推出的一些特性，它们可以改进对有状态服务的支持，以及相应的当前解决方法。
持久卷（0.23）：启动任务时，可以创建一个存在于任务沙盒之外的卷，该卷即使在任务结束/完成后也将在节点上持久存在。当任务退出时，可以将其资源（包括持久卷）提供回框架，以便框架可以再次启动同一任务、启动恢复任务或启动一个新任务，该任务使用前一个任务的输出作为其输入。
当前的解决方法：将您的状态持久化到沙盒外部的某个已知位置，并让您的任务尝试手动恢复它。可以将其持久化在分布式文件系统/数据库中，以便可以从任何节点访问它。
diskisolation（0.22）：对沙盒和持久卷强制执行磁盘配额限制。这确保了存储量大的框架不会阻塞磁盘并阻止其他任务运行。
当前的解决方法：监视带外磁盘使用情况，并运行定期清理作业。
动态保留（0.23）：在启动任务时，您可以保留任务使用的资源（包括持久卷），以确保在任务退出时向您提供这些资源，而不是转到低于其公平份额的框架。
当前解决方法：使用从属服务器 --resources 标记在从属启动时为框架静态保留资源。
至于您的具体用例和问题：
1a）如何组织？您可以使用marathon来实现这一点，也许可以为有状态服务创建一个单独的marathon示例，这样您就可以为“有状态”角色创建静态保留，这样只有有状态的marathon才能保证这些资源。
1b）将服务器约束到特定群集节点？您可以在marathon中轻松地实现这一点，将应用程序约束到特定的主机名或具有特定属性值的任何节点（例如nfs\u access=true）。请参见马拉松约束。如果您只想在一组特定的节点上运行任务，那么只需要在这些节点上创建静态保留。如果您需要这些节点的可发现性，您应该查看mesos dns和/或marathon的haproxy集成。
1c）使用一些分布式fs？许多分布式文件系统提供的数据复制将保证您的数据能够在任何单个节点发生故障时幸存下来。持久化到dfs还可以为您安排任务的位置提供更大的灵活性，尽管这是以网络和本地磁盘之间的延迟差异为代价的。mesos内置了对从hdfs uri获取二进制文件的支持，许多客户使用hdfs将执行器二进制文件、配置文件和输入数据传递给将运行其任务的从机。
2） drbd，moosefs，glusterfs，nfs，cepfs？我听说有客户在mesos中使用cepfs、hdfs和maprfs。nfs看起来也很适合。对mesos来说，使用什么并不重要，只要任务知道如何从它所在的节点访问它。
希望有帮助！