我是apache mesos elasticsearch框架的作者。我建议你尝试所有这些方法，并选择你有最好的经验。当谈到性能时，请确保您考虑到了性能要求，然后执行测试。还有其他事情要考虑。我将在问题中提及。
mesos的elasticsearch框架是这四个选项中最具弹性的。elasticsearch节点作为mesos任务运行。如果任何任务失败（硬件或软件故障），它们将在mesos集群中的其他地方重新启动。如果要添加节点（以提高性能）或删除节点（以减少资源使用），只需发送一行curl请求即可。数据非常安全。默认配置（可以重写）将所有数据复制到所有节点。因此，集群可以遭受灾难性事件，只剩下一个节点，而不会丢失任何数据。您还可以使用任何docker卷插件将数据写入外部卷，这样，如果任务结束，数据仍然包含在云卷上。还有一些其他的功能，看看网站。还可以在容器解决方案youtube频道上查看视频。我们还开发了一些工具来帮助简化开发，参见minimesos。
这是完全合理的，但您必须考虑如何协调集群。如果一个或多个容器死亡会发生什么？你能忍受这种损失吗？如果是这样的话，这可能是devops的最佳选择（即，您可以对看起来像真实的集群进行复制和测试）。
这是我唯一反对的选择。这对于开发来说是很好的，但是在生产中您会看到一个重要的性能问题。您可能在另一个vm（云）中拥有一个完整的堆栈vm（vagrant）。开销是不必要的。链接1，链接2。
这是官方推荐的elastic方法，可能为给定的硬件配置提供最高的性能。但由于这些都是静态部署a）许多机器的资源将被浪费（未使用的ram/cpu/等），b）存在一个重要的问题（尤其是在大型组织中！）提供新示例的延迟（与单个api调用相比）和c）如果示例失败，则不会被替换，也不会被修复，直到有人修复它（与自动故障转移相比）。如果您对elasticsearch的需求是固定的，您不需要像devops那样的灵活性，也不介意停机，那么这可能是最简单的方法（但请确保您的es配置正确！）。
因此，如果是我，那么我会考虑用于测试的对接设置，小型poc，可能还有非常小的生产任务。除此之外，我每次都会选择mesos elasticsearch选项。

我的公司或多或少有相同的问题，但可能是一个有点远的道路，当谈到有一个poc等。
目前，我们正在通过marathon在Mesos0.27.1上运行一个带有自定义docker映像的3节点es集群。我们在容器中装载主机卷（路径），这意味着您可以在mesos slave的主机上装载ceph卷。但这是一个相当手工的过程。在我看来，最大的问题是数据安全，因为默认情况下，数据只存储在主机本身，以及应用程序在marathon中缩放时的行为（必须使用约束，以便每个mesos从机只能运行一个节点等）。
几个月前，我们也尝试了上述mesos-es框架，但对当时的框架状况并不满意。从我在文档中看到的情况来看，在过去的几个月里它改进了很多，但是mesos仍然缺少一些重要的特性（例如，对docker卷驱动程序的持久卷支持）。。。但这不是框架问题，而是Mesos问题。
我将很快再尝试一下mesos框架。我特别喜欢设置 --externalVolumeDriver ，这意味着我们现在可以使用docker rbd卷驱动程序（就像我们使用ceph一样）。。。