Almacenamiento UltraWarm para Amazon OpenSearch Service

UltraWarm proporciona una forma rentable de almacenar grandes cantidades de datos de solo lectura en Amazon OpenSearch Service. Los nodos de datos estándar utilizan almacenamiento "en caliente", que adopta la forma de almacenes de instancias o volúmenes de Amazon EBS asociados a cada nodo. El almacenamiento en caliente proporciona el rendimiento más rápido posible para indexar y buscar nuevos datos.

En lugar de almacenamiento asociado, los nodos UltraWarm utilizan Amazon S3 y una sofisticada solución de almacenamiento en caché para mejorar el rendimiento. Para los índices en los que no se está escribiendo de forma activa, que se consultan con menos frecuencia y de los que no se necesita el mismo rendimiento, UltraWarm ofrece costos significativamente inferiores por GiB de datos. Dado que los índices templados son de solo lectura a menos que se los restaure al almacenamiento caliente, UltraWarm es más adecuado para datos inmutables, tales como registros.

En OpenSearch, los índices templados se comportan como cualquier otro índice. Puede consultarlos mediante las mismas API o utilizarlos para crear visualizaciones en OpenSearch Dashboards.

Requisitos previos

UltraWarm tiene algunos requisitos previos importantes:

Configurar permisos

Si habilita UltraWarm en un dominio de OpenSearch Service preexistente, la opción ultrawarm_manager puede no definirse en el dominio. Los usuarios que no sean administradores deben estar asignados a este rol para poder administrar índices templados en los dominios mediante un control de acceso detallado. Para crear el rol ultrawarm_manager de forma manual, siga estos pasos:

Requisitos de almacenamiento UltraWarm y consideraciones de rendimiento

Como se explica en Cálculo de requisitos de almacenamiento, los datos del almacenamiento en caliente generan una sobrecarga significativa: réplicas, espacio reservado para Linux y espacio reservado para OpenSearch Service. Por ejemplo, una partición principal de 20 GiB con una partición de réplica requiere aproximadamente 58 GiB de almacenamiento en caliente.

Debido a que utiliza Amazon S3, UltraWarm no genera ninguno de estos gastos. Al calcular los requisitos de almacenamiento UltraWarm, solo se tiene en cuenta el tamaño de las particiones principales. La durabilidad de los datos en S3 elimina la necesidad de mantener réplicas y S3 abstrae (y hace innecesarias) las consideraciones de sistemas operativos o de servicio. Esa misma partición de 20 GiB requiere solo 20 GiB de almacenamiento templado. Si aprovisiona una instancia ultrawarm1.large.search, puede usar los 20 TiB de su almacenamiento máximo para particiones principales. Consulte Cuotas de almacenamiento UltraWarm para obtener un resumen de los tipos de instancia y la cantidad máxima de almacenamiento que puede abordar cada uno.

Incluso con UltraWarm, recomendamos un tamaño máximo de partición de 50 GiB. El número de núcleos de CPU y cantidad de RAM asignada a cada tipo de instancia UltraWarm brinda una idea del número de particiones que pueden buscar simultáneamente. Tenga en cuenta que, aunque solo las particiones principales cuentan para el almacenamiento UltraWarm en S3, OpenSearch Dashboards y _cat/indices aún informan del tamaño del índice UltraWarm como el total de todas las particiones primarias y de réplica.

Por ejemplo, cada instancia de ultrawarm1.medium.search tiene dos núcleos de CPU y puede abordar hasta 1,5 TiB de almacenamiento en S3. Dos de estas instancias tienen una combinación de 3 TiB de almacenamiento, que funciona en aproximadamente 62 particiones si cada partición es de 50 GiB. Si una solicitud al clúster solo busca cuatro de estas particiones, el rendimiento puede ser excelente. Si la solicitud es amplia y busca los 62, es posible que los cuatro núcleos de CPU tengan dificultades para realizar la operación. Monitoree el WarmCPUUtilization y WarmJVMMemoryPressure de las métricas de UltraWarm para comprender cómo manejan las instancias sus cargas de trabajo.

Si realiza búsquedas amplias o frecuentes, considere dejar los índices en el almacenamiento caliente. Al igual que cualquier otra carga de trabajo de OpenSearch, el paso más importante para determinar si UltraWarm satisface sus necesidades es realizar pruebas representativas en el cliente utilizando un conjunto de datos realista.

Precios de UltraWarm

Con el almacenamiento en caliente, se paga lo que se aprovisiona. Algunas instancias requieren un volumen de Amazon EBS asociado, mientras que otras incluyen un almacén de instancias. Tanto si el almacenamiento está vacío como si está lleno, se paga el mismo precio.

Con el almacenamiento UltraWarm, se paga por lo que se utiliza. Una instancia ultrawarm1.large.search puede poner a disposición hasta 20 TiB de almacenamiento en S3. Sin embargo, si únicamente se almacena 1 TiB de datos, solo se le facturará 1 TiB de datos. Al igual que todos los demás tipos de nodos, también se paga una tarifa por horas por cada nodo UltraWarm. Para más información, consulte Precios de Amazon OpenSearch Service.

Habilitar UltraWarm

La consola es la forma más sencilla de crear un dominio que utiliza almacenamiento templado. Al crear el dominio, elija Habilitar nodos de datos en caliente y la cantidad de nodos en caliente que desee. El mismo proceso básico funciona en dominios existentes, siempre que cumplan los requisitos previos. Incluso después de que el estado del dominio cambie de Procesando a Activo, es posible que UltraWarm no esté disponible para su uso durante varias horas.

Cuando se utiliza un dominio Multi-AZ con modo de espera, la cantidad de nodos templados debe ser un múltiplo de la cantidad de zonas de disponibilidad. Para obtener más información, consulte Multi-AZ con modo de espera.

También puede usar la AWS CLI o la API de configuración para habilitar UltraWarm, concretamente las opciones WarmEnabled, WarmCount y WarmType en ClusterConfig.

Ejemplo de comando de la CLI

El siguiente comando de la AWS CLI crea un dominio con tres nodos de datos, tres nodos maestros dedicados, seis nodos calientes y control de acceso detallado habilitado:

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

Para obtener información detallada, consulte la Referencia de comandos de AWS CLI.

Ejemplo de solicitud a la API de configuración

La siguiente solicitud a la API de configuración crea un dominio con tres nodos de datos, tres nodos maestros dedicados y seis nodos templados con control de acceso detallado habilitado y una política de acceso restrictiva:

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

Para obtener información detallada, consulte la Referencia de API de Amazon OpenSearch Service.

Migración de índices al almacenamiento UltraWarm

Si termina de escribir en un índice y ya no necesita el rendimiento de búsqueda más rápido posible, realice la migración de caliente a UltraWarm:

POST _ultrawarm/migration/my-index/_warm

A continuación, verifique el estado de la migración:

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

El estado del índice debe ser verde para realizar una migración. Si migra varios índices en una sucesión rápida, puede obtener un resumen de todas las migraciones en texto sin formato, similar a la API _cat:

GET _ultrawarm/migration/_status?v

index    migration_type state
my-index HOT_TO_WARM    RUNNING_SHARD_RELOCATION

OpenSearch Service migra un índice por vez a UltraWarm. Se pueden tener hasta 200 migraciones en la cola. Cualquier solicitud que supere el límite será rechazada. Para comprobar el número actual de migraciones en la cola, supervise la métrica de HotToWarmMigrationQueueSize. Los índices permanecen disponibles durante todo el proceso de migración, sin tiempo de inactividad.

El proceso de migración tiene los siguientes estados:

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

Como indican estos estados, se pueden producir errores en las migraciones si se realizan durante instantáneas, reubicaciones de particiones o fusiones forzosas. Los errores durante las instantáneas o las reubicaciones de particiones suelen deberse a errores de nodo o problemas de conectividad de S3. La falta de espacio en el disco suele ser la causa subyacente de los errores en las fusiones forzosas.

Una vez finalizada la migración, la misma solicitud _status devuelve un error. Si comprueba el índice en ese momento, verá algunos parámetros de configuración que son exclusivos de los índices templados:

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

Los índices del almacenamiento caliente son de solo lectura, a menos que los devuelva al almacenamiento en caliente, lo que hace que UltraWarm sea el más adecuado para datos inmutables, como los registros. Puede consultar los índices y eliminarlos, pero no puede agregar, actualizar ni eliminar documentos individuales. Si lo intenta, podría encontrarse con el siguiente error:

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

Automatizar migraciones

Se recomienda utilizar Administración de estados de índice en Amazon OpenSearch Service para automatizar el proceso de migración después de que un índice alcance cierta antigüedad o cumpla otras condiciones. Consulte la política de ejemplo que muestra este flujo de trabajo.

Ajuste de migración

Las migraciones de índice al almacenamiento UltraWarm requieren una combinación de fuerza. Cada índice de OpenSearch se compone de un cierto número de particiones, y cada partición está compuesta por un cierto número de segmentos de Lucene. La operación de fusión forzada purga los documentos marcados para su eliminación y conserva espacio en disco. De forma predeterminada, UltraWarm fusiona los índices en un segmento, excepto los índices kNN, donde se utiliza un valor predeterminado de 20.

Puede cambiar este valor hasta 1000 segmentos utilizando la configuración de index.ultrawarm.migration.force_merge.max_num_segments. Los valores más altos aceleran el proceso de migración, pero aumentan la latencia de consulta para el índice activo una vez finalizada la migración. Para cambiar la configuración, realice la siguiente solicitud:

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

Para comprobar cuánto tiempo tarda esta etapa del proceso de migración, monitoree la métrica de HotToWarmMigrationForceMergeLatency.

Cancelación de migraciones

UltraWarm gestiona las migraciones secuencialmente, en una cola. Si una migración está en la cola, pero aún no se ha iniciado, puede eliminarla de la cola mediante la siguiente solicitud:

POST _ultrawarm/migration/_cancel/my-index

Si el dominio utiliza un control de acceso detallado, debe tener el permiso de indices:admin/ultrawarm/migration/cancel para realizar esta solicitud.

Listado de índices calientes y templados

UltraWarm agrega dos opciones adicionales, similares a _all, para facilitar la administración de los índices calientes y templados. Para obtener una lista de todos los índices calientes o templados, realice las siguientes solicitudes:

GET _warm
GET _hot

Puede utilizar estas opciones en otras solicitudes que especifican índices, por ejemplo:

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

Devolución de índices templados al almacenamiento caliente

Si necesita volver a escribir en un índice, vuelva a migrarlo al almacenamiento en caliente:

POST _ultrawarm/migration/my-index/_hot

Puede tener hasta 10 migraciones en cola del almacenamiento templado al caliente a la vez. OpenSearch Service procesa las solicitudes de migración de una en una, en el orden en que se colocaron en cola. Para comprobar el número actual, monitoree la métrica de WarmToHotMigrationQueueSize.

Una vez finalizada la migración, compruebe la configuración del índice para asegurarse de que satisfaga sus necesidades. Los índices vuelven al almacenamiento caliente con una réplica.

Restauración de índices templados a partir de instantáneas

Además del repositorio estándar para instantáneas automatizadas, UltraWarm agrega un segundo repositorio para índices templados, cs-ultrawarm. Cada instantánea de este repositorio contiene solo un índice. Si elimina un índice caliente, su instantánea permanece en el repositorio de cs-ultrawarm durante 14 días, al igual que cualquier otra instantánea automatizada.

Cuando restaura una instantánea desde cs-ultrawarm, se restaura en el almacenamiento "warm", no en el almacenamiento en caliente. Las instantáneas de los repositorios cs-automated y cs-automated-enc restauran el almacenamiento en caliente.

Instantáneas manuales de índices templados

Usted puede tomar instantáneas manuales de índices templados, pero no lo recomendamos. El repositorio de automatización cs-ultrawarm ya contiene una instantánea para cada índice activo, tomada durante la migración, sin cargo adicional.

De manera predeterminada, OpenSearch Service no incluye los índices templados en las instantáneas manuales. Por ejemplo, la siguiente llamada solo incluye índices calientes:

PUT _snapshot/my-repository/my-snapshot

Si elige tomar instantáneas manuales de índices templados, se aplican varias consideraciones importantes.

Migración de índices templados al almacenamiento frío

Si tiene datos en UltraWarm que consulta con poca frecuencia, considere migrarlos al almacenamiento frío. El almacenamiento frío está diseñado para los datos a los que solo se accede ocasionalmente o que ya no están en uso activo. No puede leer ni escribir en índices fríos, pero puede migrarlos de nuevo al almacenamiento templado sin costo cada vez que necesite consultarlos. Para obtener instrucciones, consulte Migración de índices a cámaras frigoríficas.

Prácticas recomendadas para índices KNN

Deshabilitar UltraWarm

La consola es la forma más sencilla de deshabilitar UltraWarm. Seleccione el dominio, Acciones y Editar la configuración del clúster. Anule la selección de Habilitar nodos de datos cálidos y elija Guardar los cambios. También puede usar la opción WarmEnabled en la API de configuración y en la AWS CLI.

Antes de desactivar UltraWarm, debe eliminar todos los índices templados o migrarlos de nuevo al almacenamiento caliente. Una vez que el almacenamiento templado esté vacío, espere cinco minutos antes de intentar deshabilitar UltraWarm.