Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se explica cómo prepararse para una interrupción regional de Azure replicando los recursos, la administración y la ingesta de Azure Data Explorer en diferentes regiones de Azure. En el artículo se incluye un ejemplo de ingesta de datos con Azure Event Hubs. También se describe la optimización de costos para diferentes configuraciones de arquitectura. Para obtener una visión más detallada de las consideraciones de arquitectura y las soluciones de recuperación, consulte Introducción a la continuidad empresarial y recuperación ante desastres.
Preparación de la protección de los datos ante una interrupción regional de Azure
Azure Data Explorer no proporciona protección automática frente a la interrupción de toda una región de Azure. Este tipo de interrupción se puede producir durante un desastre natural, como un terremoto. Si necesita una solución de recuperación ante desastres, siga estos pasos para garantizar la continuidad empresarial. En estos pasos, replicará los clústeres, las actividades de administración y la ingesta de datos en dos regiones emparejadas Azure.
- Cree dos o más clústeres independientes en dos regiones emparejadas de Azure.
- Replique todas las actividades de administración en cada clúster, como la creación de nuevas tablas o la administración de roles de usuario.
- Realice la ingesta de datos en paralelo en cada clúster.
Creación de varios clústeres independientes
Cree más de un clúster de Azure Data Explorer en más de una región. Cree al menos dos de estos clústeres en regiones emparejadas de Azure.
En el diagrama siguiente se muestran tres clústeres de réplica en tres regiones diferentes.
Replicar actividades de administración
Replique las actividades de administración para que cada réplica tenga la misma configuración de clúster.
Cree los mismos recursos en cada réplica:
- Bases de datos: use el portal de Azure o uno de los SDK para crear una nueva base de datos.
- Tablas
- Asignaciones
- Directivas
Administre la autenticación y autorización en cada réplica.
Solución de recuperación ante desastres mediante la ingesta de datos con Event Hubs
Después de completar Preparación para una interrupción regional de Azure para proteger sus datos, Azure Data Explorer almacena sus datos y la información de administración en varias regiones. Si hay una interrupción en una región, Azure Data Explorer puede usar las demás réplicas.
Configurar la ingesta mediante Event Hubs
Para ingerir datos de Azure Event Hubs en el clúster de Azure Data Explorer de cada región, primero replique la configuración de Azure Event Hubs en cada región. A continuación, configure la réplica de Azure Data Explorer de cada región para ingerir datos de su correspondiente Event Hubs.
Nota:
La ingesta a través de Azure Event Hubs, IoT Hub o Storage es fiable. Si un clúster no está disponible durante el tiempo, se actualiza más adelante e inserta los mensajes o blobs pendientes. Este proceso se basa en la creación de puntos de comprobación.
Este diagrama muestra que sus orígenes de datos envían eventos a Event Hubs en todas las regiones y que cada réplica de Azure Data Explorer consume esos eventos. Los componentes de visualización de datos como Power BI, Grafana o aplicaciones web basadas en SDK pueden consultar una réplica.
Optimización de costos
Ahora está listo para optimizar las réplicas mediante algunos de los métodos siguientes:
- Cree una configuración de recuperación de datos a petición.
- Inicie y detenga las réplicas.
- Implemente un servicio de aplicación de alta disponibilidad.
- Optimice el costo en una configuración activa-activa.
Creación de una configuración de recuperación de datos a petición
La replicación y la actualización de la configuración de Azure Data Explorer aumentan linealmente el coste a medida que aumenta el número de réplicas. Para optimizar el costo, implemente una variante arquitectónica que equilibre el tiempo, la conmutación por error y el costo. Una configuración de recuperación de datos a petición optimiza el costo mediante réplicas de Azure Data Explorer pasivas. Estas réplicas solo se activan si hay un desastre en la región primaria (por ejemplo, la región A). Las réplicas de las regiones B y C no necesitan estar activas 24/7, lo que reduce significativamente el costo. Pero, en la mayoría de los casos, estas réplicas no funcionan y el clúster principal. Para más información, consulte Configuración de recuperación de datos a petición.
En el diagrama siguiente, solo un clúster ingiere datos de Event Hubs. El clúster principal de la región A realiza la exportación de datos continua de todos los datos a una cuenta de almacenamiento. Las réplicas secundarias acceden a los datos mediante tablas externas.
Iniciar y detener las réplicas
Inicie y detenga las réplicas secundarias mediante uno de los métodos siguientes:
Conector de Azure Data Explorer para Power Automate (versión preliminar)
El botón Detener de la pestaña Información general de Azure Portal. Para más información, consulte Detención y reinicio del clúster.
CLI de Azure:
az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>
Implementación de un servicio de aplicación de alta disponibilidad
Creación del cliente de BCDR de Azure App Service
En esta sección se muestra cómo crear una instancia de Azure App Service que admite una conexión a un único clúster principal y a varios clústeres secundarios de Azure Data Explorer. En la imagen siguiente se ilustra la configuración de Azure App Service.
Sugerencia
Tener varias conexiones entre réplicas en el mismo servicio proporciona mayor disponibilidad. Esta configuración no solo es útil en casos de interrupciones regionales.
Utilice este código base para un App Service. Para implementar un cliente de varios clústeres, use la clase AdxBcdrClient . Cada consulta que ejecuta este cliente se envía primero al clúster principal. Si se produce un error, la consulta se envía a las réplicas secundarias.
Use métricas personalizadas de Application Insights para medir el rendimiento y la distribución de solicitudes a clústeres principales y secundarios.
Prueba del cliente de BCDR de Azure App Service
En la prueba siguiente se usan varias réplicas de Azure Data Explorer. Después de una interrupción simulada de clústeres principales y secundarios, el cliente BCDR de App Service se comporta según lo previsto.
Los clústeres de Azure Data Explorer se distribuyen en Oeste de Europa (2xD14v2 principal), Sudeste Asiático y Este de EE. UU. (2xD11v2).
Nota:
Los tiempos de respuesta más lentos se deben a los distintos SKU y a las consultas entre planetas.
Realizar enrutamiento dinámico o estático
Use los métodos de enrutamiento de Azure Traffic Manager para el enrutamiento dinámico o estático de solicitudes. Azure Traffic Manager es un equilibrador de carga de tráfico basado en DNS que puede usar para distribuir el tráfico de App Service. Este tráfico está optimizado para los servicios en las regiones globales de Azure, a la vez que proporciona alta disponibilidad y capacidad de respuesta.
También puede usar el enrutamiento basado en Azure Front Door. Para obtener una comparación de estos dos métodos, vea Equilibrio de carga con el conjunto de entrega de aplicaciones de Azure.
Optimización del costo en una configuración activo-activo
El uso de una configuración activo-activo para la recuperación ante desastres aumenta el costo linealmente. El costo incluye los nodos, el almacenamiento, el marcado y un mayor costo de red para el ancho de banda.
Uso de la escalabilidad automática optimizada para optimizar los costos
Use la característica escalabilidad automática optimizada para configurar el escalado horizontal de los clústeres secundarios. Dimensione los clústeres secundarios para gestionar la carga de ingestión. Cuando el clúster principal no es accesible, los clústeres secundarios obtienen más tráfico y escalan según la configuración.
En este ejemplo, el escalado automático optimizado reduce los costes en aproximadamente un 50 % en comparación con utilizar la misma configuración de escalado horizontal y vertical en todas las réplicas.