LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE CONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE.
Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y sont fournies sont susceptibles d'être modifiées avant que les produits décrits ne deviennent eux-mêmes disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou services non annoncés dans ce pays. Cela ne signifie cependant pas qu'ils y seront annoncés.
Pour plus de détails, pour toute demande d'ordre technique, ou pour obtenir des exemplaires de documents IBM, référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire commercial.
Vous pouvez également consulter les serveurs Internet suivants :
Compagnie IBM France Direction Qualité Tour Descartes 92066 Paris-La Défense Cedex 50
(C) Copyright IBM France 2006. Tous droits réservés.
Le manuel WebSphere Application Server - Concepts, planification et installation pour Edge Components présente la suite des produits WebSphere Application Server - Edge Components. Il propose des présentations détaillées des produits et des fonctionnalités des composants importants, des scénarios mettant en oeuvre des composants Edge, des informations sur l'installation et la configuration initiale, des réseaux de démonstration.
Le manuel WebSphere Application Server - Concepts, planification et installation pour Edge Components est destiné aux administrateurs réseau et système expérimentés qui maîtrisent parfaitement leurs systèmes d'exploitation et la notion de fourniture de services Internet. Aucune connaissance préalable de Application Server ou de WebSphere Application Server - Edge Components n'est requise.
Les fonctions d'accessibilité permettent à un utilisateur ayant un handicap physique, telle qu'une mobilité restreinte ou une vision limitée, d'utiliser les produits logiciels. Les principales fonctions d'accessibilité de la structure WebSphere Application Server, version 6.1 sont les suivantes :
Ce document utilise les conventions et règles typographiques décrites ci-après.
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. |
Retour | Fait référence à la touche libellée Retour ou Entrée, ou à la flèche vers la gauche. |
% | Représente l'invite de commandes du shell Linux et UNIX d'une commande qui ne nécessite pas les droits d'accès root. |
# | Représente l'invite de commandes du shell Linux et UNIX d'une commande qui requiert les droits d'accès root. |
C:\ | Représente l'invite Windows. |
Entrée de commandes | Lorsque vous êtes invité à "entrer" ou à "émettre" une commande, tapez la commande et appuyez sur la touche Retour. Par exemple, l'instruction "Entrez la commande ls" signifie tapez ls à l'invite et appuyez sur Retour. |
[ ] | Encadre les éléments facultatifs des descriptions de syntaxe. |
{ } | Encadre les listes dans lesquelles vous devez choisir un élément dans les descriptions de syntaxe. |
| | Sépare les éléments d'une liste de choix encadrés par { } (accolades) dans les descriptions de syntaxe. |
... | Dans les descriptions de syntaxe, indique que l'élément qui précède peut être répété une ou plusieurs fois. Dans les exemples, indique que des informations ont volontairement été omises par souci de concision. |
Cette partie présente WebSphere Application Server - Edge Components, Caching Proxy et Load Balancer et décrit leur intégration avec Application Server. Elle définit également les composants Caching Proxy et Load Balancer. De plus, cette partie présente d'autres produits de la famille WebSphere.
Elle comporte les chapitres suivants :
WebSphere est un logiciel d'infrastructure Internet permettant aux entreprises de développer, de déployer et d'intégrer des applications de e-business, telles que celles de commerce B2B. Le produit middleware WebSphere prend en charge des applications d'entreprise de la publication Web simple aux traitements de transactions d'entreprise.
En tant que base de la plateforme WebSphere, WebSphere Application Server offre un jeu complet middleware permettant de concevoir, d'implémenter, de déployer et de gérer des applications d'entreprise, telles qu'un site Web rudimentaire de vente ou une révision complète de l'infrastructure de traitement d'une organisation.
Les fonctions gourmandes en temps processeur, telles que la personnalisation, offrent un avantage compétitif aux entreprises de commerce électronique. Cependant, confiner ces fonctions sur des serveurs centraux peut empêcher l'évolution des applications vers Internet. Avec l'ajout de nouvelles applications Web, l'infrastructure Internet d'une entreprise doit s'étendre et gagner en efficacité. En outre, la fiabilité et la sécurité sont essentielles pour une entreprise électronique. Tout dysfonctionnement même de courte durée peut entraîner une perte pour l'entreprise.
Les Composants Edge (anciennement Edge Server) sont à présent intégrés à l'offre WebSphere Application Server. Les Composants Edge peuvent être utilisés conjointement avec WebSphere Application Server pour contrôler les accès des clients aux serveurs Web et permettre aux entreprises d'offrir un meilleurs service aux utilisateurs ayant accès données Web via Internet ou un réseau intranet d'entreprise. L'utilisation des Composants Edge permet de réduire la charge du serveur Web, d'accroître la disponibilité des données et d'améliorer les performances du serveur Web. Le nom Composants Edge indique que le logiciel fonctionne généralement sur des postes situés à proximité (dans une configuration réseau) de la frontière entre l'intranet d'une entreprise et Internet.
WebSphere Application Server comporte les composants Edge Caching Proxy et Load Balancer.
IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :
Caching Proxy réduit l'utilisation de la bande passante et améliore la vitesse et la fiabilité d'un site Web en fournissant un point de présence pour un ou plusieurs serveurs de données d'arrière-plan. Caching Proxy peut placer en cache des données statiques ainsi que des données dynamiques générées par WebSphere Application Server.
Il est possible de configurer Caching Proxy comme un serveur proxy inversé (configuration par défaut) ou comme un serveur proxy d'acheminement, fournissant un point de présence pour un réseau ou un serveur de réseau interne devant améliorer les temps de demande et de réponse. Pour plus d'informations sur les configurations inversées et d'acheminement, voir Configurations de base de Caching Proxy.
Le serveur proxy intercepte les demandes de données émanant d'un client, extrait les informations demandées sur les hôtes de données et les fournit au client. Le plus souvent, les demandes concernent des documents stockés sur des serveurs Web (également appelés serveurs d'origine ou hôtes de données) et fournis à l'aide du protocole HTTP (Hypertext Transfer Protocol). Vous pouvez toutefois configurer le serveur proxy de sorte qu'il accepte d'autres protocoles, tels que FTP (File Transfer Protocol) et Gopher.
Le serveur proxy stocke les données dans une mémoire cache locale avant de les fournir au demandeur. Les données pouvant être mises en mémoire cache incluent des pages Web statiques et des fichiers JSP comportant des informations générées dynamiquement, mais peu sujettes à modification. La mise en mémoire cache permet au serveur proxy de satisfaire les demandes ultérieures afférentes aux mêmes données, directement depuis la mémoire cache locale, ce qui nécessite bien moins de temps qu'une nouvelle extraction depuis l'hôte de données.
Les plug-ins de Caching Proxy ajoutent des fonctionnalités au serveur proxy.
Vous pouvez personnaliser les fonctions de Caching Proxy en écrivant des plug-ins dans une interface de programmation d'application (API). L'API est souple, facile à utiliser et indépendante des plateformes. Le proxy effectue une séquence d'opérations pour chaque demande client qu'il traite. Une application de plug-in modifie ou remplace une opération dans le traitement des demandes, comme l'authentification client ou le filtrage des demandes. L'interface puissante Transmogrify, par exemple, fournit un accès aux données HTTP et autorise la substitution ou la transformation d'URL et de données Web. Les plug-ins peuvent modifier ou remplacer certaines étapes de traitement, et vous pouvez appeler plusieurs plug-ins pour une même étape de traitement.
Load Balancer crée des systèmes Edge Server qui gèrent le flux du trafic réseau, réduisant la surcharge et équilibrant la charge sur divers autres services et systèmes. Load Balancer fournit des fonctions de sélection de site, de gestion de la charge de travail, d'affinité de session et de gestion transparente des pannes.
Le composant Load Balancer est installé entre Internet et les serveurs dorsaux de l'entreprise qui peuvent être des hôtes de données ou des machines Caching Proxy. Load Balancer fait office de point de présence unique de l'entreprise sur Internet, même si cette dernière utilise plusieurs serveurs dorsaux en raison d'une forte demande ou d'une grande quantité de données. Vous pouvez également garantir une haute disponibilité en installant un Load Balancer de secours chargé de prendre le relais en cas de panne temporaire de l'équilibreur principal.
Le composant Load Balancer intercepte les demandes de données émanant des clients et les transmet au serveur le mieux à même d'y répondre. En d'autres termes, il équilibre la charge des demandes entrantes sur un ensemble défini de machines qui traitent le même type de demandes. Le composant Load Balancer peut répartir les demandes entre différents types de serveurs, y compris les serveurs WebSphere Application Server et les machines Caching Proxy. L'équilibrage de charge peut être personnalisé pour une application ou une plateforme particulière à l'aide de conseillers personnalisés. Des conseillers d'objet spéciaux permettent d'obtenir des informations pour l'équilibrage de la charge de systèmes WebSphere Application Server.
Si le composant CBR (Content Based Routing) est installé en même temps que le composant Caching Proxy, les demandes HTTP peuvent même être réparties en fonction des URL ou d'autres caractéristiques déterminées par un administrateur, ce qui élimine la nécessité de stocker des données identiques sur tous les serveurs dorsaux. Le composant Dispatcher peut fournir la même fonction pour les demandes HTTP.
L'équilibrage de charge améliore la disponibilité et l'évolutivité de votre site Web en mettant en clusters serveurs HTTP, serveurs d'applications et serveurs proxy, qui sont des serveurs de données de remplacement. La disponibilité est réalisée à l'aide du parallélisme, l'équilibrage de charge et le support des pannes. Une panne de serveur ne bloque en rien les affaires. L'évolutivité de l'infrastructure informatique est considérablement améliorée car il est possible d'ajouter une puissance de traitement d'arrière-plan de façon transparente.
Prise en charge d'IPv6 : La prise en charge du schéma d'adressage IP étendu d'IPv6 est disponible avec "Load Balancer pour IPv4 et IPv6." Load Balancer pour IPv4 et IPv6 est une image d'installation distincte composée uniquement du composant Dispatcher. Ce type d'installation fournit un équilibrage de charge pour le trafic IPv4 et IPv6 sur les serveurs configurés dans votre réseau à l'aide de l'acheminement de paquets basé MAC du composant Dispatcher. Il est important de noter qu'il est nécessaire de désinstaller tout composant Load Balancer en place avant d'installer Load Balancer pour IPv4 et IPv6. Il n'est pas possible de faire cohabiter deux composants Load Balancers sur une même machine. (Pour une présentation rapide du composant Dispatcher, voir Dispatcher.)
Load Balancer comporte les composants suivants :
Pour tous les services Internet, tels que HTTP, FTP, HTTPS et Telnet, le composant Dispatcher réalise l'équilibrage de la charge des serveurs sur un réseau local (LAN) ou un réseau étendu (WAN). Pour les services HTTP, Dispatcher réalise l'équilibrage de la charge des serveurs à partir de l'URL de la demande du client.
Le composant Dispatcher active la gestion stable et efficace d'un réseau de serveurs étendu et évolutif. Il permet de lier plusieurs serveurs individuels dans ce qui semble être un serveur virtuel unique. Votre site est référencé par une adresse IP unique sur l'Internet.
Si vous utilisez une installation Load Balancer pour IPv4 et IPv6, consultez le chapitre sur le déploiement de Dispatcher sur Load Balancer pour IPv4 et IPv6, qui contient des informations sur les limitations et les différences de configuration, dans le document WebSphere Application Server Load Balancer - Guide d'administration.
Pour les services HTTP et HTTPS, le composant routage CBR réalise l'équilibrage de la charge des serveurs en fonction du contenu de la demande du client. Le composant CBR fonctionne conjointement avec le composant Caching Proxy de Application Server.
IMPORTANT: Le composant CBR (routage CBR) est disponible sur toutes les plateformes prises en charge, sauf dans les cas suivants :
Par ailleurs, pour ce type d'installation, vous pouvez utiliser la méthode d'acheminement cbr du composant Dispatcher de Load Balancer pour assurer le routage basé sur contenu des requêtes HTTP et HTTPS sans utiliser Caching Proxy. Pour plus d'informations, voir le document WebSphere Application Server Load Balancer - Guide d'administration.
Load Balancer pour IPv4 et IPv6 prend en charge uniquement 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 de composants Edge, 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 de composants Edge, 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 de composants Edge, sauf dans le cas suivant :
Ce composant s'exécute en tant que démon sur un serveur dont la charge est équilibrée et fournit des informations à propos des charges du système sur les composants Load Balancer.
La famille de produits IBM WebSphere a pour vocation d'aider les utilisateurs à réaliser leurs ambitions en matière de commerce électronique. Il s'agit d'un ensemble de logiciels permettant de développer et de gérer des sites Web hautes performances, et d'intégrer des sites Web dans des systèmes d'informations d'entreprise nouveaux ou existants mettant en oeuvre une technologie client-serveur classique.
La famille de logiciels WebSphere se compose de WebSphere Application Server, comprenant les Composants Edge, et d'autres logiciels de la famille WebSphere parfaitement intégré à WebSphere Application Server, et améliore ses performances. Pour une présentation WebSphere Application Server et de ses composants, "voir Présentation des composants Edge de WebSphere Application Server".
Tivoli Access Manager (anciennement Tivoli Policy Director) est disponible séparément. Il fournit un contrôle d'accès et une sécurité centralisée pour des applications Web ainsi qu'une fonctionnalité d'authentification unique avec un accès à plusieurs ressources Web. Un plug-in Caching Proxy exploite la structure de sécurité d'Access Manager, permettant au serveur proxy d'utiliser les services d'autorisation ou d'authentification intégrés de celui-ci.
WebSphere Portal Server (disponible séparément) propose une structure répondant aux exigences de présentation, de sécurité, d'évolutivité et de disponibilité des portails. Portal Server permet aux entreprises de créer leur site Web portail personnalisé répondant aux besoins des employés, des partenaires commerciaux et des clients. Après connexion au portail, les utilisateurs reçoivent des pages Web personnalisées fournissant un accès aux informations, personnes et applications requises. Ce point d'accès personnalisé uniquement à toutes les ressources nécessaires réduit la charge d'informations, accélère la productivité et augmente l'utilisation du site Web.
WebSphere Portal Server s'exécute dans un cluster WebSphere Application Server à des fins d'évolutivité et de fiabilité. Le composant Load Balancer de Application Server peut également être utilisé pour ajouter un équilibrage de charge et une disponibilité élevée.
WebSphere Site Analyzer (disponible séparément) aide les entreprises à anticiper les problèmes de capacité et de performances. Les journaux de Caching Proxy et de Load Balancer ainsi que d'autres outils de gestion permettent d'anticiper les demandes de ressources supplémentaires en contrôlant, analysant et consignant l'activité de votre site Web. En outre, les composants de gestion Site Analyzer aident les utilisateurs à installer et à mettre à niveau les Composants Edge, gérer et stocker des configurations, exécuter les Composants Edge à distance, afficher et consigner des événements.
WebSphere Transcoding Publisher (disponible séparément) permet de convertir une page Web pour la visualiser sur une unité mobile, de type téléphone connecté à Internet, de convertir des données Web dans la langue préférée de l'utilisateur (en appelant WebSphere Translation Server) et de convertir des langages de balisage. Transcoding Publisher augmente les fonctionnalités de Caching Proxy en permettant à celui-ci de servir des données pour des périphériques et des utilisateurs différents. Après avoir accédé à des données d'un serveur Web, l'interface Transmogrify de Caching Proxy peut être configurée pour transformer ces données en vue de les placer en mémoire cache et de les réutiliser le cas échéant. A partir de l'interface de post-authentification de Caching Proxy, Transcoding Publisher interroge le serveur proxy à la recherche de données correspondant aux exigences de l'utilisateur et du périphérique et, si une occurrence existe, les données sont extraites de la mémoire cache du serveur proxy.
La documentation suivante s'applique à WebSphere Application Server Edge Components et est disponible dans le centre de documentation du logiciel Edge Components.
D'autres documents WebSphere Application Server sont disponibles dans la page de bibliothèque de WebSphere Application Server.
Des informations techniques sur le logiciel Edge Components sont disponibles dans la page de support WebSphere Application Server.
Les sites Web sur lesquels vous pouvez obtenir des informations relatives à Edge Components ou connexes sont les suivants :
Cette partie comporte des présentations détaillées mettant en relief quelques fonctionnalités offertes par les composants Edge. Pour une présentation du composant Caching Proxy de Webpshere Application Server, voir Présentation des composants Edge de WebSphere Application Server.
Elle comporte les chapitres suivants :
La fonction de mise en cache de Caching Proxy permet de réduire au minimum l'utilisation de la bande passante et d'assurer un service plus rapide et plus fiable aux utilisateurs finals. En effet, la fonction de cache réalisée par le serveur proxy allège les serveurs dorsaux et les liens de connexion. Caching Proxy peut placer en cache des données statiques ainsi que des données dynamiques générées par WebSphere Application Server. Pour améliorer la fonction de mise en cache, Caching Proxy travaille aussi conjointement avec le composant Application Server Load Balancer. Pour une présentation de ces systèmes, voir Présentation des composants Edge de WebSphere Application Server.
IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :
Il est possible de configurer Caching Proxy comme un serveur proxy de mise en cache inversé (configuration par défaut) ou comme un serveur proxy de mise en cache d'acheminement. Lorsqu'il est utilisé par des hôtes de données, Caching Proxy est configuré comme serveur proxy, placé entre Internet et les hôtes de données des entreprises. Lorsqu'il est utilisé par des fournisseurs d'accès à Internet, il est configuré comme serveur proxy d'acheminement, placé entre un client et Internet.
Dans une configuration avec un proxy inversé, les machines Caching Proxy sont situées entre Internet et les hôtes de données de l'entreprise. Fonctionnant comme un serveur de secours, le serveur proxy intercepte les demandes utilisateur émanant d'Internet, les transmet à l'hôte de données approprié, stocke les données renvoyées en mémoire cache et fournit ces données aux utilisateurs via Internet. La mise en mémoire cache permet à Caching Proxy de satisfaire les demandes ultérieures afférentes aux mêmes données, directement depuis la mémoire cache locale, ce qui nécessite bien moins de temps qu'une nouvelle extraction depuis l'hôte de données. Les informations sont placées en mémoire cache selon certains critères, comme leur délai d'expiration, leur taille par rapport à celle du cache et leur délai de mise à jour. Des temps de téléchargement des occurrences trouvées en mémoire cache signifient une meilleure qualité de service pour les clients. La figure 1 illustre cette fonctionnalité de base du Caching Proxy.
Légende : 1--Client 2--Internet 3--Routeur/Passerelle 4--Proxy de mise en cache 5--Mémoire cache 6--Hôte de donnéesDans cette configuration, le serveur proxy (4) intercepte les demandes dont les URL comportent le nom de l'hôte de données (6). Lorsqu'un client (1) demande le fichier X, la demande traverse Internet (2) et pénètre sur le réseau interne de l'entreprise via sa passerelle Internet ( 3). Le serveur proxy intercepte la demande, en génère une nouvelle avec sa propre adresse IP comme adresse d'origine, et envoie la nouvelle demande à l'hôte de données (6).
L'hôte de données renvoie le fichier X au serveur proxy et non directement à l'utilisateur. Si le fichier peut être stocké en mémoire cache, Caching Proxy en stocke une copie dans sa mémoire cache (5) avant de la transmettre à l'utilisateur final. L'exemple le plus évident de données mises en cache concerne les pages Web statiques ; cependant, Caching Proxy permet également de mettre en cache et de fournir des données générées en dynamique par WebSphere Application Server.
Fournir un accès direct à Internet aux utilisateurs finals peut être source d'inefficacité. Tout utilisateur qui récupère un fichier donné à partir d'un serveur Web génère la même quantité de trafic sur votre réseau et via la passerelle Internet que le premier utilisateur ayant récupéré le fichier, même si ce dernier n'a pas été modifié. La solution consiste à installer un Caching Proxy d'acheminement près de la passerelle.
Dans une configuration avec un proxy d'acheminement, les machines Caching Proxy sont situées entre le client et Internet. Caching Proxy achemine la requête d'un client aux hôtes de données situés sur Internet, met en cache les données extraites et les fournit au client.
figure 2 présente la configuration d'un Caching Proxy d'acheminement. Les programmes du navigateur des clients (sur les machines marquées 1) sont configurés pour pour diriger les requêtes vers le proxy de mise en cache d'acheminement (2), lequel est configuré pour intercepter les requêtes. Lorsqu'un utilisateur final demande le fichier X stocké sur l'hôte de données (6), le proxy de mise en cache d'acheminement intercepte la requête, en génère une nouvelle avec sa propre adresse IP comme adresse d'origine et renvoie la nouvelle requête au moyen du routeur de l'entreprise (4) via Internet (5).
Le serveur d'origine renvoie ainsi le fichier X au proxy de mise en cache d'acheminement et non directement à l'utilisateur final. Si la fonctionnalité de mise en cache du proxy de mise en cache d'acheminement est activée, le proxy de mise en cache détermine si le fichier X est éligible pour la mise en cache en cochant des paramètres dans son en-tête de retour, comme la date d'expiration et une indication signalant si le fichier a été généré de façon dynamique. Si le fichier est susceptible d'être mis en cache, le proxy de mise en cache en stocke une copie dans sa mémoire cache (3) avant de la transmettre à l'utilisateur final. Par défaut, la mise en cache est activée et le proxy de mise en cache d'acheminement utilise un cache mémoire ; vous pouvez toutefois configurer d'autres types de mise en cache.
Pour la première demande du fichier X, le proxy d'acheminement n'améliore pas beaucoup les performances d'accès à Internet. En fait, pour le premier utilisateur accédant au fichier X, le temps de réponse est probablement plus long que sans le proxy de mise en cache car ce dernier a besoin de temps pour traiter le paquet de demande d'origine et pour rechercher les informations de mise en cache dans l'en-tête du fichier X, à la réception de ce dernier. En revanche, utiliser le proxy d'acheminement présente un intérêt lorsque d'autres utilisateurs demandent par la suite le fichier X. Le proxy vérifie la validité de sa copie cachée du fichier X (pas d'expiration) et récupère le fichier X directement dans le cache, sans acheminer la demande via Internet jusqu'à l'hôte de données.
Même en cas d'expiration d'un fichier demandé, le proxy de mise en cache d'acheminement ne doit pas nécessairement retourner récupérer le fichier dans l'hôte de données. Il envoie plutôt un message spécial de vérification d'état à l'hôte de données. Si ce dernier indique que le fichier est inchangé, le proxy peut encore fournir la version cachée à l'utilisateur de qui émane la demande.
Dans ce type de configuration, on parle de proxy de mise en cache d'acheminement car le proxy agit pour le compte des navigateurs, acheminant leurs requêtes aux hôtes de données via Internet. Les avantages dans ce cas sont doubles :
Le proxy de mise en cache peut fonctionner avec plusieurs protocoles de transfert en réseau, notamment HTTP (Hypertext Transfer Protocol, FTP (File Transfer Protocol) et Gopher.
Une variante du Caching Proxy d'acheminement est un Caching Proxy transparent. A ce titre, Caching Proxy exécute la même fonction qu'un Caching Proxy d'acheminement de base, mais sans que le client soit conscient de sa présence. Cette configuration transparente n'est prise en charge que sur les systèmes Linux.
Dans la configuration décrite dans Caching Proxy d'acheminement, chaque navigateur client est configuré de façon distincte de façon à diriger les demandes à un certain Caching Proxy d'acheminement. Gérer une telle configuration peut se révéler peu pratique, notamment lorsque les machines client sont en grand nombre. Caching Proxy prend en charge plusieurs solutions alternatives simplifiant l'administration. Une des possibilités consiste à le configurer comme un proxy transparent, comme décrit à la figure 3. Comme dans le cas d'un proxy d'acheminement classique, le proxy transparent est installé sur une machine près de la passerelle, mais les programmes du navigateur client ne sont pas configurés pour diriger les demandes à un proxy d'acheminement. La présence d'un proxy dans la configuration reste ignorée des clients. Un routeur est configuré pour intercepter les demandes du client et les diriger vers le proxy transparent. Lorsqu'un client utilisant l'une des machines 1 demande le fichier X stocké sur un hôte de données (6), le routeur (2) transmet la demande à Caching Proxy. Caching Proxy génère une nouvelle demande avec sa propre adresse IP comme adresse d'origine et renvoie la nouvelle requête au moyen du routeur (2) via Internet (5). Lorsque le fichier X arrive, Caching Proxy le met en cache s'il est adéquat (remplit les conditions décrites dans Caching Proxy d'acheminement) et le transmet au client demandeur.
Pour les requêtes HTTP, une autre solution possible pour conserver les informations de configuration du proxy sur chaque navigateur consiste à utiliser la fonctionnalité de configuration automatique du proxy qui est disponible dans plusieurs programmes de navigateur, notamment Netscape Navigator versions 2.0 et ultérieures, et Microsoft Internet Explorer versions 4.0 et ultérieures.Dans ce cas, vous créez un ou plusieurs fichiers de configuration automatique de proxy et vous configurez les navigateurs pour qu'ils fassent référence à l'un d'entre eux plutôt qu'aux informations de configuration du proxy locales. Le navigateur remarque automatiquement toute modification apportée au fichier de configuration automatique et adapte son utilisation du proxy en conséquence. Vous éliminez ainsi le besoin de conserver des informations de configuration distinctes sur chaque navigateur, mais en plus vous pouvez réacheminer facilement les demandes en cas d'indisponibilité soudaine d'un serveur proxy.
Une troisième solution consiste à utiliser le mécanisme WPAD (Web Proxy Auto Discovery) disponible sur certains navigateurs, comme Internet Explorer version 5.0 et versions ultérieures. Lorsque vous activez cette fonctionnalité sur le navigateur, ce dernier localise automatiquement un serveur proxy compatible WPAD sur son réseau et y dirige ses requêtes Web. Dans ce cas, il est inutile de conserver des fichiers de configuration de proxy au niveau central. Caching Proxy est compatible WPAD.
Pour fournir des fonctionnalités de cache plus poussées, utilisez Caching Proxy comme proxy inversé conjointement avec le composant Load Balancer. En intégrant des fonctions de cache et d'équilibrage de charge, vous pouvez créer une infrastructure de performances Web efficace et à forte capacité de gestion.
La figure 4 montre comment associer Caching Proxy au composant Load Balancer pour répondre efficacement aux demandes de données Web, même en cas de forte demande. Dans cette configuration, le serveur proxy (4) est configuré pour intercepter les demandes dont les URL comportent le nom d'hôte d'un cluster d'hôtes de données (7) par le composant Load Balancer (6).
Légende : 1--Client 2--Internet 3--Routeur/passerelle 4--Caching Proxy 5--Mémoire cache 6--Load Balancer 7--Hôte de donnéesLorsqu'un client (1) demande le fichier X, la demande traverse Internet (2) et pénètre sur le réseau interne de l'entreprise via sa passerelle Internet ( 3). Le serveur proxy intercepte la demande, en génère une nouvelle avec sa propre adresse IP comme adresse d'origine, et envoie la nouvelle demande au composant Load Balancer à l'adresse du cluster. Le composant Load Balancer utilise son algorithme d'équilibrage de charge pour déterminer quel hôte de données est le plus apte à satisfaire la demande portant sur le fichier X. Cet hôte de données renvoie le fichier X au serveur proxy et non via le composant Load Balancer. Le serveur proxy détermine s'il doit le stocker en mémoire cache, et le fournit à l'utilisateur, comme décrit précédemment.
La fonction de cache est également fournie par le plug-in Dynamic Caching de Caching Proxy. Lorsqu'il est utilisé avec WebSphere Application Server, Caching Proxy permet de placer en cache, de fournir et d'invalider des données dynamiques telles que des JSP (JavaServer Pages) et des réponses de servlet générées par WebSphere Application Server.
En général, les données dynamiques dont la durée de vie est illimitée doivent être marquées pour ne pas être placées en mémoire cache car la logique de suppression des données arrivées à expiration n'est pas fiable pour ce type de données. Le plug-in Dynamic Caching possède une logique de suppression orientée événement permettant au serveur proxy de placer en mémoire cache des données à durée de vie illimitée. La mise en cache de telles données évite aux hôtes de données d'appeler une machine Application Server de façon répétée pour répondre aux demandes de clients. Elle offre les avantages suivants :
L'activation de la fonction de cache des réponses de servlet est idéale pour les pages Web générées en dynamique d'une durée de vie basée sur la logique applicative ou sur un événement tel qu'un message extrait d'une base de données. Bien que la durée de vie d'une telle page soit limitée, la valeur TTL ne peut être fixée sur l'heure de création car le commutateur d'expiration ne peut être connu à l'avance. Si la valeur TTL de telles pages est fixée sur zéro, les hôtes de données sont pénalisés lors des échanges de données dynamiques.
La responsabilité de synchroniser le cache dynamique de Caching Proxy et de Application Server est partagée entre les deux systèmes. Par exemple, une page Web publique créée en dynamique par une application fournissant des prévisions météorologiques peut être exportée par Application Server et mise en cache par Caching Proxy. Caching Proxy peut fournir les résultats de l'application de façon répétée à un grand nombre d'utilisateurs jusqu'à ce que la page ne soit plus valide. Les données du cache des réponses de servlet de Caching Proxy sont valides jusqu'à la suppression d'une entrée par le serveur proxy car le cache est saturé, l'expiration du délai par défaut défini par la directive ExternalCacheManager du fichier de configuration de Caching Proxy ou la réception d'un message Invalidate par Caching Proxy lui ordonnant de supprimer les données de son cache. Les messages Invalidate émanent de la machine WebSphere Application Server et sont envoyés à chaque Caching Proxy configuré.
Caching Proxy offre d'autres fonctions importantes de mise en cache :
Les performances réseau sont concernées par l'introduction de la fonctionnalité de Caching Proxy. Caching Proxy peut être utilisé seul ou avec Load Balancer afin d'améliorer les performances du réseau. Le Présentation des composants Edge de WebSphere Application Server fournit une présentation de ces systèmes.
Les performances de Caching Proxy sont aussi importantes que le matériel sur lequel le logiciel est installé et que l'architecture globale dans laquelle est intégré le système. Pour optimiser les performances réseau, adaptez le matériel et l'architecture réseau globale aux caractéristiques des serveurs proxy.
La configuration et l'administration de base du logiciel Caching Proxy et de la personnalisation au niveau du système d'exploitation contribuent également en grande partie aux performances de Caching Proxy. La plupart des modifications de la configuration logicielle permettent d'accroître sensiblement les performances. Elles comprennent mais ne sont pas limitées au réglage des directives de journalisation, des règles de mappage, des plug-ins, des valeurs de délai, des valeurs de configuration de la mémoire cache et des valeurs de threads actives. La configuration du logiciel Caching Proxy est étudiée en détails dans le Guide d'administration de Caching Proxy.
La plupart des modifications du système d'exploitation permettent également d'améliorer les performances ; elles comprennent mais ne sont pas limitées au réglage de TCP et ARP, à l'augmentation des limites des descripteurs de fichier, au réglage des cartes d'interfaces réseau (NIC pour Network Interface Cards) et au respect de bonnes pratiques lors de l'exécution de tâches d'administration système.
IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :
La section traite des points de l'architecture réseau à prendre en compte lors de l'installation de Caching Proxy.
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'un espace disque important sur la machine hébergeant Caching Proxy. Ceci est particulièrement vrai lorsque des mémoires cache sont employées. La lecture et l'écriture disque sont des processus intensifs pour l'ordinateur. Bien que les procédures d'E-S de Caching Proxy soient efficaces, les limitations mécaniques des disques durs limitent des performances quand Caching Proxy est configuré pour utiliser le cache disque. Le goulet d'étranglement des E-S disque peut être supprimé en utilisant plusieurs disques durs pour des périphériques de cache brut et des fichiers journaux ainsi que des unités de disque aux vitesses de recherche, de rotation et de transfert supérieures.
Les ressources réseau telles que la vitesse, le type et le nombre de cartes réseau ainsi que la vitesse de la connexion réseau au serveur proxy influent directement sur les performances de Caching Proxy. Pour des performances optimales, il est conseillé d'utiliser deux cartes réseau sur le serveur proxy : une pour le trafic entrant, une pour le trafic sortant. Il est fréquent qu'une seule carte réseau atteigne sa limite maximale par échange entre le client et le serveur HTTP. De plus, les cartes réseau doivent avoir un débit minimal de 100 Mo et être configurées pour un fonctionnement en mode duplex. En effet, une négociation automatique entre le périphérique de routage et le périphérique de commutation peut générer des erreurs et réduire le débit. Enfin, la vitesse de la connexion réseau est très importante. Par exemple, vous ne pouvez envisager de traiter de façon optimale un grand nombre de demandes si la connexion à la machine Caching Proxy est un ligne T1 saturée.
L'unité centrale de traitement (UC) d'une machine Caching Proxy peut devenir un facteur de limitation. La puissance de l'UC affecte la vitesse de traitement des demandes CPU ; le nombre d'UC du réseau, l'évolutivité. Il est important de respecter les ressources processeur du serveur proxy, de façon à gérer la charge maximale de demandes que le serveur proxy traitera.
Pour des performances globales, il est généralement souhaitable d'avoir une vision globale de l'architecture au lieu de se concentrer sur des éléments matériels spécifiques. Peu importe le nombre de composants matériels que vous ajoutez à une machine, ceux-ci doivent offrir un niveau maximal de performance.
La section traite des points de l'architecture réseau à prendre en compte lors de l'installation de Caching Proxy.
Si le site Web de votre entreprise est très apprécié, la demande de contenu peut excéder la capacité d'un serveur proxy et potentiellement diminuer les performances. Pour optimiser les performances réseau, vous pouvez ajouter des clusters de machines Caching Proxy à équilibrage de charge ou utiliser une architecture de cache partagée avec Remote Cache Access (RCA) dans votre architecture réseau globale.
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 pratique de conception avantageuse 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.
Un tableau RCA de serveurs proxy est plus performant qu'un Caching Proxy autonome ou qu'un cluster de machines Caching Proxy 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 cache de Caching Proxy. Cependant, le cache du serveur proxy peut devenir un goulet d'étranglement s'il n'est pas configuré correctement. Pour déterminer la meilleure configuration de cache, un effort significatif doit être apporté à l'analyse des caractéristiques du trafic. Le type, la taille, la quantité et les attributs des données influent sur les performances du serveur proxy en termes de vitesse d'extraction de documents sur les serveurs origine et de charge du serveur. Quand vous comprenez le type de trafic que Caching Proxy s'apprête à mandater ou à servir à partir du cache, vous pouvez prendre en compte ces caractéristiques au moment de la configuration du serveur proxy. Par exemple, savoir que 80 % des objets à placer en mémoire cache sont des images (*.gif ou *.jpg) d'une taille approximative de 200 Ko vous permet de personnaliser les paramètres du cache et la taille du cache. En outre, savoir que la plupart des données sont des pages dynamiques qui ne seront pas placées en mémoire est un facteur déterminant pour le réglage de Caching Proxy.
L'analyse des caractéristiques du trafic permet de déterminer si l'utilisation d'un cache mémoire ou d'un cache disque peut optimiser les performances de votre cache. De même, une bonne connaissance de ces caractéristiques permet de déterminer si l'utilisation de la fonction de cache dynamique de Caching Proxy engendrera une amélioration des performances.
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 employé 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 employé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 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 conjointement avec des hôtes de données, comme WebSphere Application Server, ou avec le composant Caching Proxy de Application Server, le composant Load Balancer de Application Server permet d'augmenter la disponibilité et l'évolutivité de votre réseau. Présentation des composants Edge de WebSphere Application Server fournit une présentation de ces composants Edge. Utilisé par les réseaux d'entreprise, Load Balancer est installé entre l'Internet et les serveurs dorsaux. Load Balancer fait office de point de présence unique de l'entreprise sur Internet, même si cette dernière utilise plusieurs serveurs dorsaux en raison d'une forte demande ou d'une grande quantité de données.
La disponibilité est assurée par l'équilibrage de charge et le support de pannes.
IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :
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 élaborée d'équilibrage de la charge de plusieurs hôtes de données consiste à utiliser le composant Dispatcher de Load Balancer, comme l'illustre la figure 5. Dans cette configuration, tous les hôtes de données (machines associées au chiffre 5) stockent les mêmes données. Ils sont définis de manière à former un cluster et l'une des interfaces réseau de la machine Load Balancer (4) reçoit un nom d'hôte et une adresse IP dédiés au cluster. Lorsqu'un utilisateur final travaillant sur l'une des machines repérées par 1 demande le fichier X, la demande traverse Internet (2) et pénètre sur le réseau interne de l'entreprise via sa passerelle Internet (3). Le composant Dispatcher intercepte la demande car son URL comporte le nom d'hôte et l'adresse IP de ce composant. Le composant Dispatcher détermine quel est l'hôte du cluster le plus apte à satisfaire la demande et dirige celle-ci sur cet hôte qui, lorsque la méthode de transfert MAC est configurée, renvoie le fichier X directement au client (le fichier X ne traverse donc pas Load Balancer).
Légende : 1--Client 2--Internet 3--Routeur/passerelle 4--Dispatcher 5--Hôte de donnéesPar défaut, le composant Dispatcher applique la technique de permutation circulaire comme DNS et, même ainsi, comble de nombreuses lacunes de DNS. Contrairement à DNS, il contrôle la disponibilité et l'accessibilité d'un hôte de données et cesse de diriger les clients sur cet hôte s'il n'est pas disponible. Qui plus est, il prend en compte la charge actuelle supportée par les hôtes de données en effectuant le suivi des connexions nouvelles, actives et terminées. Vous pouvez optimiser davantage l'équilibrage de charge en activant les composants de conseil et de gestion facultatifs de Load Balancer qui effectuent un suivi encore plus précis de l'état d'un hôte de données et incorporent les informations complémentaires dans le processus de décision d'équilibrage de charge. Le gestionnaire permet d'affecter des poids différents aux divers facteurs utilisés dans le processus de décision, ce qui permet de personnaliser davantage l'équilibrage de la charge sur votre site.
Dispatcher de Load Balancer permet également de réaliser un équilibrage de charge entre plusieurs machines Caching Proxy. Si le site Web de votre entreprise est très apprécié, la demande de contenu peut excéder la capacité d'un serveur proxy unique et potentiellement diminuer les performances du serveur proxy.
Les différents Caching Proxy peuvent alors agir comme proxy pour un seul hôte de données (comme dans la configuration décrite à la figure 1), mais si la fréquentation intense de votre site nécessite plusieurs serveurs proxy, vous aurez également besoin de plusieurs hôtes de données dont vous équilibrerez les charges à l'aide de Load Balancer (voir la figure 6. Le composantDispatcher 4 équilibre la charge d'un cluster de deux serveurs proxy (5), et le composant Dispatcher 7 équilibre la charge d'un cluster de trois hôtes de données (8).
Légende : 1--Client 2--Internet 3--Routeur/passerelle 4--Dispatcher 5--serveur proxy 6--Cache 7--Dispatcher 8--Hôte de donnéesLe nom d'hôte du cluster du composant Dispatcher 4 est le nom d'hôte qui apparaît dans les URL des données Web de l'entreprise (il s'agit du nom du site Web, tel qu'il apparaît sur Internet). Le nom d'hôte du cluster du composant Dispatcher 7 est invisible sur Internet et peut prendre la valeur de votre choix. A titre d'exemple, pour ABC Corporation, le nom d'hôte du composant Dispatcher 4 pourrait être www.abc.com, alors que le composant Dispatcher 7 serait du type http-balancer.abc.com.
Supposez qu'un navigateur de l'une des machines clientes 1 doive accéder au fichier X stocké sur les serveurs de données 8. La demande HTTP traverse Internet (2) et pénètre sur le réseau interne de l'entreprise au niveau de la passerelle (3). Le routeur achemine la demande au composant Dispatcher 4 qui la transmet au serveur proxy (5) qui est actuellement le mieux à même de la traiter conformément à l'algorithme d'équilibrage de charge. Si le serveur proxy dispose du fichier X dans sa mémoire cache (6), il le renvoie directement au navigateur, en contournant le composant Dispatcher 4.
Si le serveur proxy ne possède aucune copie du fichier X dans sa mémoire cache, il crée une nouvelle demande contenant son nom d'hôte dans la zone d'origine de l'en-tête et l'envoie au composant Dispatcher 7. Le composant Load Balancer détermine quel hôte de données (8) est actuellement le mieux à même de satisfaire la demande et la dirige sur celui-ci. L'hôte de données extrait le fichier X de son lieu de stockage et le renvoie directement au serveur proxy, en contournant le composant Dispatcher 7. Le cas échéant, le serveur proxy stocke le fichier X en mémoire cache et l'achemine vers le navigateur, en contournant le composant Dispatcher 4.
Si vous fournissez un accès Internet à un grand nombre de clients, le risque est qu'ils génèrent plus de demandes d'accès que celles auxquelles peut répondre un seul proxy. Au fur et à mesure que Caching Proxy est surchargé de demandes, les clients risquent d'expérimenter des temps de réponse encore plus longs que s'ils passaient par un accès direct à Internet. Et en cas d'échec ou de non accessibilité de Caching Proxy suite à une défaillance du réseau, l'accès à Internet devient impossible. La solution consiste à installer plusieurs machines Caching Proxy et à utiliser le composant Dispatcher de Load Balancer pour équilibrer les charges entre elles.
Sans Dispatcher, vous pouvez fournir un véritable serveur proxy transparent avec plusieurs machines Caching Proxy uniquement si vos routeurs peuvent acheminer le même type de trafic à plusieurs modules Caching Proxy (non possible avec tous les routeurs). Un service de proxy d'acheminement traditionnel est possible sur plusieurs machines Caching Proxy sans Dispatcher, mais il est alors nécessairede configurer de façon explicite les navigateurs client pour qu'ils utilisent l'une des machines comme proxy principal. En cas d'échec,de surcharge ou d'inaccessibilité de celui-ci, les utilisateurs finals risquent de ne plus pouvoir accéder à Internet. Pour éviter cette situation, vous pouvez créer un fichier de configuration automatique de proxy (comme décrit dans Caching Proxy d'acheminement transparent (systèmes Linux uniquement)) qui oriente le navigateur vers un ou plusieurs proxies de mise en cache secondaires. Un fichier de configuration automatique de proxy ne gère pas l'équilibrage de charge entre plusieurs machines Caching Proxy ; par conséquent, si une machine reçoit beaucoup plus de demandes qu'une autre, ses performances risquent de se dégrader, avec des temps de réponse plus longs pour ses clients. Pour que les performances soient égales pour tous les clients, vous devez configurer l'utilisation de chaque proxy de mise en cache par un nombre de navigateurs sensiblement égal et suivre manuellement la distribution pour maintenir la charge à un niveau égal même si vous ajoutez ou supprimez des navigateurs.
La figure 7 présente une configuration réseau dans laquelle le composant Dispatcher équilibre la charge d'un cluster de machines Caching Proxy. L'une des interfaces réseau de la machine Dispatcher est configurée pour porter l'adresse IP et le nom d'hôte dédié du cluster. Les navigateurs client sont configurés pour diriger leurs demandes Internet vers le nom d'hôte du cluster. Par exemple, lorsqu'un navigateur sur l'une des machines client 1 doit accéder au fichier X sur un hôte de données (7), il dirige sa demande vers le nom d'hôte ou l'adresse du cluster, où Dispatcher (2) l'intercepte et la dirige vers la machine Caching Proxy adaptée (3). Cette dernière crée une nouvelle demande, la fait transiter par la passerelle de l'entreprise (5) et via Internet (6), et le cas échéant, stocke le fichier renvoyé dans son cache (4) comme décrit de façon plus détaillée dans Caching Proxy d'acheminement
Le composant Dispatcher détecte si l'une des machines Caching Proxy est indisponible et achemine automatiquement les demandes vers une autre. Vous pouvez ainsi arrêter une machine Caching Proxy à des fins de maintenance sans interrompre l'accès à Internet. Grâce aux nombreuses options de configuration de Dispatcher, vous pouvez contrôler les facteurs à prendre en compte pour la prise de décision en matière d'équilibrage de charge. Vous pouvez également installer des programmes Dispatcher auxiliaires sur les machines Caching Proxy pour surveiller leur statut et renvoyer les informations au Dispatcher. Pour plus de détails, voir le document WebSphere Application Server Load Balancer - Guide d'administration. L'utilisation de plusieurs serveurs proxy de mise en cache peut induire une inefficacité potentielle dans la mesure où plus d'un proxy peut mettre en cache le même fichier si différents clients le demandent via différentes machines Caching Proxy. Pour éliminer la redondance, vous pouvez configurer un accès RCA (Remote Cache Access) qui permet à tous les serveurs proxy d'un groupe défini de partager entre eux le contenu de leur cache. Les proxies de ce groupe utilisent tous le même algorithme pour déterminer lequel est responsable d'une adresse URL donnée. Lorsqu'un proxy intercepte une adresse URL dont il n'est pas responsable, il transmet la demande au proxy concerné. Ce dernier effectue le travail voulu, soit en extrayant le fichier voulu du cache ou en acheminant la requête vers l'hôte de données voulu et en mettant en cache le fichier renvoyé, le cas échéant. Le proxy concerné transmet ensuite le fichier au proxy d'origine qui le fournit à son tour à l'utilisateur final demandeur.
Dans le groupe RCA, si le proxy responsable d'une adresse URL donnée échoue, le proxy d'origine, qui a reçu la demande du client, accède directement à l'hôte de données (ou à un serveur proxy de mise en cache de secours, s'il est défini). Autrement dit, les utilisateurs peuvent accéder à des fichiers tant qu'au moins un serveur proxy du groupe RCA fonctionne correctement.
Cette configuration est adaptée pour les fortes demandes d'accès à Internet grâce au composant Dispatcher qui équilibre la charge de demandes entre plusieurs machines Caching Proxy. Un des problèmes potentiels réside dans le fait que Dispatcher constitue un point de défaillance unique. S'il échoue ou devient inaccessible suite à une panne réseau, les clients du navigateur ne peuvent pas atteindre les serveurs proxy de mise en cache ou Internet. La solution consiste à con figurer un autre Dispatcher qui fonctionne comme remplaçant de secours, comme décrit à la figure 8.
Ici, un navigateur s'exécutant sur l'une des machines 1 dirige normalement sa demande de fichier X vers le Dispatcher principal (2), lequel achemine la demande au Caching Proxy (4) séléctionné sur la base des critères d'équilibrage de charge du composant Dispatcher. Le proxy de mise en cache crée une nouvelle demande, la fait transiter par la passerelle de l'entreprise (6) et via Internet (7) jusqu'à l'hôte de données (8), et le cas échéant, stocke le fichier renvoyé dans son cache (5) (comme décrit de façon plus détaillée dans Caching Proxy d'acheminement).
Dans cette configuration, le Dispatcher de secours (3) n'effectue aucun équilibrage de charge tant que le Dispatcher principal est opérationnel. Les composants Dispatcher principal et de secours suivent leur état respectif en s'échangeant périodiquement des messages appelés signaux de présence.Si le composant Dispatcher de secours détecte que le composant principal est tombé en panne, il prend automatiquement la responsabilité d'équilibrer la charge en interceptant les demandes dirigées vers le nom d'hôte et l'adresse IP du composant principal.Il est également possible de configurer deux composants Dispatcher pour une haute disponibilité mutuelle. Dans ce cas, chacun des composants effectue l'équilibrage de charge pour un cluster distinct de serveurs proxy de mise en cache et agit simultanément comme dispositif de secours pour son homologue.Pour plus de détails, voir le document WebSphere Application Server Load Balancer - Guide d'administration.
En général, le composant Dispatcher ne consomme pas beaucoup de ressources de traitement ou de stockage, et d'autres applications peuvent s'exécuter sur la machine Dispatcher. Si une réduction des coûts de l'équipement est essentielle, il est même possible d'exécuter le composant Dispatcher de secours sur la même machine que le proxy de mise en cache.La figure 9 illustre une configuration de ce type, dans laquelle le composant Dispatcher de secours est exécuté sur la même machine (3) que le serveur proxy de mise en cache.
Load Balancer joue le rôle d'un point de présence unique pour les hôtes de données de votre entreprise. Vous diffusez le nom d'hôte et l'adresse du cluster dans DNS au lieu de ceux de l'hôte de données, ce qui vous protège contre d'éventuelles attaques et confère une certaine homogénéité au site Web de votre entreprise. Pour augmenter la disponibilité du site Web, n'hésitez pas à configurer un autre composant Load Balancer qui assurera le relais du composant Load Balancer principal, comme décrit à la figure 10. S'il tombe en panne ou devient inaccessible en raison d'un incident sur le réseau, les utilisateurs finals peuvent toujours accéder aux hôtes de données.
Légende : 1--Client 2--Internet 3--Routeur/passerelle 4--Dispatcher principal; 5--Dispatcher de secours 6--Hôte de donnéesEn situation normale, un navigateur fonctionnant sur l'une des machines associées au chiffre 1 dirige sa demande portant sur le fichier X vers le nom d'hôte de cluster assigné au composant Load Balancer principal (4). Le composant Dispatcher achemine la demande vers l'hôte de données (6) sélectionné en fonction des critères d'équilibrage de charge du composant Dispatcher. L'hôte de données envoie le fichier X directement au navigateur, en l'acheminant via la passerelle de l'entreprise (3) sur Internet (2), mais en contournant le composant Load Balancer.
Le composant Dispatcher de secours (5) n'effectue aucun équilibrage de charge tant que le composant principal est opérationnel. Les composants Dispatcher principal et de secours suivent leur état respectif en s'échangeant périodiquement des messages appelés signaux de présence. Si le composant Dispatcher de secours détecte que le composant principal est tombé en panne, il prend automatiquement la responsabilité d'équilibrer la charge en interceptant les demandes dirigées vers le nom d'hôte et l'adresse IP du composant principal.
Il est également possible de configurer deux composants Dispatcher pour une disponibilité mutuelle élevée. Dans ce cas, chacun des composants effectue l'équilibrage de charge pour un cluster distinct d'hôtes de données et agit simultanément comme dispositif de secours pour son homologue. (Sur les installations de Load Balancer pour IPv4 et IPv6, la haute disponibilité simple est prise en charge, mais pas la haute disponibilité mutuelle.)
En général, le composant Dispatcher consomme beaucoup de ressources de traitement ou de stockage, et d'autres applications peuvent s'exécuter sur la machine Load Balancer. Si une réduction des coûts de l'équipement est essentielle, il est même possible d'exécuter le composant Dispatcher de secours sur l'une des machines du cluster dont il équilibre la charge. La figure 11 illustre une configuration de ce type, dans laquelle le composant Dispatcher de secours est exécuté sur l'un des hôtes de données (5) du cluster.
Légende : 1--Client 2--Internet 3--Routeur/passerelle 4--Dispatcher principal 5--Dispatcher de secours et hôte de données 6--Hôte de donnéesIMPORTANT: Le composant CBR (routage CBR) est disponible sur toutes les plateformes prises en charge, sauf dans les cas suivants :
Par ailleurs, pour ce type d'installation, vous pouvez utiliser la méthode d'acheminement cbr du composant Dispatcher de Load Balancer pour assurer le routage basé sur contenu des requêtes HTTP et HTTPS sans utiliser Caching Proxy. Pour plus d'informations, voir le document WebSphere Application Server Load Balancer - Guide d'administration.
Load Balancer pour IPv4 et IPv6 prend en charge uniquement 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 Caching Proxy de Application Server, le composant Load Balancer de Application Server permet de distribuer des demandes à plusieurs serveurs dorsaux hébergeant des données différentes. Le Présentation des composants Edge de WebSphere Application Server fournit une présentation de ces Composants Edge.
Si le composant CBR (Content Based Routing) de Load Balancer est installé en même temps que le composant Caching Proxy, les demandes HTTP peuvent même être réparties en fonction d'une URL ou d'autres caractéristiques déterminées par un administrateur, ce qui élimine la nécessité de stocker des données identiques sur tous les serveurs dorsaux.
L'utilisation de CBR est particulièrement appropriée si vos serveurs Web doivent effectuer différentes fonctions ou offrir plusieurs types de services. A titre d'exemple, le site Web d'un détaillant en ligne doit d'une part afficher son catalogue, dont la majeure partie est statique, et d'autre part accepter les commandes, ce qui implique d'exécuter une application interactive, tel qu'un script CGI (Common Gateway Interface) pour accepter des numéros de référence et des informations client. Il est parfois plus efficace d'utiliser deux ensembles de machines distincts pour effectuer les différentes fonctions et d'employer CBR pour acheminer les divers types de trafic vers différentes machines. De la même façon, une entreprise peut utiliser CBR pour offrir aux acheteurs un meilleur service qu'aux visiteurs occasionnels de son site Web, en acheminant les demandes payées vers des serveurs Web plus puissants.
CBR achemine les demandes en fonction de règles que vous définissez. Le type de règle le plus connu est la règle de données qui dirige les demandes en fonction du chemin d'accès indiqué dans l'URL. Par exemple, ABC Corporation peut écrire des règles pour diriger les demandes portant sur l'URL http://www.abc.com/catalog_index.html vers un cluster de serveurs et http://www.abc.com/orders.html vers un autre cluster. Il existe aussi des règles qui acheminent les demandes selon l'adresse IP du client qui les a envoyées ou d'autres caractéristiques. Pour en savoir plus, reportez-vous aux chapitres relatifs à la configuration de CBR et aux fonctions CBR et Load Balancer avancées du manuel WebSphere Application Server Load Balancer - Guide d'administration. Si vous souhaitez consulter les définitions de syntaxe des règles, reportez-vous à l'annexe relative aux types de règles CBR dans le manuel WebSphere Application Server Load Balancer - Guide d'administration.
La figure 12 représente une configuration simple dans laquelle le composant CBR de Load Balancer et Caching Proxy sont installés ensemble sur la machine 4 et acheminent des demandes vers trois hôtes de données (6, 7 et 8) qui hébergent des données différentes. Lorsqu'un utilisateur final travaillant sur l'une des machines repérées par 1 demande le fichier X, la demande traverse Internet (2) et pénètre sur le réseau interne de l'entreprise via sa passerelle Internet (3). Le serveur proxy intercepte la demande et la transmet au composant CBR de la même machine qui analyse l'URL contenue dans la demande et détermine que l'hôte de données 6 héberge le fichier X. Le serveur proxy génère une nouvelle demande portant sur le fichier X et, si sa fonction de mise en mémoire cache est activée, détermine si le fichier peut être mis en mémoire cache lorsque l'hôte 6 le renvoie. Si tel est le cas, le serveur proxy stocke une copie du fichier dans sa mémoire cache (5) avant de la transmettre à l'utilisateur final. Le routage d'autres fichiers fonctionne de la même manière : les demandes portant sur le fichier Y sont transmises à l'hôte de données 7 et les demandes concernant le fichier Z sont transmises à l'hôte de données 8.
Légende : 1--Client 2--Internet 3--Routeur/passerelle 4--Caching Proxy et composant CBR de Load Balancer 5--Mémoire cache 6, 7, 8--Hôte de donnéesLa figure 13 présente une configuration plus complexe qui peut être adaptée à un détaillant en ligne. Le composant CBR de Load Balancer et le serveur proxy sont installés ensemble sur la machine 4 et acheminent les demandes vers deux machines Load Balancer. Le composant Load Balancer 6 équilibre la charge d'un cluster d'hôtes de données (8) qui héberge les données essentiellement statiques du catalogue du détaillant, tandis que le composant Load Balancer 7 équilibre la charge d'un cluster de serveurs Web qui traite les commandes (9).
Lorsqu'un utilisateur final travaillant sur l'une des machines associées au chiffre 1 accède à l'URL du catalogue du détaillant, la demande traverse Internet (2) et pénètre sur le réseau interne de l'entreprise via sa passerelle Internet (3). Le serveur proxy intercepte la demande et la transmet au composant CBR de la même machine qui analyse l'URL et détermine que la machine Load Balancer 6 la traitera. Le serveur proxy crée une nouvelle demande d'accès et l'envoie au composant Load Balancer, qui détermine quel hôte de données repéré par 8 est actuellement le mieux à même de traiter la demande (selon les critères que vous avez définis). Cet hôte de données transmet directement le contenu du catalogue au serveur proxy, en contournant le composant Load Balancer. Comme dans l'exemple précédent, le serveur proxy détermine si les données peuvent être mises en mémoire cache et les stocke dans sa mémoire cache (5), le cas échéant.
L'utilisateur final passe une commande en accédant à l'URL de commande du détaillant, probablement par l'intermédiaire d'un lien hypertexte dans le catalogue. La demande suit le même chemin que la demande d'accès au catalogue, sauf que le composant CBR de la machine 4 la dirige sur la machine Load Balancer 7. Cette dernière la transmet au serveur Web 9, le plus adapté, qui répond directement au serveur proxy. Les informations de commande étant généralement générées dynamiquement, le serveur proxy ne les met probablement pas en mémoire cache.
Légende : 1--Client 2--Internet 3--Routeur/passerelle 4--Caching Proxy et composant CBR de Load Balancer 5--Mémoire cache 6, 7--Load Balancer 8--Hôte de données 9--Serveur WebLa 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 partie propose des scénarios utilisant des composants Edge de IBM WebSphere Application Server. Ces solutions constituent des solutions architecturales testées et efficaces à haut niveau de performances, disponibilité, évolutivité et fiabilité.
Elle comporte les chapitres suivants :
Le site Web de commerce électronique de base est un réseau B2C. Dans la première phase de développement d'Internet, les entreprises avaient pour principale préoccupation d'être présentes sur le Web. Des informations d'entreprise et des catalogues de produits sont convertis dans des formats numériques et publiés sur le site Web. Les achats s'effectuent en fournissant adresses e-mail, numéros de téléphone et de télécopie, voire des formulaires automatiques. Il n'est cependant pas possible d'effectuer un shopping digne de ce nom. Toutes les transactions ont une latence inhérente car la commande doit être traitée manuellement.
Dans la deuxième phase, les entreprises suppriment cette latence et assouplissent le processus de vente en implémentant des paniers sécurisés pour des achats directs en ligne. La synchronisation avec des bases de données du stock et l'intégration avec des systèmes bancaires sont essentielles pour le traitement de transactions commerciales. Tout produit indisponible ne peut être ni vendu ni facturé au client. De même, un produit ne peut être prélevé du stock et livré à un client tant qu'il n'a pas fait l'objet d'une transaction financière valide.
Dans la troisième phase, le site Web d'entreprise évolue vers un site de présentation où le client reçoit des données personnalisées en fonction de son poste de travail et de ses choix.
Le scénario suivant inclut Load Balancer et Caching Proxy.
IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :
La figure 14 représente un petit site Web commercial de consultation rationnelle de catalogues. Toutes les demandes du client passent au travers d'un pare-feu avant d'être transmises à un Dispatcher qui les achemine vers un cluster de serveurs proxy dont les mémoires cache jouent le rôle de serveurs de remplacement pour les serveurs Web. Des serveurs de mesure sont associés aux serveurs proxy pour fournir des données d'équilibrage de charge au Dispatcher. Cet ensemble réduit la charge du réseau sur les serveurs Web et les protège de l'Internet.
La figure 15 représente la deuxième phase de l'évolution d'un site Web commercial offrant des fonctions de consultation efficace de catalogues, ainsi que des paniers électroniques sécurisés et rapides. Toutes les demandes des clients sont routées vers la branche appropriée du réseau par un Dispatcher séparant les demandes basée sur IP. Les demandes HTTP et les demandes HTTPS sont dirigées vers le site Web statique et le réseau d'achat respectivement. Le site Web statique principal est servi par un cluster de serveurs proxy avec des mémoires cache actives en tant que serveurs de remplacement pour les serveurs Web. Cette partie du réseau correspond au réseau de la première phase.
La partie commerce électronique du site Web est également servie par un cluster de serveurs proxy. Cependant, les noeuds Caching Proxy sont agrémentés de plusieurs modules de plug-in. Le protocole d'établissement de liaison SSL est déchargé vers une carte matérielle de chiffrement et l'authentification est effectuée à l'aide du plug-in Access Manager (anciennement Policy Director). Un plug-in Dynamic Caching réduit la charge de travail sur le serveur WebSphere Application Server en stockant les données courantes. Un plug-in sur le serveur d'applications invalide les objets dans Dynacache si nécessaire.
Toutes les applications de panier électronique sont liées à la base de données des clients qui a été utilisée pour authentifier l'utilisateur. Ainsi, l'utilisateur n'a pas besoin d'entrer des informations personnelles dans le système deux fois, une fois pour l'authentification et une autre pour faire des achats.
Ce réseau répartit le trafic selon l'utilisation du client et supprime l'authentification SSL intensive du processeur et les paniers électroniques du site Web principal. Ce site Web double permet à l'administrateur réseau d'adapter les divers serveurs afin de fournir des performances excellentes en fonction du rôle du serveur dans le réseau.
La figure 16 représente la troisième phase de l'évolution d'un réseau B2C quand le Web statique adopte une méthode de présentation dynamique. Le cluster de serveurs proxy a été amélioré pour supporter la mise en cache de données Web dynamiques et l'assemblage de fragments de page écrits conformément au protocole ESI (Edge Side Includes). Au lieu d'utiliser des mécanismes de SSI (Server-Side Includes) pour créer des pages Web sur les serveurs de données, puis de propager ces pages spécifiques sur le réseau, les mécanismes ESI permettent d'assembler des pages à partir de données résidant en mémoire cache, ce qui réduit la consommation de bande passante et les temps de réponse.
Les mécanismes ESI revêtent une importance particulière dans ce scénario car chaque client reçoit du site Web une page d'accueil personnalisée. Les éléments constitutifs de ces pages émanent d'un groupe de serveurs WebSphere Application Servers. Les serveurs d'applications contenant une logique métier sensible et liés à des bases de données sécuriséés sont protégés par un pare-feu.
La figure 17 représente une solution de banque en ligne similaire au réseau B2C décrite au Réseau B2C. Toutes les demandes client sont transmises, via le pare-feu, à un Dispatcher séparant le trafic conformément aux règles du protocole Internet. Des demandes HTTP sont transmises à un cluster de serveurs proxy avec mémoire cache jouant le rôle de serveurs de remplacement pour les serveurs Web. Des serveurs de mesure sont associés aux serveurs proxy pour fournir des données d'équilibrage de charge au Dispatcher. Cet ensemble réduit la charge du réseau sur les serveurs Web en plaçant une zone tampon supplémentaire entre eux et l'Internet.
Les demandes HTTPS sont transmises à un réseau sécurisé conçu pour fournir aux clients des informations financières personnelles et permettre les transactions bancaires en ligne. Un cluster de serveurs proxy améliorés assure l'évolutivité du site. Ces serveurs proxy supportent la mise en cache de données Web dynamiques et l'assemblage de fragments de page écrits conformément au protocole ESI (Edge Side Includes). Une carte de chiffrement gère les authentifications SSL, ce qui réduit de façon considérable le traitement requis de l'hôte du serveur proxy et Access Manager (anciennement Policy Director) achemine l'authentification client.
Plusieurs clusters de serveurs d'applications distribuent le traitement de demandes en séparant la logique métier, contenue dans des composants EJB, de la couche présentation, contenue dans des servlets et des fichiers JSP. Chaque cluster est géré par un serveur de session distinct.
Le scénario suivant inclut Load Balancer et Caching Proxy.
IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :
La figure 18 représente un réseau de portails Web conçu pour prendre en charge un volume de trafic important tout en fournissant au client un contenu personnalisé. Pour réduire la charge de traitement sur les différents serveurs, aucune partie du réseau n'achemine de trafic SSL. Du fait que le portail ne délivre pas de données sensibles, la sécurité n'est pas essentielle sur ce réseau. Il est important que les bases de données contenant les ID client, les mots de passe et les paramètres soient modérement sécurisées et protégées, mais cette exigence n'influe pas sur les performances du reste du site Web.
Toutes les demandes du client passent au travers d'un pare-feu avant d'être transmises à un Dispatcher qui les achemine vers un cluster de serveurs proxy dont les mémoires cache jouent le rôle de serveurs de remplacement pour les serveurs Web. Des serveurs de mesure sont associés aux serveurs proxy pour fournir des données d'équilibrage de charge au Dispatcher.
Le site Web dynamique véritable est un cluster de serveurs d'applications générant des fragments ESI transmis aux serveurs proxy pour assemblage. Chaque serveur d'applications effectue les opérations de construction du site Web nécessaires avec un niveau de sécurité minimal. Tous les serveurs d'applications sont identiques. Si un serveur d'applications tombe en panne, le serveur de session peut acheminer les demandes aux autres serveurs, ce qui confère une disponibilité élevée au site. Cette configuration permet également une adaptation rapide du site Web en cas de trafic excessif, avec, par exemple, l'hébergement d'un événement spécial par le portail. Il est possible de configurer rapidement des serveurs proxy et des serveurs d'applications supplémentaires sur le site.
Toutes les données statiques, tels que les fichiers graphiques et le texte brut, sont stockées sur des serveurs Web séparés, ce qui permet de les mettre à jour sans risquer d'endommager les serveurs d'applications les plus complexes.
Le scénario suivant inclut Load Balancer et Caching Proxy.
IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :
Cette partie contient les procédures permettant d'installer les Composants Edge.
Elle comporte les chapitres suivants :
Conditions requises pour les Composants Edge
Installation des Composants Edge à l'aide du programme d'installation
Installation de Caching Proxy à l'aide des outils de regroupement du système
Installation de Load Balancer à l'aide des outils de regroupement du système
Ce rubrique contient un lien vers les conditions matérielles et logicielles requises pour les Composants Edge et les instructions d'utilisation des navigateurs Web avec les formulaires Caching Proxy Configuration et administration et avec l'aide en ligne de Load Balancer.
Pour les informations sur les configurations matérielle et logicielle requises de la version 6.1 de WebSphere Application Server Edge Components, accédez à la page Web suivante : http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921.
Installation SDK : le SDK Java 2 s'installe automatiquement avec Load Balancer sur toutes les plateformes.
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 formulairessont affichés par le navigateur avec le jeu de caractères utilisé par le serveur proxy, en l'occurrence, en chinois. Toutefois, les formulaires peuvent ne pas apparaître correctement si le navigateur et son système d'exploitation sous-jacent ne sont pas configurés correctement pour afficher le jeu de caractères envoyé par le serveur proxy.
Sinon, si un poste de travail Windows prenant en charge le chinois est disponible pour une connexion à distance au serveur proxy, vous pouvez charger une version chinoise du navigateur Netscape sur le poste de travail Windows pour entrer les valeurs dans les formulaires. Cette seconde solution présente l'avantage de conserver pour l'administrateur une cohérence de langue d'interface.
Les jeux de caractères propres aux systèmes d'exploitation affectent grandement l'affichage de diverses langues, en particulier les caractères double octet, dans les navigateurs. Par exemple, un jeu de caractères chinois sous AIX ne s'affiche pas de la même façon qu'un jeu de caractères chinois sur des plateformes Windows. Par conséquent, certaines irrégularités peuvent apparaître dans le texte HTML et les applets Java des formulaires Configuration et administration. Seuls les navigateurs s'exécutant sur les systèmes d'exploitation Windows permettent un affichage correct.
Remarque sur le navigateur Mozilla 1.4 sur S/390 et PowerPC
Le plug-in Java installé avec Mozilla 1.4 doit être mis à jour vers la version 1.4.2 ou suivante pour afficher correctement les formulaires d'administration. Pour mettre à jour le plug-in, procédez comme suit :
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.
Ce rubrique fournit des instructions d'installation des Composants Edge à l'aide du programme d'installation.
Le SDK Java 2 s'installe automatiquement avec Load Balancer sur toutes les plateformes.
Après l'installation, les scripts du module de Caching Proxy tentent de démarrer le serveur proxy à l'aide de la configuration par défaut. Si le port 80 est en cours d'utilisation, par un autre serveur Web par exemple, le serveur proxy ne pourra pas démarrer.
IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :
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 (...).
Lors d'une installation à partir du CD, utilisez le programme d'installation pour installer les Composants Edge sur des systèmes Linux et UNIX :
# ./installLa fenêtre Bienvenue s'affiche.
Le programme d'installation commence à installer les Composants Edge sélectionnés ainsi que 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 (...).
On Red Hat Linux 3.0 Update 3 : Lors de l'exécution du programme d'installation du module Edge Components, les boutons ne sont pas opérationnels si le panneau de l'interface utilisateur est agrandi au maximum, puis restauré. Pour résoudre cet incident :
Sur les systèmes Linux et UNIX : Si le programme de configuration est utilisé pour installer le module Edge Components, le programme de désinstallation de l'interface utilisateur peut servir à le désinstaller. Toutefois, ce programme de désinstallation ne permet pas de désinstaller un module de mise à jour installé à l'aide de commandes natives. Vous devez commencer par désinstaller le module de mise à jour à l'aide des commandes natives (commandes du système d'exploitation) avant de désinstaller des composants à l'aide du programme de désinstallation de l'interface utilisateur.
Pour plus d'informations sur l'utilisation des commandes natives, voirInstallation de Caching Proxy à l'aide des outils de regroupement du système et Installation de Load Balancer à l'aide des outils de regroupement du système.
Ce rubrique fournit des instructions d'installation de Caching Proxy à l'aide des outils d'installation et de gestion de modules système.
Après l'installation, les scripts du module de Caching Proxy tentent de démarrer le serveur proxy à l'aide de la configuration par défaut. Si le port 80 est en cours d'utilisation, par un autre serveur Web par exemple, le serveur proxy ne pourra pas démarrer.
IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :
A l'aide du système d'installation de module de votre système d'exploitation, installez les modules dans l'ordre stipulé dans le tableau 2. La procédure ci-après détaille les étapes à suivre pour remplir cette tâche.
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
Composant | Modules installés (dans l'ordre conseillé) |
---|---|
Caching Proxy |
|
documentation des composants Edge |
doc-en_US1 |
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.
Ce rubrique décrit l'installation de Load Balancer sur des systèmes AIX, HP-UX, Linux et Solaris :
Suivant le type d'installation, les modules du composant Load Balancer listés dans cette section ne sont pas tous fournis.
L'ordre d'installation recommandé des modules diffère légèrement pour les installations de Load Balancer pour IPv4 et IPv6. Il est important de noter qu'il convient d'installer le module du composant d'administration après le module du composant Dispatcher. L'ordre recommandé d'installation des modules de Load Balancer pour IPv4 et IPv6 avec les outils système est le suivant : éléments de base, licence, composant Dispatcher, administration, documentation, Metric Server
Si vous effectuez une migration à partir d'une version précédente du composant Load Balancer ou que vous réinstallez un système d'exploitation, vous pouvez sauvegarder les fichiers de configuration ou les fichiers scripts précédents de Load Balancer avant l'installation.
Si vous vous déconnectez d'une machine après l'installation de Load Balancer, vous devrez redémarrer tous les services Load Balancer quand vous vous reconnecterez.
Le tableau 5 répertorie les ensembles de fichiers AIX pour Load Balancer et l'ordre d'installation recommandé à l'aide de l'outil d'installation système des modules.
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 |
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 ibmlbou, pour des versions précédentes, entrez la commande suivante :
installp -u ibmndPour désinstaller des groupes 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 for AIX car SMIT garantit que tous les messages sont installés automatiquement.
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Modules | Commandes |
---|---|
Base | installp -acXgd unité ibmlb.base.rte |
Administration (avec messages) | installp -acXgd unité ibmlb.admin.rte ibmlb.msg.langue.admin |
Pilote de périphérique | installp -acXgd unité ibmlb.lb.driver |
Licence | installp -acXgd unité ibmlb.lb.license |
Composants Load Balancer (avec messages). Comporte : Dispatcher, CBR, Site Selector, Cisco CSS Controller et Nortel Alteon Controller |
installp -acXgd unité ibmlb.composant.rte ibmlb.msg.langue.lb |
Documents (avec messages) | installp -acXgd unité ibmlb.doc.rte ibmlb.msg.en_US.lb |
Metric Server | installp -acXgd unité ibmlb.ms.rte |
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 :
Cette section traite de l'installation de Load Balancer sous HP-UX à l'aide du CD 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. Ensuite, pour désinstaller Load Balancer, reportez-vous à la rubrique Instructions de désinstallation des packages.
Le tableau 7 répertorie les noms des packages d'installation de Load Balancer et l'ordre suivant lequel il est recommandé de les installer à l'aide de l'outil d'installation de package du système.
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 remplir cette tâche.
su - root Mot de passe : mot_de_passe
Exécutez la commande d'installation
swinstall -s /source nom_packagesource
correspondant au chemin de répertoire absolu du package et nom_package, au nom du package.
Par exemple, la commande suivante permet d'installer le package de base de Load Balancer (ibmlb.base), si vous l'installez à partir de la racine du CD :
swinstall -s /source ibmlb.base
Pour installer tous les packages pour Load Balancer, lancez la commande suivante, si vous l'installez à partir de la racine du CD :
swinstall -s /source ibmlb
Exécutez la commande swlist pour répertorier tous les packages que vous avez installés. Par exemple,
swlist -l fileset ibmlb
Utilisez la commande swremove pour désinstaller les packages. Les packages doivent être supprimés dans l'ordre inverse de celui de l'installation. Par exemple, exécutez les commandes suivantes :
swremove ibmlbPour ne désinstaller qu'un seul package (par exemple, le contrôleur Cisco CSS)
swremove ibmlb.cco
Les chemins d'installation de Load Balancer sont les suivants :
Cette section traite de l'installation de Load Balancer sous Linux à l'aide du CD Edge Components.
Avant d'installer Load Balancer, vérifiez les points suivants :
rpm -e pkgnameLes 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 package.rpm
Systèmes Red Hat Linux : A cause d'un problème Red Hat Linux connu, vous devrez également supprimer les fichiers _db* RPM, sous peine de générer une erreur.
Il est important d'installer les modules dans l'ordre figurant dans la liste de modules suivante requis pour chaque composant.
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.
Cette section traite de l'installation de Load Balancer sous Solaris à l'aide du CD Edge Components.
Avant de commencer la procédure d'installation, assurez-vous que vous êtes connecté en tant que root et que toute version précédente du produit est désinstallée.
Pour effectuer la désinstallation, assurez-vous que tous les modules d'exécution et les serveurs sont arrêtés. Puis, entrez la commande suivante :
pkgrm pkgname
pkgadd -d cheminoù -d chemin est le nom d'unité du lecteur de CD-ROM ou le répertoire du disque dur sur lequel réside le module ; par exemple : -d /cdrom/cdrom0/.
Voici la liste des packages affichés et leur ordre d'installation recommandé.
Le module documentation (ibmlbdoc.doc) contient uniquement de l'anglais. Vous trouverez les traductions de la documentation Edge Components sur le site Web suivant : www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Pour installer tous les modules, il suffit de taper all, puis appuyez sur Entrée. Pour installer des composants spécifiques, entrez le ou les noms correspondant aux modules à installer, séparés par un espace ou une virgule, puis appuyez sur Entrée. Le cas échéant, vous serez invité à modifier les autorisations sur des répertoires ou des fichiers existants. Appuyez sur Entrée ou tapez yes. Vous devez installer les modules requis (car le programme d'installation propose une liste alphabétique de modules et non la liste des dépendances). Si vous tapez all, puis répondez yes à toutes les invites, l'installation se termine avec succès.
Pour n'installer que le composant Dispatcher avec la documentation et Metric Server, vous devez installer : ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc et ibmlbms.
pkginfo | grep ibm
Les chemins d'installation de Load Balancer sont les suivants :
La présente partie comporte les procédures permettant de créer différents réseaux de démonstration à l'aide des Composants Edge. Ces réseaux ne sont pas conçus pour être utilisés dans des environnements de production. Le processus de configuration initiale d'un réseau permet aux administrateurs ne connaissant pas bien ce produit de mieux comprendre un grand nombre de concepts. Pour obtenir une présentation complète des fonctions de tous les composants ainsi que des informations de configuration détaillées, reportez-vous aux documents Caching Proxy - Guide d'administration et Load Balancer - Guide d'administration.
Les procédures permettent à n'importe quel ordinateur pris en charge par le composant d'être utilisé dans n'importe quel noeud.
Elle comporte les chapitres suivants :
Construction d'un réseau Caching Proxy.
Construction d'un réseau Load Balancer.
La figure 19 montre un réseau de serveur proxy de base utilisant trois systèmes informatiques situés sur trois noeuds de réseau. Ce réseau lie le serveur proxy à un hôte de données dédié (IBM HTTP Server), qui se trouve sur le serveur 2, le serveur proxy fournit des informations à l'hôte. Sur la figure, le réseau Internet se trouve maintenant entre le poste de travail et le serveur 1.
IMPORTANT : Caching Proxy est disponible sur toutes les installations de composants Edge, sauf dans les cas suivants :
Pour construire un réseau de Caching Proxy, suivez les procédures dans l'ordre indiqué :
Les systèmes et logiciels suivants sont requis :
Installez et configurez Caching Proxy comme suit :
# 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 Caching Proxy comme suit :
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 représente un réseau Load Balancer de base comportant trois postes de travail connectés localement à l'aide de la méthode de transfert MAC du composant Dispatcher afin d'équilibrer le trafic Web entre deux serveurs Web. La configuration est similaire dans le cadre de l'équilibrage de charge de trafic TCP ou de trafic d'application UDP sans état.
Pour construire un réseau de Load Balancer, suivez les procédures dans l'ordre indiqué :
Les systèmes et logiciels suivants sont requis :
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 |
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 www.entreprise.com 127.0.0.1 up
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 charge à présent l'équilibrage de charge basé sur les performances 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.
IMPORTANT : Avec l'installation de Load Balancer pour IPv4 et IPv6, la syntaxe de la commande Dispatcher (dscontrol) est identique, avec une exception importante. Le délimiteur des commandes dscontrol est un symbole at ( @) et non le signe deux-points (:). (Il était nécessaire de définir un délimiteur qui ne soit pas le signe deux-points car le format IPv6 utilise ce signe de ponctuation dans son schéma d'adressage.)
Exemple (provenant d'un exemple de configuration précédent de Dispatcher)
dscontrol port add www.company.com@80
dscontrol server add www.company.com@80@serveur2.entreprise.com
dscontrol server add www.company.com@80@serveur3.entreprise.com
Pour plus d'informations, si vous utilisez une installation Load Balancer pour IPv4 et IPv6, consultez le chapitre sur le déploiement de Dispatcher sur Load Balancer pour IPv4 et IPv6, qui contient des informations sur les limitations et les différences de configuration, dans le document WebSphere Application Server Load Balancer - Guide d'administration.
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 comporte les panneaux suivants :
Pour démarrer l'interface graphique utilisateur, procédez comme suit :
dsserver