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

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

关键要点

• 跨区域部署能够在发生故障或自然灾害时增加业务持续性。
• Amazon OpenSearch Service 提供高可用性和区域弹性，通过跨集群复制功能确保数据在多个区域有效管理。
• 本文提供两种无须在故障恢复期间重新建立域关系的解决方案。一种利用 Amazon OpenSearch Ingestion (OSI)，另一种利用 Amazon S3 实现跨区域写入。

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

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

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

解决方案概述

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

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

前提条件

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

1. 或 。
2. 在每个区域中 。
3. 配置与 OSI 相关的 (IAM) 权限。有关说明，请参阅 。选择 (Amazon SQS) 作为处理数据的方法。

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

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

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

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

以下是数据流的示意图。

数据流包括以下步骤：

1. 区域内的数据源将其数据写入其区域的 OSI 管道（此解决方案还支持数据源直接写入 Amazon S3）。
2. OSI 将此数据写入集合，然后再写入其他区域的 S3 存储桶。
3. OSI 从本地 S3 存储桶读取其他区域的数据，并将其写入本地集合。
4. 两个区域的集合现在包含相同的数据。

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

# 跨区域写入管道配置

version: "2" write-pipeline: source: http: path: "/logs" processor: \-
parse_json: sink: # 第一个输出到同区域集合 \- opensearch: hosts: [
"https://abcdefghijklmn.us-east-1.aoss.amazonaws.com" ] aws: sts_role_arn:
"arn:aws:iam::1234567890:role/pipeline-role" region: "us-east-1" serverless:
true index: "cross-region-index" \- s3: # 第二个输出到跨区域 S3 存储桶 aws: sts_role_arn:
"arn:aws:iam::1234567890:role/pipeline-role" region: "us-east-2" bucket: "osi-
cross-region-bucket" object_key: path_prefix: "osi-
crw/%{yyyy}/%{MM}/%{dd}/%{HH}" threshold: event_collect_timeout: 60s codec:
ndjson: ```

写管道的代码如下：

```yaml

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

version: "2" read-write-pipeline: source: s3: acknowledgments: truenotification_type: "sqs" compression: "none" codec: newline: sqs: queue_url:
"https://sqs.us-east-1.amazonaws.com/1234567890/my-osi-cross-region-write-q"
maximum_messages: 10 visibility_timeout: "60s"
visibility_duplication_protection: true aws: region: "us-east-1" sts_role_arn:
"arn:aws:iam::123567890:role/pipe-line-role" processor: \- parse_json: route:
# 路由使用 s3 密钥确保 OSI 仅将数据写入本区域一次 \- local-region-write: "contains(/s3/key,
\"osi-local-region-write\")" \- cross-region-write: "contains(/s3/key, \"osi-
cross-region-write\")" sink: \- pipeline: name: "local-region-write-cross-
region-write-pipeline" \- pipeline: name: "local-region-write-pipeline"
routes: \- local-region-write

local-region-write-cross-region-write-pipeline: # 从支持跨区域写入的 S3 存储桶读取 source:
pipeline: name: "read-write-pipeline" sink: # 输出到本区域的 OpenSearch 服务 \-
opensearch: hosts: 。此解决方案支持所有 。OSI 再次使用两个管道，但关键区别在于 OSI 首先将数据写入 Amazon S3。完成两种解决方案共有的步骤后，请参考
 以进行 Amazon S3 跨区域复制的配置。以下是数据流的示意图。

![数据流](https://d2908q01vomqb2.cloudfront.net/artifacts/DBSBlogs/BDB-4206/BDB-4206-sol2.gif)

数据流包括以下步骤：

  1. 区域内的数据源将其数据写入 OSI（此解决方案也支持数据源直接写入 Amazon S3）。
  2. 数据首先写入 S3 存储桶。
  3. OSI 从 S3 读取这些数据并写入本区域的集合。
  4. Amazon S3 跨区域复制数据，并且 OSI 读取并将这些数据写入集合。

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

`yaml version: "2" s3-write-pipeline: source: http: path: "/logs" processor: -
parse_json: sink: # 写入启用跨区域复制的 S3 存储桶 - s3: aws: sts_role_arn:
"arn:aws:iam::1234567890:role/pipeline-role" region: "us-east-2" bucket:
"s3-cross-region-bucket" object_key: path_prefix:
"pushedlogs/%{yyyy}/%{MM}/%{dd}/%{HH}" threshold: event_collect_timeout: 60sevent_count: 2 codec: ndjson:`

写管道的代码如下：

`yaml version: "2" s3-read-pipeline: source: s3: acknowledgments: truenotification_type: "sqs" compression: "none" codec: newline: # 配置 SQS 以通知 OSI管道 sqs: queue_url: "https://sqs.us-
east-2.amazonaws.com/1234567890/my-s3-crr-q" maximum_messages: 10visibility_timeout: "15s" visibility_duplication_protection: true aws: region:
"us-east-2" sts_role_arn: "arn:aws:iam::1234567890:role/pipeline-role"
processor: - parse_json: # 配置 OSI 输出，将文件从 S3 移动到 OpenSearch Serverless sink: -
opensearch: hosts: 。

## 故障场景和其他注意事项

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

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

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

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

您也可以有效地将这些解决方案应用于主动-被动复制模型。在这些场景中，只需在复制区域中拥有如一个 S3 存储桶等最低限度的资源。您可以借助其他服务如

(Amazon MSK) 修改此解决方案，以解决不同场景，因其具备内置的
。

在构建跨区域解决方案时，请考虑 。作为最佳实践，建议给所有生产管道添加一个
。

## 结论

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

您还可以将 OSI 用作在其他 AWS 服务（如 Amazon S3、 和 [Amazon DocumentDB (兼容
MongoDB)](https://aws.amazon.com/documentdb/)）中查找数据的一种机制。有关更多详细信息，请参阅 。

* * *

### 作者介绍

![Muthu Pitch