我想了解一些有关 ElasticSearch 节点的见解，以便尝试设置适当的高可用性设置:
(免责声明:我对 ES 还很陌生，所以如果我的概念有一些误解，如果您能强调它，我将不胜感激)
当前设置是一个具有三个节点的集群，它们自动在它们之间委派主节点职责，并且所有三个节点都是数据节点。客户端应用程序 (.NET) 被硬编码为将请求定向到一个特定节点，因此当该节点关闭时，客户端应用程序将无法访问整个集群。
主要来 self 从 the ES site 中可以掌握的内容，我可以将无数据节点设置为专用管理节点，以避免数据加载的过程开销。我还可以设置处理搜索和合并开销的客户端节点，并使数据节点保持数据专用。
对于高可用性，似乎首选选项是在客户端使用包含集群中所有节点的连接池，因此如果第一个选项无法访问，它会将请求定向到其他节点。
综上所述，我正在考虑将集群设置为两个无数据、无http 节点作为管理节点，并让它们相互故障转移。另外，设置两个无数据、无主节点作为“入口节点”，同时将当前的 3 个节点保留为无主、无 html，并让它们仅用于数据处理。然后，我将在客户端应用程序上汇集两个入口节点。
因此最终设置将是 2 个主节点、2 个入口节点、3 个数据加载。
这听起来合理吗？
非常感谢您的见解!
最佳答案
如果不了解更多有关应用程序所需性能形状的信息，很难说您提出的架构是否通过了基本的气味测试。您需要详细说明分片复制、预期写入与读取事件比率等，以提供更具体的反馈。
但是...没有任何理由必须将客户端硬连接到特定的 ES 节点，或者除了将请求发送到主节点之外对请求执行任何操作。在主节点以外的任何地方发送请求都是一个坏主意，而且毫无意义:每个请求最终都会路由到主节点，主节点:a)指示一组工作人员(有时是双数据/工作人员，有时只是数据)来查询分片，然后b) 将结果传递回主站，然后主站组装它们并将整体响应负载返回给您的客户端。
将您的两个/任意多个主服务器集中在一个负载均衡器下，并将您的客户端配置为将事件定向到负载均衡器。更干净，性能可能更好，更不用说更容易扩展了。
关于.net - ElasticSearch 高可用性设置，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31710227/