IMPORTANT : Le composant (CBR) routage CBR est disponible sur toutes les plateformes prises en charge, avec les exceptions suivantes :
Pour ce type d'installation, vous pouvez également utiliser la méthode de réacheminement CBR du composant Dispatcher de Load Balancer' pour assurer un routage basé sur contenu des requêtes HTTP et HTTPS sans utiliser Caching Proxy. Pour plus d'informations, voir
Fonctionnant conjointement avec le composant Caching Proxy de Application Server, le composant Load Balancer de Application Server permet de distribuer des demandes à plusieurs serveurs dorsaux hébergeant des données différentes. Présentation des composants Edge de WebSphere Application Server fournit une présentation de ces composants Edge.
Si le composant CBR (Content Based Routing) de Load Balancer est installé en même temps que le composant Caching Proxy, les demandes HTTP peuvent même être réparties en fonction d'une URL ou d'autres caractéristiques déterminées par un administrateur, ce qui élimine la nécessité de stocker des données identiques sur tous les serveurs dorsaux.
L'utilisation de CBR est particulièrement recommandée si les serveurs Web doivent effectuer différentes fonctions ou offrir plusieurs types de service. A titre d'exemple, le site Web d'un détaillant en ligne doit d'une part afficher son catalogue, dont la majeure partie est statique, et d'autre part accepter les commandes, ce qui implique d'exécuter une application interactive, tel qu'un script CGI (Common Gateway Interface) pour accepter des numéros de référence et des informations client. Il est parfois plus efficace d'utiliser deux ensembles de machines distincts pour effectuer les différentes fonctions et d'employer CBR pour acheminer les divers types de trafic vers différentes machines. De la même façon, une entreprise peut utiliser CBR pour offrir aux acheteurs un meilleur service qu'aux visiteurs occasionnels de son site Web, en acheminant les demandes payées vers des serveurs Web plus puissants.
CBR achemine les demandes en fonction de règles que vous définissez. Le type de règle le plus connu est la règle de données qui dirige les demandes en fonction du chemin d'accès indiqué dans l'URL. Par exemple, ABC Corporation peut écrire des règles pour diriger les demandes portant sur l'URL http://www.abc.com/catalog_index.html vers un cluster de serveurs et http://www.abc.com/orders.html vers un autre cluster. Il existe aussi des règles qui acheminent les demandes selon l'adresse IP du client qui les a envoyées ou d'autres caractéristiques. Pour en savoir plus, reportez-vous aux chapitres relatifs à la configuration de CBR et aux fonctions CBR et Load Balancer avancées du manuel WebSphere Application Server Load Balancer - Guide d’administration. Si vous souhaitez consulter les définitions de syntaxe des règles, reportez-vous à l'annexe relative aux types de règles CBR dans le manuel WebSphere Application Server Load Balancer - Guide d’administration.
La figure 12 représente une configuration simple dans laquelle le composant CBR de Load Balancer et Caching Proxy sont installés ensemble sur la machine 4 et acheminent des demandes vers trois hôtes de données (6, 7 et 8) qui hébergent des données différentes. Lorsqu'un utilisateur final travaillant sur l'une des machines repérées par 1 demande le fichier X, la demande traverse Internet (2) et pénètre sur le réseau interne de l'entreprise via sa passerelle Internet (3). Le serveur proxy intercepte la demande et la transmet au composant CBR de la même machine qui analyse l'URL contenue dans la demande et détermine que l'hôte de données 6 héberge le fichier X. Le serveur proxy génère une nouvelle demande portant sur le fichier X et, si sa fonction de mise en mémoire cache est activée, détermine si le fichier peut être mis en mémoire cache lorsque l'hôte 6 le renvoie. Si tel est le cas, le serveur proxy stocke une copie du fichier dans sa mémoire cache (5) avant de la transmettre à l'utilisateur final. Le routage d'autres fichiers fonctionne de la même manière : les demandes portant sur le fichier Y sont transmises à l'hôte de données 7 et les demandes concernant le fichier Z sont transmises à l'hôte de données 8.
La figure 13 présente une configuration plus complexe qui peut être adaptée à un détaillant en ligne. Le composant CBR de Load Balancer et le serveur proxy sont installés ensemble sur la machine 4 et acheminent les demandes vers deux machines Load Balancer. Le composant Load Balancer 6 équilibre la charge d'un cluster d'hôtes de données (8) qui héberge les données essentiellement statiques du catalogue du détaillant, tandis que le composant Load Balancer 7 équilibre la charge d'un cluster de serveurs Web qui traite les commandes (9).
Lorsqu'un utilisateur final travaillant sur l'une des machines associées au chiffre 1 accède à l'URL du catalogue du détaillant, la demande traverse Internet (2) et pénètre sur le réseau interne de l'entreprise via sa passerelle Internet (3). Le serveur proxy intercepte la demande et la transmet au composant CBR de la même machine qui analyse l'URL et détermine que la machine Load Balancer 6 la traitera. Le serveur proxy crée une nouvelle demande d'accès et l'envoie au composant Load Balancer, qui détermine quel hôte de données repéré par 8 est actuellement le mieux à même de traiter la demande (selon les critères que vous avez définis). Cet hôte de données transmet directement le contenu du catalogue au serveur proxy, en contournant le composant Load Balancer. Comme dans l'exemple précédent, le serveur proxy détermine si les données peuvent être mises en mémoire cache et les stocke dans sa mémoire cache (5), le cas échéant.
L'utilisateur final passe une commande en accédant à l'URL de commande du détaillant, probablement par l'intermédiaire d'un lien hypertexte dans le catalogue. La demande suit le même chemin que la demande d'accès au catalogue, sauf que le composant CBR de la machine 4 la dirige sur la machine Load Balancer 7. Cette dernière la transmet au serveur Web 9, le plus adapté, qui répond directement au serveur proxy. Les informations de commande étant généralement générées dynamiquement, le serveur proxy ne les met probablement pas en mémoire cache.
La fonction CBR de Load Balancer prend en charge l'affinité de cookie. Cela signifie que l'identité du serveur qui a traité la première demande d'un utilisateur final est enregistrée dans un paquet de données spécial (cookie) inclus dans la réponse du serveur. Si l'utilisateur final accède à la même URL au cours d'une période que vous définissez et que la demande contient le cookie, CBR transmet la demande au serveur initial au lieu de lui réappliquer ses règles standard. Le temps de réponse est généralement meilleur si le serveur a stocké des informations sur l'utilisateur et n'a pas besoin de les redemander (comme le numéro de carte de crédit).