通过 Amazon OpenSearch Ingestion 实现跨区域弹性 大数据博客

使用 Amazon OpenSearch Ingestion 实现跨区域弹性

作者：Muthu Pitchaimani 和 Aruna Govindaraju，2024年9月24日，发表在 Amazon OpenSearch Service 和 Analytics 中

关键要点

跨区域部署提升了在遭遇故障、自然灾害或其他操作中断时保持业务连续性的能力。许多大型企业会为这种情况设计和部署特别的准备方案。它们依靠建立在 AWS 服务和功能之上的解决方案来提高响应速度和信心。 Amazon OpenSearch Service 是一个用于高效搜索和分析的托管服务，支持 OpenSearch。OpenSearch Service 通过其多可用区部署模型提供高可用性，并通过 跨集群复制 提供区域弹性。 Amazon OpenSearch Serverless 是一种按需自动扩展的部署选项，持续引入许多新功能。

在现有的跨集群复制功能中，您需要将一个域指定为主域，另一个作为从域，采用主动被动复制模型。虽然该模型在区域失灵期间提供了继续操作的方式，但您需要手动配置从域。此外，恢复后，您必须重新配置两个域之间的主从关系。

在本文中，我们概述了两种能够在无须在故障恢复期间重新建立域关系的情况下实现跨区域弹性解决方案，这些解决方案利用 主动主动复制模型 和 Amazon OpenSearch Ingestion (OSI) 以及 Amazon Simple Storage Service (Amazon S3)。这些解决方案适用于 OpenSearch Service 托管集群和 OpenSearch Serverless 集合。本文以 OpenSearch Serverless 作为示例进行配置说明。

解决方案概述

我们在本文中概述了两种解决方案。在这两种选项中，位于特定区域的数据源将数据写入同一区域配置的 OpenSearch Ingestion (OSI) 管道。这些解决方案可扩展至多个区域，但我们以两个区域作为示例，因为跨两个区域的区域弹性是许多大型企业的流行部署模式。

您可以使用这些解决方案解决 OpenSearch Serverless 部署的跨区域弹性需求，以及针对 OpenSearch Service 的服务器和预配置选项的主动主动复制需求，特别是当数据源在不同区域生成不同数据时。

前提条件

请完成以下前提条件步骤：

完成这些步骤后，您可以在每个区域创建两个 OSI 管道，其配置将在接下来的部分中详细说明。

使用 OpenSearch Ingestion (OSI) 进行跨区域写入

在此解决方案中，OSI 将区域内的数据写入到另一个区域。为了促进跨区域写入并增强数据耐久性，我们在每个区域中使用一个 S3 存储桶。其他区域的 OSI 管道从该 S3 存储桶读取数据并将其写入本地区域的集合。其他区域的 OSI 管道遵循类似的数据流。

在读取数据时，您有两个选择：Amazon SQS 或 Amazon S3 扫描。本文选择使用 Amazon SQS，因为它有助于提供接近实时的数据交付。此解决方案还支持在拉取型 OSI 数据源的情况下直接将数据写入本地存储桶。有关 OSI 使用的不同数据源类型，请参考 关键概念 下的 “源” 部分。

以下是数据流的示意图。

数据流包括以下步骤：

以下代码片段展示了两个管道的配置。

yaml

跨区域写入管道配置

version 2writepipeline source http path /logs processor parsejson sink # 第一个输出到同区域集合 opensearch hosts [ https//abcdefghijklmnuseast1aossamazonawscom ] aws stsrolearn arnawsiam1234567890role/pipelinerole region useast1 serverless true index crossregionindex s3 # 第二个输出到跨区域 S3 存储桶 aws stsrolearn arnawsiam1234567890role/pipelinerole region useast2 bucket osicrossregionbucket objectkey pathprefix osicrw/{yyyy}/{MM}/{dd}/{HH} threshold eventcollecttimeout 60s codec ndjson

写管道的代码如下：

yaml

从本地 S3 存储桶读取数据的管道配置

version 2readwritepipeline source s3 acknowledgments true notificationtype sqs compression none codec newline sqs queueurl https//sqsuseast1amazonawscom/1234567890/myosicrossregionwriteq maximummessages 10 visibilitytimeout 60s visibilityduplicationprotection true aws region useast1 stsrolearn arnawsiam123567890role/pipelinerole processor parsejson route # 路由使用 s3 密钥确保 OSI 仅将数据写入本区域一次 localregionwrite contains(/s3/key osilocalregionwrite) crossregionwrite contains(/s3/key osicrossregionwrite) sink pipeline name localregionwritecrossregionwritepipeline pipeline name localregionwritepipeline routes localregionwrite

localregionwritecrossregionwritepipeline # 从支持跨区域写入的 S3 存储桶读取 source pipeline name readwritepipeline sink # 输出到本区域的 OpenSearch 服务 opensearch hosts [ https//abcdefghijklmnuseast1aossamazonawscom ] aws stsrolearn arnawsiam12345678890role/pipelinerole region useast1 serverless true index crossregionindex

localregionwritepipeline # 本区域写入的读取 source pipeline name readwritepipeline processor deleteentries withkeys [s3] sink # 输出到跨区域 S3 存储桶 s3 aws stsrolearn arnawsiam1234567890role/pipelinerole region useast2 bucket osicrossregionwritebucket objectkey pathprefix osicrossregionwrite/{yyyy}/{MM}/{dd}/{HH} threshold eventcollecttimeout 60s codec ndjson

为了分离管理和操作，我们在两个区域的存储桶中使用两个前缀 osilocalregionwrite 和 osicrossregionwrite。OSI 使用这些前缀仅将本区域数据复制到另一区域。同时，OSI 也创建了 s3bucket 和 s3key 这两个键值，装饰写入集合的文档。在跨区域写入时，我们会删除这些装饰；在另一区域的管道中，这些装饰将被再度添加。

此解决方案提供接近实时的数据交付，确保数据在两个区域中均可用。然而，尽管 OpenSearch Service 中的数据显示相同，每个区域的存储桶中仅包含部分数据。接下来的解决方案将解决这个问题。

使用 Amazon S3 进行跨区域写入

在此解决方案中，我们使用 Amazon S3 区域复制功能。此解决方案支持所有 OSI 可用的数据源。OSI 再次使用两个管道，但关键区别在于 OSI 首先将数据写入 Amazon S3。完成两种解决方案共有的步骤后，请参考 示例配置实时复制 以进行 Amazon S3 跨区域复制的配置。以下是数据流的示意图。

数据流包括以下步骤：

以下代码片段展示了两个管道的配置。

yamlversion 2s3writepipeline source http path /logs processor parsejson sink # 写入启用跨区域复制的 S3 存储桶 s3 aws stsrolearn arnawsiam1234567890role/pipelinerole region useast2 bucket s3crossregionbucket objectkey pathprefix pushedlogs/{yyyy}/{MM}/{dd}/{HH} threshold eventcollecttimeout 60s eventcount 2 codec ndjson

写管道的代码如下：

yamlversion 2s3readpipeline source s3 acknowledgments true notificationtype sqs compression none codec newline # 配置 SQS 以通知 OSI 管道 sqs queueurl https//sqsuseast2amazonawscom/1234567890/mys3crrq maximummessages 10 visibilitytimeout 15s visibilityduplicationprotection true aws region useast2 stsrolearn arnawsiam1234567890role/pipelinerole processor parsejson # 配置 OSI 输出，将文件从 S3 移动到 OpenSearch Serverless sink opensearch hosts [ https//abcdefghijklmnuseast1aossamazonawscom ] aws # 角色必须具备访问 S3 OpenSearch 管道和 OpenSearch Serverless 的权限 stsrolearn arnawsiam1234567890role/pipelinerole region useast1 serverless true index crossregionindex

此解决方案的配置相对简单且依赖于 Amazon S3 跨区域复制。此解决方案确保 S3 存储桶和 OpenSearch Serverless 集合中的数据在两个区域中保持一致。

有关此复制的 SLA 和可用于监控复制过程的指标的更多信息，请参考 S3 复制更新：复制 SLA、指标和事件。

故障场景和其他注意事项

让我们考虑区域故障场景。在这个用例中，我们假设您的应用程序以 OpenSearch Serverless 集合作为后端。当一个区域发生故障时，这些应用程序可以简单地故障转移到另一区域的 OpenSearch Serverless 集合中，并继续操作，因为在故障发生之前的数据在两个集合中均可用。

当区域故障解决后，您可以立即或在允许缺失数据在该区域内恢复的条件下，再次故障转移回该区域的 OpenSearch Serverless 集合。然后，操作可以继续进行而不受中断。

您可以自动化这些故障转移和故障恢复操作，以提供无缝的用户体验。虽然这部分不在本文的范围内，但将来会有专门内容进行介绍。

现有的跨集群复制解决方案要求您手动重新建立主从关系，并在从故障恢复后重新开始复制。但本文讨论的解决方案能够自动恢复复制，并从上次停止的地方继续。如果出于某种原因，只有 Amazon OpenSearch 服务如集合或域出现故障，本地存储桶中仍存有数据，且该数据会在集合或域新增可用后立即恢复。

您也可以有效地将这些解决方案应用于主动被动复制模型。在这些场景中，只需在复制区域中拥有如一个 S3 存储桶等最低限度的资源。您可以借助其他服务如 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 修改此解决方案，以解决不同场景，因其具备内置的 复制特性。

在构建跨区域解决方案时，请考虑 AWS 的跨区域数据传输费用。作为最佳实践，建议给所有生产管道添加一个 死信队列。

结论

在本文中，我们概述了两种可实现 OpenSearch Serverless 和 OpenSearch Service 托管集群区域弹性的解决方案。如果您需要显式控制跨区域写入数据，请使用方案一。在我们对几 KB 数据的实验中，大多数写入在两个选定区域之间都在一秒内完成。如果您需要简单的解决方案，可以选择方案二。我们在实验中发现，复制在几秒内顺利完成。 9999 的对象将在 15 分钟内完成复制。这些解决方案同样适用于使用 OpenSearch Ingestion 的 OpenSearch Service 主动主动复制模型。

您还可以将 OSI 用作在其他 AWS 服务如 Amazon S3、Amazon DynamoDB 和 Amazon DocumentDB (兼容 MongoDB)中查找数据的一种机制。有关更多详细信息，请参阅 使用 Amazon OpenSearch Ingestion 管道集成。

作者介绍

![Muthu Pitch