Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Almacenamiento de varios niveles para Amazon Service OpenSearch
El almacenamiento en varios niveles para Amazon OpenSearch Service es una solución de gestión de datos inteligente que optimiza el rendimiento y los costes mediante la gestión de los datos en diferentes niveles de almacenamiento. Esta arquitectura permite a las organizaciones equilibrar de manera eficiente el equilibrio entre rendimiento y costo al mantener los datos a los que se accede con frecuencia en un almacenamiento en caliente de alto rendimiento y, al mismo tiempo, transferir los datos a los que se accede con menos frecuencia a un almacenamiento en caliente más rentable.
Amazon OpenSearch Service ofrece dos opciones de arquitectura para el nivel hot/warm de almacenamiento:
+ **OpenSearch Arquitectura de almacenamiento de varios niveles**
+ Combina Amazon S3 con el almacenamiento de instancias local
+ Funciona con instancias OpenSearch optimizadas
+ Soporta operaciones de escritura en niveles cálidos
+ Soporta una migración de datos fluida entre el nivel caliente y el cálido
+ Disponible a partir de la versión OpenSearch 3.3
+ No es compatible con Cold Tier
+ **UltraWarmArquitectura basada en**
+ Combina Amazon S3 con el almacenamiento de instancias local
+ Funciona con UltraWarm instancias
+ Optimizado para cargas de trabajo de nivel cálido de solo lectura
+ Disponible en las versiones 6.8 y superiores de Elasticsearch y en todas las versiones OpenSearch
+ Compatible con Cold Tier
**nota**
Esta documentación solo se centra en la arquitectura de varios niveles. [Para conocer la arquitectura de almacenamiento ultracálido, consulte Almacenamiento [ultracálido y](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ultrawarm.html) en frío](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/cold-storage.html)
## Arquitectura de almacenamiento de varios niveles
**Topics**
+ [Ventajas principales](#multi-tier-benefits)
+ [Requisitos previos](#multi-tier-prerequisites)
+ [Limitaciones](#multi-tier-limitations)
+ [Puntos a tener en cuenta](#things-to-note)
+ [Crear un dominio de varios niveles](#multi-tier-creating)
+ [Gestión de las migraciones de niveles](#multi-tier-managing)
+ [Configuración de seguridad](#multi-tier-security)
+ [Prácticas recomendadas](#multi-tier-best-practices)
+ [Supervisión de métricas](#multi-tier-metrics)
### Ventajas principales
+ **Grabable en caliente:** admite operaciones de escritura en índices en caliente
+ **Migración perfecta:** movimiento fluido de datos entre los niveles de almacenamiento
+ **Optimización de costos:** reduzca los costos de almacenamiento al mover los datos menos activos a un almacenamiento en caliente rentable
+ **Mejora del rendimiento:** mantenga un alto rendimiento para los datos a los que se accede con frecuencia en la capa activa
+ **Administración de datos flexible:** elija la arquitectura que mejor se adapte a sus requisitos de carga de trabajo
+ **Administración automatizada: administración** simplificada del ciclo de vida de los datos en todos los niveles de almacenamiento
### Requisitos previos
+ **Versión del motor: OpenSearch ** **3.3 o posterior**
+ **Familias de instancias:**
+ Nodos activos: OR1 OR2, OM2, o OI2
+ Nodos cálidos: OI2
+ **Seguridad:** Node-to-node cifrado, cifrado en reposo, HTTPS reforzado
### Limitaciones
+ Funciona en todos los dominios con instancias OpenSearch optimizadas que aún no tengan Ultrawarm activado
+ No es compatible con el nivel frío
### Puntos a tener en cuenta
+ Las migraciones de calor a clima cálido no provocan una fusión forzada en una arquitectura de varios niveles. Si es necesario, el usuario aún puede organizar fusiones forzadas mediante la política de gestión de índices.
+ Además de la indexación, los nodos cálidos ahora también realizan operaciones de combinación en segundo plano (similares a las calientes).
+ Todas las solicitudes de búsqueda en índices calientes se dirigen al fragmento principal y los servidores de réplica solo leen cuando el fragmento principal está inactivo.
+ Esta arquitectura también admite instantáneas automatizadas para índices cálidos
+ La replicación entre clústeres solo se admite para índices calientes
+ Los índices APIs como Shrink, Split y Clone no funcionan con índices cálidos.
### Crear un dominio de varios niveles
#### Paso 1: Crear el dominio
```
aws opensearch create-domain \
--domain-name my-domain \
--engine-version OpenSearch_3.3 \
--cluster-config InstanceCount=3,InstanceType=or2.large.search,DedicatedMasterEnabled=true,DedicatedMasterType=m6g.large.search,DedicatedMasterCount=3,WarmEnabled=true,WarmCount=3,WarmType=oi2.2xlarge.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":"user_name","MasterUserPassword":"your_pass"}}' \
--access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":"*","Action":"es:*","Resource":"*"}]}' \
--region us-east-1
```
#### Paso 2: Verificar los nodos calientes
```
aws opensearch describe-domain-nodes --domain-name my-domain --region us-east-1
```
Ejemplo de respuesta (extracto):
```
{
"NodeType": "Warm",
"InstanceType": "oi2.large.search",
"NodeStatus": "Active"
}
```
### Gestión de las migraciones de niveles
Compatibilidad con dominios de varios niveles:
+ Nueva organización en niveles APIs para una experiencia simplificada
+ Legacy en materia UltraWarm APIs de compatibilidad
#### Nueva estratificación APIs
**Migrar un índice a cálido:**
```
curl -XPOST 'https://localhost:9200/index-name/_tier/warm'
```
Respuesta:
```
{"acknowledged": true}
```
**Migrar un índice a caliente:**
```
curl -XPOST 'https://localhost:9200/index-name/_tier/hot'
```
Respuesta:
```
{"acknowledged": true}
```
**Compruebe el estado de la organización por niveles:**
```
curl -XGET 'https://localhost:9200/index-name/_tier'
```
Ejemplo de respuesta:
```
{
"tiering_status": {
"index": "index-name",
"state": "RUNNING_SHARD_RELOCATION",
"source": "HOT",
"target": "WARM",
"start_time": 1745836500563,
"shard_level_status": {
"running": 0,
"total": 100,
"pending": 100,
"succeeded": 0
}
}
}
```
**Vista compartida detallada:**
```
curl 'https://localhost:9200/index1/_tier?detailed=true'
```
**Enumere todas las migraciones en curso (texto):**
```
curl 'https://localhost:9200/_tier/all'
```
**Enumere todas las migraciones en curso (JSON):**
```
curl 'https://localhost:9200/_tier/all?format=json'
```
**Filtrar por nivel de destino:**
```
curl 'https://localhost:9200/_tier/all?target=_warm'
```
#### Legado UltraWarm APIs por motivos de compatibilidad
**Migre a una zona cálida:**
```
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_warm
```
**Migrar a calor:**
```
curl -XPOST localhost:9200/_ultrawarm/migration/index2/_hot
```
**Compruebe el estado:**
```
curl -XGET localhost:9200/_ultrawarm/migration/index2/_status
```
### Configuración de seguridad
Si habilitas el almacenamiento de varios niveles en un dominio de Amazon OpenSearch Service preexistente, es posible que la `storage_tiering_manager` función no esté definida 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 `storage_tiering_manager` de forma manual, siga estos pasos:
1. **En los OpenSearch paneles, vaya a **Seguridad** y elija Permisos.**
1. Seleccione **Crear grupo de acciones** y configure los siguientes grupos:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/opensearch-service/latest/developerguide/multi-tier-storage.html)
1. Seleccione **Roles** y, a continuación, **Crear rol**.
1. Llame al rol `storage_tiering_manager`.
1. Para **Permisos de clúster,** seleccione `storage_tiering_cluster` y `cluster_monitor`.
1. Para **Índice**, escriba `*`.
1. **Para los permisos de índice, seleccione y.** `storage_tiering_index_read` `storage_tiering_index_write` `indices_monitor`
1. Seleccione **Crear**.
1. Después de crear el rol, asígnelo a cualquier rol de usuario o backend que administre índices de varios niveles.
### Prácticas recomendadas
Al implementar el almacenamiento de varios niveles en sus dominios de Amazon OpenSearch Service, tenga en cuenta las siguientes prácticas recomendadas:
+ Revise periódicamente sus patrones de acceso a los datos para optimizar la asignación de niveles
+ Supervise las métricas de rendimiento para garantizar una utilización eficiente de los recursos
+ Utilice la nueva organización en niveles APIs para un control pormenorizado de la migración de datos
### Supervisión de métricas
Los dominios de almacenamiento de varios niveles proporcionan métricas adicionales para monitorear el rendimiento de los niveles intermedios. Estas métricas incluyen tanto las UltraWarm métricas existentes como las nuevas métricas específicas de la arquitectura de instancias OpenSearch optimizadas:
#### Nuevas métricas
| Nombre de métrica | Estadísticas a nivel de nodo | Estadísticas a nivel de clúster | Granularity (Grado de detalle) |
| --- | --- | --- | --- |
| WarmIndexingLatency | Media | Media | 1 min |
| WarmIndexingRate | Media | promedio, máximo, suma | 1 min |
| WarmThreadpoolIndexingQueue | Máximo | Suma, máximo, promedio | 1 min |
| WarmThreadpoolIndexingRejected | Máximo | Sum | 1 min |
| WarmThreadpoolIndexingThreads | Máximo | Suma, promedio | 1 min |