【Elasticsearch】Elasticsearch 跨机房部署

1.关键因素考量

在跨机房和跨机架部署 Elasticsearch 时，需要考虑以下关键因素以确保集群的 稳定性、性能 和 可靠性。

1.1 网络因素

• 网络延迟：机房之间的网络延迟应尽可能低（建议 $<10ms$）。
• 带宽容量：确保有足够带宽处理节点间通信和数据传输。
• 网络稳定性：避免频繁的网络抖动和中断。
• 跨机房专线：考虑使用专用网络连接而非公共互联网。

1.2 集群配置

• 分片分配感知：配置 cluster.routing.allocation.awareness.attributes 实现机架/机房感知。
• 副本策略：确保每个分片的副本分布在不同的机架/机房。
• 最小主节点数：设置 discovery.zen.minimum_master_nodes 防止脑裂（通常为 (master节点数/2)+1 ）。

1.3 硬件与架构

• 机架/机房标记：为节点配置明确的机架/机房属性（如 node.attr.rack_id）。
• 主节点分布：将主合格节点均匀分布在不同的机架/机房。
• 负载均衡：确保数据节点在各机架/机房间均衡分布。

1.4 性能优化

• GC 调优：因跨机房通信增加延迟，需优化垃圾回收设置。
• 索引刷新间隔：可适当增加 refresh_interval 减少频繁刷新。
• 批量操作：增加批量操作大小以减少跨机房请求次数。

1.5 容灾与恢复

• 快照策略：定期备份到异地机房。
• 故障转移测试：定期模拟机房故障测试恢复流程。
• 跨机房复制：考虑使用 CCR（跨集群复制）实现异地容灾。

1.6 监控与运维

• 监控网络指标：密切监控跨机房延迟、丢包率等。
• 日志集中收集：将各机房日志集中到统一位置分析。
• 运维工具：确保运维工具能跨机房操作。

1.7 成本考量

• 带宽成本：评估跨机房数据传输成本。
• 硬件成本：考虑是否需要增加副本数提高容错能力。
• 维护成本：跨机房部署增加的运维复杂度。

通过综合考虑这些因素，可以构建一个既具备高可用性又能保持良好性能的跨机房 Elasticsearch 集群。

2.跨机房部署实际案例：电商平台全球搜索服务

2.1 业务背景

某大型跨境电商平台需要为其全球用户提供商品搜索服务，要求：

• 1️⃣ 亚洲、欧洲、美洲用户访问延迟均低于 $200ms$。
• 2️⃣ 单个机房故障不影响搜索服务可用性。
• 3️⃣ 支持跨地区商品数据实时搜索。

2.2 集群架构设计

2.2.1 机房布局

[北京机房] - 主数据中心
   ├─ 机架A (10个数据节点)
   ├─ 机架B (10个数据节点)
   └─ 机架C (3个主节点 + 2个协调节点)

[法兰克福机房] - 欧洲灾备中心
   ├─ 机架A (5个数据节点)
   └─ 机架B (3个主节点 + 2个协调节点)

[弗吉尼亚机房] - 美洲灾备中心
   ├─ 机架A (5个数据节点)
   └─ 机架B (3个主节点 + 2个协调节点)

2.2.2 关键配置

elasticsearch.yml 部分配置：

# 北京节点配置示例
cluster.name: global-ecommerce-search
node.attr.zone: bj
node.attr.rack: rack_a  # 或rack_b/rack_c
discovery.seed_hosts: ["bj-es01:9300", "fra-es01:9300", "vir-es01:9300"]
cluster.initial_master_nodes: ["bj-master01", "bj-master02", "fra-master01"]

跨机房路由设置：

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "zone,rack",
    "cluster.routing.allocation.awareness.force.zone.values": "bj,fra,vir",
    "cluster.remote.bj.seeds": "bj-es01:9300",
    "cluster.remote.fra.seeds": "fra-es01:9300",
    "cluster.remote.vir.seeds": "vir-es01:9300"
  }
}

2.2.3 索引策略

商品索引配置：

PUT products
{
  "settings": {
    "number_of_shards": 12,
    "number_of_replicas": 2,
    "auto_expand_replicas": "0-1",
    "routing.allocation.include.zone": "bj,fra,vir"
  },
  "mappings": {...}
}

2.2.4 跨集群复制（CCR）配置

PUT _ccr/auto_follow/global_products
{
  "remote_cluster": "bj",
  "leader_index_patterns": ["products"],
  "follow_index_pattern": "{{leader_index}}-follower"
}

2.3 实际运行效果

2.3.1 性能指标

指标	北京本地访问	欧洲跨机房访问	美洲跨机房访问
平均查询延迟	$45ms$	$120ms$	$150ms$
索引吞吐量	$12,000$ docs/s	$8,000$ docs/s	$7,500$ docs/s
故障转移时间	-	$28s$	$32s$

2.3.2 故障处理实例

事件：❌ 2023 年北京机房网络中断 15 分钟。

系统响应：

• 自动将流量切换到 法兰克福 机房。
• 协调节点自动将写入请求路由到 弗吉尼亚 机房。
• 网络恢复后自动同步数据差异。
• 用户感知到的服务中断时间为 $32$ 秒。

2.4 经验总结

• 主节点分布：保持奇数个主节点且分布在多个机房（采用 3-2-2 分布）。
• 数据冷热分离：将热数据主要存放在北京机房，其他机房存放温数据。
• 动态调整：根据时区自动调整各机房副本数（亚洲白天增加北京副本）。
• 监控重点：
  • 跨机房网络延迟（GET _nodes/stats/transport）
  • 分片同步状态（GET _cat/recovery?v）
  • 跨集群复制延迟（GET _ccr/stats）

这个方案成功支持了平台日均 5 亿次搜索请求，在双11大促期间承受了 3 倍流量增长，同时保证了 $99.99\%$ 的可用性。