Équilibrage de charge HTTP à l’aide de Application Request Routing

Article
03/20/2024

par l’équipe IIS

Vue d’ensemble

Cette rubrique guide le lecteur dans les étapes de configuration du routage des demandes d’application pour équilibrer la charge des requêtes HTTP afin d’obtenir une haute disponibilité et une scalabilité. La procédure pas à pas met également en évidence quelques fonctionnalités principales sur la façon dont Application Request Routing surveille l’intégrité des serveurs de contenu et affinité les requêtes d’un client à un serveur de contenu.

But

Pour équilibrer la charge des requêtes HTTP sur plusieurs serveurs de contenu à l’aide de Application Request Routing, comme indiqué ci-dessous :

Prérequis

Cette procédure pas à pas nécessite les prérequis suivants :

IIS 7.0 ou version ultérieure sur Windows 2008 (toute référence SKU) ou ultérieure.
Microsoft Application Request Routing version 1 et modules dépendants
Minimum de deux serveurs d’applications avec des sites et des applications de travail.

Suivez les étapes décrites dans ce document pour installer Application Request Routing.

Comme autre condition préalable, vous devez avoir défini et configuré une batterie de serveurs en suivant les étapes décrites dans Définir et configurer un groupe de serveurs ARR (Application Request Routing).

Étape 1 : Vérifier les règles de réécriture d’URL

À condition que la batterie de serveurs ait été créée à l’aide des étapes décrites dans Définir et configurer un groupe de serveurs ARR (Application Request Routing), les règles de réécriture d’URL ont déjà été créées pour un scénario d’équilibrage de charge simple.

Pour vérifier les règles de réécriture d’URL à l’aide de l’interface utilisateur :

Lancez le gestionnaire IIS.
Sélectionnez la batterie de serveurs, myServerFarm, qui a été créée dans Définir et configurer un groupe de serveurs ARR (Application Request Routing).
Les icônes suivantes sont affichées :
Double-cliquez sur Règles de routage.
Vérifiez que la case Utiliser la réécriture d’URL pour inspecter les requêtes entrantes est cochée.
Le déchargement SSL est activé par défaut. L’activation du déchargement SSL implique que toutes les communications entre le serveur ARR et les serveurs web sont effectuées en texte clair, même pour les requêtes HTTPS des clients vers le serveur ARR. Lorsque le serveur ARR et les serveurs d’applications sont déployés dans un réseau approuvé, comme dans le même centre de données, l’activation du déchargement SSL ne sacrifie pas la sécurité. En outre, l'activation de cette fonction peut contribuer à maximiser les ressources des serveurs d'application, puisqu'ils ne doivent pas consacrer de cycles au cryptage et au décryptage des requêtes et des réponses.
Pour désactiver le déchargement SSL, décochez la case Activer le déchargement SSL, puis cliquez sur Appliquer.
Ouvrez un navigateur et envoyez plusieurs requêtes au serveur ARR.
Pour vérifier que les requêtes sont en cours d’équilibrage de charge égale entre les serveurs d’applications, sélectionnez myServerFarm. Double-cliquez sur Surveillance et gestion.
Dans l’affichage tableau de bord, vérifiez que les requêtes sont distribuées uniformément.

Pour vérifier les règles de réécriture d’URL à l’aide de la ligne de commande :

Ouvrez une invite de commandes avec des privilèges administrateur.
Accédez à %windir%\system32\inetsrv.

Pour vérifier que les règles de réécriture d’URL ont été créées correctement, entrez appcmd.exe configuration de liste -section:system.webServer/rewrite/globalRules. Elle retourne les globalRules qui ressemblent à ce qui suit :

<system.webServer>
    <rewrite>
        <globalRules>
            <rule name="ARR_myServerFarm_loadbalance" patternSyntax="Wildcard"
            stopProcessing="true">
                <match url="*" />
                <conditions>
                </conditions>
                <action type="Rewrite" url="http://myServerFarm/{R:0}" />
            </rule>
        </globalRules>
    </rewrite>
</system.webServer>

Pour désactiver le déchargement SSL, commencez par supprimer toutes les règles de réécriture d’URL :

appcmd.exe clear config -section:system.webServer/rewrite/globalRules

Ensuite, créez les règles de réécriture d’URL pour transférer le trafic HTTPS. Plus précisément, avec cette règle, ARR transfère les requêtes à l’aide de SSL si les requêtes entrantes sont HTTPS :

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/+"[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True']"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/+"[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].conditions.[input='{HTTPS}',pattern='On']"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite"
/[name='ARR_myServerFarm_loadbalance_SSL',patternSyntax='Wildcard',stopProcessing='True'].action.url:"https://myServerFarm/{R:0}"
/commit:apphost

Enfin, créez les règles de réécriture d’URL pour transférer le trafic HTTP en texte clair vers les serveurs d’applications :

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/+"[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True']"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].match.url:"*"
/commit:apphost

appcmd.exe set config -section:system.webServer/rewrite/globalRules
/[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].action.type:"Rewrite"
/[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].action.url:"http://myServerFarm/{R:0}"
/commit:apphost

Pour vérifier que les règles de réécriture d’URL ont été créées correctement avec le déchargement SSL désactivé, entrez appcmd.exe list config -section:system.webServer/rewrite/globalRules. Elle retourne les globalRules qui ressemblent à ce qui suit :

<system.webServer>
    <rewrite>
        <globalRules>
            <rule name="ARR_myServerFarm_loadbalance_SSL" patternSyntax="Wildcard"
            stopProcessing="true">
                <match url="*" />
                <conditions>
                <add input="{HTTPS}" pattern="On" />
                </conditions>
                <action type="Rewrite" url="https://myServerFarm/{R:0}" />
            </rule>
            <rule name="ARR_myServerFarm_loadbalance" patternSyntax="Wildcard"
            stopProcessing="true">
                <match url="*" />
                <conditions>
                </conditions>
                <action type="Rewrite" url="http://myServerFarm/{R:0}" />
            </rule>
        </globalRules>
    </rewrite>
</system.webServer>

Étape 2 : Configurer la surveillance du contrôle d’intégrité

Application Request Routing surveille l’intégrité des serveurs de contenu de deux façons :

Via le trafic en direct
Via un test d’URL explicite

Le test de trafic en direct est effectué automatiquement par défaut lorsque les demandes sont adressées à ARR. Le test d’URL explicite est un test supplémentaire qui peut être utilisé avec les tests de trafic en direct. Dans cette section, la procédure pas à pas vous guide tout au long de la configuration du test d’URL explicite.

Pour configurer la surveillance du contrôle d’intégrité à l’aide de l’interface utilisateur :

Le test d’URL nécessite une URL spécifique à tester. Pour répondre à cette exigence, utilisez le bloc-notes pour créer un fichier texte nommé healthCheck.txt qui contient la phrase «Je suis intègre ».
Placez le fichier healthCheck.txt sur les serveurs d’applications.
Vérifiez que le fichier healthCheck.txt est rendu correctement en ouvrant la page dans un navigateur.
Dans le Gestionnaire IIS, sélectionnez la batterie de serveurs, myServerFarm. Les icônes suivantes sont affichées :
Double-cliquez sur Test d’intégrité.
Entrez http://(server name or FQDN of ARR server)/healthCheck.txt comme valeur URL.
Entrez intègre en tant que valeur de correspondance de réponse. La correspondance de réponse est un test facultatif pour vous assurer que le corps de la réponse contient la chaîne attendue. Dans ce cas, étant donné que healthCheck.txt contient la phrase «Je suis intègre.» , la correspondance de réponse recherche le mot «intègre».
Cliquez sur Appliquer pour enregistrer les modifications.
Pour vérifier les fonctionnalités de surveillance de contrôle d’intégrité, arrêtez le site surveillé sur l’un des serveurs d’applications. Étant donné que la valeur Intervalle (secondes) est définie sur 30 secondes, attendez 30 secondes pour la vérification d’intégrité suivante.
Après avoir attendu 30 secondes, envoyez plusieurs requêtes au serveur ARR.
Pour vérifier que toutes les requêtes vont aux serveurs intègres, double-cliquez sur Surveillance et gestion, puis actualisez le tableau de bord à l’aide de la touche F5. Notez que les statistiques d’exécution ont été réinitialisées. C'est la procédure normale. Vous souhaiterez peut-être envoyer des requêtes supplémentaires et actualiser le tableau de bord en fonction des besoins.
La surveillance de l’intégrité est également utilisée pour détecter quand un serveur défectueux devient intègre. Pour vérifier cette fonctionnalité, démarrez le site qui a été arrêté à l’étape 9. Là encore, étant donné que la valeur Intervalle (secondes) est définie sur 30 secondes, attendez 30 secondes pour la vérification d’intégrité suivante.
Après avoir attendu 30 secondes, envoyez plusieurs requêtes au serveur ARR.
Pour vérifier que les requêtes sont distribuées uniformément entre les serveurs, actualisez le tableau de bord dans le gestionnaire IIS. Notez que les statistiques d’exécution ont été réinitialisées. C'est la procédure normale. Vous souhaiterez peut-être envoyer des requêtes supplémentaires et actualiser le tableau de bord en fonction des besoins.

Pour configurer la surveillance du contrôle d’intégrité à l’aide de la ligne de commande :

Ouvrez une invite de commandes avec des privilèges administrateur.
Accédez à %windir%\system32\inetsrv.

Pour définir l’URL sur http://(server name or FQDN of ARR server)/healthCheck.txt avec Je suis intègre. en tant que chaîne à mettre en correspondance, entrez :

appcmd.exe set config -section:webFarms
/[name='myServerFarm1'].applicationRequestRouting.healthCheck.url:"http://(server
name or FQDN of ARR server)/healthCheck.txt "
/[name='myServerFarm1'].applicationRequestRouting.healthCheck.responseMatch:"I am
healthy." /commit:apphost

Étape 3 - Configurer l’affinité client

Application Request Routing offre une fonction d'affinité client qui associe un client à un serveur de contenu derrière le routage des requêtes d'application pour la durée d'une session client. Lorsque cette fonctionnalité est activée, l’algorithme d’équilibrage de charge est appliqué uniquement pour la première requête du client. À partir de ce stade, toutes les requêtes suivantes du même client sont acheminées vers le même serveur de contenu pendant la durée de la session client. Cette fonctionnalité est utile si l’application sur le serveur de contenu est avec état et que les requêtes du client doivent être acheminées vers le même serveur de contenu, car la gestion de session n’est pas centralisée.

Pour configurer l’affinité client à l’aide de l’interface utilisateur :

Lancez le gestionnaire IIS.
Sélectionnez la batterie de serveurs, myServerFarm, qui a été créée dans Définir et configurer un groupe de serveurs ARR (Application Request Routing).
Les icônes suivantes sont affichées :
Double-cliquez sur Affinité du serveur.
Pour activer l’affinité client, cochez la case Affinité client, puis cliquez sur Appliquer.

Application Request Routing utilise un cookie pour activer l’affinité client. Le nom du cookie sera utilisé pour définir le cookie sur le client. Cela dit, le client doit accepter les cookies pour que l’affinité client fonctionne correctement.
Pour vérifier les fonctionnalités de l’affinité client, envoyez plusieurs requêtes au serveur ARR. Actualisez le tableau de bord dans le gestionnaire IIS (Surveillance et gestion). Vérifiez que les statistiques d’exécution changent pour qu’un seul des serveurs d’applications corresponde à l’emplacement d’affinité du client. Vous souhaiterez peut-être envoyer des requêtes supplémentaires et actualiser le tableau de bord en fonction des besoins.

Pour configurer l’affinité client à l’aide de la ligne de commande :

Ouvrez une invite de commandes avec des privilèges administrateur.
Accédez à %windir%\system32\inetsrv.

Pour activer l’affinité client, entrez :

appcmd.exe set config -section:webFarms
/[name='myServerFarm1'].applicationRequestRouting.affinity.useCookie:"True"
/commit:apphost

Étape 4 : Interdire les nouvelles connexions

L’interdiction de nouvelles connexions sur un serveur est un moyen approprié de sortir le serveur de l’environnement de batterie de serveurs. Cela est plus significatif lorsque la fonctionnalité d’affinité client est en cours d’utilisation, car Application Request Routing respecte les sessions existantes lors de l’interdiction des nouvelles connexions. Autrement dit, lorsqu’un client est affinitisé au serveur qui interdit les nouvelles connexions, le client continue d’être routé vers le même serveur et, par conséquent, il n’y a aucun impact sur le client. Toutefois, aucun nouveau client n’est acheminé vers le serveur qui interdit les nouvelles connexions.

Pour interdire les nouvelles connexions à l’aide de l’interface utilisateur :

À l’aide de l’installation de l’étape 3 ci-dessus, identifiez le serveur auquel votre client est affinitisé.
Sélectionnez la batterie de serveurs, myServerFarm, qui a été créée dans Définir et configurer un groupe de serveurs ARR (Application Request Routing).
Les icônes suivantes sont affichées :
Double-cliquez sur Surveillance et gestion.
Sélectionnez le serveur sur lequel votre client est affinitisé. Dans le volet Actions , cliquez sur Interdire les nouvelles connexions.
Cliquez sur Oui dans la boîte de dialogue de confirmation.
Pour vérifier que les requêtes de vos clients continuent d’être routées vers le serveur affinitisé, ce qui empêche désormais les nouvelles connexions, envoyez plusieurs requêtes au serveur ARR. Actualisez le tableau de bord dans le gestionnaire IIS. Vérifiez que les statistiques d’exécution changent uniquement pour le serveur vers l’emplacement d’affinité du client. Vous souhaiterez peut-être envoyer des requêtes supplémentaires et actualiser le tableau de bord en fonction des besoins.
Pour vérifier que les nouveaux clients ne sont pas routés vers le serveur qui interdit les nouvelles connexions, supprimez le cookie défini par AAR en fermant et en redémarrant le navigateur.
Envoyez plusieurs requêtes au serveur ARR. Actualisez le tableau de bord dans le gestionnaire IIS. Vérifiez que les statistiques d’exécution changent uniquement pour les serveurs disponibles. Plus précisément, vérifiez que les statistiques d’exécution du serveur ne sont pas modifiées. Vous souhaiterez peut-être envoyer des requêtes supplémentaires et actualiser le tableau de bord en fonction des besoins.

Résumé

Vous avez maintenant configuré un certain nombre de paramètres pour que AAR étende et répartisse la charge de manière uniforme. Pour obtenir des fonctionnalités de routage plus avancées à l’aide de AAR, reportez-vous à Utiliser Application Request Routing.

Partager via