Base de datos Core: Técnicas de optimización

Document created by RSA Information Design and Development on Feb 9, 2017
Version 1Show Document
  • View in full screen mode
  

En este tema se describen las técnicas de optimización para la base de datos de Security Analytics Core. La base de datos de Security Analytics Core está configurada para trabajar con una amplia gama de cargas de trabajo de manera predeterminada. Sin embargo, como cualquier tecnología de base de datos, su rendimiento puede ser muy sensible tanto a la naturaleza de los datos recopilados, como a la naturaleza de las búsquedas que realiza el usuario en la base de datos.

Límites

Los umbrales son una optimización útil que puede tener un efecto drástico en la velocidad con la que se devuelven resultados a la herramienta de navegación de Security Analytics. Los umbrales se aplican a la llamada de valores. Para obtener más información acerca de la llamada values, consulte Consultas.

El umbral define un límite de cuánto se recupera de la base de datos desde disco con el fin de producir un conteo. Para la mayoría de las consultas, la cantidad de sesiones que coinciden con la cláusula Where es muy grande. Por ejemplo, si se seleccionan todos los eventos de registro para solo una hora mientras se ejecutan 30,000 eventos por segundo, las coincidencias son 108,000,000 sesiones.

RSA introdujo la función de umbral basándose en la observación de que en la mayoría de los casos en que se requiere un conteo de sesiones, no es necesario tener resultados que sean precisos hasta la última sesión. Por ejemplo, cuando se observan las 20 principales direcciones IP presentes en la última hora, no es muy importante si el informe indica que un valor IP coincidió exactamente con 10,000,000 o 10,000,001 sesiones. El estimado es suficiente. En estos escenarios, podemos realizar un estimado para el valor del conteo devuelto cuando nuestro conteo excede el parámetro de umbral. Cuando se alcanza el umbral, el conteo restante se estima y los resultados se ordenan basados en los conteos estimados, si es necesario.

Cláusulas Where complejas

La cantidad de tiempo que tarda la base de datos de Security Analytics Core en producir un resultado depende de la complejidad de la consulta. Las consultas que se alinean directamente con los índices presentes en los metadatos se pueden resolver rápidamente, pero es muy común escribir consultas que no se puedan resolver rápidamente. En ocasiones, las consultas que no se pueden devolver rápidamente se pueden procesar mediante la base de datos de Core y el índice de manera distinta para producir resultados mucho más satisfactorios para el cliente.

Es útil conocer el costo relativo de cada parte de la cláusula Where. Una cláusula con un costo alto tarda más en ejecutarse. En la siguiente tabla, las operaciones de consulta se ordenan en términos de su costo relativo, del más bajo al más alto.

                               
OperationCosto
exists, !existsConstante
=, !=Logarítmico en términos de la cantidad de valores únicos para la clave de metadatos, lineal en términos de la cantidad de elementos únicos que coinciden con una expresión de rango
<, >, <=, >=Logarítmico en términos de búsqueda de valores únicos, pero lo más probable es que sea lineal, ya que la expresión coincide con un gran rango de valores
begins, ends, containsLineal en términos de cantidad de valores únicos para la clave de metadatos
regexLineal en términos de cantidad de valores únicos para la clave de metadatos con un costo alto por valor

AND y OR

Cuando se crea una cláusula Where, tenga en mente que crear muchos términos con el operador Y puede tener una consecuencia benéfica en el rendimiento de una consulta. Siempre que se puedan usar múltiples criterios para filtrar el conjunto de sesiones que coinciden con la cláusula Where, hay menos trabajo que hacer para la consulta. Del mismo modo, cada cláusula OR crea un grupo de sesiones más grande para procesar por cada consulta.

Como regla general, mientras más cláusulas AND haya en la consulta, más rápido será su proceso de completado; por otra parte, mientras más cláusulas OR haya en la consulta, más lento será su proceso de completado.

Caso de uso: Coincidencia con una subred grande

Es que los usuarios creen consultas que intenten incluir o excluir una subred de clase A. Este tipo de consulta es común debido a que los usuarios intentan incluir o excluir una gran parte de su red interna de su investigación.

Resolver esta consulta con los índices ip.src o ip.dst solamente es un problema para el motor de consultas. El problema surge desde el hecho que una cláusula Where como esta:

 ip.src = 10.0.0.0/8 

En realidad se debe interpretar así:

 ip.src = 10.0.0.0 || ip.src = 10.0.0.1 || ip.src = 10.0.0.2 || ... || ip.src = 10.255.255.255 

Por lo tanto, el índice podría tener que crear una cláusula Where con más de 16 millones de términos.

La solución a este problema es usar el Decoder para etiquetar redes de interés comunes mediante reglas de aplicación. Por ejemplo, podría crear metadatos con una regla de aplicación que se vea así:

 name=internal rule="ip.src = 10.0.0.0/8" order=3 alert=network 

Esta regla crea metadatos en la red clave con el valor interno para cualquier dirección IP en la red 10.0.0.0/8.

La cláusula Where se podría expresar como:

 network = "internal" 

Asumiendo que hay un índice de nivel de valor en los metadatos de red, el índice no tiene que expandir esta consulta en nada más complejo y las sesiones coincidentes con la subred deseada coinciden muy rápidamente.

Caso de uso: Coincidencias de subcadena

Usar los operadores begins, ends, contains y regex en una cláusula Where puede ser muy lento si hay una cantidad grande de valores únicos para la clave de metadatos. Cada uno de estos operadores se evalúa de manera independiente contra cada valor único. Por ejemplo, si el operador es regex, el regex se debe ejecutar de manera independiente contra cada valor único.

Para solucionar esto, la estrategia más eficaz es reorganizar los metadatos de manera que el usuario no tenga que usar una coincidencia de subcadena.

Por ejemplo, suponga que los usuarios intentan encontrar el nombre de host en una URL en algún lugar de la sesión. Los usuarios pueden escribir una cláusula Where como:

 url contains 'www.rsa.com' 

En este escenario, es probable que la clave de metadatos de la URL contenga un valor único para cada sesión que capturó el Decoder y, por lo tanto, tiene una gran cantidad de valores únicos. En este caso, la operación contains es lenta.

El mejor enfoque es identificar la parte de los metadatos que está intentando coincidir y mover la coincidencia al analizador de contenido.

Por ejemplo, si hay metadatos generados para cada URL, un analizador también podría desglosar la URL en sus componentes constitutivos. Por ejemplo, si el Decoder genera metadatos de URL con el valor http://www.rsa.com/security_analytics, también podría generar metadatos de alias.host con el valor www.rsa.com. Se pueden realizar consultas mediante:

 alias.host = 'www.rsa.com' 

Debido a que el operador de subcadena ya no es necesario, la consulta es mucho más rápida.

Guardados del índice

El índice de Core se subdivide en puntos de guardado, también conocidos como segmentos. Cuando se guarda el índice, todos los metadatos del índice se envían al disco y esa parte del índice se marca como de solo lectura. Los guardados cumplen dos funciones:

  • Cada punto de guardado representa un lugar donde el índice se puede recuperar en el caso de una falla en la energía.
  • El guardado periódico garantiza que la parte del índice que se está actualizando activamente no crezca más que la memoria RAM.

Los puntos de guardado tienen el efecto de particionar el índice en segmentos independientes y que no se sobreponen. Cuando una consulta debe cruzar múltiples puntos de guardado, debe volver a ejecutar las partes de la consulta y combinar los resultados. En última instancia, esto hace que la consulta se demore más en completarse.

De manera predeterminada, para Security Analytics 10.5 e instalaciones posteriores, se realiza un guardado en el índice de Core cada vez que se agregan 600,000,000 sesiones a la base de datos. Este intervalo se configura mediante el parámetro de configuración del índice save.session.count. Para obtener más información, consulte Nodos de configuración de índices.

Las versiones anteriores de Security Analytics Core, o los sistemas que se actualizaron desde las versiones de Security Analytics anteriores a 10.5, usan un programa de guardado basado en tiempo que guarda el índice cada ocho horas. Puede ver el intervalo de guardado actual mediante el uso del editor del programador en la interfaz del usuario de Security Analytics Administration para el servicio. La entrada predeterminada tiene la siguiente apariencia:

 hours=8 pathname=/index msg=save 

Si ajusta el intervalo, puede controlar la frecuencia con la que se crean los guardados.

Efectos de aumentar el intervalo de guardado

Si se aumenta el intervalo de guardado, se crean puntos de guardado de manera menos frecuente y, por lo tanto, existen menos puntos de guardado. Esto tiene un efecto positivo en el rendimiento de la consulta, ya que se hace menos probable que las consultas recorran segmentos, y cuando sí es necesario recorrer los segmentos, no hay tantos que se deban cruzar.

De todas formas, existen inconvenientes si se aumenta el intervalo de guardado. Primero, es más probable que Concentrator alcance el límite de valueMax establecido en cualquiera de las incidencias. Segundo, se aumenta el tiempo de recuperación en caso de que se produzca un apagado forzado o una falla en la energía. Y tercero, la tasa de agregación puede verse afectada si el segmento del índice crece demasiado como para caber en la memoria.

Efectos de disminuir el intervalo de guardado

Si se disminuye el intervalo de guardado, es posible evitar alcanzar los límites de valueMax mientras se mantiene un índice de valores completos para metadatos que contienen una gran cantidad de valores únicos. Si disminuye el intervalo de guardado no hay un impacto perjudicial en el rendimiento de consultas, ya que se crean más segmentos.

Trabajo con el valor máximo

La limitación del valor máximo puede ser frustrante para los clientes que deseen indexar todos los metadatos únicos posibles. Desafortunadamente, eso no es posible en el caso general. Existen claves de metadatos que pueden tener datos aleatorios arbitrarios desde cualquier lugar de Internet y no se pueden indexar todos los valores únicos.

Sin embargo, es posible solucionar algunas de las limitaciones del valor máximo mediante el uso de índices de nivel de clave en lugar de índices de valores. Los índices de nivel clave no reciben la influencia del valor máximo.

Es posible usar la vista Navegación en una clave de metadatos indexada en el nivel de clave. La base de datos usa índices de nivel de valor en la cláusula Where cuando es posible, pero se utiliza el escaneo de la base de datos de metadatos para resolver valores únicos para la llamada de valores. Este enfoque funciona bien cuando la cláusula Where proporciona un filtro eficaz para limitar el alcance de búsqueda a una pequeña cantidad de sesiones, tal vez menos de 10,000 sesiones.

En casos donde se alcanza el valor máximo, los usuarios pueden realizar un escaneo de la base de datos en sus consultas para asegurarse de que no se desecharon valores relevantes. Esta función es accesible en el cliente de Investigator 9.8 mediante el menú del botón secundario en la vista Navegación. Aunque el escaneo de la base de datos de metadatos tarda bastante, garantiza al cliente que no se está perdiendo nada en sus informes.

Paralelizar cargas de trabajo

Cuando el cliente está utilizando varios informes, asegúrese de que no esté haciendo uso completo de las opciones de ejecución paralela en Reporting Engine. Del mismo modo, asegúrese de que la cantidad de max.concurrent.queries sea adecuada para el hardware.

La vista Navegador de Security Analytics tiene la capacidad de ejecutar los componentes de la vista Investigator en paralelo, lo cual puede tener un impacto significativo en el rendimiento percibido del servicio Security Analytics Core.

Reconstruir el índice

En casos aislados, un servicio Core se puede beneficiar producto de una reconstrucción del índice. Ejemplos:

  • El servicio Security Analytics Core tiene segmentos de índice creados con una versión muy antigua del producto y no ha transferido ningún dato en más de seis meses.
  • El índice se configuró de manera incorrecta y el cliente desea volver a indexar todos los metadatos con una nueva configuración de índice.
  • La carga de tráfico en el servicio Core era muy ligera y el intervalo de guardado era grande, lo cual provocó la generación de más segmentos de los necesarios.

En estos casos, una reconstrucción de índice puede proporcionar mejoras de rendimiento. Para hacerlo, debe enviar el mensaje reset con el parámetro index=1 a la carpeta /decoder en un Decoder, la carpeta /concentrator en un Concentrator o la carpeta /archiver en un Archiver.

Tenga en cuenta que una reindexación completa tarda días en completarse en un Concentrator completamente cargado y posiblemente semanas en un Archiver lleno.

Escalamiento de retención

Existen varias formas de mejorar la retención de la base de datos de Security Analytics Core. Retención hace referencia al período que cubren los datos almacenados en la base de datos.

El primer paso para analizar la retención es determinar qué parte de la base de datos es el factor limitante en términos de retención. Las bases de datos de paquetes, metadatos y sesiones proporcionan las estadísticas de packet.oldest.file.time, meta.oldest.file.time y session.oldest.file.time en la carpeta /database/stats para mostrar la antigüedad del archivo más antiguo en la base de datos. El índice proporciona la estadística de /index/stats/time.begin para mostrar el tiempo de sesión más antiguo almacenado en el índice.

Aumentar la retención de paquetes y metadatos

El mecanismo primario para aumentar la retención en estas bases de datos es agregar más almacenamiento. Si no es posible agregar más almacenamiento al servicio Security Analytics Core, puede que sea necesario utilizar las opciones de compresión en la base de datos de paquetes y metadatos para disminuir la cantidad de datos que escribe cada base de datos.

Si la retención de metadatos es una preocupación, es posible que desee eliminar el contenido innecesario del Decoder que genera metadatos. Muchos analizadores generan metadatos que el cliente no necesita almacenar a largo plazo.

Aumentar la retención del índice

Normalmente, el índice no tiene más retención que las bases de datos, pero con un índice personalizado complejo, la retención del índice puede ser más corta. Normalmente, el curso de acción más fácil es eliminar los índices de nivel de valor innecesarios de la configuración personalizada o tal vez reemplazar algunos de los índices de nivel de valor predeterminados por índices de nivel de clave.

También es posible escalar el índice mediante la adición de almacenamiento del índice adicional. Sin embargo, el almacenamiento del índice se debe extender solo mediante el uso de unidades de estadio sólido.

Escalar de manera horizontal

A partir de la versión 10.3, los Concentrators y los Archivers tienen la capacidad de agruparse en clústeres mediante la agregación de grupos. La agregación de grupos permite que un único Decoder alimente sesiones a múltiples Concentrators o Archivers de manera que la carga sea balanceada. La agregación de grupos permite que la consulta y la carga de trabajo de agregación se dividan en un pool arbitrariamente grande de hardware.

Para obtener más información, consulte el tema Agregación de grupos de la Guía de implementación.

Cargas de trabajo de grupos

La base de datos de Security Analytics Core funciona mucho mejor cuando todos los usuarios del sistema están trabajando dentro de la misma región de la base de datos. Debido a que la base de datos se alimenta de datos del Decoder con un esquema de tipo el primero en entrar, el primero en salir, los datos en la base de datos normalmente se incorporan al clúster juntos según la hora en la que se capturaron y almacenaron. Por lo tanto, la base de datos funciona mejor cuando todos los usuarios están trabajando en el mismo período de datos.

No siempre es posible que todos los usuarios trabajen en el mismo período simultáneamente. La base de datos de Security Analytics Core puede manejar ese caso de uso, pero lo hace lentamente porque debe alternar entre tener distintos períodos en la memoria RAM. No es posible tener todos los períodos en la memoria RAM al mismo tiempo. Normalmente menos del 1 % de la base de datos y menos del 10 % del índice caben en la memoria RAM.

Para hacer que Security Analytics funcione para el cliente, es importante que el cliente organice sus usuarios en grupos que tiendan a trabajar en los mismos rangos de tiempo. Por ejemplo, los usuarios que realizan un monitoreo diario de los datos más recientes pueden ser un grupo de usuarios. Tal vez existe otro grupo de usuarios que realiza consultas más atrás en el tiempo como parte de una investigación. Y tal vez otro grupo de usuarios realiza informes de períodos largos. Intentar servir a todos los grupos desde una base de datos simple puede llevar a frustración y esperas largas para que se produzcan resultados. Sin embargo, si se pueden esparcir los distintos casos de uso al hardware de un Concentrator distinto, el rendimiento percibido puede ser mucho mejor. En este caso, puede ser beneficioso utilizar más servicio de Concentrator con menos RAM y potencia de CPU que un Concentrator simple, grande y costoso diseñado para cumplir todas las necesidades.

Ventana de caché

Considere esta secuencia de eventos:

  1. A las 9:00 h, el usuario “kevin” inicia sesión en un servicio Concentrator y solicita un informe sobre la última hora de tiempo de recopilación.
  2. Concentrator recupera informes para el rango de tiempo entre las 8:00 h y las 9:00 h.
  3. A las 09:02 h, el usuario “scott” inicia sesión en el mismo Concentrator y además solicita un informe sobre la última hora de tiempo de recopilación.
  4. Concentrator recupera informes para el rango de tiempo entre las 8:02 h y las 9:02 h.

Tenga en cuenta que incluso cuando ambos usuarios observaban rangos de tiempo que se acercaban, el trabajo que realiza Concentrator para producir informes para Kevin no se podía volver a enviar a Scott, ya que los rangos de tiempo eran levemente distintos. Concentrator tuvo que volver a calcular la mayoría de los informes para Scott.

La configuración cache.window.minutes en el nodo /sdk le permite optimizar esta situación. Cuando un usuario inicia sesión, el punto en el tiempo que representa los datos más recientes para la recopilación solo avanzan en incrementos de la cantidad de minutos en esta configuración.

Por ejemplo, asuma que /sdk/config/cache.window.minutes es 10. Volver a evaluar la acción anterior cambia la secuencia de eventos.

  1. A las 9:00 h, el usuario “kevin” inicia sesión en un servicio Concentrator y solicita un informe sobre la última hora de tiempo de recopilación.
  2. Concentrator recupera informes para el rango de tiempo entre las 8:00 h y las 9:00 h.
  3. A las 09:02 h, el usuario “scott” inicia sesión en el mismo Concentrator y además solicita un informe sobre la última hora de tiempo de recopilación.
  4. Concentrator recupera informes para el rango de tiempo entre las 8:00 h y las 9:00 h.
  5. A las 09:10 h, el usuario “scott” vuelve a cargar los informes para la última hora del tiempo de recopilación.
  6. Concentrator recupera informes para el rango de tiempo entre las 8:10 h y las 9:10 h.

El informe devuelto en el paso 3 queda en la ventana de caché, de modo que se devuelve instantáneamente. Esto le da a Scott la impresión de que Concentrator es muy rápido.

De esta forma, una configuración más amplia de cache.window mejora el rendimiento percibido, con el costo de introducir pequeños retrasos hasta que los últimos datos estén disponibles para su búsqueda.

Límites de tiempo

Cuando se ejecuta una consulta en la base de datos de Security Analytics Core durante un período muy largo, el servicio Core dedica más y más tiempo de CPU y memoria RAM a esa consulta con el fin de hacer que se complete más rápido. Esto puede tener un impacto perjudicial en otras consultas y agregaciones. Para evitar que los usuarios con menos privilegios utilicen más que su parte de los recursos del servicio Core, es útil poner límites de tiempo en las consultas que ejecutan los usuarios normales.

You are here
Table of Contents > Técnicas de optimización

Attachments

    Outcomes