![[17.0.0.1 and later]](../ng_v17001plus.gif)
Règles de routage pour le routage dynamique Liberty
Vous pouvez utiliser des règles de routage dans le routage dynamique Liberty pour définir précisément les serveurs à utiliser pour gérer des demandes spécifiques.
Par défaut, le routage dynamique équilibre la charge des demandes entre tous les serveurs pouvant traiter la demande. Pour remplacer le comportement par défaut, vous devez configurer des règles de routage. Les règles de routage pour acheminer les demandes à des ressources de serveur spécifique, réacheminer les demandes, ou les rejeter.
- Si vous déployez la même application sur deux clusters différents, vous pouvez utiliser des règles de routage pour diriger les demandes émanant d'un ensemble spécifique d'adresses IP client vers l'un des clusters et les autres demandes au second cluster.
- Si vous déployez plusieurs collectivités dans la même application, vous pouvez utiliser des règles de routage afin d'envoyer les demandes uniquement à la première collectivité, et d'envoyer les demandes à la seconde seulement si aucun serveur n'est disponible dans la première.
Expression correspondante et actions
Les règles de routage fournissent une expression correspondante et une action. L'expression correspondante est appliquée à chaque demande. Lorsqu'une demande est conforme à l'expression correspondante, l'action spécifiée par la règle est exécutée pour cette demande. Les expressions correspondantes examinent diverses propriétés de la demande, comme l'URI, les en-têtes, les cookies, les paramètres, et l'adresse IP du client. L'action qui s'ensuit consiste à rejeter, à rediriger ou à autoriser la demande.
Les règles de routage ont un numéro d'ordre affecté à chaque règle. Les règles sont évaluées du numéro d'ordre le plus faible au plus élevé. La première règle correspondant à une demande détermine comment celle-ci est traitée. Su aucune règle ne correspond, la demande est partagée entre tous les serveurs pouvant la gérer.
Si le type d'action de la règle indique de rejeter la demande, le code retour HTTP applicable est spécifié. Ce code doit être l'un des codes de rejet pris en charge par le serveur Web.
Si le type d'action de la règle indique de rediriger la demande, l'emplacement de redirection est spécifié.
Si le type d'action de la règle indique d'autoriser la demande, les destinations vers lesquelles celle-ci peut être acheminée sont spécifiées. Ces destinations spécifient le jeu de serveurs à sélectionner pour équilibrage de charge de la demande. Dans ce jeu de destinations, seuls les serveurs pouvant le mieux traiter la demande sont utilisés. Des destinations de basculement peuvent également être spécifiées. Les serveurs dans une destination de basculement ne sont utilisés que si tous les serveurs de la destination de base sont indisponibles. Les destinations spécifiées peuvent être des clusters ou des serveurs.
Par défaut, lorsqu'une demande est associée à l'affinité de session, la sélection du serveur est basée sur l'affinité. Si un serveur d'affinité est localisé, les règles de routage ne sont pas appliquées. Pour permettre aux règles de routage de prévaloir sur la sélection d'affinité, l'attribut overrideAffinity peut être ajouté à l'élément <routingRules> dans le fichier server.xml. Voir Configuration des règles de routage pour le routage dynamique Liberty.
Destination de cluster
Une destination de cluster est spécifiée avec un nom de collectivité et un nom de cluster. Les deux parties de la destination de cluster peuvent utiliser des caractères génériques (*). Par exemple, si une destination de spécifiée sous la forme cluster=collective1,*, les serveurs de n'importe quel cluster de collective1 peuvent être utilisés. Si une destination de cluster est spécifiée sous la forme cluster=*,cluster1, les serveurs dans le cluster cluster1 de n'importe quelle collectivité peuvent être utilisés.
Destination de serveur
Une destination de serveur est spécifiée avec un nom de collectivité, un nom d'hôte, un annuaire d'utilisateurs, et un nom de serveur. Toutes les sections de la destination de serveur peuvent utiliser des caractères génériques. Par exemple, si une destination de serveur est spécifiée sous la forme server=collective1,*,*,*, n'importe quel serveur dans collective1 peut être utilisé. Si une destination de serveur est spécifiée sous la forme server=*,*,*,server1, server1 dans n'importe quelle collectivité peut être utilisé.
Evaluation des règles de routage
Avant d'appliquer des règles de routage, Intelligent Management for Web Servers détermine l'ensemble de destinations optimal pour servir la demande. Cet ensemble est composé des serveurs d'applications Web dont l'hôte virtuel, la racine de contexte et les mappages de correspondent le mieux à la demande. Les règles de routage peuvent cantonner les destinations utilisées pour le routage en les limitant à un sous-ensemble des destinations optimales. Les règles de routage ne peuvent pas entraîner la sélection d'une destination en dehors de l'ensemble de destinations optimales.
Supposons, par exemple, l'existence des conditions suivantes :
- ApplicationA a comme racine de contexte /A/* et est installée sur clusterA.
- ApplicationAB a comme racine de contexte /A/B/* et est installée sur clusterAB.
Sous ces conditions, les règles de routage évaluent les demandes comme suit :
- Les deux applications peuvent servir la demande /A/B/myservlet. Toutefois, vu que la racine de contexte /A/B/* offre une meilleure correspondance pour /A/B/myservlet que la racine de contexte /A/*, les demandes pour /A/B/myservlet sont toujours acheminées vers clusterAB.
- Une règle de routage qui correspond à une demande pour /A/B/myservlet peut être utilisée pour cantonner les destinations à un sous-ensemble de serveurs dans clusterAB, mais ne peut pas être utilisée pour sélectionner des serveurs dans clusterA, lequel n'est jamais identifié comme correspondance pour cette demande.