Conservazione a freddo per Amazon OpenSearch Service - OpenSearch Servizio Amazon

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Conservazione a freddo per Amazon OpenSearch Service

La conservazione a freddo ti consente di archiviare qualsiasi quantità di dati storici o ad accesso raro sul tuo dominio Amazon OpenSearch Service e di analizzarli su richiesta, a un costo inferiore rispetto ad altri livelli di storage. 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.

Analogamente allo UltraWarmstorage, lo storage a freddo è supportato da Amazon S3. Quando è necessario interrogare dati non aggiornati, è possibile collegarli in modo selettivo ai nodi esistenti UltraWarm. È 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:

  • La conservazione a freddo richiede Elasticsearch versione 7.9 OpenSearch o successiva.

  • Per abilitare la conservazione a freddo su un dominio OpenSearch di servizio, è necessario abilitarla anche UltraWarm sullo stesso dominio.

  • 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 l'indice utilizza i codec di compressione Zstandard ("index.codec": "zstd"or"index.codec": "zstd_no_dict"), non è possibile spostarlo nella conservazione 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 un controllo granulare degli accessi, gli utenti non amministratori devono essere mappati al cold_manager ruolo nelle OpenSearch dashboard per gestire gli indici freddi.

Nota

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

Configurazione delle autorizzazioni

Se abiliti la conservazione a freddo su un dominio di OpenSearch servizio preesistente, il cold_manager ruolo potrebbe non essere definito nel dominio. Se il dominio utilizza un controllo granulare degli accessi, gli utenti non amministratori devono essere mappati a questo ruolo per gestire gli indici freddi. Per creare manualmente il ruolo cold_manager, procedere nel seguente modo:

  1. In OpenSearch Dashboard, vai su Sicurezza e scegli 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. Seleziona Create (Crea).

  9. Dopo aver creato il ruolo, associalo a qualsiasi ruolo utente o di backend che gestisce gli indici freddi.

Requisiti di archiviazione a freddo e considerazioni sulle prestazioni

Poiché lo storage a freddo utilizza Amazon S3, non comporta alcun sovraccarico dello storage a caldo, ad esempio repliche, spazio riservato Linux e spazio riservato Service. OpenSearch 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. Monitora la ColdStorageSpaceUtilization metrica in Amazon CloudWatch per vedere quanto spazio di archiviazione a freddo stai utilizzando.

Prezzi dell'archiviazione a freddo

Analogamente all' UltraWarm archiviazione, con la conservazione a freddo paghi 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 delle celle frigorifere, consulta i prezzi OpenSearch di Amazon 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 l'Amazon OpenSearch Service API Reference.

Gestione degli indici freddi nelle dashboard OpenSearch

Puoi gestire gli indici caldi, caldi e freddi con l'interfaccia Dashboards esistente nel tuo dominio di servizio. OpenSearch 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 nei dashboard. OpenSearch

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 Il servizio migra un indice alla volta nella conservazione a freddo. È 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 parametroWarmToColdMigrationQueueSize. 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. Guarda la policy di esempio, che dimostra come migrare automaticamente gli indici dalla conservazione a caldo a quella a freddo. UltraWarm

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.

Elencare gli indici freddi

Prima di eseguire l'interrogazione, puoi elencare gli indici in cold storage per decidere a quali migrare per ulteriori analisi. UltraWarm La richiesta seguente elenca tutti gli indici freddi, ordinati per nome dell'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 un elenco di indici freddi. 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 freddi con i criteri di filtro indicati nella sezione precedente, trasferiscili nuovamente UltraWarm dove puoi interrogare i 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

Se devi ripristinare un indice freddo eliminato, puoi ripristinarlo al livello caldo seguendo le istruzioni riportate Ripristino degli indici caldi dalle istantanee e poi migrando nuovamente l'indice al livello freddo. Non è possibile ripristinare un indice di freddo eliminato direttamente nel livello freddo. OpenSearch Il servizio conserva gli indici freddi per 14 giorni dopo la loro eliminazione.

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 di indici freddi

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 OpenSearch di servizio è il modo più semplice per disabilitare la conservazione 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à.