Partager via

Redondance globale du routage pour les applications web stratégiques

Importante

La conception d’implémentations de redondance qui traitent des pannes de plateforme globales pour une architecture stratégique peut être complexe et coûteuse. En raison des problèmes potentiels qui peuvent survenir avec cette conception, examinez soigneusement les compromis.

Dans la plupart des cas, vous n’aurez pas besoin de l’architecture décrite dans cet article.

Les systèmes stratégiques s’efforcent de minimiser les points de défaillance uniques en créant des capacités de redondance et d’auto-guérison dans la solution autant que possible. Tout point d’entrée unifié du système peut être considéré comme un point de défaillance. Si ce composant rencontre une panne, l’ensemble du système est hors connexion pour l’utilisateur. Lorsque vous choisissez un service de routage, il est important de prendre en compte la fiabilité du service lui-même.

L’architecture d’une application stratégique utilise Azure Front Door en raison de son contrat de niveau de service (SLA) haute disponibilité et d’un ensemble de fonctionnalités riche :

  • Acheminer le trafic vers plusieurs régions, dans un modèle actif-actif ou actif-passif
  • Basculement transparent à l’aide de TCP anycast
  • Servir du contenu statique à partir de nœuds de périphérie à l’aide de réseaux de distribution de contenu intégrés (CDN)
  • Bloquer l’accès non autorisé avec le pare-feu d’applications web intégré

Pour plus d’informations sur les fonctionnalités d’Azure Front Door, consultez Accélérer et sécuriser votre application web avec Azure Front Door.

Azure Front Door est conçu pour fournir la plus grande résilience et disponibilité pour nos clients externes, mais également pour plusieurs propriétés dans Microsoft. Bien que Microsoft offre un contrat de niveau de service (SLA) de premier plan pour Azure Front Door, si vous disposez d’une application stratégique qui exige un contrat SLA encore plus élevé, vous devez implémenter des chemins de trafic d’entrée supplémentaires.

De nombreuses grandes organisations et propriétés web à profil élevé utilisent cette approche pour garantir la disponibilité la plus élevée possible et optimiser les performances de livraison. Toutefois, la poursuite d’un SLO plus élevé s’accompagne de coûts importants, d'une surcharge de travail opérationnel, et peut réduire par inadvertance votre fiabilité globale. Examinez attentivement les compromis et les problèmes potentiels que le chemin d’accès alternatif peut introduire dans d’autres composants qui se trouvent sur le chemin critique. Même si l’impact de l’indisponibilité est important, la complexité peut dépasser l’avantage.

Une approche consiste à définir un chemin secondaire avec d’autres services, qui devient le chemin principal quand Azure Front Door n’est pas disponible. Ne traitez pas la parité des fonctionnalités avec Azure Front Door comme une exigence stricte. Hiérarchiser les fonctionnalités dont vous avez absolument besoin à des fins de continuité d’activité, même potentiellement exécutées dans une capacité limitée.

Plusieurs stratégies peuvent atteindre une haute disponibilité dans les charges de travail web. L'approche suivante fournit une solution d'urgence manuelle simple qui vous permet de basculer rapidement en cas de panne et de rétablir le trafic vers Azure Front Door après avoir vérifié que le service est opérationnel.

Cet article décrit les stratégies de routage global. Ces stratégies utilisent Azure Traffic Manager pour diriger le trafic vers un autre routeur lorsque Azure Front Door n’est pas disponible.

Approche

Ce diagramme d’architecture montre une approche générale qui a plusieurs chemins de trafic redondants.

Diagramme montrant traffic Manager qui dirige les demandes vers Azure Front Door ou vers un autre service, puis vers le serveur d’origine.

Cette approche introduit plusieurs composants et fournit des conseils qui apportent des modifications importantes associées à la livraison de vos applications web :

  • Traffic Manager dirige le trafic vers Azure Front Door ou vers votre autre service choisi.

    Traffic Manager est un équilibreur de charge global basé sur DNS (Domain Name System). L’enregistrement CNAME de votre domaine pointe vers Traffic Manager, qui détermine la destination en fonction de la façon dont vous configurez sa méthode de routage. Pour une architecture stratégique, nous recommandons la méthode de routage pondérée . Vous pouvez configurer cette méthode pour envoyer un ou plusieurs trafics vers différents points de terminaison. Dans les opérations normales, tout votre trafic est généralement acheminé via Azure Front Door.

    Nous vous recommandons de désactiver la surveillance des points de terminaison dans Traffic Manager. Créez des procédures pour détecter quand votre chemin de trafic principal devient indisponible et basculez le trafic vers le chemin secondaire.

    Vous pouvez également utiliser un autre système de routage du trafic global. Mais Traffic Manager fonctionne bien pour de nombreuses situations.

  • Vous avez deux chemins d’entrée :

    • Azure Front Door fournit le chemin principal. Dans les opérations normales, il traite et route tout ou la plupart du trafic de votre application.

    • Un autre routeur sert de sauvegarde pour Azure Front Door. Le trafic transite par ce chemin secondaire si Azure Front Door devient indisponible.

    Le service spécifique que vous sélectionnez pour le routeur secondaire dépend de nombreux facteurs. Vous pouvez choisir d’utiliser des services natifs Azure ou des services externes. Ces articles fournissent des options natives Azure si possible pour éviter d’ajouter une complexité opérationnelle supplémentaire à la solution. Si vous utilisez des services externes, vous devez utiliser plusieurs plans de contrôle pour gérer votre solution.

  • Vos serveurs d’applications d’origine doivent être prêts à accepter le trafic de l’un ou l’autre des services. Réfléchissez à la façon dont vous sécurisez le trafic vers votre origine, ainsi que les responsabilités qu’Azure Front Door et d’autres services en amont fournissent. Assurez-vous que votre application peut gérer le trafic à partir du chemin d’accès via lequel votre trafic transite.

Compromis

Bien que cette stratégie d’atténuation puisse rendre l’application disponible pendant les pannes de plateforme, il existe des compromis importants. Vous devez évaluer les avantages potentiels par rapport aux coûts connus et prendre une décision éclairée sur la valeur de ces avantages.

  • Coût financier : lorsque vous déployez plusieurs chemins redondants sur votre application, vous devez prendre en compte le coût du déploiement et de l’exécution des ressources. Nous fournissons deux exemples de scénarios pour différents cas d’usage, chacun ayant un profil de coût différent.

  • Complexité opérationnelle : chaque fois que vous ajoutez des composants supplémentaires à votre solution, vous augmentez votre surcharge de gestion. Toute modification apportée à un composant peut affecter d’autres composants.

    Par exemple, si vous utilisez de nouvelles fonctionnalités d’Azure Front Door, vous devez vérifier si votre autre chemin de trafic fournit également une fonctionnalité équivalente. Si ce n’est pas le cas, décidez comment gérer la différence de comportement entre les deux chemins de trafic. Dans les applications réelles, ces complexités peuvent avoir un coût élevé et présenter un risque majeur pour la stabilité de votre système.

  • Performances : cette conception nécessite des recherches CNAME supplémentaires pendant la résolution de noms. Dans la plupart des applications, ce n’est pas une préoccupation significative, mais vous devez évaluer si les performances de votre application sont affectées par l’introduction de couches supplémentaires dans votre chemin d’entrée.

  • Coût des opportunités : La conception et l’implémentation de chemins d’entrée redondants nécessitent un investissement important en ingénierie, ce qui entraîne finalement un coût potentiel pour le développement de fonctionnalités et d’autres améliorations de plateforme.

Avertissement

Si vous n’êtes pas prudent dans la façon dont vous concevez et implémentez une solution de haute disponibilité complexe, vous pouvez réellement rendre votre disponibilité pire. L’augmentation du nombre de composants dans votre architecture augmente le nombre de points d’échec. Cela signifie également que vous avez un niveau plus élevé de complexité opérationnelle. Lorsque vous ajoutez des composants supplémentaires, chaque modification que vous apportez doit être soigneusement examinée pour comprendre comment elle affecte votre solution globale.

Disponibilité de Traffic Manager

Traffic Manager est un service fiable avec un contrat SLA de pointe, mais la gestion du trafic a besoin de mesures supplémentaires pour fournir une disponibilité ininterrompue dans toutes les situations. Si Traffic Manager n’est pas disponible, vos utilisateurs n’ont peut-être pas accès à votre application, même si Azure Front Door et votre autre service sont disponibles. Planifiez la façon dont votre solution peut continuer à fonctionner dans ces circonstances.

Traffic Manager retourne des réponses DNS pouvant être mises en cache. Si le temps de vie (TTL) sur vos enregistrements DNS autorise la mise en cache, les pannes courtes de Traffic Manager peuvent ne pas être un problème. Cela est dû au fait que les résolveurs DNS en aval ont peut-être mis en cache une réponse précédente. Vous devez planifier des pannes prolongées. Vous pouvez choisir de reconfigurer manuellement vos serveurs DNS pour diriger les utilisateurs vers Azure Front Door si Traffic Manager n’est pas disponible.

Cohérence du routage du trafic

Il est important de comprendre les capacités et les fonctionnalités d'Azure Front Door sur lesquelles vous comptez si vous allez également utiliser un autre service. Lorsque vous choisissez l’autre service, choisissez les fonctionnalités minimales dont vous avez besoin et omettez d’autres fonctionnalités lorsque votre solution est en mode détérioré.

Lors de la planification d’un autre chemin de trafic, voici quelques questions clés à prendre en compte :

  • Utilisez-vous les fonctionnalités de mise en cache d’Azure Front Door ? Si la mise en cache n’est pas disponible, vos serveurs d’origine peuvent-ils suivre votre trafic ?
  • Utilisez-vous le moteur de règles Azure Front Door pour effectuer une logique de routage personnalisée ou réécrire des demandes ?
  • Utilisez-vous le pare-feu d’applications web Azure Front Door (WAF) pour sécuriser vos applications ?
  • Limitez-vous le trafic en fonction de l’adresse IP ou de la zone géographique ?
  • Qui émet et gère vos certificats TLS ?
  • Comment restreindre l’accès à vos serveurs d’applications d’origine pour vous assurer qu’il provient d’Azure Front Door ? Utilisez-vous Private Link ou utilisez-vous des adresses IP publiques avec des balises de service et des en-têtes d’identificateur ?
  • Vos serveurs d’applications acceptent-ils le trafic depuis un autre endroit que Azure Front Door ? S’ils le font, quels protocoles acceptent-ils ?
  • Vos clients utilisent-ils la prise en charge HTTP/2 d’Azure Front Door ?

Pare-feu d’applications web (WAF)

Si vous utilisez le WAF d’Azure Front Door pour protéger votre application, pensez à ce qui se passe si le trafic ne passe pas par Azure Front Door.

Si votre autre chemin fournit également un WAF, tenez compte des questions suivantes :

  • Peut-il être configuré de la même façon que votre WAF Azure Front Door ?
  • Doit-il être paramétré et testé indépendamment pour réduire la probabilité de détections de faux positifs ?

Avertissement

Vous pouvez choisir de ne pas utiliser un WAF pour votre autre chemin d’entrée. Cette approche peut prendre en charge la cible de fiabilité de l’application. Mais il ne suit pas de bonne pratique de sécurité, et nous ne le recommandons pas.

Considérez l’inconvénient d’accepter le trafic à partir d’Internet sans aucun contrôle. Si un attaquant découvre un chemin de trafic secondaire non protégé vers votre application, il peut envoyer du trafic malveillant via votre chemin secondaire, même lorsque le chemin principal inclut un WAF.

Il est préférable de sécuriser tous les chemins d’accès à vos serveurs d’applications.

Considérations supplémentaires relatives à la haute disponibilité

Lorsque vous concevez une architecture web stratégique, de nombreux facteurs peuvent affecter la disponibilité et les performances de votre application. Bon nombre de ces facteurs vont au-delà de la configuration et des fonctionnalités d’Azure Front Door, et se rapportent plutôt à la conception globale de l’écosystème et de la solution.

Noms de domaine et DNS

Votre application stratégique doit utiliser des noms de domaine personnalisés pour contrôler la façon dont le trafic transite vers votre application et réduire les dépendances d’un seul fournisseur. Tenez compte des points suivants lorsque vous planifiez votre approche DNS :

  • Service DNS : Utilisez un service DNS de haute qualité et résilient pour votre nom de domaine, comme Azure DNS. Si les serveurs DNS de votre nom de domaine ne sont pas disponibles, les utilisateurs ne peuvent pas atteindre votre service.

  • Résolveurs DNS : Nous vous recommandons d’utiliser plusieurs résolveurs DNS pour augmenter la résilience globale.

  • Domaines Apex : Lorsque vous utilisez Traffic Manager, vous utilisez un CNAME pour pointer votre nom de domaine vers votre profil Traffic Manager. Les normes DNS ne vous permettent pas de créer un CNAME à l’apex (ou à la racine) d’un domaine. Hébergez votre domaine DNS sur Azure DNS et utilisez des enregistrements d’alias pour pointer vers votre profil Traffic Manager.

  • Chaînage CNAME : Les solutions qui combinent Traffic Manager, Azure Front Door et d’autres services utilisent un processus de résolution CNAME DNS multicouche, également appelé chaînage CNAME. Par exemple, lorsque vous résolvez votre propre domaine personnalisé, vous pouvez voir cinq enregistrements CNAME ou plus avant qu’une adresse IP soit retournée.

    L’ajout de liens supplémentaires à une chaîne CNAME peut affecter les performances de résolution de noms DNS. Toutefois, les réponses DNS sont généralement mises en cache, ce qui réduit l’impact sur les performances.

Certificats TLS

Pour une application stratégique, il est recommandé de provisionner et d’utiliser vos propres certificats TLS au lieu des certificats managés fournis par Azure Front Door. Vous réduisez le nombre de problèmes potentiels liés à cette architecture complexe.

Voici quelques avantages :

  • Pour émettre et renouveler des certificats TLS managés, Azure Front Door vérifie votre propriété du domaine. Le processus de vérification du domaine suppose que les enregistrements CNAME de votre domaine pointent directement vers Azure Front Door. Mais cette hypothèse n’est souvent pas correcte. L’émission et le renouvellement de certificats TLS managés sur Azure Front Door peuvent ne pas fonctionner correctement et vous augmentez le risque de pannes en raison de problèmes de certificat TLS.

  • Même si vos autres services fournissent des certificats TLS managés, ils peuvent ne pas être en mesure de vérifier la propriété du domaine.

  • Si chaque service obtient ses propres certificats TLS managés indépendamment, des problèmes peuvent se produire. Par exemple, les utilisateurs peuvent ne pas s’attendre à voir les certificats TLS émis par différentes autorités ou certificats avec des dates d’expiration ou des empreintes numériques différentes.

Toutefois, il existe des opérations supplémentaires liées au renouvellement et à la mise à jour de vos certificats avant leur expiration.

Sécurité de l’origine

Lorsque vous configurez votre origine pour accepter uniquement le trafic via Azure Front Door, vous bénéficiez d’une protection contre les attaques DDoS de couche 3 et de couche 4. Azure Front Door répond uniquement au trafic HTTP valide, ce qui permet également de réduire votre exposition à de nombreuses menaces basées sur le protocole. Si vous modifiez votre architecture pour autoriser d’autres chemins d’entrée, vous devez évaluer si vous avez accidentellement augmenté l’exposition de votre origine aux menaces.

Si vous utilisez Private Link pour vous connecter à partir d’Azure Front Door à votre serveur d’origine, comment le trafic transite-t-il par votre autre chemin d’accès ? Pouvez-vous utiliser des adresses IP privées pour accéder à vos origines ou devez-vous utiliser des adresses IP publiques ?

Si votre origine utilise la balise de service Azure Front Door et l’en-tête X-Azure-FDID pour vérifier que le trafic a transité par Azure Front Door, envisagez comment vos origines peuvent être reconfigurées pour valider que le trafic a transité par l’un de vos chemins valides. Vous devez vérifier que vous n’avez pas ouvert accidentellement votre origine au trafic via d’autres chemins, y compris à partir des profils Azure Front Door d’autres clients.

Lorsque vous planifiez votre sécurité d’origine, vérifiez si le chemin de trafic alternatif s’appuie sur l’approvisionnement d’adresses IP publiques dédiées. Cela peut nécessiter un processus déclenché manuellement pour mettre le chemin de sauvegarde en ligne.

S’il existe des adresses IP publiques dédiées, déterminez si vous devez implémenter Azure DDoS Protection pour réduire le risque d’attaques par déni de service contre vos origines. Déterminez également si vous devez implémenter le Pare-feu Azure ou un autre pare-feu capable de vous protéger contre diverses menaces réseau. Vous pouvez également avoir besoin de stratégies de détection d’intrusion supplémentaires. Ces contrôles peuvent être des éléments importants dans une architecture multipathe plus complexe.

Modélisation de la santé

La méthodologie de conception critique nécessite un modèle d’intégrité du système qui vous donne une observabilité globale de la solution et de ses composants. Lorsque vous utilisez plusieurs chemins d’entrée de trafic, vous devez surveiller l’intégrité de chaque chemin. Si votre trafic est redirigé vers le chemin d’entrée secondaire, votre modèle d’intégrité doit refléter le fait que le système est toujours opérationnel, mais qu’il s’exécute dans un état dégradé.

Incluez ces questions dans la conception de votre modèle de santé :

  • Comment les différents composants de votre solution surveillent-ils l’intégrité des composants en aval ?
  • Quand les moniteurs de santé doivent-ils considérer les composants en aval comme non sains ?
  • Combien de temps faut-il pour détecter une panne ?
  • Une fois qu’une panne est détectée, combien de temps faut-il pour que le trafic soit routé via un autre chemin ?

Surveillance de la santé

Les solutions d’équilibrage de charge globales vous permettent de basculer vers une plateforme secondaire si une panne se produit. Traffic Manager fonctionne bien pour la plupart des scénarios.

Lorsque vous utilisez Traffic Manager avec Azure Front Door, utilisez votre propre solution de supervision externe ou personnalisée pour détecter quand Azure Front Door devient indisponible et lance vos processus de réponse. Azure Front Door est un système distribué globalement qui utilise la mise en réseau anycast. Vous devez donc exécuter des vérifications de connectivité à partir des mêmes régions géographiques que vos clients.

Importante

Pour les charges de travail globales nécessitant une validation d’intégrité à partir de plusieurs zones géographiques, désactivez la surveillance des points de terminaison Traffic Manager et utilisez plutôt des procédures de basculement manuelles.

Préparez également à déclencher manuellement vos procédures de réponse si vos systèmes de surveillance ne détectent pas le problème.

Procédures de réponse

Si vos systèmes de surveillance détectent qu’Azure Front Door n’est pas disponible, reconfigurez Traffic Manager pour diriger tout le trafic via votre autre chemin. Utilisez l’une des approches suivantes :

Importante

La redirection de tout le trafic via le chemin secondaire est une solution à court terme qui permet la continuité de l’activité pendant une panne en cours. Une fois la panne résolue, restaurez les opérations normales via Azure Front Door dès que possible.

Plusieurs facteurs influencent la durée pendant laquelle la panne affecte votre trafic, y compris les facteurs suivants :

  • Valeurs de durée de vie des enregistrements DNS

  • Source de détection de panne (Traffic Manager ou surveillance personnalisée)

  • Fréquence de contrôle d’intégrité

  • Seuil d’échec de vérification de l’intégrité avant que le système ne reroute le trafic

  • Durée du cache DNS client et en amont pour les réponses Traffic Manager

Vous devez également déterminer quels facteurs se trouvent dans votre contrôle et si les services en amont au-delà de votre contrôle peuvent affecter l’expérience utilisateur. Par exemple, même si vous utilisez un faible TTL sur vos enregistrements DNS, les caches DNS en amont peuvent toujours servir des réponses obsolètes pendant une durée plus longue que nécessaire. Ce comportement pourrait accentuer les effets d'une panne ou donner l'impression que votre application est indisponible, même lorsque Traffic Manager a déjà transféré les requêtes vers le chemin de trafic alternatif.

Conseil / Astuce

Les solutions stratégiques nécessitent des approches de basculement automatisées si possible. Les processus de basculement manuels sont trop lents pour maintenir une réactivité suffisante de l’application.

Reportez-vous à : Zone de conception critique : Modélisation de la santé

Processus de reconfiguration résilients

Lorsque vous envisagez d’utiliser une solution qui utilise un chemin d’entrée redondant, planifiez également le déploiement ou la configuration de vos services lorsqu’ils s’exécutent dans un état détérioré. Pour la plupart des services Azure, les contrats SLA s’appliquent au temps d’activité du service lui-même, et non aux opérations de gestion ni aux déploiements. Déterminez si vous devez rendre vos processus de déploiement et de configuration résilients aux pannes de service.

Lorsque vous planifiez votre stratégie de basculement, évitez une dépendance à un seul outil comme le portail Azure au cas où sa connectivité est interrompue. Découvrez comment utiliser des outils comme Azure CLI, Azure PowerShell ou les API REST pour effectuer des tâches de reconfiguration, telles que la réacheminement de votre trafic. Pour plus d’informations sur les exemples de commandes pour les scripts de basculement, consultez Procédures de réponse.

Vous devez également prendre en compte le nombre de plans de contrôle indépendants avec lesquels vous devez interagir pour gérer votre solution. Lorsque vous utilisez des services Azure, Azure Resource Manager fournit un plan de contrôle unifié et cohérent. Toutefois, si vous utilisez un service externe pour acheminer le trafic, vous devrez peut-être utiliser un plan de contrôle distinct pour configurer le service, ce qui introduit une plus grande complexité opérationnelle.

Avertissement

L’utilisation de plusieurs plans de contrôle introduit la complexité et le risque pour votre solution. Chaque point de différence augmente la probabilité que quelqu’un manque accidentellement un paramètre de configuration ou applique des configurations différentes aux composants redondants. Assurez-vous que vos procédures opérationnelles atténuent ce risque.

Reportez-vous à : Zone de conception critique : Déploiement sans temps d’arrêt

Validation continue

Pour une solution stratégique, vos pratiques de test doivent vérifier que votre solution répond à vos besoins, quel que soit le chemin d’accès que votre trafic d’application transite. Considérez chaque partie de la solution et comment vous la testez pour chaque type de panne.

Vérifiez que vos processus de test incluent les éléments suivants :

  • Pouvez-vous vérifier que le trafic est correctement redirigé via le chemin d’accès alternatif lorsque le chemin principal n’est pas disponible ?
  • Les deux chemins peuvent-ils prendre en charge le niveau de trafic de production que vous prévoyez de recevoir ? Le chemin secondaire est-il prêt à recevoir le trafic de production avec un avertissement minimal ou sans avertissement ?
  • Les deux chemins sont-ils correctement sécurisés pour éviter d’ouvrir ou d’exposer des vulnérabilités lorsque vous êtes dans un état détérioré ?

Reportez-vous à : Zone de conception critique : Validation continue

Scénarios courants

Voici les scénarios courants dans lesquels cette conception peut être utilisée :

  • La distribution de contenu globale s’applique généralement aux applications de distribution de contenu statique, de média et de commerce électronique à grande échelle. Dans ce scénario, la mise en cache est une partie essentielle de l’architecture de la solution, et les échecs de mise en cache peuvent entraîner une dégradation significative des performances ou de la fiabilité.

  • L’entrée HTTP globale s’applique généralement aux applications et API dynamiques stratégiques. Dans ce scénario, l’exigence principale consiste à router le trafic vers le serveur d’origine de manière fiable et efficace. Souvent, un WAF est un contrôle de sécurité important utilisé dans ces solutions.

Avertissement

Si vous n’êtes pas prudent dans la façon dont vous concevez et implémentez une solution multi-entrée complexe, vous pouvez réduire davantage la disponibilité. L’augmentation du nombre de composants dans votre architecture augmente le nombre de points d’échec. Cela signifie également que vous avez un niveau plus élevé de complexité opérationnelle. Lorsque vous ajoutez des composants supplémentaires, chaque modification que vous apportez doit être soigneusement examinée pour comprendre comment elle affecte votre solution globale.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

  • Dave Burkhardt | Responsable du programme principal, Azure Front Door
  • John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques
  • Akhil Karmalkar | Responsable du programme principal, Azure Front Door
  • Priyanka Wilkins | Principal Content Developer, Azure Patterns &Practices

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

  • Last updated on