Partage via

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

  • Article

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.

Notes

Si vous utilisez des bases de données et des pools élastiques Premium ou Critique pour l’entreprise, vous pouvez les rendre résistants aux pannes régionales en les transformant en configuration de déploiement redondante dans une zone. Consultez Bases de données redondantes interzone.

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).

Notes

Azure Traffic Manager est utilisé dans cet article aux fins d’illustration uniquement. Vous pouvez utiliser toute solution d’équilibrage de charge qui prend en charge la méthode de routage prioritaire.

Le diagramme suivant illustre cette configuration avant une panne :

Scénario 1. Configuration avant la 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.

Notes

Toutes les transactions validées après le basculement sont perdues lors de la reconnexion. Une fois le basculement terminé, l’application de la région B est en mesure de se reconnecter et de redémarrer le traitement des demandes utilisateur. L’application web et la base de données primaire se trouvent maintenant dans la région B et restent colocalisées.

Scénario 1. 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.

Notes

Pour une récupération d’urgence, nous recommandons la configuration dans laquelle le déploiement de l’application est limité à deux régions. En effet, la plupart des zones géographiques Azure comptent seulement deux régions. Cette configuration ne protège pas votre application d’une défaillance grave simultanée des deux régions. Dans le cas peu probable d’une telle défaillance, vous pouvez restaurer vos bases de données dans une région tierce à l’aide de l’opération de géo-restauration. Pour plus d’informations, consultez Aide sur la récupération d'urgence Azure SQL Database.

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.

Notes

Une fois la panne atténuée, Traffic Manager commencera à acheminer les connexions vers l’application dans la région A en tant que point de terminaison de priorité plus élevée. Si vous envisagez de conserver la base de données principale dans la région B pendant un certain temps, vous devez modifier la table de priorité dans le profil Traffic Manager en conséquence.

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

Scénario 1. Configuration après 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 :

Scénario 2. Configuration avant la 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.

Notes

Si la panne qui affecte la région primaire est résolue avant la fin de la période de grâce, Traffic Manager détecte la restauration de la connectivité dans la région primaire et rebascule le trafic utilisateur vers l’instance de l’application dans la région A. Cette instance de l’application reprend et fonctionne en mode lecture-écriture en s’appuyant sur la base de données primaire de la région A, comme illustré dans le diagramme précédent.

Scénario 2. Phases de récupération d’urgence.

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 :

Scénario 2. 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).

Modèle RPO ERT
Déploiement actif / passif pour la récupération d’urgence avec accès à la base de données colocalisée Accès en lecture-écriture < 5 s Temps de détection des défaillances + TTL du DNS
Déploiement actif / actif pour l’équilibrage de charge d’applications Accès en lecture-écriture < 5 s Temps de détection des défaillances + TTL du DNS
Déploiement actif / passif pour la conservation des données Accès en lecture seule < 5 s Accès en lecture seule = 0
Accès en lecture-écriture = 0 Accès en lecture-écriture = temps de détection de défaillances + période de grâce en cas de risque de perte de données

Étapes suivantes