Amazon OpenSearch Service 的 UltraWarm 儲存 - Amazon OpenSearch Service
先決條件UltraWarm 儲存要求和效能考量UltraWarm 定價啟用 UltraWarm將索引遷移到 UltraWarm 儲存自動化遷移遷移調整取消遷移列出熱索引和暖索引將暖索引傳回熱儲存區從快照還原暖索引暖索引的手動快照將暖索引遷移到冷儲存KNN 索引的最佳實務停用 UltraWarm

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Amazon OpenSearch Service 的 UltraWarm 儲存

UltraWarm 提供經濟有效的方法，可在 Amazon OpenSearch Service 上儲存大量唯讀資料。標準資料節點使用「熱」儲存，它採用將執行個體存放區或 Amazon EBS 磁碟區連接到各個節點的形式。熱儲存可盡可能提供最快速的效能，以編製索引和搜尋新資料。

UltraWarm 節點使用 Simple Storage Service (Amazon S3) 和精密的快取解決方案來改善效能，而不是使用連接的儲存空間。對於您未積極寫入、較不常查詢且不需要相同效能的索引，UltraWarm 大幅降低了每 GiB 資料的成本。由於暖索引為唯讀狀態 (除非您將它們還原到熱儲存)，因此 UltraWarm 最適合不可變資料，例如日誌。

在 OpenSearch 中，這些暖索引的運作方式就像任何其他索引一樣。您可以使用相同的 API 來查詢索引，或使用索引在 OpenSearch Dashboards 中建立視覺效果。

先決條件

UltraWarm 有幾個重要的先決條件：

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

  • 若要使用暖儲存區，網域必須具有專用的主節點。

  • 將多可用區域與待命網域搭配使用時，暖節點的數量必須是正在使用的可用區域的倍數。

  • 如果您的網域將 T2 或 T3 執行個體類型用於資料節點，您則無法使用暖儲存。

  • 如果您的索引使用大約 k-NN ("index.knn":true)，您可以將其從 2.17 版和更新版本移至暖儲存。2.17 版之前的網域可以升級至 2.17 以使用此功能，但 2.x 版之前的 KNN 索引無法遷移至 UltraWarm。

  • 如果網域使用精細存取控制，使用者必須在 OpenSearch Dashboards 中映射至 ultrawarm_manager 角色，以進行 UltraWarm API 呼叫。

注意

某些預先存在的 OpenSearch Service 網域上可能未定義 ultrawarm_manager 角色。如果在 Dashboards 中沒有看到該角色，您需要手動建立它。

設定許可

如果在預先存在的 OpenSearch Service 網域上啟用 UltraWarm，可能未在網域上定義 ultrawarm_manager 角色。非系統管理員使用者必須映射至此角色，以便在使用精細存取控制的網域上管理暖索引。若要手動建立 ultrawarm_manager 角色，請執行以下步驟：

  1. 在 OpenSearch Dashboards 中，移至 Security (安全性)，然後選擇 Permissions (許可)。

  2. 選擇 Create action group (建立動作群組) 並設定下列群組：

    Group name (群組名稱) 許可
    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. 選擇 Roles (角色)，然後選擇 Create role (建立角色)。

  4. 將角色命名為 ultrawarm_manager。

  5. 對於 Cluster permissions (叢集許可)，選取 ultrawarm_cluster 和 cluster_monitor。

  6. 對於 Index (索引)，輸入 *。

  7. 對於 Index permissions (索引許可)，選取 ultrawarm_index_read、ultrawarm_index_write 以及 indices_monitor。

  8. 選擇 Create (建立)。

  9. 建立角色後，將它映射到將管理 UltraWarm 索引的任何使用者或後端角色。

UltraWarm 儲存要求和效能考量

如 計算儲存需求 中所述，熱儲存中的資料會產生大量開銷：複本、Linux 保留空間和 OpenSearch Service 保留空間。例如，含有一個複本碎片的 20 GiB 的主要碎片大約需要 58 GiB 的熱儲存空間。

由於它使用 Simple Storage Service (Amazon S3)，UltraWarm 不會產生任何此類開銷。計算 UltraWarm 儲存需求時，您只需考慮主要碎片的大小。S3 中的資料耐久性不需要複本，且 S3 消除了任何作業系統或服務考量事項。相同的 20 GiB 碎片需要 20 GiB 的暖儲存。如果您佈建了 ultrawarm1.large.search 執行個體，您可將其所有 20 TiB 的儲存空間上限用於主要碎片。請參閱UltraWarm 儲存配額，了解執行個體類型摘要，以及每個類型可處理的儲存量上限。

針對 UltraWarm，仍建議使用 50 GiB 的最大碎片大小。CPU 核心數量和配置給每個 UltraWarm 執行個體類型的 RAM 數量可讓您了解它們可以同時搜尋的碎片數量。請注意，雖然只有主要分片會計入 S3 中的 UltraWarm 儲存空間，但 OpenSearch Dashboards 和 _cat/indices 仍會將 UltraWarm 索引大小報告為所有主碎片和複本碎片的總計。

例如，每個 ultrawarm1.medium.search 執行個體具有兩個 CPU 核心，並且可處理 S3 上最多 1.5 TiB 的儲存。其中兩個執行個體具有 3 TiB 的組合儲存，如果每個碎片為 50 GiB，則可達到大約 62 個碎片。如果對叢集的請求只搜索這些碎片中的四個，則效能可能會很好。如果請求範圍廣泛，並且搜尋所有 62 個碎片，則四個 CPU 核心可能很難執行操作。監控 WarmCPUUtilization 和 WarmJVMMemoryPressure UltraWarm 指標，以了解執行個體如何處理您的工作負載。

如果您的搜尋範圍廣泛或頻繁，請考慮將索引留在熱儲存中。如同任何其他 OpenSearch 工作負載一樣，判斷 UltraWarm 是否符合您需求的最重要步驟是使用實際的資料集執行代表性的用戶端測試。

UltraWarm 定價

使用熱儲存時，您需要按實際佈建內容付費。有些執行個體需要連接的 Amazon EBS 磁碟區，有些則包含執行個體存放區。無論該儲存空間是空的還是已滿，都是支付相同的價格。

使用 UltraWarm 儲存時，您需要按實際用量付費。一個 ultrawarm1.large.search 執行個體可在 S3 上處理高達 20 TiB 的儲存空間，但如果您只儲存 1 TiB 的資料，則只需支付 1 TiB 的資料費用。就像所有其他節點類型一樣，您也需要按照小時費率為每個 UltraWarm 節點支付費用。如需詳細資訊，請參閱Amazon OpenSearch Service 定價。

啟用 UltraWarm

主控台是建立使用暖儲存之網域最簡單的方法。建立網域時，請選擇 Enable UltraWarm data nodes (啟用 UltraWomber 資料節點) 以及您想要的暖節點數目。同樣的基本程序適用於現有的網域，只要它們符合 先決條件即可。即使網域狀態從 Processing (處理) 變更為 Active (作用中)，仍可能會長達數小時無法使用 UltraWarm。

將多可用區域與待命網域搭配使用時，暖節點的數量必須是正在使用的可用區域的倍數。如需詳細資訊，請參閱具有待命的異地同步備份。

您也可以使用 AWS CLI 或組態 API 來啟用 UltraWarm，具體而言就是 ClusterConfig 中的 WarmEnabled、WarmCount 和 WarmType 選項。

注意

網域支援暖節點數量上限。如需詳細資訊，請參閱 Amazon OpenSearch Service 配額。

CLI 命令範例

下列 AWS 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

如需詳細資訊，請參閱 AWS 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/*\"}]}"
}

如需詳細資訊，請參閱 Amazon OpenSearch Service 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 OpenSearch Service 中的索引狀態管理 自動化移轉程序。請參閱示範此工作流程的範例政策。

遷移調整

索引遷移至 UltraWarm 儲存需要強制合併。每個 OpenSearch 索引由一定數量的碎片組成，每個碎片都由一定數量的 Lucene 區段組成。強制合併操作會清除標示為刪除的文件，並節省磁碟空間。根據預設，UltraWarm 會將索引合併為一個區段，但 kNN 索引除外，其中使用預設值 20。

您可以使用 index.ultrawarm.migration.force_merge.max_num_segments 設定，將此值變更為最多 1,000 個區段。較高的值會加快遷移程序，但會在移轉完成後增加暖索引的查詢延遲。若要變更設定，請提出下列請求：

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 和 cs-automated-enc 儲存庫中的快照會還原為熱儲存。

將 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 儲存庫已包含每個暖索引的快照 (在遷移期間取得)，不需額外付費。

依預設，OpenSearch Service 不會在手動快照中包含暖索引。例如，以下呼叫只包含熱索引：

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執行個體用於使用記憶體內引擎的使用案例，或用於更高的搜尋輸送量案例。

  • 遷移至 UltraWarm 的 KNN 索引不會強制合併至單一區段。這樣可以避免對在 OOM 問題中執行的熱節點和暖節點造成任何影響，因為圖形大小對記憶體內引擎而言太大。由於每個碎片的區段數量增加，這可能會導致佔用更多本機快取空間，並允許較少索引遷移至暖層。您可以選擇使用現有設定將索引強制合併為單一區段，並在將索引遷移至暖層之前將其覆寫。如需詳細資訊，請參閱遷移調整。

  • 如果您有不常搜尋索引且未提供延遲敏感工作負載的使用案例，您可以選擇將這些索引遷移至 UltraWarm 層。這將協助您縮減熱層運算執行個體，並讓 UltraWarm 層運算處理如此低優先順序索引上的查詢。這也有助於隔離低優先順序和高優先順序索引查詢之間消耗的資源，以免它們互相影響。

停用 UltraWarm

透過主控台是停用 UltraWarm 的最簡單方法。選擇網域、Actions (動作) 和 Edit cluster configuration (編輯叢集組態)。取消選取 Enable UltraWarm data nodes (啟用 UltraWarm 資料節點)，然後選擇 Save changes (儲存變更)。您也可以使用 AWS CLI 和配置 API 中的 WarmEnabled 選項。

停用 UltraWarm 之前，您必須刪除所有暖索引，或將它們遷移回熱儲存區。暖儲存區變空後，請等待五分鐘，然後再嘗試停用 UltraWarm。