Conception de services disponibles à l’échelle mondiale à l’aide d’Azure SQL Database

S’applique à : Azure SQL Database

Pour créer et déployer des services cloud avec la base de données Azure SQL, utilisez une géoréplication active ou des groupes de basculement pour fournir une tolérance aux pannes régionales et aux défaillances graves. La même fonctionnalité vous permet de créer des applications distribuées mondialement et optimisées pour l’accès local aux données. Cet article aborde les modèles d’application courants et présente les avantages et inconvénients de chacun d’eux.

Scénario 1 : Utilisation de deux régions Azure pour la continuité d’activité avec temps d’arrêt minimal

Dans ce scénario, les applications ont les caractéristiques suivantes :

• Chaque application est active dans une région Azure
• Toutes les sessions de base de données nécessitent un accès aux données en lecture et écriture
• La couche Web et la couche Données doivent être colocalisées pour réduire la latence et les coûts liés au trafic
• Les temps d’arrêt représentent un plus grand risque pour ces applications que la perte de données

Dans ce cas, la topologie de déploiement d’applications est optimisée pour la gestion des sinistres régionaux lorsque tous les composants d’application doivent être basculés en même temps. Le diagramme ci-dessous illustre cette topologie. Pour assurer la géoredondance, les ressources de l’application sont déployées dans la région A et la région B. Toutefois, les ressources de la région B sont utilisées seulement en cas de défaillance de la région A. Un groupe de basculement est configuré entre les deux régions pour gérer le basculement, la réplication et la connectivité à la base de données. Le service web des deux régions est configuré pour accéder à la base de données via l’écouteur en lecture-écriture <nom-groupe-basculement>.database.windows.net (1). Azure Traffic Manager est configuré pour utiliser la méthode de routage prioritaire (2).

Le diagramme suivant illustre cette configuration avant une panne :

Après une panne dans la région primaire, SQL Database détecte que la base de données primaire n’est pas accessible et déclenche un basculement vers la région secondaire conformément aux paramètres de la stratégie de basculement automatique (1). Selon le contrat de niveau de service (SLA) de votre application, vous pouvez choisir de configurer une période de grâce entre la détection de la panne et le basculement proprement dit. Il est possible qu’Azure Traffic Manager démarre le basculement de point de terminaison avant que le groupe de basculement ne déclenche le basculement de la base de données. Dans ce cas, l’application web ne peut pas se reconnecter immédiatement à la base de données. Toutefois, une reconnexion automatique est effectuée dès que le basculement de la base de données est terminé. Lorsque la région défaillante est restaurée et de nouveau en ligne, l’ancienne région primaire se reconnecte automatiquement en tant que nouvelle région secondaire. Le diagramme ci-dessous illustre la configuration après le basculement.

Si une panne se produit dans la région B, le processus de réplication entre la base de données primaire et la base de données secondaire est suspendu, mais le lien entre les deux reste intact (1). Le trafic géré détecte que la connectivité à la Région B est interrompue et marque l’application web de point de terminaison 2 comme étant Détériorée (2). Les performances de l’application ne sont pas impactées dans ce cas, mais la base de données devient exposée, et par conséquent, est soumise à un risque plus élevé de perte de données en cas de défaillance de la région A.

Une fois la panne atténuée, la base de données secondaire est automatiquement resynchronisée avec la base de données primaire. Pendant la synchronisation, les performances de la base de données principale peuvent être impactées. L’impact dépend de la quantité de données que la nouvelle base de données primaire a acquises depuis le basculement.

Le diagramme suivant illustre une panne dans la région secondaire :

Les avantages clés de ce modèle de conception sont les suivants :

• La même application web est déployée dans les deux régions sans configuration régionale. Elle ne nécessite pas de logique supplémentaire pour gérer le basculement.
• Les performances de l’application ne sont pas impactées par le basculement, car l’application web et la base de données sont toujours colocalisées.

Le principal inconvénient à cela est que les ressources de l’application dans la région B sont, la plupart du temps, sous-utilisées.

Scénario 2 : Régions Azure pour la continuité d’activité avec conservation maximale des données

Cette option est idéale pour les applications dotées des caractéristiques suivantes :

• Toute perte de données constitue un risque élevé pour l’entreprise. Le basculement de la base de données ne peut être utilisé qu’en dernier recours, si la panne est due à une défaillance grave.
• L’application prend en charge les opérations en modes lecture seule et lecture-écriture et peut fonctionner en mode lecture seule pendant une période donnée.

Dans ce modèle, l’application bascule vers le mode lecture seule lorsque les connexions de lecture-écriture commencent à recevoir des erreurs d’expiration du délai d’attente. L’application web est déployée dans les deux régions et inclut une connexion au point de terminaison de l’écouteur en lecture-écriture et une autre connexion au point de terminaison de l’écouteur en lecture seule (1). Le profil Traffic Manager doit utiliser le routage prioritaire. La surveillance des points de terminaison doit être activée pour le point de terminaison de l’application dans chaque région (2).

Le diagramme suivant illustre cette configuration avant une panne :

Si Traffic Manager détecte une défaillance de connectivité pour la région A, il bascule automatiquement le trafic utilisateur vers l’instance de l’application dans la région B. Avec ce modèle, il est important de définir la période de grâce en cas de risque de perte de données sur une valeur suffisamment élevée, par exemple 24 heures. Vous empêcherez ainsi toute perte de données si la panne est résolue durant ce laps de temps. Lorsque l’application web de la région B est activée, les opérations en lecture-écriture se mettent à échouer. À ce stade, elle doit basculer vers le mode lecture seule (1). Avec ce mode, les requêtes sont automatiquement acheminées vers la base de données secondaire. Si la panne est due à une défaillance grave, elle ne pourra très probablement pas être résolue pendant la période de grâce. Lorsque cette période expire, le groupe de basculement déclenche le basculement. Ensuite, l’écouteur en lecture-écriture redevient disponible et les connexions à l’écouteur cessent d’échouer (2). Le diagramme suivant illustre les deux étapes du processus de récupération.

Si une panne se produit dans la région B, Traffic Manager détecte la défaillance de l’application du point de terminaison 2 dans la région B et la marque comme étant détériorée (1). Entre-temps, le groupe de basculement bascule l’écouteur en lecture seule vers la région A (2). Cette panne n’a pas d’impact sur l’expérience des utilisateurs finaux. Toutefois, la base de données primaire est exposée lors de la panne. Le diagramme suivant illustre une panne dans la région secondaire :

Une fois la panne résolue, la base de données secondaire est immédiatement synchronisée avec la base de données primaire l’écouteur de lecture seule est rebasculé vers la base de données secondaire de la région B. Lors de la synchronisation, les performances de la base de données primaire peuvent être légèrement affectées selon la quantité de données à synchroniser.

Ce modèle de conception offre plusieurs avantages:

• Il évite la perte de données pendant les pannes temporaires.
• Le temps d’arrêt dépend uniquement de la vitesse selon laquelle Traffic Manager détecte le problème de connectivité, paramètre configurable.

L’inconvénient est que l’application doit être en mesure de fonctionner en lecture seule.

Planification de la continuité d’activité : choisir une conception d’application pour la récupération d’urgence cloud

Votre stratégie de récupération d’urgence cloud spécifique peut combiner ou étendre ces modèles de conception afin de mieux répondre aux besoins de votre application. Comme mentionné précédemment, la stratégie que vous choisissez est basée sur le contrat de niveau de service que vous souhaitez proposer à vos clients et sur la topologie de déploiement d’applications. Pour vous aider à prendre votre décision, le tableau suivant compare les choix en fonction de l’objectif de point de récupération (RPO) et du temps de récupération estimé (ERT).

Étapes suivantes

• Pour une vue d’ensemble de la continuité des activités et des scénarios, consultez Vue d’ensemble de la continuité des activités
• Pour plus d’informations sur la géoréplication active, voir la section Géoréplication active.
• Pour en savoir plus sur les groupes de basculement, reportez-vous à Groupes de basculement.
• Pour plus d’informations sur la géoréplication active avec des pools élastiques, consultez Stratégies de récupération d’urgence de pool élastique.