【问题标题】:Strategy to persist the node's data for dynamic Elasticsearch clusters为动态 Elasticsearch 集群持久化节点数据的策略
【发布时间】:2015-06-12 07:49:02
【问题描述】:

很抱歉,这可能是一个宽泛的问题,但我还没有找到解决这个问题的方法。

我尝试使用 Docker 容器在 MesosMarathon 上运行 Elasticsearch 集群。因此,我构建了一个Docker image,它可以在 Marathon 上启动并通过前端或 API 动态扩展。

这对于测试设置非常有用,但问题仍然是如何保存数据,以便如果集群缩小(我知道这也与索引配置本身有关)或停止,并且我想稍后重新启动(或放大)使用相同的数据。

问题是 Marathon 决定节点运行的位置(在哪个 Mesos Slave 上),所以从我的角度来看,当我尝试持久化重新启动时,如果所有数据都可用于“新”节点,这是不可预测的通过 Docker 卷将数据发送到 Docker 主机。

我想到的唯一的事情是:

  • 使用 HDFS 或 NFS 等分布式文件系统,在 Docker 主机或 Docker 映像本身上安装卷。尽管如此,如果“旧”集群有 8 个节点,而新集群只有 4 个节点,那么在新集群启动期间如何加载所有数据仍然存在问题。

  • 使用 Elasticsearch 的 Snapshot API 保存到网络中某处的公共驱动器。我认为这会带来性能损失...

还有其他方法可以解决这个问题吗?有什么建议吗?不幸的是,我没有找到关于这类主题的好资源。提前非常感谢。

【问题讨论】:

  • Elasticsearch 和 NFS 并不是最好的伙伴 ;-)。你不想在 NFS 上运行你的集群,它太慢了,当存储速度更好时,Elasticsearch 工作得更好。如果你在这个等式中引入网络,你就会遇到麻烦。我不知道 Docker 或 Mesos。但可以肯定的是,我建议不要使用 NFS。使用快照/恢复。
  • @AndreiStefan 非常感谢您对 NFS 的深入了解。如果我们有 100GB 的数据,Snapshot API 真的可行吗?
  • 后续快照是增量的。因此,第一个快照需要一些时间,但其余的快照应该占用更少的空间和更少的时间。总共 100GB 数据还是仅在主节点上 100GB(无副本)?另外请注意,“增量”是指文件级别的增量,而不是文档级别的增量。
  • 快照本身需要所有具有您想要快照的索引的主节点的节点。这些节点都需要访问公共位置(存储库),以便它们可以写入。
  • 是的,就像任何其他命令一样。节点得到它,节点知道全局的集群状态,因此有关于任何其他节点和分片的信息。

标签: elasticsearch docker mesos marathon


【解决方案1】:

Elasticsearch 和 NFS 不是最好的朋友 ;-)。你不想在 NFS 上运行你的集群,它太慢了,当存储速度更好时,Elasticsearch 工作得更好。如果你在这个等式中引入网络,你就会遇到麻烦。我不知道 Docker 或 Mesos。但可以肯定的是,我建议不要使用 NFS。使用快照/恢复。

第一个快照需要一些时间,但其余快照应该占用更少的空间和时间。另外请注意,“增量”是指文件级别的增量,而不是文档级别的增量。

快照本身需要具有您想要快照的索引的主节点的所有节点。这些节点都需要访问公共位置(存储库),以便它们可以写入。这种对同一位置的共同访问通常并不那么明显,这就是我提到它的原因。

【讨论】:

  • 再次感谢您的帮助!
【解决方案2】:

在 Mesos 上运行 Elasticsearch 的最佳方式是使用专门的 Mesos 框架。第一个努力是这个区域是https://github.com/mesosphere/elasticsearch-mesos。有一个更新的项目,即 AFAIK,目前正在开发中:https://github.com/mesos/elasticsearch。我不知道是什么状态,但你可能想尝试一下。

【讨论】:

  • 感谢您的回答。您链接的第一个项目或多或少已经死了,您链接的第二个项目目前正在积极开发恕我直言......我看不出后者比在 Marathon 上运行 Docker 映像“更好”的地方,但也许你可以给一些细节。我认为在扩展等方面运行马拉松更加灵活(和轻量级),但这只是我个人的看法。
  • 拥有一个专门的框架可以为您的任务(=elasticsearch 节点)的生命周期提供很大的灵活性,并允许将它们作为一个组一起管理。例如,您可以进行一组检查并自动扩展您的 elasticsearch 集成。你对这两个项目的状态都是正确的,但是我鼓励你使用第二个项目并最终为它做出贡献:)
猜你喜欢
  • 2018-07-01
  • 1970-01-01
  • 2017-07-19
  • 2022-11-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-01-03
  • 2012-02-02
相关资源
最近更新 更多