故障现象

近日有客户找到我们，说有个 ES 集群节点，磁盘利用率达到了 82% ，而其节点才 63% ，想处理下这个节点，降低节点的磁盘利用率。

起初以为是没有打开自动平衡导致的，经查询，数据还是比较平衡的。
利用率较高的是 76 节点，如果 76 节点的分片比其他节点多，好像还比较合乎逻辑，但它反而比其他节点少了 12-15 个分片。那是 76 节点上的分片比较大？

索引情况

图中都是较大的索引，1 个索引 25TB 左右，共 160 个分片。

分片大小

节点 64
节点 77
节点 75
问题节点 76
可以看出分片大小没有出现较大的倾斜，分片大小和数据平衡的原因都被排除。

换个方向思考，节点 76 比其他节点多使用了磁盘空间 8 个 TB 左右，集群最大分片大小约 140GB ，8000/140=57 ，即节点 76 至少要比其他节点多 57 个分片才行，啊这...

会不会有其他的文件占用了磁盘空间？

我们登录到节点主机，排查是否有其他文件占用了磁盘空间。

结果：客户的数据路径是单独的数据磁盘，并没有其他文件，都是 ES 集群索引占用的空间。

现象总结

分片大小差不多的情况下，节点 76 的分片数还比别的节点还少 10 个左右，它的磁盘空间反而多占用了 8TB 。

这是不是太奇怪了？事出反常必有妖，继续往下查。

原因定位

通过进一步排查，我们发现节点 76 上有一批索引目录，在其他的节点上没有，而且也不在 GET \_cat/indices?v 命令的结果中。说明这些目录都是 dangling 索引占用的。

dangling 索引产生的原因

当 Elasticsearch 节点脱机时，如果删除的索引数量超过 Cluster.indes.tombstones.size，就会发生这种情况。

解决方案

通过命令删除 dangling 索引：

<br /> DELETE /\_dangling/<index-uuid>?accept_data_loss=true<br />

最后

这次的分享就到这里了，欢迎与我一起交流 ES 的各种问题和解决方案。

关于极限科技（INFINI Labs）


极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

官网：[https://infinilabs.cn](https://infinilabs.cn)

构建Elasticsearch专家Bot的详细步骤指南

步骤1: 文档搜集

• 利用专业工具搜集Elasticsearch 8.13.2版本的官方文档，确保文档的完整性和准确性。如：Elasticsearch文档
  
  

  步骤2: 知识库建立
  

• 在coze.cn平台上创建一个专门的知识库，命名清晰，便于管理和识别。
  
  

  步骤3: 文档上传
  

• 将搜集到的Elasticsearch文档上传至新创建的知识库，确保文档格式适合后续的检索和分析。
  
  

  步骤4: Bot创建
  

• 在coze.cn上创建一个新的Bot，命名为“Elasticsearch专家”，为其设定一个专业且引人注目的形象。
  
  

  步骤5: 知识库配置
  

• 将步骤2中的知识库与新创建的Bot进行关联，确保Bot能够访问和利用这些文档资源。
  
  

  步骤6: 功能插件集成
  

• 为Bot添加以下功能插件，以提供更全面的服务：
  
  • 必应搜索引擎（Bing Web Search）：扩展信息检索范围。
    
  • 代码执行器（CodeRunner）：实现代码的即时测试与验证。
    
  • 微信搜索（WeChat Search）：增加中文信息源的覆盖。
    
    

    步骤7: 人设与回复逻辑定制
    

• 设定Bot的人设，明确其专业领域和能力，如：“我是Elasticsearch的专家，随时准备解答你的疑问。”
  
• 利用coze平台的AI技术，优化Bot的回复逻辑，确保其回答既准确又具有针对性。
  
  

  步骤8: 测试与调整
  

• 在Bot设置完成后，进行全面的测试，确保其能够正确理解和回应各种查询。
  
• 根据测试反馈，调整Bot的交互逻辑和回答内容，以提高用户满意度。
  
  

  步骤9: 发布与分享
  

• 完成所有设置和测试后，点击发布，使Bot正式上线。
  
• 通过Bot页面的商店功能，将你的“Elasticsearch专家”Bot分享给你的伙伴们，让他们也能享受到这一强大的学习工具。
  
  

  步骤10: 持续优化与更新
  

• 定期回顾Bot的表现，根据用户反馈进行持续的优化和功能更新。
  
• 随着Elasticsearch版本的迭代，及时更新知识库内容，确保Bot提供的信息始终最新。
  
  通过遵循这些步骤，你不仅能够构建一个功能全面的Elasticsearch专家Bot，而且能够确保它随着时间的推移不断进化，满足用户日益增长的需求。这将是一个不仅能提供文档查询，还能执行代码和搜索网络的智能助手，极大地提升你的Elasticsearch学习之旅。

极限网关在好未来的最佳实践案例，轻松扛住日增百 TB 数据的流量，助力 ES 从物理机到云原生架构的改造，实现了流控、请求分析、安全管理、无缝迁移等场景。一次完美的客户体验~

背景

物理机架构时代

2022 年，好未来整个日志 Elasticsearch 拥有数十套服务集群，几百台物理机。这么多台机器耗费成本非常高，而且还要花费很大精力去维护。在人力资源有限情况下，存在非常多的弊端，运行成本高，不仅是机器折旧还有机柜等费用。

流量特征

这是来自某个业务线，如下图 1，真实流量，潮汐性非常明显。好未来有很多条业务线，几乎跟这个趋势都一致的，除了个别业务有“续报”、“开课”等活动特殊情况。潮汐性带来的问题就是高峰期 CPU、内存资源是可以消耗很高；低峰期资源使用量非常低，由于是物理架构，这些资源无法给其他业务线共享。


图1

### 降本增效-容器化改造原动力

日志服务对成本的空前的压力促使我们推进 Elasticsearch 进行架构改造；如何改造，改造成什么样子，这两个问题一直是推进改造原动力。业界能够同时对水平扩展和垂直扩展就是 K8S，我们开始对 Elasticsearch 改造成能在 K8S 上运行进行探索，从而提升 CPU、内存利用率。

物理机时代，没办法把资源动态的扩缩，动态调配，资源隔离，单靠人力操作调度成本太高，几乎无法完成；集群对内存资源需求要比 CPU 资源大很多，由于机器型号配置是固定的，无法“定制”，这也会导致成本居高不下。所以，无论从那个方面来讲，容器化优势非常明显，既能够优化成本，也能够降低运维复杂度。

## ES 容器化改造

### 进行架构升级重点难点- API 服务

改造过程，我们遇到了很多问题，比如容器 ES 版本和物理机 ES 版本不一致，如何让 ES API 能够兼容不同的 ES 版本，由于版本的不兼容，导致无法直接使用原有的 tribenode 进行服务，怎么提供一个高可用的 Elasticsearch API 服务。我们考虑到多个方面，比如使用官方推荐的 proxy 模式、第三方服务等进行选择，经过多方面对比，选择了[极限网关](https://infinilabs.cn/products/gateway/) 进行 tribenode 替换。

### 原始 ES API 服务痛点

- API 访问没有流量控制
- 可观测性差，而且稳定性一般
- 版本兼容性差

### 物理机时代 API 架构

在物理机时代 ES 集群，API 架构如图 2，可以明显看到 tribe node 对所有 ES 集群的“侵入性”是非常大的，这就带来了很多问题，比较严重的就是单个集群对 ES tribenode 的影响和版本升级带来的不兼容问题。


图2

### 混合时代 API 架构

通过图 3，我们可以看到，极限网关对于版本兼容性很好，能够适配不同的版本。因此，最终选择极限网关作为下一代 ES API 服务方。


图3

### 里程碑：全部 ES 集群容器化

在 2023 年 3 月份，通过 Elastic 官方 ECK 模式，完成全部日志 ES 集群容器化改造，拥有数百节点，1PB+ 数据存储，每日新增数据 100T 左右。紧接着，除了日志服务外，同时支持了好未来多条业务线。


图4

## 极限网关实践

下面主要讲述了，为什么选择极限网关，以及极限网关在好未来落地、应用这些内容。

### 为什么选择极限网关？

**学习成本低**

我们可以从文档中看到极限网关，其架构简洁，语法简单，直观易懂。学习成本比较低，上手非常快，对新手友好。

**性能强悍**

经过压测，发现极限网关速度非常快，且针对 Elasticsearch 做了非常细致的优化，能成倍提升写入和查询的速度。

**安全性高**

支持多种认证方式，最简单的账号密码认证，可以给自定义多个账户密码，大大简化了 Elasticsearch 的安全设置，同时，还可以支持 LDAP 安全验证。

**跨版本支持**

我们容器化改造过程需要兼容不同版本的 Elasticsrearch，极限网关针对不同的 Elasticsearch 版本做了兼容和针对性处理，能够让业务代码无缝的进行适配，后端 Elasticsearch 集群版本升级能够做到无缝过渡，降低版本升级和数据迁移的复杂度，非常匹配我们的业务场景。

**灵活可扩展**

可灵活对每个请求进行干预和路由，支持路由的智能学习，内置丰富的过滤器，通过配置动态修改每个请求的处理逻辑，也支持通过插件来进行扩展，满足我们对流量的控制，尤其是限流、用户、IP 等这些功能非常实用。

### 启用安全策略-为 API 服务保驾护航

**痛点**

在升级之前使用 tribe 作为 API 服务提供后端，几乎相当于裸奔，没有任何认证策略；另外，tribe 本身的稳定性也有问题，官方在新版本逐渐废弃这种 CCS（跨集群搜索），期间出现多次服务崩溃。

### 极限网关解决问题

极限网关通过，“basic_auth” 插件，提供最基本的安全校验，使用起来非常方便；同时，极限网关提供 LDAP 插件，可以接入公共的 LDAP 服务，对所有的访问用户进行校验，安全策略对所有的用户生效，不用担心因为 IP 问题泄漏数据等。

**强大的过滤功能**

在使用 ES 集群过程中，许多场景，需要对请求进行控制、限制等操作。在这方便，感受到了极限网关强大的产品力。比如下面的两个场景

**对异常流量进行限流**

- 支持对 IP 限流
- 支持对 hostname 限流
- 支持 header 限流

**对异常用户进行封禁**

当 Elasticsearch 是通过 Basic Auth 或者 LDAP 方式来进行身份认证的时候，`request_user_filter` 过滤器可用来按请求的用户名信息来进行过滤。操作起来也非常简单，只需要 `request_user_filter` 这一个过滤器。

```ymal
- request_user_filter:
include:
- "elastic"
exclude：
- "Ryan"
```

总结来讲，主要有这些方面的功能：


图5

### 优秀的可观测性

**痛点**

改造前经常为看不到直观的数据指标感到头疼，查看指标需要多个地方同时打开，去筛选，查找，非常繁琐，付出的成本非常大。为此，大家都再考虑如何优化这种情况，无奈优先级比较低，一直没有真正的投入时间去优化这块。

**完美解决**

使用了极限网关，通过收集请求日志，非常清晰的收集到想要的数据，具体如下：

- 总体方面：
- 流量曲线
- 状态码占比
- 缓存统计
- 每台网关请求流量
- 细节方面：
- 打印每次请求语句
- 可以查看请求到具体 ES 节点流量
- 可以查看过滤器的列表

通过下图，我们可以从管理视角直观的看到各种信息，这对于管理员来讲，省时省力，方便快捷。


图6

### 意外收获：无缝迁移业务 Elasticsearch 上云

由于前期日志业务上云，受到非常好的反馈，多个业务线期望能够上云上服务，达到降本增效的目的。

**支持双写**

数据可以通过极限网关同时写入两个 ES 集群，能够保障数据完全一致，安全可靠。

**无缝切换**

切换很丝滑，影响非常小，能够让外界几乎感受不到服务波动。


图7

通过使用极限网关，自建 ES 集群可以无缝的迁移上云，在整个迁移的过程中，两套集群通过网关进行了解耦，在迁移的过程中还能实现版本的无缝升级，极大降低了迁移成本，提高迁移效率，多次验证服务稳定可靠。

### 极限网关流量概览

这是其中一套极限网关的流量统计。用这部分数据进行巡检，一目了然，做到全局的掌控，提高感知力度。


图8

### 极限网关使用总结

极限网关提供一系列高性能和高可靠性的网关服务。使用这样的服务给我们带来以下好处：

1. **可观测性好**：极限网关可以动态的对 Elasticsearch 运行过程中请求进行拦截和分析，通过指标和日志来了解集群运行状态，这些指标可以用于提升性能和业务优化。
2. **增强安全性**：包含先进的安全机制，如 basicauth、LDAP 等支持，保护用户数据不受未授权访问和各种网络威胁的侵害。
3. **高稳定性**：通过冗余设计和故障转移机制，极限网关能够确保网络服务的高可用性，即使在某些组件发生故障时也能保持服务不中断，单版本最长服务超过 15 个月。
4. **易于管理**：通过提供 [INFINI Console](https://infinilabs.cn/products/console/) 简洁直观的管理界面，让用户能够轻松配置和监控网络状态，提升管理效率。
5. **客户支持**：良好的客户服务支持可以帮助用户快速解决使用过程中遇到的问题，提供专业的技术指导。

综上所述，极限网关为用户提供了一个高速、安全、稳定且易于管理的 ES 网关，适合对网络性能有较高要求的个人和企业用户。

## 未来规划

第一阶段，完成了日志 ES 集群，所有集群的容器化改造，合并，成功的把成本降低了 60%以上。这期间积累了丰富容器化经验，为业务 ES 集群上容器做了良好的铺垫；成本优势和运维优势吸引越来越多的业务接入到容器化 ES 集群。

### 提升 ES 集群效能--新技术应用&&版本升级

- 极限科技官方推荐的 [Easysearch](https://infinilabs.cn/products/easysearch/) 在压缩率，查询速度等等方面有很多的优势，通过长时间的测试稳定性，新特性，对比云原生的 ES 集群，根据测试结果，给“客户”提供多种选择，这也是工作重点之一。
- 我们当前使用的 ES 版本是 6.8，已经远远落后于官方版本，今年我们计划在选择合适的集群升级 ES 版本，拥抱更多官方提供的特性。

### 混合（多）云架构支持

随着越来越多的 ES 集群在机房的 K8S 集群部署，这里资源出现了紧张局面。 我们尝试在云上部署自建 ES 集群，弥补机房资源有限，无法大规模扩容，同时能够支持多活场景，满足更多客户的不同需求。混合云主要实现以下几种能力：

**1、扩缩容：满足不同业务灵活适配**

混合（多）云部署，可以让负载内部私有云 ES，同时部署到公有云，提升扩展 IT 基础设施不仅局限于 CPU、内存，还有存储。比如某一个业务要做活动，预估流量“大爆发”，需要提前准备大规模资源，在机房内根本来不及采购扩容支持，然而在公有云上就能很方便扩容、缩容。在云上搭建 ES 集群，设置满足需求的数量、容量、配置，配合极限网关路由策略，精准的把控流量流向。


图9

**2、灾备：紧急情况快速部署，恢复 ES 集群读写**

当机房级别大规模故障，部分业务实现了多活，单一的机房故障不会影响其服务能力，而此时比如日志查看等仍有需求，为了满足这部分“客户”需求，可以在云上 K8S 集群，快速搭建 ES 集群，恢复日志读写功能。


图10

参考文档：

- <https://infinilabs.cn/docs/latest/gateway>
- <https://www.elastic.co/guide/e ... gt%3B

作者：张华勋，前新浪 CDN 研发，工作主要涉及 Mysql、MongoDB、Redis、Elasticsearch、流量调度等组件和系统，以及运维自动化、平台化等工作。现就职于好未来。

## 关于好未来

好未来（NYSE：TAL）是一家以内容能力与科技能力为基础，以科教、科创、科普为战略方向，助力人的终身成长，并持续探索创新的科技公司。 好未来的前身学而思成立于 2003 年，2010 年在美国纽交所正式挂牌交易。好未来以“爱与科技助力终身成长”为使命，致力成为持续创新的组织。更多参见：<https://www.100tal.com/>

## 关于极限科技（INFINI Labs）


极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

官网：<https://www.infinilabs.cn>



背景

客户需要将 Elasticsearch 集群无缝迁移到移动云，迁移过程要保证业务的最小停机时间。

实现方式

通过采用成熟的 INFINI 网关来进行数据的双写，在集群的切换恢复过程中来记录数据变更，待全量数据恢复之后再追平后面增量数据，追平增量之后，进行校验确保数据一致再进行流量的切换。

总体流程

总体迁移流程如下：

1. 客户业务代码，切流量，双写。（新增的变更都会记录在网关本地，但是暂停消费到移动云）
   
2. 暂停网关移动云这边的增量数据消费。
   
3. 迁移 11 月的数据，快照，快照上传到 S3；
   
4. 下载 S3 的文件到移动云。
   
5. 恢复快照到移动云的 11 月份的索引。
   
6. 开启网关移动云这边的增量消费。
   
7. 等待增量追平（接近追平）。
   
8. 按照时间条件（如：时间 A，当前时间往前 30 分钟），验证文档数据量，Hash 校验等等。
   
9. 停业务的写入，网关，腾讯云的写入（10 分钟）。
   
10. 等待剩余的增量追完。
    
11. 对时间 A 之后的，增量进行校验。
    
12. 切换所有流量到移动云，业务端直接访问移动云 ES。
    
    总体的迁移时间：
    
    
13. 11 月备份时间（30 分钟）19 号开始
    
14. 备份下载到移动云的时间（2-3 天）
    
15. 备份恢复到移动云集群的时间（30 分钟）
    
16. 11 月份增量备份（20 分钟）（双写开始）（21 号）
    
17. 11 月份增量下载到移动云（6 小时）
    
18. 11 月份增量恢复时间（20 分钟）
    
19. 追增量数据（8 个小时产生的数据，需要 1 个小时）
    
20. 校验比对（存量 1 个小时）
    
21. 流量暂停，增量的校验（10 分钟）
    
22. 切换（1 分钟）
    
    总体流程如下示意图：
    
    

    ES 集群信息
    

23. ES 版本 7.10.1
    
24. 2个热节点 3个温节点  总数 1.9 TB
    
25. 索引   1041， 分片2085
    
26. 无自定义插件
    
27. 有 update_bu_query 使用
    
28. 有 delete_by_query 使用
    
29. 吞吐量没有测试过，当前日增文档数 1 千多万，目标日增加上亿  
    

    迁移操作手册（参考）
    

    环境
    

    
    

    • 自建 ES 5.4.2
      
    • 自建 ES 5.6.8
      
    • 自建 ES 7.5.0
      
    • 极限网关服务器 1
      
    • 极限网关服务器 2
      
    • 云端负载均衡 1 (监听 9200 端口，指向极限网关服务器 1/2 的 8000 端口)
      
    • 云端负载均衡 2 (监听 9200 端口，指向极限网关服务器 1/2 的 8001 端口)
      

      场景描述
      

      若干个自建 Elasticsearch 集群需要平滑迁移到移动云，业务不停写、不做代码改动。
      

      数据架构
      

      通过将应用端流量走网关的方式，请求同步转发给自建 ES，网关记录所有的写入请求，并确保顺序在云端 ES 上重放请求，两侧集群的各种故障都妥善进行了处理，从而实现透明的集群双写，实现安全无缝的数据迁移。
      
      业务端如果已经部署在云上，可以使用云上的 SLB 服务来访问网关，确保后端网关的高可用，如果业务端和极限网关还在企业内网，可以使用极限网关自带的 4 层浮动 IP 来确保网关的[高可用](https://gateway.infinilabs.com ... ng_ip/)。
      
      

      数据描述
      

      以数据从自建集群 5.4.2 迁移到云上的 5.6.16 为例进行说明，执行步骤依次说明。
      

      执行步骤
      

      部署 INFINI Gateway
      

      为了保证数据的无缝透明迁移，通过 INFINI [Gateway](https://infinilabs.cn/docs/latest/gateway/overview/) 来进行双写。
      
      

30. 系统调优
    
    参考此[文档](https://infinilabs.cn/docs/lat ... ation/)。
    
    
31. 下载程序
    <br /> [root@iZbp1gxkifg8uetb33pvcoZ ~]# mkdir /opt/gateway<br /> [root@iZbp1gxkifg8uetb33pvcoZ ~]# cd /opt/gateway/<br /> [root@iZbp1gxkifg8uetb33pvcoZ gateway]# wget <a href="http://release.infinilabs.com/gateway/snapshot/gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz" rel="nofollow" target="_blank">http://release.infinilabs.com/ ... ar.gz</a><br /> --2022-05-19 10:16:25-- <a href="http://release.infinilabs.com/gateway/snapshot/gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz" rel="nofollow" target="_blank">http://release.infinilabs.com/ ... ar.gz</a><br /> 正在解析主机 release.infinilabs.com (release.infinilabs.com)... 120.79.205.193<br /> 正在连接 release.infinilabs.com (release.infinilabs.com)|120.79.205.193|:80... 已连接。<br /> 已发出 HTTP 请求，正在等待回应... 200 OK<br /> 长度：7430568 (7.1M) [application/octet-stream]<br /> 正在保存至: “gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz”<br /> <br /> 100%[==============================================================================================================================================>] 7,430,568 22.8MB/s 用时 0.3s <br /> <br /> 2022-05-19 10:16:25 (22.8 MB/s) - 已保存 “gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz” [7430568/7430568])<br /> <br /> [root@iZbp1gxkifg8uetb33pvcoZ gateway]# tar vxzf gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz <br /> gateway-linux-amd64<br /> gateway.yml<br /> sample-configs/<br /> sample-configs/elasticsearch-with-ldap.yml<br /> sample-configs/indices-replace.yml<br /> sample-configs/record_and_play.yml<br /> sample-configs/cross-cluster-search.yml<br /> sample-configs/kibana-proxy.yml<br /> sample-configs/elasticsearch-proxy.yml<br /> sample-configs/v8-bulk-indexing-compatibility.yml<br /> sample-configs/use_old_style_search_response.yml<br /> sample-configs/context-update.yml<br /> sample-configs/elasticsearch-route-by-index.yml<br /> sample-configs/hello_world.yml<br /> sample-configs/entry-with-tls.yml<br /> sample-configs/javascript.yml<br /> sample-configs/log4j-request-filter.yml<br /> sample-configs/request-filter.yml<br /> sample-configs/condition.yml<br /> sample-configs/cross-cluster-replication.yml<br /> sample-configs/secured-elasticsearch-proxy.yml<br /> sample-configs/fast-bulk-indexing.yml<br /> sample-configs/es_migration.yml<br /> sample-configs/index-docs-diff.yml<br /> sample-configs/rate-limiter.yml<br /> sample-configs/async-bulk-indexing.yml<br /> sample-configs/elasticssearch-request-logging.yml<br /> sample-configs/router_rules.yml<br /> sample-configs/auth.yml<br /> sample-configs/index-backup.yml<br />
    
    
32. 修改配置
    
    将网关提供的示例配置拷贝，并根据实际集群的信息进行相应的修改，如下：
    <br /> [root@iZbp1gxkifg8uetb33pvcoZ gateway]# cp sample-configs/cross-cluster-replication.yml 5.4.2TO5.6.16.yml <br />
    首先修改集群的身份信息，如下：
    
    
    然后修改集群的注册信息，如下：
    
    
    根据需要修改网关监听的端口，以及是否开启 TLS (如果应用客户端通过 http 协议访问 ES，请将entry.tls.enabled 值改为 false)，如下：
    
    不同的集群可以使用不同的配置，分别监听不同的端口，用于业务的分开访问。
    
    
33. 启动网关
    
    启动网关并指定刚刚创建的配置，如下：
    <br /> [root@iZbp1gxkifg8uetb33pvcoZ gateway]# ./gateway-linux-amd64 -config 5.4.2TO5.6.16.yml <br /> <br /> ___ _ _____ __ __ __ _ <br /> / _ \ /_\ /__ \/__\/ / /\ \ \/_\ /\_/\<br /> / /_\///_\\ / /\/_\ \ \/ \/ //_\\\_ _/<br /> / /_\\/ _ \/ / //__ \ /\ / _ \/ \ <br /> \____/\_/ \_/\/ \__/ \/ \/\_/ \_/\_/ <br /> <br /> [GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.<br /> [GATEWAY] 1.6.0_SNAPSHOT, 2022-05-18 11:09:54, 2023-12-31 10:10:10, 73408e82a0f96352075f4c7d2974fd274eeafe11<br /> [05-19 13:35:43] [INF] [app.go:174] initializing gateway.<br /> [05-19 13:35:43] [INF] [app.go:175] using config: /opt/gateway/5.4.2TO5.6.16.yml.<br /> [05-19 13:35:43] [INF] [instance.go:72] workspace: /opt/gateway/data1/gateway/nodes/ca2tc22j7ad0gneois80<br /> [05-19 13:35:43] [INF] [app.go:283] gateway is up and running now.<br /> [05-19 13:35:50] [INF] [actions.go:358] elasticsearch [primary] is available<br /> [05-19 13:35:50] [INF] [api.go:262] api listen at: <a href="http://0.0.0.0:2900" rel="nofollow" target="_blank">http://0.0.0.0:2900</a><br /> [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200]<br /> [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [backup] hosts: [] => [es-cn-tl32p9fkk0006m56k.elasticsearch.aliyuncs.com:9200]<br /> [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200]<br /> [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [backup] hosts: [] => [es-cn-tl32p9fkk0006m56k.elasticsearch.aliyuncs.com:9200]<br /> [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200]<br /> [05-19 13:35:50] [INF] [entry.go:322] entry [my_es_entry/] listen at: <a href="https://0.0.0.0:8000" rel="nofollow" target="_blank">https://0.0.0.0:8000</a><br /> [05-19 13:35:50] [INF] [module.go:116] all modules are started<br />
    
    
34. 后台运行
    <br /> [root@iZbp1gxkifg8uetb33pvcoZ gateway]# nohup ./gateway-linux-amd64 -config 5.4.2TO5.6.16.yml &<br />
    
    
35. 应用授权
    <br /> curl -XPOST <a href="http://localhost:2900/_license/apply" rel="nofollow" target="_blank">http://localhost:2900/_license/apply</a> -d'<br /> {<br /> "license": "XXXXXXXXXXXXXXXXXXXXXXXXX"<br /> }'<br />
    

    部署 INFINI Console
    

    为了方便在多个集群之间快速切换，使用 INFINI [Console](https://infinilabs.cn/products/console/) 来进行管理。
    
    

36. 下载安装
    <br /> [root@iZbp1gxkifg8uetb33pvcpZ console]# wget <a href="http://release.infinilabs.com/console/snapshot/console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz" rel="nofollow" target="_blank">http://release.infinilabs.com/ ... ar.gz</a><br /> --2022-05-19 10:57:24-- <a href="http://release.infinilabs.com/console/snapshot/console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz" rel="nofollow" target="_blank">http://release.infinilabs.com/ ... ar.gz</a><br /> 正在解析主机 release.infinilabs.com (release.infinilabs.com)... 120.79.205.193<br /> 正在连接 release.infinilabs.com (release.infinilabs.com)|120.79.205.193|:80... 已连接。<br /> 已发出 HTTP 请求，正在等待回应... 200 OK<br /> 长度：13576234 (13M) [application/octet-stream]<br /> 正在保存至: “console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz”<br /> <br /> 100%[==============================================================================================================================================>] 13,576,234 33.2MB/s 用时 0.4s <br /> <br /> 2022-05-19 10:57:25 (33.2 MB/s) - 已保存 “console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz” [13576234/13576234])<br /> <br /> [root@iZbp1gxkifg8uetb33pvcpZ console]# tar vxzf console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz <br /> console-linux-amd64<br /> console.yml<br />
    
    
37. 修改配置
    ```
    [root@iZbp1gxkifg8uetb33pvcpZ console]# cat console.yml
    
    

    for the system cluster, please use Elasticsearch v7.3+
    

    elasticsearch:
    

    • name: default
      enabled: true
      monitored: false
      endpoint: http://es-cn-7mz2p9fty0007frx0 ... :9200
      basic_auth:
      username: elastic
      password: XXXXXX
      discovery:
      enabled: false
      ...
      ```
      
      
38. 启动服务
    <br /> [root@iZbp1gxkifg8uetb33pvcpZ console]# ./console-linux-amd64 -service install<br /> Success<br /> [root@iZbp1gxkifg8uetb33pvcpZ console]# ./console-linux-amd64 -service start<br /> Success<br />
    
    
39. 访问后台
    
    访问该主机的 9000 端口，即可打开 Console 后台，http://x.x.x.x:9000/
    打开菜单 [System][Cluster] ，注册当前需要管理的 Elasticsearch 集群和网关地址，用来快速管理，如下：
    
    

    测试 INFINI Gateway
    

    为了验证网关是否正常工作，我们通过 INFINI Console 来快速验证一下。
    首先通过走网关的接口来创建一个索引，并写入一个文档，如下：
    
    查看 5.4.2 集群的数据情况，如下：
    
    查看集群 5.6.16 的数据情况，如下：
    
    说明网关配置都正常，验证结束。
    

    调整网关的消费策略
    

    因为我们需要在全量数据迁移之后，才能进行增量数据的追加，在全量数据迁移完成之前，我们应该暂停增量数据的消费。修改网关配置里面 Pipeline consume-queue_backup-to-backup和 consume-queue_primary-failure-to-backup的参数 auto_start为 false，表示不自动启动该任务，具体配置方法如下：
    
    
    修改完配置之后，需要重新启动网关。
    为了方便管理，可以使用 INFINI Console 来注册和管理网关，如下:
    
    
    待全量迁移完成之后，可以通过后台的 Task 管理来进行后续的任务启动、停止，如下：
    
    

    切换流量
    

    接下来，将业务正常写的流量切换到网关，也就是需要把之前指向 ES 5.4.2 的地址指向网关的地址，如果 5.4.2 集群开启了身份验证，业务端代码同样需要传递身份信息，和 5.4.2 之前的用法保持不变。
    
    切换流量到网关之后，用户的请求还是以同步的方式正常访问自建集群，网关记录到的请求会按顺序记录到 MQ 里面，但是消费是暂停状态。
    如果业务端代码使用的 ES 的 SDK 支持 Sniff，并且业务代码开启了 Sniff，那么应该关闭 Sniff，避免业务端通过 Sniff 直接链接到后端的 ES 节点，所有的流量现在应该都只通过网关来进行访问。
    

    全量数据迁移
    

    在流量迁移到网关之后，我们开始对自建 Elasticsearch 集群的数据进行全量迁移到云端 Elasticsearch 集群。
    
    全量迁移已有的数据的方式有很多种：
    
    

    • 通过快照的方式进行恢复
      
    • 使用工具来导出导入，如： [ESM](https://github.com/medcl/esm)
      
      如果索引数量很多的话，可以按照索引依次进行导入，同时需要注意将 Mapping 和 Setting 提前导入。
      以现在 5.4 集群的索引来为例，目前的待迁移索引为 demo_5_4_2，只有4 个文档：
      
      我们使用网关自带的迁移功能来进行数据迁移，拷贝自带的样例文件，如下：
      <br /> [root@iZbp1gxkifg8uetb33pvcpZ gateway]# cp sample-configs/es_migration.yml 5.4TO5.6.yml<br />
      修改其中代表集群和索引的相关配置，可以根据需要配置是否需要重命名索引和统一 Type（ 用于跨版本统一 Type），如下图红框位置：
      
      创建好模板和索引，如果目标集群不允许动态创建文档，需要提前创建好索引，如下图：
      
      然后就可以开始数据的迁移了，执行网关程序并指定刚刚定义的配置，如下：
      
      执行完成后，可以确认下数据的情况，如下图：
      
      全量数据至此导入完成。
      

      增量数据迁移
      

      在全量导入的过程中，可能存在数据的增量修改，不过这部分请求都已经完整记录下来了，我们只需要开启网关的消费任务即可将挤压的请求应用到云端的 Elasticsearch 集群。
      
      示例操作如下：
      
      如果从 5.6 的集群来看的话，这部分的修改还没同步过来，如下：
      
      这部分增量的数据变更，在网关层面都进行了完整记录，我们只需要开启网关的增量消费任务，如下：
      
      通过观察队列是否消费完成来判断增量数据是否做完，如下：
      
      现在我们再看一下 5.6 集群的数据情况，如下：
      
      数据的增量更新就过来了。
      

      执行数据比对
      

      由于集群内部的数据可能比较多，我们需要进行一个完整的比对才能确保数据的完整性，可以通过网关自带的数据比对工具来进行，将样例自带的文件拷贝一份，如下：
      <br /> [root@iZbp1gxkifg8uetb33pvcpZ gateway]# cp sample-configs/index-docs-diff.yml 5.4DIFF5.6.yml<br />
      修改需要比对的集群和索引信息，可以加上过滤条件，如时间范围窗口来进行增量 Diff，如下图：
      
      
      执行网关程序，并指定该配置文件，如下图：
      
      如图，两个集群完全一致。
      

      切换集群
      

      如果验证完之后，两个集群的数据已经完全一致了，可以将程序切换到新集群，或者将网关的配置里面的主备进行互换，同步写 5.6 集群。
      
      双集群在线运行一段时间，待业务完全验证之后，再安全下线旧集群，如遇到问题，也可以随时回切到老集群。
      

      小结
      

      通过使用极限网关，自建 ES 集群可以安全无缝的迁移到移动云 ES，在迁移的过程中，两套集群通过网关进行了解耦，两套集群的版本也可以不一样，在迁移的过程中还能实现版本的无缝升级。
      如有任何问题，请随时联系我，期待与您交流！