Calculadora de dimensionamiento de Splunk

Ejemplo resuelto: Splunk RF3 / SF2

Ejemplo ilustrativo Un clúster de indexers que recibe 200 GB/día de datos previos a la indexación, los conserva 90 días, con Replication Factor 3, Search Factor 2 y un margen de crecimiento de 25%. Almacenamiento clásico (sin SmartStore), proporciones predeterminadas. Abre este escenario.

Por qué 0,5 × RF es incorrecto cuando RF ≠ SF

El atajo P × 0,5 × RF asume que cada copia del bucket lleva tanto rawdata como archivos de índice. En un clúster de indexers solo las copias consultables llevan archivos de índice, de modo que el atajo supone en silencio que SF = RF. Para este escenario produce 33,8 TB, exactamente la respuesta de RF3/SF3, en lugar de 25,9 TB: 30% más de disco del que RF3/SF2 realmente necesita. Las dos fórmulas solo coinciden cuando SF es igual a RF.

Verificación con el ejemplo documentado de Splunk

Los requisitos de clústeres de indexers de Splunk usan 100 GB de datos de syslog con RF 3 y SF 2: cerca de 15% de rawdata × 3 copias más cerca de 35% de archivos de índice × 2 copias consultables. El motor lo reproduce sin margen de crecimiento: 45 GB de rawdata + 70 GB de archivos de índice = 115 GB. Abre este escenario.

La estimación de indexers para el ejemplo resuelto es de 3 peers: nunca baja de RF, porque RF 3 necesita tres peers para ubicar tres copias de cada bucket.

Escenarios de referencia

Escenario de referencia Cada fila la calcula el mismo motor de la calculadora de arriba y se abre con sus datos de entrada ya cargados; son puntos de referencia para comparar, no tamaños recomendados. Todas usan las proporciones predeterminadas de 15% de rawdata y 35% de archivos de índice y un margen de crecimiento de 25%.

Las dos filas grandes contienen los mismos datos. El almacenamiento clásico conserva un año de rawdata en tres copias y de archivos de índice en dos: 524,7 TB de disco local. SmartStore conserva una copia de los warm buckets en el object store (227,5 TB con crecimiento) y solo la caché más los hot buckets replicados en local (19,6 TB). SmartStore no hace más pequeños los datos; traslada la cola larga desde disco local replicado a una única copia remota.

Decisiones de dimensionamiento

RF frente a SF

El Replication Factor es la disponibilidad de los datos: con RF 3 el clúster conserva tres copias de cada bucket y puede perder dos peers sin perder datos. El Search Factor es la disponibilidad de la búsqueda: solo las copias consultables llevan archivos de índice, así que SF decide cuántos peers pueden fallar antes de que algunos buckets necesiten reconstruir sus archivos de índice a partir del rawdata para volver a ser consultables.

El costo de almacenamiento de cada uno es distinto. En el ejemplo resuelto, una copia RF adicional suma 2,7 TB de rawdata (P × 0,15); una copia SF adicional suma 6,3 TB de archivos de índice (P × 0,35), ambos antes del crecimiento. Los archivos de índice son la parte mayor, por eso SF mueve el total más que RF.

SF menor que RF

Pasar de RF3/SF3 a RF3/SF2 en el ejemplo resuelto reduce el almacenamiento recomendado de 33,8 TB a 25,9 TB, un ahorro de 7,88 TB. El costo es la recuperación: cuando se pierde una copia consultable, el clúster tiene que construir archivos de índice sobre una copia no consultable restante, lo que toma tiempo y CPU/IO de los indexers mientras los resultados de búsqueda de esos buckets están incompletos. SF = RF es la elección cuando importa más el tiempo de recuperación que el disco; SF < RF cuando domina el disco y se acepta una recuperación de búsqueda más lenta. Ninguna es mejor en todos los casos.

SmartStore

Con SmartStore, los hot buckets permanecen en local y siguen RF/SF. Cuando un bucket pasa a warm, se sube una sola vez al object store remoto; los peers mantienen una caché local de los buckets usados recientemente y obtienen el resto bajo demanda. El dimensionamiento cambia de tres maneras: el disco local sigue la ventana de caché y no la retención, el object store sigue la retención menos la ventana hot con una sola copia, y la ventana hot sigue necesitando copias RF/SF en local. La guía de dimensionamiento de SmartStore explica el dimensionamiento de la caché en detalle.

Errores comunes

1. Usar 0,5 × RF para todos los clústeres. Equivale a la respuesta con RF = SF. Con RF3/SF2 en el ejemplo resuelto sobrestima el almacenamiento en 30% (33,8 TB en lugar de 25,9 TB).
2. Dimensionar la caché de SmartStore con toda la retención. Ejemplo ilustrativo Para 1 TB/día conservado 365 días con RF3/SF2, una caché de 365 días pide 228,9 TB de disco local; una caché de 30 días necesita 19,6 TB, es decir, 11,7× menos. Los requisitos de SmartStore de Splunk sugieren unos 30 días de datos indexados, al menos 7–10 días y unos 90 días con Enterprise Security (57,1 TB aquí). Abre el escenario con caché de 365 días.
3. Olvidar la replicación de los hot buckets en SmartStore. Los hot buckets todavía no están en el object store, así que conservan en local RF copias de rawdata y SF copias de archivos de índice. En el escenario de referencia de 1 TB/día con RF3/SF2, una ventana hot de un día suma 650 GB de copias de réplica sobre la caché, antes del crecimiento. Las ventanas hot más largas lo escalan de forma lineal.
4. Confundir el volumen licenciado con la ingesta real. Una licencia es un derecho, no una medición. Ejemplo hipotético Dimensionar un clúster RF2/SF2 a 90 días desde una licencia de 500 GB/día cuando el volumen medido es de 320 GB/día da 56,3 TB en lugar de 36 TB: 56% de más. Usa el uso diario de licencia medido y mira también los días pico, no solo el promedio.
5. Asumir un único factor de compresión para todas las fuentes. Splunk presenta 15% / 35% como una referencia para syslog que varía según la fuente. Ejemplo hipotético El ejemplo resuelto pasa a 18 TB si una fuente se comprime a 10% de rawdata y 25% de archivos de índice, y a 32,6 TB si los archivos de índice llegan a 50%. Mide tu propia proporción por índice (por ejemplo, compara el tamaño en disco de los buckets de | dbinspect con el tamaño sin procesar) e ingrésala en el modo Experto.

Cómo se calcula el dimensionamiento de Splunk

Todos los volúmenes usan unidades decimales (1.000 GB = 1 TB). P es el volumen previo a la indexación que se conserva durante el período de retención.

Almacenamiento clásico en indexers

P           = ingesta diaria × días de retención
rawdata     = P × proporción de rawdata (0,15) × RF
index       = P × proporción de archivos de índice (0,35) × SF
recomendado = (rawdata + index) × (1 + crecimiento)

SmartStore

indexado/día    = ingesta diaria × (0,15 + 0,35)
caché local     = indexado/día × días de caché (predeterminado 30)
réplicas hot    = ingesta diaria × días hot × (0,15 × (RF − 1) + 0,35 × (SF − 1))
local           = (caché + réplicas hot) × (1 + crecimiento)
object store    = indexado/día × (retención − días hot) × (1 + crecimiento)   una copia

Supuestos y límites

• Las proporciones de 15% / 35% son la referencia documentada de Splunk para syslog; ambas son editables en el modo Experto.
• El crecimiento se aplica después de las copias, por lo que el margen escala con la huella que realmente aprovisionas.
• La cantidad de indexers es una heurística de planificación de ObservKit (unos 300 GB/día por indexer de referencia, nunca menos peers que RF), no una guía de dimensionamiento de Splunk. No se modelan la concurrencia de búsquedas, la aceleración de data models ni las apps premium.
• No se modela: la división de volumen entre hot/warm y cold, los clústeres multisite, los summary indexes y los data models acelerados, el overhead del SO y del sistema de archivos, ni los derechos de Splunk Cloud.

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