WebSphere Application Server

Concepts, planification et installation pour Edge Components

LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE CONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE.

Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y sont fournies sont susceptibles d'être modifiées avant que les produits décrits ne deviennent eux-mêmes disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou services non annoncés dans ce pays. Cela ne signifie cependant pas qu'ils y seront annoncés.

Pour plus de détails, pour toute demande d'ordre technique, ou pour obtenir des exemplaires de documents IBM, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial.

Vous pouvez également consulter les serveurs Internet suivants :

Compagnie IBM France

Direction Qualité

Tour Descartes

92066 Paris-La Défense Cedex 50

(C) Copyright IBM France 2006. Tous droits réservés.

Copyright International Business Machines Corporation 2006. All rights reserved.

Table des matières

Figures
A propos de ce guide
A qui s'adresse ce guide
Accessibilité
Conventions et terminologie utilisées dans ce manuel
Généralités
Présentation des composants Edge de WebSphere Application Server
Caching Proxy
Load Balancer
Dispatcher
Routage CBR (Content Based Routing)
Site Selector
Cisco CSS Controller
Nortel Alteon Controller
Metric Server
Les Composants Edge et la famille WebSphere
Tivoli Access Manager
WebSphere Portal Server
WebSphere Site Analyzer
WebSphere Transcoding Publisher
Informations complémentaires sur Application Server et Edge Components
Concepts et présentation des composants Edge
Mise en cache
Configurations de base de Caching Proxy
Caching Proxy inversé (configuration par défaut)
Caching Proxy d'acheminement
Concepts avancés de la mise en cache
Clusters de Caching Proxy à équilibrage de charge
Mise en cache de données dynamiques
Autres fonctions de mise en cache
Performances du réseau
Matériel réseau
Considérations sur la mémoire
Considération sur le disque dur
Considérations sur le réseau
Considérations sur le processeur
Architecture du réseau
Considérations sur la fréquentation du site Web et sur la charge de travail de serveur proxy
Considérations du type de trafic
Disponibilité
Equilibrage de charge
Equilibrage de la charge de plusieurs hôtes de données
Equilibrage de la charge de plusieurs serveurs proxy inversés
Load Balancer avec plusieurs serveurs proxy d'acheminement
Support de pannes
Content Based Routing
Scénarios
Réseau B2C
Phase 1
Phase 2
Phase 3
Solution bancaire B2C
Réseau de portail Web
Installation des Composants Edge
Conditions requises pour les Composants Edge
Configurations matérielle et logicielle requises
Utilisation de navigateurs avec les formulaires d'administration et de configuration de Caching Proxy
Utilisation de navigateurs avec l'aide en ligne de Load Balancer
Installation des Composants Edge à l'aide du programme d'installation
Utilisation du programme d'installation pour Windows
Utilisation du programme d'installation pour Linux et UNIX
Installation de Caching Proxy à l'aide des outils de regroupement du système
Désinstallation de modules Caching Proxy avec les outils système
Installation de Load Balancer à l'aide des outils de regroupement du système
Installation sous AIX
Avant de commencer
Procédure d'installation
Installation pour HP-UX
Avant de commencer
Procédure d'installation
Installation pour Linux
Avant de commencer
Procédure d'installation
Installation sous Solaris
Avant de commencer
Procédure d'installation
Construction de réseau avec les Composants Edge
Construction d'un réseau Caching Proxy
Flux de travail
Logiciels et systèmes requis
Création du serveur 1 (systèmes Linux et UNIX)
Création du serveur 1 (système Windows)
Configuration du serveur 1
Test du réseau de Caching Proxy
Construction d'un réseau Load Balancer
Flux de travail
Révision des matériels et logiciels requis
Configuration du réseau
Configuration de Dispatcher
Configuration à partir de la ligne de commande
Configuration à l'aide de l'assistant de configuration
Configuration à l'aide de l'interface graphique utilisateur (GUI)
Test du réseau Load Balancer
Annexes

Figures

  1. Caching Proxy fonctionnant comme un proxy inversé
  2. Caching Proxy fonctionnant comme un proxy d'acheminement
  3. Caching Proxy fonctionnant comme un proxy d'acheminement transparent
  4. Caching Proxy jouant le rôle de serveur proxy pour un cluster à charge équilibrée
  5. Equilibrage de la charge de plusieurs hôtes de données
  6. Equilibrage de la charge de plusieurs serveurs proxy inversés et hôtes de données
  7. Utilisation de Dispatcher pour équilibrer la charge de plusieurs serveurs proxy de mise en cache.
  8. Utilisation d'un composant Dispatcher principal et de secours pour garantir un accès à Internet à haute disponibilité.
  9. Localisation du composant Dispatcher de secours sur une machine Caching Proxy.
  10. Utilisation de composants Load Balancer principal et de secours pour une haute disponibilité des données Web
  11. Localisation du composant Load Balancer de secours sur l'hôte de données
  12. Routage de demandes HTTP avec CBR
  13. Equilibrage de charge pour les demandes HTTP acheminées avec CBR
  14. Réseau B2C (phase 1)
  15. Réseau B2C (phase 2)
  16. Réseau B2C (phase 3)
  17. Solution bancaire B2C
  18. portail Web
  19. Réseau de démonstration de Caching Proxy
  20. réseau de démonstration Load Balancer

A propos de ce guide

Le manuel WebSphere Application Server - Concepts, planification et installation pour Edge Components présente la suite des produits WebSphere Application Server - Edge Components. Il propose des présentations détaillées des produits et des fonctionnalités des composants importants, des scénarios mettant en oeuvre des composants Edge, des informations sur l'installation et la configuration initiale, des réseaux de démonstration.

A qui s'adresse ce guide

Le manuel WebSphere Application Server - Concepts, planification et installation pour Edge Components est destiné aux administrateurs réseau et système expérimentés qui maîtrisent parfaitement leurs systèmes d'exploitation et la notion de fourniture de services Internet. Aucune connaissance préalable de Application Server ou de WebSphere Application Server - Edge Components n'est requise.

Accessibilité

Les fonctions d'accessibilité permettent à un utilisateur ayant un handicap physique, telle qu'une mobilité restreinte ou une vision limitée, d'utiliser les produits logiciels. Les principales fonctions d'accessibilité de la structure WebSphere Application Server, version 6.1 sont les suivantes :

Conventions et terminologie utilisées dans ce manuel

Ce document utilise les conventions et règles typographiques décrites ci-après.

Tableau 1. Conventions utilisées dans ce manuel
Convention Signification
Gras Les intitulés des menus, options de menu, libellés, boutons, icônes et dossiers des interfaces graphiques utilisateur apparaissent également en caractères gras. Les caractères gras permettent également de mettre en évidence les noms de commandes afin de les distinguer du texte qui les entoure.
Espacement fixe Texte à entrer à une invite de commande, mais également texte affiché à l'écran, exemples de code et extraits de fichiers.
Italique Variables à entrer (par exemple, le nom d'un fichier dans la zone nom de fichier). Les italiques sont également utilisés pour mettre en évidence les titres des manuels.
Ctrl-x x est le nom d'une touche, indique une séquence de caractères de commande. Par exemple, Ctrl-c signifie maintenir la touche Ctrl enfoncée tout en appuyant sur la touche c.
Retour Fait référence à la touche libellée Retour ou Entrée, ou à la flèche vers la gauche.
% Représente l'invite de commandes du shell Linux et UNIX d'une commande qui ne nécessite pas les droits d'accès root.
# Représente l'invite de commandes du shell Linux et UNIX d'une commande qui requiert les droits d'accès root.
C:\ Représente l'invite Windows.
Entrée de commandes Lorsque vous êtes invité à "entrer" ou à "émettre" une commande, tapez la commande et appuyez sur la touche Retour. Par exemple, l'instruction "Entrez la commande ls" signifie tapez ls à l'invite et appuyez sur Retour.
[ ] Encadre les éléments facultatifs des descriptions de syntaxe.
{ } Encadre les listes dans lesquelles vous devez choisir un élément dans les descriptions de syntaxe.
| Sépare les éléments d'une liste de choix encadrés par { } (accolades) dans les descriptions de syntaxe.
... Dans les descriptions de syntaxe, indique que l'élément qui précède peut être répété une ou plusieurs fois. Dans les exemples, indique que des informations ont volontairement été omises par souci de concision.

Généralités

Cette partie présente WebSphere Application Server - Edge Components, Caching Proxy et Load Balancer et décrit leur intégration avec Application Server. Elle définit également les composants Caching Proxy et Load Balancer. De plus, cette partie présente d'autres produits de la famille WebSphere.

Elle comporte les chapitres suivants :

Présentation des composants Edge de WebSphere Application Server

WebSphere est un logiciel d'infrastructure Internet permettant aux entreprises de développer, de déployer et d'intégrer des applications de e-business, telles que celles de commerce B2B. Le produit middleware WebSphere prend en charge des applications d'entreprise de la publication Web simple aux traitements de transactions d'entreprise.

En tant que base de la plateforme WebSphere, WebSphere Application Server offre un jeu complet middleware permettant de concevoir, d'implémenter, de déployer et de gérer des applications d'entreprise, telles qu'un site Web rudimentaire de vente ou une révision complète de l'infrastructure de traitement d'une organisation.

Les fonctions gourmandes en temps processeur, telles que la personnalisation, offrent un avantage compétitif aux entreprises de commerce électronique. Cependant, confiner ces fonctions sur des serveurs centraux peut empêcher l'évolution des applications vers Internet. Avec l'ajout de nouvelles applications Web, l'infrastructure Internet d'une entreprise doit s'étendre et gagner en efficacité. En outre, la fiabilité et la sécurité sont essentielles pour une entreprise électronique. Tout dysfonctionnement même de courte durée peut entraîner une perte pour l'entreprise.

Les Composants Edge (anciennement Edge Server) sont à présent intégrés à l'offre WebSphere Application Server. Les Composants Edge peuvent être utilisés conjointement avec WebSphere Application Server pour contrôler les accès des clients aux serveurs Web et permettre aux entreprises d'offrir un meilleurs service aux utilisateurs ayant accès données Web via Internet ou un réseau intranet d'entreprise. L'utilisation des Composants Edge permet de réduire la charge du serveur Web, d'accroître la disponibilité des données et d'améliorer les performances du serveur Web. Le nom Composants Edge indique que le logiciel fonctionne généralement sur des postes situés à proximité (dans une configuration réseau) de la frontière entre l'intranet d'une entreprise et Internet.

WebSphere Application Server comporte les composants Edge Caching Proxy et Load Balancer.

IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :

Caching Proxy

Caching Proxy réduit l'utilisation de la bande passante et améliore la vitesse et la fiabilité d'un site Web en fournissant un point de présence pour un ou plusieurs serveurs de données d'arrière-plan. Caching Proxy peut placer en cache des données statiques ainsi que des données dynamiques générées par WebSphere Application Server.

Il est possible de configurer Caching Proxy comme un serveur proxy inversé (configuration par défaut) ou comme un serveur proxy d'acheminement, fournissant un point de présence pour un réseau ou un serveur de réseau interne devant améliorer les temps de demande et de réponse. Pour plus d'informations sur les configurations inversées et d'acheminement, voir Configurations de base de Caching Proxy.

Le serveur proxy intercepte les demandes de données émanant d'un client, extrait les informations demandées sur les hôtes de données et les fournit au client. Le plus souvent, les demandes concernent des documents stockés sur des serveurs Web (également appelés serveurs d'origine ou hôtes de données) et fournis à l'aide du protocole HTTP (Hypertext Transfer Protocol). Vous pouvez toutefois configurer le serveur proxy de sorte qu'il accepte d'autres protocoles, tels que FTP (File Transfer Protocol) et Gopher.

Le serveur proxy stocke les données dans une mémoire cache locale avant de les fournir au demandeur. Les données pouvant être mises en mémoire cache incluent des pages Web statiques et des fichiers JSP comportant des informations générées dynamiquement, mais peu sujettes à modification. La mise en mémoire cache permet au serveur proxy de satisfaire les demandes ultérieures afférentes aux mêmes données, directement depuis la mémoire cache locale, ce qui nécessite bien moins de temps qu'une nouvelle extraction depuis l'hôte de données.

Les plug-ins de Caching Proxy ajoutent des fonctionnalités au serveur proxy.

Vous pouvez personnaliser les fonctions de Caching Proxy en écrivant des plug-ins dans une interface de programmation d'application (API). L'API est souple, facile à utiliser et indépendante des plateformes. Le proxy effectue une séquence d'opérations pour chaque demande client qu'il traite. Une application de plug-in modifie ou remplace une opération dans le traitement des demandes, comme l'authentification client ou le filtrage des demandes. L'interface puissante Transmogrify, par exemple, fournit un accès aux données HTTP et autorise la substitution ou la transformation d'URL et de données Web. Les plug-ins peuvent modifier ou remplacer certaines étapes de traitement, et vous pouvez appeler plusieurs plug-ins pour une même étape de traitement.

Load Balancer

Load Balancer crée des systèmes Edge Server qui gèrent le flux du trafic réseau, réduisant la surcharge et équilibrant la charge sur divers autres services et systèmes. Load Balancer fournit des fonctions de sélection de site, de gestion de la charge de travail, d'affinité de session et de gestion transparente des pannes.

Le composant Load Balancer est installé entre Internet et les serveurs dorsaux de l'entreprise qui peuvent être des hôtes de données ou des machines Caching Proxy. Load Balancer fait office de point de présence unique de l'entreprise sur Internet, même si cette dernière utilise plusieurs serveurs dorsaux en raison d'une forte demande ou d'une grande quantité de données. Vous pouvez également garantir une haute disponibilité en installant un Load Balancer de secours chargé de prendre le relais en cas de panne temporaire de l'équilibreur principal.

Le composant Load Balancer intercepte les demandes de données émanant des clients et les transmet au serveur le mieux à même d'y répondre. En d'autres termes, il équilibre la charge des demandes entrantes sur un ensemble défini de machines qui traitent le même type de demandes. Le composant Load Balancer peut répartir les demandes entre différents types de serveurs, y compris les serveurs WebSphere Application Server et les machines Caching Proxy. L'équilibrage de charge peut être personnalisé pour une application ou une plateforme particulière à l'aide de conseillers personnalisés. Des conseillers d'objet spéciaux permettent d'obtenir des informations pour l'équilibrage de la charge de systèmes WebSphere Application Server.

Si le composant CBR (Content Based Routing) est installé en même temps que le composant Caching Proxy, les demandes HTTP peuvent même être réparties en fonction des 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. Le composant Dispatcher peut fournir la même fonction pour les demandes HTTP.

L'équilibrage de charge améliore la disponibilité et l'évolutivité de votre site Web en mettant en clusters serveurs HTTP, serveurs d'applications et serveurs proxy, qui sont des serveurs de données de remplacement. La disponibilité est réalisée à l'aide du parallélisme, l'équilibrage de charge et le support des pannes. Une panne de serveur ne bloque en rien les affaires. L'évolutivité de l'infrastructure informatique est considérablement améliorée car il est possible d'ajouter une puissance de traitement d'arrière-plan de façon transparente.

Prise en charge d'IPv6 : La prise en charge du schéma d'adressage IP étendu d'IPv6 est disponible avec "Load Balancer pour IPv4 et IPv6." Load Balancer pour IPv4 et IPv6 est une image d'installation distincte composée uniquement du composant Dispatcher. Ce type d'installation fournit un équilibrage de charge pour le trafic IPv4 et IPv6 sur les serveurs configurés dans votre réseau à l'aide de l'acheminement de paquets basé MAC du composant Dispatcher. Il est important de noter qu'il est nécessaire de désinstaller tout composant Load Balancer en place avant d'installer Load Balancer pour IPv4 et IPv6. Il n'est pas possible de faire cohabiter deux composants Load Balancers sur une même machine. (Pour une présentation rapide du composant Dispatcher, voir Dispatcher.)

Load Balancer comporte les composants suivants :

Dispatcher

Pour tous les services Internet, tels que HTTP, FTP, HTTPS et Telnet, le composant Dispatcher réalise l'équilibrage de la charge des serveurs sur un réseau local (LAN) ou un réseau étendu (WAN). Pour les services HTTP, Dispatcher réalise l'équilibrage de la charge des serveurs à partir de l'URL de la demande du client.

Le composant Dispatcher active la gestion stable et efficace d'un réseau de serveurs étendu et évolutif. Il permet de lier plusieurs serveurs individuels dans ce qui semble être un serveur virtuel unique. Votre site est référencé par une adresse IP unique sur l'Internet.

Si vous utilisez une installation Load Balancer pour IPv4 et IPv6, consultez le chapitre sur le déploiement de Dispatcher sur Load Balancer pour IPv4 et IPv6, qui contient des informations sur les limitations et les différences de configuration, dans le document WebSphere Application Server Load Balancer - Guide d'administration.

Routage CBR (Content Based Routing)

Pour les services HTTP et HTTPS, le composant routage CBR réalise l'équilibrage de la charge des serveurs en fonction du contenu de la demande du client. Le composant CBR fonctionne conjointement avec le composant Caching Proxy de Application Server.

IMPORTANT: Le composant CBR (routage CBR) est disponible sur toutes les plateformes prises en charge, sauf dans les cas suivants :

Site Selector

Ce composant crée un système d'équilibrage de charge qui fait office de point de présence sur un réseau et équilibre la charge des demandes entrantes en mappant les noms DNS sur les adresses IP. Utilisé conjointement avec Metric Server, Site Selector permet de contrôler le niveau d'activité d'un serveur, de détecter le serveur le moins chargé ou en panne.

Ce composant est pris en charge sur toutes les installations de composants Edge, sauf dans le cas suivant :

Cisco CSS Controller

Ce composant génère des mesures de pondération du serveur qui sont envoyées à un Cisco CSS switch pour la sélection du serveur, l'optimisation des charges et la tolérance aux erreurs.

Ce composant est pris en charge sur toutes les installations de composants Edge, sauf dans le cas suivant :

Nortel Alteon Controller

Ce composant génère des mesures de pondération du serveur qui sont envoyées à un Nortel Alteon switch pour la sélection du serveur, l'optimisation des charges et la tolérance aux erreurs.

Ce composant est pris en charge sur toutes les installations de composants Edge, sauf dans le cas suivant :

Metric Server

Ce composant s'exécute en tant que démon sur un serveur dont la charge est équilibrée et fournit des informations à propos des charges du système sur les composants Load Balancer.

Les Composants Edge et la famille WebSphere

La famille de produits IBM WebSphere a pour vocation d'aider les utilisateurs à réaliser leurs ambitions en matière de commerce électronique. Il s'agit d'un ensemble de logiciels permettant de développer et de gérer des sites Web hautes performances, et d'intégrer des sites Web dans des systèmes d'informations d'entreprise nouveaux ou existants mettant en oeuvre une technologie client-serveur classique.

La famille de logiciels WebSphere se compose de WebSphere Application Server, comprenant les Composants Edge, et d'autres logiciels de la famille WebSphere parfaitement intégré à WebSphere Application Server, et améliore ses performances. Pour une présentation WebSphere Application Server et de ses composants, "voir Présentation des composants Edge de WebSphere Application Server".

Tivoli Access Manager

Tivoli Access Manager (anciennement Tivoli Policy Director) est disponible séparément. Il fournit un contrôle d'accès et une sécurité centralisée pour des applications Web ainsi qu'une fonctionnalité d'authentification unique avec un accès à plusieurs ressources Web. Un plug-in Caching Proxy exploite la structure de sécurité d'Access Manager, permettant au serveur proxy d'utiliser les services d'autorisation ou d'authentification intégrés de celui-ci.

WebSphere Portal Server

WebSphere Portal Server (disponible séparément) propose une structure répondant aux exigences de présentation, de sécurité, d'évolutivité et de disponibilité des portails. Portal Server permet aux entreprises de créer leur site Web portail personnalisé répondant aux besoins des employés, des partenaires commerciaux et des clients. Après connexion au portail, les utilisateurs reçoivent des pages Web personnalisées fournissant un accès aux informations, personnes et applications requises. Ce point d'accès personnalisé uniquement à toutes les ressources nécessaires réduit la charge d'informations, accélère la productivité et augmente l'utilisation du site Web.

WebSphere Portal Server s'exécute dans un cluster WebSphere Application Server à des fins d'évolutivité et de fiabilité. Le composant Load Balancer de Application Server peut également être utilisé pour ajouter un équilibrage de charge et une disponibilité élevée.

WebSphere Site Analyzer

WebSphere Site Analyzer (disponible séparément) aide les entreprises à anticiper les problèmes de capacité et de performances. Les journaux de Caching Proxy et de Load Balancer ainsi que d'autres outils de gestion permettent d'anticiper les demandes de ressources supplémentaires en contrôlant, analysant et consignant l'activité de votre site Web. En outre, les composants de gestion Site Analyzer aident les utilisateurs à installer et à mettre à niveau les Composants Edge, gérer et stocker des configurations, exécuter les Composants Edge à distance, afficher et consigner des événements.

WebSphere Transcoding Publisher

WebSphere Transcoding Publisher (disponible séparément) permet de convertir une page Web pour la visualiser sur une unité mobile, de type téléphone connecté à Internet, de convertir des données Web dans la langue préférée de l'utilisateur (en appelant WebSphere Translation Server) et de convertir des langages de balisage. Transcoding Publisher augmente les fonctionnalités de Caching Proxy en permettant à celui-ci de servir des données pour des périphériques et des utilisateurs différents. Après avoir accédé à des données d'un serveur Web, l'interface Transmogrify de Caching Proxy peut être configurée pour transformer ces données en vue de les placer en mémoire cache et de les réutiliser le cas échéant. A partir de l'interface de post-authentification de Caching Proxy, Transcoding Publisher interroge le serveur proxy à la recherche de données correspondant aux exigences de l'utilisateur et du périphérique et, si une occurrence existe, les données sont extraites de la mémoire cache du serveur proxy.

Informations complémentaires sur Application Server et Edge Components

La documentation suivante s'applique à WebSphere Application Server Edge Components et est disponible dans le centre de documentation du logiciel Edge Components.

D'autres documents WebSphere Application Server sont disponibles dans la page de bibliothèque de WebSphere Application Server.

Des informations techniques sur le logiciel Edge Components sont disponibles dans la page de support WebSphere Application Server.

Les sites Web sur lesquels vous pouvez obtenir des informations relatives à Edge Components ou connexes sont les suivants :

Concepts et présentation des composants Edge

Cette partie comporte des présentations détaillées mettant en relief quelques fonctionnalités offertes par les composants Edge. Pour une présentation du composant Caching Proxy de Webpshere Application Server, voir Présentation des composants Edge de WebSphere Application Server.

Elle comporte les chapitres suivants :

Mise en cache

Performances du réseau

Disponibilité

Content Based Routing

Mise en cache

La fonction de mise en cache de Caching Proxy permet de réduire au minimum l'utilisation de la bande passante et d'assurer un service plus rapide et plus fiable aux utilisateurs finals. En effet, la fonction de cache réalisée par le serveur proxy allège les serveurs dorsaux et les liens de connexion. Caching Proxy peut placer en cache des données statiques ainsi que des données dynamiques générées par WebSphere Application Server. Pour améliorer la fonction de mise en cache, Caching Proxy travaille aussi conjointement avec le composant Application Server Load Balancer. Pour une présentation de ces systèmes, voir Présentation des composants Edge de WebSphere Application Server.

IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :

Configurations de base de Caching Proxy

Il est possible de configurer Caching Proxy comme un serveur proxy de mise en cache inversé (configuration par défaut) ou comme un serveur proxy de mise en cache d'acheminement. Lorsqu'il est utilisé par des hôtes de données, Caching Proxy est configuré comme serveur proxy, placé entre Internet et les hôtes de données des entreprises. Lorsqu'il est utilisé par des fournisseurs d'accès à Internet, il est configuré comme serveur proxy d'acheminement, placé entre un client et Internet.

Caching Proxy inversé (configuration par défaut)

Dans une configuration avec un proxy inversé, les machines Caching Proxy sont situées entre Internet et les hôtes de données de l'entreprise. Fonctionnant comme un serveur de secours, le serveur proxy intercepte les demandes utilisateur émanant d'Internet, les transmet à l'hôte de données approprié, stocke les données renvoyées en mémoire cache et fournit ces données aux utilisateurs via Internet. La mise en mémoire cache permet à Caching Proxy de satisfaire les demandes ultérieures afférentes aux mêmes données, directement depuis la mémoire cache locale, ce qui nécessite bien moins de temps qu'une nouvelle extraction depuis l'hôte de données. Les informations sont placées en mémoire cache selon certains critères, comme leur délai d'expiration, leur taille par rapport à celle du cache et leur délai de mise à jour. Des temps de téléchargement des occurrences trouvées en mémoire cache signifient une meilleure qualité de service pour les clients. La figure 1 illustre cette fonctionnalité de base du Caching Proxy.

Figure 1. Caching Proxy fonctionnant comme un proxy inversé
Ce graphique présente la configuration proxy inversé de base
Légende : 1--Client   2--Internet   3--Routeur/Passerelle   4--Proxy de mise en cache   5--Mémoire cache   6--Hôte de données

Dans cette configuration, le serveur proxy (4) intercepte les demandes dont les URL comportent le nom de l'hôte de données (6). Lorsqu'un client (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, en génère une nouvelle avec sa propre adresse IP comme adresse d'origine, et envoie la nouvelle demande à l'hôte de données (6).

L'hôte de données renvoie le fichier X au serveur proxy et non directement à l'utilisateur. Si le fichier peut être stocké en mémoire cache, Caching Proxy en stocke une copie dans sa mémoire cache (5) avant de la transmettre à l'utilisateur final. L'exemple le plus évident de données mises en cache concerne les pages Web statiques ; cependant, Caching Proxy permet également de mettre en cache et de fournir des données générées en dynamique par WebSphere Application Server.

Caching Proxy d'acheminement

Fournir un accès direct à Internet aux utilisateurs finals peut être source d'inefficacité. Tout utilisateur qui récupère un fichier donné à partir d'un serveur Web génère la même quantité de trafic sur votre réseau et via la passerelle Internet que le premier utilisateur ayant récupéré le fichier, même si ce dernier n'a pas été modifié. La solution consiste à installer un Caching Proxy d'acheminement près de la passerelle.

Dans une configuration avec un proxy d'acheminement, les machines Caching Proxy sont situées entre le client et Internet. Caching Proxy achemine la requête d'un client aux hôtes de données situés sur Internet, met en cache les données extraites et les fournit au client.

Figure 2. Caching Proxy fonctionnant comme un proxy d'acheminement
Ce graphique présente la configuration proxy d'acheminement de base

figure 2 présente la configuration d'un Caching Proxy d'acheminement. Les programmes du navigateur des clients (sur les machines marquées 1) sont configurés pour pour diriger les requêtes vers le proxy de mise en cache d'acheminement (2), lequel est configuré pour intercepter les requêtes. Lorsqu'un utilisateur final demande le fichier X stocké sur l'hôte de données (6), le proxy de mise en cache d'acheminement intercepte la requête, en génère une nouvelle avec sa propre adresse IP comme adresse d'origine et renvoie la nouvelle requête au moyen du routeur de l'entreprise (4) via Internet (5).

Le serveur d'origine renvoie ainsi le fichier X au proxy de mise en cache d'acheminement et non directement à l'utilisateur final. Si la fonctionnalité de mise en cache du proxy de mise en cache d'acheminement est activée, le proxy de mise en cache détermine si le fichier X est éligible pour la mise en cache en cochant des paramètres dans son en-tête de retour, comme la date d'expiration et une indication signalant si le fichier a été généré de façon dynamique. Si le fichier est susceptible d'être mis en cache, le proxy de mise en cache en stocke une copie dans sa mémoire cache (3) avant de la transmettre à l'utilisateur final. Par défaut, la mise en cache est activée et le proxy de mise en cache d'acheminement utilise un cache mémoire ; vous pouvez toutefois configurer d'autres types de mise en cache.

Pour la première demande du fichier X, le proxy d'acheminement n'améliore pas beaucoup les performances d'accès à Internet. En fait, pour le premier utilisateur accédant au fichier X, le temps de réponse est probablement plus long que sans le proxy de mise en cache car ce dernier a besoin de temps pour traiter le paquet de demande d'origine et pour rechercher les informations de mise en cache dans l'en-tête du fichier X, à la réception de ce dernier. En revanche, utiliser le proxy d'acheminement présente un intérêt lorsque d'autres utilisateurs demandent par la suite le fichier X. Le proxy vérifie la validité de sa copie cachée du fichier X (pas d'expiration) et récupère le fichier X directement dans le cache, sans acheminer la demande via Internet jusqu'à l'hôte de données.

Même en cas d'expiration d'un fichier demandé, le proxy de mise en cache d'acheminement ne doit pas nécessairement retourner récupérer le fichier dans l'hôte de données. Il envoie plutôt un message spécial de vérification d'état à l'hôte de données. Si ce dernier indique que le fichier est inchangé, le proxy peut encore fournir la version cachée à l'utilisateur de qui émane la demande.

Dans ce type de configuration, on parle de proxy de mise en cache d'acheminement car le proxy agit pour le compte des navigateurs, acheminant leurs requêtes aux hôtes de données via Internet. Les avantages dans ce cas sont doubles :

Le proxy de mise en cache peut fonctionner avec plusieurs protocoles de transfert en réseau, notamment HTTP (Hypertext Transfer Protocol, FTP (File Transfer Protocol) et Gopher.

Caching Proxy d'acheminement transparent (systèmes Linux uniquement)

Une variante du Caching Proxy d'acheminement est un Caching Proxy transparent. A ce titre, Caching Proxy exécute la même fonction qu'un Caching Proxy d'acheminement de base, mais sans que le client soit conscient de sa présence. Cette configuration transparente n'est prise en charge que sur les systèmes Linux.

Dans la configuration décrite dans Caching Proxy d'acheminement, chaque navigateur client est configuré de façon distincte de façon à diriger les demandes à un certain Caching Proxy d'acheminement. Gérer une telle configuration peut se révéler peu pratique, notamment lorsque les machines client sont en grand nombre. Caching Proxy prend en charge plusieurs solutions alternatives simplifiant l'administration. Une des possibilités consiste à le configurer comme un proxy transparent, comme décrit à la figure 3. Comme dans le cas d'un proxy d'acheminement classique, le proxy transparent est installé sur une machine près de la passerelle, mais les programmes du navigateur client ne sont pas configurés pour diriger les demandes à un proxy d'acheminement. La présence d'un proxy dans la configuration reste ignorée des clients. Un routeur est configuré pour intercepter les demandes du client et les diriger vers le proxy transparent. Lorsqu'un client utilisant l'une des machines 1 demande le fichier X stocké sur un hôte de données (6), le routeur (2) transmet la demande à Caching Proxy. Caching Proxy génère une nouvelle demande avec sa propre adresse IP comme adresse d'origine et renvoie la nouvelle requête au moyen du routeur (2) via Internet (5). Lorsque le fichier X arrive, Caching Proxy le met en cache s'il est adéquat (remplit les conditions décrites dans Caching Proxy d'acheminement) et le transmet au client demandeur.

Figure 3. Caching Proxy fonctionnant comme un proxy d'acheminement transparent
Ce graphique présente la configuration proxy d'acheminement de base

Pour les requêtes HTTP, une autre solution possible pour conserver les informations de configuration du proxy sur chaque navigateur consiste à utiliser la fonctionnalité de configuration automatique du proxy qui est disponible dans plusieurs programmes de navigateur, notamment Netscape Navigator versions 2.0 et ultérieures, et Microsoft Internet Explorer versions 4.0 et ultérieures.Dans ce cas, vous créez un ou plusieurs fichiers de configuration automatique de proxy et vous configurez les navigateurs pour qu'ils fassent référence à l'un d'entre eux plutôt qu'aux informations de configuration du proxy locales. Le navigateur remarque automatiquement toute modification apportée au fichier de configuration automatique et adapte son utilisation du proxy en conséquence. Vous éliminez ainsi le besoin de conserver des informations de configuration distinctes sur chaque navigateur, mais en plus vous pouvez réacheminer facilement les demandes en cas d'indisponibilité soudaine d'un serveur proxy.

Une troisième solution consiste à utiliser le mécanisme WPAD (Web Proxy Auto Discovery) disponible sur certains navigateurs, comme Internet Explorer version 5.0 et versions ultérieures. Lorsque vous activez cette fonctionnalité sur le navigateur, ce dernier localise automatiquement un serveur proxy compatible WPAD sur son réseau et y dirige ses requêtes Web. Dans ce cas, il est inutile de conserver des fichiers de configuration de proxy au niveau central. Caching Proxy est compatible WPAD.

Concepts avancés de la mise en cache

Clusters de Caching Proxy à équilibrage de charge

Pour fournir des fonctionnalités de cache plus poussées, utilisez Caching Proxy comme proxy inversé conjointement avec le composant Load Balancer. En intégrant des fonctions de cache et d'équilibrage de charge, vous pouvez créer une infrastructure de performances Web efficace et à forte capacité de gestion.

La figure 4 montre comment associer Caching Proxy au composant Load Balancer pour répondre efficacement aux demandes de données Web, même en cas de forte demande. Dans cette configuration, le serveur proxy (4) est configuré pour intercepter les demandes dont les URL comportent le nom d'hôte d'un cluster d'hôtes de données (7) par le composant Load Balancer (6).

Figure 4. Caching Proxy jouant le rôle de serveur proxy pour un cluster à charge équilibrée
Le graphique illustre le serveur proxy agissant en tant que serveur de secours pour un cluster dont la charge est équilibrée
Légende : 1--Client   2--Internet   3--Routeur/passerelle   4--Caching Proxy   5--Mémoire cache   6--Load Balancer   7--Hôte de données

Lorsqu'un client (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, en génère une nouvelle avec sa propre adresse IP comme adresse d'origine, et envoie la nouvelle demande au composant Load Balancer à l'adresse du cluster. Le composant Load Balancer utilise son algorithme d'équilibrage de charge pour déterminer quel hôte de données est le plus apte à satisfaire la demande portant sur le fichier X. Cet hôte de données renvoie le fichier X au serveur proxy et non via le composant Load Balancer. Le serveur proxy détermine s'il doit le stocker en mémoire cache, et le fournit à l'utilisateur, comme décrit précédemment.

Mise en cache de données dynamiques

La fonction de cache est également fournie par le plug-in Dynamic Caching de Caching Proxy. Lorsqu'il est utilisé avec WebSphere Application Server, Caching Proxy permet de placer en cache, de fournir et d'invalider des données dynamiques telles que des JSP (JavaServer Pages) et des réponses de servlet générées par WebSphere Application Server.

En général, les données dynamiques dont la durée de vie est illimitée doivent être marquées pour ne pas être placées en mémoire cache car la logique de suppression des données arrivées à expiration n'est pas fiable pour ce type de données. Le plug-in Dynamic Caching possède une logique de suppression orientée événement permettant au serveur proxy de placer en mémoire cache des données à durée de vie illimitée. La mise en cache de telles données évite aux hôtes de données d'appeler une machine Application Server de façon répétée pour répondre aux demandes de clients. Elle offre les avantages suivants :

L'activation de la fonction de cache des réponses de servlet est idéale pour les pages Web générées en dynamique d'une durée de vie basée sur la logique applicative ou sur un événement tel qu'un message extrait d'une base de données. Bien que la durée de vie d'une telle page soit limitée, la valeur TTL ne peut être fixée sur l'heure de création car le commutateur d'expiration ne peut être connu à l'avance. Si la valeur TTL de telles pages est fixée sur zéro, les hôtes de données sont pénalisés lors des échanges de données dynamiques.

La responsabilité de synchroniser le cache dynamique de Caching Proxy et de Application Server est partagée entre les deux systèmes. Par exemple, une page Web publique créée en dynamique par une application fournissant des prévisions météorologiques peut être exportée par Application Server et mise en cache par Caching Proxy. Caching Proxy peut fournir les résultats de l'application de façon répétée à un grand nombre d'utilisateurs jusqu'à ce que la page ne soit plus valide. Les données du cache des réponses de servlet de Caching Proxy sont valides jusqu'à la suppression d'une entrée par le serveur proxy car le cache est saturé, l'expiration du délai par défaut défini par la directive ExternalCacheManager du fichier de configuration de Caching Proxy ou la réception d'un message Invalidate par Caching Proxy lui ordonnant de supprimer les données de son cache. Les messages Invalidate émanent de la machine WebSphere Application Server et sont envoyés à chaque Caching Proxy configuré.

Remarque :
Les pages privées générées en dynamique (comme c'est le cas d'une page affichant le contenu du panier électronique d'un utilisateur) ne peuvent généralement pas et ne doivent pas être mises en cache par Caching Proxy. Caching Proxy peut placer en cache des pages privées et les fournir uniquement quand il est configuré pour effectuer des opérations d'authentification et d'autorisation, ce qui garantit que ces pages ne sont transmises qu'aux utilisateurs auxquels elles sont destinées.

Autres fonctions de mise en cache

Caching Proxy offre d'autres fonctions importantes de mise en cache :

Performances du réseau

Les performances réseau sont concernées par l'introduction de la fonctionnalité de Caching Proxy. Caching Proxy peut être utilisé seul ou avec Load Balancer afin d'améliorer les performances du réseau. Le Présentation des composants Edge de WebSphere Application Server fournit une présentation de ces systèmes.

Les performances de Caching Proxy sont aussi importantes que le matériel sur lequel le logiciel est installé et que l'architecture globale dans laquelle est intégré le système. Pour optimiser les performances réseau, adaptez le matériel et l'architecture réseau globale aux caractéristiques des serveurs proxy.

La configuration et l'administration de base du logiciel Caching Proxy et de la personnalisation au niveau du système d'exploitation contribuent également en grande partie aux performances de Caching Proxy. La plupart des modifications de la configuration logicielle permettent d'accroître sensiblement les performances. Elles comprennent mais ne sont pas limitées au réglage des directives de journalisation, des règles de mappage, des plug-ins, des valeurs de délai, des valeurs de configuration de la mémoire cache et des valeurs de threads actives. La configuration du logiciel Caching Proxy est étudiée en détails dans le Guide d'administration de Caching Proxy.

La plupart des modifications du système d'exploitation permettent également d'améliorer les performances ; elles comprennent mais ne sont pas limitées au réglage de TCP et ARP, à l'augmentation des limites des descripteurs de fichier, au réglage des cartes d'interfaces réseau (NIC pour Network Interface Cards) et au respect de bonnes pratiques lors de l'exécution de tâches d'administration système.

IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :

Matériel réseau

La section traite des points de l'architecture réseau à prendre en compte lors de l'installation de Caching Proxy.

Considérations sur la mémoire

Une grande quantité de mémoire doit être allouée au serveur proxy. Caching Proxy peut consommer 2 Go d'espace d'adressage virtuel lorsqu'une mémoire cache importante est configurée. La mémoire est également requise pour le noyau, les bibliothèques partagées et les zones tampons réseau. Par exemple, un serveur proxy peut requérir 3 ou 4 Go de mémoire physique. Notez qu'un cache en mémoire vive est considérablement plus rapide qu'une mémoire cache sur disque. Ce changement de configuration suffit à améliorer les performances.

Considération sur le disque dur

Il est important de disposer d'un espace disque important sur la machine hébergeant Caching Proxy. Ceci est particulièrement vrai lorsque des mémoires cache sont employées. La lecture et l'écriture disque sont des processus intensifs pour l'ordinateur. Bien que les procédures d'E-S de Caching Proxy soient efficaces, les limitations mécaniques des disques durs limitent des performances quand Caching Proxy est configuré pour utiliser le cache disque. Le goulet d'étranglement des E-S disque peut être supprimé en utilisant plusieurs disques durs pour des périphériques de cache brut et des fichiers journaux ainsi que des unités de disque aux vitesses de recherche, de rotation et de transfert supérieures.

Considérations sur le réseau

Les ressources réseau telles que la vitesse, le type et le nombre de cartes réseau ainsi que la vitesse de la connexion réseau au serveur proxy influent directement sur les performances de Caching Proxy. Pour des performances optimales, il est conseillé d'utiliser deux cartes réseau sur le serveur proxy : une pour le trafic entrant, une pour le trafic sortant. Il est fréquent qu'une seule carte réseau atteigne sa limite maximale par échange entre le client et le serveur HTTP. De plus, les cartes réseau doivent avoir un débit minimal de 100 Mo et être configurées pour un fonctionnement en mode duplex. En effet, une négociation automatique entre le périphérique de routage et le périphérique de commutation peut générer des erreurs et réduire le débit. Enfin, la vitesse de la connexion réseau est très importante. Par exemple, vous ne pouvez envisager de traiter de façon optimale un grand nombre de demandes si la connexion à la machine Caching Proxy est un ligne T1 saturée.

Considérations sur le processeur

L'unité centrale de traitement (UC) d'une machine Caching Proxy peut devenir un facteur de limitation. La puissance de l'UC affecte la vitesse de traitement des demandes CPU ; le nombre d'UC du réseau, l'évolutivité. Il est important de respecter les ressources processeur du serveur proxy, de façon à gérer la charge maximale de demandes que le serveur proxy traitera.

Architecture du réseau

Pour des performances globales, il est généralement souhaitable d'avoir une vision globale de l'architecture au lieu de se concentrer sur des éléments matériels spécifiques. Peu importe le nombre de composants matériels que vous ajoutez à une machine, ceux-ci doivent offrir un niveau maximal de performance.

La section traite des points de l'architecture réseau à prendre en compte lors de l'installation de Caching Proxy.

Considérations sur la fréquentation du site Web et sur la charge de travail de serveur proxy

Si le site Web de votre entreprise est très apprécié, la demande de contenu peut excéder la capacité d'un serveur proxy et potentiellement diminuer les performances. Pour optimiser les performances réseau, vous pouvez ajouter des clusters de machines Caching Proxy à équilibrage de charge ou utiliser une architecture de cache partagée avec Remote Cache Access (RCA) dans votre architecture réseau globale.

Considérations du type de trafic

L'amélioration des performances est en grande partie due aux fonctions de cache de Caching Proxy. Cependant, le cache du serveur proxy peut devenir un goulet d'étranglement s'il n'est pas configuré correctement. Pour déterminer la meilleure configuration de cache, un effort significatif doit être apporté à l'analyse des caractéristiques du trafic. Le type, la taille, la quantité et les attributs des données influent sur les performances du serveur proxy en termes de vitesse d'extraction de documents sur les serveurs origine et de charge du serveur. Quand vous comprenez le type de trafic que Caching Proxy s'apprête à mandater ou à servir à partir du cache, vous pouvez prendre en compte ces caractéristiques au moment de la configuration du serveur proxy. Par exemple, savoir que 80 % des objets à placer en mémoire cache sont des images (*.gif ou *.jpg) d'une taille approximative de 200 Ko vous permet de personnaliser les paramètres du cache et la taille du cache. En outre, savoir que la plupart des données sont des pages dynamiques qui ne seront pas placées en mémoire est un facteur déterminant pour le réglage de Caching Proxy.

L'analyse des caractéristiques du trafic permet de déterminer si l'utilisation d'un cache mémoire ou d'un cache disque peut optimiser les performances de votre cache. De même, une bonne connaissance de ces caractéristiques permet de déterminer si l'utilisation de la fonction de cache dynamique de Caching Proxy engendrera une amélioration des performances.

Disponibilité

Fonctionnant conjointement avec des hôtes de données, comme WebSphere Application Server, ou avec le composant Caching Proxy de Application Server, le composant Load Balancer de Application Server permet d'augmenter la disponibilité et l'évolutivité de votre réseau. Présentation des composants Edge de WebSphere Application Server fournit une présentation de ces composants Edge. Utilisé par les réseaux d'entreprise, Load Balancer est installé entre l'Internet et les serveurs dorsaux. Load Balancer fait office de point de présence unique de l'entreprise sur Internet, même si cette dernière utilise plusieurs serveurs dorsaux en raison d'une forte demande ou d'une grande quantité de données.

La disponibilité est assurée par l'équilibrage de charge et le support de pannes.

IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :

Equilibrage de charge

L'équilibrage de charge améliore la disponibilité et l'évolutivité de votre site Web en mettant en clusters serveurs proxy et serveurs d'applications. L'évolutivité de l'infrastructure informatique est considérablement améliorée car il est possible d'ajouter une puissance de traitement d'arrière-plan de façon transparente.

Equilibrage de la charge de plusieurs hôtes de données

Vous pouvez satisfaire les fortes demandes en dupliquant les données sur plusieurs hôtes, mais il vous faut alors un moyen d'équilibrer la charge entre eux. DNS (Domain Name Service) peut équilibrer la charge par la technique de permutation circulaire, mais les performances de cette technique sont insuffisantes dans certains cas.

Une solution plus élaborée d'équilibrage de la charge de plusieurs hôtes de données consiste à utiliser le composant Dispatcher de Load Balancer, comme l'illustre la figure 5. Dans cette configuration, tous les hôtes de données (machines associées au chiffre 5) stockent les mêmes données. Ils sont définis de manière à former un cluster et l'une des interfaces réseau de la machine Load Balancer (4) reçoit un nom d'hôte et une adresse IP dédiés au cluster. 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 composant Dispatcher intercepte la demande car son URL comporte le nom d'hôte et l'adresse IP de ce composant. Le composant Dispatcher détermine quel est l'hôte du cluster le plus apte à satisfaire la demande et dirige celle-ci sur cet hôte qui, lorsque la méthode de transfert MAC est configurée, renvoie le fichier X directement au client (le fichier X ne traverse donc pas Load Balancer).

Figure 5. Equilibrage de la charge de plusieurs hôtes de données
Le graphique présenté ici illustre l'équilibrage de charge entre plusieurs hôtes de données
Légende : 1--Client   2--Internet   3--Routeur/passerelle   4--Dispatcher   5--Hôte de données
Remarque :
Le composant Dispatcher propose trois méthodes de transfert :

Par défaut, le composant Dispatcher applique la technique de permutation circulaire comme DNS et, même ainsi, comble de nombreuses lacunes de DNS. Contrairement à DNS, il contrôle la disponibilité et l'accessibilité d'un hôte de données et cesse de diriger les clients sur cet hôte s'il n'est pas disponible. Qui plus est, il prend en compte la charge actuelle supportée par les hôtes de données en effectuant le suivi des connexions nouvelles, actives et terminées. Vous pouvez optimiser davantage l'équilibrage de charge en activant les composants de conseil et de gestion facultatifs de Load Balancer qui effectuent un suivi encore plus précis de l'état d'un hôte de données et incorporent les informations complémentaires dans le processus de décision d'équilibrage de charge. Le gestionnaire permet d'affecter des poids différents aux divers facteurs utilisés dans le processus de décision, ce qui permet de personnaliser davantage l'équilibrage de la charge sur votre site.

Equilibrage de la charge de plusieurs serveurs proxy inversés

Dispatcher de Load Balancer permet également de réaliser un équilibrage de charge entre plusieurs machines Caching Proxy. Si le site Web de votre entreprise est très apprécié, la demande de contenu peut excéder la capacité d'un serveur proxy unique et potentiellement diminuer les performances du serveur proxy.

Les différents Caching Proxy peuvent alors agir comme proxy pour un seul hôte de données (comme dans la configuration décrite à la figure 1), mais si la fréquentation intense de votre site nécessite plusieurs serveurs proxy, vous aurez également besoin de plusieurs hôtes de données dont vous équilibrerez les charges à l'aide de Load Balancer (voir la figure 6. Le composantDispatcher 4 équilibre la charge d'un cluster de deux serveurs proxy (5), et le composant Dispatcher 7 équilibre la charge d'un cluster de trois hôtes de données (8).

Figure 6. Equilibrage de la charge de plusieurs serveurs proxy inversés et hôtes de données
Le graphique présenté ici illustre l'équilibrage de charge entre plusieurs serveurs proxy et hôtes de données
Légende : 1--Client   2--Internet   3--Routeur/passerelle   4--Dispatcher   5--serveur proxy   6--Cache   7--Dispatcher   8--Hôte de données

Le nom d'hôte du cluster du composant Dispatcher 4 est le nom d'hôte qui apparaît dans les URL des données Web de l'entreprise (il s'agit du nom du site Web, tel qu'il apparaît sur Internet). Le nom d'hôte du cluster du composant Dispatcher 7 est invisible sur Internet et peut prendre la valeur de votre choix. A titre d'exemple, pour ABC Corporation, le nom d'hôte du composant Dispatcher 4 pourrait être www.abc.com, alors que le composant Dispatcher 7 serait du type http-balancer.abc.com.

Supposez qu'un navigateur de l'une des machines clientes 1 doive accéder au fichier X stocké sur les serveurs de données 8. La demande HTTP traverse Internet (2) et pénètre sur le réseau interne de l'entreprise au niveau de la passerelle (3). Le routeur achemine la demande au composant Dispatcher 4 qui la transmet au serveur proxy (5) qui est actuellement le mieux à même de la traiter conformément à l'algorithme d'équilibrage de charge. Si le serveur proxy dispose du fichier X dans sa mémoire cache (6), il le renvoie directement au navigateur, en contournant le composant Dispatcher 4.

Si le serveur proxy ne possède aucune copie du fichier X dans sa mémoire cache, il crée une nouvelle demande contenant son nom d'hôte dans la zone d'origine de l'en-tête et l'envoie au composant Dispatcher 7. Le composant Load Balancer détermine quel hôte de données (8) est actuellement le mieux à même de satisfaire la demande et la dirige sur celui-ci. L'hôte de données extrait le fichier X de son lieu de stockage et le renvoie directement au serveur proxy, en contournant le composant Dispatcher 7. Le cas échéant, le serveur proxy stocke le fichier X en mémoire cache et l'achemine vers le navigateur, en contournant le composant Dispatcher 4.

Load Balancer avec plusieurs serveurs proxy d'acheminement

Si vous fournissez un accès Internet à un grand nombre de clients, le risque est qu'ils génèrent plus de demandes d'accès que celles auxquelles peut répondre un seul proxy. Au fur et à mesure que Caching Proxy est surchargé de demandes, les clients risquent d'expérimenter des temps de réponse encore plus longs que s'ils passaient par un accès direct à Internet. Et en cas d'échec ou de non accessibilité de Caching Proxy suite à une défaillance du réseau, l'accès à Internet devient impossible. La solution consiste à installer plusieurs machines Caching Proxy et à utiliser le composant Dispatcher de Load Balancer pour équilibrer les charges entre elles.

Sans Dispatcher, vous pouvez fournir un véritable serveur proxy transparent avec plusieurs machines Caching Proxy uniquement si vos routeurs peuvent acheminer le même type de trafic à plusieurs modules Caching Proxy (non possible avec tous les routeurs). Un service de proxy d'acheminement traditionnel est possible sur plusieurs machines Caching Proxy sans Dispatcher, mais il est alors nécessairede configurer de façon explicite les navigateurs client pour qu'ils utilisent l'une des machines comme proxy principal. En cas d'échec,de surcharge ou d'inaccessibilité de celui-ci, les utilisateurs finals risquent de ne plus pouvoir accéder à Internet. Pour éviter cette situation, vous pouvez créer un fichier de configuration automatique de proxy (comme décrit dans Caching Proxy d'acheminement transparent (systèmes Linux uniquement)) qui oriente le navigateur vers un ou plusieurs proxies de mise en cache secondaires. Un fichier de configuration automatique de proxy ne gère pas l'équilibrage de charge entre plusieurs machines Caching Proxy ; par conséquent, si une machine reçoit beaucoup plus de demandes qu'une autre, ses performances risquent de se dégrader, avec des temps de réponse plus longs pour ses clients. Pour que les performances soient égales pour tous les clients, vous devez configurer l'utilisation de chaque proxy de mise en cache par un nombre de navigateurs sensiblement égal et suivre manuellement la distribution pour maintenir la charge à un niveau égal même si vous ajoutez ou supprimez des navigateurs.

La figure 7 présente une configuration réseau dans laquelle le composant Dispatcher équilibre la charge d'un cluster de machines Caching Proxy. L'une des interfaces réseau de la machine Dispatcher est configurée pour porter l'adresse IP et le nom d'hôte dédié du cluster. Les navigateurs client sont configurés pour diriger leurs demandes Internet vers le nom d'hôte du cluster. Par exemple, lorsqu'un navigateur sur l'une des machines client 1 doit accéder au fichier X sur un hôte de données (7), il dirige sa demande vers le nom d'hôte ou l'adresse du cluster, où Dispatcher (2) l'intercepte et la dirige vers la machine Caching Proxy adaptée (3). Cette dernière crée une nouvelle demande, la fait transiter par la passerelle de l'entreprise (5) et via Internet (6), et le cas échéant, stocke le fichier renvoyé dans son cache (4) comme décrit de façon plus détaillée dans Caching Proxy d'acheminement

Remarque :
La fonctionnalité de proxy transparent n'est prise en charge que sur les systèmes Linux.
Figure 7. Utilisation de Dispatcher pour équilibrer la charge de plusieurs serveurs proxy de mise en cache.
Ce graphique présente l'équilibrage de charge entre plusieurs serveurs proxy

Le composant Dispatcher détecte si l'une des machines Caching Proxy est indisponible et achemine automatiquement les demandes vers une autre. Vous pouvez ainsi arrêter une machine Caching Proxy à des fins de maintenance sans interrompre l'accès à Internet. Grâce aux nombreuses options de configuration de Dispatcher, vous pouvez contrôler les facteurs à prendre en compte pour la prise de décision en matière d'équilibrage de charge. Vous pouvez également installer des programmes Dispatcher auxiliaires sur les machines Caching Proxy pour surveiller leur statut et renvoyer les informations au Dispatcher. Pour plus de détails, voir le document WebSphere Application Server Load Balancer - Guide d'administration. L'utilisation de plusieurs serveurs proxy de mise en cache peut induire une inefficacité potentielle dans la mesure où plus d'un proxy peut mettre en cache le même fichier si différents clients le demandent via différentes machines Caching Proxy. Pour éliminer la redondance, vous pouvez configurer un accès RCA (Remote Cache Access) qui permet à tous les serveurs proxy d'un groupe défini de partager entre eux le contenu de leur cache. Les proxies de ce groupe utilisent tous le même algorithme pour déterminer lequel est responsable d'une adresse URL donnée. Lorsqu'un proxy intercepte une adresse URL dont il n'est pas responsable, il transmet la demande au proxy concerné. Ce dernier effectue le travail voulu, soit en extrayant le fichier voulu du cache ou en acheminant la requête vers l'hôte de données voulu et en mettant en cache le fichier renvoyé, le cas échéant. Le proxy concerné transmet ensuite le fichier au proxy d'origine qui le fournit à son tour à l'utilisateur final demandeur.

Dans le groupe RCA, si le proxy responsable d'une adresse URL donnée échoue, le proxy d'origine, qui a reçu la demande du client, accède directement à l'hôte de données (ou à un serveur proxy de mise en cache de secours, s'il est défini). Autrement dit, les utilisateurs peuvent accéder à des fichiers tant qu'au moins un serveur proxy du groupe RCA fonctionne correctement.

Cette configuration est adaptée pour les fortes demandes d'accès à Internet grâce au composant Dispatcher qui équilibre la charge de demandes entre plusieurs machines Caching Proxy. Un des problèmes potentiels réside dans le fait que Dispatcher constitue un point de défaillance unique. S'il échoue ou devient inaccessible suite à une panne réseau, les clients du navigateur ne peuvent pas atteindre les serveurs proxy de mise en cache ou Internet. La solution consiste à con figurer un autre Dispatcher qui fonctionne comme remplaçant de secours, comme décrit à la figure 8.

Figure 8. Utilisation d'un composant Dispatcher principal et de secours pour garantir un accès à Internet à haute disponibilité.
Ce graphique présente un composant Dispatcher principal et un composant de secours pour l'équilibrage de la charge de plusieurs serveurs proxy

Ici, un navigateur s'exécutant sur l'une des machines 1 dirige normalement sa demande de fichier X vers le Dispatcher principal (2), lequel achemine la demande au Caching Proxy (4) séléctionné sur la base des critères d'équilibrage de charge du composant Dispatcher. Le proxy de mise en cache crée une nouvelle demande, la fait transiter par la passerelle de l'entreprise (6) et via Internet (7) jusqu'à l'hôte de données (8), et le cas échéant, stocke le fichier renvoyé dans son cache (5) (comme décrit de façon plus détaillée dans Caching Proxy d'acheminement).

Dans cette configuration, le Dispatcher de secours (3) n'effectue aucun équilibrage de charge tant que le Dispatcher principal est opérationnel. Les composants Dispatcher principal et de secours suivent leur état respectif en s'échangeant périodiquement des messages appelés signaux de présence.Si le composant Dispatcher de secours détecte que le composant principal est tombé en panne, il prend automatiquement la responsabilité d'équilibrer la charge en interceptant les demandes dirigées vers le nom d'hôte et l'adresse IP du composant principal.Il est également possible de configurer deux composants Dispatcher pour une haute disponibilité mutuelle. Dans ce cas, chacun des composants effectue l'équilibrage de charge pour un cluster distinct de serveurs proxy de mise en cache et agit simultanément comme dispositif de secours pour son homologue.Pour plus de détails, voir le document WebSphere Application Server Load Balancer - Guide d'administration.

En général, le composant Dispatcher ne consomme pas beaucoup de ressources de traitement ou de stockage, et d'autres applications peuvent s'exécuter sur la machine Dispatcher. Si une réduction des coûts de l'équipement est essentielle, il est même possible d'exécuter le composant Dispatcher de secours sur la même machine que le proxy de mise en cache.La figure 9 illustre une configuration de ce type, dans laquelle le composant Dispatcher de secours est exécuté sur la même machine (3) que le serveur proxy de mise en cache.

Figure 9. Localisation du composant Dispatcher de secours sur une machine Caching Proxy.
Ce graphique présente un composant Dispatcher principal et un composant de secours pour l'équilibrage de la charge de plusieurs serveurs proxy

Support de pannes

Load Balancer joue le rôle d'un point de présence unique pour les hôtes de données de votre entreprise. Vous diffusez le nom d'hôte et l'adresse du cluster dans DNS au lieu de ceux de l'hôte de données, ce qui vous protège contre d'éventuelles attaques et confère une certaine homogénéité au site Web de votre entreprise. Pour augmenter la disponibilité du site Web, n'hésitez pas à configurer un autre composant Load Balancer qui assurera le relais du composant Load Balancer principal, comme décrit à la figure 10. S'il tombe en panne ou devient inaccessible en raison d'un incident sur le réseau, les utilisateurs finals peuvent toujours accéder aux hôtes de données.

Figure 10. Utilisation de composants Load Balancer principal et de secours pour une haute disponibilité des données Web
Le graphique présenté ici illustre l'utilisation de composants Dispatcher principal et de secours pour une haute disponibilité des données Web
Légende : 1--Client   2--Internet   3--Routeur/passerelle   4--Dispatcher principal;   5--Dispatcher de secours   6--Hôte de données

En situation normale, un navigateur fonctionnant sur l'une des machines associées au chiffre 1 dirige sa demande portant sur le fichier X vers le nom d'hôte de cluster assigné au composant Load Balancer principal (4). Le composant Dispatcher achemine la demande vers l'hôte de données (6) sélectionné en fonction des critères d'équilibrage de charge du composant Dispatcher. L'hôte de données envoie le fichier X directement au navigateur, en l'acheminant via la passerelle de l'entreprise (3) sur Internet (2), mais en contournant le composant Load Balancer.

Le composant Dispatcher de secours (5) n'effectue aucun équilibrage de charge tant que le composant principal est opérationnel. Les composants Dispatcher principal et de secours suivent leur état respectif en s'échangeant périodiquement des messages appelés signaux de présence. Si le composant Dispatcher de secours détecte que le composant principal est tombé en panne, il prend automatiquement la responsabilité d'équilibrer la charge en interceptant les demandes dirigées vers le nom d'hôte et l'adresse IP du composant principal.

Il est également possible de configurer deux composants Dispatcher pour une disponibilité mutuelle élevée. Dans ce cas, chacun des composants effectue l'équilibrage de charge pour un cluster distinct d'hôtes de données et agit simultanément comme dispositif de secours pour son homologue. (Sur les installations de Load Balancer pour IPv4 et IPv6, la haute disponibilité simple est prise en charge, mais pas la haute disponibilité mutuelle.)

En général, le composant Dispatcher consomme beaucoup de ressources de traitement ou de stockage, et d'autres applications peuvent s'exécuter sur la machine Load Balancer. Si une réduction des coûts de l'équipement est essentielle, il est même possible d'exécuter le composant Dispatcher de secours sur l'une des machines du cluster dont il équilibre la charge. La figure 11 illustre une configuration de ce type, dans laquelle le composant Dispatcher de secours est exécuté sur l'un des hôtes de données (5) du cluster.

Figure 11. Localisation du composant Load Balancer de secours sur l'hôte de données
Le graphique qui s'affiche présente le composant Dispatcher de secours exécuté sur un hôte de données
Légende : 1--Client   2--Internet   3--Routeur/passerelle   4--Dispatcher principal   5--Dispatcher de secours et hôte de données   6--Hôte de données

Content Based Routing

IMPORTANT: Le composant CBR (routage CBR) est disponible sur toutes les plateformes prises en charge, sauf dans les cas suivants :

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. Le 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 appropriée si vos serveurs Web doivent effectuer différentes fonctions ou offrir plusieurs types de services. 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.

Figure 12. Routage de demandes HTTP avec CBR
Le graphique présenté ici illustre le routage des demandes HTTP avec CBR
Légende : 1--Client   2--Internet   3--Routeur/passerelle   4--Caching Proxy et composant CBR de Load Balancer   5--Mémoire cache   6, 7, 8--Hôte de données

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.

Figure 13. Equilibrage de charge pour les demandes HTTP acheminées avec CBR
Le graphique présenté ici illustre l'équilibrage de charge pour les demandes HTTP acheminées avec CBR
Légende : 1--Client   2--Internet   3--Routeur/passerelle   4--Caching Proxy et composant CBR de Load Balancer   5--Mémoire cache   6, 7--Load Balancer   8--Hôte de données   9--Serveur Web

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).

Scénarios

Cette partie propose des scénarios utilisant des composants Edge de IBM WebSphere Application Server. Ces solutions constituent des solutions architecturales testées et efficaces à haut niveau de performances, disponibilité, évolutivité et fiabilité.

Elle comporte les chapitres suivants :

Réseau B2C

Solution bancaire B2C

Réseau de portail Web

Réseau B2C

Le site Web de commerce électronique de base est un réseau B2C. Dans la première phase de développement d'Internet, les entreprises avaient pour principale préoccupation d'être présentes sur le Web. Des informations d'entreprise et des catalogues de produits sont convertis dans des formats numériques et publiés sur le site Web. Les achats s'effectuent en fournissant adresses e-mail, numéros de téléphone et de télécopie, voire des formulaires automatiques. Il n'est cependant pas possible d'effectuer un shopping digne de ce nom. Toutes les transactions ont une latence inhérente car la commande doit être traitée manuellement.

Dans la deuxième phase, les entreprises suppriment cette latence et assouplissent le processus de vente en implémentant des paniers sécurisés pour des achats directs en ligne. La synchronisation avec des bases de données du stock et l'intégration avec des systèmes bancaires sont essentielles pour le traitement de transactions commerciales. Tout produit indisponible ne peut être ni vendu ni facturé au client. De même, un produit ne peut être prélevé du stock et livré à un client tant qu'il n'a pas fait l'objet d'une transaction financière valide.

Dans la troisième phase, le site Web d'entreprise évolue vers un site de présentation où le client reçoit des données personnalisées en fonction de son poste de travail et de ses choix.

Le scénario suivant inclut Load Balancer et Caching Proxy.

IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :

Phase 1

La figure 14 représente un petit site Web commercial de consultation rationnelle de catalogues. Toutes les demandes du client passent au travers d'un pare-feu avant d'être transmises à un Dispatcher qui les achemine vers un cluster de serveurs proxy dont les mémoires cache jouent le rôle de serveurs de remplacement pour les serveurs Web. Des serveurs de mesure sont associés aux serveurs proxy pour fournir des données d'équilibrage de charge au Dispatcher. Cet ensemble réduit la charge du réseau sur les serveurs Web et les protège de l'Internet.

Figure 14. Réseau B2C (phase 1)
Ce graphique représente un exemple de réseau B2C de base

Phase 2

La figure 15 représente la deuxième phase de l'évolution d'un site Web commercial offrant des fonctions de consultation efficace de catalogues, ainsi que des paniers électroniques sécurisés et rapides. Toutes les demandes des clients sont routées vers la branche appropriée du réseau par un Dispatcher séparant les demandes basée sur IP. Les demandes HTTP et les demandes HTTPS sont dirigées vers le site Web statique et le réseau d'achat respectivement. Le site Web statique principal est servi par un cluster de serveurs proxy avec des mémoires cache actives en tant que serveurs de remplacement pour les serveurs Web. Cette partie du réseau correspond au réseau de la première phase.

La partie commerce électronique du site Web est également servie par un cluster de serveurs proxy. Cependant, les noeuds Caching Proxy sont agrémentés de plusieurs modules de plug-in. Le protocole d'établissement de liaison SSL est déchargé vers une carte matérielle de chiffrement et l'authentification est effectuée à l'aide du plug-in Access Manager (anciennement Policy Director). Un plug-in Dynamic Caching réduit la charge de travail sur le serveur WebSphere Application Server en stockant les données courantes. Un plug-in sur le serveur d'applications invalide les objets dans Dynacache si nécessaire.

Toutes les applications de panier électronique sont liées à la base de données des clients qui a été utilisée pour authentifier l'utilisateur. Ainsi, l'utilisateur n'a pas besoin d'entrer des informations personnelles dans le système deux fois, une fois pour l'authentification et une autre pour faire des achats.

Ce réseau répartit le trafic selon l'utilisation du client et supprime l'authentification SSL intensive du processeur et les paniers électroniques du site Web principal. Ce site Web double permet à l'administrateur réseau d'adapter les divers serveurs afin de fournir des performances excellentes en fonction du rôle du serveur dans le réseau.

Figure 15. Réseau B2C (phase 2)
Ce graphique représente un exemple de réseau B2C

Phase 3

La figure 16 représente la troisième phase de l'évolution d'un réseau B2C quand le Web statique adopte une méthode de présentation dynamique. Le cluster de serveurs proxy a été amélioré pour supporter la mise en cache de données Web dynamiques et l'assemblage de fragments de page écrits conformément au protocole ESI (Edge Side Includes). Au lieu d'utiliser des mécanismes de SSI (Server-Side Includes) pour créer des pages Web sur les serveurs de données, puis de propager ces pages spécifiques sur le réseau, les mécanismes ESI permettent d'assembler des pages à partir de données résidant en mémoire cache, ce qui réduit la consommation de bande passante et les temps de réponse.

Les mécanismes ESI revêtent une importance particulière dans ce scénario car chaque client reçoit du site Web une page d'accueil personnalisée. Les éléments constitutifs de ces pages émanent d'un groupe de serveurs WebSphere Application Servers. Les serveurs d'applications contenant une logique métier sensible et liés à des bases de données sécuriséés sont protégés par un pare-feu.

Figure 16. Réseau B2C (phase 3)
Ce graphique représente un exemple de réseau B2C

Solution bancaire B2C

La figure 17 représente une solution de banque en ligne similaire au réseau B2C décrite au Réseau B2C. Toutes les demandes client sont transmises, via le pare-feu, à un Dispatcher séparant le trafic conformément aux règles du protocole Internet. Des demandes HTTP sont transmises à un cluster de serveurs proxy avec mémoire cache jouant le rôle de serveurs de remplacement pour les serveurs Web. Des serveurs de mesure sont associés aux serveurs proxy pour fournir des données d'équilibrage de charge au Dispatcher. Cet ensemble réduit la charge du réseau sur les serveurs Web en plaçant une zone tampon supplémentaire entre eux et l'Internet.

Les demandes HTTPS sont transmises à un réseau sécurisé conçu pour fournir aux clients des informations financières personnelles et permettre les transactions bancaires en ligne. Un cluster de serveurs proxy améliorés assure l'évolutivité du site. Ces serveurs proxy supportent la mise en cache de données Web dynamiques et l'assemblage de fragments de page écrits conformément au protocole ESI (Edge Side Includes). Une carte de chiffrement gère les authentifications SSL, ce qui réduit de façon considérable le traitement requis de l'hôte du serveur proxy et Access Manager (anciennement Policy Director) achemine l'authentification client.

Plusieurs clusters de serveurs d'applications distribuent le traitement de demandes en séparant la logique métier, contenue dans des composants EJB, de la couche présentation, contenue dans des servlets et des fichiers JSP. Chaque cluster est géré par un serveur de session distinct.

Le scénario suivant inclut Load Balancer et Caching Proxy.

IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :

Figure 17. Solution bancaire B2C
Ce graphique représente un exemple de solution bancaire B2C

Réseau de portail Web

La figure 18 représente un réseau de portails Web conçu pour prendre en charge un volume de trafic important tout en fournissant au client un contenu personnalisé. Pour réduire la charge de traitement sur les différents serveurs, aucune partie du réseau n'achemine de trafic SSL. Du fait que le portail ne délivre pas de données sensibles, la sécurité n'est pas essentielle sur ce réseau. Il est important que les bases de données contenant les ID client, les mots de passe et les paramètres soient modérement sécurisées et protégées, mais cette exigence n'influe pas sur les performances du reste du site Web.

Toutes les demandes du client passent au travers d'un pare-feu avant d'être transmises à un Dispatcher qui les achemine vers un cluster de serveurs proxy dont les mémoires cache jouent le rôle de serveurs de remplacement pour les serveurs Web. Des serveurs de mesure sont associés aux serveurs proxy pour fournir des données d'équilibrage de charge au Dispatcher.

Le site Web dynamique véritable est un cluster de serveurs d'applications générant des fragments ESI transmis aux serveurs proxy pour assemblage. Chaque serveur d'applications effectue les opérations de construction du site Web nécessaires avec un niveau de sécurité minimal. Tous les serveurs d'applications sont identiques. Si un serveur d'applications tombe en panne, le serveur de session peut acheminer les demandes aux autres serveurs, ce qui confère une disponibilité élevée au site. Cette configuration permet également une adaptation rapide du site Web en cas de trafic excessif, avec, par exemple, l'hébergement d'un événement spécial par le portail. Il est possible de configurer rapidement des serveurs proxy et des serveurs d'applications supplémentaires sur le site.

Toutes les données statiques, tels que les fichiers graphiques et le texte brut, sont stockées sur des serveurs Web séparés, ce qui permet de les mettre à jour sans risquer d'endommager les serveurs d'applications les plus complexes.

Le scénario suivant inclut Load Balancer et Caching Proxy.

IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :

Figure 18. portail Web
Ce graphique représente un portail Web

Installation des Composants Edge

Cette partie contient les procédures permettant d'installer les Composants Edge.

Elle comporte les chapitres suivants :

Conditions requises pour les Composants Edge

Installation des Composants Edge à l'aide du programme d'installation

Installation de Caching Proxy à l'aide des outils de regroupement du système

Installation de Load Balancer à l'aide des outils de regroupement du système

Conditions requises pour les Composants Edge

Ce rubrique contient un lien vers les conditions matérielles et logicielles requises pour les Composants Edge et les instructions d'utilisation des navigateurs Web avec les formulaires Caching Proxy Configuration et administration et avec l'aide en ligne de Load Balancer.

Configurations matérielle et logicielle requises

Pour les informations sur les configurations matérielle et logicielle requises de la version 6.1 de WebSphere Application Server Edge Components, accédez à la page Web suivante : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.

Installation SDK : le SDK Java 2 s'installe automatiquement avec Load Balancer sur toutes les plateformes.

Utilisation de navigateurs avec les formulaires d'administration et de configuration de Caching Proxy

Configuration minimale requise pour le navigateur

Pour configurer Caching Proxy à l'aide des formulaires de configuration et d'administration, le navigateur doit présenter les caractéristiques suivantes :

Sur les systèmes Linux et UNIX : pour les versions recommandées des navigateurs Mozilla et Firefox, consultez le site Web suivant et suivez les liens d'accès à la page Web du logiciel pris en charge : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.

Sur les systèmes Windows : pour les versions recommandées des navigateurs Internet Explorer, Mozilla et Firefox, consultez le site Web suivant et suivez les liens d'accès à la page Web du logiciel pris en charge : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.

Remarque :
Sur les systèmes PowerPC Linux 64 bits, l'accès aux formulaires Configuration et administration avec le navigateur Mozilla est impossible car aucun SDK n'est disponible pour cette architecture. Sinon, vous pouvez accéder à ces formulaires à partir d'une autre machine dotée d'un navigateur Web pris en charge.

LIMITATION : La barre de défilement vertical gauche des formulaires d'administration risque de ne pas s'afficher dans le navigateur si le nombre d'éléments développés est trop élevé pour apparaître dans la fenêtre du navigateur. Les éléments développés situés à la fin de la liste n'apparaissent pas dans la fenêtre d'affichage du navigateur et sont inaccessibles. Pour corriger cette erreur, limitez le nombre d'éléments développés dans le menu de gauche. Si le nombre d'éléments développés est élevé, réduisez certains éléments jusqu'à ce que les éléments situés à la fin de la liste apparaissent dans la fenêtre du navigateur.

Pour que les formulaires s'affichent correctement, le système d'exploitation qui les affiche (celui sur lequel réside le navigateur) doit intégrer les jeux de caractères appropriés à la langue dans laquelle le formulaire est rédigé. Toutefois, il n'est pas obligatoire que l'interface du navigateur soit dans la même langue que les formulaires.

Par exemple, une version en chinois du serveur proxy s'exécute sur un système Solaris 9. Un navigateur Mozilla dont l'interface est en anglais est chargé sur l'hôte Solaris. Vous pouvez utiliser ce navigateur en local pour éditer les formulaires de configuration et d'administration. Les formulairessont affichés par le navigateur avec le jeu de caractères utilisé par le serveur proxy, en l'occurrence, en chinois. Toutefois, les formulaires peuvent ne pas apparaître correctement si le navigateur et son système d'exploitation sous-jacent ne sont pas configurés correctement pour afficher le jeu de caractères envoyé par le serveur proxy.

Sinon, si un poste de travail Windows prenant en charge le chinois est disponible pour une connexion à distance au serveur proxy, vous pouvez charger une version chinoise du navigateur Netscape sur le poste de travail Windows pour entrer les valeurs dans les formulaires. Cette seconde solution présente l'avantage de conserver pour l'administrateur une cohérence de langue d'interface.

Les jeux de caractères propres aux systèmes d'exploitation affectent grandement l'affichage de diverses langues, en particulier les caractères double octet, dans les navigateurs. Par exemple, un jeu de caractères chinois sous AIX ne s'affiche pas de la même façon qu'un jeu de caractères chinois sur des plateformes Windows. Par conséquent, certaines irrégularités peuvent apparaître dans le texte HTML et les applets Java des formulaires Configuration et administration. Seuls les navigateurs s'exécutant sur les systèmes d'exploitation Windows permettent un affichage correct.

Remarque sur le navigateur Mozilla 1.4 sur S/390 et PowerPC

Le plug-in Java installé avec Mozilla 1.4 doit être mis à jour vers la version 1.4.2 ou suivante pour afficher correctement les formulaires d'administration. Pour mettre à jour le plug-in, procédez comme suit :

  1. Accédez au site http://plugindoc.mozdev.org
  2. Sélectionnez la plateforme dans la section "Documentation".
  3. Suivez les instructions indiquées dans la section "Java Runtime Environment" pour mettre à jour le plug-in.

Utilisation de navigateurs avec l'aide en ligne de Load Balancer

Pour utiliser l'aide en ligne de Load Balancer, votre navigateur doit prendre en charge les éléments suivants :

L'utilisation d'un navigateur qui ne prend pas en charge ces éléments peut entraîner des erreurs de formatage des pages et d'exécution des fonctions.

Installation des Composants Edge à l'aide du programme d'installation

Ce rubrique fournit des instructions d'installation des Composants Edge à l'aide du programme d'installation.

Le SDK Java 2 s'installe automatiquement avec Load Balancer sur toutes les plateformes.

Après l'installation, les scripts du module de Caching Proxy tentent de démarrer le serveur proxy à l'aide de la configuration par défaut. Si le port 80 est en cours d'utilisation, par un autre serveur Web par exemple, le serveur proxy ne pourra pas démarrer.

IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :

Utilisation du programme d'installation pour Windows

Utilisez le programme d'installation pour installer le logiciel Edge Components sur votre système Windows :

  1. Vérifiez que le système Windows respecte les configurations matérielle et logicielle requises (Conditions requises pour les Composants Edge).
  2. Connectez-vous avec un ID utilisateur disposant des privilèges administrateur.
  3. Insérez le CD-ROM du logiciel Edge Components dans l'unité de CD-ROM. Le tableau de bord (LaunchPad) démarre automatiquement.
  4. Cliquez sur l'option de lancement de l'assistant d'installation de WebSphere Application Server - Edge Components. Le programme d'installation démarre automatiquement. Il prépare l'assistant d'installation InstallShield et ouvre l'écran Bienvenue.
    Remarque :
    Si votre machine ne prend pas en charge l'option Autoplay, ou si cette dernière est désactivée, démarrez manuellement le programme d'installation en exécutant le programme setup.exe, situé dans le répertoire supérieur du CD-ROM.
  5. Cliquez sur Suivant pour poursuivre l'installation. La fenêtre Contrat de licence du programme s'affiche.
  6. Lisez le contrat de licence et cliquez sur Oui pour accepter tous ses termes. La fenêtre Sélection des composants s'affiche.

    Si le logiciel Edge Components est déjà installé, l'écran Options de maintenance s'affiche avant l'écran Sélection des composants. Cliquez sur le bouton d'option Modifier puis sur Suivant. La fenêtre Sélection des composants s'affiche.

  7. Sélectionnez les composants à installer.
  8. Pour modifier la sélection des sous-composants à installer pour un composant donné, cliquez sur le nom du composant à sélectionner puis cliquez sur Changer les sous-composants. Une autre fenêtre Sélection des composants s'affiche. Elle contient les sous-composants du composant actif. Utilisez les mêmes procédures pour sélectionner les sous-composants à installer, la langue des composants ainsi que l'emplacement d'installation des composants.
  9. Dans les menus Langue actuelle, sélectionnez une ou plusieurs langues pour l'installation des Composants Edge. Les langues disponibles figurent dans le menu à gauche. Les langues sélectionnées figurent dans le menu à droite.
  10. La fenêtre Sélection des composants permet de vérifier l'emplacement d'installation des Composants Edge. Vous pouvez accepter la valeur par défaut ou indiquer un nouvel emplacement en cliquant sur Changer le dossier.
    Remarque :
    Si vous choisissez un emplacement d'installation autre que celui par défaut, vérifiez que le nom du chemin ne contient pas de blancs. Par exemple, évitez d'utiliser des noms de chemin comme C:\My Files\edgeserver\.
  11. La fenêtre Sélection des composants permet de vérifier que l'emplacement d'installation choisi dispose d'un espace suffisant. Si l'espace est insuffisant, cliquez sur Changer le dossier et indiquez un nouvel emplacement d'installation.
  12. Après avoir sélectionné vos Composants Edge, leur emplacement d'installation et les langues voulues, cliquez sur Suivant. Vérifiez les informations de la fenêtre Confirmation d'installation. Si vous voulez modifier une ou plusieurs options, cliquez sur Précédent pour retourner à l'écran Sélection des composants puis effectuez vos modifications. Une fois que vous avez vérifié vos sélections, cliquez sur Continuer.
  13. Le programme dÆinstallation du logiciel Edge Components commence à installer les Composants Edge, et, si nécessaire, GSK à l'emplacement indiqué.
  14. La fenêtre Installation terminée s'affiche ensuite. Si vous souhaitez lire le fichier Readme des Composants Edge, assurez-vous que la case Oui, afficher le fichier Readme de Edge Components est cochée. Le fichier Readme s'ouvre dans votre navigateur par défaut.
  15. Vérifiez que la case Oui, redémarrer le poste immédiatement est cochée puis cliquez sur Fin. Si vous avez choisi d'afficher le fichier Readme, le poste est redémarré lorsque vous fermez la fenêtre de navigateur qui affiche ce fichier. Sinon, le programme d'installation du logiciel Composants Edge se ferme immédiatement et le poste redémarre. Pour utiliser Edge Components nouvellement installés, commencez par redémarrer votre poste.

Limitation : L'utilisation de la touche de tabulation dans la fenêtre de contrat de licence permet de basculer entre les options J'accepte (...) et Je n'accepte pas (...) . Vous ne pouvez toutefois pas utiliser cette touche pour accéder aux options de navigation Précédent, Suivant ou Annuler. Vous pouvez accéder à celles-ci à l'aide de la combinaison de touches Maj+Tab. En outre, la touche Entrée fonctionne uniquement sur les boutons de navigation, vous devez donc utiliser la barre d'espace pour sélectionner les options J'accepte (...) ou Je n'accepte pas (...).

Utilisation du programme d'installation pour Linux et UNIX

Lors d'une installation à partir du CD, utilisez le programme d'installation pour installer les Composants Edge sur des systèmes Linux et UNIX :

  1. Vérifiez que le serveur respecte les configurations matérielle et logicielle requises indiquées dans Conditions requises pour les Composants Edge.
  2. Connectez-vous en tant que superutilisateur, généralement root.
  3. Insérez le CD-ROM Edge Components dans le lecteur de CD-ROM de la machine. Si nécessaire, montez le CD-ROM.
  4. A partir du répertoire de travail, accédez au répertoire de niveau supérieur du CD-ROM.
  5. Appelez le programme d'installation en entrant la commande suivante :
    # ./install
    La fenêtre Bienvenue s'affiche.
  6. Cliquez sur Suivant pour poursuivre l'installation. La fenêtre Contrat de licence du programme s'affiche.
  7. Lisez le contrat de licence et cliquez sur Oui pour accepter tous ses termes. La fenêtre de sélection des langues s'affiche.
  8. Sélectionnez les langues devant être prises en charge par cette installation des Composants Edge. Cliquez sur Suivant. La fenêtre Sélection des composants s'affiche.
  9. Sélectionnez les composants à installer.
  10. Cliquez sur Suivant. L'écran Confirmation d'installation s'affiche.
  11. Vérifiez les informations de la fenêtre Confirmation d'installation. Si vous voulez modifier une ou plusieurs options, cliquez sur Précédent pour retourner à la fenêtre Sélection des composants puis effectuez vos modifications. Une fois que vous avez vérifié vos sélections, cliquez sur Continuer.

    Le programme d'installation commence à installer les Composants Edge sélectionnés ainsi que les modules requis.

  12. L'écran Récapitulatif des résultats de l'installation s'affiche. Consultez les résultats, puis cliquez sur Fin.

Limitation : L'utilisation de la touche de tabulation dans la fenêtre de contrat de licence permet de basculer entre les options J'accepte (...) et Je n'accepte pas (...) . Vous ne pouvez toutefois pas utiliser cette touche pour accéder aux options de navigation Précédent, Suivant ou Annuler. Vous pouvez accéder à celles-ci à l'aide de la combinaison de touches Maj+Tab. En outre, la touche Entrée fonctionne uniquement sur les boutons de navigation, vous devez donc utiliser la barre d'espace pour sélectionner les options J'accepte (...) ou Je n'accepte pas (...).

On Red Hat Linux 3.0 Update 3 : Lors de l'exécution du programme d'installation du module Edge Components, les boutons ne sont pas opérationnels si le panneau de l'interface utilisateur est agrandi au maximum, puis restauré. Pour résoudre cet incident :

  1. Cliquez sur le bouton X dans le coin supérieur droit de la fenêtre pour fermer le programme d'installation.
  2. Répondez par Oui à la question vous demandant si vous voulez quitter le programme.
  3. Relancez le programme d'installation sans agrandir ni restaurer la taille de la fenêtre.

Sur les systèmes Linux et UNIX : Si le programme de configuration est utilisé pour installer le module Edge Components, le programme de désinstallation de l'interface utilisateur peut servir à le désinstaller. Toutefois, ce programme de désinstallation ne permet pas de désinstaller un module de mise à jour installé à l'aide de commandes natives. Vous devez commencer par désinstaller le module de mise à jour à l'aide des commandes natives (commandes du système d'exploitation) avant de désinstaller des composants à l'aide du programme de désinstallation de l'interface utilisateur.

Pour plus d'informations sur l'utilisation des commandes natives, voirInstallation de Caching Proxy à l'aide des outils de regroupement du système et Installation de Load Balancer à l'aide des outils de regroupement du système.

Installation de Caching Proxy à l'aide des outils de regroupement du système

Ce rubrique fournit des instructions d'installation de Caching Proxy à l'aide des outils d'installation et de gestion de modules système.

Après l'installation, les scripts du module de Caching Proxy tentent de démarrer le serveur proxy à l'aide de la configuration par défaut. Si le port 80 est en cours d'utilisation, par un autre serveur Web par exemple, le serveur proxy ne pourra pas démarrer.

IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :

A l'aide du système d'installation de module de votre système d'exploitation, installez les modules dans l'ordre stipulé dans le tableau 2. La procédure ci-après détaille les étapes à suivre pour remplir cette tâche.

  1. Insérez le CD-ROM du logiciel Edge Components dans l'unité de CD-ROM et montez l'unité, si nécessaire.
  2. Connectez-vous en tant que superutilisateur local root.
    su - root
    
    Mot de passe : mot_de_passe
  3. Accédez au répertoire approprié sur le CD.
    cd point_montage/répertoire_modules/
  4. Installez les modules.

    Sous AIX :

    installp -acXd ./nom_module

    Sous HP-UX :

    swinstall -s source/ nom_module

    Sous Linux :

    rpm -i ./nom_module

    Sous Solaris :

    pkgadd -d ./nom_module
Tableau 2. Composants Caching Proxy
Composant Modules installés (dans l'ordre conseillé)
Caching Proxy
  1. gskit7
  2. icu
  3. admin
  4. msg-cp-lang
  5. cp
documentation des composants Edge

doc-en_US1

Remarques :
  1. La documentation Load Balancer est fournie sous forme de deux modules. Le module doc-en_US inclut toute la documentation des Composants Edge, notamment les documents Load Balancer et les place dans le répertoire ../edge/doc/. Le module documentation associé aux installations Load Balancer (Installation de Load Balancer à l'aide des outils de regroupement du système) installe uniquement les documents Load Balancer et les place dans un sous-répertoire au sein du répertoire ../edge/lb/.
Tableau 3. Noms des fichiers des modules sous AIX, HP-UX et Solaris
Nom du module générique Ensemble de fichiers AIX Jeux de fichiers HP-UX Nom du fichier Solaris
admin wses_admin.rte WSES-ADMIN WSESadmin
cp wses_cp.base WSES-CP WSEScp
doc wses_doc.en_US WSES-DOC-en_US WSESdocen
gskit7 gskkm.rte gsk7bas gsk7bas
icu wses_icu.rte WSES-ICU WSESicu
msg-cp-lang wses_cp.msg.lang1 .base WSES-cpmlang2 WSEScpmlang3
Remarques :
  1. Sous AIX, la variable lang correspond à la variable de remplacement de l'un des codes de langue suivants : en_US, de_CH, de_DE, es_ES, fr_CA, fr_CH, fr_FR, it_CH, it_IT, ja_JP, Ja_JP, ko_KR, pt_BR, zh_CN, ZH_CN, zh_TW, Zh_TW.
  2. Sous HP-UX, la variable lang correspond à la variable de remplacement de l'un des codes de langue suivants : de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, zh_CN, zh_TW. (HP-UX ne prend pas en charge les paramètres régionaux Portuguese Brazilian (pt_BR).)
  3. Sous Solaris, la variable lang correspond à la variable de remplacement de l'un des codes de langue suivants : br, cn, cw, de, en, es, fr, it, ja, kr.
Tableau 4. Noms des fichiers des modules sous Linux
Nom du module générique Nom du fichier Linux
admin WSES_Admin_Runtime-version_édition1.hardw2.rpm
cp WSES_CachingProxy-version_édition1.hardw2.rpm
doc WSES_Doc_en_US-version_édition1.hardw2.rpm
gskit7 gsk7bas.rpm
icu WSES_ICU_Runtime-version_édition1.hardw2.rpm
msg-cp-lang WSES_CachingProxy_msg_lang3-version_édition1.hardw2.rpm
Remarques :
  1. version_édition correspond à la version actuelle, par exemple : 6.1.0-0
  2. La variable matér peut prendre l'une des valeurs suivantes : i686, s390, ppc64.
  3. La variable lang correspond à la variable de remplacement de l'un des codes de langue suivants : de_DE, en_US, es_ES, fr_FR, it_IT, ja_JP, ko_KR, pt_BR, zh_CN, zh_TW.

Le module documentation contient uniquement de l'anglais. Vous trouverez les traductions de la documentation Edge Components sur le site Web suivant : www.ibm.com/software/webservers/appserv/ecinfocenter.html.

Désinstallation de modules Caching Proxy avec les outils système

Pour désinstaller les modules, procédez comme suit :

Sous AIX :

installp -u nom_module

Pour désinstaller tous les modules de Caching Proxy, utilisez la commande suivante :

installp -u wses

Sous HP-UX :

swremove nom_module

Pour rechercher les modules de Caching Proxy installés, utilisez la commande suivante :

swlist | grep WSES

Les modules doivent être supprimés dans l'ordre inverse de leur installation.

Sous Linux :

rpm -e nom_module

Pour rechercher les modules de Caching Proxy installés, utilisez la commande suivante :

rpm -qa |grep -i  wses

Les modules doivent être supprimés dans l'ordre inverse de leur installation.

Sous Solaris :

pkgrm nom_module

Pour rechercher les modules de Caching Proxy installés, utilisez la commande suivante :

pkginfo | grep WSES

Les modules doivent être supprimés dans l'ordre inverse de leur installation.

Installation de Load Balancer à l'aide des outils de regroupement du système

Ce rubrique décrit l'installation de Load Balancer sur des systèmes AIX, HP-UX, Linux et Solaris :

Suivant le type d'installation, les modules du composant Load Balancer listés dans cette section ne sont pas tous fournis.

Si vous effectuez une migration à partir d'une version précédente du composant Load Balancer ou que vous réinstallez un système d'exploitation, vous pouvez sauvegarder les fichiers de configuration ou les fichiers scripts précédents de Load Balancer avant l'installation.

Si vous vous déconnectez d'une machine après l'installation de Load Balancer, vous devrez redémarrer tous les services Load Balancer quand vous vous reconnecterez.

Installation sous AIX

Le tableau 5 répertorie les ensembles de fichiers AIX pour Load Balancer et l'ordre d'installation recommandé à l'aide de l'outil d'installation système des modules.

Tableau 5. Fichiers AIX
Composants Load Balancer Fichiers AIX
Base ibmlb.base.rte
Administration (avec messages)
  • ibmlb.admin.rte
  • ibmlb.msg.lang.admin
Pilote de périphérique ibmlb.lb.driver
Licence ibmlb.lb.license
Composants Load Balancer (avec messages)
  • ibmlb.composant.rte
  • ibmlb.msg.lang.lb
Documentation (avec messages)
  • ibmlb.doc.rte
  • ibmlb.msg.en_US.doc
Metric Server ibmlb.ms.rte
Remarques :
  1. La variable composant peut être remplacée par l'un des composants suivants : disp (dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller) ou nal (Nortel Alteon Controller).
  2. Vous pouvez utiliser l'un des codes de langue suivants pour remplacer la variable lang : en_US, de_CH, de_DE, es_ES, fr_CA, fr_CH, fr_FR, it_CH, it_IT, ja_JP, Ja_JP, ko_KR, pt_BR, zh_CN, ZH_CN, zh_TW, Zh_TW

Le module documentation contient uniquement de l'anglais. Vous trouverez les traductions de la documentation Edge Components sur le site Web suivant : www.ibm.com/software/webservers/appserv/ecinfocenter.html.

Avant de commencer

Avant d'installer Load Balancer pour AIX, vérifiez les points suivants :

Lors de l'installation du produit, vous avez la possibilité d'installer les composants suivants un à un ou en totalité :

Procédure d'installation

Il est recommandé d'utiliser SMIT pour installer Load Balancer for AIX car SMIT garantit que tous les messages sont installés automatiquement.

Utilisation de SMIT pour l'installation de Load Balancer pour AIX

  1. Sélectionnez l'option d'installation et de maintenance du logiciel.
  2. Sélectionnez l'option d'installation et de mise à jour du logiciel.
  3. Sélectionnez l'option d'installation et de mise à jour à partir du dernier logiciel disponible.
  4. Entrez l'unité ou le répertoire contenant les groupes de fichiers.
  5. Dans la zone *LOGICIEL à installer, entrez les informations appropriées pour spécifier des options (ou sélectionnez Liste).
  6. Cliquez sur OK.
  7. Lorsque la commande prend fin, cliquez sur Terminer.
  8. Fermez SMIT en sélectionnant Quitter Smit dans le menu Sortie ou en appuyant sur F12. Si vous utilisez SMITTY, cliquez sur F10 pour fermer le programme.

Installation de Load Balancer à partir de la ligne de commande

  1. Si vous effectuez l'installation à partir d'un CD, entrez les commandes suivantes afin de monter le support :
    mkdir /cdrom
    
    mount -v cdrfs -p -r /dev/cd0 /cdrom
  2. Reportez-vous au tableau suivant pour déterminer quelle(s) commande(s) doit être entrée pour installer les modules de Load Balancer for AIX :
    Tableau 6. Commandes d'installation AIX
    Modules Commandes
    Base installp -acXgd unité ibmlb.base.rte
    Administration (avec messages) installp -acXgd unité ibmlb.admin.rte ibmlb.msg.langue.admin
    Pilote de périphérique installp -acXgd unité ibmlb.lb.driver
    Licence installp -acXgd unité ibmlb.lb.license
    Composants Load Balancer (avec messages). Comporte : Dispatcher, CBR, Site Selector, Cisco CSS Controller et Nortel Alteon Controller

    installp -acXgd unité ibmlb.composant.rte

    ibmlb.msg.langue.lb

    Documents (avec messages) installp -acXgd unité ibmlb.doc.rte ibmlb.msg.en_US.lb
    Metric Server installp -acXgd unité ibmlb.ms.rte
    unité désignant :
  3. Assurez-vous que la colonne résultat du résumé indique SUCCESS pour chaque partie de Load Balancer installée. Arrêtez immédiatement l'installation en cas d'échec de l'installation de l'une des parties.
    Remarque :
    Pour générer une liste de groupes de fichiers d'une unité spécifique, y compris tous les catalogues de messages disponibles, entrez
    installp -ld unité

Si vous effectuez l'installation à partir d'un CD, pour démonter le CD, entrez la commande suivante :

unmount /cdrom

Vérifiez que le produit est installé en entrant la commande suivante

lslpp -h | grep ibmlb

Si vous avez installé le produit en totalité, cette commande retourne le résultat suivant :

ibmlb.base.rte

ibmlb.admin.rte

ibmlb.lb.driver

ibmlb.lb.license

ibmlb.composant.rte

ibmlb.doc.rte

ibmlb.ms.rte

ibmlb.msg.langue.admin

ibmlb.msg.en_US.doc

ibmlb.msg.langue.lb

Les chemins d'installation de Load Balancer sont les suivants :

Installation pour HP-UX

Cette section traite de l'installation de Load Balancer sous HP-UX à l'aide du CD du produit.

Avant de commencer

Avant de commencer la procédure d'installation, vérifiez que vous disposez des droits d'accès root pour l'installation du logiciel.

Si une version antérieure est déjà installée, désinstallez-la avant d'installer la nouvelle version. Vérifiez auparavant que l'exécuteur et le serveur sont arrêtés. Ensuite, pour désinstaller Load Balancer, reportez-vous à la rubrique Instructions de désinstallation des packages.

Procédure d'installation

Le tableau 7 répertorie les noms des packages d'installation de Load Balancer et l'ordre suivant lequel il est recommandé de les installer à l'aide de l'outil d'installation de package du système.

Tableau 7. Détails de l'installation des packages HP-UX pour Load Balancer
Description du package Nom du package HP-UX
Base ibmlb.base
Administration et messages ibmlb.admin ibmlb.nlv-lang
Licence Load Balancer ibmlb.lic
Composants Load Balancer ibmlb.composant
Documentation ibmlb.doc
Metric Server ibmlb.ms
Remarques :
  1. La variable lang correspond à la variable de remplacement de l'un des codes de langue suivants : de_DE, es_ES, fr_FR, it_IT, ja_JP, ko_KR, zh_CN, zh_TW.
  2. La variable composant peut prendre les valeurs suivantes : disp (dispatcher), cbr (CBR), ss (Site Selector), cco (contrôleur Cisco CSS) ou nal (contrôleur Nortel Alteon).
  3. Le module documentation (ibmlb.doc) contient uniquement de l'anglais. Vous trouverez les traductions de la documentation Edge Components sur le site Web suivant : www.ibm.com/software/webservers/appserv/ecinfocenter.html.

HP-UX ne prend pas en charge les paramètres régionaux Portugais Brésil (pt_BR). Les paramètres régionaux pris en charge sous HP-UX sont les suivants :

Instructions d'installation des packages

La procédure ci-après détaille les étapes à suivre pour remplir cette tâche.

  1. Connectez-vous en tant que super utilisateur local root.
    su - root
    
    Mot de passe : mot_de_passe
  2. Exécutez la commande d'installation pour installer les packages

    Exécutez la commande d'installation

    swinstall -s /source nom_package
    source

    correspondant au chemin de répertoire absolu du package et nom_package, au nom du package.

    Par exemple, la commande suivante permet d'installer le package de base de Load Balancer (ibmlb.base), si vous l'installez à partir de la racine du CD :

    swinstall -s /source ibmlb.base

    Pour installer tous les packages pour Load Balancer, lancez la commande suivante, si vous l'installez à partir de la racine du CD :

    swinstall -s /source ibmlb
  3. Vérifiez l'installation des packages de Load Balancer

    Exécutez la commande swlist pour répertorier tous les packages que vous avez installés. Par exemple,

    swlist -l fileset ibmlb
    
    

Instructions de désinstallation des packages

Utilisez la commande swremove pour désinstaller les packages. Les packages doivent être supprimés dans l'ordre inverse de celui de l'installation. Par exemple, exécutez les commandes suivantes :

Les chemins d'installation de Load Balancer sont les suivants :

Installation pour Linux

Cette section traite de l'installation de Load Balancer sous Linux à l'aide du CD Edge Components.

Avant de commencer

Avant d'installer Load Balancer, vérifiez les points suivants :

Procédure d'installation

  1. Insérez le support du logiciel Edge Components ou téléchargez le produit à partir du site Web et installez l'image d'installation à l'aide de RPM (Red Hat Packaging Manager).

    L'image d'installation est un fichier au format lblinux-version.tar.

  2. Décompressez le fichier tar dans un répertoire temporaire en entrant la commande suivante :
    tar -xf lblinux-version.tar
    Les fichiers suivants portant l'extension .rpm sont extraits :

    Où :

    Le module documentation contient uniquement de l'anglais. Vous trouverez les traductions de la documentation Edge Components sur le site Web suivant : www.ibm.com/software/webservers/appserv/ecinfocenter.html.

  3. A partir du répertoire dans lequel résident les fichiers RPM, exécutez la commande permettant d'installer chaque module. Par exemple :
    rpm -i package.rpm

    Systèmes Red Hat Linux : A cause d'un problème Red Hat Linux connu, vous devrez également supprimer les fichiers _db* RPM, sous peine de générer une erreur.

    Il est important d'installer les modules dans l'ordre figurant dans la liste de modules suivante requis pour chaque composant.

    Remarque :
    Java doit être installé et enregistré dans la base RPM pour au moins un module RPM précité. Si Java est installé sans être enregistré dans la base RPM, utilisez la commande d'installation avec l'option no dependencies comme suit :
    rpm -i --nodeps module.rpm 
  4. Vérifiez que le produit est installé. Entrez la commande suivante :
    rpm -qa | grep ibmlb

    L'installation complète du produit génère la sortie suivante :

Les chemins d'installation de Load Balancer sont les suivants :

Si vous devez désinstaller les modules, supprimez-les par ordre chronologique inverse, en veillant à traiter les modules d'administration en dernier.

Installation sous Solaris

Cette section traite de l'installation de Load Balancer sous Solaris à l'aide du CD Edge Components.

Avant de commencer

Avant de commencer la procédure d'installation, assurez-vous que vous êtes connecté en tant que root et que toute version précédente du produit est désinstallée.

Pour effectuer la désinstallation, assurez-vous que tous les modules d'exécution et les serveurs sont arrêtés. Puis, entrez la commande suivante :

pkgrm pkgname

Procédure d'installation

  1. Insérez le CD-ROM contenant le logiciel Load Balancer dans l'unité appropriée.
  2. A l'invite, entrez la commande suivante :
    pkgadd -d chemin
    -d chemin est le nom d'unité du lecteur de CD-ROM ou le répertoire du disque dur sur lequel réside le module ; par exemple : -d /cdrom/cdrom0/.

    Voici la liste des packages affichés et leur ordre d'installation recommandé.

    Le module documentation (ibmlbdoc.doc) contient uniquement de l'anglais. Vous trouverez les traductions de la documentation Edge Components sur le site Web suivant : www.ibm.com/software/webservers/appserv/ecinfocenter.html.

    Pour installer tous les modules, il suffit de taper all, puis appuyez sur Entrée. Pour installer des composants spécifiques, entrez le ou les noms correspondant aux modules à installer, séparés par un espace ou une virgule, puis appuyez sur Entrée. Le cas échéant, vous serez invité à modifier les autorisations sur des répertoires ou des fichiers existants. Appuyez sur Entrée ou tapez yes. Vous devez installer les modules requis (car le programme d'installation propose une liste alphabétique de modules et non la liste des dépendances). Si vous tapez all, puis répondez yes à toutes les invites, l'installation se termine avec succès.

    Pour n'installer que le composant Dispatcher avec la documentation et Metric Server, vous devez installer : ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc et ibmlbms.

  3. Vérifiez que le produit est installé. Exécutez la commande suivante :
    pkginfo | grep ibm

Les chemins d'installation de Load Balancer sont les suivants :

Construction de réseau avec les Composants Edge

La présente partie comporte les procédures permettant de créer différents réseaux de démonstration à l'aide des Composants Edge. Ces réseaux ne sont pas conçus pour être utilisés dans des environnements de production. Le processus de configuration initiale d'un réseau permet aux administrateurs ne connaissant pas bien ce produit de mieux comprendre un grand nombre de concepts. Pour obtenir une présentation complète des fonctions de tous les composants ainsi que des informations de configuration détaillées, reportez-vous aux documents Caching Proxy - Guide d'administration et Load Balancer - Guide d'administration.

Les procédures permettent à n'importe quel ordinateur pris en charge par le composant d'être utilisé dans n'importe quel noeud.

Elle comporte les chapitres suivants :

Construction d'un réseau Caching Proxy.

Construction d'un réseau Load Balancer.

Construction d'un réseau Caching Proxy

La figure 19 montre un réseau de serveur proxy de base utilisant trois systèmes informatiques situés sur trois noeuds de réseau. Ce réseau lie le serveur proxy à un hôte de données dédié (IBM HTTP Server), qui se trouve sur le serveur 2, le serveur proxy fournit des informations à l'hôte. Sur la figure, le réseau Internet se trouve maintenant entre le poste de travail et le serveur 1.

IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :

Figure 19. Réseau de démonstration de Caching Proxy
Réseau de démonstration de Caching Proxy

Flux de travail

Pour construire un réseau de Caching Proxy, suivez les procédures dans l'ordre indiqué :

  1. Logiciels et systèmes requis.
  2. Création du serveur 1 (systèmes Linux et UNIX) ou Création du serveur 1 (système Windows).
  3. Configuration du serveur 1.
  4. Test du réseau de Caching Proxy.

Logiciels et systèmes requis

Les systèmes et logiciels suivants sont requis :

Création du serveur 1 (systèmes Linux et UNIX)

Installez et configurez Caching Proxy comme suit :

  1. Vérifiez que le système serveur dispose des configurations matérielle et logicielle requises.
  2. Connectez-vous en tant que superutilisateur, généralement root.
  3. Installez le composant Caching Proxy.
  4. A l'aide de la commande suivante, créez un ID et un mot de passe administrateur permettant d'accéder aux formulaires Configuration et administration.
    # htadm -adduser /opt/ibm/edge/cp/server_root/protect/webadmin.passwd

    A l'invite du système, indiquez pour le programme htadm le nom d'utilisateur, le mot de passe et le nom réel de l'administrateur.

  5. Poursuivez par la section Configuration du serveur 1.

Création du serveur 1 (système Windows)

Installez et configurez le Caching Proxy comme suit :

  1. Vérifiez que les systèmes d'exploitation Windows 2000 et Windows 2003 respectent les configurations matérielle et logicielle requises.
  2. Connectez-vous avec un ID utilisateur disposant des privilèges administrateur.
  3. Installez le composant Caching Proxy.
  4. A l'aide de la commande suivante, créez un ID et un mot de passe administrateur permettant d'accéder aux formulaires Configuration et administration.
    cd "Program Files\IBM\edge\cp\server_root\protect"
    
    htadm -adduser webadmin.passwd"

    A l'invite du système, indiquez pour le programme htadm le nom d'utilisateur, le mot de passe et le nom réel de l'administrateur.

  5. Poursuivez par la section Configuration du serveur 1.

Configuration du serveur 1

A partir du poste de travail, procédez aux opérations ci-dessous.

  1. Démarrez un navigateur Web.
  2. Dans la zone Adresse de votre navigateur, entrez http://serveur_1, où serveur_1 correspond au nom réel de l'hôte ou à l'adresse IP de la machine désignée comme le serveur 1.
  3. Cliquez sur Formulaires Configuration et administration.
  4. Entrez votre nom d'administrateur et votre mot de passe. Les formulaires Configuration et administration s'ouvrent dans votre navigateur.
  5. Cliquez sur Configuration du serveur-->Traitement des demandes-->Acheminement des demandes.
  6. Insérez une nouvelle règle de mappage à caractères génériques avant la règle existante en sélectionnant Insérer avant et la valeur d'index de la règle de mappage à caractères génériques.
  7. Dans la liste déroulante Action, sélectionnez Proxy.
  8. Entrez /* dans la zone de modèle de demande d'URL.
  9. Tapez le nom d'hôte du site vers lequel vous souhaitez rediriger les demandes HTTP dans la zone d'adresse IP du serveur ou nom d'hôte. Faites commencer cette valeur par http://.
  10. Cliquez sur Valider.
  11. Créez une règle de mappage permettant l'accès aux formulaires Configuration et administration en sélectionnant Insérer avant et la valeur d'index de la règle de mappage créée à l'étape 6.
  12. Sélectionnez Pass dans la liste déroulante Action.
  13. Entrez /pub/* dans la zone de modèle de demande d'URL.
  14. Entrez l'emplacement des formulaires Configuration et administration.
  15. Cliquez sur Valider.
  16. Cliquez sur l'icône de redémarrage du serveur située dans la partie supérieure du formulaire de configuration.
  17. Poursuivez par la section Test du réseau de Caching Proxy.

Test du réseau de Caching Proxy

A partir du poste de travail, procédez aux opérations ci-dessous.

  1. Démarrez un navigateur Web.
  2. Saisissez http://serveur_1 dans la zone Adresse de votre navigateur. Les pages HTML provenant du serveur 2 seront acheminées via le serveur 1 et distribuées au navigateur Web.
  3. Pour accéder aux formulaires Configuration et administration, saisissez http://serveur_1 /pub/ dans la zone Adresse de votre navigateur. La page d'accueil des formulaires Configuration et administration s'affiche.

Construction d'un réseau Load Balancer

La figure 20 représente un réseau Load Balancer de base comportant trois postes de travail connectés localement à l'aide de la méthode de transfert MAC du composant Dispatcher afin d'équilibrer le trafic Web entre deux serveurs Web. La configuration est similaire dans le cadre de l'équilibrage de charge de trafic TCP ou de trafic d'application UDP sans état.

Figure 20. réseau de démonstration Load Balancer
Graphique représentant un client, Internet, une machine Load Balancer et deux serveurs connectés localement possédant des adresses.
Remarque :
Cette configuration peut être réalisée avec seulement deux postes de travail, Dispatcher étant installé sur l'un d'eux, doté du serveur Web. Ceci représente une configuration cooccurrente.

Flux de travail

Pour construire un réseau de Load Balancer, suivez les procédures dans l'ordre indiqué :

  1. Révision des matériels et logiciels requis.
  2. Configuration du réseau.
  3. Configuration de Dispatcher.
  4. Test du réseau Load Balancer.

Révision des matériels et logiciels requis

Les systèmes et logiciels suivants sont requis :

Configuration du réseau

  1. Configurez les postes de travail pour qu'ils se trouvent sur le même segment de réseau local. Assurez-vous que le trafic réseau entre les trois machines ne passe pas par aucun routeur ou passerelle.
  2. Configurez les cartes réseau des trois postes de travail. Pour cet exemple, supposons que vous ayez la configuration réseau suivante :
    Poste de travail Nom Adresse IP
    1 serveur1.entreprise.com 9.67.67.101
    2 serveur2.entreprise.com 9.67.67.102
    3 serveur3.entreprise.com 9.67.67.103
    Masque de réseau = 255.255.255.0
    Chaque poste de travail ne contient qu'une carte d'interface réseau Ethernet standard.
  3. Assurez-vous que serveur1.entreprise.com peut communiquer avec serveur2.entreprise.com et serveur3.entreprise.com.
  4. Assurez-vous que serveur2.entreprise.com et serveur3.entreprise.com peuvent communiquer avec serveur1.entreprise.com.
  5. Assurez-vous que le contenu est identique sur les deux serveurs Web (Serveur 2 et Serveur 3). Au besoin, dupliquez les données sur les postes de travail, en utilisant un système de fichiers partagé tel que NFS, AFS ou DFS, ou tout autre moyen adapté à votre site.
  6. Assurez-vous que les serveurs Web de serveur2.entreprise.com et serveur3.entreprise.com sont opérationnels. Utilisez un navigateur Web pour demander des pages directement à partir de http://serveur2.entreprise.com et http://serveur3.entreprise.com.
  7. Extrayez une autre adresse IP valide pour ce segment de réseau local. Il s'agit de l'adresse que vous fournissez aux clients souhaitant accéder à votre site. Dans notre exemple, les informations sont les suivantes :
    Nom= www.entreprise.com
    
    IP=9.67.67.104  
  8. Configurez les deux postes de travail serveurs Web pour qu'ils acceptent du trafic destiné à www.entreprise.com.

    Ajoutez un alias pour www.entreprise.com à l'interface de bouclage sur serveur2.entreprise.com et serveur3.entreprise.com.

  9. Supprimez les autres routes susceptibles d'avoir été créées en tant qu'alias de l'interface de bouclage.

    La procédure de configuration des deux postes de travail agissant en tant que serveurs Web est à présent terminée.

Configuration de Dispatcher

Dispatcher permet de créer une configuration en utilisant la ligne de commande, l'assistant de configuration ou l'interface graphique utilisateur.

Remarque :
Les valeurs de paramètres doivent figurer en caractères anglais (donc sans accent, ni cédille). Les seules exceptions sont les valeurs de paramètres des noms d'hôte et des noms de fichier.

Configuration à partir de la ligne de commande

Si vous utilisez la ligne de commande, procédez comme suit :

  1. Démarrez dsserver sur Dispatcher :

  2. Démarrez la fonction d'exécution de Dispatcher :
    dscontrol executor start
  3. Ajoutez l'adresse de cluster à la configuration de Dispatcher :
    dscontrol cluster add www.entreprise.com
  4. Ajoutez le port du protocole http à la configuration de Dispatcher :
    dscontrol port add www.entreprise.com:80
  5. Ajoutez chaque serveur Web à la configuration de Dispatcher :
    dscontrol server add www.entreprise.com:80:serveur2.entreprise.com
    dscontrol server add  www.entreprise.com:80:server3.entreprise.com
  6. Configurez le poste de travail de sorte qu'il accepte le trafic pour l'adresse de cluster :
    dscontrol executor configure www.entreprise.com
  7. Démarrez la fonction gestionnaire de Dispatcher :
    dscontrol manager start

    Dispatcher charge à présent l'équilibrage de charge basé sur les performances serveur.

  8. Démarrez la fonction conseiller de Dispatcher :
    dscontrol advisor start http 80

    Dispatcher vérifie à présent que les demandes du client ne sont pas envoyées à un serveur Web inadéquat.

La configuration de base des serveurs connectés localement est à présent terminée.

IMPORTANT : Avec l'installation de Load Balancer pour IPv4 et IPv6, la syntaxe de la commande Dispatcher (dscontrol) est identique, avec une exception importante. Le délimiteur des commandes dscontrol est un symbole at ( @) et non le signe deux-points (:). (Il était nécessaire de définir un délimiteur qui ne soit pas le signe deux-points car le format IPv6 utilise ce signe de ponctuation dans son schéma d'adressage.)

Exemple (provenant d'un exemple de configuration précédent de Dispatcher)

Pour plus d'informations, si vous utilisez une installation Load Balancer pour IPv4 et IPv6, consultez le chapitre sur le déploiement de Dispatcher sur Load Balancer pour IPv4 et IPv6, qui contient des informations sur les limitations et les différences de configuration, dans le document WebSphere Application Server Load Balancer - Guide d'administration.

Configuration à l'aide de l'assistant de configuration

Si vous utilisez l'assistant de configuration, procédez comme suit :

  1. Démarrez dsserver sur Dispatcher :

  2. Démarrez la fonction assistant de Dispatcher, dswizard.

L'assistant vous guide pas à pas dans le processus de création d'une configuration de base du composant Dispatcher. Il vous pose des questions sur le réseau pour vous guider dans la configuration d'un cluster pour le composant Dispatcher et l'activation de l'équilibrage de charge du trafic d'un groupe de serveurs.

L'assistant de configuration comporte les panneaux suivants :

Configuration à l'aide de l'interface graphique utilisateur (GUI)

Pour démarrer l'interface graphique utilisateur, procédez comme suit :

  1. Assurez-vous le processus dsserver est actif :
  2. Effectuez ensuite l'une des opérations suivantes :

Test du réseau Load Balancer

  1. Dans un navigateur Web, tapez http://www.entreprise.com pour vérifier qu'une page apparaît.
  2. Rechargez la page dans le navigateur Web.
  3. Exécutez la commande suivante : dscontrol server report www.company.com:80:. Vérifiez que la colonne du nombre total de connexions des deux serveurs indique 2.

Annexes