在同一台服务器上实现弹性搜索服务与节点服务器的自动伸缩是个好主意吗？

Question

试图在t3大型服务器上部署一个项目，并进行自动伸缩。

• 我的弹性搜索服务与node和react项目部署在同一系统上（没有使用AWS弹性搜索）。

• 将来会不会面临问题，需要把弹性搜索服务隔离到其他服务器上？

Answer 1

有一个单独的专用服务器来运行Elasticsearch服务器总是很好的，但是由于你使用的是AWS，你可以做一些事情来减少问题。

Elasticsearch是一个有状态的应用程序 与你的应用程序相比 node 和 react 除非你把状态也存储在那里，这不是一个好主意，由于应用程序的无状态性质，自动缩放是非常有用的，因为你可以根据CPU、内存或其他指标按需扩大或缩小实例。

但在Elasticsearch或其他有状态应用的情况下，它变得很棘手，因为当你扩大或缩小实例时，如果在阈值内无法达到，碎片会被重新定位，这可能会导致Elasticsearech集群不平衡。

现在为了尽量减少这些问题。

1. 确保你可以将Elasticsearch指数存储在网络连接的磁盘上，这样当自动缩放带来一个新的实例时，就不会有数据丢失，而新的实例又应该使用早期的网络连接EBS(你的数据存储在那里)。

2. 确保当你根据你的自动缩放策略扩展或缩减实例时，你不会创建一个新的Elasticsearch进程，Elasticsearch进程应该是固定的，并且通过一些人工干预来升级。

3. 如果你必须扩大Elasticsearch集群的规模，那么确保你禁用shard分配以避免前面提到的问题。

这些都是你可能面临的一些已知问题，根据你的配置，可能会有更多的问题，在写答案的时候，我觉得，只要有一个专门的Elasticsearch实例就可以避免这些奇怪的问题。

Answer 2

下面我再补充一下其他答案。

• Elasticsearch如果有足够的RAM来将索引完整地保存在RAM中，那么Elasticsearch的表现是最好的。如果Elasticsearch与NodeApplication竞争RAM，会影响它的性能。
• 从维护性能的角度来看，你应该考虑至少有3个节点的集群。即使这意味着你有更小的机器。如果AWS正在升级基础设施，而你有1台机器，当比0.05%的不可用性命中时，你的搜索就会下降。如果你需要对节点进行维护或进行升级，拥有多台机器将有助于可用性。
• 根据你对Elasticsearch的使用情况和你在索引中更新elete项目的频率，以及你的索引增长的速度，在集群中增加更多的机器节点将有助于增长。

可能还有很多事情需要考虑，但这完全取决于你的应用、预算、SLA等。