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 d'acheminement MAC est configurée, renvoie le fichier X directement au client (le fichier X ne traverse donc pas Load Balancer).
Par défaut, le composant Dispatcher applique la technique de permutation circulaire comme DNS et, même ainsi, comble de nombreuses lacunes de DNS. Contrairement à DNS, il contrôle la disponibilité et l'accessibilité d'un hôte de données et cesse de diriger les clients sur cet hôte s'il n'est pas disponible. Qui plus est, il prend en compte la charge actuelle supportée par les hôtes de données en effectuant le suivi des connexions nouvelles, actives et terminées. Vous pouvez optimiser davantage l'équilibrage de charge en activant les composants de conseil et de gestion facultatifs de Load Balancer qui effectuent un suivi encore plus précis de l'état d'un hôte de données et incorporent les informations complémentaires dans le processus de décision d'équilibrage de charge. Le gestionnaire permet d'affecter des poids différents aux divers facteurs utilisés dans le processus de décision, ce qui permet de personnaliser davantage l'équilibrage de la charge sur votre site.
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).
Le nom d'hôte du cluster du composant Dispatcher 4 est le nom d'hôte qui apparaît dans les URL des données Web de l'entreprise (il s'agit du nom du site Web, tel qu'il apparaît sur Internet). Le nom d'hôte du cluster du composant Dispatcher 7 est invisible sur Internet et peut prendre la valeur de votre choix. A titre d'exemple, pour ABC Corporation, le nom d'hôte du composant Dispatcher 4 pourrait être www.abc.com, alors que le composant Dispatcher 7 serait du type http-balancer.abc.com.
Supposez qu'un navigateur de l'une des machines clientes 1 doive accéder au fichier X stocké sur les serveurs de données 8. La demande HTTP traverse Internet (2) et pénètre sur le réseau interne de l'entreprise au niveau de la passerelle (3). Le routeur achemine la demande au composant Dispatcher 4 qui la transmet au serveur proxy (5) qui est actuellement le mieux à même de la traiter conformément à l'algorithme d'équilibrage de charge. Si le serveur proxy dispose du fichier X dans sa mémoire cache (6), il le renvoie directement au navigateur, en contournant le composant Dispatcher 4.
Si le serveur proxy ne possède aucune copie du fichier X dans sa mémoire cache, il crée une nouvelle demande contenant son nom d'hôte dans la zone d'origine de l'en-tête et l'envoie au composant Dispatcher 7. Le composant Load Balancer détermine quel hôte de données (8) est actuellement le mieux à même de satisfaire la demande et la dirige sur celui-ci. L'hôte de données extrait le fichier X de son lieu de stockage et le renvoie directement au serveur proxy, en contournant le composant Dispatcher 7. Le cas échéant, le serveur proxy stocke le fichier X en mémoire cache et l'achemine vers le navigateur, en contournant le composant Dispatcher 4.
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écessaire de configurer de façon explicite les navigateurs client pour qu'ils utilisent l'une des machines comme proxy principal. En cas d'échec,de surcharge ou d'inaccessibilité de celui-ci, les utilisateurs finals risquent de ne plus pouvoir accéder à Internet. Pour éviter cette situation, vous pouvez créer un fichier de configuration automatique de proxy (comme décrit dans Caching Proxy d'acheminement transparent (systèmes Linux uniquement)) qui oriente le navigateur vers un ou plusieurs proxys 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 proxys 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 à configurer un autre Dispatcher qui fonctionne comme remplaçant de secours, comme décrit sur 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électionné 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 composant Dispatcher de secours (3) n'effectue aucun équilibrage de charge tant que le composant 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.