Calculadora de dimensionamiento de Elasticsearch

Ejemplo resuelto: el escenario de referencia

Escenario de referencia los datos de entrada predeterminados de la calculadora: 250 GB/día de datos sin procesar, 90 días de retención repartidos en 7 hot / 23 warm / 60 cold (cold como índices regulares), 1 réplica, factor índice/sin procesar 1,0, 25% de crecimiento y un objetivo de utilización de disco planificada de 85%. Abre este escenario.

El margen se aplica por división: para mantener el uso en 85% o menos, el disco aprovisionado es utilizable ÷ 0,85, lo que suma cerca de 17,6%, no 15%. Con todos los tiers regulares, factor 1,0 y una réplica, el resultado equivale a la estimación genérica de almacenamiento de logs dividida por 0,85.

Comparación de tiers de datos

Cold regular no es lo mismo que un searchable snapshot cold. Un índice cold regular conserva primarios y réplicas en disco local, igual que hot y warm. Un searchable snapshot fully mounted conserva una copia local y depende del repositorio de snapshots para la resiliencia. En el escenario de referencia, pasar los 60 días cold a searchable snapshots reduce el disco aprovisionado de 66,2 TB a 44,1 TB y agrega 18,8 TB en el repositorio. Los searchable snapshots requieren una suscripción Enterprise en clústeres autogestionados.

Frozen no es un dataset completo en local. Los índices partially mounted solo conservan una caché compartida en local; cada búsqueda que no encuentra datos en la caché lee del repositorio. La proporción de caché de 10% que usa ObservKit es una suposición de planificación, no una recomendación de Elastic: dimensiónala según la parte de datos frozen que realmente consultas. La guía de dimensionamiento de tiers de datos explica cuándo vale la pena cada tier.

Escenarios de referencia

Escenario de referencia Cada fila la calcula el motor de arriba y se abre con sus datos de entrada ya cargados; son puntos de comparación, no layouts recomendados. Una réplica en tiers regulares, factor 1,0, 25% de crecimiento, 85% de utilización planificada.

Conservar un año con 335 días en frozen necesita 33,7 TB de disco local y 104,7 TB en el repositorio. El mismo año con índices cold regulares y una réplica necesita 268,4 TB de disco local.

Ejemplo de planificación de shards

La guía de Elastic para el tamaño de los shards es apuntar a shards de entre 10 GB y 50 GB y mantener cada shard por debajo de 200 millones de documentos; para datos de series temporales sugiere hacer rollover con max_primary_shard_size en 50 GB. El planificador divide los datos primarios indexados de cada ventana de rollover por un tamaño de shard objetivo y redondea hacia arriba.

Cada réplica agrega la misma cantidad de shards de réplica. Elasticsearch limita por defecto los shards no frozen a 1.000 por nodo, así que la cantidad de shards, y no solo el disco, puede fijar un mínimo de nodos. Abre el objetivo de 30 GB · Abre el objetivo de 50 GB.

Errores comunes

1. Agregar réplicas a los searchable snapshots. Los índices cold fully mounted no tienen réplicas por defecto. Contar una réplica para los 60 días cold da 44,1 TB de disco cold en lugar de 22,1 TB.
2. Agregar réplicas, o copias completas, a frozen. Tratar 335 días frozen como datos cold regulares con una réplica pide 246,3 TB de disco local; los datos frozen partially mounted necesitan una caché local de 11,6 TB en este modelo.
3. Planificar con el disco al 100%. El escenario de referencia necesita 56,3 TB de datos con crecimiento. Aprovisionar exactamente eso deja a cada nodo por encima del low watermark de 85%, donde Elasticsearch deja de asignarle shards (salvo los primarios de índices recién creados); con 90% (high) intenta mover shards a otros nodos, y con 95% (flood stage) los índices con un shard en ese nodo pasan a solo lectura. Planificar con 85% da 66,2 TB.
4. Interpretar el objetivo de 85% como matemática del asignador. Los watermarks se evalúan por nodo, no como promedio del clúster: un nodo lleno bloquea la asignación aunque el clúster esté en 70%. En discos grandes, el low.max_headroom por defecto de 200 GB hace que el low watermark se alcance cuando quedan 200 GB libres, cerca de 98% usado en un disco de 10 TB.
5. Asumir factor índice/sin procesar = 1. Los mappings, multi-fields, _source, códecs y LogsDB cambian el tamaño en disco. Ejemplo hipotético Con un factor de 1,3 el escenario de referencia necesita 86 TB; con 0,7, 46,3 TB. Mídelo como pri.store.size de los índices con rollover dividido entre los bytes sin procesar enviados para ellos.
6. Demasiados shards pequeños. Ejemplo ilustrativo Con 2 GB/día, rollover diario y 90 días de retención, cada data stream acumula 90 shards primarios de unos 2 GB. Con rollover cada 15 días salen 6 shards de unos 30 GB para los mismos datos. Abre el escenario con rollover de 15 días.
7. Presupuestar el repositorio de snapshots como disco local. En el escenario frozen, 104,7 TB viven en almacenamiento de objetos y 33,7 TB en los nodos. Comprar disco de nodos para el total del repositorio sobrecompra; olvidar el repositorio subcompra almacenamiento de objetos.

Cómo se calcula el dimensionamiento de Elastic

indexado/día    = GB/día sin procesar × factor índice/sin procesar
dataset del tier = indexado/día × días del tier
tier regular     local = dataset × (1 + réplicas)
cold snapshot    local = dataset × 1          repositorio = dataset
frozen           local = dataset × % de caché  repositorio = dataset
utilizable       = local × (1 + crecimiento)
aprovisionado    = utilizable ÷ utilización planificada (85%)      hot, warm, cold
                 = utilizable ÷ 0,90 de caché compartida           frozen
shards/rollover  = ceil(indexado/día × días de rollover ÷ tamaño objetivo de shard)

• Utilización planificada (85%): un supuesto agregado de planificación inspirado en los watermarks de disco por nodo, pero no igual a ellos.
• Factor índice/sin procesar: es 1,0 por defecto porque no existe una proporción universal; ajústalo a partir de mediciones.
• Réplicas: se aplican solo a índices regulares.
• Searchable snapshots: sin réplicas; el repositorio contiene el dataset completo.
• Caché frozen: 10% del dataset frozen por defecto (suposición de ObservKit); los nodos frozen dedican por defecto 90% del disco a la caché compartida.
• Shards: un conteo derivado del tamaño y del rollover; una orientación, no una recomendación de producción.
• No se modela: cantidad de nodos y relaciones RAM:disco, backups con snapshots regulares de datos hot/warm, overhead del SO y del sistema de archivos, ni picos de merges y translog.

El modelo común detrás de todas las calculadoras se describe en la metodología.