Version 7.0
Document Number GC31-6918-00
Première édition - aout 2008
Cette édition s'applique à :
ainsi qu'à toutes les éditions et mises à jour ultérieures jusqu'à mention contraire dans les nouvelles éditions.
D'autres publications sont disponibles auprès de votre interlocuteur IBM ou de l'agence commerciale IBM de votre localité.
(C) Copyright International Business Machines Corporation 2008. All rights reserved.
Concepts et discussions liés à Edge Components
Installation de Edge Components
Mise à jour du logiciel Edge Components
Création de réseaux avec Edge Components
Le présent document, WebSphere Application Server - Concepts, planification et installation pour Edge Components, est une introduction au logiciel 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 Edge Components, des informations sur l'installation et la configuration initiale, des réseaux de démonstration.
Le document 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 leurs systèmes d'exploitation et les services Internet. La connaissance préalable de WebSphere Application Server ou de WebSphere Application Server Edge Components n'est pas indispensable.
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 WebSphere Application Server, version 7.0 sont les suivantes :
Ce document utilise les conventions et règles typographiques décrites ci-après.
Tableau 1. Conventions utilisées dans ce guide
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 | Où 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. |
Retourne | Fait référence à la touche libellée Retour ou Entrée, ou à la flèche vers la gauche. |
% | Représente l'invite de commande du shell Linux et UNIX d'une commande qui ne nécessite pas les droits d'accès root. |
# | Représente l'invite de commande 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 à partir de l'invite de commande, puis 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. |
La présente partie décrit les composants du produit WebSphere Application Server Edge Components, à savoir Caching Proxy et Load Balancer, et explique leur intégration à WebSphere 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 :
WebSphere est un logiciel d'infrastructure Internet permettant aux entreprises de développer, de déployer et d'intégrer des applications e-business, telles que des applications B2B. Le produit middleware WebSphere prend en charge des applications d'entreprise de la publication Web simple aux traitements de transactions d'entreprise.
Clé de voûte de la plateforme WebSphere, WebSphere Application Server offre un jeu complet de logiciels middleware permettant de concevoir, de mettre en oeuvre, de déployer et de gérer des applications d'entreprise. Ces applications peuvent aller du site de ventes simple à la 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.
Le logiciel Edge Components (anciennement appelé Edge Server) est désormais intégré à l'offre WebSphere Application Server. Il peut être utilisé avec WebSphere Application Server pour contrôler les accès des clients aux serveurs Web et permettre aux entreprises d'offrir un meilleur service aux utilisateurs qui accèdent aux données Web via Internet ou un réseau intranet d'entreprise. L'utilisation du logiciel Edge Components 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. Comme son nom l'indique, Edge Components 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 comprend les composants Caching Proxy et Load Balancer du logiciel Edge Components.
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. Il peut placer en mémoire cache et transmettre 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, qui fournit un point de présence pour un réseau ou un serveur de réseau interne dans le but d'améliorer les temps de demande et de réponse. Pour plus d'informations sur les configurations des serveurs inversés et des serveurs d'acheminement, voir Configurations de base de Caching Proxy.
Le serveur proxy intercepte les demandes de données provenant d'un client, extrait les informations demandées sur les hôtes de données et les transmet 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 pour 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 transmettre 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 traiter 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 opérationnelle sur n'importe quelle plateforme. 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 crée des systèmes aux abords du réseau pour gérer le flux du trafic réseau, réduisant la surcharge et équilibrant la charge sur divers autres services et systèmes. Il 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 d'arrière-plan de l'entreprise qui peuvent être des hôtes de données ou des systèmes Caching Proxy. Load Balancer assure la fonction de point de présence unique de l'entreprise sur Internet, même si cette dernière utilise plusieurs serveurs d'arrière-plan en raison d'une forte demande ou de données volumineuses. Vous pouvez également garantir une haute disponibilité en installant un composant Load Balancer de secours chargé de prendre le relais en cas de panne temporaire du composant principal.
Le composant Load Balancer intercepte les demandes de données provenant des clients et les transmet au serveur qui est 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. Load Balancer peut répartir les demandes entre différents types de serveur, y compris les serveurs WebSphere Application Server et les systèmes 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 évite le stockage de données identiques sur tous les serveurs d'arrière-plan. 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.
Load Balancer comprend les composants suivants :
Pour tous les services Internet, tels que HTTP, FTP, HTTPS et Telnet, le composant Dispatcher assure l'équilibrage de la charge des serveurs sur un réseau local (LAN) ou un réseau étendu (WAN). Pour les services HTTP, Dispatcher assure l'équilibrage de la charge des serveurs en fonction 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.
Pour les services HTTP et HTTPS, ce composant réalise l'équilibrage de la charge des serveurs en fonction du contenu de la demande du client. Le composant CBR fonctionne avec le composant Caching Proxy de WebSphere Application Server.
IMPORTANT : Le composant CBR est disponible sur toutes les plateformes prises en charge, sauf dans les cas suivants :
Pour ce type d'installation, vous pouvez utiliser la méthode d'acheminement CBR du composant Dispatcher de Load Balancer pour assurer un acheminement basé sur le contenu des demandes HTTP et HTTPS sans utiliser Caching Proxy. Pour plus d'informations, reportez-vous au document WebSphere Application Server Load Balancer - Guide d'administration.
Load Balancer for IPv4 and IPv6 prend uniquement en charge la méthode d'acheminement MAC du composant Dispatcher. Les méthodes d'acheminement NAT et CBR ne sont pas prises en charge.
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 Edge Components, sauf dans le cas suivant :
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 Edge Components, sauf dans le cas suivant :
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 Edge Components, sauf dans le cas suivant :
Ce composant Metric Server s'exécute en tant que démon sur un serveur dont la charge est équilibrée et fournit des informations sur les charges système aux composants Load Balancer.
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, avec Edge Components, et d'autres logiciels de la famille WebSphere parfaitement intégrés à WebSphere Application Server, pour améliorer ses performances. Pour consulter une présentation de WebSphere Application Server et de ses composants, voir Introduction à WebSphere Application Server Edge Components.
Tivoli Access Manager (anciennement appelé 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 tire parti de l'infrastructure de sécurité d'Access Manager pour permettre au serveur proxy d'utiliser les services d'autorisation ou d'authentification intégrés d'Access Manager.
WebSphere Portal Server (disponible séparément) propose une infrastructure 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 portail personnalisé répondant aux besoins des employés, des partenaires commerciaux et des clients. Une fois connectés au portail, les utilisateurs reçoivent des pages Web personnalisées qui fournissent 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 WebSphere Application Server peut également être utilisé pour assurer l'équilibrage de charge et une disponibilité élevée.
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 Edge Components, gérer et stocker des configurations, exécuter Edge Components à distance, afficher et consigner des événements.
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 optimise les fonctionnalités de Caching Proxy en lui permettant d'utiliser 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 pour obtenir les 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.
La documentation suivante s'applique à WebSphere Application Server Edge Components et est disponible dans le centre de documentation du logiciel Edge Components.
Les autres documentations de WebSphere Application Server sont disponibles dans la page de la bibliothèque de WebSphere Application Server.
Des informations techniques sur le logiciel Edge Components sont disponibles dans la page de support de WebSphere Application Server.
Les sites Web sur lesquels vous pouvez obtenir des informations relatives à Edge Components ou connexes sont les suivants :
La présente partie contient des présentations détaillées mettant en relief quelques fonctionnalités offertes par Edge Components. Pour obtenir une présentation du composant Caching Proxy de WebSphere Application Server, voir Introduction à WebSphere Application Server Edge Components.
Elle comporte les chapitres suivants :
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 à l'utilisateur final. En effet, les opérations de mise en cache réalisées par le serveur proxy allège la charge des serveurs d'arrière-plan et les liaisons de connexion. Caching Proxy peut placer en mémoire 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 fonctionne avec le composant Load Balancer de WebSphere Application Server. Pour obtenir une présentation de ces systèmes, voir Introduction à WebSphere Application Server Edge Components.
IMPORTANT : Caching Proxy est disponible dans toutes les installations Edge Components, sauf dans les cas suivants :
Il est possible de configurer Caching Proxy comme un serveur proxy inversé Caching Proxy (configuration par défaut) ou comme un serveur proxy d'acheminement Caching Proxy. Lorsqu'il est utilisé par des hôtes de données, Caching Proxy est configuré comme un serveur inversé Caching Proxy, placé entre Internet et les hôtes de données des entreprises. Lorsqu'il est utilisé par des fournisseurs d'accès à Internet, Caching Proxy est configuré comme serveur proxy d'acheminement, placé entre un client et Internet.
Dans une configuration avec un serveur proxy inversé, les systèmes Caching Proxy sont situés 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 envoie ces données aux utilisateurs via Internet. La mise en mémoire cache permet à Caching Proxy de traiter 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 décrit cette fonction de base de Caching Proxy.
Figure 1. Caching Proxy fonctionnant comme un serveur proxy inversé
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 passe par Internet (2) et pénètre dans 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 est susceptible d'être mis en cache, Caching Proxy 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 de manière dynamique par WebSphere Application Server.
Fournir un accès direct à Internet à l'utilisateur final 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 système d'acheminement Caching Proxy près de la passerelle.
Dans une configuration avec un serveur proxy d'acheminement, les systèmes Caching Proxy sont situés entre le client et Internet. Caching Proxy achemine la demande d'un client vers les hôtes de données situés sur Internet, met en cache les données extraites et les transmet au client.
Figure 2. Caching Proxy fonctionnant comme un serveur proxy d'acheminement
La Figure 2 présente la configuration d'un système d'acheminement Caching Proxy. Les programmes du navigateur des clients (sur les systèmes 1) sont configurés pour adresser les demandes au serveur d'acheminement Caching Proxy (2), qui est configuré pour intercepter les demandes. Lorsqu'un utilisateur final demande le fichier X stocké sur l'hôte de données (6), le serveur d'acheminement Caching Proxy intercepte la demande, en génère une nouvelle avec sa propre adresse IP comme adresse d'origine et renvoie la nouvelle demande au moyen du routeur de l'entreprise (4) via Internet (5).
Le serveur d'origine renvoie ainsi le fichier X au serveur d'acheminement Caching Proxy et non directement à l'utilisateur final. Si la fonctionnalité de mise en cache du serveur d'acheminement Caching Proxy est activée, Caching Proxy détermine si le fichier X est susceptible d'être mis 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 serveur d'acheminement Caching Proxy 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 serveur d'acheminement Caching Proxy 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 serveur proxy Caching Proxy 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 serveur d'acheminement Caching Proxy présente un intérêt lorsque d'autres utilisateurs demandent par la suite le fichier X. Le serveur d'acheminement Caching Proxy vérifie la validité de sa copie cachée du fichier X (pas d'expiration) et extrait fichier X directement du 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 serveur d'acheminement Caching Proxy ne doit pas nécessairement retourner extraire le fichier de 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 serveur proxy peut encore fournir la version cachée à l'utilisateur de qui émane la demande.
Dans ce type de configuration, on parle de serveur proxy d'acheminement car le serveur proxy agit pour le compte des navigateurs, acheminant leurs demandes vers les hôtes de données via Internet. Les avantages de cette configuration 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.
Une variante d'un système d'acheminement Caching Proxy est un système Caching Proxy transparent. A ce titre, Caching Proxy exécute la même fonction qu'un système d'acheminement Caching Proxy de base, mais sans que le client soit conscient de sa présence. Cette configuration transparente de Caching Proxy n'est prise en charge que sur les systèmes Linux.
Dans la configuration décrite à la section Serveur d'acheminement Caching Proxy, chaque navigateur client est configuré séparément pour acheminer les demandes vers un système d'acheminement Caching Proxy spécifique. Gérer une telle configuration peut se révéler difficile, notamment lorsque les systèmes client sont très nombreux. Caching Proxy prend en charge plusieurs solutions alternatives simplifiant l'administration. Une solution consiste à configurer le système Caching Proxy en tant que serveur proxy transparent, comme indiqué à la Figure 3. Comme dans le cas d'un serveur proxy d'acheminement classique, le serveur proxy transparent est installé sur un système près de la passerelle, mais les programmes du navigateur client ne sont pas configurés pour acheminer les demandes vers un système d'acheminement Caching Proxy. La présence d'un serveur proxy dans la configuration n'est pas détectée par les clients. Un routeur est configuré pour intercepter les demandes du client et les diriger vers le système Caching Proxy transparent. Lorsqu'un client utilisant l'un des systèmes 1 demande le fichier X stocké sur un hôte de données (6), le routeur (2) transmet la demande au système Caching Proxy. Caching Proxy génère une nouvelle demande avec sa propre adresse IP comme adresse d'origine et renvoie la nouvelle demande au moyen du routeur (2) via Internet (5). Lorsque le fichier X arrive, Caching Proxy le met en cache (en fonction des conditions décrites à la section Serveur d'acheminement Caching Proxy) et le transmet au client demandeur.
Figure 3. Caching Proxy fonctionnant comme un serveur proxy d'acheminement transparent
Pour les demandes 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 demandes Web. Dans ce cas, il est inutile de conserver des fichiers de configuration de proxy au niveau central. Caching Proxy est compatible avec WPAD.
Pour fournir des fonctionnalités de mise en 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 explique comment associer Caching Proxy à Load Balancer pour transmettre des données Web efficacement, même en cas de fortes demandes. 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) .
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 mieux à même de traiter 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 transmet à l'utilisateur, comme décrit précédemment.
Les fonctionnalités de mise en cache avancée sont également fournies 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 transmettre et d'invalider des données dynamiques, telles que des pages 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 WebSphere Application Server est partagée entre les deux systèmes. Par exemple, une page Web publique créée dynamiquement par une application qui fournit des prévisions météorologiques peut être exportée par WebSphere Application Server et mise en cache par Caching Proxy. Caching Proxy peut ensuite transmettre 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 demandant de supprimer les données de son cache. Les messages Invalidate émanent du système WebSphere Application Server propriétaire des données et sont envoyés à chaque système Caching Proxy configuré.
Caching Proxy offre d'autres fonctions de mise en cache importantes :
Les performances réseau sont optimisées par l'introduction des fonctionnalités de Caching Proxy. Caching Proxy peut être utilisé seul ou avec Load Balancer afin d'améliorer les performances du réseau. Pour obtenir une présentation de ces systèmes, voir Introduction à WebSphere Application Server Edge Components.
Les performances de Caching Proxy sont aussi importantes que la configuration matérielle sur laquelle le logiciel est installé et que l'architecture globale à laquelle le système est intégré. Pour optimiser les performances réseau, adaptez la configuration matérielle et l'architecture réseau globale aux caractéristiques des serveurs proxy.
La configuration et l'administration de base du logiciel Caching Proxy et 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 notamment des instructions 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 d'unités d'exécution actives. La configuration du logiciel Caching Proxy est présenté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 dans toutes les installations Edge Components, sauf dans les cas suivants :
La présente section contient les éléments de configuration matérielle à prendre en compte pour intégrer les fonctionnalités Caching Proxy à votre réseau.
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.
Il est important de disposer d'une quantité d'espace disque importante sur le système 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.
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 ont une incidence directe sur les performances de Caching Proxy. Pour obtenir 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 le trafic des demandes et des réponses 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.
L'unité centrale de traitement (UC) d'un système 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 d'adapter les ressources processeur du serveur proxy en fonction de l'environnement pour gérer la charge maximale de demandes que le serveur proxy doit traiter.
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 présente section contient les éléments de l'architecture réseau à prendre en compte lors de l'intégration des fonctionnalités Caching Proxy à votre réseau.
Si le site Web de votre entreprise est très consulté, la demande de contenu peut dépasser les capacités de traitement d'un serveur proxy unique et éventuellement allonger les temps de réponse. Pour optimiser les performances réseau, vous pouvez ajouter des clusters de systèmes Caching Proxy à équilibrage de charge ou utiliser une architecture de cache partagée avec RCA (Remote Cache Access) dans votre architecture réseau globale.
Une façon de faire évoluer l'architecture est de créer des clusters de serveurs proxy et d'utiliser le composant Load Balancer afin de répartir la charge entre eux. La création de clusters de serveurs proxy est une conception qui présente de nombreux avantages non seulement pour les performances et l'évolutivité mais aussi pour la redondance et la fiabilité. L'utilisation d'un seul serveur proxy présente également l'inconvénient de constituer un point de défaillance unique. Si le serveur proxy tombe en panne ou devient inaccessible en raison d'un incident sur le réseau, les utilisateurs ne peuvent plus accéder à votre site Web.
RCA permet de bénéficier d'une architecture de cache partagé. Une architecture de cache partagé répartit la mémoire cache virtuelle totale entre plusieurs serveurs Caching Proxy utilisant un protocole d'intercache, tel que le protocole ICP (Internet Cache Protocol) ou le protocole CARP (Cache Array Routing Protocol). RCA est conçu pour optimiser les ratios d'occurrences de cache en cluster en fournissant un cache virtuel de grande taille.
Une architecture RCA de serveurs proxy est plus performante qu'un système Caching Proxy autonome ou qu'un cluster de systèmes autonomes. Les meilleures performances sont dues à l'augmentation de la taille totale du cache virtuel, qui optimise le ratio d'occurrences du cache et réduit au minimum le manque d'homogénéité et la latence du cache. Avec RCA, un seul exemplaire d'un document particulier réside dans le cache. Avec un cluster de serveurs proxy, la taille totale du cache est accrue mais plusieurs serveurs proxy permettent d'extraire et placer en mémoire cache les mêmes informations. Le ratio d'occurrences de cache total n'est donc pas plus élevé.
RCA est généralement utilisé dans des scénarios d'hébergement de données d'entreprise de grande envergure. Toutefois, RCA n'est pas limité à ce type de déploiement. Vous pouvez envisager d'utiliser RCA si la charge de votre réseau requiert un cluster de serveurs de cache et si la plupart des demandes portent sur des données résidant en mémoire cache. Selon la configuration de votre réseau, RCA n'améliore pas toujours les performances en raison de l'augmentation du nombre de connexions TCP utilisées par le client lorsque RCA est utilisé. En effet, non seulement un membre RCA doit traiter les URL les plus demandées mais il doit également acheminer les demandes à d'autres membres ou clusters s'il reçoit une demande d'une URL qui ne fait pas partie des plus demandées. Ceci signifie qu'un membre d'un tableau RCA peut avoir plus de connexions TCP ouvertes que s'il fonctionnait comme serveur autonome.
L'amélioration des performances est en grande partie due aux fonctions de mise en 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 à traiter ou à transmettre à 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 des paramètres 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 peut entraîner une amélioration des performances.
Les caches disque sont bien adaptés aux grandes quantités de données à placer en mémoire cache. Par exemple, si le contenu du site est important (d'une taille supérieure à 5 Go) avec un taux de correspondance de 80 à 90 %, un cache disque est recommandé. Pourtant, du fait de sa vitesse plus élevée, un cache RAM peut être utilisé sur certains sites de grande taille. Par exemple, la quantité de données extraites du cache de Caching Proxy n'est pas aussi élevée ou si une configuration de cache partagé est appliquée, un cache mémoire est approprié.
Caching Proxy peut mettre en cache et invalider des données dynamiques (résultant de JSP et de servlets) générées par le cache dynamique de WebSphere Application Server, fournissant une extension virtuelle du cache WebSphere Application Server dans les caches réseau. L'activation de la fonction de cache des données générées en dynamique améliore les performances réseau dans un environnement comptant de nombreuses demandes de pages Web publiques 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. La durée de vie de la page est finie mais un déclencheur d'expiration peut être défini au moment de sa création ; En conséquence, les hôtes sans fonction de cache dynamique et d'invalidation doivent régler la valeur TTL des pages sur zéro.
Si une page générée en dynamique est appelée plusieurs fois par un ou plusieurs utilisateurs, le cache dynamique allège la charge du réseau et réduit la charge de travail des hôtes de données. L'utilisation du cache dynamique améliore également les performances réseau en fournissant des temps de réponse aux utilisateurs, car elle supprime les attentes et réduit l'utilisation de la bande passante en raison d'un nombre plus faible de noeuds Internet.
Fonctionnant avec des hôtes de données, comme WebSphere Application Server, ou avec le composant Application Server Caching Proxy, le composant WebSphere Application Server Load Balancer permet d'augmenter la disponibilité et l'évolutivité de votre réseau. (Pour obtenir une présentation des composants du produit Edge Components, voir Introduction à WebSphere Application Server Edge Components.) Utilisé par les réseaux d'entreprise, Load Balancer est installé entre Internet et les serveurs d'arrière-plan. Load Balancer assure la fonction de point de présence unique de l'entreprise sur Internet, même si cette dernière utilise plusieurs serveurs d'arrière-plan en raison d'une forte demande ou de données volumineuses.
La disponibilité est assurée par l'équilibrage de charge et le support de reprise sur incident.
IMPORTANT : Caching Proxy est disponible dans toutes les installations Edge Components, sauf dans les cas suivants :
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.
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 complexe qui équilibre la charge de plusieurs hôtes de données repose sur l'utilisation du composant Dispatcher de Load Balancer, comme indiqué à la Figure 5. Dans cette configuration, tous les hôtes de données (systèmes 5) stockent les mêmes données. Ils sont définis de manière à former un cluster à équilibrage de charge et l'une des interfaces réseau du système (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 systèmes 1 demande le fichier X, la demande passe par 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 correspondant. Le composant Dispatcher détermine quel est l'hôte du cluster le mieux à même de traiter 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 passe donc pas par Load Balancer).
Figure 5. Equilibrage de la charge de plusieurs hôtes de données
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 intègrent 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.
Le composant Dispatcher de Load Balancer permet également de réaliser un équilibrage de charge entre plusieurs systèmes Caching Proxy. Si le site Web de votre entreprise est très consulté, la demande de contenu peut dépasser les capacités de traitement d'un serveur proxy unique et éventuellement diminuer les performances du système.
Vous pouvez posséder plusieurs systèmes Caching Proxy assurant la fonction de serveur 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 systèmes Caching Proxy, vous aurez également besoin de plusieurs hôtes de données dont vous équilibrez les charges à l'aide de Load Balancer. La Figure 6 présente cette configuration. Le composant Dispatcher 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
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 correspondrait à 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 vers le composant Dispatcher (4) qui la transmet au serveur proxy (5) 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 demande contenant son propre nom d'hôte dans la zone d'origine de l'en-tête et l'envoie au composant Dispatcher 7. Load Balancer identifie l'hôte de données (8) qui est le mieux à même de traiter la demande et lui adresse la demande. 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.
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 systèmes Caching Proxy et à utiliser le composant Dispatcher de Load Balancer pour équilibrer les charges entre eux.
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écessaire de 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 à la section Serveur d'acheminement Caching Proxy transparent (systèmes Linux uniquement) qui oriente le navigateur vers un ou plusieurs systèmes Caching Proxy secondaires. Un fichier de configuration automatique de proxy ne gère pas l'équilibrage de charge entre plusieurs systèmes Caching Proxy ; par conséquent, si un système reçoit beaucoup plus de demandes qu'un 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 systèmes Caching Proxy. L'une des interfaces réseau du système Dispatcher est configurée pour disposer de l'adresse IP et du nom d'hôte dédiés 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). Caching Proxy crée une demande, la fait transiter par la passerelle de l'entreprise (5) et 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 à la section Serveur d'acheminement Caching Proxy.
Figure 7. Utilisation de Dispatcher pour équilibrer la charge de plusieurs systèmes Caching 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 systèmes Caching Proxy peut se révéler inefficace dans la mesure où plusieurs serveurs proxy peuvent mettre en cache le même fichier si plusieurs clients le demandent via différents systèmes 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 serveurs proxy de ce groupe utilisent tous le même algorithme pour déterminer lequel est responsable d'une adresse URL donnée. Lorsqu'un serveur 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 demande 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 à la suite d'une panne réseau, les clients du navigateur ne peuvent pas atteindre les systèmes Caching Proxy ou Internet. La solution consiste à configurer un autre composant Dispatcher de secours, comme indiqué à la Figure 8.
Ici, un navigateur s'exécutant sur l'un des systèmes 1 adresse normalement sa demande de fichier X vers le composant Dispatcher principal (2), qui achemine la demande vers le composant Caching Proxy (4) sélectionné en fonction des critères d'équilibrage de charge du composant Dispatcher. Le composant Caching proxy crée une demande, la fait transiter par la passerelle de l'entreprise (6) et par 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 à la section Serveur d'acheminement Caching Proxy).
Dans cette configuration, le composant Dispatcher de secours (3) n'effectue aucun équilibrage de charge tant que le composant Dispatcher principal est opérationnel. Le composant Dispatcher principal et le composant Dispatcher de secours suivent leur état respectif en s'échangeant régulièrement 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 système 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 d'informations, 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 présente une configuration de ce type, dans laquelle le composant Dispatcher de secours est exécuté sur le même système (3) que le composant Caching Proxy.
Figure 9. Localisation du composant Dispatcher de secours sur un système Caching Proxy.
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 assure une fonction de secours pour le composant Load Balancer principal, comme décrit à la Figure 10. Si un composant Load Balancer tombe en panne ou devient inaccessible en raison d'un incident sur le réseau, l'utilisateur final peut toujours accéder aux hôtes de données.
En situation normale, un navigateur fonctionnant sur l'un des systèmes associés au chiffre 1 adresse sa demande portant sur le fichier X vers le nom d'hôte du 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 X sur Internet (2) mais en contournant le composant Load Balancer.
Le composant Dispatcher de secours (5) n'effectue pas l'équilibrage de charge tant que le composant principal est opérationnel. Le composant Dispatcher principal et le composant Dispatcher de secours suivent leur état respectif en s'échangeant régulièrement 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 de l'hôte du cluster principal.
Il est également possible de configurer deux composants Dispatcher pour assurer une haute disponibilité mutuelle. 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. (Les installations de Load Balancer for IPv4 and IPv6 prennent en charge la haute disponibilité simple mais pas la haute disponibilité mutuelle.)
En général, le composant Dispatcher n'utilise pas beaucoup de ressources de traitement ou de stockage et d'autres applications peuvent s'exécuter sur le système Load Balancer. Si une réduction des coûts de l'équipement s'avère indispensable, il est même possible d'exécuter le composant Dispatcher de secours sur l'un des systèmes du cluster dont il équilibre la charge. La Figure 11 présente ce type de configuration, avec un composant Dispatcher qui s'exécute sur l'un des hôtes de données (5) du cluster.
Figure 11. Emplacement du composant Load Balancer de secours sur un hôte de données
IMPORTANT : Le composant CBR est disponible sur toutes les plateformes prises en charge, sauf dans les cas suivants :
Pour ce type d'installation, vous pouvez utiliser la méthode d'acheminement CBR du composant Dispatcher de Load Balancer pour assurer un acheminement basé sur le contenu des demandes HTTP et HTTPS sans utiliser Caching Proxy. Pour plus d'informations, reportez-vous au document WebSphere Application Server Load Balancer - Guide d'administration.
Load Balancer for IPv4 and IPv6 prend uniquement en charge la méthode d'acheminement MAC du composant Dispatcher. Les méthodes d'acheminement NAT et CBR ne sont pas prises en charge.
Fonctionnant conjointement avec le composant WebSphere Application Server Caching Proxy, le composant WebSphere Application Server Load Balancer permet de distribuer des demandes à plusieurs serveurs d'arrière-plan hébergeant des données différentes. (Pour obtenir une présentation des composants du produit Edge Components, voir Introduction à WebSphere Application Server Edge Components.)
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 évite le stockage de données identiques sur tous les serveurs d'arrière-plan.
L'utilisation de CBR est particulièrement recommandée si les serveurs Web doivent effectuer différentes fonctions ou offrir plusieurs types de service. A titre d'exemple, le site Web d'un détaillant en ligne doit d'une part afficher son catalogue, dont la majeure partie est statique, et d'autre part accepter les commandes, ce qui implique d'exécuter une application interactive, tel qu'un script CGI (Common Gateway Interface) pour accepter des numéros de référence et des informations client. Il est parfois plus efficace d'utiliser deux ensembles de machines distincts pour effectuer les différentes fonctions et d'employer CBR pour acheminer les divers types de trafic vers différentes machines. De la même façon, une entreprise peut utiliser CBR pour offrir aux acheteurs un meilleur service qu'aux visiteurs occasionnels de son site Web, en acheminant les demandes payées vers des serveurs Web plus puissants.
CBR achemine les demandes en fonction de règles que vous définissez. Le type de règle le plus connu est la règle de données qui dirige les demandes en fonction du chemin d'accès indiqué dans l'URL. Par exemple, ABC Corporation peut écrire des règles pour diriger les demandes portant sur l'URL http://www.abc.com/catalog_index.html vers un cluster de serveurs et http://www.abc.com/orders.html vers un autre cluster. Il existe aussi des règles qui acheminent les demandes selon l'adresse IP du client qui les a envoyées ou d'autres caractéristiques. Pour plus d'informations, reportez-vous aux chapitres relatifs à la configuration de CBR et aux fonctions CBR et Load Balancer avancées dans le document 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ègle CBR dans le document WebSphere Application Server Load Balancer - Guide d'administration.
La Figure 12 présente une configuration simple dans laquelle le composant CBR de Load Balancer et Caching Proxy sont tous deux installés sur le système 4 et acheminent des demandes vers trois hôtes de données (6, 7 et 8) qui hébergent différents types de données. Lorsqu'un utilisateur final travaillant sur l'un des systèmes 1 demande le fichier X, la demande passe par 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 du même système qui analyse l'URL incluse 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 le fichier est susceptible d'être mis en cache, le serveur proxy stocke une copie 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. Acheminement de demandes HTTP avec CBR
Figure 13 décrit 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 tous deux installés sur le système 4 et acheminent les demandes vers deux systèmes Load Balancer. Le système Load Balancer é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 du même système qui analyse l'URL et détermine que le système Load Balancer 6 doit la traiter. Le serveur proxy crée une demande d'accès et l'envoie au composant Load Balancer, qui détermine l'hôte de données 8 qui 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 du système 4 l'adresse au système 7. Celui-ci 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 des demandes HTTP acheminées avec CBR
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).
Cette présente section contient des scénarios qui utilisent IBM WebSphere Application Server Edge Components. Ces solutions constituent des solutions architecturales testées et efficaces à haut niveau de performances, disponibilité, évolutivité et fiabilité.
Elle comporte les chapitres suivants :
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 dans toutes les installations Edge Components, sauf dans les cas suivants :
La Figure 14 présente un petit site Web commercial conçu pour permettre une consultation efficace de catalogues. Toutes les demandes du client passent par un pare-feu avant d'être transmises à un composant 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)
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 acheminées vers la branche appropriée du réseau par un composant Dispatcher qui sépare les demandes de type IP. Les demandes HTTP et les demandes HTTPS sont dirigées respectivement vers le site Web statique et le réseau d'achat. Le site Web statique principal est pris en charge 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 représentant le commerce électronique du site Web est également prise en charge par un cluster de serveurs proxy. Toutefois, les noeuds Caching Proxy sont améliorés avec 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 système 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)
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 systèmes WebSphere Application Server. Les serveurs d'applications contenant une logique métier sensible et liés à des bases de données sécurisées sont protégés par un pare-feu.
Figure 16. Réseau B2C (phase 3)
La Figure 17 présente une solution bancaire en ligne efficace comparable au réseau B2C décrit à la section Réseau B2C. Toutes les demandes client sont transmises, via le pare-feu, à un composant 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 composant 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 dans toutes les installations Edge Components, sauf dans les cas suivants :
Figure 17. Solution bancaire B2C
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érément 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 dans toutes les installations Edge Components, sauf dans les cas suivants :
La présente partie indique les procédures à suivre pour installer Edge Components.
Elle comporte les chapitres suivants :
Configuration requise pour Edge Components
Installation du logiciel Edge Components à l'aide du programme d'installation
Installation de Caching Proxy à l'aide des outils d'installation et de gestion système
Installation de Load Balancer à l'aide des outils d'installation et de gestion système
La présente section contient un lien pour connaître la configuration matérielle et logicielle requise avec Edge Components, ainsi que les instructions à suivre pour utiliser des navigateurs Web avec les formulaires de configuration et d'administration de Caching Proxy et l'aide en ligne.
Pour plus d'informations sur les configurations matérielles et logicielles requises avec WebSphere Application Server, version 7.0 Edge Components, accédez à la page suivante : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Installation de SDK : SDK Java 2 s'installe automatiquement avec Load Balancer sur toutes les plateformes.
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.
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 formulaires sont affichés par le navigateur avec le jeu de caractères utilisé par le serveur proxy, ici 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 de configuration et d'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 :
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.
La présente section contient les instructions à suivre pour installer Edge Components à l'aide du programme d'installation.
Le composant SDK Java 2 est installé 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, le serveur proxy ne peut pas démarrer.
IMPORTANT : Caching Proxy est disponible dans toutes les installations Edge Components, sauf dans les cas suivants :
Utilisez le programme d'installation pour installer le logiciel Edge Components sur votre système Windows :
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.
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 (...).
Si vous effectuez l'installation à partir du CD-ROM, utilisez le programme d'installation pour installer Edge Components sur des systèmes Linux et UNIX :
# ./installLa fenêtre Bienvenue s'affiche.
Le programme d'installation commence à installer les composants sélectionnés et les modules requis.
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 (...).
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 groupe de mises à 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 de commandes natives, voir Installation de Caching Proxy à l'aide des outils d'installation et de gestion système et Installation de Load Balancer à l'aide des outils d'installation et de gestion système.
La présente section contient les instructions à suivre pour installer 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, le serveur proxy ne peut pas démarrer.
IMPORTANT : Caching Proxy est disponible dans toutes les installations Edge Components, sauf dans les cas suivants :
A l'aide du système d'installation des modules de votre système d'exploitation, installez les modules dans l'ordre indiqué dans le Tableau 2. La procédure ci-après détaille les étapes nécessaires pour exécuter cette tâche.
su - root Mot de passe : mot_de_passe
cd point_montage/répertoire_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. Composant Caching Proxy
Composant | Modules installés (dans l'ordre conseillé) |
---|---|
Caching Proxy |
|
Documentation Edge Components |
doc-en_US
1
|
Remarques :
|
Tableau 3. Noms de fichier des modules AIX, HP-UX et Solaris
Nom du module générique | Jeux 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.lang 1 .base | WSES-cpmlang2 | WSEScpmlang3 |
Remarques :
|
Tableau 4. Noms de fichier des modules Linux
Nom du module générique | Nom du fichier Linux |
---|---|
admin | WSES_Admin_Runtime-version_édition 1.hardw2.rpm |
cp | WSES_CachingProxy-version_édition 1.hardw2.rpm |
doc | WSES_Doc_en_US-édition-version1.hardw2.rpm |
gskit7 | gsk7bas.rpm |
icu | WSES_ICU_Runtime-version_édition 1.hardw2.rpm |
msg-cp-lang | WSES_CachingProxy_msg_lang3-version_édition 1.hardw2.rpm |
Remarques :
|
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.
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.
La présente section décrit l'installation de Load Balancer sur des systèmes AIX, HP-UX, Linux et Solaris :
En fonction du type d'installation effectué, certains modules du composant Load Balancer répertoriés dans cette section ne sont pas 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'un système après l'installation de Load Balancer, vous devez redémarrer tous les services quand vous vous reconnecterez.
Le Tableau 5 répertorie les jeux de fichiers AIX pour Load Balancer et indique l'ordre d'installation recommandé avec l'outil d'installation système des modules.
Tableau 5. Jeux de fichiers AIX
Composants Load Balancer | Fichiers AIX |
---|---|
Base | ibmlb.base.rte |
Administration (avec messages) |
|
Pilote de périphérique | ibmlb.lb.driver |
Licence | ibmlb.lb.license |
Composants Load Balancer (avec messages) |
|
Documentation (avec messages) |
|
Metric Server | ibmlb.ms.rte |
Remarques :
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 d'installer Load Balancer pour AIX, vérifiez les points suivants :
installp -u ibmlb
ou, pour des versions précédentes, entrez la commande suivante :
installp -u ibmnd
Pour désinstaller des jeux de fichiers spécifiques, vous devez les afficher au lieu de spécifier le nom de module ibmlb.
Lors de l'installation du produit, vous avez la possibilité d'installer les composants suivants un à un ou en totalité :
Il est recommandé d'utiliser SMIT pour installer Load Balancer sous AIX car SMIT garantit l'installation automatique de tous les messages.
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
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). Comprend 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 |
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 :
La présente section décrit l'installation de Load Balancer sous HP-UX à l'aide du CD-ROM du produit.
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. Pour désinstaller Load Balancer, voir Instructions de désinstallation des modules.
Le Tableau 7 répertorie les noms des modules d'installation
de Load Balancer et l'ordre dans lequel il est recommandé de les installer à l'aide de
l'outil d'installation des modules du système.
Tableau 7. Détails de l'installation des modules HP-UX pour Load Balancer
Description du module | Nom du module 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 :
|
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 :
La procédure ci-après détaille les étapes à suivre pour effectuer cette tâche.
su - root Mot de passe : mot_de_passe
Exécutez la commande d'installation
swinstall -s /source nom_module
source correspondant au chemin de répertoire absolu du module et nom_module, au nom du module.
Par exemple, la commande suivante permet d'installer le module 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 modules pour Load Balancer, lancez la commande suivante, si vous l'installez à partir de la racine du CD :
swinstall -s /source ibmlb
Lancez la commande swlist pour afficher tous les modules que vous avez installés. Par exemple,
swlist -l fileset ibmlb
Utilisez la commande swremove pour désinstaller les modules. Les modules doivent être supprimés dans l'ordre inverse de celui de l'installation. Par exemple, exécutez les commandes suivantes :
swremove ibmlb
Pour ne désinstaller qu'un seul module (par exemple, le contrôleur Cisco CSS)
swremove ibmlb.cco
Les chemins d'installation de Load Balancer sont les suivants :
La présente section explique comment installer Load Balancer sous Linux à l'aide du CD-ROM du produit.
Avant d'installer Load Balancer, vérifiez les éléments suivants :
rpm -e nom_module
Les modules à désinstaller doivent être traités par ordre chronologique inverse, en veillant à désinstaller les modules d'administration en dernier.
L'image d'installation est un fichier au format lblinux-version.tar.
tar -xf lblinux-version.tarLes 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.
rpm -i module.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.
rpm -i --nodeps module.rpm
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.
La présente section explique comment installer Load Balancer sous Solaris à l'aide du CD-ROM du produit.
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. Entrez ensuite la commande suivante :
pkgrm nom_module
pkgadd -d cheminoù -d chemin est le nom de l'unité de CD-ROM ou du répertoire du disque dur où le module se trouve, par exemple : -d /cdrom/cdrom0/.
Voici la liste des modules 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.
pkginfo | grep ibm
Les chemins d'installation de Load Balancer sont les suivants :
Vous pouvez vous procurer le groupe de correctifs Edge Components pour les systèmes d'exploitation AIX, HP-UX, Linux, Solaris ou Microsoft Windows sur les supports suivants :
Pour plus d'informations sur les systèmes d'exploitation pris en charge, voir WebSphere Application Server detailed system requirements.
Le lien permettant de télécharger les groupes de mises à jour et de correctifs du logiciel Edge Components est disponible sur le site de support de WebSphere Application Server.
Pour connaître les instructions de mise à jour, reportez-vous aux sections suivantes :
Pour connaître les instructions de mise à jour de Load Balancer, reportez-vous au document Load Balancer for IPv4 - Guide d'administration ou Load Balancer for IPv4 and IPv6 - Guide d'administration.
Avant de lancer l'installation des groupes de mises à jour ou de correctifs, prenez en compte les éléments suivants :
Vous pouvez utiliser les outils d'installation des modules de votre système d'exploitation pour installer les modules Caching Proxy dans l'ordre approprié. Pour connaître la liste de tous les modules Edge Components et l'ordre dans lequel vous devez les installer, reportez-vous au tableau 4. La procédure ci-après détaille les étapes à suivre pour effectuer cette tâche.
su - root Mot de passe : mot_de_passe
stopsrc -c -s ibmproxy
kill -9 PID_proxy
Le terme PID_proxy est l'identificateur du processus Caching Proxy. Utilisez la commande suivante pour déterminer l'ID du processus Caching Proxy :
ps -e | grep ibmproxy
/etc/init.d/ibmproxy stop
/etc/rc.d/init.d/ibmproxy stop
kill -9 PID_proxy
Le terme PID_proxy est l'identificateur du processus Caching Proxy. Utilisez la commande suivante pour déterminer l'ID du processus Caching Proxy :
ps -e | grep ibmproxy
cd répertoire_téléchargement_modules/
Tableau 8. Instructions d'installation de Caching Proxy en fonction du système d'exploitation
Tableau 8. Instructions d'installation de Caching Proxy en fonction du système d'exploitation | |
---|---|
Système d'exploitation | Commandes |
AIX |
installp -acXd source nom_module source correspondant au répertoire du module et nom_module, au nom du module. Exemple :
Si vous utilisez SMIT (System Management Interface Tool) :
|
HP-UX |
swinstall -s /source nom_module source correspondant au répertoire du module et nom_module, au nom du module. Par exemple, la commande suivante installe le module d'administration de Caching Proxy, WSES-ADMIN, lorsqu'il se trouve dans le répertoire en cours : swinstall -s /admin WSES-ADMIN Pour vérifier l'installation des modules, lancez la commande swlist pour afficher tous les modules que vous avez installés. Par exemple, lancez les commandes suivantes pour afficher tous les modules installés pour Caching Proxy : swlist gsk* swlist WSES* |
Linux |
rpm -iv --replacefiles nom_module où nom_module correspond au nom du module. Par exemple, utilisez la commande suivante : rpm -iv --replacefiles WSES_Admin_Runtime-6.1.0-1.686.rpm
|
Solaris |
pkgadd -d source nom_module source correspondant au répertoire du module et nom_module, au nom du module. Exemple :
Pour lancer l'installation en mode silencieux, utilisez l'option -a et indiquez un fichier d'administration. Un fichier d'administration, instadm, est fourni avec les modules que vous installez. A l'issue de l'installation, les versions déjà installées des nouveaux modules se trouvent toujours sur le système. Ne les désinstallez pas. |
Le tableau ci-après répertorie tous les modules fournis avec Caching Proxy et l'ordre d'installation à suivre. Installez les modules inclus dans le groupe de mises à jour ou le groupe de correctifs en fonction de l'ordre indiqué dans le tableau ci-après.
Liste des modules | |
Composants installés | Mettez à jour les modules dans cet ordre |
Caching Proxy |
|
Documentation Edge Components | doc-lang |
A l'issue de l'installation d'une mise à jour du logiciel Edge Components, la configuration précédente du logiciel est conservée. Lorsque de nouvelles fonctionnalités ou améliorations sont fournies avec le groupe de mises à jour ou de correctifs, vous pouvez être amené à ajouter des instructions aux fichiers de configuration pour les activer.
Utilisez le programme d'installation de Caching Proxy de la manière suivante :
A l'issue de l'installation d'une mise à jour Edge Components, la configuration précédente du logiciel est conservée. Lorsque de nouvelles fonctionnalités ou améliorations sont fournies avec le groupe de mises à jour ou de correctifs, vous pouvez être amené à ajouter des instructions aux fichiers de configuration pour les activer.
Pour refuser une mise à jour :
Pour la plupart des composants, les fichiers de configuration sont sauvegardés dans le répertoire oldfiles/component lorsque le groupe de correctifs ou de mises à jour est supprimé. Vous pouvez utiliser ces fichiers de configuration avec la version réinstallée du produit pour conserver la configuration mise à jour dans la version antérieure.
La présente partie contient les procédures à suivre pour créer des réseaux de démonstration de base avec Edge Components. 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 :
Création d'un réseau Caching Proxy.
Création d'un réseau Load Balancer.
La Figure 19 présente un réseau de serveurs proxy de base utilisant trois systèmes situés sur trois noeuds 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 système serveur2 et le serveur proxy transmet des informations à l'hôte. Sur la figure, le réseau Internet se trouve maintenant entre le poste de travail et le système serveur1.
IMPORTANT : Caching Proxy est disponible dans toutes les installations Edge Components, sauf dans les cas suivants :
Figure 19. Réseau de démonstration Caching Proxy
Pour créer un réseau Caching Proxy, exécutez les procédures ci-après dans l'ordre indiqué :
Les systèmes et les logiciels suivants sont nécessaires :
Installez et configurez le système Caching Proxy de la manière suivante :
# 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.
Installez et configurez le système Caching Proxy de la manière suivante :
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.
A partir du poste de travail, procédez aux opérations ci-dessous.
A partir du poste de travail, procédez aux opérations ci-dessous.
La Figure 20 pré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
Pour créer un réseau Load Balancer, suivez les procédures ci-après dans l'ordre indiqué :
Les systèmes et les logiciels suivants sont nécessaires :
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.
Nom= www.entreprise.com IP=9.67.67.104
Ajoutez un alias pour www.entreprise.com à l'interface de bouclage sur serveur2.entreprise.com et serveur3.entreprise.com.
ifconfig lo0 alias www.entreprise.com netmask 255.255.255.0
ifconfig lo0:1 plumb www.entreprise.com netmask 255.255.255.0
La procédure de configuration des deux postes de travail agissant en tant que serveurs Web est à présent terminée.
Dispatcher permet de créer une configuration en utilisant la ligne de commande, l'assistant de configuration ou l'interface graphique utilisateur.
Si vous utilisez la ligne de commande, procédez comme suit :
dscontrol executor start
dscontrol cluster add www.entreprise.com
dscontrol port add www.entreprise.com:80
dscontrol server add www.entreprise.com:80:serveur2.entreprise.com
dscontrol server add www.entreprise.com:80:server3.entreprise.com
dscontrol executor configure www.entreprise.com
dscontrol manager start
Dispatcher effectue à présent l'équilibrage de charge en fonction des performances du serveur.
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.
Si vous utilisez l'assistant de configuration, procédez comme suit :
dsserver
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 contient les panneaux suivants :
Pour démarrer l'interface graphique utilisateur, procédez comme suit :
dsserver