Origins et groupes d’origin dans Azure Front Door

Cet article décrit des concepts sur la façon de mapper votre déploiement d’application web avec Azure Front Door. Vous découvrez également ce que sont un origin et un groupe d’origin dans la configuration Azure Front Door.

Origine

Une origine fait référence au déploiement d’application à partir duquel Azure Front Door récupère le contenu. Azure Front Door prend en charge les origins hébergés dans Azure et les applications hébergées dans votre centre de données local ou avec un autre fournisseur de cloud. Il ne faut pas confondre un origin avec votre niveau de base de données ou de stockage. L’origin doit être considéré comme le point de terminaison de votre back-end d’application. Lorsque vous ajoutez un origin à un groupe d’origins dans la configuration Front Door, vous devez également configurer les éléments suivants :

• Type d’origine : type de ressource que vous souhaitez ajouter. Front Door prend en charge la découverte automatique de vos back-ends d’application à partir d’App Service, d’un service cloud ou de Stockage. Si vous voulez une autre ressource Azure ou même un back-end non-Azure, sélectionnez Hôte personnalisé.

  Important

  Pendant la configuration, les API ne valident pas si l’origine n’est pas accessible depuis l’environnement Front Door. Assurez-vous que Front Door peut atteindre votre origine.

• Abonnement et nom d’hôte de l’origin : si vous n’avez pas sélectionné Hôte personnalisé pour le type d’hôte de votre back-end, sélectionnez votre back-end en choisissant l’abonnement approprié et le nom d’hôte de back-end correspondant.

• En-tête de l’hôte d’origine : valeur d’en-tête de l’hôte envoyée au back-end pour chaque demande. Pour plus d’informations, consultez En-tête d’hôte d’origine.

• Priorité. Attribuez des priorités à vos back-end lorsque vous souhaitez utiliser un back-end de service principal pour tout le trafic. Fournissez également des sauvegardes si les back-ends principaux ou de secours ne sont pas disponibles. Pour plus d'informations, veuillez consulter Priorité.

• Poids. Attribuez des poids à vos différents back-ends si vous voulez répartir le trafic entre un ensemble de back-ends, que ce soit de façon équitable ou selon des coefficients de pondération. Pour plus d’informations, veuillez consulter Poids.

En-tête de l’hôte d’origine

Les demandes qui sont transférées par Azure Front Door vers un origin incluent un champ d’en-tête d’hôte utilisé par l’origin pour récupérer la ressource ciblée. La valeur de ce champ provient généralement de l’URI de l’origine qui contient l’en-tête et le port de l’hôte.

Par exemple, une demande formulée pour www.contoso.com a l’en-tête d’hôte www.contoso.com. Si vous utilisez le portail Azure pour configurer votre origin, la valeur par défaut pour ce champ sera le nom d’hôte de l’origin. Si votre origin est contoso-westus.azurewebsites.net, la valeur renseignée automatiquement pour l’en-tête de l’hôte d’origin dans le portail Azure est contoso-westus.azurewebsites.net. Toutefois, si vous utilisez des modèles Azure Resource Manager ou une autre méthode sans définir explicitement ce champ, Front Door transmet le nom d’hôte entrant comme valeur pour l’en-tête d’hôte. Si la demande a été formulée pour www.contoso.com et que votre origin contoso-westus.azurewebsites.net présente un champ d’en-tête vide, Front Door attribue à l’en-tête de l’hôte la valeur www.contoso.com.

La plupart des back-endq d’application (comme Azure Web Apps, Stockage Blob et Cloud Services) exigent une correspondance entre l’en-tête de l’hôte et le domaine du back-end. Toutefois, l’hôte frontal qui achemine vers votre origin a un nom d’hôte différent, comme www.contoso.net.

Si votre origin nécessite une correspondance entre l’en-tête de l’hôte et le nom d’hôte de l’origin, assurez-vous que l’en-tête de l’hôte de l’origin inclut le nom de l’hôte de l’origin.

Configurer l’en-tête de l’hôte d’origin pour l’origin

Pour configurer le champ de l’en-tête de l’hôte d’origine pour une origine dans la section du groupe d’origines :

1. Ouvrez votre ressource Front Door et sélectionnez le groupe d’origines contenant l’origine à configurer.

2. Si ce n’est déjà fait, ajoutez une origine, ou modifiez-en une.

3. Définissez le champ d’en-tête de l’hôte d’origine sur une valeur personnalisée ou laissez-le vide. Le nom d’hôte pour la requête entrante est utilisé en tant que valeur d’en-tête hôte.

Groupe d’origines

Un groupe d’origin dans Azure Front Door fait référence à l’ensemble d’origins qui reçoit un trafic similaire pour son application. Vous pouvez définir le groupe d’origin comme un regroupement logique des instances de votre application dans le monde entier, qui reçoivent le même trafic et répondent avec un comportement attendu. Ces origines peuvent être déployées dans différentes régions ou au sein d’une même région. Tous les origins peuvent être déployés dans une configuration Active/Active ou Active/Passive.

Un groupe d’origins définit le mode d’évaluation des origins par des sondes d’intégrité. Il définit également la méthode d’équilibrage de charge entre eux.

Sondes d’intégrité

Azure Front Door envoie des requêtes de sonde HTTP/HTTPS périodiques à chacune de vos origins configurés. Les requêtes de sonde déterminent la proximité et l’intégrité de chaque origine, afin d’équilibrer la charge des demandes de vos utilisateurs finaux. Les paramètres de sonde d’intégrité d’un groupe d’origines définissent la façon dont nous sondons l’état d’intégrité des back-ends de l’application. Les paramètres de configuration de l’équilibrage de charge disponibles sont les suivants :

• Chemin : URL utilisée pour les requêtes de sonde pour toutes les origines du groupe d’origines. Par exemple, si l’un de vos origins est contoso-westus.azurewebsites.net et que le chemin défini est /probe/test.aspx, Front Door envoie les requêtes de sonde d’intégrité à http://contoso-westus.azurewebsites.net/probe/test.aspx, si le protocole est défini sur HTTP.

• Protocole : détermine si les requêtes de sonde d’intégrité de Front Door vers vos origines sont envoyées via le protocole HTTP ou HTTPS.

• Méthode : méthode HTTP à utiliser pour l’envoi des sondes d’intégrité. Les options incluent GET ou HEAD (par défaut).

  Notes

  Afin de limiter la charge et les coûts qui pèsent sur vos back-ends, Front Door recommande d’utiliser des requêtes HEAD pour les sondes d’intégrité.

• Intervalle (en secondes) : définit la fréquence des sondes d’intégrité de vos origines, ou les intervalles dans lequel chacun des environnements Front Door envoie une sonde.

  Notes

  Pour accélérer les basculements, baissez la valeur de l’intervalle. Plus la valeur est faible, plus le nombre de sondes d’intégrité de vos back-ends augmente. Par exemple, si l’intervalle est défini sur 30 secondes avec 100 points de présence (POP) Front Door dans le monde entier, chaque back-end reçoit environ 200 requêtes d’intégrité par minute.

Pour plus d’informations, veuillez consulter la section Sondes d’intégrité.

Paramètres d’équilibrage de charge

Les paramètres d’équilibrage de charge du groupe d’origines définissent la façon dont nous évaluons les sondes d’intégrité. Ces paramètres déterminent si l’origine est saine ou pas. Ils vérifient également comment équilibrer la charge du trafic entre différentes origines dans le groupe d’origines. Les paramètres de configuration de l’équilibrage de charge disponibles sont les suivants :

• Taille de l’échantillon : cette propriété identifie le nombre d’échantillons de sondes d’intégrité à prendre en compte pour évaluer l’intégrité d’une origine.

• Taille d’échantillon réussi : définit la taille d’échantillon comme mentionnée ci-dessus, le nombre d’échantillons réussis nécessaires pour appeler l’origine saine. Par exemple, imaginons le cas d’un intervalle de sonde d’intégrité Front Door de 30 secondes, dont la taille d’échantillon est de 5, et la taille d’échantillon réussi de 3. Chaque fois que nous évaluons les sondes d’intégrité pour votre origine, nous examinons les 5 derniers échantillons pendant 150 secondes (5 x 30). Au moins 3 sondages réussis sont nécessaires pour déclarer que l’origine est saine.

• Sensibilité de latence (latence supplémentaire) : définit si vous souhaitez que Front Door envoie la requête à l’origin dans la plage de sensibilité de mesure de latence ou transfère la requête vers le back-end le plus proche.

Pour plus d’informations, consultez Routage du trafic basé sur les latences les plus faibles.

Étapes suivantes