Fiabilité de Azure Event Grid et de l’espace de noms Event Grid

Article
07/21/2024

Cet article contient des informations détaillées sur la résilience régionale de la grille d’événements et de l’espace de noms de la grille d’événements à l’aide de zones de disponibilité, ainsi que sur la récupération d’urgence et continuité des activité inter-régions.

Pour obtenir une vue d’ensemble architecturale de la fiabilité dans Azure, consultez Fiabilité Azure.

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.

Les définitions des ressources Event Grid pour les rubriques, les rubriques système, les domaines, les abonnements aux événements et les données d’événements sont automatiquement répliquées sur trois zones de disponibilité. 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é. Lorsqu’une région existante commence à prendre en charge des zones de disponibilité, les ressources Event Grid existantes sont automatiquement basculées pour tirer parti de cette fonctionnalité. Aucune action du client n’est nécessaire.

L’espace de noms Azure Event Grid permet également d’obtenir une haute disponibilité au sein d’une région à l’aide de zones de disponibilité.

Prérequis

Pour prendre en charge les zones de disponibilité, vos ressources Event Grid doivent se trouver dans une région qui prend en charge les zones de disponibilité. Pour voir quelles régions prennent en charge les zones de disponibilité, consultez la liste des régions prises en charge.

Tarification

Comme Event Grid prend automatiquement en charge les zones de disponibilité dans les régions qui les prennent en charge, les tarifs ne changent pas.

Créer une ressource avec les zones de disponibilité activées

Comme Event Grid prend automatiquement en charge les zones de disponibilité dans les régions qui les prennent en charge, aucune configuration n’est nécessaire.

Migrer vers une prise en charge des zones de disponibilité

Si vous relocalisez vos ressources Event Grid dans une région qui prend en charge les zones de disponibilité, vous bénéficiez automatiquement de la prise en charge de ces zones. Pour savoir comment déplacer vos ressources vers une autre région qui prend en charge les zones de disponibilité, reportez-vous aux sections suivantes :

Récupération d’urgence et continuité d’activité inter-région

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, 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.

La récupération d’urgence implique généralement la création d’une ressource de sauvegarde pour éviter les interruptions lorsqu’une région devient défectueuse. Au cours de ce processus, une région primaire et secondaire de Azure Event Grid ressources sera nécessaire dans votre charge de travail.

Il existe différentes façons de récupérer d’une perte grave de fonctionnalités d’application. Dans cette section, nous décrivons la liste de contrôle que vous devrez suivre pour préparer votre client à récupérer après une défaillance due à une ressource ou à une région non saine.

Event Grid prend en charge la récupération d’urgence géographique (GeoDR) manuelle et automatique côté serveur. Vous pouvez toujours implémenter une logique de récupération d’urgence côté client si vous souhaitez plus de contrôle sur le processus de basculement. Pour plus d’informations sur le processus GeoDR automatique, consultez Géoreprise d’activité après sinistre côté serveur dans Azure Event Grid. Pour découvrir plus de détails sur l’implémentation de la récupération d’urgence côté client, consultez Implémentation du basculement côté client dans Azure Event Grid.

Le tableau suivant illustre la prise en charge du basculement côté client et de la Géoreprise d’activité après sinistre dans Event Grid.

Ressource Event Grid	Prise en charge du basculement côté client	Prise en charge de la Géoreprise d’activité après sinistre (GeoDR)
Rubriques personnalisées	Pris en charge	Intergéographique / régionale
Rubriques sur le système	Non prise en charge	Activé automatiquement
Domaines	Pris en charge	Intergéographique / régionale
Espaces de noms de partenaires	Pris en charge	Non prise en charge
Espaces de noms	Pris en charge	Non pris en charge

Espace de noms Event Grid

L’espace de noms Event Grid ne prend pas en charge la récupération d’urgence (DR) inter-régions. Vous pouvez toutefois obtenir une haute disponibilité entre régions via l’implémentation d’un basculement côté client en créant des espaces de noms primaires et secondaires.

Avec une implémentation de basculement côté client, vous pouvez :

Implémenter un processus personnalisé (manuel ou automatisé) pour répliquer l’espace de noms, les identités des clients et d’autres configurations**, y compris les certificats d’autorité de certification (CA), les groupes de clients, les espaces de rubriques, les liaisons d’autorisation, le routage, entre les régions primaires et secondaires.
Implémenter un service de conciergerie qui fournit aux clients des points de terminaison primaires et secondaires en effectuant un contrôle d’intégrité des points de terminaison. Le service de conciergerie peut être une application web répliquée et rendue accessible à l’aide de techniques de redirection par DNS (par exemple, en utilisant Azure Traffic Manager).
Obtenir une solution de DR active-active répliquant les métadonnées et en équilibrant la charge entre les espaces de noms. Une solution de DR active-passive peut être obtenue en répliquant les métadonnées pour que l’espace de noms secondaire soit disponible à la redirection de trafic lorsque l’espace de nom principal n’est pas disponible.

Configurer une récupération d'urgence

Pour les régions jumelées, 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.

Vous avez le choix entre deux options de basculement : le basculement initié par Microsoft et le basculement initié par le client. Pour plus de détails sur la configuration de ces deux paramètres, consultez Configurer la résidence des données.

Le basculement initié par Microsoft est effectué par Microsoft dans de rares situations pour faire basculer les ressources Event Grid d’une région affectée vers 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.

Mettez à jour la configuration de votre thème ou domaine pour activer cette fonctionnalité. Pour activer le basculement initié par Microsoft, sélectionnez Intergéographique (par défaut).
Le basculement initié par le client est défini par votre plan de récupération d’urgence personnalisé pour les rubriques et les domaines Azure Event Grid, et aucune donnée n’est répliquée dans une autre région par Microsoft. Bien que nécessitant un peu plus d’efforts, cette option de basculement 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.

Vous pouvez désactiver la fonction de basculement initiée par Microsoft pour plusieurs raisons :
- 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.
Mettez à jour la configuration de votre thème ou domaine pour activer cette fonctionnalité. Sélectionnez Régional.

Si vous utilisez une région non jumelée, vos métadonnées seront uniquement répliquées dans la région, quelle que soit la configuration de résidence des données sélectionnée.

Expérience de basculement en cas de récupération d’urgence

La récupération d’urgence est mesurée à l’aide de deux indicateurs, l’objectif de point de récupération (RPO) et l’objectif de temps de récupération (RTO).

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.

Partage via