【ELasticsearch】搭建有负载均衡 ELB 的 ES 集群

在公有云上为 Elasticsearch 集群封装一层 ELB（Elastic Load Balancer）或类似的负载均衡器，核心目的是 解耦、简化客户端访问、提高可用性、增强可维护性。

1. 为什么要这样设计（封装 ELB）?

• 单一入口点
  • 简化客户端配置：客户端应用无需知道集群内部有多少个节点、哪些节点是协调节点、哪些节点宕机了。它们只需要配置一个稳定的 ELB DNS 名称或 IP 地址即可。这大大简化了客户端的连接逻辑和配置管理。
• 高可用性
  • 故障转移：如果某个协调节点（或普通节点）发生故障、进行滚动重启或维护，ELB 的健康检查机制能够自动检测到该节点不健康，并将其从后端服务器池中移除，将流量无缝路由到其他健康的节点。客户端几乎感知不到后端节点的变化。
  • 避免单点故障：ELB 本身通常是高可用的（跨可用区部署），并且将流量分散到多个后端节点，避免了客户端直接连接到一个可能宕机的节点导致服务中断。
• 负载均衡
  • 流量分发： 将传入的搜索、索引等请求均匀地（根据配置的策略，如轮询、最少连接数等）分发到集群中的多个协调节点或普通节点上。这防止了单个节点因请求过多而过载，充分利用集群资源，提高整体吞吐量和响应速度。
• 可扩展性
  • 当需要水平扩展集群（增加节点）时，只需将新节点（尤其是协调节点）注册到 ELB 的后端目标组即可。客户端配置无需任何修改，新节点就能立即开始分担负载。
  • 同样，缩减集群时，移除节点后 ELB 会自动停止向其发送流量。
• 安全与隔离
  • 提供了一个额外的网络边界。ELB 可以承担 SSL / TLS 终止、基础访问控制（如安全组 / IP 白名单）等任务，减少直接暴露 ES 节点给外部网络的风险。可以将 ES 节点部署在私有子网，仅允许 ELB 访问，增强安全性。
• 简化运维
  • 节点维护、升级、替换对客户端透明。运维人员可以更自由地管理后端节点，而不用担心影响客户端连接。
  • 集中管理访问入口和流量策略。

2.如果没有这层负载均衡呢 ?

• 客户端复杂性剧增
  • 客户端必须配置集群中所有可能的协调节点（或所有节点）的地址列表。
  • 客户端需要实现 节点发现机制：定期获取集群状态，了解哪些节点在线、哪些是协调节点（如果用了专属协调节点角色）。Elasticsearch 客户端库（如 Java High-Level REST Client）虽然内置了嗅探功能，但这增加了客户端逻辑的复杂度和资源消耗（网络请求、解析）。
  • 客户端需要实现 故障转移和重试逻辑：当连接某个节点失败时，客户端需要尝试列表中的下一个节点。这不是所有客户端库都完美支持的，且需要仔细配置。
• 可用性风险
  • 单点故障敏感：如果客户端配置的初始连接节点列表不全，或者某个关键节点宕机而客户端未能及时感知或切换到其他节点，就会导致服务中断。
  • 滚动重启/维护困难：在维护期间（如节点升级），如果客户端恰好连接到了即将重启的节点，请求会失败。需要更复杂的协调或容忍客户端错误。
• 负载不均风险
  • 客户端实现的连接策略可能不够智能，导致某些节点负载过高，而其他节点闲置。尤其在小规模客户端或特定访问模式下更明显。
• 可扩展性挑战
  • 每次添加或移除节点，都需要更新所有客户端的配置（节点列表），这在大型分布式系统中是运维噩梦，容易出错且效率低下。
• 安全暴露面增大：更多节点需要暴露在客户端可访问的网络中，增加了安全加固的复杂度和攻击面。

3.外来的请求会打到集群哪一个节点上 ？

• 默认情况（无专属协调节点）：在标准的 Elasticsearch 集群中，默认情况下所有节点都具备 master、data、ingest 角色，同时也隐含了 coordinating（协调）角色。这意味着任何节点都能接收客户端请求。如果客户端（或 ELB）将请求发送到一个普通的数据节点，该节点会：
  • 1️⃣ 解析请求。
  • 2️⃣ 确定涉及哪些分片（主分片或副本分片）。
  • 3️⃣ 将子请求转发给持有这些分片的其他数据节点。
  • 4️⃣ 汇总结果，返回给客户端。该节点承担了协调工作。
• 使用专属协调节点：为了优化性能（特别是大型集群或高负载场景），可以配置专属协调节点。这些节点设置：

  node.roles: [ remote_cluster_client, coordinator ] # ES 7.8+
  # 或者更传统的显式禁用其他角色：
  node.roles: [ ] # ES 7.8+ 空角色默认就是协调节点
  # 或者 （旧版本方式，效果类似）
  node.master: false
  node.data: false
  node.ingest: false
  

  • 这些节点不存储数据，不参与主节点选举，不执行预处理管道。
  • 它们只负责接收客户端请求、分解查询、分发子请求到数据节点、聚合结果、返回响应。
  • 优势：解放了数据节点和主节点的 CPU、内存资源，让它们专注于核心的数据存储、检索和管理任务。协调节点更容易横向扩展，处理大量并发客户端连接。这是生产环境的最佳实践，尤其是规模较大的集群。

结论： 无论是否有专属协调节点，外来请求最初都会打到接收该请求的那个节点上。这个节点可能是：

• 一个普通的数据节点（默认角色）。
• 一个专属的协调节点（如果配置了）。
• 甚至是一个主节点（虽然不推荐直接连接主节点）。

4.优先是专属协调节点吗？

• 强烈推荐优先使用专属协调节点！ 原因如上所述：性能优化、资源隔离、更好的扩展性。
• ELB 的目标：ELB 配置的目标就是将所有客户端的流量引导到这些专属协调节点上（或者在没有专属协调节点时，引导到所有普通节点上）。这样确保了请求由最适合处理协调工作的节点来处理。
• “优先” 的含义：在 ELB 配置中，你会将后端服务器池（目标组）明确指定为这些专属协调节点的 IP & 端口。ELB 只会在这些协调节点之间进行负载均衡。客户端无法（也不应该）直接访问数据节点或主节点（除非特殊管理需求）。

5.ELB 需要对接所有节点吗，还是协调节点就可以了？

• 只需要对接协调节点！
• 绝对不要将 ELB 对接所有节点（包括数据节点、主节点）：
  • 性能浪费/干扰：让数据节点处理协调工作消耗其本应用于数据操作的宝贵资源（CPU、内存、网络）。主节点尤其脆弱，应避免处理任何用户请求流量。
  • 潜在风险：意外的大量请求打到主节点可能导致集群不稳定（主节点负责集群状态管理、索引创建等关键操作）。
  • 安全：减少了不必要的网络暴露面。
• 🚀 最佳实践：在集群中部署一组专属协调节点（数量根据负载预估和冗余需求确定，通常至少 $2-3$ 个）。ELB 的后端目标组只包含这些专属协调节点的 IP 地址和端口（通常是 $9200$）。所有外部客户端流量都通过 ELB 发送到这些协调节点。