Planification de Dispatcher

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 :

Remarque :
Dans les versions antérieures où le produit se nommait Network Dispatcher, la commande de contrôle de Dispatcher était ndcontrol. Elle s'intitule désormais dscontrol.

Remarques relatives à la planification

Dispatcher se compose des fonctions suivantes :

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.

Méthodes d'acheminement

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

Réacheminement MAC de Dispatcher (méthode d'acheminement mac)

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

Réacheminement NAT/NAPT de Dispatcher (méthode d'acheminement nat)

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

Fonction CBR de Dispatcher (méthode d'acheminement cbr)

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.

Remarque :
La règle de contenu est configurée dans le composant Dispatcher de la même façon que dans le composant CBR. Dispatcher peut utiliser la règle de contenu pour le trafic HTTP. Toutefois, le composant CBR peut utiliser la règle de contenu à la fois pour le trafic HTTP et HTTPS (SSL).

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

Remarque :
La fonction de réplication des enregistrements de connexions de haute-disponibilité (qui garantit que la connexion d'un client ne sera pas annulée lorsqu'une machine Dispatcher de sauvegarde remplace la machine principale) n'est pas pris en charge avec la fonction cbr de Dispatcher.

Etapes de configuration des méthodes d'acheminement nat ou cbr de Dispatcher

Figure 12. Exemple d'utilisation des méthodes d'acheminement nat ou cbr de Dispatcher
Configuration de l'utilisation des méthodes d'acheminement nat ou cbr de Dispatcher

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.

Partitionnement du serveur : serveurs logiques configurés pour un serveur physique (adresse IP)

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.

Partitionnement de serveur à l'aide des conseillers HTTP ou HTTPS

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

Exemple de configuration d'un serveur physique en plusieurs serveurs logiques

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

Haute disponibilité

Haute disponibilité simple

Figure 13. Exemple de Dispatcher utilisant la haute disponibilité
Dispatcher utilisant la configuration à haute disponibilité simple

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

Haute disponibilité réciproque

Figure 14. Exemple de Dispatcher utilisant la haute disponibilité réciproque
Dispatcher utilisant la configuration à haute disponibilité réciproque

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.

Remarque :
Les deux machines doivent configurer de la même façon leur ensembles de clusters partagés. C'est-à-dire que les ports utilisés et les serveurs définis pour chaque port doivent être identiques dans les deux configurations.

Pour plus d'informations sur la fonction de haute disponibilité, voir Haute disponibilité.