Elasticsearch 最佳实践：在 Elasticsearch 7 前面实现 Ha Proxy 是个好主意吗？

Question

在 Elasticsearch Spark/Hadoop 文档中，我可以阅读以下选项：

es.nodes.wan.only (default : false)

连接器是否用于通过 WAN 处理云/受限环境中的 Elasticsearch 实例，例如 Amazon Web Services。在这种模式下，连接器禁用发现，并且仅在所有操作（包括读取和写入）期间通过声明的 es.nodes 进行连接。请注意，在此模式下，性能会受到很大影响。

我的云提供商在 Elasticsearch 之上放置了一个 Ha 代理。所以，我必须将之前的选项设置为true。

所以基本上，我对这种架构的理解是，我只有一个 URL 端点来连接到 ES，并且由于 Ha Proxy 具有一些高可用性（和负载平衡），但另一方面，它伤害了性能很多吗？

您能否根据您的经验澄清一下，Elasticsearch 之上的 Ha Proxy 是否是一个好习惯（或不是）？

谢谢

Answer 1

所以基本上，我对这种架构的理解是，我只有一个 URL 端点可以连接到 ES，并且由于 Ha Proxy 具有一些高可用性（和负载平衡）

是的，很多项目（我参与过）都会将 HAProxy 放在 Elasticsearch 前面，然后只将请求发送到单个节点进行负载平衡。

但另一方面，它对性能的影响很大？

不，相反。
就像拥有 ELK 堆栈一样，logstash 的监控管道会抛出错误，因为它无法恢复负载均衡器后面的已终止连接。如果您将选项设置为true，则修复方法是禁用发现sniffing => false，就像您的云提供商一样。

您能否根据您的经验澄清一下，Elasticsearch 之上的 Ha Proxy 是否是一种好习惯？

是的，在 ES 前面有一个负载均衡器绝对是个好主意。