Le présent chapitre explique comment configurer les paramètres d'équilibrage de charge et comment installer les fonctions avancées de Load Balancer.
Tâche | Description | Informations connexes |
---|---|---|
Placement de Load Balancer sur une machine dont il équilibre la charge | Installation d'une machine Load Balancer co-implantée. | Utilisation de serveurs implantés au même endroit |
Configuration de la haute disponibilité ou de la haute disponibilité réciproque | Installe une deuxième machine Dispatcher comme répartiteur de secours. | Haute disponibilité |
Configuration d'un équilibrage de charge basé sur des règles | Définition des conditions sous lesquelles un sous-ensemble donné de serveurs est utilisé. | Configuration de l'équilibrage de charge basé sur des règles |
Utilisation de la substitution d'affinité de port pour fournir au serveur un dispositif de remplacement de la fonction de maintien de routage de port. | Permet à un serveur de remplacer sur son port les paramètres de maintien de routage. | Substitution d'affinité de port |
Utilisation de la fonction de maintien de routage (affinité) pour fidéliser un port de cluster. | Permet aux demandes clients d'être acheminées vers le même serveur. | Fonctionnement de la fonction d'affinité pour Load Balancer |
Utilisation de l'affinité de ports croisés pour étendre la fonction de maintien de routage (affinité) aux autres ports. | Permet aux demandes clients reçues par des ports différents d'être dirigées vers le même serveur. | Affinité de ports croisés |
Utilisation du masque d'adresse d'affinité pour désigner une adresse de sous-réseau IP commune. | Permet aux demandes clients reçues par le même sous-réseau d'être dirigées vers un même serveur. | Masque d'adresse de l'affinité (masque de maintien de routage) |
Utilisation de l'affinité de cookie actif pour l'équilibrage de charge des serveurs pour le composant CBR | Option de règle permettant de conserver l'affinité pour un serveur particulier. | Affinité de cookie actif |
Utilisation de l'affinité de cookie pour le routage en fonction du contenu de Dispatcher et le composant CBR | Option de règle permettant de conserver l'affinité pour un serveur particulier en fonction de la valeur du cookie/nom du cookie. | Affinité de cookie passif |
Utilisation de l'affinité d'URI pour effectuer l'équilibrage de charge au sein des serveurs Caching avec un contenu unique à placer en mémoire cache sur chaque serveur | Option de règle permettant de conserver l'affinité pour un serveur particulier en fonction de l'URI. | Affinité d'URI |
Configuration du support de réseau étendu pour Dispatcher | Installe une machine Dispatcher éloignée pour l'équilibrage de charge sur un réseau étendu. Ou effectue l'équilibrage de charge dans un réseau étendu (sans Dispatcher éloigné) à l'aide d'une plateforme de serveur prenant en charge GRE. | Configuration du support de réseau étendu pour Dispatcher |
Utilisation de liens explicites | Evitez d'ignorer Dispatcher dans vos liens. | Utilisation de liens explicites |
Utilisation d'un réseau privé | Configurez le répartiteur (Dispatcher) pour qu'il assure l'équilibrage de charge des serveurs sur un réseau privé. | Utilisation d'une configuration réseau privée |
Utilisation d'un cluster générique pour combiner des configurations serveur communes | Les adresses non explicitement configurées utiliseront le cluster générique pour équilibrer le trafic. | Utilisation d'un cluster générique pour combiner les configurations serveurs |
Utilisation d'un cluster générique pour équilibrer la charge des pare-feux. | La totalité du trafic sera équilibré sur les pare-feux. | Utilisation du cluster générique pour équilibrer la charge des pare-feux |
Utilisation d'un cluster générique avec Caching Proxy pour le proxy transparent | Permet d'utiliser Dispatcher pour activer un proxy transparent. | Utilisation de cluster générique avec Caching Proxy pour le proxy transparent |
Utilisation du port générique pour acheminer le trafic destiné à un port non configuré | Prend en charge le trafic qui n'est configuré pour aucun port particulier. | Utilisation du port générique pour acheminer le trafic destiné à un port non configuré |
Utilisation de la détection de "refus de service" pour indiquer aux administrateurs (via une alerte) des attaques éventuelles | Dispatcher analyse les demandes entrantes d'un certain nombre de connexions partielles sur les serveurs. | Détection d'attaque de refus de service |
Utilisation de la consignation binaire pour analyser les statistiques des serveurs. | Permet d'enregistrer les informations sur les serveurs dans des fichiers binaires et d'extraire ces informations. | Utilisation de la consignation binaire pour analyser les statistiques des serveurs |
Utilisation d'une configuration de client co-implanté | Autoriser Load Balancer à résider sur la même machine qu'un client | Utilisation d'un client co-implanté |
Load Balancer peut se trouver sur la même machine qu'un serveur pour lequel il équilibre la charge des demandes. On parle alors de co-implantation d'un serveur. La co-implantation s'applique aux composants Dispatcher et Site Selector. Elle est également prise en charge pour le composant CBR, mais uniquement avec des serveurs Web et un serveur Caching Proxy de type serveur de liaison.
Linux : Pour configurer simultanément la co-implantation et la haute disponibilité lors de l'exécution du composant Dispatcher avec la méthode d'acheminement MAC, voir 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.
Solaris : Dans cet environnement, vous ne pouvez pas configurer de conseillers WAN lorsque le point d'entrée est co-implanté. Voir Utilisation de conseillers éloignés avec le support de réseau étendu de Dispatcher.
Windows : La collocation n'est plus disponible.
Dans les versions précédentes, il était nécessaire de préciser que l'adresse du serveur co-implanté devait être la même que l'adresse de non-acheminement (NFA) dans la configuration. Cette restriction a maintenant été éliminée.
Pour configurer un serveur afin qu'il soit co-implanté, la commande dscontrol server propose l'option collocated qui peut être oui ou non. La valeur par défaut est non. L'adresse du serveur doit être une adresse IP valide d'une carte d'interface réseau sur la machine. Le paramètre collocated ne doit pas être défini pour les serveurs co-implantés à l'aide de la méthode d'acheminement NAT ou CBR de Dispatcher.
Vous pouvez configurer un serveur co-implanté de l'une des manières suivantes :
Pour l'acheminement NAT ou CBR de Dispatcher, vous devez configurer (alias) une adresse NFA de carte réseau inutilisée. Le serveur doit être configuré pour écouter cette adresse. Configurez le serveur en utilisant la syntaxe de commande suivante :
dscontrol server add cluster:port:nouvel_alias address nouvel_alias router ip_routeur returnaddress adresse_retour
Si vous n'effectuez pas cette configuration, des erreurs système risquent de se produire et le serveur peut ne pas répondre.
Lorsque vous configurez un serveur co-implanté avec la méthode d'acheminement NAT de Dispatcher, le routeur spécifié dans la commande dscontrol server add doit correspondre à une adresse de routeur réelle et non à l'adresse IP du serveur.
Vous pouvez désormais configurer la prise en charge de la co-implantation sur les systèmes d'exploitation suivants lors de la configuration de la méthode d'acheminement NAT de Dispatcher si vous exécutez les étapes suivantes sur la machine Dispatcher :
arp -s nom_hôte ether_addr puben utilisant l'adresse MAC locale pour ether_addr. L'application peut ainsi envoyer le trafic à l'adresse de retour du noyau.
CBR prend en charge la co-implantation sur les plateformes AIX, HP-UX, Linux et Solaris sans configuration supplémentaire requise. Vous devez toutefois utiliser des serveurs Web et Caching Proxy de liaison.
Site Selector prend en charge la co-implantation sur les plateformes AIX, HP-UX, Linux et Solaris sans configuration supplémentaire requise.
La fonction de haute disponibilité (configurable avec la commande dscontrol highavailability) est disponible pour le composant Dispatcher (mais pas pour les composants CBR et Site Selector).
Pour améliorer la disponibilité de Dispatcher, la fonction de haute disponibilité de Dispatcher utilise les mécanismes suivants :
Au moins une des paires de signaux de présence doit utiliser si possible un sous-réseau différent du trafic classique du cluster. Un trafic distinct de signaux de présence permet d'éviter les faux relais lors des fortes charges réseau et d'améliorer les temps de reprise totale.
La syntaxe complète de la commande dscontrol highavailability est fournie dans la section dscontrol highavailability — Contrôle de la haute disponibilité.
Pour plus d'informations sur les tâches détaillées ci-dessous, voir Configuration de la machine Dispatcher.
dscontrol highavailability heartbeat add adresse_source adresse_destination
Machine principale (primary) - highavailability heartbeat add 9.67.111.3 9.67.186.8 machine de secours (backup) - highavailability heartbeat add 9.67.186.8 9.67.111.3Au moins, une des paires de signaux de présence doit disposer des NFA de la paire en tant d'adresse source et de destination.
Au moins une des paires de signaux de présence doit utiliser si possible un sous-réseau différent du trafic classique du cluster. Un trafic distinct de signaux de présence permet d'éviter les faux relais lors des fortes charges réseau et d'améliorer les temps de reprise totale.
Définit le nombre de secondes nécessaires à l'exécuteur pour arrêter les signaux de présence de disponibilité pour dépassement du délai d'expiration. Exemple :
dscontrol executor set hatimeout 3
La valeur par défaut est 2 secondes.
dscontrol highavailability reach add 9.67.125.18Les cibles à atteindre sont recommandées mais pas obligatoires. Pour plus d'informations, voir Détections des incidents en utilisant signal de présence et cible à atteindre.
dscontrol highavailability backup add primary [auto | manual] port
dscontrol highavailability backup add backup [auto | manual] port
dscontrol highavailability backup add both [auto | manual] port
dscontrol highavailability statusChacune des machines doit avoir le rôle (principal, secondaire ou les deux), les états et sous-états qui conviennent. La machine principale doit être active et synchronisée ; la machine de secours doit être en mode veille et se synchroniser rapidement avec l'autre. Les deux stratégies doivent être identiques.
dscontrol cluster set clusterA primaryhost NFAdispatcher1 dscontrol cluster set clusterB hôte_principal dispatcherNFA2
dscontrol cluster set clusterB primaryhost NFAdispatcher2 dscontrol cluster set clusterA hôte_principal dispatcherNFA1
Outre les critères de détection d'incidents de base (perte de connectivité entre le système Dispatcher de secours et le système Dispatcher actif, détectée via les messages de signal de présence), un autre mécanisme de détection d'incidents appelé critères d'accessibilité est disponible. Lorsque vous configurez Dispatcher, vous pouvez indiquer une liste d'hôtes auxquels chaque système Dispatcher doit pouvoir accéder pour fonctionner correctement. Les deux partenaires en haute disponibilité communiquent en continu par l'intermédiaire de signaux de présence et ils s'indiquent le nombre de cibles à contacter auxquelles ils peuvent chacun accéder (via la commande ping). Si le serveur en attente parvient à accéder à un plus grand nombre de cibles à contacter (via la commande ping) que le serveur actif, une reprise survient.
Les signaux de présence sont envoyés par la machine Dispatcher active et doivent être reçus par la machine Dispatcher en veille toutes les demi secondes. Si la machine Dispatcher en veille ne parvient pas à recevoir un signal de présence dans les 2 secondes, une reprise survient. Une reprise n'est effectuée par la machine Dispatcher de secours que si tous les signaux de présence échouent. En d'autres termes, lorsque deux paires de signaux de présence sont configurées, les deux signaux de présence doivent échouer. Pour stabiliser un environnement en haute disponibilité et éviter les reprises, ajoutez plusieurs paires de signaux de présence.
Pour les cibles à contacter, vous devez choisir au moins un hôte pour chaque sous-réseau que l'ordinateur Dispatcher utilise. Il peut s'agir de systèmes hôtes tels que les routeurs, les serveurs IP ou d'autres types d'hôtes. L'accessibilité de l'hôte est obtenue grâce au conseiller de contact, qui lance un ping à l'hôte. La reprise a lieu si les messages de signal de présence ne peuvent pas être transmis ou si les critères d'accessibilité sont mieux respectés par la machine Dispatcher de secours que par la machine Dispatcher principale. Pour prendre la décision sur la base de toutes les informations disponibles, le répartiteur actif envoie régulièrement au répartiteur de secours ses données d'accessibilité. La machine Dispatcher de secours compare ensuite ces données aux siennes, puis décide de procéder ou non au basculement.
Deux machines Dispatcher sont configurées : la machine principale et une deuxième machine appelée machine de sauvegarde (ou de secours). Au démarrage, la machine principale transmet toutes les données de connexion à la machine de secours afin d'obtenir une parfaite synchronisation. La machine principale devient active, c'est-à-dire qu'elle commence l'équilibrage de charge. Parallèlement, la machine de secours contrôle l'état de la machine principale et conserve l'état de veille.
Si, à tout instant, la machine de secours décèle une défaillance de la machine principale, elle prend le relais des fonctions d'équilibrage de charge de la machine principale et devient, à son tour, la machine active. Une fois la machine principale redevenue opérationnelle, les machines se comportent selon la stratégie de reprise après incident définie par l'utilisateur. Il existe deux types de stratégie :
La stratégie définie doit être identique pour les deux machines.
La stratégie de reprise manuelle oblige l'utilisateur à forcer le routage des paquets vers une machine spécifique, à l'aide de la commande "takeover". La reprise manuelle s'avère utile lorsque l'autre machine doit subir des opérations de maintenance. La stratégie de reprise automatique est conçue pour un fonctionnement normal sans surveillance.
Pour une configuration de haute disponibilité réciproque , il n'existe pas de défaillance par cluster. Si l'une des machines est victime d'une défaillance, même si celle-ci ne concerne qu'un des clusters, l'autre machine prendra le relais pour chacun des deux clusters.
Pour que Dispatcher puisse acheminer les paquets de données, chaque adresse de cluster doit posséder un alias la reliant à une interface réseau.
Pour plus d'informations sur l'association d'alias à la carte d'interface réseau, voir Etape 5. Affectation d'un alias à la carte d'interface réseau.
Dans la mesure où les machines Dispatcher changent d'état lorsqu'une défaillance est détectée, les commandes citées plus haut doivent être lancées automatiquement. Dispatcher exécutera des scripts créés par l'utilisateur pour le faire. Les exemples de script se trouvent dans le répertoire suivant :
Ces scripts doivent être déplacés dans le répertoire suivant avant d'être exécutés :
Les scripts s'exécutent automatiquement uniquement si dsserver est en cours d'exécution.
Les scripts exemples suivants peuvent être utilisés :
Sur les systèmes Windows : Si, dans votre configuration, Site Selector équilibre la charge de deux machines Dispatcher fonctionnant en environnement à haute disponibilité, vous devrez définir un alias pour les systèmes Metric Server dans la pile Microsoft des systèmes Metric Server. Insérez cet alias dans le script goActive. Par exemple :
call netsh interface ip add address "Local Area Connection" addr=9.37.51.28 mask=255.255.240.0
Supprimez les alias des scripts goStandby et goInOp. Par exemple :
call netsh interface ip delete address "Local Area Connection" addr=9.37.51.28
Si la machine est équipée de plusieurs cartes d'interface réseau, vérifiez dans un premier temps l'interface à utiliser en entrant la commande suivante au niveau de l'invite : netsh interface ip show address. Elle renvoie la liste des interfaces configurées et le numéro de la connexion au réseau local (par exemple, "Local Area Connection 2") permettant de déterminer celle à utiliser.
Sous Linux pour S/390 : Dispatcher génère automatiquement un protocole de résolution d'adresse ATM pour transférer les adresses IP d'une machine Dispatcher vers une autre. Ce mécanisme est donc lié au type de réseau sous-jacent. Lors de l'exécution de Linux pour S/390, Dispatcher ne peut effectuer des reprises en haute disponibilité de manière native (complètes avec transferts d'adresse IP) que sur les interfaces qui peuvent générer automatiquement un protocole de résolution d'adresse ATM et configurer l'adresse sur l'interface locale. Ce mécanisme ne fonctionne pas sur les interfaces point à point telles qu'IUCV et CTC et ne fonctionne pas correctement dans certaines configurations de qeth/QDIO.
Pour les interfaces et configurations dans lesquelles la fonction de reprise IP native de Dispatcher ne fonctionne pas correctement, le client peut insérer les commandes appropriées dans les scripts go pour transférer manuellement les adresses. Ces topologies réseau peuvent ainsi également bénéficier de la haute disponibilité.
Vous pouvez utiliser un équilibrage basé sur des règles pour déterminer de manière précise quand et pourquoi des paquets sont envoyés à des serveurs et quels sont ces serveurs. Load Balancer parcourt toute les règles que vous ajoutez, de la première à la dernière priorité et s'arrête sur la première règle vérifiée avant d'équilibrer la charge en fonction du contenu entre les serveurs associés à cette règle. Ils équilibrent déjà la charge en fonction de la destination et du port, mais l'utilisation de règles permet d'étendre votre capacité à répartir les connexions.
Dans la plupart des cas lors de la configuration de règles, vous devez configurer une règle par défaut toujours vraie afin d'intercepter les demandes provenant des autres règles de priorité élevée. Il peut s'agir d'une réponse du type "Désolé, ce site est actuellement inaccessible. Faites une nouvelle tentative ultérieurement" lorsque tous les autres serveurs ne peuvent pas traiter la demande client.
Vous devez utiliser l'équilibrage de charge dépendant des règles avec Dispatcher et Site Selector lorsque vous voulez utiliser un sous-ensemble de serveurs pour une raison quelconque. Vous devez toujours utiliser des règles pour le composant CBR.
Vous pouvez sélectionner les types de règles suivants :
Planifiez la logique à suivre par les règles avant de commencer à ajouter des règles à votre configuration.
Toutes les règles possèdent un nom, un type, une priorité et peuvent avoir une valeur de début et une valeur de fin ainsi qu'un ensemble de serveurs. En outre, à la règle de type contenu du composant CBR est associée une structure d'expression standard. (Pour obtenir des exemples et des scénarios sur le mode d'utilisation de la règle de contenu et la syntaxe de motif valide pour la règle de contenu, voir Annexe B. Syntaxe des règles de contenu (modèle).)
Les règles sont évaluées dans l'ordre de leur priorité. en d'autres termes, une règle de priorité 1 (nombre le moins élevé) avant une règle de priorité 2 (nombre plus élevé). La première règle vérifiée est utilisée. Lorsqu'une règle est vérifiée, aucune autre règle n'est évaluée.
Pour qu'une règle soit vérifiée, elle doit remplir deux conditions :
Si aucun serveur n'est associé à une règle, cette dernière ne doit remplir que la première condition pour être vérifiée. Dans ce cas, Dispatcher abandonne la demande de connexion, Site Selector renvoie la demande de serveur de nom avec une erreur et CBR provoque une page d'erreur Caching Proxy.
Si aucune règle n'est vérifiée, Dispatcher sélectionne un serveur parmi l'ensemble des serveurs disponibles du port, Site Selector sélectionne un serveur parmi l'ensemble des serveurs disponibles sur le nom du site et CBR provoque l'affichage d'une page d'erreur par Caching Proxy.
Ce type de règle est disponible dans le composant Dispatcher, CBR ou Site Selector.
Vous pouvez souhaiter utiliser des règles basées sur l'adresse IP des clients pour trier les clients et leur affecter des ressources en fonction de leur provenance.
Par exemple, vous constatez la présence sur le réseau d'un nombre important de transmissions impayées et donc indésirables en provenance de clients appartenant à un ensemble spécifique d'adresses IP. Vous créez donc une règle à l'aide de la commande dscontrol rule , par exemple :
dscontrol rule add 9.67.131.153:80:ni type ip beginrange 9.0.0.0 endrange 9.255.255.255
Cette règle "ni" permet de trier les connexions des clients indésirables. Ajoutez ensuite à la règle les serveurs qui doivent être accessibles, ou si vous n'ajoutez pas de serveurs à la règle, les demandes provenant des adresses 9.x.x.x ne sont pas transmises par l'un de vos serveurs.
Ce type de règle est disponible uniquement avec le composant Dispatcher.
Vous pouvez souhaiter utiliser des règles basées sur le port client lorsque vos clients utilisent un type de logiciel nécessitant un port spécifique de TCP/IP lors des demandes.
Vous pouvez, par exemple, créer une règle spécifiant que toute demande dont le port client est 10002, doit utiliser un ensemble de serveurs rapides spéciaux car vous savez que les demandes client associées à ce port proviennent d'un groupe de clients privilégiés.
Ce type de règle est disponible dans le composant Dispatcher, CBR ou Site Selector.
Vous pouvez souhaiter utiliser des règles basées sur l'heure en vue de la planification des pondérations. Si par exemple votre site Web est surchargé chaque jour pendant les mêmes créneaux horaires, il est préférable de dédier cinq serveurs supplémentaires aux heures de pointe.
Ce type de règle est également intéressant lorsque vous voulez arrêter certains serveurs chaque jour à minuit, pour des raisons de maintenance. Dans ce cas, vous pouvez définir une règle qui exclut ces serveurs pendant la période de maintenance nécessaire.
Ce type de règle est disponible uniquement avec le composant Dispatcher.
Vous pouvez souhaiter utiliser des règles fondées sur le contenu du champ “type de service” (TOS) de l'en-tête IP. Par exemple, si la valeur TOS d'une demande client entrante indique un service normal, cette demande peut être routée vers un ensemble de serveurs. Si une autre demande arrive, munie cette fois d'une valeur TOS différente indiquant une priorité de service élevée, elle peut être dirigée vers un autre ensemble de serveurs.
La règle TOS permet de configurer entièrement chacun des bits de l'octet TOS en utilisant la commande dscontrol rule. Utilisez 0 ou 1 pour les bits importants que vous souhaitez apparier dans l'octet TOS. La valeur x est utilisée par défaut. Voici un exemple d'ajout d'une règle TOST :
dscontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
Ce type de règle est disponible dans les composants Dispatcher et CBR.
Vous pouvez souhaiter utiliser des règles basées sur le nombre de connexions par seconde lorsque vous devez partager certains serveurs avec d'autres applications. Vous pouvez, par exemple, définir deux règles :
Vous pouvez aussi utiliser Telnet et vouloir lui réserver deux des cinq serveurs, sauf lorsque le nombre de connexions par seconde dépasse un certain niveau. Ainsi, Dispatcher équilibre la charge entre les cinq serveurs, pendant les heures de pointe.
Définition de l'option d'évaluation de règle "upserversonrule" avec la règle de type "connexion" : Si, lorsque vous utilisez la règle de type connexions et définissez l'option upserversonrule, certains serveurs de l'ensemble de serveurs sont inactifs, vous pouvez préserver les serveurs actifs d'une surcharge. Pour plus d'informations, voir Option d'évaluation de serveur.
Ce type de règle est disponible dans le composant Dispatcher ou CBR.
Vous pouvez utiliser des règles reposant sur le nombre total de connexions actives sur un port si vos serveurs sont surchargés et ne traitent plus les paquets. Dans ce cas, certains serveurs Web continuent d'accepter les connexions même s'ils ne disposent pas d'un nombre suffisant d'unités d'exécution pour répondre à la demande. Il en résulte que le poste client réclame un certain délai de temporisation et que le client accédant à votre site Web n'est pas servi. Vous pouvez utiliser des règles basées sur le nombre de connexions actives pour équilibrer les pondérations d'un pool de serveurs.
Par exemple, vous savez d'expérience que vos serveurs s'arrêtent après avoir accepté 250 connexions. Vous pouvez créer une règle à l'aide de la commande dscontrol rule ou cbrcontrol rule, par exemple :
dscontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500 ou à cbrcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500
Vous pouvez ensuite ajouter à la règle vos serveurs en cours plus d'autres serveurs qui, autrement seraient utilisés pour d'autres processus.
Les règles de largeur de bande réservée et partagée sont disponibles uniquement dans le composant Dispatcher.
Pour les règles de largeur de bande, Dispatcher calcule la largeur de bande en tant que débit auquel les données sont délivrées aux clients par un ensemble de serveurs spécifique. Dispatcher effectue le suivi de la capacité aux niveaux du serveur, de la règle, du port, du cluster et de l'exécuteur. Pour chacun de ces niveaux, il existe une zone compteur d'octets : les kilo-octets transmis par seconde. Dispatcher calcule ces débits sur un intervalle de 60 secondes. Vous pouvez consulter ces valeurs de débit dans l'interface ou dans la sortie d'un rapport de ligne de commande.
La règle de largeur de bande réservée permet de contrôler le nombre de kilo-octets délivrés par seconde à un ensemble de serveurs. En définissant un seuil (définition d'une plage de largeur de bande précise) pour chaque ensemble de serveurs dans la configuration, vous pouvez contrôler et garantir le montant de la largeur de bande utilisé par chaque combinaison cluster-port.
Voici un exemple d'ajout de règle de largeur de bande réservée :
dscontrol rule add 9.67.131.153:80:rbw type reservedbandwidth beginrange 0 endrange 300
Les valeurs de début et de fin sont indiquées en kilo-octets par seconde.
Avant de configurer la règle de largeur de bande partagée, vous devez indiquer la quantité maximale de largeur de bande (kilo-octets par seconde) pouvant être partagée au niveau de l'exécuteur ou du cluster à l'aide de la commande dscontrol executor ou dscontrol cluster avec l'option sharedbandwidth. La valeur sharebandwidth ne doit pas dépasser la largeur totale de bande (capacité réseau totale) disponible. L'utilisation de la commande dscontrol pour définir la largeur de bande partagée ne fournit qu'une limite maximale pour la règle.
Voici des exemples de la syntaxe de la commande.
dscontrol executor set sharedbandwidth taille dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth taille
La taille de l'option sharedbandwidth correspond à une valeur entière (kilo-octets par seconde). La valeur par défaut est zéro. Si la valeur est zéro, la bande passante ne peut pas être partagée.
Le partage de la largeur de bande au niveau du cluster permet au cluster d'utiliser une largeur de bande maximale indiquée. Tant que la largeur de bande utilisée par le cluster est inférieure à la quantité indiquée, cette règle est respectée (true). Lorsque la largeur totale de bande utilisée dépasse la quantité indiquée, cette règle n'est plus respectée (false).
Le partage de la largeur de bande au niveau de l'exécuteur permet à toute la configuration Dispatcher de partager une quantité maximale de largeur de bande. Tant que la largeur de bande utilisée au niveau de l'exécuteur est inférieure à la quantité indiquée, cette règle est respectée (true). Lorsque la largeur totale de bande utilisée dépasse la quantité définie, cette règle n'est plus respectée (false).
Ci-dessous, se trouvent des exemples d'ajout ou de définition d'une règle sharedbandwidth.
dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel valeur dscontrol rule set 9.20.34.11:80:shrule sharelevel valeur
La valeur de l'option sharelevel est soit exécuteur, soit cluster. Sharelevel est un paramètre requis dans la règle sharebandwidth
Dispatcher permet d'attribuer une largeur de bande indiquée à des ensembles de serveurs dans votre configuration à l'aide de la règle largeur de bande réservée. En précisant un début et une fin de plage, vous pouvez contrôler la plage de kilo-octets livrée aux clients par un ensemble de serveurs. Dès que la règle n'est plus vraie (limite de plage dépassée), la règle de priorité inférieure suivante est appliquée. S'il s'agit d'une règle "toujours vraie", un serveur peut être sélectionné pour envoyer une réponse "site occupé" au client.
Prenons, par exemple, un groupe de trois serveurs sur le port 2222. Si la largeur de bande réservée est fixée à 300, le nombre maximal de kilo-octets par seconde est 300, sur une durée de 60 secondes. Lorsque ce débit est excédé, la règle n'est plus respectée. Si cette règle est la seule, Dispatcher sélectionne l'un des trois serveurs pour traiter la demande. S'il existe une règle "toujours vraie" de priorité inférieure, la demande est dirigée vers un autre serveur et reçoit la réponse "site occupé".
La règle de largeur de bande partagée offre aux clients l'accès à des serveurs supplémentaires. Plus précisément, lorsqu'elle est utilisée comme règle de priorité inférieure faisant suite à une règle de largeur de bande réservée, un client peut encore accéder à un serveur lorsque la largeur de bande réservée a été dépassée.
Par exemple, si vous placez une règle de largeur de bande partagée après une règle de largeur de bande réservée, vous permettez aux clients d'accéder à trois serveurs de manière contrôlée. Tant qu'il reste de la largeur de bande réservée à utiliser, la règle est vraie et l'accès accordé. Lorsqu'il ne reste plus de largeur de bande réservée disponible, cette règle n'est plus vraie et la suivante est appliquée. Si la règle suivante est une règle "toujours vraie", la demande est au besoin dirigée vers un autre serveur.
En utilisant les règles de largeur de bande réservée et partagée comme indiqué dans l'exemple ci-dessus , permet plus de souplesse et de contrôle au niveau des accords (ou refus) d'accès aux serveurs. Les serveurs d'un port particulier peuvent se voir attribuer une largeur de bande limitée, tandis que d'autres peuvent utiliser autant de largeur de bande que disponible.
Ce type de règle est disponible uniquement dans le composant Site Selector.
Pour la règle Mesure de tous les serveurs, vous choisissez une mesure système (cpuload, memload ou votre propre script de mesure système personnalisé) et Site Selector compare la valeur de mesure système (renvoyée par l'agent du système Metric Server se trouvant dans chaque serveur d'équilibrage de charge) avec les valeurs de début et de fin indiquées dans la règle. La valeur de mesure de tous les serveurs de l'ensemble de serveurs doit être définie dans la plage afin que la règle puisse s'exécuter.
Ci-dessous, se trouve un exemple d'ajout de mesure à toutes les règles de la configuration.
sscontrol rule add dnsload.com:allrule1 type metricall metricname cpuload beginrange 0 endrange 100
Ce type de règle est disponible uniquement dans le composant Site Selector.
Pour la règle Moyenne des mesures, vous choisissez une mesure système (cpuload, memload ou votre propre script de mesure système personnalisé) et Site Selector compare la valeur de mesure système (renvoyée par l'agent du système Metric Server se trouvant dans chaque serveur d'équilibrage de charge) avec les valeurs de début et de fin indiquées dans la règle. La moyenne des valeurs des mesures système de tous les serveurs de l'ensemble de serveurs doit être définie dans la plage pour que la règle puisse s'exécuter.
Ci-dessous, se trouve un exemple d'ajout de règle de moyenne des mesures à votre configuration.
sscontrol rule add dnsload.com:avgrule1 type metricavg metricname cpuload beginrange 0 endrange 100
Ce type de règle est disponible dans le composant Dispatcher, CBR ou Site Selector.
Une règle peut être créée comme règle “toujours vraie.” Ces règle seront toujours sélectionnées, sauf si tous les serveurs associés sont arrêtés. Pour cette raison, leur niveau de priorité est généralement inférieur à celui de autres règles.
Vous pouvez même avoir plusieurs règles “toujours vraies”, chacune d'elles associée à un ensemble de serveurs. La première règle vérifiée pour laquelle un serveur est disponible est choisie. Supposons par exemple que vous disposiez de six serveurs. Vous voulez que deux d'entre eux traitent le trafic quelles que soient les circonstances, à moins qu'ils soient tous les deux arrêtés. Si les deux premiers serveurs sont arrêtés, vous voulez qu'un deuxième jeu de serveurs traite le trafic. Enfin, si les quatre serveurs sont arrêtés, vous utiliserez les deux derniers pour traiter le trafic. Vous pouvez définir trois règles “toujours vraie”. Le premier jeu de serveurs est toujours choisi, tant que l'un d'eux est actif. Si les deux serveurs sont arrêtés, l'un des serveurs du deuxième jeu est choisi, etc.
Autre exemple : il se peut que vous vouliez une règle “toujours vraie” pour garantir que les clients entrants qui ne remplissent aucune des règles définies ne sont pas pris en charge. Il vous faut donc créer, à l'aide de la commande dscontrol rule, la règle suivante :
dscontrol rule add 130.40.52.153:80:jamais type true priority 100
Vous n'ajoutez alors pas de serveur à cette règle, ce qui provoque l'abandon sans réponse des paquets des clients.
Vous pouvez définir plusieurs règles “toujours vraies”, puis choisir ensuite celle qui doit être exécutée en modifiant les niveaux de priorité.
Ce type de règle est disponible dans le composant CBR ou Dispatcher (lorsque vous utilisez la méthode d'acheminement CBR de Dispatcher).
Vous pouvez utiliser des règles basées sur le contenu pour envoyer des demandes à des ensembles de serveurs spécialement configurés pour prendre en charge une partie du trafic de votre site. Par exemple, vous pouvez utiliser un ensemble de serveurs pour la prise en charge de toutes les demandes cgi-bin, un autre pour les demandes audio, et un troisième pour toutes les autres demandes. Vous pouvez ajouter une règle dont la structure correspond au chemin d'accès du répertoire cgi-bin, une autre correspondant au type de vos fichiers audio, et une troisième règle "toujours vraie" pour prendre en charge le reste du trafic. Vous ajouterez ensuite les serveurs appropriés à chaque type de règle.
Important : Pour obtenir des exemples et des scénarios sur le mode d'utilisation de la règle de contenu et la syntaxe de modèle valide pour la règle de contenu, voir Annexe B. Syntaxe des règles de contenu (modèle).
La substitution d'affinité de port permet le remplacement du maintien de routage du port d'un serveur spécifique. Par exemple, dans le cas où vous utilisez une règle pour limiter le nombre de connexions alloué à chaque serveur d'application et disposez d'un serveur de débordement à règle fixe qui annonce “please try again later" à propos de cette application. Le délai du maintien de routage du port est de 25 minutes et vous ne souhaitez pas que le client soit maintenu sur ce serveur. La substitution d'affinité de port vous permet alors de changer de serveur de débordement afin de remplacer l'affinité qui est habituellement associée à ce port. Ainsi, les demandes ultérieures du client destinées au cluster seront transmises au serveur d'applications ayant le plus de disponibilités et non pas au serveur de débordement, afin d'équilibrer la charge.
Pour plus d'informations sur la syntaxe de commande de la substitution d'affinité de port, en utilisant l'option de serveurmaintien de routage, voir dscontrol server — Configuration des serveurs. .
Vous pouvez ajouter des règles à l'aide de la commande dscontrol rule add , en modifiant le fichier de configuration exemple ou en utilisant l'interface graphique. Vous pouvez ajouter une ou plusieurs règles à chaque port que vous avez défini.
Il s'agit d'une procédure en deux étapes : vous devez ajouter la règle, puis définir les serveurs sur lesquels les services doivent être effectués si la règle est vraie. Supposons par exemple que l'administrateur système veuille déterminer le taux d'utilisation des serveurs proxy pour chaque division du site. Une adresse IP est octroyée à chaque division. Créez le premier jeu de règles en fonction des adresses IP des clients pour séparer les charges individuelles de chaque division :
dscontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 dscontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 dscontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255
Ajoutez ensuite un serveur distinct à chaque règle, puis mesurez la charge de chaque serveur pour facturer correctement les divisions en fonction des services qu'elles utilisent. Par exemple :
dscontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 dscontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 dscontrol rule useserver 130.40.52.153:80:div3 207.72.33.47
L'option d'évaluation de serveur est disponible uniquement dans le composant Dispatcher.
La commande dscontrol rule a une option d'évaluation de serveur pour les règles. L'option evaluate permet de choisir d'évaluer les conditions de la règle parmi tous les serveurs du port ou d'évaluer les conditions de la règle des serveurs faisant partie de la règle. (Dans les versions précédentes de Load Balancer, il n'était possible de mesurer que la condition de chaque règle parmi tous les serveurs du port.)
Ci-dessous, se trouvent des exemples d'ajout ou de définition de l'option d'évaluation au niveau d'une règle de largeur de bande réservée.
dscontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate niveau dscontrol rule set 9.22.21.3:80:rbweval evaluate niveau
Vous pouvez attribuer la valeur port, règle ou upserversonrule au niveau d'évaluation. La valeur par défaut est port.
L'option permettant de mesurer les conditions de la règle dans les serveurs de la règle permet de configurer deux règles ayant les caractéristiques suivantes :
Par conséquence, lorsque le trafic dépasse le seuil des serveurs dans la première règle, le trafic est envoyé au serveur “site occupé" dans la deuxième règle. Lorsque le trafic descend en dessous du seuil des serveurs de la première règle, le nouveau trafic est de nouveau acheminé aux serveurs de la première règle.
Lors de l'utilisation des deux règles décrites dans l'exemple précédent, si vous attribuez l'option port à l'option d'évaluation pour la première règle (évaluation des conditions de la règle dans tous les serveurs du port), lorsque le trafic dépasse la limite de cette règle, le trafic est envoyé au serveur “site occupé" associé à la deuxième règle.
La première règle mesure l'ensemble du trafic du serveur (incluant le serveur “site occupé") sur le port afin de déterminer si le trafic a dépassé la limite. Alors que la surcharge diminue pour les serveurs associés à la première règle, le trafic se poursuit sur le serveur “site occupé" étant donné que le trafic sur ce port dépasse toujours la limite de la première règle.
Pour les composants Dispatcher et CBR : Vous activez la fonction d'affinité lorsque vous faites en sorte que le maintien de routage d'un port de clusters soit conservé. Lorsque vous configurez un port de cluster de telle sorte que le routage soit conservé, les demandes clients peuvent être dirigées vers le même serveur. Cette opération peut être effectuée en attribuant un nombre de secondes à l'option délai de maintien de routage au niveau de l'exécuteur, du cluster ou du port. Lorsque vous attribuez la valeur zéro au délai de maintien de routage, cette fonction est désactivée.
Lors de l'activation de l'affinité de ports croisés, les valeurs de délai de maintien de routage des ports partagés doit avoir la même valeur (différente de zéro). Pour plus d'informations, voir Affinité de ports croisés.
Pour le composant Site Selector : Vous activez la fonction d'affinité lorsque vous faites en sorte que le maintien de routage d'un nom de site soit conservé. La configuration du maintien de routage pour un nom de site permet au client d'utiliser le même serveur pour plusieurs requêtes de service annuaire. Cette opération peut être effectuée en attribuant un nombre de secondes à l'option délai de maintien de routage sur le nom de site. Lorsque vous attribuez la valeur zéro au délai de maintien de routage, cette fonction est désactivée.
Le délai de maintient de routage pour un serveur est le délai entre la fermeture d'une connexion et l'ouverture d'une nouvelle connexion au cours de laquelle un client est renvoyé au même serveur utilisé lors de la première connexion. Passé le délai de maintien de routage, le client peut être envoyé à un serveur autre que le premier. Ce délai est configuré à l'aide de la commande dscontrol executor, port ou cluster.
Lorsque l'affinité est désactivée, dès qu'une connexion TCP est reçue d'un client, Load Balancer utilise le serveur correct et lui transmet les paquets. Si une autre connexion arrive du même client, Load Balancer la traite comme si les deux connexions n'étaient pas liées et utilise à nouveau le serveur correct.
Lorsque l'affinité est activée, si une autre demande est reçue du même client, la demande est acheminée vers le même serveur.
Progressivement, le client arrête d'envoyer des transactions et l'enregistrement d'affinité disparaît. D'où l'importance du "délai" de maintien de routage. La durée de vie de chaque enregistrement d'affinité est déterminée en secondes par le "délai de maintien de routage". Lorsque des demandes suivantes sont reçues lors du délai de maintien de routage, l'enregistrement d'affinité est toujours valide et la demande est toujours acheminée vers le même serveur. Si aucune connexion supplémentaire n'est reçue lors du délai de maintien de routage, l'enregistrement est vidé. Un nouveau serveur sera sélectionné pour toute connexion reçue une fois ce délai écoulé.
La commande server down (dscontrol server down) est utilisée pour arrêter un serveur. Ce dernier ne s'arrête pas tant que le délai de maintien de routage n'arrive pas à expiration.
L'affinité de ports croisés s'applique uniquement aux méthodes d'acheminement MAC et NAT/NATP du composant Dispatcher.
L'affinité de ports croisés se définit comme l'extension à plusieurs ports de la fonction maintien de routage. Par exemple, si la demande d'un client est d'abord reçue par un port puis une deuxième demande de ce client par un autre port, l'affinité de ports croisés permet au répartiteur d'envoyer cette demande au même serveur. Pour utiliser cette fonction, les ports doivent :
Il est possible de relier plusieurs ports au même trans ports. Quand un même client se connectera, à l'avenir, sur le même port ou sur un port partagé, ses connexions seront traitées par le même serveur. Voici un exemple de configuration de ports multiples munis d'une affinité de ports croisés au port 10 :
dscontrol port set cluster:20 crossport 10 dscontrol port set cluster:30 crossport 10 dscontrol port set cluster:40 crossport 10
Après l'établissement de l'affinité de ports croisés, vous disposez de la possibilité de modifier le délai de maintien de routage du port. Il est cependant recommandé de choisir la même valeur pour tous les délais de maintien de routage des ports partagés. Dans le cas contraire, des résultats inattendus peuvent se produire.
Pour supprimer l'affinité de ports croisés, replacez la valeur trans ports sur son propre numéro de port. Voir dscontrol port — Configuration des ports, pour plus d'informations sur la syntaxe de commande de l'optiontrans ports.
Le masque d'adresse de l'affinité ne s'applique qu'au composant Dispatcher.
Le masque d'adresse de l'affinité est une amélioration de la fonction de maintien de routage, destinée aux clients de groupe situés à des adresses de sous-réseau communes. La sélection du masque de maintien de routage de la commande dscontrol port permet de masquer les bits communs à poids fort de l'adresse IP sur 32 bits. Si cette fonction est configurée lors de la première connexion d'un client à un port, alors toutes les connexions suivantes des clients ayant la même adresse de sous-réseau (indiquée par la partie masquée de l'adresse) seront dirigées vers le même serveur.
Par exemple, si vous souhaitez que toutes les demandes client disposant d'une adresse de réseau classe A identique soient envoyées au même serveur, fixez à 8 (bits) la valeur du port du masque de maintien de routage. En ce qui concerne les demandes de clients de groupe possédant la même adresse de réseau classe B, fixez la valeur du masque de maintien de routage à 16 (bits). Pour les demandes de clients de groupe disposant de la même adresse de réseau classe C, fixez la valeur du masque de maintien de routage à 24 (bits).
Pour obtenir de meilleurs résultats, fixez la valeur du masque de maintien de routage dès le lancement de Load Balancer. Si vous modifiez cette valeur, les résultats seront imprévisibles.
Interaction avec l'affinité de ports croisés : Lors de l'activation de l'affinité de ports croisés, les valeurs du masque de maintien de routage des ports partagés doivent être identiques. Pour plus d'informations, voir Affinité de ports croisés.
Pour activer le masque d'adresse d'affinité, émettez une commande dscontrol port du type :
dscontrol port set cluster:port stickytime 10 stickymask 8
Les valeurs possibles des masques de maintien de routage sont 8, 16, 24 et 32. Une valeur de 8 indique que les 8 premiers bits à poids fort de l'adresse IP (adresse de réseau classe A) seront masqués. Une valeur de 16 indique que les 16 premiers bits à poids fort de l'adresse IP (adresse de réseau classe B) seront masqués. Une valeur de 24 indique que les 24 premiers bits à poids fort de l'adresse IP (adresse de réseau classe C) seront masqués. Si vous spécifiez une valeur de 32, l'adresse IP toute entière sera masquée, ce qui entraînera la désactivation de la fonction de masque d'adresse d'affinité. La valeur par défaut du masque de maintien de routage est 32.
Voir dscontrol port — Configuration des ports, pour plus d'informations sur la syntaxe de commande du masque de maintien de routage(fonction de masque d'adresse d'affinité).
La mise au repos de la gestion des connexions s'applique aux composants Dispatcher et CBR.
Pour retirer un serveur de la configuration Load Balancer quelle qu'en soit la raison (mises à jour, mises à niveau, service, etc.), vous pouvez utiliser la commande dscontrol manager quiesce . La sous-commande quiesce permet aux connexions de s'achever (sans avoir été traitées) et transmet les connexions ultérieures du client vers le serveur mis au repos si la connexion est associée à un délai de maintien de routage et que ce dernier n'est pas arrivé à expiration. La sous-commande quiesce désactive toute nouvelle connexion au serveur.
Utilisez l'option "Mettre au repos maintenant" si le délai de maintien de routage est défini et que vous voulez que les nouvelles connexions soient envoyées à un autre serveur (et non au serveur mis au repos) avant que le délai de maintien de routage n'expire. Voici un exemple d'utilisation de cette option pour mettre le serveur 9.40.25.67 au repos :
dscontrol manager quiesce 9.40.25.67 now
L'option now détermine comment les options avec maintien de routage seront gérées.
Il s'agit de la manière la moins brusque de placer des serveurs au repos. Par exemple, vous pouvez mettre au repos un serveur puis attendre le moment où le trafic est faible (peut-être le matin) pour retirer complètement le serveur de la configuration.
Vous pouvez définir les types d'affinité suivants dans la commande dscontrol rule :
L'affinité de cookie actif ne s'applique qu'au composant CBR.
L'affinité de cookie passif s'applique au composant CBR et à la méthode d'acheminement CBR du composant Dispatcher.
L'affinité d'URI s'applique au composant CBR et à la méthode d'acheminement CBR du composant Dispatcher.
L'option d'affinité par défaut est "none". La valeur zéro (inactif) doit être associée à l'option stickytime de la commande port pour affecter la valeur de cookie actif ou URI à l'option d'affinité de la commande rule. Lorsque l'affinité de cette dernière est définie, il devient impossible d'activer l'option stickytime de la commande port.
L'affinité de cookie actif ne s'applique qu'au composant CBR.
Elle permet de “fidéliser” les clients à un serveur donné. Pour l'activer, attribuez un nombre positif au paramètre stickytime (délai de maintien de routage) d'une règle et optez pour l'affinité de cookie actif (“activecookie”), lors de l'ajout de la règle ou à l'aide de la commande rule set. Pour obtenir des informations sur la syntaxe de cette commande, voir dscontrol rule — Configuration des règles.
Lorsqu'une règle a été activée pour l'affinité de cookie actif, l'équilibrage de charge des nouvelles demandes client est effectué à l'aide d'algorithmes CBR standard, tandis que les demandes suivantes du même client sont envoyées au serveur initialement choisi. Le serveur choisi est stocké en tant que cookie dans la réponse au client. Tant que les demandes suivantes du client contiennent ce cookie et qu'elles arrivent dans le délai de maintien de routage, le client conserve l'affinité pour le serveur initial.
L'affinité de cookie actif permet d'assurer qu'un client fait l'objet d'un équilibrage de charge vers le même serveur pendant une période déterminée. A cet effet, un cookie est envoyé pour être stocké par le navigateur des clients. Ce cookie indique les cluster:port:règle adoptés pour la prise de décision, le serveur cible de l'équilibrage de charge et la date d'expiration de l'affinité. Il est au format suivant : IBMCBR=cluster:port:règle+serveur-heure! Les informations cluster:port:règle et serveur sont codées pour ne révéler aucune information sur la configuration CBR.
Lorsqu'une règle est déclenchée et que l'affinité de cookie actif est activée, le cookie envoyé par le client est examiné.
Le nouveau cookie est ensuite inséré dans les en-têtes qui reviennent au client. Le navigateur du client renvoie les demandes suivantes lorsqu'il est configuré pour accepter les cookies.
Chaque instance d'affinité du cookie a une longueur de 65 octets et se termine au point d'exclamation. Ainsi, un cookie de 4096 octets peut contenir environ 60 règles de cookie actif individuel par domaine. Une fois le cookie entièrement plein, les instances d'affinité expirées sont supprimées. Si toutes les instances sont encore valides, les plus anciennes sont supprimées et les nouvelles pour la règle en cours ajoutées.
Pour la commande rule, vous ne pouvez attribuer que la valeur activecookie (cookie actif) à l'option d'affinité de cookie actif lorsque le délai de maintien de routage est zéro (non activé). Lorsque l'affinité de cookie actif est active au niveau d'une règle, vous ne pouvez pas activer le maintien de routage sur le port.
Pour activer l'affinité de cookie actif pour une règle donnée, utilisez la commande rule set :
rule set cluster:port:règle stickytime 60 rule set cluster:port:règle affinity activecookie
Le maintien de routage d'une règle est normalement utilisé pour les interfaces CGI ou les servlets qui enregistrent l'état du client sur le serveur. Cet état est identifié par un ID cookie (cookie serveur). L'état du client figure uniquement sur le serveur sélectionné. Pour maintenir cet état d'une demande à l'autre, le client a besoin du cookie du serveur.
Le délai d'expiration par défaut de l'affinité de cookie actif correspond au délai du serveur auquel s'ajoute le délai de maintien de routage plus vingt-quatre heures. Si les heures sont inexactes sur les systèmes de vos clients (ceux qui envoient des requêtes à la machine CBR), par exemple, s'ils dépassent de plus de 24 heures le délai du serveur), ces systèmes ignorent les cookies provenant de la CBR car ils considèrent que ces cookies ont déjà expiré. Pour rallonger le délai d'expiration, modifiez le script cbrserver. Dans le fichier script, modifiez la ligne javaw en y ajoutant le paramètre suivant après LB_SERVER_KEYS : -DCOOKIEEXPIREINTERVAL=X où X correspond au nombre de jours à ajouter au délai d'expiration.
Sur les systèmes AIX, Solaris et Linux, le fichier cbrserver se trouve dans le répertoire /usr/bin.
Sur les systèmes Windows, il se trouve dans le répertoire \winnt\system32.
L'affinité de cookie passif s'applique à la méthode d'acheminement CBR (content-based routing) du composant Dispatcher et au composant CBR. Pour obtenir la procédure de configuration de la méthode d'acheminement CBR de Dispatcher, voir Fonction CBR de Dispatcher (méthode d'acheminement cbr).
L'affinité de cookie passif offre une façon de fidéliser les clients à un serveur donné. Lorsque vous attribuez la valeur "cookiepassif" à l'affinité d'une règle, l'affinité de cookie passif permet d'équilibrer la charge du trafic Web destiné au même serveur, en fonction des cookies d'auto-identification générés par les serveurs. Vous configurez l'affinité de cookie passif au niveau de la règle.
Lors du déclenchement de la règle, si l'affinité de cookie passif est activée, Load Balancer choisit le serveur en fonction du nom du cookie se trouvant dans l'en-tête HTTP de la demande client. Load Balancer commence à comparer le nom du cookie dans l'en-tête HTTP du client à la valeur du cookie configurée pour chaque serveur.
La première fois que Load Balancer détecte un serveur dont la valeur de cookie contient le nom de cookie du client, Load Balancer choisit ce serveur pour la demande.
Si le nom du cookie est introuvable dans la demande client ou s'il ne correspond à aucun contenu des valeurs de cookie des serveurs, le serveur est choisi à l'aide de la méthode de sélection existante ou de la technique de permutation circulaire pondérée.
Pour configurer l'affinité de cookie passif :
Pour la commande rule, vous ne pouvez attribuer que la valeur “passivecookie” (cookie passif) à l'option d'affinité de cookie passif lorsque le délai de maintien de routage est zéro (non activé). Lorsque l'affinité de cookie passif est active au niveau d'une règle, il n'est pas possible d'activer le maintien de routage sur le port.
L'affinité d'URI s'applique à la méthode d'acheminement CBR de Dispatcher et au composant CBR. Pour obtenir la procédure de configuration de la méthode d'acheminement CBR de Dispatcher, voir Fonction CBR de Dispatcher (méthode d'acheminement cbr).
L'affinité URI permet d'équilibrer le trafic Web sur des serveurs Caching Proxy, ce qui permet de mettre en mémoire cache un contenu unique sur un serveur spécifique. Ainsi, vous augmentez la capacité de la mémoire cache du site en éliminant les éléments superflus placés en mémoire cache sur plusieurs machines. Configurez l'affinité d'URI au niveau de la règle. Une fois que la règle est déclenchée, si l'affinité d'URI est activée et que le même ensemble de serveurs est actif et répond,Load Balancer transmet les nouvelles demandes client entrantes ayant le même URI au même serveur.
Généralement, Load Balancer peut distribuer des demandes à plusieurs serveurs gérant un contenu identique. Lorsque vous utilisez Load Balancer avec un groupe de serveurs de mise en mémoire cache, le contenu dont l'accès est souvent demandé peut être placé dans la mémoire cache de tous les serveurs. En répliquant le contenu placé en mémoire cache identique, vous pouvez prendre en charge un grand nombre de clients. Cela est particulièrement utile pour les sites Web dont le volume est important.
Cependant, si le site Web prend en charge un trafic client modéré vers un contenu très divers et que vous préférez une mémoire cache répartie sur plusieurs serveur, votre site sera plus performant si chaque serveur de mise en cache comporte un contenu unique et que Load Balancer distribue la demande uniquement au serveur de mise en cache avec ce contenu.
Avec l'affinité d'URI, Load Balancer vous permet de distribuer le contenu mis en cache vers des serveurs individuels, éliminant la mise en cache superflue de contenu sur plusieurs machines. Grâce à cette fonction, les performances des sites ayant un contenu divers utilisant les serveurs Caching Proxy sont améliorées. Les demandes identiques sont envoyées au même serveur, plaçant ainsi en mémoire cache le contenu uniquement sur les serveurs individuels. La taille de la mémoire cache s'accroît avec chaque nouveau serveur ajouté au pool.
Pour configurer l'affinité d'URI :
Pour la commande rule, vous ne pouvez attribuer que la valeur “URI” à l'option d'affinité d'URI lorsque le délai de maintien de routage est zéro (non activé). Lorsque l'affinité d'URI est active au niveau d'une règle, il n'est pas possible d'activer le maintien de routage sur le port.
Cette fonction est disponible uniquement pour le composant Dispatcher.
Si vous n'utilisez ni le support de réseau étendu de Dispatcher ni la méthode d'acheminement CBR de Dispatcher, la configuration de Dispatcher requiert que la machine Dispatcher et ses serveurs soient tous connectés au même segment de réseau local (voir la figure 32). Une demande client arrive à la répartiteur et est envoyée au serveur. Du serveur, la réponse est renvoyée directement au client.
La fonction de répartiteur étendu permet la prise en charge des serveurs hors site, appelés serveurs éloignés (voir la figure 33). Si GRE n'est pas pris en charge sur le site distant et que la méthode d'acheminement NAT de Dispatcher n'est pas utilisée, le site distant doit correspondre à une machine Dispatcher éloignée (Dispatcher 2) et aux serveurs associés localement (Serveur G, Serveur H et Serveur I). Le paquet d'un client passe d'Internet à la machine Dispatcher initiale. Il passe ensuite à un système Dispatcher éloigné géographiquement et enfin à l'un de ses serveurs locaux.
Tous les systèmes Dispatcher (locaux ou éloignés) doivent exécuter le même type de système d'exploitation et de plateforme pour exécuter des configurations de réseau étendu.
Cela permet à une adresse de cluster de supporter l'ensemble des demandes client du monde entier, tout en répartissant la charge entre l'ensemble des serveurs.
Le système Dispatcher qui reçoit le paquet en premier peut tout de même être connecté à des serveurs locaux et répartir la charge entre ses serveurs locaux et les serveurs éloignés.
Pour configurer un support de réseau étendu :
dscontrol server add cluster:port:serveur router adresse
Pour obtenir plus d'informations sur le mot clé router, voir dscontrol server — Configuration des serveurs.
Sur les machines Dispatcher servant de point d'entrée :
Un répartiteur de point d'entrée traite Dispatcher de second niveau en tant que serveur et il surveille sa santé en tant que serveur et associe les résultats à l'adresse IP du répartiteur.
Sur des répartiteurs éloignés : Exécutez les étapes de configuration suivantes pour chaque adresse de cluster éloignée. Pour définir une configuration de haute disponibilité à l'emplacement éloigné du composant Dispatcher, vous devez effectuer l'opération sur les deux systèmes.
Systèmes AIX
ifconfig en0 alias 10.10.10.99 netmask 255.255.255.255
dscontrol executor configure 204.67.172.72 en0 255.255.255.255
Systèmes HP-UX, Linux, Solaris et Windows
Cet exemple s'applique à la configuration illustrée à la figure 34.
Vous trouverez ci-après la méthode à utiliser pour configurer les machines Dispatcher afin qu'elles supportent l'adresse de cluster xebec sur le port 80. LB1 est défini comme «point d'entrée». Il est supposé qu'une connexion Ethernet est utilisée. LB1 comporte cinq serveurs définis : trois serveurs locaux (ServeurA, ServeurB, ServeurC) et deux serveurs éloignés (LB2 et LB3). Par ailleurs, trois serveurs locaux ont été définis pour chacun des serveurs éloignés LB2 et LB3.
Sur la console de la première machine Dispatcher (LB1), procédez comme suit :
dscontrol executor start
dscontrol executor set nfa LB1
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure xebec
Sur la console de la deuxième machine Dispatcher (LB2) :
dscontrol executor start
dscontrol executor set nfa LB2
dscontrol cluster add xebec
dscontrol port add xebec:80
Sur la console de la troisième machine Dispatcher (LB3) :
dscontrol executor start
dscontrol executor set nfa LB3
dscontrol cluster add xebec
dscontrol port add xebec:80
GRE (Generic Routing Encapsulation) est un protocole Internet défini dans RFC 1701 et RFC 1702. Lorsque vous utilisez GRE, Load Balancer peut encapsuler les paquets IP de clients dans des paquets IP/GRE et les transmettre aux plateformes de serveur telles qu'OS/390 qui prend en charge GRE. Le support GRE permet au composant Dispatcher d'équilibrer la charge des paquets sur plusieurs adresses de serveurs associées à une adresse MAC.
Load Balancer implémente GRE en tant qu'élément de sa fonction de réseau étendu. Ainsi, Load Balancer peut fournir l'équilibrage de charge de réseau étendu directement aux systèmes de serveur pouvant désencapsuler les paquets GRE. Il n'est pas nécessaire que Load Balancer soit installé sur le site éloigné si les serveurs éloignés prennent en charge les paquets GRE encapsulés. Load Balancer encapsule les paquets WAN, la valeur décimale 3735928559 étant attribuée à l'ensemble de zones de clés GRE.
Dans cet exemple (figure 35), afin d'ajouter le serveurD éloigné, qui prend en charge GRE, définissez-le dans la configuration Load Balancer comme si vous définissiez un serveur WAN dans la hiérarchie cluster:port:serveur :
dscontrol server add cluster:port:ServeurD router Routeur1
Les systèmes Linux disposent en natif d'une possibilité d'excapsulation GRE permettant à Load Balancer d'équilibrer la charge d'images de serveur Linux pour S/390, lorsque de nombreuses images de serveur se partagent une adresse MAC. Ainsi, le point d'entrée Load Balancer peut équilibrer la charge directement sur des serveurs Linux WAN sans passer par Load Balancer sur le site éloigné. Les conseillers du point d'entrée Load Balancer peuvent alors traiter directement chaque serveur éloigné.
Sur le point d'entrée Load Balancer, procédez à la configuration décrite pour WAN.
Pour configurer chaque serveur dorsal Linux, entrez les commandes ci-après en tant que superutilisateur. (Ces commandes peuvent être ajoutées à la fonction de démarrage du système de sorte que les modifications sont conservées entre les réamorçages.)
# modprobe ip_gre # ip tunnel add gre-nd mode gre ikey 3735928559 # ip link set gre-nd up # ip addr add adresse_cluster dev gre-nd
En règle générale, les fonctions d'équilibrage de charge de Dispatcher fonctionnent indépendamment de la physionomie des sites sur lesquels le produit est installé. Il existe une zone, cependant, dans laquelle le contenu du site peut s'avérer important, et dans laquelle les décisions prises au sujet de ce contenu peuvent avoir une influence non négligeable sur l'efficacité de Dispatcher. Il s'agit de la zone d'adressage de liens.
Lorsque vos pages indiquent des liens pointant sur des serveurs individuels de votre site, un client est en réalité forcé à s'adresser à une machine déterminée, détournant de ce fait toute fonction d'équilibrage de charge éventuellement mise en oeuvre. Pour cette raison, utilisez systématiquement l'adresse de Dispatcher dans tous les liens figurant sur vos pages. Il est à noter que le type d'adressage utilisé n'est pas toujours apparent, notamment si votre site applique une procédure de programmation automatique permettant la création dynamique de HTML. Pour optimiser l'équilibrage de charge, identifiez les éventuelles occurrences d'adressage explicite et évitez-les autant que possible.
Vous pouvez configurer Dispatcher et les machines serveurs TCP de sorte qu'ils utilisent un réseau privé. Cette configuration peut réduire l'encombrement des accès utilisateurs ou du réseau externe, susceptible d'affecter les performances.
Pour les systèmes AIX, cette configuration peut également tirer parti des vitesses élevées du commutateur SP High Performance Switch, si vous utilisez Dispatcher et les machines serveurs TCP comme noeuds sur un cadre SP.
Pour créer un réseau privé, chaque machine doit être équipée d'au moins deux cartes de réseau local, l'une d'elles étant reliée au réseau privé. La deuxième carte de réseau local doit être également configurée sur un sous-réseau différent. La machine Dispatcher transmettra alors les demandes aux machines serveurs TCP par l'intermédiaire du réseau privé.
Systèmes Windows : Configurez également chaque adresse NFA avec la commande executor configure.
Les serveurs ajoutés à l'aide de la commande dscontrol server add doivent être ajoutés avec les adresses de réseau privé. Par exemple, reprenant le cas du serveur A de la figure 36, la syntaxe de la commande sera la suivante :
dscontrol server add adresse_cluster:80:10.0.0.1
et non
dscontrol server add adresse_cluster:80:9.67.131.18
Si vous utilisez Site Selector pour fournir des données de charge à Dispatcher, Site Selector doit être configuré pour acheminer ces états vers les adresses privées.
L'utilisation d'une configuration de réseau privé ne s'applique qu'au composant Dispatcher.
L'utilisation d'un cluster générique pour combiner les configurations serveurs ne s'applique qu'au composant Dispatcher.
Le terme “générique” fait référence à l'aptitude du cluster à s'adapter à plusieurs adresses IP (c'est-à-dire à fonctionner comme un "joker"). L'adresse 0.0.0.0 permet d'indiquer un cluster générique.
Si vous devez assurer l'équilibrage de plusieurs adresses de cluster ayant des configurations port/serveur identiques, vous pouvez combiner tous les clusters dans une seule configuration de cluster générique.
Vous devez toujours configurer de manière explicite chaque adresse de cluster sur les cartes réseau de votre poste Dispatcher. Toutefois, vous ne devez ajouter aucune des adresses de cluster à la configuration de Dispatcher à l'aide de la commande dscontrol cluster add.
Ajoutez simplement le cluster générique (adresse 0.0.0.0), et configurez les ports et les serveurs correctement pour l'équilibrage de charge. Tout trafic à destination des adresses configurées sur les cartes est équilibré en utilisant la configuration du cluster générique.
L'avantage de cette approche réside dans le fait que le trafic vers toutes les adresses de clusters est pris en compte lors du choix du meilleur serveur. Si un cluster est particulièrement chargé et qu'il a créé de nombreuses connexions sur l'un des serveurs, le trafic vers les autres adresses de cluster est équilibré en tenant compte de cette information.
Vous pouvez combiner le cluster générique avec des clusters réels si certaines adresses de cluster ont une configuration port/serveur unique alors que d'autres partagent la même configuration. Les configurations uniques doivent être attribuées à une adresse de cluster réelle. Toutes les configurations communes peuvent être attribuée au cluster générique.
L'utilisation du cluster générique pour équilibrer la charge des pare-feux ne s'applique qu'au composant Dispatcher. L'adresse 0.0.0.0 permet d'indiquer un cluster générique.
Vous pouvez utiliser le cluster générique pour équilibrer le trafic vers des adresses qui ne sont pas explicitement configurées sur une carte réseau du poste Dispatcher. Pour que cela fonctionne, le répartiteur doit au moins être en mesure de voir la totalité du trafic qu'il est supposé équilibrer. Le poste répartiteur ne verra pas le trafic vers des adresses non explicitement configurées sur l'une de ses cartes réseau, excepté s'il est configuré en tant que route par défaut pour certains trafic.
Une fois Dispatcher configuré comme route par défaut, le trafic TCP ou UDP passant par la machine Dispatcher est équilibré en utilisant la configuration du cluster générique.
C'est ce principe qui est utilisé pour équilibrer les pare-feux. Les pare-feux peuvent traiter des paquets à destination de n'importe quelle adresse et de n'importe quel port. Pour cette raison, vous devez être en mesure d'équilibrer le trafic indépendamment de l'adresse ou du port cible.
Les pare-feux permettent de gérer le trafic de clients non sécurisés vers des serveurs sécurisés et les réponses de ces serveurs, ainsi que le trafic de clients sécurisés vers des serveurs non sécurisés et les réponses de ces derniers.
Vous devez configurer deux machines Dispatcher : l'une pour envoyer le trafic non-sécurisé vers les adresses de pare-feux non sécurisés et l'autre le trafic sécurisé vers les adresses de pare-feux sécurisés. Comme ces deux machines Dispatcher doivent utiliser le cluster générique et le port générique avec des adresses de serveur différentes, les deux répartiteurs doivent se trouver sur deux machines distinctes.
L'utilisation du cluster générique avec Caching Proxy pour le proxy transparent ne s'applique qu'au composant Dispatcher. L'adresse 0.0.0.0 permet d'indiquer un cluster générique.
La fonction de cluster générique permet également d'utiliser Dispatcher pour activer une fonction de proxy transparent pour un serveur Caching Proxy se trouvant sur le même système que Dispatcher. Cette fonction est disponible sous AIX uniquement car il doit y avoir communication entre le composant dispatcher et le composant TCP du système d'exploitation.
Pour activer cette fonction, vous devez lancer Caching Proxy écoutant les demandes client sur le port 80. Vous configurez ensuite un cluster générique (0.0.0.0). Dans le cluster générique, vous configurez le port 80. Dans le port 80, vous configurez l'adresse NFA de la machine Dispatcher en tant que serveur unique. Désormais, tout trafic client vers une adresse du port 80 est acheminé vers le serveur Caching Proxy exécuté sur le poste de travail Dispatcher. La demande client est ensuite traitée par un proxy comme d'habitude et la réponse est envoyée de Caching Proxy au client. Dans ce mode, le composant Dispatcher n'effectue pas l'équilibrage de charge.
Le port générique permet de gérer le trafic destiné à un port non explicitement configuré. Ce principe est utilisé pour équilibrer la charge des pare-feux. Il est également utilisé pour assurer la bonne gestion du trafic destiné à un port non configuré. En définissant un port générique sans serveur, vous garantissez que toutes les demandes en direction de ce port non configuré sont supprimées et non renvoyées au système d'exploitation. Le numéro de port 0 (zéro) permet d'indiquer un port générique, par exemple :
dscontrol port add cluster:0
Lors de la configuration d'un cluster pour le traitement du port FTP passif et du port générique, le port FTP passif utilise par défaut l'intégralité de la fourchette de ports TCP non privilégiés pour les connexions aux données. Cela signifie que pour un client connecté via un cluster d'équilibrage de charge à un port de contrôle FTP, toutes les connexions de contrôle ultérieures et les connexions aux ports dont le numéro est élevé (port > 1023) à ce même cluster seront automatiquement acheminées par Load Balancer vers le même serveur que la connexion de contrôle FTP.
Si le port générique et le port FTP d'un même cluster ne possèdent pas le même jeu de serveurs, les applications dont le numéro de port est élevé (port > 1023) peuvent échouer lorsqu'il existe une connexion de contrôle FTP pour un client. Par conséquent, la configuration de jeux de serveurs différents pour le port FTP et le port générique sur un même cluster n'est pas recommandée. Si vous optez pour ce scénario, la fourchette de ports passifs du démon FTP doit être définie dans la configuration de Load Balancer.
Cette fonction est disponible uniquement pour le composant Dispatcher.
Dispatcher permet de détecter les attaques de "refus de service" possible et d'en alerter l'administrateur. Pour cela, Dispatcher analyse les demandes entrantes d'un certain nombre de connexions partielles TCP sur les serveurs, point commun des attaques de refus de service. Dans une attaque de refus de service, un site reçoit une grand nombre de paquets SYN d'un grand nombre d'adresses IP source et de numéros de port source, mais le site ne reçoit pas les paquets suivants de ces connexions TCP. De cette manière, vous avez un grand nombre de connexion partielles TCP sur les serveurs. Les serveurs peuvent devenir très lents et peuvent ne plus accepter de nouvelles connexions entrantes.
Load Balancer fournit des exit utilisateur qui déclenchent des scripts que vous pouvez personnaliser. Ces scripts avertissent l'administrateur d'une attaque de refus de service possible. Dispatcher fournit des exemples de fichier script dans le répertoire suivant :
Les scripts suivants sont disponibles :
Pour pouvoir exécuter les fichiers, vous devez les déplacer dans le répertoire suivant et supprimer l'extension de fichier "sample" :
Pour implémenter la détection d'attaque DoS, définissez le paramètre maxhalfopen dans la commande dscontrol port de la manière suivante :
dscontrol port set 127.40.56.1:80 maxhalfopen 1000
Dans l'exemple ci-dessus, Dispatcher compare le nombre total de connexions partielles (pour tous les serveurs se trouvant sur le cluster 127.40.56.1 du port 80) avec la valeur maximale de 100 (indiqué par le paramètre maxhalfopen). Si le nombre de connexions partielles dépasse la limite, un script d'alerte (halfOpenAlert) est appelé. Lorsque le nombre de connexions partielles est inférieur à la limite, un autre script d'alerte (halfOpenAlertDone) est effectué pour indiquer que l'attaque est terminée.
Pour déterminer comment définir la valeur maxhalfopen : Régulièrement (toutes les 10 minutes, par exemple), effectuez un rapport de connexion partielle ( dscontrol port halfopenaddressreport cluster:port ) lorsque le trafic de votre site est normal ou élevé. Le rapport de connexion partielle renvoie un message "Nombre total de connexions partielles reçues". Vous devez attribuer au paramètre maxhalfopen une valeur supérieure de 50 à 200% au nombre le plus élevée de connexions partielles rencontrées par votre site.
Le paramètre halfopenaddressport permet d'effectuer un rapport de données statistiques ainsi que de générer des entrées dans le journal (..ibm/edge/lb/servers/logs/dispatcher/halfOpen.log) pour toutes les adresses client (jusqu'à environ 8000 paires d'adresses) qui ont accédé à des serveurs disposant de connexions partielles.
Pour renforcer la protection des serveurs dorsaux contre les attaques de refus de service, vous pouvez configurer des clusters et des ports génériques. En particulier, ajoutez sous chaque cluster configuré un port générique sans serveur. Ajoutez également un cluster générique doté d'un port générique, mais sans serveur. Ces actions ont pour résultat le rejet des paquets qui ne sont pas adressés à un cluster ni à un port non génériques. Pour obtenir des informations sur les clusters et les ports génériques, voir Utilisation d'un cluster générique pour combiner les configurations serveurs et Utilisation du port générique pour acheminer le trafic destiné à un port non configuré.
La fonction de consignation binaire permet de stocker les informations du serveur dans des fichiers binaires. Ces fichiers peuvent ensuite être traités pour analyser les informations relatives aux serveurs qui ont été rassemblées.
Les informations suivantes sont stockées dans le journal binaire pour chaque serveur défini dans la configuration.
Certaines de ces informations sont extraites de l'exécuteur comme faisant partie du cycle du gestionnaire. C'est pourquoi, le gestionnaire doit être en cours d'exécution afin que les informations puissent être consignées dans les journaux binaires.
Utilisez l'ensemble de commandes dscontrol binlog pour configurer la consignation binaire.
L'option start commencer à consigner les informations relatives au serveur dans les journaux binaires du répertoire logs. Un journal est créé au début de chaque heure, la date et l'heure constituant le nom du fichier.
L'option stop arrête la consignation des informations relatives au serveur dans les journaux binaires. Le service de consignation est arrêté par défaut.
L'option set interval contrôle la fréquence d'inscription des informations dans les journaux. Le gestionnaire enverra les informations du serveur au serveur de consignation à chaque intervalle défini pour le gestionnaire. Les informations sont écrites dans les journaux uniquement si l'intervalle de consignation indiqué a expiré depuis l'écriture du dernier enregistrement dans le journal. Par défaut, la valeur de l'intervalle de consignation est 60 secondes. Il y a interaction entre les paramètres relatifs à l'intervalle défini pour le gestionnaire et l'intervalle de consignation. Comme les informations ne sont pas fournies au serveur de consignation plus fréquemment que l'intervalle défini pour le gestionnaire, l'indication d'un intervalle de consignation inférieur à l'intervalle du gestionnaire, entraîne en réalité la définition d'un intervalle de consignation identique à l'intervalle du gestionnaire. Cette technique de consignation permet d'accéder aux informations du serveur quel que soit le niveau de granularité. Vous pouvez connaître toutes les modifications apportées au serveur qui sont vues par le gestionnaire pour le calcul des pondérations du serveur. Cependant, ces informations peuvent ne pas être requises pour analyser l'utilisation et les tendances du serveur. La consignation des informations du serveur toutes les 60 secondes permet d'obtenir un aperçu de la progression des informations du serveur. La définition d'un intervalle de consignation très faible peut générer un nombre de données très important.
L'option set retention permet de contrôler la durée de conservation des fichiers journaux. Les journaux dont la durée de vie a dépassé la durée définie sont supprimés par le serveur de consignation. Cela se produit uniquement si le serveur de consignation est appelé par le gestionnaire. Par conséquent, si le gestionnaire est arrêté, les fichiers journaux plus anciens ne sont pas supprimés.
L'option status renvoie les paramètres courants de la fonction de consignation, c'est-à-dire l'état actif ou inactif du service, l'intervalle de consignation et la durée de conservation.
Un exemple de programme Java et un fichier de commandes ont été fournis dans le répertoire suivant :
Ce modèle indique comment rappeler toutes les informations contenues dans les fichiers journaux pour les afficher à l'écran. Il peut être personnalisé pour effectuer n'importe quel type d'analyse. Par exemple (à l'aide du script et du programme fournis) :
dslogreport 2001/05/01 8:00 2001/05/01 17:00
Cet exemple permet d'obtenir un rapport sur les informations du serveur Dispatcher de 8 à 17 heures le premier mai 2001. (Pour CBR, utilisez cbrlogreport.)
Seuls les systèmes Linux acceptent des configurations dans lesquelles le client réside sur la même machine que Load Balancer.
Les configurations avec client co-implanté risque de ne pas fonctionner correctement sur les autres plateformes car Load Balancer utilise des techniques différentes pour examiner les paquets entrants selon les systèmes d'exploitation pris en charge. La plupart du temps, sur les systèmes autres que Linux, Load Balancer ne reçoit pas de paquets de la machine locale. Il reçoit les paquets provenant uniquement du réseau. C'est la raison pour laquelle les demandes envoyées à l'adresse du cluster à partir de la machine locale ne sont pas reçues par Load Balancer et ne peuvent pas être traitées.