Ajuste de las bases de datos: Técnicas de optimización

Document created by RSA Information Design and Development on Apr 19, 2018Last modified by RSA Information Design and Development on Apr 23, 2018
Version 3Show Document
  • View in full screen mode
 

En este tema se describen las técnicas de optimización para la base de datos de NetWitness Core. La base de datos de NetWitness 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 vista Navegar de NetWitness Suite. Los umbrales se aplican a la llamada values . 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 el 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 NetWitness 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.

                         
Operación Costo
exists, !exists Constante
= , != 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 , contains Lineal en términos de cantidad de valores únicos para la clave de metadatos
regex Lineal 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 AND 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 , la carga de trabajo para la consulta es menor. Del mismo modo, cada cláusula OR crea un conjunto de sesiones más grande para procesar en cada consulta.

Como regla general, mientras más cláusulas AND haya en la consulta, esta se completará con mayor rapidez; por otra parte, mientras más cláusulas OR haya en la consulta, esta se completará con mayor lentitud.

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 a partir del hecho de 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 elementos de 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 elementos de metadatos en la red de clave de metadatos 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" 

Siempre y cuando haya un índice value-level 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 gran cantidad 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 , regex se debe ejecutar de manera independiente contra cada valor único.

Para solucionar esto, la estrategia más eficaz es reorganizar los elementos de 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 la siguiente:

 url contains 'www.rsa.com' 

En este escenario, es probable que la clave de metadatos url contenga un valor único para cada sesión que capturó el Decoder y, por lo tanto, tenga 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 con los cuales se intenta encontrar una coincidencia y mover la coincidencia al analizador de contenido.

Por ejemplo, si se generan metadatos 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/netwitness , también podría generar metadatos 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 NetWitness Suite 10.5 e instalaciones posteriores, se realiza un guardado en el índice principal 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 NetWitness Suite, o los sistemas que se actualizaron de versiones de NetWitness Suite anteriores a 10.5, utilizan un programa de guardado basado en tiempo que guarda el índice cada 8 horas. Puede ver el intervalo de guardado actual mediante el uso del editor del programador en la interfaz del usuario de NetWitness Admin 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 los índices. 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 valueMax

La limitación de valueMax 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 de valueMax mediante el uso de índices de nivel de clave en lugar de índices de valores. Los índices de nivel clave no reciben la influencia de valueMax .

Es posible usar la vista Navegar 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 values . 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.

En casos donde se alcanza valueMax , los usuarios pueden realizar un escaneo de la base de datos en sus consultas para asegurarse de que no se hayan descartado valores pertinentes. 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 Navegar de NetWitness Suite tiene la capacidad de ejecutar los componentes de su salida en paralelo, lo cual puede tener un impacto significativo en el rendimiento percibido del servicio NetWitness Core.

Reconstruir el índice

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

  • El servicio NetWitness 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 del í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 NetWitness 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 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 /index/stats/time.begin para mostrar el tiempo de sesión más antiguo que almacena.

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 NetWitness 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 Archivers tienen la capacidad de incorporarse a clústeres mediante la agregación de grupos. La agregación de grupos permite que un solo Decoder alimente sesiones a múltiples Concentrators o Archivers de manera que la carga sea equilibrada. 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 NetWitness 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 NetWitness Core puede manejar ese caso de uso, pero lo hace lentamente porque debe alternar entre tener distintos períodos en la 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 NetWitness Suite funcione para el cliente, es importante hacer que este organice sus usuarios en grupos que tienden 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 los distintos casos de uso se pueden distribuir entre distintos elementos de hardware de Concentrator, el rendimiento percibido puede ser mucho mejor. En este caso, puede ser beneficioso utilizar más servicios 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 avanza en incrementos de la cantidad de minutos en esta configuración.

Por ejemplo, suponga que /sdk/config/cache.window.minutes es 10\. La reevaluación de 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 NetWitness Core durante un período muy largo, el servicio principal dedica más y más tiempo de CPU y 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