Share via


Continuité d’activité et reprise d’activité

Les sinistres peuvent être des défaillances matérielles, des catastrophes naturelles ou des défaillances logicielles. Le processus de préparation et de récupération en cas de sinistre est appelé reprise d’activité. Cet article décrit les pratiques recommandées pour assurer la continuité d'activité et reprise d'activité (BCDR) pour Azure Operator Insights.

Les stratégies BCDR incluent la redondance des zones de disponibilité et la récupération gérée par l’utilisateur.

Plan de contrôle

Le plan de contrôle Azure Operator Insights est résilient à la fois aux erreurs logicielles et aux défaillances d’une zone de disponibilité. La possibilité de créer et de gérer des produits de données n’est pas affectée par ces modes d’échec.

Le plan de contrôle n’est pas redondant régionalement. Lors d’une panne dans une région Azure, vous ne pouvez pas créer de produits de données dans cette région ou accéder à/gérer des produits existants. Une fois que la région a surmonté la panne, vous pouvez à nouveau accéder aux produits de données existants et les gérer.

Plan de données

Les produits de données sont résilients aux défaillances logicielles ou matérielles. Par exemple, si un bogue logiciel provoque un blocage du service ou qu’une défaillance matérielle entraîne la perte des ressources de calcul pour les requêtes d’enrichissement, le service récupère automatiquement. Le seul impact est un léger retard dans la disponibilité des données nouvellement ingérées dans le point de terminaison de stockage du produit de données et dans l’URL de consommation KQL.

Redondance de zone

Les produits de données ne prennent pas en charge la redondance de zone. Lorsqu’une zone de disponibilité échoue, l’ingestion du produit de données, blob/DFS et les API KQL/SQL ne fonctionnent pas, non plus que les tableaux de bord. La transformation des données déjà ingérées est suspendue. Aucune donnée précédemment ingérée n’est perdue. Le traitement reprend lorsque la zone de disponibilité récupère.

Ce qu’il advient des données générées pendant la panne de zone de disponibilité dépend du comportement de l’agent d’ingestion :

  • Si l’agent d’ingestion met en mémoire tampon les données et les renvoie lorsque la zone de disponibilité récupère, les données ne sont pas perdues. Azure Operator Insights peut prendre un certain temps pour traiter son backlog de transformation.
  • Sinon, les données sont perdues.

Récupération d’urgence

Azure Operator Insights n’a pas de redondance de région innée. Les pannes régionales affectent les produits de données de la même façon que les défaillances de zone de disponibilité. Nous proposons des recommandations et des fonctionnalités aux clients qui souhaitent pouvoir gérer les défaillances d’une région Azure entière.

Redondance gérée par l’utilisateur

Pour une redondance maximale, vous pouvez déployer des produits de données en mode actif-actif. Déployez un deuxième produit de données dans une région Azure de sauvegarde de votre choix et configurez vos agents d'ingestion pour qu'ils transfèrent les données vers les deux produits de données simultanément. Le produit de données de sauvegarde n’est pas affecté par l’échec de la région primaire. Pendant une panne régionale, examinez les tableaux de bord qui utilisent le produit de données de sauvegarde comme source de données. Cette architecture double le coût de la solution.

Vous pouvez également utiliser un mode actif-passif. Déployez un deuxième produit de données dans une région Azure de sauvegarde et configurez vos agents d’ingestion pour qu’ils envoient au produit de données principal. Pendant une panne régionale, reconfigurez vos agents d'ingestion pour qu'ils envoient des données au produit de données de secours lors d’une panne régionale. Cette architecture donne un accès complet aux données créées pendant la panne (à partir du moment où vous reconfigurez les agents d’ingestion), mais pendant la panne, vous n’avez pas accès aux données ingérées auparavant. Cette architecture nécessite des frais d’infrastructure réduits pour le deuxième produit de données, mais pas de frais supplémentaires de traitement des données.