Continuidad empresarial y recuperación ante desastres

Los desastres pueden ser errores de hardware, desastres naturales o errores de software. El proceso de preparación y recuperación de un desastre se denomina recuperación ante desastres (DR). En este artículo se describen los procedimientos recomendados para lograr la continuidad empresarial y la recuperación ante desastres (BCDR) para Azure Operator Insights.

Las estrategias de BCDR incluyen la redundancia de zona de disponibilidad y la recuperación administrada por el usuario.

Plano de control

El plano de control de Azure Operator Insights es resistente tanto a errores de software como a errores de una zona de disponibilidad. La capacidad de crear y administrar productos de datos no se ve afectada por estos modos de error.

El plano de control no es redundante a nivel regional. Durante una interrupción en una región de Azure, no puede crear nuevos productos de datos en esa región ni acceder a ellos ni administrar los existentes. Una vez que la región se recupera de la interrupción, puede volver a acceder a los productos de datos existentes y administrarlos.

Plano de datos

Los productos de datos son resistentes a errores de software o de hardware. Por ejemplo, si un error de software hace que el servicio se bloquee o un error de hardware hace que se pierdan los recursos de proceso para las consultas de enriquecimiento, el servicio se recupera automáticamente. El único impacto es un ligero retraso en la disponibilidad de los datos recién ingeridos en el punto de conexión de almacenamiento del producto de datos y en la dirección URL de consumo de KQL.

Redundancia de zona

Los productos de datos no admiten la redundancia de zona. Cuando se produce un error en una zona de disponibilidad, la ingesta del producto de datos, las API de blob/DFS y KQL/SQL no están disponibles y los paneles no funcionan. La transformación de los datos ya ingeridos se pone en pausa. No se pierden datos ingeridos previamente. El procesamiento se reanuda cuando se recupera la zona de disponibilidad.

Lo que ocurre con los datos generados durante la interrupción de la zona de disponibilidad depende del comportamiento del agente de ingesta:

• Si el agente de ingesta almacena en búfer los datos y los reenvía cuando se recupera la zona de disponibilidad, los datos no se pierden. Azure Operator Insights podría tardar algún tiempo en resolver su trabajo pendiente de transformación.
• De lo contrario, se perderán los datos.

Recuperación ante desastres

Azure Operator Insights no tiene redundancia de región innata. Las interrupciones regionales afectan a los productos de datos de la misma manera que los errores de zona de disponibilidad. Tenemos recomendaciones y características para admitir a los clientes que quieran poder controlar los errores de toda una región de Azure.

Redundancia administrada por el usuario

Para obtener la máxima redundancia, puede implementar productos de datos en modo activo-activo. Implemente un segundo producto de datos en una región de Azure de reserva de su elección y configure los agentes de ingesta para bifurcar datos en ambos productos de datos a la vez. El producto de datos de reserva no se ve afectado por el error de la región primaria. Durante una interrupción regional, examine los paneles que usan el producto de datos de reserva como origen de datos. Esta arquitectura duplica el costo de la solución.

Como alternativa, puede usar un modo activo-pasivo. Implemente un segundo producto de datos en una región de Azure de reserva y configure los agentes de ingesta para enviarlos al producto de datos principal. Durante una interrupción regional, vuelva a configurar los agentes de ingesta para enviar datos al producto de datos de reserva durante una interrupción de la región. Esta arquitectura proporciona acceso completo a los datos creados durante la interrupción (a partir del momento en que se vuelven a configurar los agentes de ingesta), pero durante la interrupción no tiene acceso a los datos ingeridos antes de ese momento. Esta arquitectura requiere un pequeño cargo de infraestructura para el segundo producto de datos, pero sin cargos adicionales de procesamiento de datos.