Base de datos Core: Almacenamiento de la base de datos en niveles

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

En este tema se describe el almacenamiento de base de datos en niveles y se proporcionan recomendaciones para el almacenamiento en niveles activo, semiactivo e inactivo.

A partir de la versión 10.4, el servicio Archiver se puede configurar para el uso de almacenamiento en niveles. El concepto de almacenamiento en niveles consiste en colocar los datos más recientes en un nivel activo, que es el almacenamiento más rápido disponible en Archiver.

Nota: De forma predeterminada, todos los servicios usan el nivel activo.

El nivel siguiente se conoce como semiactivo y suele ser almacenamiento más económico y más lento, como el almacenamiento conectado en red (NAS). El nivel semiactivo contiene datos más antiguos; la antigüedad depende del volumen de almacenamiento que se asigna en el nivel activo y de la tasa recopilación promedio. Cuando el nivel activo alcanza la utilización máxima, la progresión natural es transferir los datos más antiguos del nivel activo al nivel semiactivo. Cuando se configura correctamente, esto sucede de manera automática y es invisible para el usuario final. Las consultas y el acceso a los datos suceden automáticamente sin importar el nivel (activo o semiactivo) en el cual residen los datos. Sin embargo, puede haber un impacto en el rendimiento cuando se accede a los datos en el nivel semiactivo en comparación con el nivel activo, debido a que los tiempos de acceso en el nivel semiactivo suelen ser más lentos.

Además de los niveles activo y semiactivo, también hay un nivel inactivo. El nivel inactivo solo se usa como portapapeles para el respaldo offline. Los servicios Security Analytics Core no acceden a datos en el nivel inactivo. Los servicios Security Analytics Core transfieren los datos más antiguos al nivel inactivo y los consideran abandonados (el servicio ya no accede a ellos). Posteriormente, estos datos se pueden respaldar en almacenamiento a largo plazo, como cinta, para una posible restauración meses o incluso años después, en función de los requisitos. El respaldo y la posterior eliminación de los datos en el nivel inactivo se deben manejar fuera de los servicios Security Analytics Core mediante scripts u otros procesos.

Precaución: Si el nivel inactivo se llena debido a que los procesos externos no están quitando los datos a tiempo, el servicio Security Analytics Core detiene finalmente la recopilación de nuevos datos hasta que se resuelve el problema.

Cuando los datos se transfieren al nivel inactivo, RSA recomienda que el directorio permanezca en el mismo punto de montaje de origen de la transferencia. Por lo tanto, si los archivos provienen del nivel semiactivo, es mucho mejor, por motivos de rendimiento, configurar el directorio del nivel inactivo en el mismo sistema de archivos. La razón de esto es que el servicio intenta transferir simplemente el archivo y el directorio al nivel inactivo, lo cual es una operación casi instantánea en el mismo sistema de archivos. Si la transferencia falla, el último recurso es copiar los datos al nivel inactivo, lo cual conlleva un mayor tiempo de procesamiento y causa una contención adicional de I/O en el nivel de origen de la copia.

Archiver

Archiver usa los niveles de funcionalidades de almacenamiento. Puede configurar Archiver de modo que use solo el almacenamiento activo (el valor predeterminado), el almacenamiento activo y semiactivo o los tres (activosemiactivo e inactivo). Todos los servicios deben usar el almacenamiento activo. No puede configurar un servicio para que solo use el almacenamiento semiactivo. Los datos fluyen desde el almacenamiento activo al semiactivo y, finalmente, al inactivo. También puede omitir el almacenamiento semiactivo y pasar del activo al inactivo. Si el almacenamiento inactivo (offline) no está configurado, los datos más antiguos se eliminan en el último nivel configurado. Este ha sido el procedimiento operativo estándar.

La implementación típica de Archiver configura todas las bases de datos en un tamaño ilimitado (packet.dir, meta.dir, session.dir, index.dir y opcionalmente las variantes del nivel semiactivo), lo cual significa que el especificador de tamaño se deja desactivado o se configura en cero. Esto permite que las bases de datos y el índice crezcan sin límites. En lugar de que cada base de datos administre su propio tamaño y se implemente solo cuando cada una supere su tamaño configurado, Archiver implementa todos los elementos juntos mediante el comando /index sizeRoll. Esto permite que las bases de datos y el índice se implementen simultáneamente. Para obtener más información acerca de sizeRoll, consulte Transferencia asíncrona en Rollover.

Generalmente, Archiver está configurado para colocar las bases de datos de índice, sesión, metadatos y paquetes (registro) en el mismo volumen en lugar de múltiples volúmenes, como sucede con Concentrator o Decoder. Aunque esto puede causar una mayor contención de I/O cuando se producen lecturas simultáneas en múltiples bases de datos, también maximiza la retención general. Debido a que todas las bases de datos están en el mismo volumen, están configuradas para implementarse juntas, lo cual minimiza la orfandad de los datos. Decoder y Concentrator están configurados para una velocidad máxima de I/O, pero puede ser difícil calcular el dimensionamiento correcto de los volúmenes.

Por ejemplo, si la base de datos de sesión es demasiado grande, puede tener almacenamiento suficiente para seis meses de retención, mientras que la base de datos de metadatos y el índice solo tienen retención para cuatro meses. Debido a que la base de datos de sesión y de metadatos y el índice están intrínsecamente vinculados, el período de retención más breve para los tres define el período de retención general (en este caso, cuatro meses). La retención de bases de datos individuales se ve afectada principalmente por factores que escapan a nuestro control, como el tráfico capturado, los metadatos generados (analizadores, feeds y reglas) y el filtrado. Las bases de datos se redimensionan fácilmente con un simple cambio en la configuración, pero esto suele implicar cambios en el nivel de hardware y del sistema de archivos para ajustar las particiones, lo cual complica el redimensionamiento dinámico. Archiver evita estos problemas mediante el uso de un único volumen para todo, con la desventaja de una velocidad de I/O algo más lenta.

Next Topic:Manifiestos
You are here
Table of Contents > Configuración básica de la base de datos > Almacenamiento de la base de datos en niveles

Attachments

    Outcomes