UltraWarm spazio di archiviazione per Amazon OpenSearch Service

UltraWarm offre un modo conveniente per archiviare grandi quantità di dati di sola lettura su Amazon Service. OpenSearch 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.

Invece dello storage collegato, UltraWarm i nodi utilizzano Amazon S3 e una sofisticata soluzione di caching per migliorare le prestazioni. Per gli indici su cui non scrivi attivamente, esegui query meno frequentemente e che non richiedono le stesse prestazioni, UltraWarm offre costi notevolmente inferiori per GiB di dati. Poiché gli indici caldi sono di sola lettura a meno che non vengano restituiti all'archiviazione a caldo, sono più adatti per dati immutabili, UltraWarm come i log.

In OpenSearch, gli indici caldi si comportano come qualsiasi altro indice. Puoi interrogarli utilizzando le stesse API o usarli per creare visualizzazioni nelle dashboard. OpenSearch

Prerequisiti

UltraWarm presenta alcuni prerequisiti importanti:

• UltraWarm richiede Elasticsearch 6.8 OpenSearch o versione successiva.

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

• Quando si utilizza un dominio Multi-AZ con standby, il numero di nodi caldi deve essere un multiplo del numero di zone di disponibilità utilizzate.

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

• Se l'indice utilizza codec di compressione Zstandard ("index.codec": "zstd"o"index.codec": "zstd_no_dict"), non è possibile spostarlo nella memoria 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 un controllo granulare degli accessi, gli utenti devono essere mappati al ultrawarm_manager ruolo nelle dashboard per effettuare chiamate API. OpenSearch UltraWarm

Nota

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

Configurazione delle autorizzazioni

Se si abilita UltraWarm su un dominio di OpenSearch servizio preesistente, il ultrawarm_manager ruolo 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 Dashboard, vai su Sicurezza e scegli 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. Scegli Crea.

9. Dopo aver creato il ruolo, associalo a qualsiasi utente o ruolo di backend che gestirà gli indici. UltraWarm

UltraWarm requisiti di archiviazione e considerazioni sulle prestazioni

Come illustrato in precedenzaCalcolo dei requisiti di archiviazione, i dati nell'archiviazione a caldo comportano un sovraccarico significativo: repliche, spazio riservato Linux e OpenSearch spazio riservato ai servizi. Ad esempio, una partizione primaria da 20 GiB con una partizione di replica richiede circa 58 GiB di archiviazione ad accesso frequente.

Poiché utilizza Amazon S3, non UltraWarm comporta alcun sovraccarico. Nel calcolo dei requisiti UltraWarm di archiviazione, si considera solo la dimensione degli shard 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 UltraWarm quote di archiviazione per un riepilogo dei tipi di istanza e la quantità massima di archiviazione che ciascuna può gestire.

Tuttavia UltraWarm, consigliamo comunque una dimensione massima dello shard di 50 GiB. Il numero di core della CPU e la quantità di RAM allocata a ciascun tipo di UltraWarm istanza ti danno un'idea del numero di shard che possono essere cercati contemporaneamente. Tieni presente che, sebbene solo gli shard primari contino ai fini UltraWarm dello storage in S3, in OpenSearch Dashboard le dimensioni UltraWarm dell'indice vengono _cat/indices comunque riportate come il totale di tutti gli shard primari 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. Monitora le WarmJVMMemoryPressure UltraWarm metriche WarmCPUUtilization e per capire come le istanze gestiscono i carichi di lavoro.

Se le ricerche sono vaste o frequenti, valuta la possibilità di lasciare gli indici nell'archiviazione ad accesso frequente. Proprio come qualsiasi altro OpenSearch carico di lavoro, il passaggio più importante per determinare se UltraWarm soddisfa le proprie esigenze è eseguire test rappresentativi sui clienti utilizzando un set di dati realistico.

UltraWarm prezzi

Con l'archiviazione ad accesso frequente, 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 UltraWarm lo spazio di archiviazione, paghi in base a ciò che usi. 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 nodi, paghi anche una tariffa oraria per ogni UltraWarm nodo. Per ulteriori informazioni, consulta Prezzi per Amazon OpenSearch Service.

Abilitazione UltraWarm

La console è il modo più semplice per creare un dominio che utilizza l'archiviazione calda. Durante la creazione del dominio, scegli Abilita nodi UltraWarm dati e il numero di nodi caldi che desideri. Lo stesso processo di base funziona sui domini esistenti, a condizione che soddisfino i prerequisiti. Anche dopo la modifica dello stato del dominio da Processing a Active, UltraWarm potrebbe non essere disponibile all'uso per diverse ore.

Quando si utilizza un dominio Multi-AZ con standby, il numero di nodi caldi deve essere un multiplo del numero di zone di disponibilità utilizzate. Per ulteriori informazioni, consulta Multi-AZ con Standby.

Puoi anche utilizzare l'API AWS CLIo di configurazione per abilitare UltraWarm, in particolare WarmEnabledWarmCount, e WarmType le opzioni in. ClusterConfig

Nota

I domini supportano un numero massimo di nodi a caldo. Per informazioni dettagliate, vedi Quote OpenSearch del servizio Amazon.

Comando CLI di esempio

Il AWS CLI comando seguente crea un dominio con tre nodi di dati, tre nodi master dedicati, sei nodi caldi e un 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 l'Amazon OpenSearch Service API Reference.

Migrazione degli indici verso lo storage UltraWarm

Se hai finito di scrivere su un indice e non hai più bisogno delle prestazioni di ricerca più veloci possibili, esegui la migrazione da hot a: UltraWarm

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 Il servizio esegue la migrazione di un indice alla volta su. 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 parametroHotToWarmMigrationQueueSize. 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 controlli l'indice in quel momento, puoi visualizzare alcune impostazioni che sono univoche per gli indici a caldo:

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 di dati standard.

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

Gli indici nella memoria a caldo sono di sola lettura a meno che non vengano restituiti all'archiviazione a caldo, che li rende UltraWarm più adatti a dati immutabili, come 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" : "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
}

Automazione delle migrazioni

Si consiglia di utilizzare Gestione dello stato dell'indice 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 verso lo storage richiedono un'unione forzata. UltraWarm Ogni OpenSearch indice è composto da un certo numero di frammenti e ogni frammento è composto da un certo numero di segmenti di 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 unico 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 ad accesso frequente e degli indici a caldo

UltraWarm aggiunge due opzioni aggiuntive, simili a_all, per aiutare a gestire gli indici caldi e caldi. Per un elenco di tutti gli indici ad accesso frequente o a caldo, effettua le seguenti richieste:

GET _warm
GET _hot

Puoi utilizzare queste opzioni in altre richieste che specificano gli indici:

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

Ritorno di indici a caldo all'archiviazione ad accesso frequente

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

POST _ultrawarm/migration/my-index/_hot

È possibile avere fino a 10 migrazioni in coda dalla memorizzazione a caldo a quella a caldo alla volta. OpenSearch Il servizio elabora le richieste di migrazione una alla volta, nell'ordine in cui sono state messe in coda. 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 ad accesso frequente con una replica.

Ripristino degli indici caldi dalle istantanee

Oltre al repository standard per le istantanee automatiche, UltraWarm aggiunge un secondo archivio per gli indici caldi,. 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 ad accesso frequente. Gli snapshot nei repository cs-automated e cs-automated-enc ripristinano l'archiviazione ad accesso frequente.

Per ripristinare un'istantanea in una memoria calda UltraWarm

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

   GET _snapshot/cs-ultrawarm/_all?verbose=false
   
   {
     "snapshots": [{
       "snapshot": "snapshot-name",
       "version": "1.0",
       "indices": [
         "my-index"
       ]
     }]
   }

   Nota

   Per impostazione predefinita, l'GET _snapshot/<repo>operazione visualizza informazioni dettagliate sui dati come ora di inizio, ora di fine e durata per ogni istantanea all'interno di un repository. L'GET _snapshot/<repo>operazione recupera le informazioni dai file di ogni istantanea contenuta in un repository. Se non sono necessarie l'ora di inizio, l'ora di fine e la durata e si richiedono solo il nome e le informazioni sull'indice di un'istantanea, si consiglia di utilizzare il verbose=false parametro quando si elencano le istantanee per ridurre al minimo i tempi di elaborazione ed evitare il timeout.

2. Se l'indice esiste già, eliminalo:

   DELETE my-index

   Se non si desidera eliminare l'indice, riportarlo all'archiviazione ad accesso frequente 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 e. rename_pattern rename_replacement Per un riepilogo delle opzioni di ripristino delle OpenSearch istantanee, consulta la OpenSearch documentazione.

Snapshot manuali di indici a caldo

Puoi eseguire 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 caldi nelle istantanee manuali. Ad esempio, la chiamata seguente include solo gli indici ad accesso frequente:

PUT _snapshot/my-repository/my-snapshot

Per eseguire snapshot manuali di indici a caldo, occorre fare delle considerazioni importanti.

• Non è possibile mescolare indici ad accesso frequente e indici 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 mescoli indici ad accesso frequente e indici a caldo, le istruzioni con caratteri jolly (*) non riescono.

• Puoi includere un solo indice a caldo per ogni 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 ad accesso frequente, anche se originariamente includevano un indice a caldo.

Migrazione degli indici a caldo all'archiviazione a freddo

Se hai dati UltraWarm che richiedi raramente, valuta la possibilità di migrarli alla conservazione a freddo. L'archiviazione a freddo è pensata per i dati a cui si accede solo occasionalmente o che non sono più utilizzati. Non puoi leggere o scrivere su indici a freddo, ma puoi eseguirne di nuovo la migrazione allo storage a caldo senza alcun costo ogni volta che devi eseguire una query su tali indici. Per istruzioni, consulta Migrazione degli indici all'archiviazione a freddo.

Disabilitazione UltraWarm

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

Prima di disabilitarli UltraWarm, devi eliminare tutti gli indici caldi o migrarli nuovamente all'archiviazione a caldo. Una volta esaurita la memoria a caldo, attendi cinque minuti prima di provare a disattivarla. UltraWarm