Méthodes de routage du trafic vers l’origine

Important

Azure Front Door (classique) sera mis hors service le 31 mars 2027. Pour éviter toute interruption de service, il est important de migrer vos profils Azure Front Door (classique) vers le niveau Azure Front Door Standard ou Premium d’ici mars 2027. Pour plus d’informations, consultez Mise hors service d'Azure Front Door (classique).

Azure Front Door prend en charge quatre méthodes différentes de routage du trafic pour déterminer comment votre trafic HTTP/HTTPS est distribué entre différentes origines. Lorsque les requêtes de vos clients atteignent les emplacements de périphérie Front Door, la méthode de routage configurée est appliquée pour veiller à ce que les requêtes soient transmises à la meilleure ressource de serveur principal.

Notes

Une origine et un groupe d’origine dans cet article font référence au serveur principal et au pool principal de la configuration Azure Front Door (classique).

Les quatre méthodes de routage du trafic sont les suivantes :

• Latence : le routage basé sur la latence garantit que les requêtes sont envoyées aux origines ayant la latence la plus faible acceptables dans une plage de sensibilité. En d’autres termes, les demandes sont envoyées à l’ensemble d’origines le plus proche en ce qui concerne la latence du réseau.

• Priorité : une priorité peut être définie à vos origines lorsque vous souhaitez configurer une origine principale pour traiter tout le trafic. L’origine secondaire peut servir de sauvegarde en cas d'indisponibilité de l’origine principale.

• Pondération : Une valeur pondérée peut être assignée à vos origines lorsque vous souhaitez répartir le trafic sur un ensemble d’origines uniformément ou selon les coefficients de pondération. Le trafic est distribué par la valeur de pondération si les latences des origines sont comprises dans la plage de sensibilité de latence acceptable dans le groupe d’origine.

• Affinité de session : Vvus pouvez configurer l'affinité de session de vos hôtes ou domaines front-end afin que les requêtes d'un même utilisateur final soient envoyées à la même origine.

Notes

Nom du point de terminaison dans le niveau Standard et Premium d’Azure Front Door est appelé hôte frontal dans Azure Front Door (classique).

Toutes les configurations Front Door disposent du monitoring de l’intégrité du serveur principal et du basculement global instantané automatisé. Pour plus d’informations, consultez Monitoring des serveurs principaux Front Door. Azure Front Door peut être utilisé avec une seule méthode de routage. En fonction des besoins de votre application, vous pouvez combiner plusieurs méthodes de routage pour créer une topologie de routage optimale.

Notes

Lorsque vous utilisez le moteur de règles Azure Front Door, vous pouvez configurer une règle pour remplacer les configurations d’itinéraires dans le niveau Standard et Premium d’Azure Front Door ou remplacer le pool principal dans Azure Front Door (classique) pour une demande. Le groupe d’origine ou le pool principal défini par le moteur de règles remplace le processus de routage décrit dans cet article.

Flux de décision global

Le diagramme suivant montre le processus global de décision :

Les étapes de décision sont les suivantes :

1. Origines disponibles : Tout d'abord, sélectionnez toutes les origines qui sont signalés intègres (200 OK) par la sonde d'intégrité.
   • Exemple : supposez qu’il y a six origines A, B, C, D, E et F, parmi lesquelles C est non intègre et E est désactivée. la liste des origines disponibles est A, B, D et F.
2. Priorité :Sont sélectionnées les priorités disposant de la priorité la plus élevée parmi celles qui sont disponibles.
   • Exemple : supposez que la priorité des origines A, B et D est de 1 et celle de l’origine F de 2. Puis, les origines sélectionnées sont A, B et D.
3. Signal de latence (basé sur la sonde d’intégrité) : Sélectionnez les origines dans la plage de latence autorisée à partir de l’environnement Front Door où la demande est arrivée. Ce signal est basé sur le paramètre de sensibilité à la latence sur le groupe d’origines, et sur la latence des origines plus proches.
   • Exemple : supposons que Front Door ait mesuré la latence de l’environnement où la requête est arrivée à l’origine A à 15 ms, tandis que la latence pour B est de 30 ms et D de 60 ms. Si la sensibilité à la latence du groupe d’origines est définie sur 30 ms, le pool de latences le plus faible se compose des origines A et B, car D est au-delà de 30 ms de l’origine la plus proche qui est A.
4. Poids : Enfin, Azure Front Door répartit le trafic par tourniquet (Round Robin) entre le groupe d’origines sélectionné final dans les proportions définies par les pondérations spécifiées.
   • Exemple : si l’origine A a une pondération de 3 et que l’origine B a une pondération de 7, le trafic est distribué dans les proportions 3/10 à l’origine A et 7/10 à l’origine B.

Si l’affinité de session est activée, la première requête d’une session suit le flux répertorié précédemment. Les demandes suivantes sont envoyées à l’origine sélectionnée dans la première demande.

Routage du trafic basé sur les latences les plus faibles

Le déploiement d’origines à différents emplacements du globe peut améliorer la réactivité de vos applications en acheminant le trafic vers la destination « la plus proche » de vos utilisateurs finaux. La latence est la méthode de routage du trafic par défaut pour votre configuration Front Door. Cette méthode de routage transfère les demandes de vos utilisateurs finaux vers l’origine la plus proche derrière Azure Front Door. Associé à l’architecture anycast d’Azure Front Door, ce mécanisme de routage garantit que tous vos utilisateurs finaux obtiendront les meilleurs performances en fonction de leur emplacement.

L’origine « la plus proche » n'est pas nécessairement la plus proche en termes de distance géographique. Azure Front Door détermine plutôt les origines les plus proches en mesurant la latence du réseau. Lisez plus d’informations sur l’architecture de routage d’Azure Front Door.

Chaque environnement Front Door mesure la latence d’origine séparément. Cela signifie que différents utilisateurs se trouvent à différents emplacements sont acheminés vers l’origine avec les meilleures performances pour cet environnement.

Notes

Par défaut, la propriété de sensibilité de latence est définie sur 0 ms. Avec ce paramètre, la demande est toujours transmise aux origines les plus rapides disponibles et les pondérations de l’origine ne prennent pas effet, à moins que deux origines aient la même latence du réseau.

Routage du trafic basé sur les priorités

Les organisations cherchent souvent à assurer la haute disponibilité de leurs services en déployant plusieurs services de sauvegarde utilisables en cas de défaillance du service principal. Dans l’ensemble du secteur, ce type de topologie est également appelée déploiement Actif/En veille ou Actif/passif. La méthode de routage du trafic Priorité vous permet d’implémenter facilement ce modèle de basculement.

Le service Azure Front Door par défaut contient une liste d’origines de priorité égale. Par défaut, Azure Front Door envoie le trafic uniquement aux origines de priorité supérieure (valeur de priorité la plus faible) ; en tant qu’ensemble principal d’origines. Si les origines principales ne sont pas disponibles, Azure Front Door achemine le trafic vers l’ensemble secondaire d’origines (deuxième valeur de priorité la plus faible). Si les origines principales et secondaires ne sont pas disponibles, le trafic est envoyé aux origines de troisième rang, et ainsi de suite. La disponibilité de l’origine est basée sur l’état configuré et sur l’état d’intégrité de l’origine en cours déterminé par les sondes d’intégrité.

Configuration de la priorité des origines

Chaque origine dans votre groupe d’origines de la configuration Azure Front Door dispose d'une propriété appelée Priorité, qui peut être une valeur comprise entre 1 et 5. Avec Azure Front Door, vous pouvez configurer la priorité des origines explicitement à l’aide de cette propriété pour chaque origine. Cette propriété est une valeur comprise entre 1 et 5. Plus la valeur est faible, plus la priorité est élevée. Les origines peuvent partager les mêmes valeurs de priorité.

Méthode de routage du trafic basé sur la pondération

La méthode de routage du trafic Pondéré vous permet de répartir le trafic uniformément ou d’utiliser une pondération prédéfinie.

Dans la méthode de routage du trafic basée sur la pondération, vous affectez une pondération à chaque origine dans la configuration Azure Front Door de votre groupe d’origine. La pondération est un entier compris entre 1 et 1 000. Ce paramètre utilise la pondération par défaut 50.

Avec la liste des origines disponibles dont la sensibilité de latence est acceptable, le trafic est distribué avec un mécanisme de tourniquet (round-robin) en utilisant les proportions définies par les pondérations spécifiées. Si la sensibilité de latence est définie sur 0 milliseconde, cette propriété n'a pas d'effet, sauf si deux origines ont la même latence de réseau.

La méthode pondérée permet des scénarios utiles :

• Mise à niveau progressive d’une application : fournit un pourcentage de trafic à router vers une nouvelle origine, puis augmente progressivement le trafic au fil du temps jusqu’à ce qu’il soit au même niveau que celui des autres origines.
• Migration d’application vers Azure : créez un groupe d’origines avec à la fois des origines Azure et des origines externes. Ajustez la pondération des origines pour privilégier les nouvelles origines. Pour effectuer progressivement ce paramétrage, commencez par désactiver les nouvelles origines, puis affectez-leur les pondérations les plus faibles, et augmentez-les lentement à des niveaux où ils prennent le plus de trafic. Enfin, désactivez les origines les moins prisées, puis supprimez-les du groupe.
• Extension du cloud (cloud bursting) pour une capacité supplémentaire : étendez rapidement un déploiement local dans le cloud en le plaçant derrière Front Door. Quand vous avez besoin d’une capacité supplémentaire dans le cloud, vous pouvez ajouter ou activer des origines supplémentaires, et spécifier quelle partie du trafic est destinée à chaque origine.

Affinité de session

Par défaut, sans affinité de session, Azure Front Door transfère les requêtes provenant d'un même client vers différentes origines. Certaines applications à état ou dans certains scénarios où les requêtes successives du même utilisateur préfèrent que la même origine traite la demande initiale. La fonctionnalité d’affinité de session basée sur les cookies est utile lorsque vous souhaitez conserver une session utilisateur sur la même origine. Lorsque vous utilisez des cookies managés avec SHA256 de l’URL d’origine comme identificateur dans le cookie, Azure Front Door peut diriger le trafic d’une session utilisateur vers la même origine pour le traitement.

L’affinité de session peut être activée au niveau du groupe d’origine dans le niveau Standard et le niveau Premium d’Azure Front Door et le niveau d’hôte frontal dans Azure Front Door (classique) pour chacun de vos domaines configurés (ou sous-domaines). Une fois activé, Azure Front Door ajoute un cookie à la session de l’utilisateur. Les cookies sont appelés ASLBSA et ASLBSACORS. L’affinité de session basée sur les cookies permet à Front Door d’identifier différents utilisateurs même s’ils utilisent la même adresse IP, ce qui permet une répartition plus équitable du trafic entre vos différentes origines.

La durée de vie du cookie est identique à celle de la session de l’utilisateur, car Front Door ne prend actuellement en charge que le cookie de session.

Notes

Quel que soit l’emplacement où elle est configurée, l’affinité de session est mémorisée via le cookie de session de navigateur au niveau du domaine. Les sous-domaines sous le même domaine générique peuvent partager l’affinité de session tant que le même navigateur d’utilisateur envoie des requêtes pour la même ressource d’origine.

Les proxys publics peuvent interférer avec l’affinité de session. En effet, l’établissement d’une session nécessite que Front Door ajoute un cookie d’affinité de session à la réponse. Cette opération ne peut pas être effectuée si la réponse peut être mise en cache, car cela perturberait les cookies d’autres clients demandant la même ressource. Pour vous protéger contre cela, l’affinité de session n’est pas établie si l’origine envoie une réponse pouvant être mise en cache quand vous tentez cette opération. Si la session a déjà été établie, le fait que la réponse de l’origine puisse être mise en cache n’a pas d’importance.

L’affinité de session est établie dans les circonstances suivantes au-delà des scénarios non mis en cache standard :

• La réponse doit inclure l’en-tête Cache-Control de no-store.
• Si la réponse contient un en-tête Authorization, elle ne doit pas être expirée.
• La réponse est un code d'état HTTP 302.

Étapes suivantes

• Découvrez comment créer un service Azure Front Door.
• Découvrez comment fonctionne Azure Front Door.