Dimensionamiento de OpenSearch

En resumen

• Amazon OpenSearch Service: fuente × (1 + réplicas) × (1 + overhead de indexación) ÷ 0,95 ÷ 0,80, que AWS simplifica a aproximadamente fuente × (1 + réplicas) × 1,45.
• OpenSearch autogestionado no tiene overhead de servicio; ObservKit divide el tamaño almacenado por un objetivo de utilización de disco de planificación basado en el low watermark de 85% por defecto.
• Shards: apunta a unos 10–50 GB cada uno y verifica el límite de shards por nodo para tu despliegue y tu versión (autogestionado: 1.000 por defecto; en Amazon OpenSearch Service depende de la versión y del heap).
• Escenario de referencia 250 GB/día durante 90 días, una réplica, 25% de crecimiento: 81,4 TB en Amazon OpenSearch Service y 72,8 TB autogestionado.

Amazon OpenSearch Service frente a autogestionado

Son productos distintos con overheads distintos, así que ObservKit cambia de modelo en lugar de mezclarlos. En Amazon OpenSearch Service, Linux reserva 5% de cada volumen y el servicio reserva 20% (hasta 20 GiB por instancia), y los tiers de almacenamiento como UltraWarm y cold viven en S3. Los clústeres autogestionados asignan según los watermarks de disco (85% low, 90% high y 95% flood stage por defecto), que se evalúan por nodo. El objetivo agregado de planificación de la calculadora es una simplificación de eso.

Fórmula de almacenamiento

La guía de AWS señala que los datos de origen más su índice suelen ser cerca de 110% del origen, por eso ObservKit usa un factor de índice de 1,1 en ambos tipos de despliegue. Mide el tuyo con _cat/indices?v y la columna pri.store.size de un índice de muestra.

Escenario de referencia Sin el overhead del índice (factor 1,0), el resultado de Amazon baja de 81,4 TB a 74 TB. Sin réplica es de 40,7 TB. Abre este escenario

Shards

OpenSearch documenta 10–50 GB por shard como regla práctica; AWS sugiere 10–30 GiB para búsquedas sensibles a la latencia y 30–50 GiB para cargas con mucha escritura, como el análisis de logs. El límite de shards por nodo depende del despliegue: OpenSearch autogestionado usa 1.000 por defecto (cluster.max_shards_per_node, configurable); Amazon OpenSearch Service usa 1.000 hasta OpenSearch 2.15 y, desde la 2.17, 1.000 por cada 16 GiB de heap de JVM, hasta 4.000. La calculadora estima los nodos de datos a partir del límite de shards solo cuando sabe cuál aplica. Demasiados shards pequeños agregan overhead por shard; los shards muy grandes se recuperan y se reubican con lentitud.

Escenario de referencia 250 GB/día indexados con 1,1 y con rollover diario y un objetivo de 30 GB dan 10 shards primarios por día de unos 27,5 GB cada uno. Para una fuente de 2 GB/día, el mismo rollover diario crea un shard de apenas unos 2,2 GB; con rollover cada 14 días llega a unos 15,4 GB. Abre este escenario

Réplicas

Cada réplica agrega una copia completa al almacenamiento hot y ayuda a la disponibilidad y al throughput de búsqueda. Cero réplicas arriesga pérdida de datos ante la falla de un nodo; AWS recomienda al menos una. En UltraWarm y cold los datos están en S3, así que la calculadora cuenta solo los shards primarios.

Tiers de almacenamiento

En Amazon OpenSearch Service puedes mover los índices más antiguos a UltraWarm y a almacenamiento cold. Los índices de UltraWarm son de solo lectura y requieren nodos master dedicados. Escenario de referencia Un año de retención con 14 días hot, 76 días UltraWarm y 275 días cold suma 133,3 TB, frente a 330,2 TB si los 365 días permanecen hot. Abre este escenario

Ejemplo resuelto

Escenario de referencia De EPS a OpenSearch: 8.000 eventos/s con unos 700 bytes son 483,84 GB/día. Con todo en hot durante 30 días en Amazon OpenSearch Service, con una réplica y 25% de crecimiento, el total es de 52,5 TB. Abre este escenario

Errores comunes

• Usar la fórmula de Amazon para un clúster autogestionado, o al revés.
• Olvidar que el índice forma parte del tamaño almacenado (factor de índice).
• Contar UltraWarm y almacenamiento cold con réplicas.
• Dimensionar solo por almacenamiento e ignorar la cantidad de shards.
• Rollover diario para una fuente pequeña, lo que produce shards muy pequeños.

Planificación de disco en clústeres autogestionados

OpenSearch protege los nodos con tres watermarks de disco: en el low watermark (85% por defecto) el clúster deja de asignar nuevos shards a un nodo, en el high watermark (90%) intenta reubicar shards hacia otros nodos y en el flood stage (95%) aplica un bloqueo de solo lectura a los índices que tienen un shard en ese nodo. Estos umbrales se verifican por nodo, así que un nodo lleno puede causar problemas aunque el promedio del clúster se vea sano. La calculadora divide los datos almacenados por un objetivo de utilización agregado (85% por defecto) para dejar margen; tómalo como punto de partida para una conversación sobre capacidad, no como una garantía por nodo.

Deja espacio para algo más que los datos en régimen estable. Los merges de segmentos necesitan espacio temporal, la falla de un nodo traslada sus shards a los sobrevivientes, y una restauración de snapshot o un reindex mantienen brevemente dos copias del mismo índice. Si esperas esos eventos, baja el objetivo de utilización en el modo Experto en lugar de apoyarte en el margen de crecimiento, que está pensado para la ingesta del próximo año.

¿Qué modelo deberías usar?

• Usas Amazon OpenSearch Service. Mantén el despliegue en Amazon, reparte la retención entre hot, UltraWarm y cold solo si vas a usar esos tiers, y espera que el resultado incluya el espacio reservado y el overhead de servicio de AWS.
• Operas OpenSearch por tu cuenta. Usa el modelo autogestionado. No tiene tiers: si además conservas snapshots o un archivo aparte, dimensiónalos por separado.
• Todavía estás eligiendo plataforma. Compara Elasticsearch, Loki y OpenSearch en el hub de capacidad, y recuerda que OpenSearch y Elasticsearch usan aquí fórmulas y valores predeterminados distintos.

Limitaciones

La calculadora no modela cantidad de nodos, tipos de instancia, tipos de volumen EBS e IOPS, cantidad de nodos UltraWarm, instancias OpenSearch Optimized, tiers warm autogestionados ni searchable snapshots, backups, ni la recomendación de AWS de no pasar de 25 shards por GiB de heap de JVM. El overhead de servicio de 20% tiene un tope de 20 GiB por instancia, así que la cifra de Amazon sobrestima cuando los nodos tienen volúmenes grandes.

Fuentes

• Cálculo de los requisitos de almacenamiento — documentación de Amazon OpenSearch Service.
• Cómo elegir el número de shards — documentación de Amazon OpenSearch Service.
• Almacenamiento UltraWarm — documentación de Amazon OpenSearch Service.
• Almacenamiento cold — documentación de Amazon OpenSearch Service.
• Introducción a OpenSearch — documentación de OpenSearch: tamaño de shards y réplicas.
• Ajustes del clúster — documentación de OpenSearch: watermarks de disco y max_shards_per_node.

Última revisión: octubre de 2026 · Calculadora de dimensionamiento de OpenSearch · Planificación de capacidad · Metodología