【Elasticsearch】Elasticsearch 跨机房部署

1.关键因素考量

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

1.1 网络因素

  • 网络延迟:机房之间的网络延迟应尽可能低(建议 < 10 m s < 10ms <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️⃣ 亚洲、欧洲、美洲用户访问延迟均低于 200 m s 200ms 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 性能指标

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

2.3.2 故障处理实例

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

系统响应

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

2.4 经验总结

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

大数据与AI实验室

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值