ElasticSearch 不停服升级实践
导读：产品的迭代升级往往也会涉及到业务系统、中间件的更新，如果在升级过程中采用停服升级的方式，则会产生业务的中断，从而给产品的使用体验带来一定影响。不停服升级实现了业务的无缝更新，可以带给用户连贯的产品使用体验。ElasticSearch 作为主流的搜索服务解决方案，社区活跃，发版频繁，所以了解 ElasticSearch 不停服升级的实践非常必要。
背景
我们升级 ElasticSearch 通常会出于以下原因：
•安全漏洞
•JDK 版本陈旧
•服务器迁移、硬件变更
•需要使用到 ElasticSearch 新版本中提供的新功能
•Lucene 中提供了性能相关的改进增强
在升级准备过程中，我们需要考虑：ElasticSearch 版本兼容性、集群状态、备份、配置兼容性、索引迁移、业务迁移等内容。为了保证升级成功，需要制定详尽的策略和方针，将升级过程中可能出现的风险降低到最小。
版本兼容性
ElasticSearch 官方提供了滚动升级的支持，它允许 ElasticSearch 集群中加入新版本的节点，逐步替换所有节点，从而形成新版本的集群。但是新版本中提供的功能会被暂时禁用或以向后兼容的模式运行，只有当所有的节点都升至新版本，才会重新开启新功能的运行。当所有节点都升级至最新的版本后，旧版本的节点将不会被允许加入到新的集群。
ElasticSearch 通常会兼容如下版本间的滚动升级策略：
•同一主要版本的次要版本升级，例如，从 7.10.0 升级到 7.17.6。
•从低版本的最后一个次要版本升级到下一个版本，例如：从 7.17.6 到 8.4.2。
所以在跨版本升级时，通常的策略是先升级至当前版本的最后一个版本再滚动升级至下一个版本。
此外，在迁移的时候，也需要关注当前业务中连接的 ElasticSearch 的 Client 是否兼容新版本。例如 Java Client 的升级经历了几个阶段：
•早期的 Transport Java Client，使用 9300 端口从节点建立连接。
•Low Level REST Client，原始的 HTTP 交互，需要自己准备 JSON 串。
•High Level REST Client，低级别的 REST 封装，在 V5.6 后引入，在高版本中将会被废弃。
•Java API Client，从 V7.17 后支持，提供了强类型、Jackson 无缝集成等特性，是新版本推荐的 Client 工具。
所以在升级后，业务侧也最好同步更新至新版本匹配的 Client 工具，以取得更好的官方支持和向后扩展的能力。
集群状态检查
在升级之前，应当对集群、索引、服务器等状态做一个全面的检测，用来评估此次升级的风险。
1.集群状态的检查，如果出现集群节点断开的情况，或者状态为 red/yellow 的情况下，则需要修复完毕再执行升级操作。
2.检查索引是否为关闭状态、分片数量是否正确以及索引状态是否为 green。
3.索引配置
检查 index template 等索引配置的新版本兼容性。
4.服务器节点状态
需要评估当前系统的资源状况，例如 CPU、内存、磁盘的使用情况，避免升级过程中出现的服务中断。
备份
在执行集群升级之前，可以将快照作为回滚的策略，保存一个完整的拷贝，从而避免出现升级失败数据丢失导致的灾难性故障。关于 Snapshot 与 Restore 的内容可以参考公众号历史文章：ElasticSearch 集群备份与恢复实践。
索引迁移实践
下面通过一个模拟的业务场景来更好的说明升级过程，假设集群中存在 ElasticSearch 7.10.0 版本 5 个节点，其中 3 个 master/data 节点，2 个 ingest 节点，fluentd 实时采集采集业务日志发送到 ingest 节点之中，存在一个日志搜索的 Java Client 业务搜索收到的日志，现接到需求，要求升级 ElasticSearch 到最高版本。
在升级中，可以通过将 ElasticSearch 升级至 7.17.6 再升级至 8.4.2 两次滚动升级，也可以选择新搭建一个 8.4.2 新集群，采用索引迁移的方式，远程 reindex 原集群中的索引至新集群的方式进行。当集群负载比较高、当前集群资源不足、读写入操作频繁的情况下，选择新搭建集群迁移索引的方式，让两套集群短时间内并行运行，利用灰度/蓝绿发布进行流量迁移的方式，可以降低整个迁移升级过程失败的风险，让业务的平滑升级。
根据以上需求整理，我们选择第二种方案规划了下面升级路线：
在做完版本兼容性判断、集群状态检查、快照备份工作之后就可以开始滚动升级了。
在滚动升级时，需要先升级非 master 选举节点，例如 ingest、ml 节点，再升级数据节点，从冻结的节点、data_cold、data_warm、data_hot 的顺序逐步升级，最后再升级 master 节点。
在 remote reindex 迁移索引之前，还需要考虑到升级过程中的数据同步问题，通常会采用如下策略来提升升级体验：
•禁用分片分配
ElasticSearch 在数据节点关闭时，会在index.unassigned.node_left.delayed_timeout （默认 1 分钟）后自动执行分片的复制到其他节点的操作。在滚动升级的节点恢复时间很短暂，在更替节点开始前，可以暂时关闭这个配置，来避免不必要的分片复制 I/O 行为：
•停止 flush 操作，暂时关闭它，能够提升分片恢复的速度：
•配置迁移白名单
在配置完以上策略后，停止当前版本的节点，接入新版本的 ElasticSearch 节点，通过查看集群的状态：
可以看到集群恢复的进度，如果集群状态恢复到 green，则说明主分片和副本都已成功分配，重复此过程直至所有节点都替换完毕：
在 7.17.6 升级完毕后，搭建 8.4.2 新集群，在新集群中，当验证确认新集群状态与分片状态健康之后，需要迁移原集群中的索引模板、索引策略、对应版本的插件，跨版本的升级可能会涉及到 index template 参数的些许变化，这种情况下需要重新为索引设计一个 template，并在新集群中执行与验证。
此时可以规划业务的迁移，可以利用蓝绿发布或者灰度的方式，对业务的流量进行切换。Fluentd 写入端也可以利用多个 match 分发数据的方式，把数据并行写入到两个 ElasticSearch 集群之中。
当所有工作完成后，即可进行索引的远程迁移工作，此时通过执行 reindex 操作进行索引的跨集群索引的重建与迁移，也可以自行编写脚本进行全量索引的迁移：
迁移完毕后，可以查看索引的状态来确认此次升级的结果：
总结
本文探讨了 ElasticSearch 不停服升级的实践思路，从集群检查、滚动升级、数据同步等步骤说明了升级过程中的注意事项，虽然 ElasticSearch 提供了滚动升级的思路与 Snapshot 备份回退的方案，不过为了降低升级失败的风险，采用两个集群并行运行仍是一个更加稳妥的选择。
参考链接：
•https://www.alibabacloud.com/help/en/elasticsearch/latest/perform-a-check-before-a-version-upgrade
移动云，5G时代你身边的智慧云 2019.02.13 加入
移动云大数据产品团队，在移动云上提供云原生大数据分析LakeHouse，消息队列Kafka/Pulsar，云数据库HBase，弹性MapReduce，数据集成与治理等PaaS服务。 微信公众号：人人都学大数据
评论