在与具有自动缩放功能的节点服务器相同的服务器上实现弹性搜索服务是个好主意吗？
Is implementing elastic search service on same server as node server with auto scaling is a good idea?
正在尝试在具有自动缩放功能的 t3 大型服务器上部署项目。
我将我的弹性搜索服务部署在与节点和反应项目相同的系统上。（不使用 AWS 弹性搜索）
将来会不会遇到问题，我需要将弹性搜索服务隔离到其他服务器？
为 运行 Elasticsearch 服务器提供单独的专用服务器总是很好，但是当您使用 AWS 时，您可以采取一些措施来最大程度地减少问题：
Elasticsearch 是有状态应用程序，与您的 node 和 react 应用程序不同，除非您也将状态存储在那里，这不是一个好主意，并且由于应用程序的无状态性质，自动缩放这非常有用，因为您可以根据 CPU、内存或其他指标按需扩大或缩小实例。
但在 Elasticsearch 或其他有状态应用程序的情况下，它变得棘手，因为当您放大或缩小实例时，如果分片在阈值内无法访问，则会重新定位，这可能导致 Elasticsearch 集群不平衡。
现在为了尽量减少这些问题：
- 确保您可以将 Elasticsearch 索引存储在网络附加磁盘上，以便在自动缩放带来新实例时不会丢失数据，并且新实例再次应使用较早的网络附加 EBS（存储数据的位置）。
确保在根据自动扩展策略扩展或缩小实例时不会创建新的 Elasticsearch 进程，并且 Elasticsearch 进程应该固定并扩展 up/down人工干预。
如果您必须扩展 Elasticsearch 集群，请确保禁用分片分配以避免前面提到的问题。
这些是您可能会遇到的一些已知问题，根据您的配置，可能还会遇到更多问题，在编写答案时我觉得，只需为 Elasticsearch 提供一个专用实例就可以很容易地避免这些奇怪的问题。
我会添加以下其他答案：
- 如果 Elasticsearch 有足够的 RAM 来将索引完整地保存在 RAM 中，那么 Elasticsearch 的性能最佳。如果 Elasticsearch 与 Node/Application 竞争 RAM，则会影响其性能。
- 从 maintenance/performance 的角度来看，您应该考虑至少拥有 3 节点集群。即使这意味着您拥有更小的机器。如果 AWS 正在升级基础设施并且您有 1 台机器，当不可用性低于 0.05% 时，您的搜索就会失败。如果您需要在节点上进行维护或进行多台机器的升级将有助于提高可用性。
- 根据您对 Elasticsearch 的使用以及索引中 update/delete 项的频率，以及索引增长的速度，向集群添加更多 machines/nodes 将有助于增长。
可能还有很多事情需要考虑，但这完全取决于您的应用程序、预算、SLA 等。
正在尝试在具有自动缩放功能的 t3 大型服务器上部署项目。
我将我的弹性搜索服务部署在与节点和反应项目相同的系统上。（不使用 AWS 弹性搜索）
将来会不会遇到问题，我需要将弹性搜索服务隔离到其他服务器？
为 运行 Elasticsearch 服务器提供单独的专用服务器总是很好，但是当您使用 AWS 时，您可以采取一些措施来最大程度地减少问题：
Elasticsearch 是有状态应用程序，与您的 node 和 react 应用程序不同，除非您也将状态存储在那里，这不是一个好主意，并且由于应用程序的无状态性质，自动缩放这非常有用，因为您可以根据 CPU、内存或其他指标按需扩大或缩小实例。
但在 Elasticsearch 或其他有状态应用程序的情况下，它变得棘手，因为当您放大或缩小实例时，如果分片在阈值内无法访问，则会重新定位，这可能导致 Elasticsearch 集群不平衡。
现在为了尽量减少这些问题：
- 确保您可以将 Elasticsearch 索引存储在网络附加磁盘上，以便在自动缩放带来新实例时不会丢失数据，并且新实例再次应使用较早的网络附加 EBS（存储数据的位置）。
确保在根据自动扩展策略扩展或缩小实例时不会创建新的 Elasticsearch 进程，并且 Elasticsearch 进程应该固定并扩展 up/down人工干预。
如果您必须扩展 Elasticsearch 集群，请确保禁用分片分配以避免前面提到的问题。
这些是您可能会遇到的一些已知问题，根据您的配置，可能还会遇到更多问题，在编写答案时我觉得，只需为 Elasticsearch 提供一个专用实例就可以很容易地避免这些奇怪的问题。
我会添加以下其他答案：
- 如果 Elasticsearch 有足够的 RAM 来将索引完整地保存在 RAM 中，那么 Elasticsearch 的性能最佳。如果 Elasticsearch 与 Node/Application 竞争 RAM，则会影响其性能。
- 从 maintenance/performance 的角度来看，您应该考虑至少拥有 3 节点集群。即使这意味着您拥有更小的机器。如果 AWS 正在升级基础设施并且您有 1 台机器，当不可用性低于 0.05% 时，您的搜索就会失败。如果您需要在节点上进行维护或进行多台机器的升级将有助于提高可用性。
- 根据您对 Elasticsearch 的使用以及索引中 update/delete 项的频率，以及索引增长的速度，向集群添加更多 machines/nodes 将有助于增长。
可能还有很多事情需要考虑，但这完全取决于您的应用程序、预算、SLA 等。