elasticsearch - 用于 Elasticsearch Multi-Tenancy SaaS 或单实例和代理的 Docker？

Question

我正在尝试构建 Elasticsearch 即服务的原型(prototype)。我想到了 2 种不同的方法，我想就一种或另一种实现方式征求意见

1. Elasticsearch 的单一安装，以及在顶部添加用户验证的代理层(http 基本身份验证 + 用户帐户以验证使用情况)。 这种方法相对直接，主要挑战是正确配置集群以处理负载和权限，这样就不会因用户无权访问集群管理 API 而导致数据泄漏。

2. 使用 Docker 作为容器，并为每个用户提供一个 elasticsearch 实例。在这种情况下，我将使用 Linux 容器 (Docker) 提供隔离。我仍然需要管理身份验证。

实现两者可能会很好，试一试，看看事情的表现如何。对每种方法的优缺点有何看法？

谢谢!

Answer 1

免责声明:本人是Elasticsearch服务商创始人Facetflow ，目前提供共享集群。

我认为这两种方法各有优点，但可能适合不同类型的客户。 看看其他 SaaS 提供商，比如 MongoDB 提供商 MongoLab，他们基本上最终提供了两种设置(尽管没有使用 Docker)。

所以，在我看来，它们的优缺点是:

共享集群

大多数 Elasticsearch 即服务提供商都以这种方式运作。

优点:

1. 对于大多数只寻求良好搜索和分析的用户来说，价格要便宜得多。
2. 维护更简单，需要监控的集群更少
3. 可集成的 Elasticsearch 版本可能更少。如果您需要与其他系统通信(您这样做)，请编写您自己的插件(我们这样做了，用于身份验证、孤岛、权利、统计等)更少的版本将更容易维护。

缺点:

1. 必须监控嘈杂的邻居，您必须扩展和重新定位索引来处理这个问题。
2. 用户必须从有限的 Elasticsearch 版本列表中进行选择，通常是一个版本。
3. 用户无法获得完整的集群管理员控制权。

使用 Docker 的私有(private)集群

以这种方式工作的一个提供商是 Found .

优点:

1. 用户可能能够部署各种版本的 Elasticsearch
2. 用户可以拥有完整的集群管理员权限
3. 吵闹的邻居不会影响他们的集群，减少您的人工干预

缺点:

1. 综合监控和支持。如果人们可以为所欲为(通过 API 关闭集群)，那么您必须清楚您作为提供者的责任在哪里结束，以及什么让您在晚上醒来。
2. 与多个版本的复杂集成，查看共享集群的优点。
3. 成本更高，因为您必须分配可能并不总是被使用的资源。