如何在生产环境中实现Elasticsearch的零停机升级

2021-01-04 11:18:49 浏览数 (1)

文章目录
  • 1. 版本注意事项
  • 2.定义升级策略
    • 2.0 快照备份
    • 2.1 滚动升级（minor或单个major升级）
      • 2.1.1 Elasticsearch运行在最新的次要版本上
      • 2.1.2 Elasticsearch没有运行在最新的次要版本上
    • 2.2 新集群部署（跨多个主版本）
      • 2.2.1 后端：Elasticsearch
      • 2.2.2 后端和前端：Elasticsearch 应用程序
  • 3，常见的快速回归部署策略
    • 3.1 蓝绿部署
    • 3.2金丝雀部署
  • 4. 监视升级
    • 4.1 专用监控集群
    • 4.2 定义成功标准
    • 5.1 冒烟测试：构建验证
    • 5.2 基准测试
  • 6.自动部署
  • 扫尾工作

许多用户需要他们的Elasticsearch集群始终可用。而这些用户中的很多人也希望在新版本发布时升级他们的Elasticsearch环境，这样他们就可以利用所有的新特性和功能。随之，管理员最终会在生产中满负荷运行的情况下升级Elasticsearch。这听起来好得不像真的？好吧，Elasticsearch是为零停机升级而设计的，但在满负荷的同时升级Elasticsearch引擎确实需要一些知识和准备。

在这篇博客中，我们将介绍零停机时间升级Elasticsearch环境的步骤。我们将提供指导方针和策略，以便在active的生产环境上运行升级时将风险降到最低。以下是我们将介绍的内容：

  • 版本注意事项
  • 定义升级策略
  • 用于支持快速回归的常见部署策略
  • 监控升级
  • A / B测试
  • 自动部署

1. 版本注意事项

你的升级路径将取决于你的当前版本和将要升级的版本。因此，作为第一步，应该在现有的部署版本和预期的版本之间进行比较。以下是我们推荐的几件事：

  1. 查看你使用的每个产品的重要更新，并进行必要的修改，使你的代码与新版本兼容（例如Elasticsearch .NET客户端的重要更新）。
  2. 启用弃用日志（deprecation logging），以验证没有使用弃用的功能。
  3. 升级前重建索引（reindex）! Elasticsearch只能读取前一个主要版本(major)中创建的索引。如果集群中包含的索引是在前一个主要版本之前创建和写入，那么就需要重建索引才能在新版本中得到支持。（例如，Elasticsearch 7.x不能读取5.x中创建的索引）。索引的列表可以在升级助手中找到。
  4. 使用升级助手来确定对集群配置进行所需的更改。
  1. 查看所有已保存的实体（stored scripts, stored search templates , watchers 等），以确保它们与新版本兼容。
  2. （推荐）查看将来的版本重大更新。为了简化未来的主要升级，当下是审查下一个主要版本重大更新的好时机。

有关需要回顾的完整列表，请阅读Upgrading the Elastic Stack: Planning for success (blog) 和Elastic Stack升级的官方文档。

2.定义升级策略

2.0 快照备份

在运行群集升级之前，建议将快照作为回滚策略的一部分。这是因为一旦有来自较新版本的节点加入群集，就无法降级群集了。此时，如果需要降级，则只能使用快照。除升级外，备份对于发生故障或事故时恢复数据也很重要，因此，创建快照始终是最佳实践。

2.1 滚动升级（minor或单个major升级）

最快的升级途径是滚动升级。滚动升级允许Elasticsearch集群一次升级一个节点，因此停机时间为零。

在以下情况下支持滚动升级：

  • 次要版本（例如-从7.0到7.10）
  • 最新的次要版本至下一个主要版本（从5.6到6.8或从6.8到7.10.0）

虽然在上述情况下支持滚动升级，但在生产环境中滚动升级总是会有一些风险，因为在这个过程中可能会出现一些问题。除了意外的问题，另一个需要牢记的因素是，你的滚动升级将一次升级一个节点。这意味着你在升级时将少了一个节点来接受搜索和索引请求。如果过载风险太高，更好的选择是按照2.2节中的描述部署一个新的集群。

2.1.1 Elasticsearch运行在最新的次要版本上

由于Elasticsearch在最新的次要版本和下一个主要版本之间是向后兼容的（这意味着全部功能支持，包括与客户端应用的支持），你仍然必须将客户端库升级到匹配的主要版本，并重新编译你的客户端应用，使其与新版本兼容。此外，我们始终建议在生产升级之前在开发环境上进行构建验证。

2.1.2 Elasticsearch没有运行在最新的次要版本上

在这种情况下，可以分两个阶段执行滚动升级。第一步是升级到最新的次要版本，第二步是在主要版本之间进行升级。例如，第一次从6.1到6.8，第二次从6.8到7.3。

只有当客户端应用程序可以与Elasticsearch的两个版本进行通信，并且成功解决了应用程序代码中的所有重大更新时，才适合采用此解决方案。您还需要将客户端库升级到相匹配的主要版本，并重新编译客户端应用程序。否则，你可以部署一个新版本的集群，按照变更修改代码应用，并按照第3节中的说明定义部署策略。

2.2 新集群部署（跨多个主版本）

如果升级将跨越多个主要版本之间进行（例如，从5.x到7.x），则需要升级客户端应用程序，并需要应用部署策略。也可以执行一系列滚动升级，但是与部署新集群相比，这可能需要更多的精力，因为在两种情况下都需要对数据集进行完全重新索引。

2.2.1 后端：Elasticsearch

如果客户端应用程序可以同时与两个Elasticsearch版本通信，并且应用程序中没有重大更新，请在现有群集旁边部署一个新集群，此时，除了客户端升级外，没有其他应用程序需要更改。

在这种情况下，应用程序将使用蓝绿发布或金丝雀发布同时将流量导航到现有群集和新群集中（详见第3节中的更多信息）。

  • Elasticsearch Vx
  • Elasticsearch Vy
2.2.2 后端和前端：Elasticsearch 应用程序

如果在客户端库中有重大更新，并且需要在Elasticsearch和客户端应用上同时采用捆绑的部署策略，也就是说同时有两个部署：

  • 客户端应用程序V1和Elasticsearch Vx
  • 客户端应用程序V2和Elasticsearch Vy

3，常见的快速回归部署策略

准备和测试应尽量减少升级的风险。尽管如此，在大多数情况下，测试环境通常没办法一一模拟的现实世界中的场景。因此，总是建议有一个回归路径，以防万一出现问题。

3.1 蓝绿部署

在蓝绿部署中，蓝色环境将提供100％的流量服务，而绿色将准备就绪。为了进行迁移，流量将在环境之间一次性的全部切换。

在蓝绿色路线中，应考虑以下几点：

  1. 需要准备两套环境，这意味着资源和成本都会增加一倍。
  2. 绿色部署必须经过高度测试，因为迁移过程很突然。如果出现问题，所有用户都会立即受到影响。

3.2金丝雀部署

在金丝雀部署中，在每个时间点上，我们都将拥有为大多数用户提供服务的旧环境，并且新环境将首先由一小部分用户进行测试。

  1. 这种方法将更具成本效益，因为在每个点上都可以在环境之间分配资源
  2. 用户影响中等，因为只影响一小部分
  3. 可能会选择优先级较低的组进行试验。例如，先让内部用户分组使用而非外部用户分组

4. 监视升级

在升级期间，应监控环境以确保其健康。

4.1 专用监控集群

在生产中，您应始终将数据发送到单独的监视集群。理想情况下，监视项应包含客户端应用程序和Elasticsearch在可观察性支柱下的所有数据：

  • 日志
  • 指标
  • 应用程序性能监控（APM）

您也可以使用已有的监视集群来监视升级。否则，请考虑至少在升级时临时部署一个监视集群。

4.2 定义成功标准

为了验证新的部署，需定义成功标准。例如，从运行环境中收集统计数据以分析其正常行为。为此，您可以使用当前环境监控仪表板或创建专用仪表板。这将帮助您为测试阶段做准备，并通过比较当前和新部署统计数据来验证成功的测试操作。可能的指标可以是低延迟，没有CPU或内存压力，没有瓶颈或滞后，类似的错误率和其他与您的应用程序相关的因素。

5. A / B测试 在投入生产之前，应测试新环境，并通过使测试环境尽可能接近实际来隔离更改可能带来的影响。

可能要考虑的因素：

  • 相同的硬件类型
  • 相同的数据类型
  • 相同的查询
  • 相同的索引/搜索的吞吐比率
  • 如果可以承受，保持类似的规模。否则，使用相同的数据子集和进入/即将到来的流量之间的比例来确定生产部署的大小。
  • 比较升级前后的环境KPI。通过对监视数据运行T检验聚合来验证任何更改在统计上是有效的。

5.1 冒烟测试：构建验证

执行构建测试，以验证所有关键功能是否都可以在新版本中按预期工作。冒烟测试的主要目标是验证系统的初始稳定性。常见的检查工作包括：GUI已启动并正在运行，应用程序能够集成并登录到Elasticsearch和其他第三方应用程序，所有应用程序工作流程均按预期工作，所有查询或索引请求均已成功执行，等等。

5.2 基准测试

由于我们无法在生产中运行基准测试，因此与生产环境相似的环境是运行基准测试以收集统计数据以进行未来容量规划的绝佳机会。Rally是在Elasticsearch上运行基准测试的一个很好的工具。这与我们在Elastic上用于测试Elasticsearch构建的工具相同。

6.自动部署

完成所有步骤后，剩下的唯一步骤就是应用！最后一步是确保您有一个自动过程来最大程度地减少人为错误。如果您在Elastic Cloud上运行，则只需单击即可完成Elasticsearch升级！而在本地，您可以通过整合完整的RESTful API，将整个过程应用于自动化。该过程完成后，部署应该是自动的并且可重复进行，以确保将来成功进行更新。

扫尾工作

就是这样! 升级完成了，你的用户几乎没有注意到! 在进行升级这样的操作时，规划是关键。现在，这次升级已经完成，你可以利用你的经验教训，为你的下一次升级准备一个量身定做的部署策略。这样做将确保未来的每次升级都比上一次更容易。而通过彻底记录整个过程，你就会知道，你将不必为下一次升级而担心（即使你在度假）!

ElasticsearchService

0 人点赞