Partager via

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

  • Article

Cet article explique en détail comment vous 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. Un exemple d’ingestion de données avec Azure Event Hubs est fourni. L’optimisation des coûts y est également abordée pour différentes configurations architecturales. 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. S’il vous faut une solution de récupération d’urgence, procédez comme suit afin de garantir la continuité d’activité. Au cours de ces étapes, vous allez répliquer vos clusters, la gestion et l’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. Veillez à ce qu’au moins deux de ces clusters soient créés dans des régions jumelées Azure.

L’illustration suivante montre les réplicas, trois clusters dans trois régions différentes.

Créer des clusters indépendants.

Répliquer des activités de gestion

Répliquez les activités de gestion de manière à disposer de la même configuration de cluster dans chaque réplica.

  1. Sur chaque réplica, créez les mêmes :

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

    Dupliquer les activités de gestion.

Solution de reprise d’activité utilisant l’ingestion de hub d’événements

Après vous être préparé à une panne régionale Azure pour protéger vos données, ces dernières, de même que la gestion sont distribuées dans plusieurs régions. En cas de panne dans une région, Azure Data Explorer est en mesure d’utiliser d’autres réplicas.

Configurer l’ingestion en utilisant un hub d’événements

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.

Notes

L’ingestion via Azure Event Hubs/IoT Hub/Stockage est robuste. Si un cluster n’est pas disponible pendant un certain temps, il rattrapera son retard ultérieurement et insérera les messages ou objets blob en attente. Ce processus s’appuie sur les points de contrôle.

Ingérer via Azure Event Hubs.

Comme illustré dans le diagramme ci-dessous, vos sources de données produisent des événements dans les hubs d’événements de toutes les régions, et chaque réplica Azure Data Explorer consomme les é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 l’un des réplicas.

Sources de données pour la visualisation des données.

Optimiser les coûts

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

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

La réplication et la mise à jour de la configuration Azure Data Explorer augmentent de manière linéaire le coût en fonction du nombre de réplicas. A des fins d’optimisation des coûts, vous pouvez implémenter une variante architecturale pour équilibrer le temps, le basculement et le coût. Dans une configuration de récupération des données à la demande, l’optimisation des coûts a été implémentée en introduisant des réplicas Azure Data Explorer passifs. Ces réplicas ne sont activés qu’en cas d’incident dans la région primaire (région A, par exemple). Les réplicas des régions B et C n’ont pas à être actifs 24 heures sur 24, 7 jours sur 7, ce qui réduit considérablement les coûts. Dans la plupart des cas cependant, les performances de ces réplicas ne sont pas aussi bonnes que celles du cluster principal. Pour plus d’informations, consultez Configuration de la récupération des données à la demande.

Dans l’illustration ci-dessous, un seul cluster ingère des données provenant du hub d’événements. 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.

architecture pour une configuration de récupération de données à la demande.

Démarrer et arrêter les réplicas

Vous pouvez démarrer et arrêter les réplicas secondaires à l’aide d’une des méthodes suivantes :

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

Implémenter un service d’application hautement disponible

Créer le client BCDR 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.

Créer une instance d’Azure App Service.

Conseil

Le fait de disposer de plusieurs connexions entre les réplicas du même service offre une disponibilité accrue. Cette configuration n’est pas seulement utile dans les cas de pannes régionales.

  1. Utilisez ce code réutilisable pour une instance App Service. La classe AdxBcdrClient a été créée pour implémenter un client à plusieurs clusters. Dans un premier temps, chaque requête exécutée à l’aide de ce client est envoyée au cluster principal. En cas d’échec, la requête est envoyée aux réplicas secondaires.

  2. Utilisez des métriques d’insights d’application personnalisées pour mesurer les performances et demander une distribution vers les clusters principaux et secondaires.

Tester le client BCDR Azure App Service

Nous avons exécuté un test à l’aide de plusieurs réplicas Azure Data Explorer. Après une panne simulée de clusters principaux et secondaires, vous pouvez voir que le client BCDR App Service se comporte comme prévu.

Vérifier le client BCDR App Service.

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

Temps de réponse des requêtes mondiales.

Notes

Les temps de réponse plus lents sont dus à des références SKU et des requêtes mondiales.

Effectuer un routage dynamique ou statique

Utilisez les méthodes de routage Azure Traffic Manager à des fins de routage dynamique ou statique des requêtes. L’équilibreur de charge de trafic DNS Azure Traffic Manager vous permet de répartir 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 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. Ils doivent être dimensionnés de manière à gérer la charge d’ingestion. Lorsque le cluster principal n’est pas accessible, les clusters secondaires reçoivent plus de trafic et sont mis à l’échelle en fonction de la configuration.

Dans cet exemple, l’utilisation de la mise à l’échelle automatique optimisée a permis d’économiser environ 50 % du coût par rapport à la même échelle horizontale et verticale sur tous les réplicas.

Contenu connexe