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 OpenSearch 服务上存储大量只读数据提供了一种经济实惠的方式。标准数据节点使用 “热” 存储，其形式是实例存储或连接到每个节点的 Amazon EBS 卷。热存储为编制索引和搜索新数据提供尽可能快的性能。

UltraWarm 节点不使用附加存储，而是使用 Amazon S3 和复杂的缓存解决方案来提高性能。对于不主动写入、查询频率较低且不需要相同性能的索引， UltraWarm 可以显著降低每 GiB 数据的成本。因为除非将温索引返回到热存储，否则它们 UltraWarm 是只读的，因此最适合存储不可变的数据，例如日志。

在中 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电话。

注意

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

配置权限

如果您在先前存在的 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。通过RAM分配给每种 UltraWarm 实例类型的CPU内核数量和数量，您可以了解它们可以同时搜索的分片数量。请注意，虽然在 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 节点支付小时费率。有关更多信息，请参阅 亚马逊 OpenSearch 服务的定价。

正在启用 UltraWarm

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

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

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

注意

域支持最大数量的温节点。有关详细信息，请参阅亚马逊 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 存储

如果您完成了对索引的写入并且不再需要尽可能快的搜索性能，请将其从 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
    }
  }
}

索引运行状况必须为绿色才能执行迁移。如果您快速连续迁移多个索引，则可以以纯文本形式获得所有迁移的摘要，类似于：_catAPI

GET _ultrawarm/migration/_status?v

index    migration_type state
my-index HOT_TO_WARM    RUNNING_SHARD_RELOCATION

OpenSearch 服务一次将一个索引迁移到。 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 OpenSearch Service 中的索引状态管理 自动执行迁移过程。请参阅演示该工作流程的示例策略。

迁移调整

索引迁移到 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 服务按排队顺序逐一处理迁移请求。要查看当前数量，请监控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（编辑集群配置）。取消选择 “启用 UltraWarm 数据节点”，然后选择 “保存更改”。您也可以使用 Amazon CLI 和配置中的WarmEnabled选项API。

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