Le présent chapitre décrit les aspects que l'administrateur de réseau doit prendre en compte avant d'installer et de configurer le composant Dispatcher.
Ce chapitre contient les sections suivantes :
Dispatcher se compose des fonctions suivantes :
Dispatcher fournit également des conseillers qui n'échangent pas d'informations relatives aux protocoles, tels que le conseiller DB2 qui indique l'état des serveurs DB2 et le conseiller ping qui indique si le serveur répond à une commande ping. Pour connaître la liste complète des conseillers, voir Liste des conseillers.
Vous avez également la possibilité de développer vos propres conseillers (voir Création de conseillers personnalisés).
L'utilisation des conseillers est facultative mais recommandée.
Les trois fonctions clés de Dispatcher (l'exécuteur, le gestionnaire et les conseillers) agissent en collaboration pour équilibrer et répartir entre les serveurs les requêtes réceptionnées. Outre la gestion des requêtes d'équilibrage de charge, l'exécuteur contrôle le nombre de nouvelles connexions, de connexions actives et de connexions terminées. Il assure également le retrait des connexions terminées ou réinitialisées et transmet ces informations au gestionnaire.
Le gestionnaire recueille les informations transmises par l'exécuteur, les conseillers et par tout programme de contrôle tel que Metric Server. Sur la base de ces informations, le gestionnaire ajuste les capacités des machines serveurs, pour chaque port, et transmet ces données à l'exécuteur qui en tient compte pour l'équilibrage de charge des nouvelles connexions.
Les conseillers contrôlent chaque serveur relié au port dont ils ont la charge afin de déterminer leur temps de réponse et leur disponibilité, puis retournent ces informations au gestionnaire. Les conseillers détectent également si un serveur est opérationnel ou non. Sans la contribution du gestionnaire et des conseillers, l'exécuteur assure une planification circulaire basée sur les capacités courantes des serveurs.
Avec Dispatcher, vous pouvez choisir l'une des trois méthodes d'acheminement spécifiées au niveau du port : acheminement MAC, acheminement NAT/NAPT ou acheminement CBR (routage par contenu).
La méthode d'acheminement MAC de Dispatcher (qui est la méthode d'acheminement par défaut) permet d'équilibrer la charge de la demande entrante sur le serveur sélectionné et de faire en sorte que le serveur renvoie une réponse directement au client sans impliquer le composant Dispatcher. Ainsi, Dispatcher se contente de surveiller les flux entrants du client vers le serveur. Il n'effectue aucun contrôle des transmissions en sortie, du serveur vers le client. Cet aspect réduit sensiblement son impact sur les performances des applications et permet même d'accroître celles du réseau.
La méthode d'acheminement peut être sélectionnée lors de l'ajout d'un port à l'aide de la commande dscontrol port add cluster:port method valeur. La valeur de la méthode d'acheminement par défaut est mac. Vous ne pouvez spécifier le paramètre method que lorsque le port est ajouté. Une fois le port ajouté, vous ne pouvez pas modifier les paramètres de la méthode d'acheminement. Pour plus d'informations, voir dscontrol port — Configuration des ports.
Restriction sous Linux : les systèmes Linux emploient un modèle fondé sur l'hôte pour afficher les adresses matérielles sous la forme d'adresses IP à l'aide du protocole ARP. Ce modèle n'est pas compatible avec les conditions requises par le serveur dorsal ou le serveur co-implanté à haute disponibilité pour la prise en charge de la méthode d'acheminement MAC de Load Balancer. Pour modifier le comportement du système Linux afin de le rendre compatible avec l'acheminement MAC de Load Balancer, voir les solutions présentées dans Solutions alternatives pour l'affectation d'alias à l'unité de bouclage sous Linux lors de l'utilisation de la méthode d'acheminement MAC de Load Balancer.
Restriction sous Linux lors de l'utilisation de serveurs zSeries ou S/390 : Il existe des limitations lorsque vous utilisez des serveurs zSeries ou S/390 dotés de cartes OSA (Open System Adapter). Pour des solutions possibles, voir Incident : Sous Linux, la configuration de Dispatcher est limitée lorsque vous utilisez des serveurs zSeries ou S/390 dotés de cartes OSA (Open System Adapter).
Si vous utilisez NAT ou NAPT, il n'est pas nécessaire que les serveurs d'équilibrage de charge se trouvent sur un réseau local. Si vous préférez disposer de serveurs à distance, utilisez la méthode d'acheminement NAT plutôt que la technique d'encapsulation GRE/WAN. Vous pouvez également utiliser la fonction NAPT pour accéder à plusieurs démons de serveur situés sur chaque machine serveur faisant l'objet d'un équilibrage de charge, où chaque démon écoute sur un port unique.
Vous pouvez configurer un serveur à plusieurs démons de deux façons différentes.
L'application fonctionne bien avec des protocoles de niveau supérieur tels que HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet, etc.
Restrictions :
Vous avez besoin de trois adresses IP pour la machine Dispatcher : l'adresse nfa, l'adresse de cluster et l'adresse de retour. Pour implémenter NAT/NAPT, procédez comme suit (voir également Etapes de configuration des méthodes d'acheminement nat ou cbr de Dispatcher) :
dscontrol server add cluster:port:serveur mapport valeur returnaddress adresseretour router adresseretour
Mappe le numéro du port de destination de la demande client (pour Dispatcher) au numéro de port du serveur que Dispatcher utilise pour équilibrer la charge de la demande du client. Mapport permet à Load Balancer de recevoir une demande de client sur un port et de la transmettre à un autre port sur la machine serveur. Le paramètre mapport permet d'équilibrer la charge des demandes d'un client sur une machine serveur sur laquelle peuvent s'exécuter plusieurs démons serveur. La valeur par défaut du paramètre mapport est le numéro de port de destination de la demande du client.
L'adresse retour correspond à une adresse ou à un nom d'hôte unique que vous configurez sur la machine Dispatcher. Dispatcher utilise l'adresse de retour comme adresse source lors de l'équilibrage de charge de la demande du client sur le serveur. Elle permet de garantir que le serveur renvoie le paquet à la machine Dispatcher, au lieu de l'envoyer directement au client. (Dispatcher transmettra ensuite le paquet IP au client.) Vous devez indiquer la valeur d'adresse de retour lors de l'ajout du serveur. Vous ne pouvez pas modifier l'adresse de retour sauf si vous supprimez le serveur et que vous l'ajoutez à nouveau. L'adresse de retour ne peut pas être identique à l'adresse de cluster, de serveur ou NFA.
Lorsque vous utilisez les méthodes d'acheminement nat ou cbr, vous devez définir une adresse de retour permettant la communication entre Load Balancer et les serveurs dorsaux. Le nombre de connexions que Load Balancer peut maintenir avec le serveur dorsal est limité par le nombre d'adresses de retour définies. Load Balancer utilise des ports basés uniquement sur les adresses de retour et non pas sur la combinaison adresse de retour et serveur. Les connexions supplémentaires échouent, lorsque tous les ports disponibles sont occupés. Dans un environnement occupé, utilisez plusieurs adresses de retour afin d'éviter le problème de disponibilité des ports.
Adresse du routeur vers le serveur distant. S'il s'agit d'un serveur rattaché en local, entrez son adresse, sauf s'il réside sur la même machine que Load Balancer. Dans ce cas, continuez à utiliser l'adresse réelle du routeur.
Le composant Dispatcher permet d'exécuter la fonction CBR (content-based routing) pour HTTP (avec la règle de type de contenu) et HTTPS (avec l'affinité des ID de session SSL) sans Caching Proxy. Pour le trafic HTTP et HTTPS, la méthode d'acheminement cbr du composant Dispatcher peut fournir une fonction CBR (content-based routing) plus rapide que le composant CBR qui nécessite le module Caching Proxy.
Pour HTTP : La sélection du serveur, pour fonction CBR de Dispatcher, est effectuée sur la base du contenu d'une adresse URL ou d'un en-tête HTTP. Cette option est configurée à l'aide du type de règle "Contenu". Lors de la configuration de la règle de contenu, spécifiez la chaîne de recherche "pattern" et un ensemble de serveurs pour la règle. Lors du traitement d'une nouvelle demande entrante, cette règle compare la chaîne indiquée à l'URL du client ou à l'en-tête HTTP spécifié dans la demande du client.
Si Dispatcher trouve la chaîne dans la demande du client, il transmet la demande à l'un des serveurs de la règle. Dispatcher achemine ensuite les données de la réponse du serveur vers le client (méthode d'acheminement cbr).
Si Dispatcher ne trouve pas la chaîne dans la demande du client, il ne sélectionne pas de serveur dans l'ensemble de serveurs de la règle.
Pour HTTPS (SSL) : L'acheminement CBR (content-based routing) de Dispatcher basée sur la zone de session SSL ID de la demande client. Avec SSL, une demande client contient l'ID session SSL d'une session antérieure, et les serveurs gèrent une cache de leurs connexions SSL précédentes. L'affinité de l'ID de session SSL de Dispatcher permet au client et au serveur d'établir une nouvelle connexion à l'aide des paramètres de sécurité de la connexion précédente au serveur. En éliminant la renégociation des paramètres de sécurité SSL, comme les clés partagées et les algorithmes de chiffrement, les serveurs sauvegardent des cycles CPU et le client obtient une réponse plus rapidement. Pour activer l'affinité de l'ID de session SSL : le type de protocole indiqué pour le port doit être SSL et le délai de maintien de routage du port doit être associé à une valeur autre que zéro. Si le délai de maintien de routage est dépassé, le client peut être envoyé à un autre serveur.
Vous avez besoin de trois adresses IP pour la machine Dispatcher : l'adresse nfa, l'adresse de cluster et l'adresse de retour. Pour implémenter la fonction CBR de Dispatcher, procédez aux opérations ci-dessous (voir également Etapes de configuration des méthodes d'acheminement nat ou cbr de Dispatcher):
dscontrol server add cluster:port:serveur mapport valeur returnaddress adresseretour router adresseretour
dscontrol rule 125.22.22.03:80:contentRule1 type content pattern motif
où masque indique le masque à utiliser pour une règle de type de contenu. Pour plus d'informations sur le type de règle de contenu, voir Utilisation de règles basées sur le contenu des demandes. Pour plus d'informations sur les expressions valides de masque, voir Annexe B. Syntaxe des règles de contenu (modèle).
Vous avez besoin d'au moins trois adresses IP pour la machine Dispatcher. Pour la figure 12, les étapes minimales de configuration des méthodes nat ou cbr de Dispatcher sont les suivantes :
1. Démarrage de l'exécuteur
dscontrol executor start
2. Définition de la passerelle client
dscontrol executor set clientgateway 1.2.3.5
REMARQUE : si votre sous-réseau ne dispose pas de routeur local, vous devez
configurer une machine pour l'acheminement des adresses IP et l'utiliser comme
clientgateway. Reportez-vous à la documentation de votre système d'exploitation
pour déterminer la manière d'activer l'acheminement des adresses IP.
3. Définition de l'adresse de cluster
dscontrol cluster add 1.2.3.44
4. Configuration de l'adresse de cluster
dscontrol executor configure 1.2.3.44
5. Définition du port avec une méthode nat ou cbr
dscontrol port add 1.2.3.44:80 method nat
or
dscontrol port add 1.2.3.44:80 method cbr protocol http
6. Configuration d'une adresse de retour alias sur Load Balancer (à l'aide de la carte ethernet 0)
NOTE : Sur les systèmes Linux, vous n'avez pas besoin de créer un alias pour l'adresse de retour si vous utilisez
la méthode de transfert nat sur une machine co-implantée.
dscontrol executor configure 10.10.10.99
ou utilisez la commande ifconfig (pour Linux ou UNIX uniquement) :
sous AIX : ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0
HP-UX : ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up
sous Linux : ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up
Solaris : ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up
7. Définition des serveurs dorsaux
dscontrol server add 1.2.3.4:80:192.10.10.10
router 10.10.10.6 returnaddress 10.10.10.99
La passerelle client (1.2.3.5) correspond à l'adresse du routeur 1 entre Load Balancer et le client. Router (10.10.10.6) correspond à l'adresse du routeur 2 entre Load Balancer et le serveur dorsal. Si vous n'êtes pas sûr de l'adresse de la passerelle client ou du routeur 2, vous pouvez utiliser un programme traceroute avec l'adresse du client (ou du serveur) pour déterminer l'adresse du routeur. La syntaxe d'appel de ce programme varie en fonction du système d'exploitation utilisé. Pour plus d'informations sur ce programme, consultez la documentation afférente à votre programme d'exploitation.
Si le serveur se trouve sur le même sous-réseau que Load Balancer (c'est-à-dire si traceroute ne désigne aucun routeur), entrez l'adresse du serveur comme adresse de routeur. Cependant, si le serveur réside sur la même machine que Load Balancer, entrez plutôt l'adresse du routeur que celle du serveur. L'adresse du routeur est celle utilisée dans la commande "server add", sur la machine Load Balancer, à l'étape 7.
Avec le partitionnement du serveur, vous pouvez effectuer une distinction plus avancée entre des URL particulières et leurs applications spécifiques. Par exemple, un serveur Web permet de gérer des pages JSP, des pages HTML, des fichiers GIF, des requêtes de base de données, etc. Load Balancer permet maintenant de partitionner un cluster et un serveur spécifiques d'un port en plusieurs serveurs logiques. Ainsi, vous pouvez appliquer le conseiller sur un service particulier de la machine afin de détecter si un moteur de servlet ou une demande de base de données s'exécute très rapidement ou s'il ne s'exécute pas du tout.
Le partitionnement de serveur permet à Load Balancer de détecter, par exemple, que le service HTML traite les pages rapidement mais que la connexion à la base de données à été interrompue. Ainsi vous pouvez distribuer la charge en fonction de la charge de travail de chaque service plus granulaire et non en fonction uniquement de la pondération serveur.
Le partitionnement de serveur peut se révéler utile s'il est associé aux conseillers HTTP et HTTPS. Par exemple, lorsque vous disposez d'un serveur HTML qui gère des pages HTML, GIF et JSP, si vous définissez le serveur (par ajout) une seule fois sur le port 80, vous ne recevez qu'une valeur de charge pour la totalité du serveur HTTP. Ceci peut vous induire en erreur car il est possible que le service GIF ne fonctionne pas sur le serveur. Dispatcher continue d'acheminer les pages GIF vers le serveur, mais le client n'obtient qu'un message de dépassement de délai ou d'erreur.
Si vous définissez le serveur trois fois (par exemple, ServerHTML, ServerGIF et ServerJSP) sur le port et que vous définissez le paramètre advisorrequest du serveur avec une chaîne différente pour chaque serveur logique, vous pouvez demander des informations concernant l'état d'un service particulier sur le serveur. ServerHTML, ServerGIF et ServerJSP correspondent à trois serveurs logiques partitionnés à partir d'un serveur physique. Pour ServerJSP, vous pouvez définir la chaîne advisorrequest afin d'interroger le service sur la machine qui gère les pages JSP. Pour ServerGIF, vous pouvez définir la chaîne advisorrequest afin d'interroger le service GIF. Pour ServerHTML, vous pouvez définir la chaîne advisorrequest afin d'interroger le service HTML. Ainsi, lorsque le client n'obtient pas de réponse de l'interrogation advisorrequest du service GIF, Dispatcher marque ce serveur logique (ServerGIF) comme inactif tandis que les deux autres serveurs logiques peuvent parfaitement fonctionner. Dispatcher n'achemine plus de pages GIF vers le serveur physique, mais peut encore envoyer des requêtes JSP et HTML au serveur.
Pour plus d'informations sur le paramètres advisorrequest, voir Configuration du conseiller HTTP ou HTTPS à l'aide de l'option de demande ou de réponse (URL).
Dans la configuration de Dispatcher, vous pouvez représenter un serveur physique ou un serveur logique à l'aide de la hiérarchie cluster:port:serveur. Le serveur peut être une adresse IP unique de la machine (serveur physique) sous la forme d'un nom symbolique ou d'une adresse IP. Ou, si vous définissez le serveur afin qu'il représente un serveur partitionné, vous devez alors fournir une adresse de serveur pouvant être résolue pour le serveur physique dans le paramètre address de la commande dscontrol server add. Pour plus d'informations, voir dscontrol server — Configuration des serveurs.
Voici un exemple de partitionnement de serveurs physiques en serveurs logiques afin de gérer différents types de demandes.
Cluster: 1.1.1.1 Port: 80 Server: A (IP address 1.1.1.2) HTML server Server: B (IP address 1.1.1.2) GIF server Server: C (IP address 1.1.1.3) HTML server Server: D (IP address 1.1.1.3) JSP server Server: E (IP address 1.1.1.4) GIF server Server: F (IP address 1.1.1.4) JSP server Rule1: /*.htm Server: A Server: C Rule2: /*.jsp Server: D Server: F Rule3: /*.gif Server: B Server: E
Dans cet exemple, le serveur 1.1.1.2 est divisé en deux serveurs logiques : "A" (gérant les demandes HTML) et "B" (gérant les demandes GIF). Le serveur 1.1.1.3 est divisé en deux serveurs logiques : "C" (gérant les demandes HTML) et "D" (gérant les demandes JSP). Le serveur 1.1.1.4 est partitionné en deux serveurs logiques : "E" (gérant les demandes GIF) et "F" (gérant les demandes JSP).
La fonctionnalité de haute disponibilité requiert une deuxième machine. La première se charge de l'équilibrage de charge pour la totalité du trafic client, comme dans une configuration à une seule machine. La seconde machine surveille le bon fonctionnement de la première et reprend l'équilibrage de charge si elle détecte un échec de la première machine.
Chacune des deux machines se voit affecter un rôle spécifique, principal ou de sauvegarde. La machine principale envoie régulièrement les données de connexion à la machine de secours. Pendant que la machine principale est active (équilibrage de charge), la machine de sauvegarde est en état d'attente et ses données s'actualisent en permanence, ce qui lui permet de prendre le relais des opérations en cas de besoin.
Les sessions de communication entre les deux machines sont désignées par le terme signal de présence. Ces signaux permettent à chaque machine de contrôler l'état de l'autre.
Si la machine de sauvegarde détecte que la machine principale est défaillante, elle prend en charge l'équilibrage de charge. A cette étape, les états respectifs des deux machines s'inversent : la machine de secours devient active et la machine principale passe en attente.
Dans la configuration à haute disponibilité, les deux machines doivent se trouver sur le même sous-réseau et leur configuration doit être identique.
Pour plus d'informations sur la fonction de haute disponibilité, voir Haute disponibilité.
La fonctionnalité à haute disponibilité réciproque implique l'utilisation de deux machines. Les deux machines effectuent l'équilibrage de la charge du trafic client de manière active et assurent réciproquement la sauvegarde l'une de l'autre. Dans une configuration à haute disponibilité, une seule machine effectue l'équilibrage de charge. Dans une configuration à haute disponibilité réciproque, les deux machines assument l'équilibrage de charge d'une partie du trafic du client.
Pour la haute disponibilité réciproque, le trafic client est affecté à chaque machine sur la base d'une adresse de cluster. Chaque cluster peut être configuré avec l'adresse de non-acheminement (NFA) de sa machine principale. La machine du Dispatcher principal effectue normalement l'équilibrage de charge pour ce cluster. En cas de panne, l'autre machine assume l'équilibrage de charge pour son propre cluster et pour celui du Dispatcher qui est en panne.
La figure 14 illustre une configuration de haute disponibilité réciproque avec “cluster partagé A" et “cluster partagé B,". Chaque répartiteur peut acheminer activement des paquets pour son cluster principal. Si l'un des répartiteurs venait à échouer et ne pouvait plus activement acheminer les paquets pour son cluster principal, l'autre répartiteur pourrait le remplacer et acheminerait les paquets pour son cluster de sauvegarde.
Pour plus d'informations sur la fonction de haute disponibilité, voir Haute disponibilité.