Qu’est-ce que le basculement et le rétablissement ?

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 à la fois des applications et des copies de sauvegarde des 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 deviennent 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 services dans une région. Dans l'ensemble d'une solution, il est possible de basculer différentes parties de celle-ci de différentes manières et dans différentes situations.

Un composant ou une collection de composants configuré pour le basculement et le retour nécessite plusieurs instances. Chacune de ces instances assume un rôle particulier :

• Les instances principales ou actives fonctionnent activement, comme le traitement des demandes entrantes des clients. En règle générale, il existe une instance principale à la fois.
• Les instances secondaires ou passives sont inactives, mais sont prêtes à être basculées pour devenir le primaire 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 :

• Veilles actives, conçues pour être prêtes à accepter le trafic de production à tout moment.
• Configurations d'attente actives, qui sont conçues pour être presque prêtes à recevoir le trafic de production, mais qui pourraient nécessiter des modifications de configuration ou des opérations de mise à l’échelle pour qu’elles puissent accepter ce trafic.
• Les secours légers pilotes, qui sont partiellement déployés dans une configuration minimale et nécessitent une préparation importante avant qu’ils puissent accepter le trafic de production.
• Les secours à froid, qui pourraient ne pas être déployés du tout et doivent s'appuyer sur des composants devant être déployés avant de pouvoir accepter le trafic de production.

Conseil / Astuce

Certaines solutions sont conçues pour utiliser une approche active-active , ce qui signifie que plusieurs instances servent toutes les requêtes. Un système actif-actif ne nécessite pas de basculement, car toutes les instances servent activement des requêtes à tout moment.

Étendues de basculement

Différentes situations nécessitent différentes stratégies de basculement. Pour illustrer ces stratégies possibles, considérez un exemple de solution qui se compose d’une application qui accède aux données à partir 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 :

• Redondance de zone en plaçant des copies et des répliques dans différentes zones de disponibilité dans une région Azure.
• 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 entraîner 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éplique de base de données peut se produire lorsque la réplique de base de données active devient indisponible. La réplique passive est promue pour devenir la réplique active. 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é complète subit une interruption. Ce type de panne nécessite que tout le trafic soit routé vers le serveur web dans la seule zone restante, et garantit également que la réplique de base de données de la zone survivante devienne active si elle 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érents niveaux auxquels 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 devenir le réplica actif. Ensuite, les serveurs web communiquent avec la nouvelle réplique active. De même, si une zone de disponibilité échoue, de nombreuses solutions sont créées 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, par exemple, 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 et 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é de l’activité vous oblige à effectuer des tests et conception plus détaillés. Pour plus d’informations, consultez Qu’est-ce que la continuité de l’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 de quelque chose qui pourrait se produire, comme une machine virtuelle qui va être corrigée et redémarrée. Les basculements planifiés peuvent présenter une tolérance moindre aux temps d'arrêt et aux pertes 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é nécessite qu'un élément détecte lorsqu'une instance n'est pas disponible, ce qui est généralement basé sur un certain type de vérification de l'état. Différents services définissent leur état de fonctionnement de différentes manières. Par exemple, certains services envoient de manière proactive des événements heartbeat 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 moniteurs de santé détectent qu'une instance a échoué, et il est souvent important d'accorder une période de grâce au cas où l'instance serait simplement occupée et ne pourrait pas répondre.

2. Choisissez de basculer vers le système de secours. À 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 au risque, vous pourriez choisir de passer rapidement en mode d'échec en cas de problème. Si vous avez une tolérance au risque plus élevée, vous pouvez choisir d'attendre pour voir si le problème peut être résolu avant de basculer.

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

   Dans certaines situations, vous avez peut-être prédéfini quelle instance doit devenir la nouvelle primaire, ou bien vous n’avez qu’une seule instance vers laquelle 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 l’informatique distribuée, y compris pour les élections de leader. 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 de la nouvelle réplique principale et que les résultats de la sélection soient annoncés à chaque réplique automatiquement.

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 des demandes. 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 demandes soient routées vers la nouvelle instance principale. DNS a le 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 TTL est défini sur une valeur longue, il peut falloir du temps aux clients pour recevoir des informations sur le mécanisme de basculement, et ils peuvent continuer à envoyer des requêtes à l'ancien nœud principal.

É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 point 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

Failback est le processus de réintégration et de redirection du trafic vers l'instance primaire d'origine.

Dans certaines situations, il n’est pas nécessaire de retourner à l'état initial, car chaque instance est également capable de fonctionner comme instance principale. Toutefois, il existe certaines situations où il est important d’effectuer un rétablissement, par exemple lorsque 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, le retour à l'état initial est géré de la même façon qu’un basculement. Toutefois, le retour en arrière 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 effectué un travail 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 le serveur principal avant le basculement, elles ont peut-être laissé l’instance principale dans un état inconnu.

  S'il existe une éventualité que l'instance principale soit dans un état incohérent, vous devrez peut-être détruire et redéployer l'instance principale afin de la ramener dans un état stable et connu avant d'effectuer un basculement inverse.

• 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 de reconfigurations requises ou d’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 de la modification à 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 au risque. 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 le rétablissement peut être inférieure.

  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é du retour arrière et des conséquences des procédures de retour arrière. Vous serez peut-être en mesure de négocier un délai approprié pour apporter les modifications.

Basculement et retour en arrière dans les services Azure

Bien qu’il soit important de comprendre le fonctionnement du basculement en général, gardez à l’esprit que chaque service Azure peut aborder le basculement et le rétablissement 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 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 prendre en charge le basculement pour vous.

Lorsque vous concevez votre propre solution qui combine plusieurs services Azure ensemble, 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 exacts que vous utilisez, vous devrez peut-être planifier votre propre stratégie de basculement pour passer entre les déploiements dans 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

• Découvrez la responsabilité partagée de la fiabilité.
• Découvrez les recommandations pour la conception multirégion à haute disponibilité dans le Azure Well-Architected Framework.