Archiviazione a freddo per Amazon OpenSearch Service - Amazon OpenSearch Service

Archiviazione a freddo per Amazon OpenSearch Service

L'archiviazione a freddo consente di archiviare qualsiasi quantità di dati della cronologia o a cui si accede raramente nel dominio Amazon OpenSearch Service e di analizzarli on demand, a un costo inferiore rispetto ad altri livelli di archiviazione. L'archiviazione a freddo è adatta se si ha bisogno di effettuare ricerche periodiche o analisi forensi sui dati più vecchi. Esempi pratici di dati adatti per l'archiviazione a freddo includono i log a cui si accede raramente, i dati che devono essere conservati per soddisfare i requisiti di conformità o i log che hanno un valore storico.

Simile all'archiviazione UltraWarm, l'archiviazione a freddo è supportata da Amazon S3. Quando è necessario eseguire query sui dati a freddo, è possibile collegarli in modo selettivo ai nodi UltraWarm esistenti. È possibile gestire la migrazione e il ciclo di vita dei dati a freddo manualmente o con le policy di Index State Management.

Prerequisiti

L'archiviazione a freddo ha i seguenti prerequisiti:

  • L'archiviazione a freddo richiede OpenSearch o Elasticsearch versione 7.9 o successiva.

  • Per abilitare l'archiviazione a freddo in un dominio OpenSearch Service, è necessario abilitare nello stesso dominio anche UltraWarm.

  • Per utilizzare l'archiviazione a freddo, i domini devono disporre di nodi principali dedicati.

  • Se il dominio utilizza un tipo di istanza T2 o T3 per i nodi di dati, non è possibile utilizzare l'archiviazione a freddo.

  • Se il tuo indice utilizza un k-NN approssimato ("index.knn": true), non puoi spostarlo in un’archiviazione offline sicura.

  • Se il dominio utilizza il controllo granulare degli accessi, gli utenti senza privilegi di amministratore devono essere mappati al ruolo cold_manager in OpenSearch Dashboards in modo da gestire gli indici a freddo.

Nota

Il ruolo cold_manager potrebbe non esistere in alcuni domini OpenSearch Service preesistenti. Se il ruolo non è visualizzato in Dashboards, è necessario crearlo manualmente.

Configurazione delle autorizzazioni

Se si abilita l'archiviazione a freddo in un dominio OpenSearch Service preesistente, il ruolo cold_manager potrebbe non essere definito nel dominio. Se il dominio utilizza il controllo granulare degli accessi, gli utenti senza privilegi di amministratore devono essere mappati a questo ruolo in modo da gestire gli indici a freddo. Per creare manualmente il ruolo cold_manager, procedere nel seguente modo:

  1. In OpenSearch Dashboards, passare a Sicurezza e scegliere Autorizzazioni.

  2. Scegliere Crea gruppo di operazioni e configurare i seguenti gruppi:

    Group name (Nome gruppo) Autorizzazioni
    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. Scegliere Ruoli, quindi selezionare Crea ruolo.

  4. Denominare il ruolo cold_manager.

  5. Per Autorizzazioni cluster, scegliere il gruppo cold_cluster creato.

  6. Per Indice, immettere *.

  7. Per Autorizzazioni indice, scegliere il gruppo cold_index creato.

  8. Scegliere Create (Crea) .

  9. Dopo aver creato il ruolo, mapparlo a qualsiasi utente o ruolo di back-end che gestisce gli indici a freddo.

Requisiti di archiviazione a freddo e considerazioni sulle prestazioni

Poiché l'archiviazione a freddo utilizza Amazon S3, non comporta alcun sovraccarico di archiviazione hot, come le repliche, lo spazio riservato Linux e lo spazio riservato OpenSearch Service. L'archiviazione a freddo non ha tipi di istanza specifici perché non ha alcuna capacità di calcolo collegata. Con l'archiviazione a freddo è possibile archiviare qualsiasi quantità di dati. Monitorare il parametro ColdStorageSpaceUtilization in Amazon CloudWatch per vedere quanto spazio di archiviazione a freddo si sta utilizzando.

Prezzi dell'archiviazione a freddo

Simile all'archiviazione UltraWarm, con l'archiviazione a freddo si paga solo per l'archiviazione dei dati. Non è previsto alcun costo di calcolo per i dati a freddo e non verrà addebitato nulla se nello spazio di archiviazione a freddo non ci sono dati.

Non si applicano spese di trasferimento quando si spostano i dati tra l'archiviazione a freddo e quella a caldo. Mentre gli indici vengono migrati tra l'archiviazione a caldo e quella a freddo, si continua a pagare solo una copia dell'indice. Al termine della migrazione, l'indice viene fatturato in base al livello di archiviazione in cui è stata eseguita la migrazione. Per ulteriori informazioni sui prezzi relativi all'archiviazione a freddo, consulta Prezzi di Amazon OpenSearch Service.

Abilitazione dell'archiviazione a freddo

La console è il modo più semplice per creare un dominio che utilizza l'archiviazione a freddo. Durante la creazione del dominio, scegliere Abilita archiviazione a freddo. Lo stesso processo di base funziona sui domini esistenti, a condizione che soddisfino i prerequisiti. Anche dopo che lo stato del dominio cambia da Elaborazione a Attivo, l'archiviazione a freddo potrebbe non essere disponibile per diverse ore.

Per abilitare l'archiviazione a freddo è possibile utilizzare anche la AWS CLI o l'API di configurazione.

Comando CLI di esempio

Il seguente comando AWS CLI crea un dominio con tre nodi di dati, tre nodi principali dedicati, l'archiviazione a freddo abilitata e il controllo granulare degli accessi abilitato:

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

Per ulteriori informazioni, consultare Riferimento ai comandi AWS CLI.

Richiesta dell'API di configurazione di esempio

La seguente richiesta all'API di configurazione crea un dominio con tre nodi di dati, tre nodi principali dedicati, l'archiviazione a freddo abilitata e il controllo granulare degli accessi abilitato:

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" }

Per informazioni dettagliate, consulta Riferimento dell'API di configurazione per Amazon OpenSearch Service.

Gestione degli indici a freddo in OpenSearch Dashboards

È possibile gestire gli indici hot, a caldo e a freddo con l'interfaccia Dashboards esistente nel dominio OpenSearch Service. Dashboards consente di eseguire la migrazione degli indici tra l'archiviazione a caldo e quella a freddo e di monitorare lo stato della migrazione degli indici, senza utilizzare la CLI o l'API di configurazione. Per ulteriori informazioni, consulta Gestione degli indici in OpenSearch Dashboards.

Migrazione degli indici all'archiviazione a freddo

Quando si esegue la migrazione degli indici all'archiviazione a freddo, si fornisce un intervallo di tempo per i dati per semplificare l'individuazione. È possibile selezionare un campo timestamp in base ai dati dell'indice, fornire manualmente un timestamp di inizio e di fine oppure scegliere di non specificarne uno.

Parametro Valore supportato Descrizione
timestamp_field Il campo data/ora dalla mappatura dell'indice.

I valori minimo e massimo del campo forniti vengono calcolati e archiviati come metadati start_time e end_time per l'indice a freddo.

start_time e end_time

Uno dei seguenti formati:

  • strict_date_optional_time. Ad esempio: yyyy-MM-dd'T'HH:mm:ss.SSSZ o yyyy-MM-dd

  • L'ora Epoch espressa in millisecondi

I valori forniti vengono calcolati e archiviati come metadati start_time e end_time per l'indice a freddo.

Se non si intendi specificare un timestamp, aggiungere ?ignore=timestamp alla richiesta.

La richiesta seguente esegue la migrazione di un indice a caldo all'archiviazione a freddo e fornisce ora di inizio e fine per i dati in tale indice:

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

Quindi controlla lo stato della migrazione:

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

OpenSearch Service esegue la migrazione di un indice alla volta in un’archiviazione offline sicura. È possibile disporre di un massimo di 100 migrazioni nella coda. Qualsiasi richiesta che supera il limite verrà rifiutata. Per controllare il numero corrente di migrazioni nella coda, monitorare il parametro WarmToColdMigrationQueueSize. Il processo di migrazione ha i seguenti stati:

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.

Automatizzazione delle migrazioni all'archiviazione a freddo

Si consiglia di utilizzare Index State Management per automatizzare il processo di migrazione dopo che un indice raggiunge una certa età o soddisfa altre condizioni. Consulta la policy di esempio, che illustra come eseguire automaticamente la migrazione degli indici dall'archiviazione hot a UltraWarm a freddo.

Nota

Un timestamp_field esplicito è necessario per spostare gli indici nell'archiviazione a freddo utilizzando una policy di Index State Management.

Annullamento delle migrazioni all'archiviazione a freddo

Se una migrazione all'archiviazione a freddo è in coda o in uno stato di errore, è possibile annullare la migrazione utilizzando la seguente richiesta:

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

Se il dominio utilizza il controllo granulare degli accessi, per effettuare questa richiesta è necessaria l'autorizzazione indices:admin/ultrawarm/migration/cancel.

Elenco degli indici a freddo

Prima di eseguire una query, è possibile elencare gli indici nell'archiviazione a freddo in modo da decidere quali migrare a UltraWarm per ulteriori analisi. La richiesta seguente elenca tutti gli indici a freddo, ordinati per nome indice:

GET _cold/indices/_search

Risposta di esempio

{ "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" } ] }

Filtraggio

È possibile filtrare gli indici a freddo in base a un modello di indice basato su prefisso e a offset di intervallo di tempo.

La seguente richiesta elenca gli indici che corrispondono al modello di prefisso di event-*:

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

Risposta di esempio

{ "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" } ] }

La seguente richiesta restituisce indici con campi di metadati start_time e end_time tra 2019-03-01 e 2020-03-01:

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

Risposta di esempio

{ "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" } ] }

Ordinamento

È possibile ordinare gli indici a freddo in base ai campi di metadati, ad esempio il nome dell'indice o la dimensione. La richiesta seguente elenca tutti gli indici ordinati per dimensione in ordine decrescente:

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

Risposta di esempio

{ "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" } ] }

Altre chiavi di ordinamento valide sono start_time:asc/desc, end_time:asc/desc e index_name:asc/desc.

Paginazione

È possibile impaginare una lista di indici a freddo. Configurare il numero di indici da restituire per pagina con il parametro page_size (il valore di default è 10). Ogni richiesta _search sugli indici a freddo restituisce un pagination_id che è possibile utilizzare per le chiamate successive.

La seguente richiesta impagina i risultati di una richiesta _search degli indici a freddo e visualizza i successivi 100 risultati:

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

Migrazione degli indici a freddo all'archiviazione a caldo

Dopo aver ristretto l'elenco degli indici a freddo con i criteri di filtro nella sezione precedente, eseguirne la migrazione a UltraWarm, dove è possibile eseguire query sui dati e utilizzarli per creare visualizzazioni.

La richiesta seguente esegue la migrazione di due indici a freddo all'archiviazione a caldo:

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

Per verificare lo stato della migrazione e recuperare l'ID di migrazione, inviare la seguente richiesta:

GET _cold/migration/_status

Risposta di esempio

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

Per ottenere informazioni sulla migrazione specifiche dell'indice, includere il nome dell'indice:

GET _cold/migration/my-index/_status

Anziché specificare un indice, è possibile elencare gli indici in base al relativo stato di migrazione corrente. I valori validi sono _failed, _accepted e _all.

Il comando seguente ottiene lo stato di tutti gli indici in una singola richiesta di migrazione:

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

Recuperare l'ID di migrazione utilizzando la richiesta di stato. Per informazioni dettagliate sulla migrazione, aggiungere &verbose=true.

È possibile migrare gli indici dall'archiviazione a freddo a quella a caldo in batch da 10 o meno, con un massimo di 100 indici simultanei. Qualsiasi richiesta che supera il limite verrà rifiutata. Per controllare il numero di migrazioni in atto, monitora il parametro ColdToWarmMigrationQueueSize. Il processo di migrazione ha i seguenti stati:

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.

Ripristino di indici a freddo da snapshot

Contattare AWS Support se è necessario ripristinare gli indici a freddo da uno snapshot automatico, anche in situazioni in cui un intero dominio è stato eliminato accidentalmente. OpenSearch Service conserva gli indici a freddo per 14 giorni dopo che sono stati eliminati.

Annullamento delle migrazioni dall'archiviazione a freddo a quella a caldo

Se una migrazione dell'indice dall'archiviazione a freddo a quella a caldo è in coda o in uno stato di errore, è possibile annullare la migrazione utilizzando la seguente richiesta:

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

Per annullare la migrazione per un batch di indici (massimo 10 alla volta), specificare l'ID di migrazione:

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

Recuperare l'ID di migrazione utilizzando la richiesta di stato.

Aggiornamento dei metadati dell'indice a freddo

È possibile aggiornare i campi start_time e end_time per un indice a freddo:

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

Non è possibile aggiornare il timestamp_field di un indice nell'archiviazione a freddo.

Nota

OpenSearch Dashboards non supporta il metodo PATCH. Per aggiornare i metadati a freddo, utilizzare curl, Postman o qualche altro metodo.

Eliminazione degli indici a freddo

Se non si utilizza una policy ISM, è possibile eliminare manualmente gli indici a freddo. La seguente richiesta elimina un indice a freddo:

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

Disabilitazione dell'archiviazione a freddo

La console di OpenSearch Service è il modo più semplice per disabilitare l'archiviazione a freddo. Seleziona il dominio e scegli Operazioni, Modifica configurazione cluster, quindi deseleziona Abilita archiviazione a freddo.

Per utilizzare AWS CLI o l'API di configurazione, inColdStorageOptions, impostare "Enabled"="false".

Prima di disabilitare l'archiviazione a freddo, è necessario eliminare tutti gli indici a freddo o migrarli nuovamente all'archiviazione a caldo, altrimenti l'operazione di disabilitazione non riuscirà.