Elasticsearch多租户SaaS或单实例和代理的Docker?
我正在尝试构build一个Elasticsearch即服务的原型。 我已经想到了两种不同的方法,我希望得到一个或另一个实现的意见
-
Elasticsearch的单一安装和顶层的一个代理层添加用户validation(http基本authentication+用户帐户来validation使用情况)。 这种方法是比较直接的,主要的挑战是正确configuration集群来处理负载以及权限,这样用户就不会有数据泄漏,从而无法访问集群pipe理API。
-
使用Docker作为容器,并为每个用户提供一个elasticsearch实例。 在这种情况下,我将通过使用Linux容器(Docker)提供隔离。 我仍然需要pipe理身份validation。
实现这两者可能会很好,玩耍,看看事情的行为。 任何有关每种方法的利弊的意见?
谢谢!
免责声明:我是Elasticsearch服务提供商Facetflow的创始人,它目前提供共享群集。
我认为这两种方法都有优点,但可能适合不同types的客户。 看看其他SaaS提供商,如MongoDB提供商MongoLab,他们基本上都提供了两个设置(尽pipe不使用Docker)。
所以,我看到他们的利弊:
共享群集
大多数Elasticsearch即服务提供商都是这样操作的。
优点:
- 对于大多数用户来说,只要寻找好的search和分析工具,价格就更实惠了。
- 更简单的维护,更less的集群供您监控
- Elasticsearch的潜在版本可以集成在一起。 如果您需要与其他系统(您所做的)进行交stream,请编写您自己的插件(我们为此进行身份validation,孤岛,授权,统计等),更less的版本将更容易维护。
缺点:
- 嘈杂的邻居必须受到监视,你必须调整和重新安置指数来处理这个问题。
- 用户必须从Elasticsearch版本的有限列表中进行select,通常是单个版本。
- 用户没有得到完整的集群pipe理控制。
使用Docker的私有集群
一个这样工作的供应商是Found 。
优点:
- 用户可能可以部署Elasticsearch的各种版本
- 用户可以有完整的群集pipe理访问权限
- 嘈杂的邻居不会影响他们的集群,减less你的人工干预
缺点:
- 复杂的监控和支持。 如果人们可以做任何他们想做的事情(closuresapi上的集群),你必须清楚你作为一个提供者的职责何时终止,什么东西在晚上唤醒你。
- 与多个版本的复杂集成,请参阅共享集群专业人员
- 因为您必须分配可能不总是使用的资源,所以成本更高。