跨AZ高可用之Elasticsearch实践

最新推荐文章于 2025-03-13 21:41:27 发布
原创 最新推荐文章于 2025-03-13 21:41:27 发布 · 1.6k 阅读 · 5 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#elasticsearch #业界参考 #可用性 #最佳实践 #开源软件

本文探讨了Elasticsearch在不同云平台如AWS、阿里云上的跨可用区（AZ）部署策略，包括多AZ多活、数据均衡、数据损失保护等方案。详细介绍了AWS的区域感知（zone awareness）和专用主节点（Dedicated Master Nodes）实践，以及阿里云的跨地域备份和多副本使用。同时，文章分析了tribe节点作为多集群代理层的优缺点，以及当前业务单AZ部署的风险。

作者：SUNNY
时间：2018-01-04

AZ，AWS提出的，可用区（Availability Zone），在每个区域（Region）都有多个可用区。AZ之间物理隔离，独立供电，一个AZ故障，不会影响另外一个AZ，但AZ之间是连通，且网络耗时低。简单可以将AZ理解为独立机房或逻辑机房，这样可以利用AZ的隔离性，对业务进行跨AZ部署，实现高可用。

本文先是简单介绍了跨AZ服务部署的一些方案，之后介绍了调研的Elasticsearch跨AZ部署方案，最后介绍了在当前业务场景下，所采取的一个部署方案实战。

1. Elasticsearch介绍

Elasticsearch是一开源搜索引擎，可以为站点提供实时分析搜索服务；也可以与Logstash、Kibana一起进行日志分析展现（ELK）。 官方网址：https://www.elastic.co。 在我们业务使用中，主要是提供实时商品搜索服务，当前处于业务发展初期，有多个Elasticsearch集群，总体流量较小。

2. 跨AZ部署方案概览

在我理解，按照服务是否有数据，可以分为无状态服务、有状态服务。 无状态服务，像接入层，业务逻辑模块等。 有状态服务，像存储，缓存，消息队列，id分配等。 针对无状态服务，每个AZ按照集群方式部署即可，这是实现该类服务高可用的一个基本措施。 对于接入层，一般有2种方式： 1）购买ELB时，可以选择跨AZ。这样ELB可以将流量分配到不同的AZ； 2）通过DNS解析控制，比如针对某些地区用户可以解析到第一个AZ对应的公网IP，其他地区可以解析到第二个AZ对应的公网IP。 针对有状态服务，由于存在数据一致性、灾备等问题，一般会是主备方式进行部署，如果对性能要求较高，可能还会提供一个读的实例。 但针对id分配服务来说，是一个特例，虽然自己本身是有数据，但由于是预分配，因此可以采用类集群方式部署。

3.Elasticsearch跨AZ部署

AWS做法 AWS实现了Ela

最低0.47元/天 解锁文章
智能运维
关注
高可用elasticsearch集群搭建
lmj3732018的博客
11-23 1万+
Elasticsearch（简称为ES）是一个开源的分布式搜索和分析引擎，构建在Apache Lucene搜索引擎库之上。它提供了一个强大的全文搜索和实时分析功能，适用于大规模的数据存储、检索和分析。
【实战ES】实战 Elasticsearch：快速上手与深度实践-8.1.1基于ES的语义搜索（BERT嵌入向量）
kngines
03-12 2097
【实战ES】实战 Elasticsearch：快速上手与深度实践-8.1.1基于ES的语义搜索（BERT嵌入向量）
Elasticsearch集群跨机房迁移方案
一只小白
05-17 1544
目录 背景介绍 1 A机房elasticsearch集群基本情况 2 在B机房完成elasticsearch集群扩容 2.1 扩容规划 2.2 启动非master节点 2.3 通知业务修改集群连接地址 3 将索引数据排空迁移至B机房 4 下线A机房data节点 5 master节点切割 5.1 关闭集群自动均衡 5.2 从节点pending master切割 5.3 主节点required master切割 6 恢复集群配置 7 修改B机房节点配置，不需要重启 背景介绍
Pod跨AZ高可用
青烟绕指柔的博客
10-24 1131
在很多情况下，如果不对 Pod 进行限制，那么可能存在一个节点多个同一个 Deployment 的所有 Pod，那么在这种情况下，如果机器宕机了，整个 Deployment 可能就不存在可用的 Pod，导致整个服务挂掉。同理，如果 AZ 故障（地震、火灾等）了，一个 Deployment 的所有 Pod 都在同一个 AZ当中，也是会产生服务不可用的情况，所以我们在大多数情况下，都需要将 Pod 跨 AZ 以实现服务的高可用。Pod 跨 AZ 使用 Kubernetes 中的反亲和性就可以完成。
CentOS7下Elasticsearch高可用集群方案-完整部署记录（个人珍藏版）
08-29
本篇文章详细记录了CentOS7下Elasticsearch高可用集群方案-完整部署过程，可作为线上长期的实操手册。特在此分享，希望能帮助到有用到的朋友。
跨AZ部署最佳实践之Elasticsearch
焦振清
07-18 1849
作者：焦振清 跨AZ部署是实现服务高可用较为有效的方法，同时也极具性价比。如果实现了跨AZ部署，不仅可以消除服务中的单点，同时还可以逐步建设如下能力：服务隔离，灰度发布，N+1冗余，可谓一举多得。因此，接下来我们会对有状态的开源软件进行一系列的跨AZ部署的介绍，从Elasticsearch开始。 最佳实践 首先，我们介绍下Elasticsearch基于跨AZ部署的最佳实践，下图1是一个...
大数据实操篇 No.15-Elasticsearch集群高可用部署（含Elasticsearch head+Kibana）
pezynd的专栏
01-20 2012
第1章 ELK简介 ELK（Elasticsearch、Logstash、Kibana）提供了一整套日志分析解决方案，其中elasticsearch是开源分布式搜索引擎。Logstash是一个开源的日志采集工具。Kibana也是开源的数据分析可视化工具。三者结合，Logstash采集系统日志信息后，上传到Elasticsearch中，kibana在利用Elasticsearch分布式高效的检索引擎，将数据可视化的展示到Web界面上。 对于一些中小型的系统，可以用ELK快速搭建一套日志分析系统。本篇文章为
服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、AZ内的高可用、单元化、跨region容灾、异地多活容灾
辣香牛肉面的博客
11-06 847
‌和‌‌是微服务架构中常用的两种技术手段，它们在应对系统异常和资源分配方面有着不同的作用和机制。
【实战ES】实战 Elasticsearch：快速上手与深度实践-8.2.1AWS OpenSearch无服务器方案
kngines
03-13 939
【实战ES】实战 Elasticsearch：快速上手与深度实践-8.2.1AWS OpenSearch无服务器方案
ElasticSearch高可用集群环境搭建和分片原理
art_code的博客
01-21 346
ElasticSearch高可用集群环境搭建和分片原理 1、ES是如何实现分布式高并发全文检索 2、简单介绍ES分片Shards分片技术 3、为什么ES主分片对应的备分片不在同一台节点存放 4、索引的主分片定义好后为什么不能做修改 5、ES如何实现高可用容错方案 6、搭建Linux上环境三台ES高可用集群环境 ES是如何解决高并发 ES是...
Elasticsearch的分布式架构、负载均衡、高可用以及容错性看这一篇就够了
02-24
开箱即用，简单粗暴Elasticsearch天然支持分布式和集群，开箱即用，零配置，零改动。自动分片一个index默认5个primaryshard，那么我们创建一个document，他给我们分配到哪个shard上了呢？搜索的时候又是怎么知道我们搜的这个document再哪个shard上呢？这都是es内部为我们做好的，开发者完全不用关心。自动集群发现英文：clusterdiscovery。我们本机启动两个es实例，也就是两个node节点，默认集群名称是elasticsearch，所以他会自动将这两个node凑成一个集群，我们什么都不用配置，它自动发现。shard负载均衡假设我们有1个index，
阿里云高可用的跨AZ部署方案.docx
10-11
阿里云高可用的跨AZ部署方案.docx
多AZ的高可用方案
热门推荐
王飞Vincent-Fei的AWS专栏
03-12 1万+
AWS在每个Region都有多个AZ（Availability Zone)多个AZ之间物理隔离,供电也是独立的，这样部署业务时，可以充分利用多AZ实现高可用方案，避免亚马逊底层机房事故导致业务中断。（1）前端ELB层，可以将ELB设置成跨多个AZ，即将需要的子网（Available Subnet)添加进ELB就行，（点击Available Subnet前面的绿色加号按钮），这个时候，每个AZ至少选择
ElasticSearch核心语法及集群高可用搭建
m0_60162373的博客
03-25 1132
一、ElasticSearch文档批量操作实现 （这里只是批量操作文档，查询文档的操作在后面会补充） 1.批量获取文档数据 批量获取文档数据是通过_mget的API来实现的 (1)在URL中不指定index和type 功能说明 ： 可以通过ID批量获取不同index和type的数据 请求方式：GET 请求地址：_mget 请求参数： docs : 文档数组参数 ...
ApsaraDB For SQL Server Multi-AZ 高可用版数据库常用功能使用介绍
weixin_33913377的博客
02-12 286
ApsaraDB For SQL Server Multi-AZ 高可用版数据库使用介绍 引言 RDS SQL Server Multi-AZ 高可用版涵盖了SQL Server 2008 R2标准版和企业版、SQL Server 2012 标准版和企业版、SQL Server 2014 标准版和企业版、SQL Server 2016 标准版和企业版 。...
12月13日云栖精选夜读：如何在阿里云上构建高可用的跨AZ部署方案
weixin_33851177的博客
12-13 335
引言 针对企业而言不管业务是不是在云上服务的稳定和连续性总归是无法回避的话题为了降低不可抗力因素对服务提供造成的影响我们有了高可用性和容灾的概念。虽然我们的产品已有很高的可用性我们仍不能忽视构建服务高可用性和容灾的重要性。 热点热议 如何在阿里云上构建高可用的跨AZ部署方案 作者：技术小能手 阿里安全技术平台资深专家玄泰解密：“如何防止信息泄露” 作...
RocketMQ基于Kosmos实现AZ级高可用
2301_80257403的博客
02-01 1210
(2) Broker组件作为消息中转角色，负责存储消息，转发消息，采用Master/Slave部署模式，在两个可用区上交叉部署（如broker-a的Master部署在可用区1上，Slave节点部署在可用区2上，broker-b的Master部署在可用区2上，Slave节点部署在可用区1上），消息发送到Master节点后会实时同步到Slave节点，保证每个可用区保存了全量的消息。如图所示，我们首先通过kwok创建了20个大规模集群，每个集群包含5000个节点，我们将这些集群使用Kosmos进行纳管。
Longhorn跨AZ实现存储高可用
jiayu的博客
11-12 908
使用longhorn的backup/restore功能，但是随着数据量的增加，RTO时间具体需要多久待测试，且由于backup是定时或某个时刻手动触发的，RPO大小取决于备份完成后到发生故障这段时间具体产生了多少数据。且用户是否能容忍丢失这个数据量？将k8s-node-3/k8s-node-2节点关机(longhorn基础组件功能及其作用这里就不做介绍了。通过上述测试我们可以发现。
跨 AZ 部署最佳实践之 Zookeeper
焦振清
10-22 5709
作者：焦振清 跨 AZ 部署是实现服务高可用较为有效的方法，同时也极具性价比。如果实现了跨 AZ 部署，不仅可以消除服务中的单点，同时还可以逐步建设如下能力：服务隔离，灰度发布，N+1 冗余，可谓一举多得。因此，接下来我们会对有状态的开源软件进行一系列的跨 AZ 部署的介绍，本次介绍 Zookeeper。 ZK 容错数 Zookeeper 有这样一个特性：集群中只要有过半的机器是正常工作的，...
es 高可用性、可扩展警报 详解
最新发布
03-27
<think>嗯，用户现在问的是Elasticsearch的高可用性和可扩展的警报系统，也就是Alerting功能。首先，我需要确定用户对这两个概念的理解程度。可能他们已经在使用ES，但想要更深入的知识来优化他们的集群或者配置监控告警。 高可用性方面，ES主要通过集群架构、分片副本、节点角色分配来实现。记得要解释主节点、数据节点、协调节点的作用，以及分片和副本如何防止数据丢失。还有Zen Discovery和故障恢复机制，比如如何选举新主节点，分片重新分配的过程。这部分需要结构清晰，分点说明，让用户能一步步理解每个组件如何贡献于高可用性。 然后是扩展性，用户可能想知道如何横向扩展ES集群，处理更大的数据量或更高的查询负载。需要提到分片设计、冷热架构、跨集群搜索等。冷热架构对于时间序列数据特别重要，可以节省成本。跨集群搜索则适用于分布式数据场景，可能需要举例子说明。 接下来是Alerting功能，也就是Elasticsearch的告警机制。用户可能想知道如何配置实时警报，比如基于阈值或异常检测。这里要介绍Alerting的触发条件、动作（比如发邮件、调用Webhook），以及如何与Kibana集成。还要提到Watcher的历史，虽然现在推荐用Alerting，但有些用户可能还在用旧版，需要简单比较。 用户可能的深层需求是确保他们的ES集群稳定可靠，并且能够及时响应问题。他们可能遇到过高负载导致性能下降，或者数据丢失的情况，所以需要高可用性的解决方案。同时，他们可能希望自动化监控，减少人工干预，这时候Alerting就显得重要了。需要强调最佳实践，比如定期备份、监控分片状态、避免脑裂问题等，帮助用户预防潜在问题。 还要注意用户可能对某些术语不太熟悉，比如“脑裂”、“分片分配”等，需要用简单的语言解释。另外，示例配置和步骤能帮助他们更好地应用这些知识到实际环境中。最后，确保内容结构清晰，分点明确，方便用户逐步理解和实施。</think>好的！以下是关于 **Elasticsearch（ES）高可用性**和**可扩展警报（Alerting）**的详细介绍，从基础概念到实践细节逐步展开： --- ### **一、Elasticsearch 高可用性** #### **1. 高可用性核心机制** ES 通过分布式架构和冗余设计确保服务持续可用，核心实现包括： - **集群（Cluster）**：多个节点（Node）组成，共享相同集群名称。 - **分片（Shard）**：索引被拆分为多个分片（主分片 + 副本分片），分散存储在不同节点。 - **副本（Replica）**：每个主分片有 1 个或多个副本，提供数据冗余和故障恢复能力。 #### **2. 实现高可用的关键配置** - **节点角色分离** - **主节点（Master Node）**：负责集群状态管理（如索引创建、分片分配），建议配置 3 个专用主节点避免“脑裂”。 - **数据节点（Data Node）**：存储分片和处理查询，横向扩展提升容量和性能。 - **协调节点（Coordinating Node）**：接收客户端请求并分发到数据节点，汇总结果返回。 - **分片分配策略** ```json PUT /my_index/_settings { "index.routing.allocation.total_shards_per_node": 2, // 限制单节点分片数 "index.unassigned.node_left.delayed_timeout": "5m" // 节点离线后延迟分片重分配 } ``` - **故障恢复机制** - **Zen Discovery**：集群节点发现协议，通过 `discovery.seed_hosts` 配置初始主节点列表。 - **分片重分配**：节点故障时，副本分片自动提升为主分片，确保数据完整性。 #### **3. 高可用最佳实践** - **避免脑裂（Split Brain）** 配置 `discovery.zen.minimum_master_nodes`（ES 7.x 后自动计算），确保主节点选举的多数一致性。 - **跨可用区部署（Cross-AZ）** 将节点分布在不同可用区（如 AWS AZ），防止单区域故障导致服务中断。 - **快照与恢复** 定期备份到远程存储（如 S3、HDFS）： ```bash PUT /_snapshot/my_backup_repo { "type": "s3", "settings": { "bucket": "my-es-backups" } } ``` --- ### **二、Elasticsearch 可扩展性** #### **1. 水平扩展（横向扩展）** - **添加数据节点**：直接扩容数据节点，分片自动均衡分布。 - **分片设计优化** - 单个分片建议 10–50GB（日志场景可更大）。 - 避免“过度分片”（如数千个小分片），增加集群元数据负担。 #### **2. 冷热架构（Hot-Warm-Cold）** - **热节点（Hot）**：SSD 存储，处理实时写入和查询。 - **温节点（Warm）**：HDD 存储，存储历史数据，优化成本。 - 通过 ILM（索引生命周期管理）自动迁移数据： ```json PUT _ilm/policy/my_policy { "policy": { "phases": { "hot": { "actions": { "rollover": { "max_size": "50GB" } } }, "warm": { "min_age": "7d", "actions": { "allocate": { "require": { "data": "warm" } } } } } } } ``` #### **3. 跨集群扩展** - **跨集群搜索（CCS）**：联合查询多个集群数据，适合分布式部署场景。 - **跨集群复制（CCR）**：主集群到从集群的数据同步，实现异地容灾。 --- ### **三、Elasticsearch 警报（Alerting）详解** #### **1. 警报系统核心功能** - **实时监控**：基于 Elasticsearch 数据动态触发警报。 - **多条件支持**：阈值、异常检测、外部 API 调用等。 - **通知渠道**：邮件、Slack、Webhook、企业微信等。 #### **2. 配置警报的步骤（以 Kibana 为例）** 1. **定义规则类型** - **阈值告警**：当某个指标超过设定值时触发（如 CPU 使用率 >90%）。 - **异常检测**：利用机器学习模型识别数据异常（需 License 支持）。 2. **配置条件与频率** ```json { "rule_type_id": "metrics.alert.threshold", "schedule": { "interval": "5m" }, // 每5分钟检查一次 "conditions": [{ "agg_type": "avg", "threshold": 90, "comparator": ">" }] } ``` 3. **设置通知动作** ```json "actions": [{ "group": "default", "id": "my-webhook", "params": { "message": "CPU使用率超过90%!", "url": "https://hooks.slack.com/services/..." } }] ``` #### **3. 高级警报场景** - **复合条件（Composite Alerts）**：组合多个条件触发（如同时满足错误日志激增和响应时间上升）。 - **静默期（Mute）**：临时禁用重复警报，避免“警报风暴”。 - **历史记录与审计**：通过 Kibana 查看警报触发历史及处理状态。 --- ### **四、关键注意事项** 1. **高可用性** - 监控集群健康状态（`GET /_cluster/health?pretty`）。 - 避免单点故障，确保主节点和数据节点冗余。 2. **可扩展性** - 定期优化分片数量和大小。 - 使用 `_cat/allocation` API 检查分片分布均衡性。 3. **警报系统** - 测试警报规则，避免误报或漏报。 - 结合 Elastic Stack 的 APM 和 Metrics 模块实现端到端监控。 --- 通过合理配置高可用架构、优化扩展策略以及精准的警报规则，Elasticsearch 可以稳定支撑大规模数据处理与实时监控需求。具体实践可参考 [Elasticsearch 官方文档](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html) 和 [Kibana Alerting 指南](https://www.elastic.co/guide/en/kibana/current/alerting-getting-started.html)。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值