Calculadora de dimensionamiento de OpenSearch

Ejemplo resuelto: Amazon OpenSearch Service, solo hot

Escenario de referencia los valores predeterminados de la calculadora: 250 GB/día de datos de la fuente, 90 días en hot, 1 réplica, factor índice / fuente 1,1 y 25% de crecimiento. Abre este escenario.

AWS simplifica la misma fórmula a fuente × (1 + réplicas) × 1,45. Los términos exactos dan un multiplicador de 2,9 con una réplica.

Escenarios de referencia

Escenario de referencia puntos de comparación, no layouts recomendados. Factor índice / fuente de 1,1, 1 réplica, 25% de crecimiento, objetivo de planificación de 85% para la fila autogestionada.

Conservar un año en hot necesita 330,2 TB; mover 351 días a tiers respaldados por S3 necesita 133,3 TB, 2,48× menos, porque los datos warm y cold no llevan réplicas ni nada del overhead del almacenamiento hot. Los mismos 90 días en un clúster autogestionado necesitan 72,8 TB: el overhead de servicio de AWS no aplica allí, pero sí un objetivo de utilización planificada.

Ejemplo de planificación de shards

OpenSearch documenta 10–50 GB por shard como regla práctica (AWS: 10–30 GiB para búsquedas sensibles a la latencia, 30–50 GiB para análisis de logs con mucha escritura). El límite de shards por nodo depende del despliegue y de la versión. El planificador divide los datos indexados de cada rollover por un tamaño de shard objetivo y redondea hacia arriba.

Ejemplo ilustrativo 2 GB/día con rollover diario indexa 2,2 GB por rollover, así que cada shard es de unos 2,2 GB, por debajo de la regla práctica de 10 GB, y 90 días producen 180 shards en nodos de datos. Con rollover cada 14 días, los shards son de unos 15,4 GB y suman 28. Abre el rollover de 14 días.

Errores comunes

1. Aplicar la fórmula de Amazon a un clúster autogestionado, o al revés. Los términos de 5% de Linux y 20% de overhead de servicio son de AWS. En el escenario de 250 GB/día, el modelo del servicio de Amazon da 81,4 TB y el modelo autogestionado 72,8 TB. Elige el despliegue que corresponde al tuyo.
2. Darle réplicas a UltraWarm y al almacenamiento cold. Están respaldados por S3 y cuentan solo shards primarios. En el escenario anual con tiers, UltraWarm necesita 26,1 TB; contar una réplica mostraría 52,3 TB.
3. Mantener en hot un año de datos que casi no se consultan. Todo en hot, un año necesita 330,2 TB; con tiers necesita 133,3 TB.
4. Planificar con cero réplicas. Ejemplo hipotético sin réplica, el escenario de 250 GB/día necesita 40,7 TB en lugar de 81,4 TB, pero la pérdida de un nodo implica pérdida de datos. AWS recomienda al menos una réplica.
5. Asumir que no hay overhead de indexación. Ejemplo hipotético con un factor de 1,0 en lugar del 1,1 documentado, el escenario de 250 GB/día se reduce a 74 TB, 10% por debajo de lo que indica AWS. Mide tu propio factor.
6. Índices diarios para volúmenes pequeños. Muchos shards pequeños agregan overhead por shard: 180 shards de unos 2,2 GB, frente a 28 con rollover de 14 días.
7. Mezclar los valores por defecto del código abierto y del servicio de Amazon. OpenSearch de código abierto crea por defecto un primario y una réplica; AWS documenta que el servicio de Amazon divide por defecto un índice en cinco shards primarios. Define explícitamente la cantidad de shards antes de indexar.

Cómo se calcula el dimensionamiento de OpenSearch

Amazon OpenSearch Service
  fuente(tier)        = ingesta diaria × días del tier × (1 + crecimiento)
  hot a aprovisionar  = fuente(hot) × (1 + réplicas) × factor de índice ÷ 0,95 ÷ 0,80
  UltraWarm           = fuente(warm) × factor de índice        solo shards primarios
  almacenamiento cold = fuente(cold) × factor de índice        solo shards primarios

OpenSearch autogestionado (solo hot)
  disco a aprovisionar = fuente × (1 + réplicas) × factor de índice ÷ objetivo de utilización (85%)

shards por rollover = ceil(ingesta diaria × factor de índice × días de rollover ÷ tamaño objetivo de shard)

• Unidades decimales: 1.000 GB = 1 TB.
• Los términos 0,95 y 0,80 son el espacio reservado de Linux y el almacenamiento reservado del servicio, aplicados como el peor caso de AWS.
• No se modela: cantidad de nodos e instancias, tipos de volumen EBS, cantidad de nodos UltraWarm, la recomendación de 25 shards por GiB de heap ni los tiers warm autogestionados.

El modelo común detrás de cada calculadora está en la metodología.