本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # UltraWarm 亚马逊 OpenSearch 服务的存储空间 UltraWarm 为在 Amazon OpenSearch 服务上存储大量只读数据提供了一种经济实惠的方式。标准数据节点使用“热”存储，其形式是连接到每个节点的实例存储或 Amazon EBS 卷。热存储为编制索引和搜索新数据提供尽可能快的性能。 UltraWarm 节点不使用附加存储，而是使用 Amazon S3 和复杂的缓存解决方案来提高性能。对于不主动写入、查询频率较低且不需要相同性能的索引， UltraWarm 可以显著降低每 GiB 数据的成本。因为除非将温索引返回到热存储，否则它们 UltraWarm 是只读的，因此最适合存储不可变的数据，例如日志。 在中 OpenSearch，暖索引的行为与任何其他索引一样。您可以使用相同的方法查询它们， APIs 也可以使用它们在 OpenSearch 仪表板中创建可视化效果。 **Topics** + [先决条件](#ultrawarm-pp) + [UltraWarm 存储要求和性能注意事项](#ultrawarm-calc) + [UltraWarm 定价](#ultrawarm-pricing) + [启用 UltraWarm](#ultrawarm-enable) + [将索引迁移到 UltraWarm 存储](#ultrawarm-migrating) + [自动执行迁移](#ultrawarm-ism) + [迁移调整](#ultrawarm-settings) + [取消迁移](#ultrawarm-cancel) + [列出热索引和暖索引](#ultrawarm-api) + [将温索引返回到热存储](#ultrawarm-migrating-back) + [从快照恢复温索引](#ultrawarm-snapshot) + [暖索引的手动快照](#ultrawarm-manual-snapshot) + [将温索引迁移到冷存储](#ultrawarm-cold) + [KNN 索引的最佳实践](#ultrawarm-recommendations) + [正在禁用 UltraWarm](#ultrawarm-disable) ## 先决条件 UltraWarm 有几个重要的先决条件： + UltraWarm 需要 OpenSearch 或 Elasticsearch 6.8 或更高版本。 + 要使用温存储，域必须具有[专用的主节点](managedomains-dedicatedmasternodes.md)。 + 使用[带待机功能的多可用区](managedomains-multiaz.md#managedomains-za-standby)域时，温节点的数量必须是所用可用区数量的整数倍。 + 如果您的域为数据节点使用 T2 实例类型，则无法使用温存储。 + 如果您的索引使用近似 k-NN（`"index.knn":true`），则可将版本 2.17 及更高版本移至温存储。2.17 之前版本的域名可以升级到 2.17 以使用此功能，但是在 2.x 之前的版本上创建的 KNN 索引无法迁移到。 UltraWarm + 如果网域使用[精细的访问控制](fgac.md)，则必须将用户映射到控制 OpenSearch 面板中的`ultrawarm_manager`角色才能进行 UltraWarm API 调用。 **注意** 可能无法在某些先前存在的 OpenSearch 服务域上定义该`ultrawarm_manager`角色。如果没有在控制面板中看到角色，则需要[手动创建它](#ultrawarm-create-role)。 ### 配置权限 如果您在先前存在的 OpenSearch 服务域 UltraWarm 上启用，则可能无法在该域上定义该`ultrawarm_manager`角色。必须将非管理员用户映射到此角色，才能使用精细访问控制管理域上的温索引。手动创建 `ultrawarm_manager` 角色，请执行下列步骤： 1. 在 “ OpenSearch 控制面板” 中，转至 “**安全**”，然后选择 “**权限**”。 1. 选择**创建操作组**并配置以下组： [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/opensearch-service/latest/developerguide/ultrawarm.html) 1. 选择**角色**和**创建角色**。 1. 将角色命名为 **ultrawarm\$1manager**。 1. 对于**群集权限**，选择 `ultrawarm_cluster` 和 `cluster_monitor`。 1. 对于**索引**，键入 `*`。 1. 对于**索引权限**，选择 `ultrawarm_index_read`、`ultrawarm_index_write` 和 `indices_monitor`。 1. 选择**创建**。 1. 创建角色后，[将其映射](fgac.md#fgac-mapping)到任何将管理 UltraWarm 索引的用户或后端角色。 ## UltraWarm 存储要求和性能注意事项 如所述[计算存储要求](bp-storage.md)，热存储中的数据会产生大量开销：副本、Linux 预留空间和 OpenSearch 服务预留空间。例如，具有一个副本分片的 20 GiB 主分片需要大约 58 GiB 的热存储。 由于它使用 Amazon S3，因此不会 UltraWarm 产生任何开销。在计算 UltraWarm 存储需求时，您只考虑主分片的大小。S3 中数据的持久性消除了对副本的需要，而 S3 会抽象掉任何操作系统或服务注意事项。同样的 20 GiB 分片需要 20 GiB 的温存储空间。如果您预配置一个 `ultrawarm1.large.search` 实例，则可以将其所有 20 TiB 的最大存储空间用于主分片。有关实例类型的摘要以及每个实例可以解决的最大存储量，请参阅[UltraWarm 存储配额](limits.md#limits-ultrawarm)。 使用 UltraWarm，我们仍然建议最大分片大小为 50 GiB。通过[分配给每种 UltraWarm 实例类型的 CPU 内核数量和 RAM](#ultrawarm-pricing) 量，您可以大致了解它们可以同时搜索的分片数量。请注意，虽然在 S3 中只有主分片计入 UltraWarm存储空间，但 OpenSearch 控制面板和`_cat/indices`仍将 UltraWarm 索引大小报告为所有主分片和副本分片的*总*和。 例如，每个 `ultrawarm1.medium.search` 实例具有两个 CPU 内核，并且可以在 S3 上寻址高达 1.5 TiB 的存储。其中两个实例具有 3 TiB 的存储组合，如果每个分片为 50 GiB，则可以使用大约 62 个分片。如果对集群的请求仅搜索其中的四个分片，则性能可能会非常优良。如果请求很宽泛并且搜索了所有 62 个分片，则四个 CPU 内核可能难以执行该操作。监控`WarmCPUUtilization`和`WarmJVMMemoryPressure`[UltraWarm 指标](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)以了解实例如何处理您的工作负载。 如果您的搜索范围广泛或频繁，请考虑将索引留在热存储中。就像任何其他 OpenSearch 工作负载一样，确定是否 UltraWarm 满足需求的最重要步骤是使用真实的数据集进行具有代表性的客户测试。 ## UltraWarm 定价 使用热存储，您需要为预配置的内容支付费用。有些实例需要附加的 Amazon EBS 卷，而其他实例则包含实例存储。无论该存储空间是空还是满，您都要支付相同的价格。 对于 UltraWarm 存储空间，您需要为实际使用量付费。一个 `ultrawarm1.large.search` 实例可以在 S3 上处理多达 20 TiB 的存储空间，但如果您仅存储 1 TiB 的数据，则只需为 1 TiB 的数据付费。与所有其他节点类型一样，您还需要为每个 UltraWarm 节点支付小时费率。有关更多信息，请参阅 [Amazon OpenSearch 服务的定价](what-is.md#pricing)。 ## 启用 UltraWarm 控制台是创建使用温存储的域的最简单方法。创建域时，请选择**启用温数据节点**，然后选择所需的温节点数。相同的基本过程适用于现有域，前提是它们满足[先决条件](#ultrawarm-pp)。即使在域状态从 “**处理**中” 变为 “**活动**” 之后，也 UltraWarm 可能在几个小时内无法使用。 使用带待机功能的多可用区域时，温节点的数量必须是可用区数量的整数倍。有关更多信息，请参阅 [带待机功能的多可用区](managedomains-multiaz.md#managedomains-za-standby)。 您也可以使用[Amazon CLI](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/opensearch/index.html)或[配置 API](https://docs.amazonaws.cn/opensearch-service/latest/APIReference/Welcome.html) 来启用 UltraWarm，特别是中的`WarmEnabled``WarmCount`、和`WarmType`选项`ClusterConfig`。 **注意** 域支持最大数量的温节点。有关更多信息，请参阅 [亚马逊 OpenSearch 服务配额](limits.md)。 ### 示例 CLI 命令 以下 Amazon CLI 命令创建一个具有三个数据节点、三个专用主节点、六个温节点并启用了细粒度访问控制的域： ``` aws opensearch create-domain \ --domain-name my-domain \ --engine-version Opensearch_1.0 \ --cluster-config InstanceCount=3,InstanceType=r6g.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3,ZoneAwarenessEnabled=true,ZoneAwarenessConfig={AvailabilityZoneCount=3},WarmEnabled=true,WarmCount=6,WarmType=ultrawarm1.medium.search \ --ebs-options EBSEnabled=true,VolumeType=gp2,VolumeSize=11 \ --node-to-node-encryption-options Enabled=true \ --encryption-at-rest-options Enabled=true \ --domain-endpoint-options EnforceHTTPS=true,TLSSecurityPolicy=Policy-Min-TLS-1-2-2019-07 \ --advanced-security-options Enabled=true,InternalUserDatabaseEnabled=true,MasterUserOptions='{MasterUserName=master-user,MasterUserPassword=master-password}' \ --access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":["123456789012"]},"Action":["es:*"],"Resource":"arn:aws:es:us-west-1:123456789012:domain/my-domain/*"}]}' \ --region us-east-1 ``` 有关更多信息，请参阅 [Amazon CLI 命令参考](https://docs.amazonaws.cn/cli/latest/reference/)。 ### 示例配置 API 请求 对配置 API 的以下请求创建一个域，其中包含三个数据节点、三个专用主节点以及六个温节点（启用了精细访问控制并具有限制性访问策略）： ``` POST https://es.us-east-2.amazonaws.com/2021-01-01/opensearch/domain { "ClusterConfig": { "InstanceCount": 3, "InstanceType": "r6g.large.search", "DedicatedMasterEnabled": true, "DedicatedMasterType": "r6g.large.search", "DedicatedMasterCount": 3, "ZoneAwarenessEnabled": true, "ZoneAwarenessConfig": { "AvailabilityZoneCount": 3 }, "WarmEnabled": true, "WarmCount": 6, "WarmType": "ultrawarm1.medium.search" }, "EBSOptions": { "EBSEnabled": true, "VolumeType": "gp2", "VolumeSize": 11 }, "EncryptionAtRestOptions": { "Enabled": true }, "NodeToNodeEncryptionOptions": { "Enabled": true }, "DomainEndpointOptions": { "EnforceHTTPS": true, "TLSSecurityPolicy": "Policy-Min-TLS-1-2-2019-07" }, "AdvancedSecurityOptions": { "Enabled": true, "InternalUserDatabaseEnabled": true, "MasterUserOptions": { "MasterUserName": "master-user", "MasterUserPassword": "master-password" } }, "EngineVersion": "Opensearch_1.0", "DomainName": "my-domain", "AccessPolicies": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"AWS\":[\"123456789012\"]},\"Action\":[\"es:*\"],\"Resource\":\"arn:aws:es:us-east-1:123456789012:domain/my-domain/*\"}]}" } ``` 有关详细信息，请参阅[亚马逊 OpenSearch 服务 API 参考](https://docs.amazonaws.cn/opensearch-service/latest/APIReference/Welcome.html)。 ## 将索引迁移到 UltraWarm 存储 如果您完成了对索引的写入并且不再需要尽可能快的搜索性能，请将其从 hot 迁移到 UltraWarm： ``` POST _ultrawarm/migration/my-index/_warm ``` 然后检查迁移的状态： ``` GET _ultrawarm/migration/my-index/_status { "migration_status": { "index": "my-index", "state": "RUNNING_SHARD_RELOCATION", "migration_type": "HOT_TO_WARM", "shard_level_status": { "running": 0, "total": 5, "pending": 3, "failed": 0, "succeeded": 2 } } } ``` 索引运行状况必须为绿色才能执行迁移。如果您快速连续迁移多个索引，您可以获得所有迁移的明文摘要，类似于 `_cat` API： ``` GET _ultrawarm/migration/_status?v index migration_type state my-index HOT_TO_WARM RUNNING_SHARD_RELOCATION ``` OpenSearch 服务一次将一个索引迁移到。 UltraWarm队列中最多可包含 200 个迁移。任何超出限制的请求都将被拒绝。要检查队列中的当前迁移数，请监控 `HotToWarmMigrationQueueSize` [指标](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)。在整个迁移过程中，索引仍然可用，无需停机。 迁移过程具有以下状态： ``` PENDING_INCREMENTAL_SNAPSHOT RUNNING_INCREMENTAL_SNAPSHOT FAILED_INCREMENTAL_SNAPSHOT PENDING_FORCE_MERGE RUNNING_FORCE_MERGE FAILED_FORCE_MERGE PENDING_FULL_SNAPSHOT RUNNING_FULL_SNAPSHOT FAILED_FULL_SNAPSHOT PENDING_SHARD_RELOCATION RUNNING_SHARD_RELOCATION FINISHED_SHARD_RELOCATION ``` 如这些状态所示，迁移可能会在快照、分片重新定位或强制合并期间失败。快照或分片重新定位期间的故障通常是由于节点故障或 S3 连接问题造成的。磁盘空间不足通常是强制合并失败的根本原因。 迁移完成后，同一 `_status` 请求返回错误。如果您在此时检查索引，您可以看到暖索引独有的一些设置： ``` GET my-index/_settings { "my-index": { "settings": { "index": { "refresh_interval": "-1", "auto_expand_replicas": "false", "provided_name": "my-index", "creation_date": "1599241458998", "unassigned": { "node_left": { "delayed_timeout": "5m" } }, "number_of_replicas": "1", "uuid": "GswyCdR0RSq0SJYmzsIpiw", "version": { "created": "7070099" }, "routing": { "allocation": { "require": { "box_type": "warm" } } }, "number_of_shards": "5", "merge": { "policy": { "max_merge_at_once_explicit": "50" } } } } } } ``` + 在这种情况下，`number_of_replicas` 是不消耗磁盘空间的被动副本的数量。 + `routing.allocation.require.box_type` 指定索引应使用热节点而不是标准数据节点。 + `merge.policy.max_merge_at_once_explicit` 指定迁移期间要同时合并的段数。 温存储中的索引是只读的，除非您将[它们返回到热存储](#ultrawarm-migrating-back)，这 UltraWarm 最适合存储不可变的数据，例如日志。您可以查询索引并将其删除，但无法添加、更新或删除单个文档。如果尝试，您可能会遇到以下错误：。 ``` { "error" : { "root_cause" : [ { "type" : "cluster_block_exception", "reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];" } ], "type" : "cluster_block_exception", "reason" : "index [indexname] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];" }, "status" : 429 } ``` ## 自动执行迁移 我们建议在索引达到特定期限或满足其他条件后使用 [Amazon OpenSearch 服务中的索引状态管理](ism.md) 自动执行迁移过程。请参阅演示该工作流程的[示例策略](ism.md#ism-example-cold)。 ## 迁移调整 索引迁移到 UltraWarm 存储需要强制合并。每个 OpenSearch 索引由一定数量的分片组成，每个分片由一定数量的 Lucene 片段组成。强制合并操作清除标记为删除的文档，并节省磁盘空间。默认情况下，会将索引 UltraWarm 合并到一个段中，kNN 索引除外，其中使用默认值 20。 您可以将此值更改为达 1,000 个分段，使用 `index.ultrawarm.migration.force_merge.max_num_segments` 设置。更高的值会加快迁移过程，但在迁移完成后会增加温索引的查询延迟。要更改设置，请执行下列请求： ``` PUT my-index/_settings { "index": { "ultrawarm": { "migration": { "force_merge": { "max_num_segments": 1 } } } } } ``` 要检查迁移过程的此阶段花费的时间，请监视 `HotToWarmMigrationForceMergeLatency` [指标](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)。 ## 取消迁移 UltraWarm 按顺序处理队列中的迁移。如果迁移在队列中，但尚未开始，您可以使用以下请求将迁移从队列中删除： ``` POST _ultrawarm/migration/_cancel/my-index ``` 如果您的域使用精细访问控制，则必须使用 `indices:admin/ultrawarm/migration/cancel` 权限提出此请求。 ## 列出热索引和暖索引 UltraWarm 添加了另外两个选项，类似于`_all`，以帮助管理热索引和温索引。有关所有暖索引或热索引的列表，请提出以下请求： ``` GET _warm GET _hot ``` 您可以在指定索引的其他请求中使用这些选项，例如： ``` _cat/indices/_warm _cluster/state/_all/_hot ``` ## 将温索引返回到热存储 如果您需要再次写入索引，请将其迁移回热存储： ``` POST _ultrawarm/migration/my-index/_hot ``` 一次最多可以有 10 个从温存储到热存储的排队迁移。 OpenSearch 服务按排队顺序逐一处理迁移请求。要查看当前数量，请监控`WarmToHotMigrationQueueSize`[指标](managedomains-cloudwatchmetrics.md#managedomains-cloudwatchmetrics-uw)。 迁移完成后，检查索引设置以确保它们满足需求。索引使用一个副本返回热存储。 ## 从快照恢复温索引 除了用于自动快照的标准存储库外，还 UltraWarm 添加了第二个用于温索引的存储库`cs-ultrawarm`。此存储库中的每个快照只包含一个索引。如果删除温索引，其快照将保留在 `cs-ultrawarm` 存储库中 14 天，就像任何其他自动执行的快照一样。 从 `cs-ultrawarm` 还原快照时，快照会恢复到温存储，而不是热存储。`cs-automated-enc` 和 `cs-automated` 存储库中的快照还原到热存储。 **将 UltraWarm 快照恢复到温存储空间** 1. 标识包含要还原的索引的最新快照： ``` GET _snapshot/cs-ultrawarm/_all?verbose=false { "snapshots": [{ "snapshot": "snapshot-name", "version": "1.0", "indices": [ "my-index" ] }] } ``` **注意** 默认情况下，`GET _snapshot/` 操作显示存储库中每个快照的开始时间、结束时间和持续时间等详细数据信息。`GET _snapshot/` 操作从存储库包含的每个快照文件中检索信息。如果不需要开始时间、结束时间和持续时间，只需要快照名称和索引信息，我们建议您在列出快照时使用 `verbose=false` 参数，以最大限度地缩短处理时间并防止超时。 1. 如果索引已经存在，请将其删除： ``` DELETE my-index ``` 如果不想删除索引，请[将其返回到热存储](#ultrawarm-migrating-back)和[重新编制索引](https://docs.opensearch.org/latest/opensearch/reindex-data/)它。 1. 还原快照： ``` POST _snapshot/cs-ultrawarm/snapshot-name/_restore ``` UltraWarm 会忽略您在此还原请求中指定的任何索引设置，但您可以指定`rename_pattern`和`rename_replacement`之类的选项。有关 OpenSearch 快照还原选项的摘要，请参阅[OpenSearch 文档](https://docs.opensearch.org/latest/opensearch/snapshot-restore/#restore-snapshots)。 ## 暖索引的手动快照 您*可以*手动拍摄暖索引的快照，但我们不建议这样做。自动执行 `cs-ultrawarm` 存储库已包含在迁移期间拍摄的每个热索引的快照，无需额外付费。 默认情况下，S OpenSearch ervice 不在手动快照中包含热索引。例如，以下调用只包含热索引： ``` PUT _snapshot/my-repository/my-snapshot ``` 如果您选择手动拍摄暖索引的快照，则需要考虑几个重要的因素。 + 您不能将热索引和暖索引混合使用。例如，下面的命令将失败： ``` PUT _snapshot/my-repository/my-snapshot { "indices": "warm-index-1,hot-index-1", "include_global_state": false } ``` 如果将热索引和暖索引混合，则通配符（`*`）语句也会失败。 + 每个快照只能包含一个温索引。例如，下面的命令将失败： ``` PUT _snapshot/my-repository/my-snapshot { "indices": "warm-index-1,warm-index-2,other-warm-indices-*", "include_global_state": false } ``` 此请求成功： ``` PUT _snapshot/my-repository/my-snapshot { "indices": "warm-index-1", "include_global_state": false } ``` + 手动快照始终恢复到热存储，即使它们最初包含热索引也是如此。 ## 将温索引迁移到冷存储 如果您不经常查询数据 UltraWarm ，请考虑将其迁移到冷存储。冷存储适用于您偶尔访问的数据或不再处于活动状态的数据。您无法读取或写入冷索引，但可以在需要查询时免费将它们迁移回暖存储。有关说明，请参阅[将索引迁移至冷存储](https://docs.amazonaws.cn/opensearch-service/latest/developerguide/cold-storage.html#coldstorage-migrating)。 ## KNN 索引的最佳实践 + Ultrawarm/冷存储层级适用于所有 KNN 索引引擎类型。我们建议在使用 Lucene 引擎和磁盘优化向量搜索的 KNN 索引中采用此方案，这无需将图形数据完全加载到堆外内存中。在将其与 FAISS 和 NMSLIB 等原生内存引擎一起使用时，必须考虑要主动搜索的分片图形大小，并相应地配置 UltraWarm实例，最好是实例类型的实例。`uw.large`例如，如果客户已配置 2 个 `uw.large` 实例，则每个实例将有约 `knn.memory.circuit_breaker.limit * 61` GiB 的可用堆外内存。如果所有热查询都针对累积图形大小不超过可用堆外内存的分片，则可获得最佳性能。如果由于驱逐和等待堆外内存释放而导致可用内存低于加载图所需的内存，则会影响延迟。因此，我们不建议在使用内存引擎的使用案例或需要更高搜索吞吐量的场景中使用 `uw.medium` 实例，无论采用何种引擎。 + 迁移到的 KNN 索引 UltraWarm 不会被强制合并到单个片段。这可避免因图规模过大导致内存引擎无法处理，从而引发热节点和温节点遭遇 OOM 问题的情况。由于每个分片的分段数量增加，这可能会导致消耗更多本地缓存空间，并使迁移到温层的索引数量减少。您可以选择使用现有设置强制将索引合并到单个分段，并在将索引迁移到温层之前覆盖该设置。有关更多信息，请参阅 [迁移调整](#ultrawarm-settings)。 + 如果您的用例很少搜索索引，并且不处理延迟敏感的工作负载，则可以选择将这些索引迁移到该 UltraWarm 层。这将帮助您缩小热层计算实例的规模，让 UltraWarm 分层计算处理对此类低优先级索引的查询。这还有助于实现低优先级索引与高优先级索引查询之间资源消耗的隔离，从而避免相互影响。 ## 正在禁用 UltraWarm 控制台是最简单的禁用方法 UltraWarm。选择域、**Actions（操作）**和 **Edit cluster configuration（编辑集群配置）**。选择**启用温数据节点**，然后选择**保存更改**。还可以在 Amazon CLI 和配置 API 中使用 `WarmEnabled` 选项。 在禁用之前 UltraWarm，必须[删除](https://opensearch.org/docs/latest/opensearch/rest-api/index-apis/delete-index/)所有热索引或[将其迁移回热存储](#ultrawarm-migrating-back)。热存储空间为空后，请等待五分钟，然后再尝试禁用 UltraWarm。