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

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

UltraWarm Amazon 服 OpenSearch 務存儲

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

UltraWarm 節點不使用附加儲存，而是使用 Amazon S3 和精密的快取解決方案來提高效能。對於您未主動寫入、查詢頻率較低且不需要相同效能的索引， UltraWarm 可大幅降低每 GiB 資料的成本。因為暖索引是唯讀的，除非您將它們返回到熱存儲，因 UltraWarm 此最適合不可變數據，例如日誌。

在中 OpenSearch，暖索引的行為就像任何其他索引一樣。您可以使用相同的 API 查詢它們，也可以使用它們在 OpenSearch 儀表板中建立視覺效果。

必要條件

UltraWarm 有一些重要的先決條件：

  • UltraWarm 需要 OpenSearch 或彈性搜索 6.8 或更高版本。

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

  • 將異地同步備份與待命網域搭配使用時，暖節點數目必須是正在使用的可用區域數目的倍數。

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

  • 如果您的索引使用 近似 k-NN ("index.knn": true)，則您無法將其移動至暖儲存。

  • 如果網域使用精細的存取控制，則必須將使用者對應至 OpenSearch 儀表板中的ultrawarm_manager角色，才能進行 UltraWarm API 呼叫。

注意

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

設定許可

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

  1. 在 OpenSearch 儀表板中，轉到安全性，然後選擇權限。

  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. 選擇建立。

  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。CPU 核心數量和配置給每個 UltraWarm 執行個體類型的 RAM 數量可讓您瞭解它們可以同時搜尋的碎片數量。請注意，雖然只有主要碎片計入 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 OpenSearch 服務的定價。

啟用 UltraWarm

主控台是建立使用暖儲存之網域最簡單的方法。建立網域時，選擇 [啟用 UltraWarm 資料節點] 和您想要的暖節點數目。同樣的基本程序適用於現有的網域，只要它們符合 先決條件即可。即使網域狀態從 [處理] 變更為 [作用中]，也 UltraWarm 可能在數小時內無法使用。

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

您也可以使用AWS CLI或設定 API 來啟用 UltraWarm，特別是中的WarmEnabledWarmCount、和WarmType選項ClusterConfig。

注意

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

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 服務 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 服務一次會將一個索引移轉至 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 服務中的索引狀態管理 自動化移轉程序。請參閱示範此工作流程的範例政策。

遷移調整

將索引移轉至 UltraWarm 儲存區需要強制合併。每個 OpenSearch 索引由一定數量的碎片組成，並且每個分片由一定數量的 Lucene 段組成。強制合併操作會清除標示為刪除的文件，並節省磁碟空間。默認情況下，將索引 UltraWarm 合併為一個段。

您可以使用 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 服務不會在手動快照中包含暖索引。例如，以下呼叫只包含熱索引：

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 的資料，請考慮將其移轉至冷存放區。冷儲存適合您偶爾才存取的資料，或不再為使用中狀態的資料。您無法讀取或寫入冷索引，但無論何時需要查詢，都可以免費將它們遷移回暖儲存。如需說明，請參閱將索引遷移至冷儲存。

禁用 UltraWarm

控制台是最簡單的禁用方法 UltraWarm。選擇網域、Actions (動作) 和 Edit cluster configuration (編輯叢集組態)。取消選取啟用 UltraWarm 資料節點並選擇儲存變更。您也可以使用 AWS CLI 和配置 API 中的 WarmEnabled 選項。

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