Fiabilité dans Azure Bot Service
Lorsque vous créez une application (bot) dans Azure, vous pouvez choisir si votre ressource de bot aura ou non une résidence des données globale ou locale. La résidence des données locale garantit que les données personnelles de votre bot sont conservées, stockées et traitées dans certaines limites géographiques (comme les limites de l’UE).
Important
La prise en charge des zones de disponibilité n’est pas activée pour les canaux standard dans le service de bot régional.
Cet article décrit la prise en charge de la fiabilité dans Azure Bot Service et traite à la fois de la fiabilité régionale avec les zones de disponibilité et de la résilience interrégion avec récupération d’urgence pour les bots avec résidence de données locale. Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez Fiabilité Azure.
Pour plus d’informations sur le déploiement de bots avec résidence des données locale et conformité régionale, consultez Régionalisation dans Azure Bot Service.
Prise en charge des zones de disponibilité
Les zones de disponibilité Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.
Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.
Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.
Pour les bots régionaux, Azure Bot Service prend en charge la redondance de zone par défaut. Vous n’avez pas besoin de le configurer ou de le reconfigurer pour la prise en charge des zones de disponibilité.
Prérequis
- Votre bot doit être régional (et non global).
- Actuellement, seule la région « westeurope » prend en charge les zones de disponibilité.
Expérience en cas de panne de zone
Pendant une panne à l’échelle de la zone, le client doit s’attendre à une brève dégradation des performances, jusqu’à ce que le service ré-équilibre la capacité sous-jacente pour s’ajuster aux zones saines. Cela ne dépend pas de la restauration de zone ; on s’attend à ce que l’état de l’auto-réparation du service géré par Microsoft compense une zone perdue, en se servant de la capacité des autres zones.
Reprise d’activité inter-région dans une zone géographique multirégion
La récupération d’urgence (Disaster Recovery/DR) consiste à récupérer après des évènements à fort impact, comme les catastrophes naturelles ou les déploiements ayant échoué, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.
En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.
Azure Bot Service s’exécute en mode actif-actif pour les services globaux et régionaux. Lorsqu’une panne se produit, vous n’avez pas besoin de détecter les erreurs ou de gérer le service. Azure Bot Service effectue automatiquement le basculement automatique et la récupération automatique dans une architecture multi-régions géographiques. Pour le service régional de bot de l’UE, Azure Bot Service fournit deux régions complètes à l’intérieur de l’Europe avec une réplication active/active pour garantir la redondance. Pour le service de bot global, toutes les régions/zones géographiques disponibles peuvent être servies en tant qu’empreinte globale.