Créer des solutions de continuité d'activité et de reprise d'activité avec Azure Data Explorer

Cet article explique comment préparer une panne régionale Azure en répliquant vos ressources Azure Data Explorer, la gestion et l’ingestion dans différentes régions Azure. L’article inclut un exemple d’ingestion de données avec Azure Event Hubs. Il traite également de l’optimisation des coûts pour différentes configurations d’architecture. Pour une analyse plus approfondie des considérations d’architecture et des solutions de reprise d’activité, consultez la vue d’ensemble relative à la continuité d’activité.

Se préparer à une panne régionale Azure pour protéger ses données

Azure Data Explorer ne prend pas en charge la protection automatique en cas de panne d’une région Azure entière. Cette interruption peut se produire lors d’une catastrophe naturelle, telle qu’un tremblement de terre. Si vous avez besoin d’une solution de récupération d’urgence, procédez comme suit pour garantir la continuité de l’activité. Dans ces étapes, vous répliquez vos clusters, activités de gestion et ingestion de données dans deux régions jumelées Azure.

1. Créez un minimum de clusters indépendants dans deux régions jumelées Azure.
2. Répliquez toutes les activités de gestion, telles que la création des tables ou la gestion des rôles d’utilisateur sur chaque cluster.
3. Ingérez des données dans chaque cluster en parallèle.

Créer plusieurs clusters indépendants

Créez plusieurs clusters Azure Data Explorer dans différentes régions. Créez au moins deux de ces clusters dans Azure régions jumelées.

Le diagramme suivant montre trois clusters de réplicas dans trois régions différentes.

Répliquer des activités de gestion

Répliquer les activités de gestion afin que chaque réplique ait la même configuration du cluster.

1. Créez les mêmes ressources sur chaque réplique :

   • Bases de données : utilisez le portail Azure ou l’un des kits SDK pour créer une base de données.
   • Tables
   • Mappages
   • Stratégies

2. Gérez l’authentification et l’autorisation sur chaque réplique.

   

Solution de reprise d’activité utilisant l’ingestion d'Event Hubs

Après avoir terminé Préparer une panne régionale Azure pour protéger vos données, Azure Data Explorer stocke vos données et les métadonnées de gestion dans plusieurs régions. En cas de panne dans une région, Azure Data Explorer peut utiliser les autres réplicas.

Configurer l’ingestion à l’aide d’Event Hubs

Pour ingérer des données depuis Azure Event Hubs dans le cluster Azure Data Explorer de chaque région, répliquez d’abord votre configuration d’Azure Event Hubs dans chaque région. Configurez ensuite le réplica Azure Data Explorer de chaque région pour ingérer les données de ses Event Hubs correspondants.

Ce diagramme montre que vos sources de données produisent des événements dans Event Hubs dans toutes les régions, et chaque réplica Azure Data Explorer consomme ces événements. Les composants de visualisation des données tels que Power BI, Grafana ou les applications web alimentées par les kits de développement logiciel (SDK) peuvent interroger un réplica.

Optimiser les coûts

Vous êtes maintenant prêt à optimiser vos réplicas à l’aide de certaines des méthodes suivantes :

• Créez une configuration de récupération de données à la demande.
• Démarrer et arrêter les réplicas.
• Implémentez un service d’application hautement disponible.
• Optimiser le coût dans une configuration active-active.

Créer une configuration de la récupération des données à la demande

La réplication et la mise à jour de la configuration d’Azure Data Explorer augmentent linéairement les coûts à mesure que le nombre de réplicas augmente. Pour optimiser les coûts, mettez en œuvre une variante d’architecture qui établit un équilibre entre les délais, le basculement et les coûts. Une configuration de récupération de données à la demande optimise le coût en utilisant des réplicas de Azure Data Explorer passifs. Ces répliques ne sont activées qu’en cas de sinistre dans la région primaire (par exemple, la région A). Les répliques dans les régions B et C n’ont pas besoin d’être actives 24 h/24 et 7 j/7, ce qui réduit considérablement les coûts. Toutefois, dans la plupart des cas, ces réplicas ne fonctionnent pas sur le cluster principal. Pour plus d’informations, consultez Configuration de la récupération des données à la demande.

Dans le diagramme suivant, un seul cluster ingère des données à partir d’Event Hubs. Le cluster principal de la région A se charge de l’exportation continue de toutes les données vers un compte de stockage. Les réplicas secondaires accèdent aux données à l’aide de tables externes.

Démarrer et arrêter les réplicas

Démarrez et arrêtez les réplicas secondaires à l’aide de l’une des méthodes suivantes :

• Connecteur Azure Data Explorer pour Power Automate (aperçu)

• Bouton Arrêter sous l’onglet Vue d’ensemble dans le portail Azure. Pour plus d’informations, consultez Arrêter et redémarrer le cluster.

• Azure CLI :

az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>

Implémenter un service d’application hautement disponible

Créer le client BCDR pour Azure App Service

Cette section explique comment créer une instance Azure App Service prenant en charge une connexion à un cluster Azure Data Explorer principal et plusieurs clusters secondaires. L’image suivante illustre la configuration d’Azure App Service.

1. Utilisez ce code standard pour un service d’application. Pour implémenter un client multicluster, utilisez la classe AdxBcdrClient . Chaque requête exécutée par ce client est envoyée en premier au cluster principal. Si une défaillance se produit, la requête est envoyée aux réplicas secondaires.

2. Utilisez des métriques Application Insights personnalisées pour mesurer les performances et demander la distribution aux clusters principaux et secondaires.

Tester le client BCDR pour Azure App Service

Le test suivant utilise plusieurs réplicas Azure Data Explorer. Après une panne simulée de clusters principaux et secondaires, le client BCDR App Service se comporte comme prévu.

Les clusters Azure Data Explorer sont répartis dans les régions Europe Ouest (2xD14v2 primaire), Asie Sud-Est et USA Est (2xD11v2).

Effectuer un routage dynamique ou statique

Utilisez Azure Traffic Manager méthodes de routage pour le routage des requêtes dynamiques ou statiques. Azure Traffic Manager est un équilibreur de charge de trafic BASÉ sur DNS que vous pouvez utiliser pour distribuer le trafic App Service. Ce trafic est optimisé pour les services des régions Azure du monde entier, tout en offrant une disponibilité et une réactivité élevées

Vous pouvez également utiliser le routage basé sur Azure Front Door. Pour découvrir une comparaison de ces deux méthodes, consultez Équilibrage de charge avec la suite de livraison d’application Azure.

Optimiser les coûts dans une configuration active-active

L’utilisation d’une configuration active-active à des fins de récupération d’urgence augmente le coût de façon linéaire. Le coût comprend les nœuds, le stockage, le balisage et la hausse du coût de mise en réseau pour la bande passante.

Utiliser la mise à l’échelle automatique optimisée pour optimiser les coûts

Utilisez la fonctionnalité de mise à l’échelle automatique optimisée pour configurer la mise à l’échelle horizontale des clusters secondaires. Dimensionner les clusters secondaires pour gérer la charge d’ingestion. Lorsque le cluster principal n’est pas accessible, les clusters secondaires obtiennent davantage de trafic et de mise à l’échelle en fonction de la configuration.

Dans cet exemple, la mise à l’échelle automatique optimisée permet de réduire les coûts d’environ 50 % par rapport à l’application du même dimensionnement horizontal et vertical à tous les réplicas.

Contenu connexe

• Vue d’ensemble de la continuité d'activité et de la reprise d'activité