Archiviazione UltraWarm per Amazon OpenSearch Service - Amazon OpenSearch Service

Archiviazione UltraWarm per Amazon OpenSearch Service

UltraWarm offre un modo conveniente per archiviare grandi quantità di dati di sola lettura su Amazon OpenSearch Service. I nodi di dati standard utilizzano l'archiviazione "hot", che assume la forma di archivi di istanze o volumi Amazon EBS collegati a ciascun nodo. L'archiviazione a caldo offre le prestazioni più veloci possibili per l'indicizzazione e la ricerca di nuovi dati.

Piuttosto che l'archiviazione collegata, i nodi UltraWarm utilizzano Amazon S3 e una sofisticata soluzione di memorizzazione nella cache per migliorare le prestazioni. Per gli indici su cui non si sta scrivendo attivamente, sui quali si eseguono query meno frequentemente e per cui non si ha bisogno delle stesse prestazioni, UltraWarm offre costi significativamente inferiori per GiB di dati. Poiché gli indici a caldo sono di sola lettura a meno che non vengano ripristinati all'archiviazione hot, UltraWarm è più adatto ai dati immutabili, ad esempio i registri.

In OpenSearch, questi indici a caldo si comportano come qualsiasi altro indice. È possibile eseguire una query su di essi utilizzando le stesse API o utilizzarli per creare visualizzazioni in OpenSearch Dashboards.

Prerequisiti

UltraWarm ha alcuni prerequisiti importanti:

  • UltraWarm richiede OpenSearch o Elasticsearch 6.8 o superiore.

  • Per utilizzare l'archiviazione warm, i domini devono disporre di nodi master dedicati.

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

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

  • Se il dominio utilizza il controllo granulare degli accessi per effettuare chiamate API UltraWarm gli utenti devono essere mappati al ruolo ultrawarm_manager in OpenSearch Dashboards.

Nota

Il ruolo ultrawarm_manager potrebbe non essere definito in alcuni domini OpenSearch Service preesistenti. Se il ruolo non è visualizzato in Dashboards, sarà necessario crearlo manualmente.

Configurazione delle autorizzazioni

Se si abilita UltraWarm in un dominio OpenSearch Service preesistente, il ruolo ultrawarm_manager potrebbe non essere definito nel dominio. Gli utenti senza privilegi di amministratore devono essere mappati a questo ruolo in modo da gestire gli indici a caldo sui domini che utilizzano il controllo granulare degli accessi. Per creare manualmente il ruolo ultrawarm_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
    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. Scegliere Ruoli, quindi selezionare Crea ruolo.

  4. Denominare il ruolo ultrawarm_manager.

  5. Per Autorizzazioni cluster, selezionare ultrawarm_cluster e cluster_monitor.

  6. Per Indice, digitare *.

  7. Per Autorizzazioni indice, selezionare ultrawarm_index_read, ultrawarm_index_write e indices_monitor.

  8. Scegliere Create (Crea) .

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

Requisiti di archiviazione UltraWarm e considerazioni sulle prestazioni

Come indicato in Calcolo dei requisiti di archiviazione, i dati nell'archiviazione hot comportano un sovraccarico significativo: repliche, spazio riservato per Linux e spazio riservato per OpenSearch Service. Ad esempio, una partizione primaria da 20 GiB con una partizione di replica richiede circa 58 GiB di archiviazione hot.

Poiché utilizza Amazon S3, UltraWarm non subisce questo sovraccarico. Quando si calcolano i requisiti di archiviazione UltraWarm, si considerano solo le dimensioni dei frammenti primari. La durata dei dati in S3 elimina la necessità di repliche e S3 elimina tutte le considerazioni relative al sistema operativo o al servizio. La stessa partizione da 20 GiB richiede 20 GiB di archiviazione a caldo. Se si esegue il provisioning di un'istanza ultrawarm1.large.search, è possibile utilizzare tutti i 20 TiB della relativa archiviazione massima per le partizioni primarie. Vedere Limiti di archiviazione UltraWarm per un riepilogo dei tipi di istanza e la quantità massima di archiviazione che ciascuna può gestire.

Con UltraWarm, consigliamo comunque una dimensione massima della partizione di 50 GiB. Il numero di core CPU e la quantità di RAM allocata a ciascun tipo di istanza UltraWarm dà un'idea del numero di partizioni che possono essere utilizzate simultaneamente per la ricerca. Notare che, mentre per l'archiviazione UltraWarm in S3 contano solo le partizioni primarie, OpenSearch Dashboards e _cat/indices riportano ancora la dimensione dell'indice UltraWarm come totale di tutte le partizioni primarie e di replica.

Ad esempio, ogni istanza ultrawarm1.medium.search ha due core CPU e può indirizzare fino a 1,5 TiB di archiviazione su S3. Due di queste istanze hanno un'archiviazione combinata di 3 TiB, che corrisponde a circa 62 partizioni se ogni partizione è 50 GiB. Se una richiesta al cluster esegue la ricerca solo in quattro di queste partizioni, le prestazioni potrebbero essere eccellenti. Se la richiesta è ampia ed esegue la ricerca in tutte le 62 partizioni, i quattro core della CPU potrebbero faticare per eseguire l'operazione. Monitorare i parametri UltraWarm WarmCPUUtilization e WarmJVMMemoryPressure per capire come le istanze gestiscono i carichi di lavoro.

Se le ricerche sono ampie o frequenti, considerare la possibilità di lasciare gli indici nell'archiviazione hot. Come qualsiasi altro carico di lavoro OpenSearch, la fase più importante per determinare se UltraWarm soddisfa le proprie esigenze è eseguire il test rappresentativo del client utilizzando un set di dati realistico.

Prezzi di UltraWarm

Con l'archiviazione a caldo, si paga per ciò che si fornisce. Alcune istanze richiedono un volume Amazon EBS allegato, mentre altre includono un archivio di istanze. Se lo spazio di archiviazione è vuoto o pieno, si paga lo stesso prezzo.

Con l'archiviazione UltraWarm, si pagha per quello che si usa. Un'istanza ultrawarm1.large.search può indirizzare fino a 20 TiB di archiviazione su S3, ma se si memorizza solo 1 TiB di dati, viene addebitato solo 1 TiB di dati. Come tutti gli altri tipi di nodo, si paga anche una tariffa oraria per ogni nodo UltraWarm. Per ulteriori informazioni, consultare Prezzi per Amazon OpenSearch Service.

Abilitazione di UltraWarm

La console è il modo più semplice per creare un dominio che utilizza l'archiviazione calda. Durante la creazione del dominio, scegliere Abilita nodi dati UltraWarm e il numero di nodi caldi desiderati. 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, UltraWarm potrebbe non essere disponibile per diverse ore.

È inoltre possibile utilizzare l'AWS CLI o l'API di configurazione per abilitare UltraWarm, in particolare le opzioni WarmEnabled, WarmCount e WarmType in ClusterConfig.

Nota

I domini supportano un numero massimo di nodi a caldo. Per dettagli, consulta Limiti di Amazon OpenSearch Service.

Comando CLI di esempio

Il seguente comando AWS CLI crea un dominio con tre nodi di dati, tre nodi principali dedicati, sei nodi a caldo e il controllo granulare degli accessi abilitato:

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

Per ulteriori informazioni, consultare Riferimento ai comandi AWS CLI.

Richiesta all'API di configurazione di esempio

La seguente richiesta all'API di configurazione crea un dominio con tre nodi di dati, tre nodi master dedicati e sei nodi a caldo con il controllo granulare degli accessi abilitato e una policy di accesso restrittiva:

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/*\"}]}" }

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

Migrazione di indici all'archiviazione UltraWarm

Se la scrittura su un indice è terminata e non si ha più bisogno delle prestazioni di ricerca più veloci possibili, eseguire la migrazione dell'indice da hot a caldo:

POST _ultrawarm/migration/my-index/_warm

Quindi controlla lo stato della migrazione:

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

Per eseguire una migrazione, l'integrità dell'indice deve essere verde. Se si esegue la migrazione di diversi indici in rapida successione, è possibile ottenere un riepilogo di tutte le migrazioni in chiaro, simile all'API _cat:

GET _ultrawarm/migration/_status?v index migration_type state my-index HOT_TO_WARM RUNNING_SHARD_RELOCATION

OpenSearch Service migra un indice alla volta a UltraWarm. In coda possono essere presenti fino a 200 migrazioni. Qualsiasi richiesta che supera il limite verrà rifiutata. Per controllare il numero corrente di migrazioni nella coda, monitorare il parametro HotToWarmMigrationQueueSize. Gli indici rimangono disponibili durante tutto il processo di migrazione, senza tempi di inattività.

Il processo di migrazione ha i seguenti stati:

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

Come indicato da questi stati, le migrazioni potrebbero non riuscire durante gli snapshot, le traslocazioni di sezioni o le fusioni forzate. Gli errori durante gli snapshot o il trasferimento di partizioni sono in genere dovuti a errori dei nodi o a problemi di connettività S3. La mancanza di spazio su disco è solitamente la causa sottostante degli errori di unioni forzate.

Al termine di una migrazione, la stessa richiesta _status restituisce un errore. Se si controlla l'indice in quel momento, è possibile visualizzare alcune impostazioni che sono univoche per gli indici caldi:

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, in questo caso, è il numero di repliche passive, che non consumano spazio su disco.

  • routing.allocation.require.box_type specifica che l'indice deve utilizzare nodi caldi anziché nodi dati standard.

  • merge.policy.max_merge_at_once_explicit specifica il numero di segmenti da unire contemporaneamente durante la migrazione.

Poiché gli indici a caldo sono di sola lettura a meno che non vengano ripristinati all'archiviazione hot, UltraWarm è più adatto ai dati immutabili, ad esempio i log. È possibile eseguire query sugli indici ed eliminarli, ma non è possibile aggiungere, aggiornare o eliminare singoli documenti. Se ci si prova, potrebbe essere restituito il seguente errore:

{ "error": { "root_cause": [{ "type": "cluster_block_exception", "reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];" }], "type": "cluster_block_exception", "reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];" }, "status": 403 }

Automazione delle migrazioni

Si consiglia di utilizzare Index State Management in Amazon OpenSearch Service per automatizzare il processo di migrazione dopo che un indice raggiunge una certa età o soddisfa altre condizioni. Consultare la policy di esempio che illustra tale flusso di lavoro.

Regolazione della migrazione

Le migrazioni degli indici all'archiviazione UltraWarm richiedono un'unione forzata. Ogni indice OpenSearch è composto da un certo numero di partizioni, e ogni partizione a sua volta è composta da un certo numero di segmenti Lucene. L'operazione di unione forzata elimina i documenti contrassegnati per l'eliminazione e consente di risparmiare spazio su disco. Per impostazione predefinita, UltraWarm unisce gli indici in un segmento.

È possibile modificare questo valore fino a 1.000 segmenti utilizzando l'impostazione index.ultrawarm.migration.force_merge.max_num_segments. Valori più elevati velocizzano il processo di migrazione, ma aumentano la latenza delle query per l'indice a caldo al termine della migrazione. Per modificare l'impostazione, effettuare la seguente richiesta:

PUT my-index/_settings { "index": { "ultrawarm": { "migration": { "force_merge": { "max_num_segments": 1 } } } } }

Per verificare quanto tempo richiede questa fase del processo di migrazione, monitorare il parametro HotToWarmMigrationForceMergeLatency.

Annullamento di migrazioni

UltraWarm gestisce le migrazioni in sequenza, in una coda. Se una migrazione è nella coda, ma non è ancora stata avviata, è possibile rimuoverla dalla coda utilizzando la seguente richiesta:

POST _ultrawarm/migration/_cancel/my-index

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

Elenco degli indici hot e a caldo

UltraWarm aggiunge due ulteriori opzioni, simili a _all, per aiutare a gestire gli indici hot e warm. Per un elenco di tutti gli indici hot o warm, effettuare le seguenti richieste:

GET _warm GET _hot

È possibile utilizzare queste opzioni in altre richieste che specificano gli indici:

_cat/indices/_warm _cluster/state/_all/_hot

Ritorno degli indici a caldo all'archiviazione hot

Se è necessario scrivere nuovamente su un indice, eseguire la migrazione di nuovo all'archiviazione hot:

POST _ultrawarm/migration/my-index/_hot

È possibile eseguire fino a 10 migrazioni simultanee dall'archiviazione a caldo. Per controllare il numero corrente, monitorare il parametro WarmToHotMigrationQueueSize.

Al termine della migrazione, controllare le impostazioni dell'indice per assicurarti che soddisfino le tue esigenze. Gli indici tornano all'archiviazione hot con una replica.

Ripristino di indici a caldo da snapshot automatici

Oltre al repository standard per gli snapshot automatici, UltraWarm aggiunge un secondo repository per gli indici a caldo, cs-ultrawarm. Ogni snapshot in questo repository contiene un solo indice. Se si elimina un indice a caldo, il relativo snapshot rimarrà nel repository cs-ultrawarm per altri 14 giorni, proprio come qualsiasi altro snapshot automatico.

Quando si ripristina uno snapshot da cs-ultrawarm, viene ripristinata l'archiviazione a caldo, non l'archiviazione hot. Gli snapshot nei repository cs-automated e cs-automated-enc ripristinano l'archiviazione hot.

Come ripristinare uno snapshot UltraWarm nell'archiviazione a caldo

  1. Identificare lo snapshot più recente che contiene l'indice che si desidera ripristinare:

    GET _snapshot/cs-ultrawarm/_all { "snapshots": [{ "snapshot": "snapshot-name", "version": "1.0", "indices": [ "my-index" ] }] }
  2. Se l'indice esiste già, eliminalo:

    DELETE my-index

    Se non si desidera eliminare l'indice, riportarlo all'archiviazione hot e reindicizzarlo.

  3. Ripristinare lo snapshot:

    POST _snapshot/cs-ultrawarm/snapshot-name/_restore

    UltraWarm ignora tutte le impostazioni dell'indice specificate in questa richiesta di ripristino, ma è possibile specificare opzioni come rename_pattern e rename_replacement. Per un riepilogo delle opzioni di ripristino dello snapshot OpenSearch, consultare la documentazione di OpenSearch.

Snapshot manuali di indici a caldo

È possibile acquisire snapshot manuali di indici a caldo, ma non è consigliabile. Il repository cs-ultrawarm automatico contiene già uno snapshot per ogni indice a caldo, acquisito durante la migrazione, senza costi aggiuntivi.

Per impostazione predefinita, OpenSearch Service non include indici a caldo negli snapshot manuali. Ad esempio, la chiamata seguente include solo gli indici hot:

PUT _snapshot/my-repository/my-snapshot

Se si decide di acquisire snapshot manuali di indici a caldo, è necessario tenere in considerazione diversi concetti importanti.

  • Non è possibile mescolare indici hot e a caldo. Ad esempio, la seguente richiesta ha esito negativo:

    PUT _snapshot/my-repository/my-snapshot { "indices": "warm-index-1,hot-index-1", "include_global_state": false }

    Se includono un mix di indici hot e a caldo, le istruzioni con caratteri jolly (*) avranno esito negativo.

  • È possibile includere un solo indice a caldo per snapshot. Ad esempio, la seguente richiesta ha esito negativo:

    PUT _snapshot/my-repository/my-snapshot { "indices": "warm-index-1,warm-index-2,other-warm-indices-*", "include_global_state": false }

    Questa richiesta ha esito positivo:

    PUT _snapshot/my-repository/my-snapshot { "indices": "warm-index-1", "include_global_state": false }
  • Gli snapshot manuali vengono sempre ripristinati nell'archiviazione hot, anche se originariamente includevano un indice a caldo.

Migrazione degli indici a caldo all'archiviazione a freddo

Se si dispone di dati in UltraWarm per cui si eseguono query di rado, prendere in considerazione la migrazione di tali dati all'archiviazione a freddo. L'archiviazione a freddo è pensata per i dati a cui si accede solo occasionalmente o che non sono più utilizzati. Non è possibile leggere o scrivere su indici a freddo, ma è possibile eseguirne di nuovo la migrazione allo all'archiviazione a caldo senza alcun costo ogni volta che è necessario eseguire una query su tali indici. Per istruzioni, consultare Migrazione degli indici all'archiviazione a freddo.

Disattivazione di UltraWarm

La console è il modo più semplice per disabilitare UltraWarm. Scegli il dominio, Operazioni quindi Modifica configurazione cluster. Deseleziona Abilita nodi di dati UltraWarm e scegli Salva modifiche. È inoltre possibile utilizzare l'opzione WarmEnabled nell'API di configurazione e in AWS CLI.

Prima di disabilitare UltraWarm, è necessario eliminare tutti gli indici a caldo o migrarli nuovamente all'archiviazione hot. Quando l'archiviazione warm è vuota, attendere cinque minuti prima di tentare di disattivare la funzionalità.