Compartir vía

Selección de una plataforma de Azure de destino para hospedar los datos históricos exportados

  • Artículo

Una de las decisiones importantes que toma durante el proceso de migración es dónde almacenar los datos históricos. Para tomar esta decisión, debe conocer las distintas plataformas de destino y ser capaz de compararlas.

En este artículo, se comparan las plataformas de destino en términos de rendimiento, costo, facilidad de uso y sobrecarga de administración.

Nota

Las consideraciones que se muestran en esta tabla solo se aplican a la migración de registros históricos y no a otros escenarios, como la retención a largo plazo.

Registros básicos/Archivo Azure Data Explorer (ADX) Azure Blob Storage ADX + Azure Blob Storage
Funcionalidades: • Aplicar la mayoría de las experiencias de registros de Azure Monitor existentes a un costo menor.
• Los registros básicos se conservan durante ocho días y, luego, se transfieren automáticamente al archivo (según el período de retención original).
• Utilizar trabajos de búsqueda para buscar eventos específicos en petabytes de datos.
• Para investigaciones profundas en un intervalo de tiempo, restaurar los datos desde el archivo. Luego, los datos quedan disponibles en la caché activa para su posterior análisis.		 • Tanto ADX como Microsoft Sentinel utilizan el Lenguaje de consulta Kusto (KQL), lo que le permite consultar, agregar o correlacionar datos en ambas plataformas. Por ejemplo, puede ejecutar una consulta de KQL de Microsoft Sentinel para combinar datos almacenados en ADX con datos almacenados en Log Analytics.
• Con ADX, tiene un control sustancial sobre la configuración y el tamaño de los clústeres. Por ejemplo, puede crear un clúster más grande para alcanzar un mayor rendimiento de la ingesta, o bien o crear un clúster más pequeño para controlar los costos.		 • El almacenamiento de blobs está optimizado para almacenar grandes cantidades de datos no estructurados.
• Ofrece costos competitivos.
• Adecuado para un escenario en el que una organización no clasifica por orden de prioridad la accesibilidad ni el rendimiento, como cuando la organización debe cumplir con requisitos de cumplimiento o auditoría.		 • Los datos se almacenan en un almacenamiento de blobs, que es bajo en costos.
• Puede utilizar ADX para consultar datos en KQL, lo que le permite acceder fácilmente a los datos. Información sobre cómo consultar datos de Azure Monitor con ADX
Facilidad de uso: Magnífico

Las opciones de archivo y búsqueda son fáciles de utilizar y se puede acceder a ellas desde el portal de Microsoft Sentinel. Sin embargo, los datos no quedan disponibles de inmediato para consultarlos. Para recuperar los datos, debe hacer una búsqueda. Esto puede tardar algún tiempo según la cantidad de datos que se van a examinar y devolver.		 Bueno

Muy fácil de usar en el contexto de Microsoft Sentinel. Por ejemplo, puede usar un cuaderno de Azure para visualizar los datos distribuidos entre Microsoft Sentinel y ADX. También puede consultar datos de AD desde el portal de Microsoft Sentinel mediante el proxy de ADX.		 Insuficiente

Con las migraciones de datos históricos, es posible que tenga que tratar con millones de archivos, por lo que la exploración de los datos se vuelve un desafío.		 Aceptable

Si bien el operador externaldata es muy complicado de utilizar con las grandes cantidades de blobs que se van a consultar, usar tablas externas de ADX elimina esta incidencia. La definición de tabla externa comprende la estructura de carpetas del almacenamiento de blobs y le permite consultar de manera transparente los datos que se incluyen en muchos blobs y carpetas diferentes.
Sobrecarga de administración: Completamente administrada

Las opciones de búsqueda y archivo están totalmente administradas y no agregan ninguna sobrecarga de administración.		 Alta

ADX es externo a Microsoft Sentinel, por lo que requiere supervisión y mantenimiento.		 Baja

Si bien esta plataforma requiere poco mantenimiento, al seleccionarla se agregan tareas de supervisión y configuración, como configurar la administración del ciclo de vida.		 Mediano

Con esta opción, podrá mantener y supervisar tanto ADX como Azure Blob Storage, ambos componentes externos a Microsoft Sentinel. Si bien ADX se puede apagar a veces, considere la sobrecarga de administración adicional que implica esta opción.
Rendimiento: Mediano

Por lo general, interactúa con registros básicos dentro del archivo mediante trabajos de búsqueda, una opción adecuada cuando quiere mantener el acceso a los datos, pero no necesita acceder inmediatamente a ellos.		 Alto a bajo

• El rendimiento de las consultas de un clúster de ADX depende del número de nodos que tenga el clúster, la SKU de la máquina virtual del clúster, la creación de particiones de datos, entre otros.
• El rendimiento mejora, con un costo agregado, a medida que agrega nodos al clúster.
• Si utiliza ADX, le recomendamos configurar el tamaño del clúster a fin de encontrar un equilibrio entre el rendimiento y el costo. Esta configuración depende de las necesidades de la organización, incluida la rapidez con la que debe completar la migración, la frecuencia con la que se accede a los datos y el tiempo de respuesta esperado.		 Baja

Ofrece dos niveles de rendimiento: Premium o Estándar. Si bien ambos niveles son una opción para el almacenamiento a largo plazo, el nivel Estándar es más rentable. Obtenga más información sobre los límites de escalabilidad y rendimiento.		 Baja

Como los datos residen en Blob Storage, esa plataforma limita el rendimiento.
Costo: Alta

El costo consta de dos componentes:
• Costo de ingesta. Cada GB de los datos que se ingieren en los registros básicos está sujeto a los costos de ingesta de registros de Azure Monitor y Microsoft Sentinel, los que suman aproximadamente USD 1/GB. Consulte los detalles de los precios.
• Costo de archivado. El costo de los datos en el nivel de archivo suma aproximadamente USD 0,02/GB al mes. Consulte los detalles de los precios.
Además de estos dos componentes del costo, si necesita acceso frecuente a los datos, se aplican costos adicionales al acceder a los datos a través de trabajos de búsqueda.		 Alto a bajo

• Como ADX es un clúster de máquinas virtuales, se le cobra en función del uso de las redes, el almacenamiento y el proceso, además de un margen de beneficio de ADX (consulte los detalles de los precios). Por lo tanto, cuantos más nodos agregue al clúster y más datos almacene, mayor será el costo.
• ADX también ofrece funcionalidades de escalado automático para adaptarse a la carga de trabajo a petición. ADX también puede aprovechar la ventaja de los precios de instancias reservadas. Puede hacer sus propios cálculos de costos en la calculadora de precios de Azure.		 Baja

Con una configuración óptima, Azure Blob Storage tiene los costos más bajos. Para aumentar la eficiencia y los ahorros de costos, se puede utilizar la administración del ciclo de vida de Azure Storage para colocar blobs antiguos en niveles de almacenamiento más baratos de manera automática.		 Baja

ADX solo actúa como proxy en este caso, por lo que el clúster puede ser pequeño. Además, el clúster se puede apagar cuando no sea necesario acceder a los datos y encenderlo solo cuando necesite acceder a ellos.
Cómo acceder a los datos: Trabajos de búsqueda Consultas de KQL directas Operador externaldata de KQL Consultas de KQL modificadas
Escenario: Acceso ocasional

Importante en escenarios en los que no es necesario ejecutar análisis intensivos o desencadenar reglas de análisis y solo necesita acceder a los datos de manera ocasional.		 Acceso frecuente

Importante en escenarios en los que necesita acceder a los datos con frecuencia y controlar cómo se ajusta y configura el clúster.		 Cumplimiento/auditoría

• Óptimo para almacenar grandes cantidades de datos no estructurados.
• Importante en escenarios en los que no se necesita un acceso rápido a los datos ni tampoco un alto rendimiento, como para fines de cumplimiento o auditoría.		 Acceso ocasional

Importante en escenarios en los que desea aprovechar la ventaja del bajo costo de Azure Blob Storage y mantener un acceso relativamente rápido a los datos.
Complejidad: Muy baja Media Bajo Alto
Preparación: Disponibilidad general GA GA Disponibilidad general

Consideraciones generales

Ahora que conoce más de las plataformas de destino disponibles, revise estos factores principales para completar su decisión.

Uso de los registros ingeridos

Defina cómo la organización usará los registros ingeridos para guiar la selección de la plataforma de ingesta.

Considere estos tres escenarios generales:

  • La organización debe conservar los registros solo con fines de cumplimiento o auditoría. En este caso, la organización rara vez accederá a los datos. Incluso si la organización accede a los datos, la facilidad de uso o el alto rendimiento no son prioridad.
  • La organización debe conservar los registros para que los equipos puedan acceder a ellos de manera sencilla y bastante rápida.
  • La organización debe conservar los registros para que los equipos puedan acceder a ellos de manera ocasional. El rendimiento y la facilidad de uso son secundarios.

Consulte la comparación de plataformas para saber qué plataforma se adapta a cada uno de estos escenarios.

Velocidad de la migración

En algunos escenarios, es posible que tenga que cumplir con una fecha límite ajustada; por ejemplo, es posible que la organización tenga que migrar de manera urgente de una SIEM anterior debido a un evento de expiración de licencia.

Revise los componentes y factores que determinan la velocidad de la migración.

Origen de datos

Por lo general, el origen de datos es un almacenamiento en la nube o un sistema de archivos local; por ejemplo, S3. El rendimiento del almacenamiento de un servidor depende de varios factores, como la tecnología de disco (SSD frente a HDD), la naturaleza de las solicitudes de E/S y el tamaño de cada solicitud.

Por ejemplo, el rendimiento de las máquinas virtuales de Azure oscila entre 30 MB por segundo en SKU de VM más pequeñas y 20 GB por segundo para algunas de las SKU optimizadas para el almacenamiento con discos de NVM Express (NVMe). Aprenda a diseñar una VM de Azure para lograr un alto rendimiento del almacenamiento. También puede aplicar la mayoría de los conceptos a los servidores locales.

Potencia de proceso

En algunos casos, incluso si el disco es capaz de copiar los datos rápidamente, la potencia de proceso es el cuello de botella del proceso de copia. En estos casos, puede elegir una de estas opciones de escalado:

  • Escalado vertical. Puede agregar más CPU o aumentar la velocidad de la CPU para aumentar la potencia de un servidor único.
  • Escalado horizontal. Puede agregar más servidores, lo que aumenta el paralelismo del proceso de copia.

Plataforma de destino

Cada una de las plataformas de destino descritas en esta sección tiene un perfil de rendimiento distinto.

  • Registros básicos de Azure Monitor. De manera predeterminada, los registros básicos se pueden insertar en Azure Monitor a una velocidad aproximada de 1 GB por minuto. Esta velocidad le permite ingerir aproximadamente 1,5 TB al día o 43 TB al mes.
  • Azure Data Explorer. El rendimiento de la ingesta varía según el tamaño del clúster que aprovisione y la configuración del procesamiento por lotes que aplique. Obtenga información sobre los procedimientos recomendados de ingesta, incluido el rendimiento y la supervisión.
  • Azure Blob Storage. El rendimiento de una cuenta de Azure Blob Storage puede variar considerablemente en función del número y el tamaño de los archivos, el tamaño del trabajo, la simultaneidad, etc. Aprenda a optimizar el rendimiento de AzCopy con Azure Storage.

Cantidad de datos

La cantidad de datos es el factor principal que afecta a la duración del proceso de migración. Por lo tanto, debe pensar en cómo configurar el entorno en función del conjunto de datos.

Para determinar la duración mínima de la migración y dónde podría estar el cuello de botella, considere la cantidad de datos y la velocidad de ingesta de la plataforma de destino. Por ejemplo, imagine que selecciona una plataforma de destino que puede ingerir 1 GB por segundo y tiene que migrar 100 TB. En este caso, la migración tardará un mínimo de 100 000 GB, multiplicado por la velocidad de 1 GB por segundo. Divida el resultado en 3600, lo que da como resultado 27 horas. Este cálculo es correcto si el resto de los componentes de la canalización, como el disco local, la red y las máquinas virtuales, pueden alcanzar una velocidad de 1 GB por segundo.

Pasos siguientes

En este artículo, aprendió a asignar las reglas de migración de QRadar a Microsoft Sentinel.

Selección de una herramienta de ingesta de datos