Amazon OpenSearch 服務的冷存儲 - Amazon OpenSearch Service

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

Amazon OpenSearch 服務的冷存儲

冷存儲可讓您在 Amazon Ser OpenSearch vice 網域上存放任何數量的不常存取或歷史資料,並以比其他儲存層更低的成本按需進行分析。如果您需要對舊資料進行定期研究或鑑識分析,則冷儲存適合。適合冷儲存的實際資料範例包括不常存取的日誌、必須保留以滿足合規要求的資料,或是具有歷史價值的日誌。

UltraWarm儲存類似,冷儲存也由 Amazon S3 提供支援。當您需要查詢冷資料時,可以選擇性地將其貼附至既有 UltraWarm節點。您可以手動或使用索引狀態管理政策來管理冷資料的遷移和生命週期。

必要條件

冷儲存具有以下先決條件:

  • 冷庫需要 OpenSearch 或彈性搜索 7.9 版或更高版本。

  • 若要在 OpenSearch 服務網域上啟用冷儲存,您也必須在相同網域 UltraWarm 上啟用。

  • 若要使用冷儲存,網域必須具有專用的主節點

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

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

  • 如果網域使用精細的存取控制,則非管理員使用者必須對應至 OpenSearch 儀表板中的cold_manager角色,才能管理冷索引。

注意

cold_manager角色可能不存在於某些預先存在的 OpenSearch 服務網域中。如果在 Dashboards 中沒有看到該角色,您需要手動建立它

設定許可

如果您在預先存在的 OpenSearch 服務網域上啟用冷儲存,則該cold_manager角色可能不會在網域上定義。如果網域使用精細的存取控制,則必須將非管理員使用者對應至此角色,才能管理冷索引。若要手動建立 cold_manager 角色,請執行以下步驟:

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

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

    Group name (群組名稱) 許可
    cold_cluster
    • cluster:monitor/nodes/stats

    • cluster:admin/ultrawarm*

    • cluster:admin/cold/*

    cold_index
    • indices:monitor/stats

    • indices:data/read/minmax

    • indices:admin/ultrawarm/migration/get

    • indices:admin/ultrawarm/migration/cancel

  3. 選擇 Roles (角色),然後選擇 Create role (建立角色)。

  4. 將角色命名為 cold_manager

  5. 對於 Cluster permissions (叢集許可),選擇您建立的 cold_cluster 群組。

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

  7. 對於 Index permissions (索引許可),選擇您建立的 cold_index 群組。

  8. 選擇建立

  9. 建立角色之後,請將其對應至管理冷索引的任何使用者或後端角色。

冷儲存要求和效能考量

由於冷儲存使用 Amazon S3,因此不會產生熱儲存的額外負荷,例如複本、Linux 保留空間和 OpenSearch 服務保留空間。冷儲存沒有特定執行個體類型,因為它沒有連接任何運算容量。您可以在冷儲存中儲存任意數量的資料。在 Amazon 中監控ColdStorageSpaceUtilization指標, CloudWatch 以查看您正在使用多少冷儲存空間。

冷儲存定價

與 UltraWarm 存儲類似,使用冷存儲,您只需支付數據存儲費用。冷資料沒有運算成本,如果冷儲存中沒有資料,您將無需支付費用。

在冷儲存和暖儲存之間移動資料時,不會產生任何傳輸費用。雖然正在暖儲存和冷儲存之間遷移索引,但您仍然只需支付一份索引副本的費用。遷移完成後,會根據索引遷移到的儲存層計費。如需冷儲存定價的詳細資訊,請參閱 Amazon OpenSearch 服務定價

啟用冷儲存

主控台是建立使用冷儲存之網域的最簡單方法。建立網域時,選擇 Enable cold storage (啟用冷儲存)。只要滿足先決條件,相同程序也適用於現有網域。即使網域狀態從 Processing (正在處理) 變更為 Active (作用中),冷儲存可能會長達數小時無法使用。

您也可以使用 AWS CLI組態 API 來啟用冷儲存。

CLI 命令範例

下列 AWS CLI 指令會建立具有三個資料節點、三個專用主節點、已啟用冷儲存並啟用精細存取控制的網域:

aws opensearch create-domain \ --domain-name my-domain \ --engine-version Opensearch_1.0 \ --cluster-config ColdStorageOptions={Enabled=true},WarmEnabled=true,WarmCount=4,WarmType=ultrawarm1.medium.search,InstanceType=r6g.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=r6g.large.search,DedicatedMasterCount=3,InstanceCount=3 \ --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}' \ --region us-east-2

如需詳細資訊,請參閱 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": 4, "WarmType": "ultrawarm1.medium.search", "ColdStorageOptions": { "Enabled": true } }, "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" }

如需詳細資訊,請參閱 Amazon OpenSearch 服務 API 參考

管理 OpenSearch 儀表板中的冷索引

您可以使用 OpenSearch Service 網域中現有的儀表板介面來管理熱索引、溫索引和冷索引。Dashboards 可讓您在暖儲存和冷儲存之間遷移索引並監控索引遷移狀態,而不需要使用 CLI 或組態 API。如需詳細資訊,請參閱管理 OpenSearch 儀表板中的索引

將索引遷移至冷儲存

當您將索引遷移至冷儲存時,會為資料提供一個時間範圍,以便更輕鬆地探索。您可以根據索引中的資料選取時間戳記欄位,手動提供開始和結束時間戳記,或選擇不指定時間戳記。

參數 支援的值 描述
timestamp_field 來自索引映射的日期/時間欄位。

會運算提供的欄位的最小值和最大值並存儲為冷索引的 start_timeend_time 中繼資料。

start_timeend_time

下列其中一個格式:

  • strict_date_optional_time。例如:yyyy-MM-dd'T'HH:mm:ss.SSSZyyyy-MM-dd

  • Epoch 時間 (以毫秒為單位)

提供的值存儲為冷索引的 start_timeend_time 中繼資料。

如果您不希望指定時間戳記,請將 ?ignore=timestamp 新增到請求。

下列請求會將暖索引遷移至冷儲存,並提供在該索引中資料的開始和結束時間:

POST _ultrawarm/migration/my-index/_cold { "start_time": "2020-03-09", "end_time": "2020-03-09T23:00:00Z" }

接著,檢查遷移狀態:

GET _ultrawarm/migration/my-index/_status { "migration_status": { "index": "my-index", "state": "RUNNING_METADATA_RELOCATION", "migration_type": "WARM_TO_COLD" } }

OpenSearch 服務一次會將一個索引移轉至冷藏庫。您最多可以在佇列中進行 100 個遷移操作。任何超出限制的請求都會被拒絕。若要檢查佇列中的目前遷移數目,請監控 WarmToColdMigrationQueueSize 指標。遷移程序具有下列狀態:

ACCEPTED_COLD_MIGRATION - Migration request is accepted and queued. RUNNING_METADATA_MIGRATION - The migration request was selected for execution and metadata is migrating to cold storage. FAILED_METADATA_MIGRATION - The attempt to add index metadata has failed and all retries are exhausted. PENDING_INDEX_DETACH - Index metadata migration to cold storage is completed. Preparing to detach the warm index state from the local cluster. RUNNING_INDEX_DETACH - Local warm index state from the cluster is being removed. Upon success, the migration request will be completed. FAILED_INDEX_DETACH - The index detach process failed and all retries are exhausted.

自動移轉至冷儲存

在索引達到特定時間或滿足其他條件時,您可使用索引狀態管理自動化遷移程序。請參閱範例原則,其中示範如何自動將索引從熱儲存移轉 UltraWarm 到冷存放區。

注意

需要明確定義 timestamp_field,才能使用索引狀態管理政策將索引移至冷儲存。

取消遷移至冷儲存

如果遷移至冷儲存已排入佇列或處於失敗狀態,您可以使用下列請求取消遷移:

POST _ultrawarm/migration/_cancel/my-index { "acknowledged" : true }

如果您的網域使用精細存取控制,您需要 indices:admin/ultrawarm/migration/cancel 許可來提出此請求。

列出冷索引

在查詢之前,您可以列出冷存儲中的索引,以決定要移轉到哪些索引以 UltraWarm 進一步分析。下列要求會列出所有冷索引,並依索引名稱排序:

GET _cold/indices/_search

回應範例

{ "pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY", "total_results" : 3, "indices" : [ { "index" : "my-index-1", "index_cold_uuid" : "hjEoh26mRRCFxRIMdgvLmg", "size" : 10339, "creation_date" : "2021-06-28T20:23:31.206Z", "start_time" : "2020-03-09T00:00Z", "end_time" : "2020-03-09T23:00Z" }, { "index" : "my-index-2", "index_cold_uuid" : "0vIS2n-oROmOWDFmwFIgdw", "size" : 6068, "creation_date" : "2021-07-15T19:41:18.046Z", "start_time" : "2020-03-09T00:00Z", "end_time" : "2020-03-09T23:00Z" }, { "index" : "my-index-3", "index_cold_uuid" : "EaeXOBodTLiDYcivKsXVLQ", "size" : 32403, "creation_date" : "2021-07-08T00:12:01.523Z", "start_time" : "2020-03-09T00:00Z", "end_time" : "2020-03-09T23:00Z" } ] }

篩選

您可以根據以字首為基礎的索引模式和時間範圍偏移來篩選冷索引。

以下請求列出了與 event-* 的字首模式匹配的索引:

GET _cold/indices/_search { "filters":{ "index_pattern": "event-*" } }

回應範例

{ "pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY", "total_results" : 1, "indices" : [ { "index" : "events-index", "index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA", "size" : 32263273, "creation_date" : "2021-08-18T18:25:31.845Z", "start_time" : "2020-03-09T00:00Z", "end_time" : "2020-03-09T23:00Z" } ] }

以下請求傳回的索引具有介於 2019-03-012020-03-01 之間的 start_timeend_time 中繼資料欄位:

GET _cold/indices/_search { "filters": { "time_range": { "start_time": "2019-03-01", "end_time": "2020-03-01" } } }

回應範例

{ "pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY", "total_results" : 1, "indices" : [ { "index" : "my-index", "index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA", "size" : 32263273, "creation_date" : "2021-08-18T18:25:31.845Z", "start_time" : "2019-05-09T00:00Z", "end_time" : "2019-09-09T23:00Z" } ] }

排序

您可以按照中繼資料欄位 (例如索引名稱或大小) 來排序冷索引。以下請求列出按照大小排序 (降序) 的所有索引:

GET _cold/indices/_search { "sort_key": "size:desc" }

回應範例

{ "pagination_id" : "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY", "total_results" : 5, "indices" : [ { "index" : "my-index-6", "index_cold_uuid" : "4eFiab7rRfSvp3slrIsIKA", "size" : 32263273, "creation_date" : "2021-08-18T18:25:31.845Z", "start_time" : "2020-03-09T00:00Z", "end_time" : "2020-03-09T23:00Z" }, { "index" : "my-index-9", "index_cold_uuid" : "mbD3ZRVDRI6ONqgEOsJyUA", "size" : 57922, "creation_date" : "2021-07-07T23:41:35.640Z", "start_time" : "2020-03-09T00:00Z", "end_time" : "2020-03-09T23:00Z" }, { "index" : "my-index-5", "index_cold_uuid" : "EaeXOBodTLiDYcivKsXVLQ", "size" : 32403, "creation_date" : "2021-07-08T00:12:01.523Z", "start_time" : "2020-03-09T00:00Z", "end_time" : "2020-03-09T23:00Z" } ] }

其他有效的排序金鑰為 start_time:asc/descend_time:asc/descindex_name:asc/desc

分頁

您可以分頁冷索引清單。使用 page_size 參數來設定每頁要傳回的索引數目 (預設值為 10)。針對冷索引的每個 _search 請求傳回一個 pagination_id,您可以將其用於後續呼叫。

以下請求會對冷索引的 _search 請求結果進行分頁,並顯示接下來的 100 個結果:

GET _cold/indices/_search?page_size=100 { "pagination_id": "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY" }

將冷索引遷移至暖儲存

使用上一節中的篩選準則縮小冷索引清單之後,請將它們移轉回您可以查詢資料的 UltraWarm 位置,並使用它來建立視覺效果。

以下請求會將兩個冷索引遷移回暖儲存:

POST _cold/migration/_warm { "indices": "my-index1,my-index2" } { "acknowledged" : true }

若要檢查遷移狀態並擷取遷移 ID,請傳送下列請求:

GET _cold/migration/_status

回應範例

{ "cold_to_warm_migration_status" : [ { "migration_id" : "tyLjXCA-S76zPQbPVHkOKA", "indices" : [ "my-index1,my-index2" ], "state" : "RUNNING_INDEX_CREATION" } ] }

若要取得索引特定的遷移資訊,請包含索引名稱:

GET _cold/migration/my-index/_status

您可以按照當前遷移狀態列出索引,而不是指定索引。有效值為 _failed_accepted_all

以下命令會取得單一遷移請求中所有索引的狀態:

GET _cold/migration/_status?migration_id=my-migration-id

使用狀態請求擷取遷移 ID。如需詳細的遷移資訊,請新增 &verbose=true

您可以分 10 個或更少批次,將索引從冷儲存遷移到暖儲存,最多可同時遷移 100 個索引。任何超出限制的請求都會被拒絕。若要檢查佇列中的目前遷移數目,請監控 ColdToWarmMigrationQueueSize 指標。遷移程序具有下列狀態:

ACCEPTED_MIGRATION_REQUEST - Migration request is accepted and queued. RUNNING_INDEX_CREATION - Migration request is picked up for processing and will create warm indexes in the cluster. PENDING_COLD_METADATA_CLEANUP - Warm index is created and the migration service will attempt to clean up cold metadata. RUNNING_COLD_METADATA_CLEANUP - Cleaning up cold metadata from the indexes migrated to warm storage. FAILED_COLD_METADATA_CLEANUP - Failed to clean up metadata in the cold tier. FAILED_INDEX_CREATION - Failed to create an index in the warm tier.

從快照中還原冷索引

如果您需要還原已刪除的冷索引,可以依照中的指示將其還原回暖層,從快照還原暖索引然後再次將索引移轉回冷層。您無法將已刪除的冷索引直接還原回冷層。 OpenSearch 服務會在刪除後保留冷索引 14 天。

取消從冷儲存遷移至暖儲存

如果從冷儲存到暖儲存的索引遷移已排入佇列或處於失敗狀態,您可以使用以下請求取消它:

POST _cold/migration/my-index/_cancel { "acknowledged" : true }

若要取消批次索引的遷移 (一次最多 10 個),請指定遷移 ID:

POST _cold/migration/_cancel?migration_id=my-migration-id { "acknowledged" : true }

使用狀態請求擷取遷移 ID。

更新冷索引中繼資料

您可以更新冷索引的 start_timeend_time 欄位:

PATCH _cold/my-index { "start_time": "2020-01-01", "end_time": "2020-02-01" }

您無法更新冷儲存中的索引的 timestamp_field

注意

OpenSearch 儀表板不支援 PATCH 方法。使用 curlPostman 或其他方法來更新冷中繼資料。

刪除冷索引

如果您未使用 ISM 政策,您可以手動刪除冷索引。以下要求會刪除冷索引:

DELETE _cold/my-index { "acknowledged" : true }

停用冷儲存

OpenSearch 服務主控台是停用冷儲存的最簡單方法。選取網域並選擇 Actions (動作)、Edit cluster configuration (編輯叢集組態),然後取消選取 Enable cold storage (啟用冷儲存)。

若要使用 AWS CLI 或組態 API,請在下ColdStorageOptions設定"Enabled"="false"

停用冷儲存之前,您必須刪除所有冷索引,或將它們遷移回暖儲存,否則停用動作會失敗。