Mappage des demandes
Le serveur proxy utilise le mappage des demandes pour associer une demande HTTP reçue à une application qui est déployée dans la cellule ou dans la stratégie de routage.
Contrairement au serveur Web Apache ou Caching Proxy, qui comportent des fichiers de configuration à plat avec une priorité de routage inhérente à l'ordre des directives, le serveur proxy utilise un mécanisme de meilleure correspondance afin de déterminer quelle application installée ou quelle règle de routage correspond à une demande. L'hôte virtuel ou les masques d'URI déterminent la meilleure correspondance pour un module web ou une règle de routage. Pour les applications déployées dans des clusters, le serveur proxy entretient une affinité (ID de couche Secure Sockets Layer, cookie et réécriture d'URL), en d'autres termes, une approche par permutation circulaire pondérée est utilisée pour sélectionner le serveur cible. Les exemples suivants abordent divers scénarios de routage lorsque les règles de routage et les applications sont déployées au sein d'une même cellule.
- Environnement proxy
Un serveur proxy WebSphere nommé proxy1 est actif dans la même cellule que les applications et les règles de routage. Toutes les applications et les règles de routage sont activées dans la cellule pour proxy1, et PROXY_HTTP_ADDRESS pour proxy1 est réglé sur 80.
Hôte virtuel Nom d'hôte port default_host host1.company.com 80 host1.company.com 9080 * 80 proxy_host host2.company.com 80 * 443 * 80 server_host host3.company.com 80 Nom de groupe URI Masques d'URI ALL /* PIECES /kitchen/*, /bathroom/*, /bedroom/* CONFLICT /WM2C/* Nom générique de cluster de serveurs Protocole Hôte port CLUSTER1 HTTP webserver1.company.com 9081 webserver2.company.com 9083 CLUSTER2 HTTP host47.company.com 8088 host48.company.com 8088 CLUSTER2-SSL HTTPS host47.company.com 8443 host48.company.com 8443 Nom de la règle de routage Hôte virtuel Groupe d'URI Action ALLTOCLUSTER1 proxy_host ALL Cluster de serveurs génériques - CLUSTER1 ROOMTOCLUSTER2 proxy_host PIECES Cluster de serveurs génériques - CLUSTER2 ALLTOCLUSTER2 server_host ALL Cluster de serveurs génériques - CLUSTER2 REDIRECTTOCONFLICT default_host CONFLICT Rediriger - http://www.conflict.com Nom de l'application Racine de contexte Nom du module Web Hôte virtuel Masques d'URI du module Web App1 /WM1A/ Web Mod A default_host wm1a.jsp /WM1B/ Web Mod B default_host wm1b.jsp App2 /WM2C/ Web Mod C default_host /*, wm2c.jsp /WM2D/ Web Mod D default_host /*, wm2d.jsp - Exemple 1 : demande de base
- Le proxy proxy1 reçoit la demande suivante :
GET /WM1A/wm1a.jsp HTTP/1.1 Host: host1.company.com
Le résultat est l'envoi du fichier wm1a.jsp en réponse. La règle de routage ALLTOCLUSTER1 est une correspondance possible, mais Web Mod A est sélectionné en tant que meilleure correspondance par proxy1 car la combinaison de sa racine de contexte et de son masque d'URI /WM1A/wm1a.jsp est plus adaptée que /*. Web Mod est également choisi en tant que meilleure correspondance car son hôte virtuel contient l'alias host1.company.com:80, qui est une correspondance plus spécifique que l'alias avec le caractère générique *:80.
- Exemple 2 : règles de routage qui utilisent le même groupe d'URI et différents hôtes virtuels
- Le proxy proxy1 reçoit la demande suivante :
GET /index.html HTTP/1.1 Host: host3.company.com
En conséquence, le proxy proxy1 mappe la demande sur la règle de routage ALLTOCLUSTER2, et une réponse est reçue d'un serveur dans CLUSTER2. La règle de routage ALLTOCLUSTER1 est une correspondance possible et peut gérer la demande à condition que la règle de routage ALLTOCLUSTER2 n'existe pas. Cependant, la règle ALLTOCLUSTER2 est la meilleure correspondance car son hôte virtuel (server_host) répertorie host3.company.com de façon explicite.
- Exemple 3 : règles de routage qui utilisent le même hôte virtuel et des groupes d'URI différents
- Le proxy proxy1 reçoit la demande suivante :
GET /kitchen/sink.gif HTTP/1.1 Host: host2.company.com
En conséquence, le proxy proxy1 mappe la demande sur la règle de routage ROOMSTOCLUSTER2 et un serveur du cluster CLUSTER2 envoie une réponse. La règle de routage ALLTOCLUSTER1 est une possibilité, mais la règle ROOMSTOCLUSTER2 rule est la meilleure correspondance car son groupe d'URI contient un masque /kitchen/* qui correspond le mieux à l'URI de demande /kitchen/sink.gif.
- Exemple 4 : groupe d'URI de règle de routage qui est en conflit avec le modèle d'URI d'un module Web qui utilise le même hôte virtuel
- Le proxy proxy1 reçoit la demande suivante :
GET /WM2C/index.html HTTP/1.1 Host: host1.company.com
Le résultat est indéterminé. Nous ne savons pas si Web Mod C ou si la règle de routage REDIRECTTOCONFLICT gère la demande car ils utilisent le même hôte virtuel et possèdent le même masque d'URI. Dans de tels cas, le message ID DWCT0007E est affiché dans le fichier SystemOut.log pour le proxy proxy1. Dans cet exemple, le fait de changer la règle de routage REDIRECTTOCONFLICT pour utiliser un hôte virtuel différent résout le problème.
Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications. - Exemple 5 : l'adresse The PROXY_HTTP_ADDRESS n'est pas dans l'hôte virtuel
- Supposons que l'adresse du proxy proxy1, PROXY_HTTP_ADDRESS, est remplacée par 81, alors que toutes les autres informations de configuration demeurent inchangées. Le proxy proxy1 reçoit la demande suivante :
GET /index.html HTTP/1.1 Host: host1.company.com:81
En conséquence, le proxy proxy1 est incapable de gérer la demande car l'adresse PROXY_HTTP_ADDRESS n'est pas disponible dans l'hôte virtuel. Il renverra une réponse HTTP 404 au client.