Qu’est-ce que le basculement et la restauration automatique ?

Cet article fournit une vue d’ensemble générale de la façon dont le basculement et la restauration automatique fonctionnent dans un environnement cloud. Toutefois, pour comprendre le basculement, vous devez d’abord comprendre la redondance et la réplication. Pour en savoir plus sur ces concepts avant de poursuivre cet article, consultez Redondance, réplication et sauvegarde.

Une raison courante de conserver des copies redondantes des applications et des réplicas de données est de pouvoir effectuer un basculement. Avec le basculement, vous pouvez rediriger le trafic et les requêtes d’instances non saines vers des instances saines. Ensuite, une fois que les instances d’origine redeviennent saines, vous pouvez effectuer une restauration automatique pour revenir à la configuration d’origine.

Rôles d’instance active et passive

Dans le contexte du basculement, une instance peut être un composant unique, comme une base de données, ou une collection de plusieurs composants qui composent un déploiement de service dans une région. Sur une solution entière, vous pouvez basculer différentes parties de cette solution de différentes manières et dans différentes situations.

Un composant ou une collection de composants configurés pour le basculement et la restauration automatique nécessitent plusieurs instances. Chacune de ces instances assume un rôle particulier :

• Les instances principales ou actives travaillent activement, par exemple en répondant aux requêtes entrantes des clients. En général, il n’y a qu’une seule instance principale à la fois.
• Les instances secondaires ou passives sont inactives, mais sont prêtes à devenir l’instance principale si nécessaire. Il peut y avoir plusieurs instances secondaires.

Il existe plusieurs façons de configurer des instances passives. Chaque façon implique des compromis entre le temps de récupération et d’autres facteurs, tels que le coût et la complexité opérationnelle :

• Les serveurs de secours, conçus pour être prêts à accepter le trafic de production à tout moment.
• Le secours semi-automatique, qui est conçu pour être presque prêt à accepter le trafic de production, mais qui peut nécessiter des modifications de configuration ou des opérations de mise à l’échelle pour qu’il puisse accepter le trafic.
• La veilleuse, qui est partiellement déployée dans une configuration minimale et nécessite une préparation importante avant qu’elle puisse accepter le trafic de production.
• La reprise progressive, qui peut ne pas être déployée du tout et qui s’appuie sur les composants à déployer avant de pouvoir accepter le trafic de production.

Étendues de basculement

Différentes situations nécessitent différentes stratégies de basculement. Pour illustrer ces stratégies, prenons un exemple de solution qui consiste en une application qui accède aux données d’une base de données. Vous configurez la solution pour le basculement en créant des copies redondantes de votre serveur d’applications et plusieurs réplicas de la base de données. Ensuite, vous configurez :

• La redondance de zone en plaçant des copies et des réplicas dans différentes zones de disponibilité dans une région Azure.
• La géoredondance à l’aide d’un équilibreur de charge global pour basculer entre les régions.

Voici un diagramme simplifié qui illustre l’architecture globale dans les opérations normales :

Différentes situations peuvent déclencher différents événements de basculement dans cette solution. Chacune d’elles correspond à une étendue de basculement, qui représente la granularité des composants qui basculent :

• Un basculement de réplica de base de données peut se produire lorsque le réplica de base de données actif devient indisponible. Le réplica passif est promu pour devenir le réplica actif. En règle générale, les applications peuvent rapidement rediriger leurs requêtes vers le nouveau réplica actif :

  

• Un basculement de zone de disponibilité peut se produire si une zone de disponibilité entière subit une panne. Ce type de panne nécessite que tout le trafic soit acheminé vers le serveur web dans la zone restante, et garantit également que le réplica de base de données de la zone survivante devient le réplica actif s’il ne l’est pas déjà :

  

• Un basculement de région peut se produire en cas de perte catastrophique de l’ensemble de la région Azure primaire.

  

Bien que chacune de ces étendues fournisse un type de basculement, elles peuvent avoir des exigences et des processus de basculement distincts. En outre, Microsoft peut être responsable de certaines étendues de basculement, telles que lorsque vous utilisez des services redondants interzone, tandis que vous serez peut-être responsable du basculement dans des étendues plus larges, comme le basculement entre les régions Azure.

Planification du basculement et de la continuité d’activité

Une partie de la planification de la continuité d’activité consiste à concevoir vos stratégies de basculement, y compris les différentes étendues auxquelles vous pouvez basculer.

En règle générale, vos plans de continuité d’activité doivent inclure des procédures de basculement automatisées dans ou entre des zones de disponibilité. Ce type de basculement fait partie de votre stratégie de haute disponibilité. Par exemple, si le réplica actif d’une base de données échoue, un processus automatisé peut promouvoir un réplica passif pour qu’il devienne le réplica actif. Ensuite, les serveurs web communiquent avec le nouveau réplica actif. De même, si une zone de disponibilité échoue, de nombreuses solutions existes pour récupérer automatiquement à l’aide des zones restantes.

Différentes procédures de basculement sont utilisées pour les scénarios de sinistre, comme dans le cas peu probable d’une panne de région complète. Dans le cas d’une panne de région, vous pouvez basculer les requêtes web entrantes pour utiliser la deuxième région, ainsi que déclencher un basculement de la base de données vers un réplica dans la région secondaire.

N’oubliez pas que l’inclusion de procédures de basculement dans votre planification de la continuité d’activité vous oblige à effectuer des tests et des conceptions plus détaillés. Pour plus d’informations, consultez Qu’est-ce que la continuité d’activité, la haute disponibilité et la récupération d’urgence ?.

Basculements planifiés et non planifiés

Les basculements non planifiés sont ceux qui sont effectués lors d’une panne d’un composant, afin que vous puissiez restaurer le service à l’aide d’une autre instance. Les basculements non planifiés entraînent parfois un temps d’arrêt ou une perte de données, selon la façon dont une solution est conçue. Les basculements non planifiés nécessitent quelque chose pour détecter l’échec et prendre une décision sur le moment où déclencher le basculement.

En revanche, les basculements planifiés sont ceux que vous déclenchez de manière proactive. Vous pouvez le faire en prévision d’un événement, comme une machine virtuelle qui va être corrigée et redémarrée. Les basculements planifiés peuvent avoir une tolérance plus faible pour les temps d’arrêt et la perte de données, car ils font partie des procédures de maintenance régulières.

Fonctionnement du basculement

Le basculement se compose généralement des étapes suivantes, qui peuvent être effectuées manuellement ou par un système automatisé. Les détails spécifiques pour chacune de ces étapes dépendent du système particulier.

1. Détecter un échec (basculements non planifiés uniquement). Un basculement automatisé exige que quelque chose détecte l’indisponibilité d’une instance, qui est généralement basée sur une sorte de contrôle d’intégrité. Différents services définissent leur intégrité de différentes manières. Par exemple, certains services envoient de manière proactive des événements de pulsation entre les instances. D’autres nécessitent un composant distinct pour sonder chaque instance à intervalle régulier. Il faut souvent un certain temps pour que les contrôleurs d’intégrité détectent qu’une instance a échoué, et il est souvent important de donner une période de grâce au cas où l’instance était simplement occupée et ne pouvait pas répondre.

2. Choisir de basculer. À un moment donné, une décision sera prise pour effectuer un basculement. La décision peut être prise par un outil automatisé ou manuellement. La tolérance aux risques de votre organisation peut affecter la rapidité à laquelle cette décision est prise. Si vous avez une faible tolérance aux risques, vous pouvez choisir de basculer rapidement en cas de problème. Si vous avez une tolérance aux risques plus élevée, vous pouvez choisir d’attendre de voir si le problème peut être résolu avant de basculer.

3. Sélectionner une nouvelle instance principale. L’une des instances restantes doit devenir la nouvelle instance primaire.

   Dans certains cas, vous avez peut-être prédéfini l’instance qui doit devenir la nouvelle instance principale, ou vous n’avez peut-être qu’une seule instance à basculer.

   Dans d’autres situations, il existe un processus automatisé par lequel le système sélectionne une nouvelle instance principale. Il existe un certain nombre d’algorithmes de consensus utilisés dans les traitements distribués, y compris pour les élections du responsable. Ces algorithmes sont implémentés dans les services appropriés, tels que les bases de données. Dans certains systèmes, il est important que chaque instance soit informée du nouveau réplica principal et que les résultats de la sélection soient annoncés automatiquement à chaque réplica.

4. Rediriger les demandes. Configurez votre environnement afin que les requêtes soient dirigées vers les instances saines ou vers la nouvelle instance principale.

   Pour ce faire, vous devrez peut-être mettre à jour d’autres systèmes afin qu’ils sachent où envoyer les requêtes. Cela peut impliquer la mise à jour d’un système d’équilibrage de charge pour exclure l’instance non saine. Dans d’autres cas, le système DNS (Domain Name System) est couramment utilisé comme moyen d’envoyer des requêtes à une instance active d’un système. Dans le cadre du processus de basculement, vous devez généralement mettre à jour les enregistrements DNS afin que les requêtes soient acheminées vers la nouvelle instance principale. DNS dispose du concept de durée de vie (TTL), qui indique aux clients la fréquence à laquelle ils doivent rechercher les enregistrements DNS mis à jour. Si votre durée de vie est définie sur une valeur longue, cela peut prendre du temps pour que les clients reçoivent des informations sur le basculement, et ils peuvent continuer à envoyer des requêtes à l’ancienne instance principale.

Étant donné que les processus de basculement peuvent inclure des retards, il est important de planifier vos procédures de basculement pour répondre à vos besoins en cas de temps d’arrêt (objectif de temps de récupération ou RTO) et de perte de données (objectif de point de récupération ou RPO). Pour plus d’informations, consultez Qu’est-ce que la continuité d’activité, la haute disponibilité et la récupération d’urgence ?.

Restauration automatique

La restauration automatique est le processus de réactivation et de redirection du trafic vers l’instance principale d’origine.

Dans certaines situations, il n’est pas nécessaire d’effectuer une restauration automatique, car chaque instance est également capable d’agir comme instance principale. Toutefois, il existe certaines situations où il est important d’effectuer une restauration automatique, par exemple quand vous devez exécuter vos applications à partir d’une région Azure particulière et que vous avez basculé vers une autre région temporairement lors d’une panne régionale.

Parfois, la restauration automatique est gérée de la même façon qu’un basculement. Toutefois, la restauration automatique peut également être plus complexe que le basculement, pour plusieurs raisons :

• Problèmes de synchronisation des données. Pendant et même après un basculement normal, l’instance principale précédente a peut-être travaillé ou écrit des données dans un magasin de données. Une partie du processus de restauration automatique consiste à garantir la cohérence et l’intégrité des données dans votre solution, notamment la gestion des conflits ou des duplications entre les instances primaires et secondaires.

  Il est courant que les problèmes de synchronisation de données nécessitent une intervention manuelle. Si vous n’avez pas besoin des données en conflit, vous pouvez choisir de réinitialiser la base de données ou un autre état.

• Étapes de correction. Si des étapes de correction ont été tentées sur l’instance principale avant le basculement, elles ont peut-être laissé l’instance principale dans un état inconnu.

  S’il existe un risque que l’instance principale soit dans un état incohérent, vous devrez peut-être détruire et redéployer l’instance principale afin qu’elle soit dans un état correct connu avant de restaurer automatiquement.

• Temps d’arrêt supplémentaire. Le temps d’arrêt pendant le processus de restauration automatique peut être plus long que pendant un basculement en raison des reconfigurations requises ou des opérations pour restaurer la cohérence des données.

  Vous pouvez atténuer ce problème en exécutant des processus de restauration automatique pendant une fenêtre de maintenance ou en informant les utilisateurs du changement à l’avance. En outre, vous pourrez peut-être effectuer certaines des opérations préparatoires pendant que le système est en ligne et réduire le temps d’arrêt requis.

• Tolérance aux risques. Si le basculement s’est produit en raison d’une panne, la tolérance de l’organisation pour les temps d’arrêt ou d’autres risques pendant la restauration automatique peut être plus faible.

  Les parties prenantes de l’entreprise doivent être informées de la situation tout au long du processus et doivent être pleinement conscientes de la nécessité de la restauration automatique et des conséquences des procédures de restauration automatique. Vous serez peut-être en mesure de négocier un délai approprié pour apporter les modifications.

Basculement et restauration automatique dans les services Azure

Bien qu’il soit important de comprendre le fonctionnement général du basculement, gardez à l’esprit que chaque service Azure peut aborder le basculement et la restauration automatique différemment. Pour plus d’informations sur le fonctionnement des services Azure spécifiques du point de vue de la fiabilité, consultez le guide de fiabilité de chaque service.

De nombreux services Azure gèrent automatiquement certains types de basculement. Par exemple, lorsque vous utilisez des services Azure configurés pour être redondants interzone, Microsoft effectue automatiquement un basculement entre les zones de disponibilité pour vous. Pour en savoir plus, consultez Que sont les zones de disponibilité ? et les guides de fiabilité du service Azure.

Si vous utilisez des machines virtuelles, Azure Site Recovery réplique les machines virtuelles et leurs disques entre les zones de disponibilité ou vers une autre région Azure et peut effectuer un basculement pour vous.

Lorsque vous concevez votre propre solution qui combine plusieurs services Azure, vos besoins de basculement peuvent devenir plus complexes. Supposons que vous concevez une solution avec une couche Application et une base de données, et que vous souhaitez créer une architecture active/passive multirégion. Lors d’une panne dans la région primaire, il est important que votre application et votre base de données basculent ensemble vers la région secondaire. Selon les services que vous utilisez, vous devrez peut-être planifier votre propre approche de basculement pour basculer entre les déploiements de chaque région. Azure fournit un routage global du trafic et un équilibrage de charge via Azure Front Door et Azure Traffic Manager, et vous pouvez sélectionner la technologie qui répond à vos besoins de basculement. Chaque service prend en charge la surveillance de l’intégrité de chaque instance régionale de votre application et vous pouvez la configurer pour rediriger automatiquement le trafic vers l’instance saine.

Étapes suivantes

• En savoir plus sur la responsabilité partagée de la fiabilité.
• En savoir plus sur les recommandations pour la conception multirégion hautement disponible dans Azure Well-Architected Framework.