Elasticsearch 多可用区高可用架构设计方案

最新推荐文章于 2025-10-15 19:38:14 发布

原创最新推荐文章于 2025-10-15 19:38:14 发布 · 1.1k 阅读

22 ·

CC 4.0 BY-SA版权

文章标签：

#elasticsearch #多可用区 #高可用 #架构设计 #方案 #学习

搜索引擎专栏收录该内容

55 篇文章

订阅专栏

在生产级 Elasticsearch 部署中，多可用区（Multi-AZ）高可用架构 是保障系统容灾能力、避免单点故障的核心设计。当一个机房或可用区（Availability Zone）发生网络中断、电力故障或硬件损坏时，集群仍能继续提供服务。

本文将为你提供一份 全面、可落地的 Elasticsearch 多可用区高可用架构设计方案，涵盖架构设计、节点分布、分片策略、故障转移、监控与最佳实践。

一、目标与核心需求

目标	说明
✅ 高可用（HA）	单可用区故障时，集群仍可读写
✅ 数据冗余	副本跨可用区存储，防止单点数据丢失
✅ 自动故障转移	主分片故障后自动选举新主
✅ 读写性能均衡	避免跨区网络瓶颈
✅ 可维护性	支持滚动升级、扩容、监控

二、架构设计原则

原则	说明
🟢 奇数个主节点候选	3 或 5 个，避免脑裂
🟡 主节点跨可用区分布	确保多数派存活
🔵 数据副本跨可用区	主副本不在同一 AZ
🟣 避免跨区写入热点	写请求由本地协调节点处理
⚪ 网络延迟可控	同城多可用区（延迟 < 5ms）

三、典型部署架构（3 可用区）

                          ┌─────────────────┐
                          │   Load Balancer  │
                          │ (跨可用区访问)   │
                          └────────┬────────┘
                                   │
           ┌───────────────────────┼───────────────────────┐
           │                       │                       │
    ┌──────▼──────┐        ┌──────▼──────┐        ┌──────▼──────┐
    │  AZ-East-1  │        │  AZ-East-2  │        │  AZ-East-3  │
    └──────┬──────┘        └──────┬──────┘        └──────┬──────┘
           │                       │                       │
    ┌──────▼──────┐        ┌──────▼──────┐        ┌──────▼──────┐
    │ Master-1    │        │ Master-2    │        │ Master-3    │
    │ Data-1      │        │ Data-2      │        │ Data-3      │
    │ Ingest-1    │        │ Ingest-2    │        │ Ingest-3    │
    │ Coord-1     │        │ Coord-2     │        │ Coord-3     │
    └─────────────┘        └─────────────┘        └─────────────┘
           │                       │                       │
    ┌──────▼──────┐        ┌──────▼──────┐        ┌──────▼──────┐
    │  Shared Storage │◄──────┤  Snapshot Repo   │─────►│  Shared Storage │
    │ (NFS/S3)     │        │ (备份与恢复)     │      │ (NFS/S3)     │
    └─────────────┘        └─────────────────┘      └─────────────┘

✅ 所有可用区通过内网高速互联（如 AWS 的 Placement Group、阿里云 vSwitch）。

四、节点角色与分布策略

1. 节点类型分布

节点类型	数量	分布策略
主节点候选（Master-Eligible）	3	每个 AZ 1 个
数据节点（Data Node）	N（每 AZ 均匀分布）	每 AZ 至少 1 个
协调节点（Coordinating Only）	M	每 AZ 部署，供本地应用访问
Ingest 节点	K	每 AZ 部署，避免跨区预处理
专用协调节点	可选	用于跨集群查询

✅ 推荐：角色分离，避免“全能节点”。

2. 主节点选举容错能力

主节点数	可容忍故障 AZ 数
3	1
5	2

✅ 3 个主节点是最小高可用配置。

五、分片与副本跨可用区策略

1. 使用 `awareness` 属性实现机架感知

在每个节点的 elasticsearch.yml 中配置：

# AZ-East-1
node.attr.zone: east-1

# AZ-East-2
node.attr.zone: east-2

# AZ-East-3
node.attr.zone: east-3

启用集群感知：

PUT /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "zone"
  }
}

2. 副本分配行为

Elasticsearch 自动确保：
- 主分片与副本不在同一 zone
- 副本均匀分布在不同可用区
例如：主在 east-1，副本在 east-2 和 east-3

✅ 实现 跨可用区数据冗余

3. 写入与读取流程

写入（Write）

写入必须跨区同步，延迟略高；
但保证数据安全。

读取（Search）

协调节点优先选择本地副本，降低延迟；
支持 preference=_local 强制本地优先。

六、故障场景与恢复

场景 1：单可用区完全宕机（如 AZ-East-1）

影响：
- 该 AZ 所有节点离线；
- 部分主分片不可用；
- 但副本在其他 AZ 存在。
恢复过程：
1. 集群状态变为 yellow（副本未分配）；
2. 主节点（仍 2 个在线）选举新主；
3. 将其他 AZ 的副本提升为主；
4. 重新分配新副本（待 AZ 恢复）；
5. 集群恢复 green 状态。

✅ 服务不中断，仅写入性能略有下降。

场景 2：主节点所在 AZ 故障

若 Master-1 所在 AZ 故障：
- 剩余 Master-2 和 Master-3 组成多数派；
- 自动选举新主；
- 集群控制平面正常。

场景 3：网络分区（Split Brain 防护）

使用 discovery.zen.minimum_master_nodes（7.x）或默认协调层（8.x）；
配置 quorum = N/2 + 1；
避免两个子集群同时认为自己是主。

七、备份与灾备（Backup & DR）

1. 快照仓库（Snapshot Repository）

使用 跨可用区共享存储：
- AWS S3
- 阿里云 OSS
- NFS 高可用集群

PUT /_snapshot/my_backup
{
  "type": "s3",
  "settings": {
    "bucket": "es-snapshots-prod",
    "region": "cn-east-1"
  }
}

✅ 快照存储独立于集群，防止单点丢失。

2. 跨区域复制（可选）

使用 CCR（Cross-Cluster Replication） 将数据同步到异地集群（如华东 → 华北）；
实现 异地容灾。

八、性能优化建议

场景	优化方案
写入延迟高	增加副本数，使用 `wait_for_active_shards=1` 降低一致性要求
读取跨区	使用 `preference=_local` 优先本地副本
协调节点负载高	增加协调节点数量
分片不均	检查 `awareness` 配置是否生效

九、监控与告警

1. 关键监控指标

指标	说明
`cluster.status`	green/yellow/red
`unassigned_shards`	是否有未分配分片
`node.attr.zone` 分布	主副本是否跨区
`jvm.mem.heap_used_percent`	内存压力
`thread_pool.write.queue`	写入阻塞

2. 告警规则

cluster.status == red
unassigned_shards > 0 for 5m
node count in one AZ == 0

十、最佳实践 checklist ✅

项目	建议
主节点数	3 或 5，奇数
主节点分布	每 AZ 1 个
启用 `awareness.attributes`	确保副本跨区
快照仓库	使用 S3/OSS 等共享存储
网络	同城多可用区，延迟 < 5ms
监控	监控节点、分片、磁盘
滚动升级	按 AZ 顺序升级，避免同时升级多个

十一、扩展建议

场景	建议方案
跨地域双活	使用 CCR + DNS 切换
读写分离	写入主区域，读取边缘区域
Serverless 架构	使用 Elastic Cloud 多可用区部署
成本优化	Warm 节点使用低配机型