Récupération dans une région utilisant des zones de disponibilité et géo-reprise d’activité après sinistre dans les régions (Azure Event Grid)
Cet article explique comment Azure Event Grid prend en charge la récupération automatique en région de vos définitions et données de ressources Event Grid quand une défaillance se produit dans une région disposant de zones de disponibilité. De même, il explique comment Event Grid prend en charge la récupération automatique des définitions de ressources Event Grid (sans données) dans une autre région lorsqu’une défaillance se produit dans une région jumelée à une autre région.
Récupération dans une région utilisant des zones de disponibilité
Les zones de disponibilité sont des emplacements physiquement séparés au sein de chaque région Azure qui tolèrent les défaillances locales. Elles sont connectées par un réseau hautes performances avec une latence aller-retour de moins de 2 millisecondes. Chaque zone de disponibilité se compose d’un ou plusieurs centres de données équipés d’une alimentation, d’un système de refroidissement et d’une infrastructure réseau indépendants. 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. Pour plus d’informations sur les zones de disponibilité, consultez Régions et zones de disponibilité. Dans cet article, vous pouvez aussi voir la liste des régions qui disposent de zones de disponibilité.
Les définitions de ressource Event Grid pour les rubriques, les rubriques système, les domaines, les abonnements aux événements et les données d’événements sont répliquées automatiquement dans trois zones de disponibilité (quand elles sont disponibles) de la région. En cas de défaillance dans l’une des zones de disponibilité, les ressources Event Grid basculent automatiquement vers une autre zone de disponibilité sans intervention humaine. Actuellement, il n’est pas possible de contrôler (activer ou désactiver) cette fonctionnalité. Quand une région existante commence à prendre en charge les zones de disponibilité, les ressources Event Grid existantes basculent automatiquement pour tirer parti de cette fonctionnalité. Aucune action du client n’est nécessaire.
Géo-reprise d’activité après sinistre dans les régions
Quand une région Azure rencontre une panne prolongée, les options de basculement vers une autre région peuvent s’avérer intéressantes pour la continuité de l’activité. De nombreuses régions Azure ont des géopaires, d’autres n’en ont pas. Pour obtenir la liste des régions jumelées, consultez Couplages de réplication inter-région Azure pour toutes les zones géographiques.
Pour les régions dotées d’une géopaire, Event Grid offre la possibilité de faire basculer le trafic de publication vers la région jumelée pour les rubriques personnalisées, les rubriques système et les domaines. En arrière-plan, Event Grid synchronise automatiquement les définitions de ressource des rubriques, rubriques système, domaines et abonnements aux événements dans la région jumelée. Cependant, les données d’événements ne sont pas répliquées dans la région jumelée. Dans l’état normal, les événements sont stockés dans la région que vous avez sélectionnée pour cette ressource. Si, à la suite d’une panne dans une région, Microsoft lance le basculement, de nouveaux événements commencent à affluer vers la région géographiquement appairée et sont dispatchées à partir de celle-ci sans aucune intervention de votre part. Les événements publiés et acceptés dans la région d’origine sont dispatchés à partir de celle-ci après que la panne a été atténuée.
Le basculement lancé par Microsoft n’est déclenché que dans de rares situations pour faire basculer des ressources Event Grid entre une région affectée et la région géographiquement associée correspondante. Microsoft se réserve le droit de déterminer à quel moment cette option sera utilisée. Ce mécanisme n’implique pas le consentement de l’utilisateur avant le basculement du trafic de celui-ci.
Vous pouvez activer ou désactiver cette fonctionnalité en mettant à jour la configuration de votre rubrique ou domaine. Sélectionnez l’option Intergéographique (par défaut) pour activer le basculement initié par Microsoft et Régional pour le désactiver. Pour configurer ce paramètre, suivez les étapes détaillées dans Configurer la résidence des données. Si vous optez pour régional, Microsoft ne réplique aucune donnée dans une autre région, et vous pouvez définir votre propre plan de récupération d’urgence. Pour plus d’informations, consultez Créer votre propre plan de récupération d’urgence pour des rubriques et domaines Azure Event Grid.
Voici quelques raisons pour lesquelles vous pouvez souhaiter désactiver la fonctionnalité de basculement initiée par Microsoft :
- Le basculement initié par Microsoft se fait au mieux.
- Certaines géopaires ne répondent pas aux besoins de résidence des données de votre organisation.
En pareil cas, la solution recommandée consiste à créer votre propre plan de reprise d’activité pour les rubriques et les domaines Azure Event Grid. Bien que cette solution demande plus d’efforts, elle permet un basculement plus rapide et vous avez la possibilité de choisir les régions secondaires. Si vous voulez implémenter une reprise d’activité côté client pour les rubriques Azure Event Grid, consultez Créer votre propre reprise d’activité côté client pour des rubriques Azure Event Grid.
RTO et RPO
La récupération d’urgence est mesurée à l’aide de deux métriques :
- Objectif de point de récupération (RPO) : nombre de minutes ou d’heures de données pouvant être perdues.
- Objectif de temps de récupération (RTO) : nombre de minutes ou d’heures pendant lesquelles le service peut être arrêté.
Le basculement automatique d’Event Grid utilise différents objectifs RPO et RTO pour vos métadonnées (rubriques, domaines, abonnements aux événements) et vos données (événements). Si vous avez besoin d’une spécification différente de celles ci-dessous, vous pouvez toujours implémenter votre propre basculement côté client à l’aide des API d’intégrité de rubrique.
Objectif de point de récupération (RPO)
RPO de métadonnées : zéro minutes. Pour les ressources applicables, quand une ressource est créée/mise à jour/supprimée, la définition de la ressource est répliquée de façon synchrone vers la géopaire. Lorsqu’un basculement se produit, aucune métadonnée n’est perdue.
RPO des données : quand un basculement s’opère, les nouvelles données sont traitées à partir de la région jumelée. Dès que la panne est atténuée pour la région touchée, les événements non traités sont dispatchés à partir de cette dernière. Si la reprise d’activité de la région prend plus de temps que prévu par rapport à la valeur de durée de vie définie pour les événements, les données risquent d’être abandonnées. Pour atténuer cette perte de données, nous vous recommandons de configurer une destination de lettre morte pour un abonnement aux événements. Si la région concernée est perdue et non récupérable, des données seront perdues. Dans le meilleur cas, l’abonné respecte le taux de publication et la perte de données se limite à quelques secondes. Dans le pire des cas, l’abonné ne traite pas activement les événements et avec une durée maximale de vie de 24 heures, la perte de données peut atteindre 24 heures.
Objectif de délai de récupération (RTO)
RTO des métadonnées : le processus de décision du basculement repose sur des facteurs tels que la capacité disponible dans la région jumelée et peut durer dans la plage de 60 minutes ou plus. Une fois que le basculement est initié, dans les 5 minutes, Event Grid commence à accepter les appels de création/mise à jour/suppression pour les rubriques et les abonnements.
RTO des données : comme ci-dessus.
Important
- Dans le cas d’une reprise d’activité côté serveur, si la région jumelée n’a pas de capacité excédentaire pour traiter le trafic supplémentaire, Event Grid ne peut pas initier le basculement. La reprise d’activité se fait au mieux.
- L’utilisation de cette fonctionnalité n’entraîne aucun coût.
- La géo-reprise d’activité après sinistre n’est pas prise en charge pour les espaces de noms partenaires et les rubriques partenaires.