Introducción a la continuidad empresarial y recuperación ante desastres

La continuidad empresarial y la recuperación ante desastres en Azure Data Explorer permiten a su empresa seguir funcionando ante una interrupción. En este artículo se detallan varias configuraciones de recuperación ante desastres en función de los requisitos de capacidad de recuperación (RPO y RTO), esfuerzo necesario y costo.

Para obtener más información sobre las opciones de confiabilidad disponibles para Azure Data Explorer, incluida la compatibilidad de zona de disponibilidad, la copia de seguridad y la protección contra algunos tipos de errores humanos, consulte Reliability in Azure Data Explorer.

Configuraciones de recuperación ante desastres

El objetivo de tiempo de recuperación (RTO) hace referencia al tiempo que se tarda en recuperarse de una interrupción. Por ejemplo, un RTO de 2 horas significa que la aplicación tiene que estar activa y en funcionamiento en un plazo de dos horas tras una interrupción. El objetivo de punto de recuperación (RPO) hace referencia al intervalo de tiempo que puede transcurrir durante una interrupción antes de que la cantidad de datos perdidos durante ese período sea mayor que el umbral permitido. Por ejemplo, si el RPO es de 24 horas y una aplicación tiene datos que comienzan hace 15 años, todavía están dentro de los parámetros del RPO acordado.

Los procesos de ingesta, procesamiento y protección necesitan un diseño diligente por adelantado al planear la recuperación ante desastres. La ingesta hace referencia a los datos integrados en Azure Data Explorer de varios orígenes; el procesamiento hace referencia a transformaciones y actividades similares; la curación hace referencia a vistas materializadas, exportaciones al lago de datos, etc.

A continuación se muestran configuraciones populares de recuperación ante desastres:

• Configuración activo-activo-activo (siempre activado)
• Configuración activo-activo
• Configuración activo-espera activa
• Configuración de clúster con recuperación de datos a petición

Configuración activo-activo-activo

Esta configuración también se denomina always-on. En el caso de las implementaciones críticas de aplicaciones sin tolerancia a interrupciones, debe usar varios clústeres de Azure Data Explorer en regiones emparejadas de Azure. Configure la ingesta, el procesamiento y la curación en paralelo en todos los clústeres. La SKU del clúster debe ser la misma en todas las regiones. Azure garantiza que las actualizaciones se implementen de manera gradual en las regiones emparejadas de Azure. Una interrupción en la región de Azure no provoca una interrupción de la aplicación. Es posible que experimente alguna latencia o degradación del rendimiento.

Configuración activo-activo

Esta configuración es idéntica a la configuración active-active-active, pero solo implica dos regiones emparejadas de Azure. Configure la ingesta, el procesamiento y la curación duales. Los usuarios se enrutan a la región más cercana. La SKU del clúster debe ser la misma en todas las regiones.

Configuración activo-espera activa

La configuración activo-caliente es similar a la configuración activo-activo en la ingesta, el procesamiento y la curación duales. Aunque el clúster en espera está en línea para la ingesta, el proceso y la curación, no está disponible para realizar consultas. El clúster en espera no necesita estar en la misma SKU que el clúster principal. Puede ser de una SKU y una escala más pequeñas, lo que puede dar lugar a que sea menos eficaz. En un escenario de desastre, los usuarios se redirigen al clúster en espera, que opcionalmente se puede escalar verticalmente para aumentar el rendimiento.

Configuración de recuperación de datos a petición

Esta solución ofrece la menor capacidad de recuperación (con el mayor RPO y RTO), con el menor costo y el mayor esfuerzo. En esta configuración, no hay ningún clúster de recuperación de datos. Configure la exportación continua de los datos protegidos (a menos que también se requieran datos sin procesar e intermedios) a una cuenta de almacenamiento configurada con GRS (almacenamiento con redundancia geográfica). Un clúster de recuperación de datos se activa si hay un escenario de recuperación ante desastres. En ese momento, se aplican los DDL, la configuración, las directivas y los procesos. Se ingieren datos desde el almacenamiento utilizando la propiedad de ingesta kustoCreationTime para anular el tiempo de ingesta que por defecto es la hora del sistema.

Resumen de las opciones de configuración de la recuperación ante desastres

procedimientos recomendados

Independientemente de la configuración de recuperación ante desastres elegida, siga estos procedimientos recomendados:

• Todos los objetos, las directivas y las configuraciones de la base de datos se deben conservar en el control de código fuente para que se puedan publicar en el clúster desde la herramienta de automatización de versiones. Para obtener más información, consulte Azure DevOps compatibilidad con Azure Data Explorer.
• Diseñe, desarrolle e implemente rutinas de validación para asegurarse de que todos los clústeres estén sincronizados desde la perspectiva de los datos. Azure Data Explorer admite uniones entre clústeres. Un simple recuento de las filas en las tablas puede ayudar a validar.
• Los procedimientos de versión deben incluir controles y equilibrios de gobernanza que aseguren el reflejo de los clústeres.
• Conozca todo lo que se necesita para crear un clúster desde cero.
• Cree una lista de comprobación de las unidades de implementación. La lista es única para sus necesidades, pero debe incluir: scripts de implementación, conexiones de ingesta, herramientas de BI y otras configuraciones importantes.

Paso siguiente