Configurer l’architecture de déploiement à 3 niveaux à l’aide d’Application Request Routing

par l’équipe IIS

Vue d’ensemble

Cette rubrique vous guide tout au long des étapes de configuration d’une architecture de déploiement à 3 niveaux à l’aide d’Application Request Routing. L’architecture de déploiement à 3 niveaux se compose d’un niveau Web, d’un niveau serveur d’applications et d’un niveau de données, comme indiqué ci-dessous :

En règle générale, dans ce scénario de déploiement, le contenu statique est servi par les serveurs de niveau 1, tandis que le contenu dynamique est servi par la logique métier dans les serveurs de niveau 2.

But

Pour configurer l’architecture de déploiement à 3 niveaux à l’aide d’Application Request Routing. Dans cette procédure pas à pas, l’accent est mis sur la manière de configurer le serveur ARR pour qu’il serve du contenu statique directement à partir du serveur ARR tout en transmettant les demandes de contenu dynamique aux serveurs d’application.

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 de contenu avec des sites de travail et des applications
• Contenu statique disponible sur le serveur d’Application Request Routing

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 : modifier les règles de réécriture d’URL pour filtrer les demandes statiques.

Dans cette étape, les règles de réécriture d’URL sont modifiées afin que les demandes de certains chemins d’accès ou extensions soient traitées directement à partir du serveur d’Application Request Routing. Les demandes statiques peuvent être identifiées en examinant les extensions de fichier, telles que .jpg ou .gif. Si les ressources statiques sont contenues dans certains dossiers, tels que /images/, les règles de réécriture d’URL peuvent rechercher le chemin d’accès dans l’URL.

Dans cette procédure pas à pas, vous allez modifier les règles de réécriture d’URL pour rechercher les extensions .jpg et .css, ainsi que le dossier /images/. Si la ressource demandée a une extension .jpg ou .css, elle est servie directement à partir du serveur ARR. De même, si l’URL demandée contient /images/, cette demande sera traitée à partir du serveur ARR. Toutes les autres demandes seront transférées aux serveurs d’applications derrière le serveur ARR.

Avant de continuer, assurez-vous que le contenu statique est disponible sur le serveur ARR à servir. Le contenu peut être mis à disposition localement sur le serveur ARR ou le contenu partagé peut être utilisé.

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

1. Lancez le gestionnaire IIS.
2. 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).
3. Les icônes suivantes sont affichées :
   
4. Double-cliquez sur Règles de routage. Tapez *.jpg et *.css dans la zone de texte Les demandes avec les extensions suivantes ne sont pas transférées. Les extensions multiples sont séparées par des virgules (,). Pour correspondre au chemin d’accès dans l’URL, tapez */image/* dans la zone de texte Les demandes avec les modèles suivants ne sont pas transférées. Le caractère générique (*) est utilisé pour faire correspondre n’importe quel caractère avant et après le chemin /image/.
   
5. Pour vérifier que les images statiques sont traitées à partir du serveur ARR, inspectez les journaux. Par défaut, les journaux sont dans c:\inetpub\logs\LogFiles\. Sur les serveurs d’applications derrière le serveur ARR, il ne doit y avoir aucune demande qui référence *.jpg, *.css ou */images/* dans le fichier journal.

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

1. Ouvrez une invite de commandes avec des privilèges administrateur.

2. Accédez à %windir%\system32\inetsrv.

3. Effacez toutes les règles de réécriture d’URL en entrant :

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

Pour modifier les règles de routage afin que les demandes de ressources avec les extensions *.jpg et *.css et un chemin correspondant à */images/* ne soient pas transférés aux serveurs d’applications, entrez :

• 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'].conditions.
  [input='EXT_{URL}',negate='True',pattern='*.jpg']" 
  /commit:apphost
  

• appcmd.exe set config  -section:system.webServer/rewrite/globalRules 
  /+"[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].conditions.
  [input='EXT_{URL}',negate='True',pattern='*.css']" 
  /commit:apphost
  

• appcmd.exe set config  -section:system.webServer/rewrite/globalRules 
  /+"[name='ARR_myServerFarm_loadbalance',patternSyntax='Wildcard',stopProcessing='True'].conditions.
  [input='{URL}',negate='True',pattern='*/images/*']" 
  /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://myServerFarm1/{R:0}"  
  /commit:apphost
  

Résumé

Vous avez maintenant modifié les règles de réécriture d’URL à l’aide de l’interface utilisateur d’Application Request Routing pour activer un scénario d’architecture de déploiement à 3 niveaux. Pour d’autres propriétés et fonctionnalités d’Application Request Routing, reportez-vous à la procédure pas à pas Équilibrage de charge HTTP à l’aide d’Application Request Routing (ARR).

Lorsqu’ARR est utilisé comme proxy inverse, le scénario peut être amélioré davantage lorsqu’il est utilisé avec la version 2 de réécriture d’URL qui a la fonctionnalité de réécrire les en-têtes de réponse et le corps de l’entité.