Dimensionamiento de Splunk SmartStore

En resumen

• Disco local ≈ días de caché × indexado/día + hot buckets replicados, y luego el crecimiento. La retención no aparece.
• Object store ≈ indexado/día × (retención − ventana hot), una copia, y luego el crecimiento.
• En el ejemplo ilustrativo de abajo (250 GB/día, RF2/SF2, caché de 30 días), el disco local es de 4,84 TB ya sea que conserves 90 días o un año; solo crece el object store (13,9 TB frente a 56,9 TB).

Dónde viven los datos

El cache manager desaloja los buckets usados hace más tiempo cuando la caché se llena, así que la caché es un conjunto de trabajo, no un archivo. Una búsqueda sobre buckets que no están en caché los descarga primero del almacén remoto.

La caché no es retención

Los requisitos de SmartStore de Splunk recomiendan almacenamiento local para unos 30 días de datos indexados, al menos 7–10 días porque la mayoría de las búsquedas apuntan a datos recientes, y unos 90 días con Enterprise Security.

Escenario de referencia 1 TB/día, RF3/SF2, conservado 365 días:

Una caché dimensionada igual que la retención renuncia al principal beneficio de SmartStore: el disco local termina cerca de una copia completa de cada bucket. Dimensiona la caché según la ventana de búsqueda que realmente usan tus usuarios y tus búsquedas programadas. Splunk también advierte que la caché comparte partición con el sistema operativo, los binarios y los artefactos de búsqueda, que también deben caber.

Ejemplo resuelto: 250 GB/día, RF2/SF2, 90 días

Ejemplo ilustrativo datos de entrada elegidos para comparar con el escenario clásico mediano.

Los mismos datos en almacenamiento clásico necesitan 28,1 TB de disco en los indexers. Abre este escenario en Splunk · Abre la versión clásica.

Clásico frente a SmartStore

Ejemplo ilustrativo los mismos 250 GB/día con dos retenciones.

El almacenamiento clásico crece con la retención sobre disco rápido y replicado. SmartStore mantiene constante el disco local y hace crecer una única copia remota. Cuanto mayor es la retención respecto de la ventana de búsqueda, mayor es la diferencia.

Advertencia de Enterprise Security

Los requisitos de Splunk piden unos 90 días de datos indexados en caché con Enterprise Security, cuyas búsquedas de correlación y data models acelerados suelen leer más atrás que las búsquedas ad hoc. Para 1 TB/día con RF3/SF2 eso es 57,1 TB de almacenamiento local en lugar de 19,6 TB. Si ES corre en el clúster, empieza con la caché en 90 días y redúcela solo con evidencia del comportamiento de cache hits.

Cuándo conviene SmartStore

• Retención larga, ventana de búsqueda corta. Se conserva un año, se buscan 30 días: el disco local se mantiene en el tamaño de la caché.
• Almacenamiento de objetos con throughput adecuado cercano a los indexers, ya que cada cache miss descarga buckets completos.
• Cantidad de indexers elástica. Agregar o reemplazar peers no obliga a copiar entre ellos todos los datos retenidos.

Encaja peor cuando las búsquedas abarcan de forma habitual toda la retención (la mayoría se convierten en descargas), cuando la retención ya es corta (la caché igualaría a la retención) o cuando no hay un object store adecuado. En Splunk Cloud Platform, SmartStore lo administra Splunk, por lo que este dimensionamiento aplica a Splunk Enterprise.

Errores comunes

1. Caché = retención. 228,9 TB de disco local en lugar de 19,6 TB en el ejemplo de 1 TB/día: 11,7× más.
2. Ignorar las réplicas de hot buckets. Los hot buckets siguen RF y SF en local: 650 GB por día de ventana hot con 1 TB/día y RF3/SF2.
3. Replicar el object store en la estimación. Los warm buckets existen una sola vez en el almacén remoto; aplicarle RF triplica el object store con RF3.
4. Usar el valor de 30 días pensado para clústeres sin ES con Enterprise Security. Las búsquedas que no encuentran datos en caché descargan buckets y vuelven lentas las búsquedas de correlación.
5. Olvidar los datos que no son buckets en la partición de la caché. El SO, los binarios de Splunk y los artefactos de búsqueda la comparten.

Limitaciones

• Una sola ventana hot para todo el clúster; la vida real de un hot bucket depende del tamaño del bucket y de los ajustes de roll.
• No se modelan los ajustes de caché por índice, las políticas de desalojo ni los tamaños de bucket.
• Los costos de solicitudes del object store, el egress y la replicación dentro del propio object store quedan fuera de la estimación.
• No se modelan clústeres multisite ni los derechos de Splunk Cloud.

Fuentes

• Descripción general de la arquitectura de SmartStore — documentación de Splunk Enterprise, 10.2.
• Requisitos del sistema de SmartStore — documentación de Splunk, 10.2: 30 días, mínimo de 7–10 días, 90 días con Enterprise Security, partición de caché compartida.
• Requisitos del sistema y otras consideraciones de despliegue para clústeres de indexers — documentación de Splunk Enterprise, 10.6: proporciones de rawdata y de archivos de índice.
• Buckets y clústeres de indexers — documentación de Splunk Enterprise, 10.2.

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