【ELasticsearch】案例：AWS 上 Elasticsearch 对接 NLB / ALB

《ES 负载均衡》系列，共包含以下文章：

• 1️⃣ 搭建有负载均衡 ELB 的 ES 集群
• 2️⃣ 案例：AWS 上 Elasticsearch 对接 NLB / ALB

😊 如果您觉得这篇文章有用 ✔️ 的话，请给博主一个一键三连 🚀🚀🚀 吧 （点赞 🧡、关注 💛、收藏 💚）！！！您的支持 💖💖💖 将激励 🔥 博主输出更多优质内容！！！

场景： 在 AWS VPC 中自管理一个 Elasticsearch 8.x 集群。有 3 个专用主节点（私有子网），5 个数据节点（私有子网），3 个专用协调节点（可放在公有子网或私有子网，通过 NLB / ALB 暴露）。客户端是部署在另一个 VPC 或公网的应用程序。

🚀 NLB（Network Load Balancer）和 ALB（Application Load Balancer）是 AWS（亚马逊云）提供的两种负载均衡器，用于在多个计算资源（如 EC2 实例）之间分配流量。它们在 Elasticsearch 集群架构中扮演流量入口和分发枢纽的关键角色。

1.配置协调节点

• 启动 3 个 EC2 实例（或使用 Auto Scaling Group 确保最小数量）。
• elasticsearch.yml 配置：

  cluster.name: my-production-cluster
  node.name: ${HOSTNAME}
  network.host: 0.0.0.0 # 或绑定具体私网IP
  http.port: 9200
  discovery.seed_hosts: ["master-node-1-ip", "master-node-2-ip", "master-node-3-ip"] # 指向主节点
  cluster.initial_master_nodes: ["master-node-1-name", "master-node-2-name", "master-node-3-name"] # 首次启动需要
  node.roles: [ ]  # ES 7.8+ 空角色表示只做协调节点 （coordinating only）
  # 或者显式配置 （效果相同）
  # node.roles: [ remote_cluster_client, coordinator ]
  xpack.security.enabled: true # 启用安全
  # 配置用户/密码或 TLS 证书等
  

• 确保安全组允许协调节点：
  • 入站：来自 ELB 安全组的 TCP 9200（或 ALB 使用的端口）。
  • 入站：来自其他 ES 节点（主、数据、协调）的 TCP 9300（内部节点间通信端口）。
  • 出站：访问其他 ES 节点的 TCP 9300，访问 KMS（如果加密）等所需端口。
• 确保协调节点能访问主节点（通过安全组和网络路由）。

2.创建 NLB 或 ALB

• 选择 NLB（Layer 4 TCP）：
  • 优点：性能高，延迟低，保持源 IP（对 ES 审计或基于 IP 的安全有用），支持静态 IP / 弹性 IP。非常适合纯粹的 API 负载均衡。更常用。
  • 缺点：不能做高级 HTTP 路由/基于路径的路由（ES 通常不需要）。
• 选择 ALB（Layer 7 HTTP / HTTPS）：
  • 优点：可以处理 HTTPS 终止、基于路径的路由（如果同一个集群暴露多个 HTTP 服务）、高级健康检查（基于 HTTP 状态码）。
  • 缺点：性能略低于 NLB，修改 HTTP Headers（会丢失原始客户端 IP，除非配置 X-Forwarded-For，但 ES 需要额外配置才能记录真实 IP），通常按请求 / LCU 收费。
• 创建步骤（以 NLB 为例）：
  • 选择 Network Load Balancer。
  • 配置监听器：TCP:9200 （或自定义端口）。
  • 配置目标组（Target Group）：
    • 协议：TCP，端口：9200。
    • 目标类型：Instance。
    • 将 3 个协调节点的 EC2 实例注册到该目标组。
  • 健康检查配置（⭐ 极其重要）：
    • 协议：TCP（简单检查端口连通性） 或 HTTP（推荐，更准确）。
    • 如果使用 HTTP：
      • 健康检查路径：/_cluster/health?local=true 或 /_cluster/health?level=cluster（后者检查全局状态，可能过重）。
      • 健康检查端口：traffic port（即 9200）。
      • 成功响应码：200。
      • 关键：设置 ?local=true 避免 NLB 健康检查请求被转发到其他节点，导致健康检查失败误判。local=true 只检查接收请求的协调节点本地的状态。
  • 配置安全组：允许客户端访问 NLB 的监听器端口（TCP 9200）。

3.客户端访问

• 客户端应用程序不再连接任何具体的 ES 节点 IP。
• 客户端配置其 Elasticsearch 客户端库的连接地址为：http(s)://<nlb-dns-name>:9200 （或 ALB 的地址）。
• 客户端配置认证信息（用户名/密码、API Key、TLS 证书等）。

4.工作流程

• 客户端发起请求到 my-es-nlb-12345.elb.us-west-2.amazonaws.com:9200。
• AWS NLB 根据配置的负载均衡策略（如轮询）选择目标组中的一个协调节点（例如 coord-node-2）。
• NLB 将 TCP 连接/请求转发到 coord-node-2:9200。
• coord-node-2 接收到请求：
  • 进行认证授权（如果启用安全）。
  • 解析请求（例如一个搜索请求）。
  • 确定需要查询哪些索引的哪些分片（主分片或副本分片）。
  • 将子查询并行发送到持有这些分片的数据节点（data-node-1，data-node-3，…）的 9300 端口（Transport 协议）。
  • 等待数据节点返回结果。
  • 聚合、排序、处理来自各个数据节点的结果。
  • 将最终结果返回给 NLB。
• NLB 将结果返回给客户端。
• 如果 coord-node-2 因健康检查失败被 NLB 标记为不健康，NLB 后续请求将自动路由到健康的 coord-node-1 或 coord-node-3。

5.关键点总结

• ELB 是入口：提供稳定、高可用的访问点，负载均衡，故障转移。
• 协调节点是工作者：专门负责处理客户端请求的协调工作。ELB 只对接协调节点。
• 数据节点专注数据：只通过 9300 端口接收来自协调节点（或其他节点）的内部请求，处理实际的分片操作。
• 主节点专注管理：几乎不参与数据路径，只处理集群状态、索引管理、节点发现等控制面操作。绝对不要暴露给客户端或 ELB。

这种架构清晰分离了关注点，显著提升了 Elasticsearch 集群在公有云上的可用性、可扩展性、性能和可运维性。

6.拓展：NLB & ALB 介绍

6.1 核心概念对比

特性	NLB（网络负载均衡器）	ALB（应用负载均衡器）
OSI 层	第 $4$ 层（传输层 - TCP/UDP）	第 $7$ 层（应用层 - HTTP/HTTPS）
协议支持	TCP，UDP，TLS	HTTP，HTTPS，HTTP/2，WebSocket
性能	⭐⭐⭐⭐ 超高性能（处理数百万请求/秒）	⭐⭐⭐ 高性能（适合HTTP应用）
延迟	超低延迟（微秒级）	较低延迟（毫秒级）
源 IP 保留	✅ 保留原始客户端 IP	❌ 默认不保留（需通过 X-Forwarded-For 获取）
静态 IP	✅ 支持弹性 IP	❌ 仅提供 DNS 域名
适用场景	非 HTTP 协议、高性能需求、源 IP 敏感型应用	HTTP/HTTPS 应用、基于路径/主机的路由

6.2 在 Elasticsearch 架构中的作用

▶ NLB 典型工作流

• 优势：
  • 零协议解析，直接转发原始 TCP 数据包
  • 保留客户端 IP → 便于 Elasticsearch 审计日志分析
  • 支持长连接（Keep-Alive）→ 适合 ES 的持久 HTTP 连接

▶ ALB 典型工作流

• 优势：
  • SSL/TLS 终止 → 减轻 ES 节点证书管理负担
  • 基于路径的路由（例：/es/* 转发到 ES，/kibana/* 转发到Kibana）

6.3 为什么 Elasticsearch 更常用 NLB ？

需求	NLB 方案	ALB 方案
客户端真实 IP 记录	✅ 原生支持	❌ 需解析 HTTP 头
非 HTTP 协议支持	✅ 原生支持 Transport 协议	❌ 仅限 HTTP
超高性能搜索请求	✅ 100万+ QPS	⚠️ 受 HTTP 解析限制
长连接优化	✅ 无损透传	⚠️ 可能重建连接
成本	按流量/小时计费	按 LCU（请求数+流量）计费

📌 结论：

• 90% 的 ES 生产集群选择 NLB：因 TCP 透传、源 IP 保留、高性能优势
• 特殊场景用 ALB：需统一 HTTPS 入口或多服务路由时（如同时暴露 ES 和 Kibana）

6.4 技术参数详解（以 AWS 为例）

6.4.1 NLB 关键配置

类型: Network Load Balancer
协议: TCP
端口: 9200
目标组: 
  协议: TCP 
  端口: 9200
  目标: [协调节点IP列表]
健康检查: 
  协议: HTTP
  路径: /_cluster/health?local=true
  端口: 9200

6.4.2 ALB 关键配置

类型: Application Load Balancer
协议: HTTPS (SSL证书绑定)
监听规则:
  - 条件: 路径 = /es/*
    动作: 转发至目标组-es
  - 条件: 路径 = /kibana/*
    动作: 转发至目标组-kibana
目标组-es: 
  协议: HTTP
  端口: 9200
健康检查: 
  协议: HTTP
  路径: /_cluster/health

6.5 多云平台等效服务

云平台	NLB 等效服务	ALB 等效服务
AWS	Network Load Balancer	Application Load Balancer
Azure	Load Balancer（Standard）	Application Gateway
GCP	TCP Proxy Load Balancing	HTTP(S) Load Balancing
阿里云	网络型 CLB	应用型 ALB

6.6 实战选择建议

💡 经验法则：

• 纯 Elasticsearch API 访问 → 必选 NLB
• 同时暴露 Kibana 且需单域名访问 → 用 ALB 统一入口
• 混合云场景 → 优先使用云厂商的 4 层 LB 服务

通过正确选择 NLB / ALB，您将获得：

• ✅ 流量自动故障转移
• ✅ 水平扩展能力
• ✅ DDoS基础防护
• ✅ 精细化监控（如 AWS CloudWatch）