Dimensionamiento de Elasticsearch: hot, warm, cold y frozen

En resumen

• Los tiers regulares (hot, warm, cold) almacenan dataset × (1 + réplicas) en disco local. Los searchable snapshots almacenan una copia local (cold) o solo una caché (frozen), y el dataset completo en el repositorio.
• Con retenciones largas, el lugar donde caen los días importa más que cualquier otro dato de entrada: en el ejemplo ilustrativo de abajo, el mismo año de 250 GB/día necesita 268,4 TB de disco local en tiers regulares y 33,7 TB con 335 días en frozen.
• Aprovisiona según un objetivo de utilización, no al 100%: el plan predeterminado divide los datos utilizables por 85%.

Cuándo usar cada tier

Los tiers dependen del patrón de acceso, no solo de la antigüedad: si un equipo busca 30 días hacia atrás cada mañana, esos 30 días pertenecen a hot o warm, sin importar lo que sugiera la plantilla de la política de ILM.

Disco local frente a repositorio de snapshots

Mover datos a searchable snapshots no elimina almacenamiento: lo traslada. En el layout de un año con 60 días cold fully mounted y 275 días frozen, los nodos necesitan 53,7 TB y el repositorio contiene 104,7 TB incluyendo el crecimiento. El repositorio pasa a formar parte de la ruta de recuperación: un shard perdido de un searchable snapshot se restaura desde allí, de modo que su disponibilidad y su throughput importan tanto como los discos de los nodos.

Ejemplo resuelto: un año a 250 GB/día

Ejemplo ilustrativo 250 GB/día de datos crudos, factor 1,0, una réplica en tiers regulares, 25% de crecimiento, 85% de utilización planificada, con 365 días de retención. Tres layouts:

El layout todo regular está dominado por 335 días cold almacenados dos veces. Pasarlos a frozen reduce el disco local aprovisionado en 7,97×, a cambio de búsquedas más lentas sobre todo lo que tenga más de 30 días y de un repositorio de 104,7 TB. El layout intermedio mantiene dos meses consultables a velocidad local por 20 TB más de disco de nodos que ir directo a frozen.

Cold regular frente a fully mounted

En el escenario de referencia de 90 días (7 hot, 23 warm, 60 cold), el cold regular necesita 44,1 TB de disco en nodos cold; el fully mounted necesita 22,1 TB, más 18,8 TB en el repositorio. Elige fully mounted cuando:

• tengas la suscripción Enterprise que requieren los searchable snapshots en clústeres autogestionados;
• el repositorio pueda restaurar un shard perdido dentro de tu objetivo de recuperación;
• quieras búsquedas cold a velocidad de disco local sin pagar por réplicas.

Mantén índices cold regulares cuando los datos aún se actualizan, cuando el repositorio es remoto y lento, o cuando necesitas réplicas para el throughput de búsqueda y no para la resiliencia. Abre el escenario cold fully mounted en Elastic.

Dimensionar la caché frozen

Los nodos frozen mantienen una caché compartida con los datos leídos recientemente y obtienen el resto del repositorio. El 10% predeterminado de ObservKit es una suposición de planificación, no una recomendación de Elastic. Una mejor estimación es la proporción de datos frozen que tus búsquedas realmente tocan.

Ejemplo hipotético 335 días frozen contienen 83,8 TB. Con 10% la caché es de 8,4 TB. Si las investigaciones leen de forma habitual los 90 días frozen más recientes, el conjunto de trabajo es cerca de 27% del rango frozen (90 ÷ 335): la caché pasa a 22,6 TB y el disco frozen aprovisionado a 31,4 TB. Abre el escenario con 27% de caché en Elastic.

Los nodos frozen dedican 90% de su disco a la caché compartida por defecto, por eso el disco frozen aprovisionado es la caché dividida por 0,9 y no por el objetivo de 85%.

Utilización de disco

Elasticsearch evalúa los watermarks de disco por nodo: en el low watermark de 85% deja de asignar shards al nodo (salvo los primarios de índices nuevos), en 90% reubica shards hacia otros nodos y en 95% aplica un bloqueo de solo lectura a los índices con shards allí. Dividir los datos utilizables por 0,85 mantiene el promedio en el low watermark; no garantiza que cada nodo quede por debajo. Los shards de tamaños desiguales y las fallas de nodos empujan a nodos individuales por encima, así que toma 85% como un límite superior de planificación, no como un objetivo que llenar.

En discos grandes, el low.max_headroom de 200 GB que viene por defecto limita el espacio libre exigido, de modo que un nodo de 10 TB llega a su low watermark con cerca de 98% usado. Eso da más espacio utilizable por nodo, pero ObservKit no modela tamaños de nodo y mantiene el objetivo agregado de 85%.

Errores comunes

1. Elegir tiers según plantillas de antigüedad en lugar del acceso. Si los dashboards leen 30 días y hot contiene 7, la mayoría de las búsquedas llegan a discos warm dimensionados para lecturas ocasionales.
2. Contar réplicas en searchable snapshots. Una réplica sobre 60 días cold fully mounted duplica el disco cold de 22,1 TB a 44,1 TB sin ganar resiliencia; el repositorio ya la aporta.
3. Olvidar el presupuesto del repositorio. El layout con frozen a partir de los 30 días necesita 104,7 TB de almacenamiento de objetos. Es más barato que el disco de nodos, no gratuito.
4. Fijar la caché frozen a partir de un valor predeterminado. Una caché menor que el conjunto de trabajo convierte cada búsqueda en lecturas del repositorio; el ejemplo de 10% frente a 27% cambia el disco frozen de 11,6 TB a 31,4 TB.
5. Tratar los snapshots de respaldo como searchable snapshots. Los snapshots regulares de datos hot y warm son backups y necesitan su propia capacidad de repositorio; el modelo no los incluye.

Tabla de decisión

Qué no cubre el modelo

• Cantidad de nodos, relaciones RAM-disco y CPU para indexación y búsqueda.
• Backups con snapshots regulares de datos hot, warm y cold regular.
• El comportamiento de los watermarks por nodo, la ubicación desigual de shards y el tope de max-headroom de 200 GB.
• Picos de merges, translog y recuperación que requieren espacio extra de forma temporal.
• Costos de solicitudes al repositorio y throughput de restauración.

Fuentes

• Tiers de datos — documentación de Elastic.
• Searchable snapshots — documentación de Elastic: montaje completo frente a parcial, sin réplicas, valores predeterminados de la caché compartida, suscripción.
• Ajustes de asignación y enrutamiento de shards a nivel de clúster — referencia de Elasticsearch: watermarks y low.max_headroom.
• Dimensiona tus shards — documentación de Elastic.

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