UltraWarm Amazon OpenSearch 服务的存储空间 - 亚马逊 OpenSearch 服务
先决条件UltraWarm 存储要求和性能注意事项UltraWarm 定价启用 UltraWarm将索引迁移到 UltraWarm 存储自动执行迁移迁移调整取消迁移列出热索引和暖索引将温索引返回到热存储从快照恢复温索引暖索引的手动快照将温索引迁移到冷存储KNN 索引的最佳实践禁用 UltraWarm
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

UltraWarm Amazon OpenSearch 服务的存储空间

UltraWarm 通过经济高效的方式在 Amazon S OpenSearch ervice 上存储大量只读数据。标准数据节点使用“热”存储，其形式是连接到每个节点的实例存储或 Amazon EBS 卷。热存储为编制索引和搜索新数据提供尽可能快的性能。

UltraWarm 节点使用 Amazon S3 和高级缓存解决方案来提高性能，而不是使用附加的存储。对于您未主动写入、查询频率较低且不需要同样性能的索引， UltraWarm 可显著降低每 GiB 数据的成本。由于 warm 索引是只读的，除非您将其返回到热存储，所 UltraWarm 以 warm 最适合于不可变数据，如日志。

在中 OpenSearch，这些温索引的行为与任何其他索引一样。您可以使用相同的方法查询它们， APIs 也可以使用它们在 OpenSearch 控制面板中创建可视化。

先决条件

UltraWarm 有几个重要的先决条件：

  • UltraWarm 需要 OpenSearch 或 Elasticsearch 6.8 或更高版本。

  • 要使用温存储，域必须具有专用的主节点。

  • 使用带待机功能的多可用区域时，温节点的数量必须是所用可用区数量的整数倍。

  • 如果您的域为数据节点使用 T2 实例类型，则无法使用温存储。

  • 如果您的索引使用近似 k-NN ("index.knn":true)，则您可以将其从2.17及更高版本移到温存储。2.17 之前版本的域名可以升级到 2.17 以使用此功能，但是在 2.x 之前的版本上创建的 KNN 索引无法迁移到。 UltraWarm

  • 如果您的域使用精细访问控制，则必须将用户映射到控制 OpenSearch 面板中的ultrawarm_manager角色进行 UltraWarm API 调用。

注意

ultrawarm_manager角色可能无法在某些预先存在的 OpenSearch 服务域上定义。如果没有在控制面板中看到角色，则需要手动创建它。

配置权限

如果在预先存在的 OpenSearch 服务域 UltraWarm 上启用，ultrawarm_manager角色可能无法在域上定义。必须将非管理员用户映射到此角色，才能使用精细访问控制管理域上的温索引。手动创建 ultrawarm_manager 角色，请执行下列步骤：

  1. 在 “ OpenSearch 控制面板” 中，转至 “安全”，然后选择 “权限”。

  2. 选择创建操作组并配置以下组：

    组名 权限
    ultrawarm_cluster

    • cluster:admin/ultrawarm/migration/list

    • cluster:monitor/nodes/stats
    ultrawarm_index_read

    • indices:admin/ultrawarm/migration/get

    • indices:admin/get
    ultrawarm_index_write

    • indices:admin/ultrawarm/migration/warm

    • indices:admin/ultrawarm/migration/hot

    • indices:monitor/stats

    • indices:admin/ultrawarm/migration/cancel

  3. 选择角色和创建角色。

  4. 将角色命名为 ultrawarm_manager。

  5. 对于群集权限，选择 ultrawarm_cluster 和 cluster_monitor。

  6. 对于索引，键入 *。

  7. 对于索引权限，选择 ultrawarm_index_read、ultrawarm_index_write 和 indices_monitor。

  8. 选择创建。

  9. 创建角色之后，将其映射到将管理 UltraWarm 索引的任何用户或后端角色。

UltraWarm 存储要求和性能注意事项

如中所述计算存储要求，热存储中的数据会产生大量开销：副本、Linux 预留空间和 OpenSearch 服务预留空间。例如，具有一个副本分片的 20 GiB 主分片需要大约 58 GiB 的热存储。

因为它使用 Amazon S3，因此不会 UltraWarm 产生这种开销。计算 UltraWarm 存储要求时，您只需考虑主碎片的大小。S3 中数据的持久性消除了对副本的需要，而 S3 会抽象掉任何操作系统或服务注意事项。同样的 20 GiB 分片需要 20 GiB 的温存储空间。如果您预配置一个 ultrawarm1.large.search 实例，则可以将其所有 20 TiB 的最大存储空间用于主分片。有关实例类型的摘要以及每个实例可以解决的最大存储量，请参阅UltraWarm 存储配额。

使用 UltraWarm，我们仍然建议最大分片大小为 50 GiB。分配给每种 UltraWarm 实例类型的 CPU 核心数量和 RAM 量可以让您了解他们可以同时搜索的分片数量。请注意，虽然在 S3 中只有主碎片计入 S3 中的 UltraWarm存储，但 OpenSearch 控制面板和_cat/indices仍会将 UltraWarm 索引大小报告为所有主碎片和副本碎片的总和。

例如，每个 ultrawarm1.medium.search 实例具有两个 CPU 内核，并且可以在 S3 上寻址高达 1.5 TiB 的存储。其中两个实例具有 3 TiB 的存储组合，如果每个分片为 50 GiB，则可以使用大约 62 个分片。如果对集群的请求仅搜索其中的四个分片，则性能可能会非常优良。如果请求很宽泛并且搜索了所有 62 个分片，则四个 CPU 内核可能难以执行该操作。监控WarmCPUUtilization和WarmJVMMemoryPressureUltraWarm 指标以了解实例如何处理您的工作负载。

如果您的搜索范围广泛或频繁，请考虑将索引留在热存储中。与任何其他 OpenSearch 工作负载一样，要确定是否 UltraWarm 满足您的需求，最重要的步骤是使用真实的数据集执行有代表性的客户端测试。

UltraWarm 定价

使用热存储，您需要为预配置的内容支付费用。有些实例需要附加的 Amazon EBS 卷，而其他实例则包含实例存储。无论该存储空间是空还是满，您都要支付相同的价格。

使用 UltraWarm 存储，您只需按实际用量付费。一个 ultrawarm1.large.search 实例可以在 S3 上处理多达 20 TiB 的存储空间，但如果您仅存储 1 TiB 的数据，则只需为 1 TiB 的数据付费。与所有其他节点类型一样，您还需要按小时费率支付费用。 UltraWarm 有关更多信息，请参阅 Amazon S OpenSearch ervice 定价。

启用 UltraWarm

控制台是创建使用温存储的域的最简单方法。创建域时，选择启用温数据节点和所需的温节点数量。相同的基本过程适用于现有域，前提是它们满足先决条件。即使域状态从 Processing (正在处理) 变为 A ctiv e (活动) 后， UltraWarm 可能也会在几个小时内无法使用。

使用带待机功能的多可用区域时，温节点的数量必须是可用区数量的整数倍。有关更多信息，请参阅 带待机功能的多可用区。

您也可以使用Amazon CLI或配置 API 来启用 UltraWarm，特别是中的WarmEnabledWarmCount、和WarmType选项ClusterConfig。

注意

域支持最大数量的温节点。有关更多信息，请参阅 Amazon OpenSearch 服务配额。

示例 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 命令参考。

示例配置 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 参考》。

将索引迁移到 UltraWarm 存储

如果您完成了对索引的写入，并且不再需要尽可能快的搜索性能，请将其从热索引转换为 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 Service 一次将一个索引迁移到。 UltraWarm队列中最多可包含 200 个迁移。任何超出限制的请求都将被拒绝。要检查队列中的当前迁移数，请监控 HotToWarmMigrationQueueSize 指标。在整个迁移过程中，索引仍然可用，无需停机。

迁移过程具有以下状态：

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 最适合于不可变的数据，例如日志。您可以查询索引并将其删除，但无法添加、更新或删除单个文档。如果尝试，您可能会遇到以下错误：。

{
  "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 S OpenSearch ervice 中的索引状态管理 自动执行迁移过程。请参阅演示该工作流程的示例策略。

迁移调整

向 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 指标。

取消迁移

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 Service 按照迁移请求的排队顺序，一次处理一个请求。要查看当前数量，请监控WarmToHotMigrationQueueSize指标。

迁移完成后，检查索引设置以确保它们满足需求。索引使用一个副本返回热存储。

从快照恢复温索引

除用于自动快照的标准存储库之外，还 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/<repo> 操作显示存储库中每个快照的开始时间、结束时间和持续时间等详细数据信息。GET _snapshot/<repo> 操作从存储库包含的每个快照文件中检索信息。如果不需要开始时间、结束时间和持续时间，只需要快照名称和索引信息，我们建议您在列出快照时使用 verbose=false 参数，以最大限度地缩短处理时间并防止超时。

  2. 如果索引已经存在，请将其删除：

    DELETE my-index

    如果不想删除索引，请将其返回到热存储和重新编制索引它。

  3. 还原快照：

    POST _snapshot/cs-ultrawarm/snapshot-name/_restore

    UltraWarm 会忽略您在此还原请求中指定的任何索引设置，但您可以指定，如rename_pattern和rename_replacement。有关 OpenSearch 快照还原选项的摘要，请参阅OpenSearch 文档。

暖索引的手动快照

您可以手动拍摄暖索引的快照，但我们不建议这样做。自动执行 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 ，请考虑将其迁移到冷存储。冷存储适用于您偶尔访问的数据或不再处于活动状态的数据。您无法读取或写入冷索引，但可以在需要查询时免费将它们迁移回暖存储。有关说明，请参阅将索引迁移到冷存储。

KNN 索引的最佳实践

  • Ultrawarm/Cold 等级适用于所有 KNN 索引引擎类型。我们建议使用 Lucene 引擎和磁盘优化的向量搜索的 KNN 索引使用它，这不需要将图形数据完全加载到堆外内存中。在将其与 FAISS 和 NMSLIB 等原生内存引擎一起使用时，必须考虑要主动搜索的分片图形大小，并相应地配置 UltraWarm实例，最好是实例类型的实例。uw.large例如，如果客户配置了 2 个uw.large实例，则每个实例将有大约 knn.memory.circuit_breaker.limit * 61 GiB 的可用堆外内存。如果您的所有热查询都针对累积图形大小不超过可用堆外内存的分片，则可以获得最佳性能。如果由于驱逐和等待堆外内存可用而导致可用内存低于加载图表所需的内存，则延迟会受到影响。这就是为什么我们不建议将uw.medium实例用于使用内存引擎的用例或更高的搜索吞吐量案例，无论引擎如何。

  • 迁移到的 KNN 索引 UltraWarm 不会被强制合并到单个片段。这样可以避免对出现 OOM 问题的热节点和温节点产生任何影响，因为图形大小对于内存引擎来说变得太大。由于每个分片的分段数量增加，这可能会导致消耗更多的本地缓存空间并允许更少的索引迁移到温层。您可以选择使用现有设置将索引强制合并到单个段，然后在将索引迁移到热层之前将其覆盖。有关更多信息，请参阅 迁移调整。

  • 如果您的用例很少搜索索引，并且不处理延迟敏感的工作负载，则可以选择将这些索引迁移到该 UltraWarm 层。这将帮助您缩小热层计算实例的规模，让 UltraWarm 分层计算处理对此类低优先级索引的查询。这还有助于隔离低优先级和高优先级索引的查询之间消耗的资源，这样它们就不会相互影响。

禁用 UltraWarm

控制台是禁用的最简单方法 UltraWarm。选择域、Actions（操作）和 Edit cluster configuration（编辑集群配置）。取消选择 “启用热数据节点”，然后选择 “保存更改”。还可以在 Amazon CLI 和配置 API 中使用 WarmEnabled 选项。

在禁用之前 UltraWarm，必须删除所有温索引或将其迁移回热存储。暖存储空间为空后，请等待五分钟，然后尝试禁用 UltraWarm。