19.1 Évaluation avancée des coûts de renvoi

Les applications serveur communiquent souvent avec d'autres serveurs via un client intégré (Dclient), car un seul serveur ne contient pas toutes les données eDirectory nécessaires au fonctionnement d'une application. Un exemple est le protocole NLDAP, lorsqu'il est configuré pour chaîner les requêtes.

Lorsqu'une application serveur demande des données que le serveur local n'héberge pas, le serveur identifie un autre serveur qui contient les données demandées et les récupère pour le client. Ce procédé est appelé « navigation dans l'arborescence ». Évidemment, un serveur mettra plus de temps à exécuter une requête via la navigation dans l'arborescence. Même si les meilleures pratiques relatives à la conception de l'arborescence eDirectory permettent de réduire le besoin de recourir à la navigation dans l'arborescence, il est parfois encore nécessaire d'avoir recours à ce procédé.

Figure 19-1 Évaluation avancée des coûts de renvoi

La Figure 19-1 illlustre une recherche du nom commun cn=GHowe dans une sous-arborescence LDAP adressée au serveur A. La recherche commence à partir de O=MyCorp. Toutefois, l'objet cn=GHowe se trouve sur la partition ou=MidWest, laquelle n'est pas représentée sur le serveur A.

Pour localiser un serveur contenant les données nécessaires pour répondre à la demande du client, le serveur A doit récupérer les données sur le serveur B ou C. Pour ce faire, le serveur A doit envoyer la requête au serveur B ou C. Dans le cas présent, le serveur A choisit le serveur B. Notez que le processus de sélection du serveur est imprévisible. Le serveur B est disponible sur le réseau et accepte la requête, mais ne peut pas l'exécuter rapidement. Le serveur A attend que le serveur B traite la requête, alors que le serveur C pourrait également fournir les données requises. La requête envoyée par le serveur A est mise en attente jusqu'à ce que le serveur B l'exécute ou ne soit plus disponible sur le réseau.

Les sections suivantes expliquent comment améliorer les performances des serveurs eDirectory :

19.1.1 Amélioration de la connexion entre les serveurs

Le système d'évaluation avancée des coûts de renvoi (ARC) est un algorithme d'évaluation des coûts amélioré. Il sert principalement à empêcher les pannes de serveur et peut offrir les avantages suivants :

Amélioration des performances et de la tolérance aux pannes des serveurs
Amélioration de la communication entre les serveurs
Distribution de la charge
Surveillance à distance de l'état de santé des serveurs
Distinction et identification plus aisées des problèmes de communication

À qui profite l'évaluation avancée des coûts de renvoi ?

L'évaluation avancée des coûts de renvoi est utile pour les serveurs qui n'hébergent pas une copie locale d'un objet ou d'un service et doivent parcourir l'arborescence pour trouver ces informations, car ils communiquent fréquemment avec les autres serveurs. L'évaluation avancée des coûts de renvoi est très efficace dans les environnements LDAP, en particulier lorsque le chaînage est privilégié.

La Figure 19-2 illustre le cas d'un serveur qui est parfois submergé par les demandes d'autres serveurs, qui lui adressent systématiquement leurs requêtes.

Figure 19-2 Effet du serveur unique

Bien que d'autres serveurs hébergeant des répliques des objets requis soient disponibles, ce serveur est systématiquement privilégié. Ceci s'explique par le fait que les serveurs qui ont besoin d'un service ou d'une réplique spécifique sont déjà connectés à ce serveur, si bien qu'ils ont tendance à lui envoyer toutes les requêtes qu'il peut traiter. La Figure 19-2 montre que toutes les requêtes émanant de S4 sont adressées à S1. S4 étant déjà connecté et authentifié auprès de S1, il continue à lui envoyer toutes les requêtes pour la partition bleue, alors que S2 et S3 pourraient aussi répondre à ces requêtes. L'évaluation avancée des coûts de renvoi permet d'éviter ces situations en répartissant la charge entre les serveurs qui répondent plus rapidement. Cette fonctionnalité doit être activée sur les serveurs distants (S4) qui sollicitent ce serveur ou peut être activée sur tous les serveurs.

La Figure 19-3 illustre un autre scénario, à savoir l'effet du « serveur en cascade ». Dans ce cas-ci, il arrive souvent que le serveur S1 ne réponde pas, sans pour autant qu'il soit hors service. S'il était hors service, les requêtes expireraient et la communication serait interrompue. Si le serveur est toujours fonctionnel au niveau du transport, mais que la base de données est lente ou occupée, le serveur continue à accepter les nouvelles requêtes provenant d'autres serveurs et les place en file d'attente. Le cas échéant, les autres serveurs (S2) peuvent finir par manquer de threads. Chaque requête en suspens prend un thread sur le serveur distant et lorsqu'il est à court de threads, le serveur ne répond plus. L'évaluation avancée des coûts de renvoi résout ce problème en répartissant les requêtes entre les serveurs les plus rapides, car le coût de traitement des requêtes est plus élevé lorsqu'un serveur est lent ou défaillant.

Figure 19-3 Effet du serveur en cascade

L'évaluation avancée des coûts de renvoi constitue également un excellent moyen d'améliorer la tolérance aux pannes, puisqu'elle permet d'identifier facilement les problèmes de communication des serveurs.

19.1.2 Avantages de la fonction d'évaluation des coûts de renvoi

Elle prévoit/achemine la plupart des requêtes de résolution de nom vers des serveurs distants au moment où elles sont soumises.
Elle calcule la moyenne des temps de traitement (en millisecondes) des requêtes de résolution de nom sur chaque adresse. Cela lui permet d'être plus précise et d'ajuster plus activement le coût du renvoi. Elle est également capable de détecter rapidement un serveur lent, car les temps de traitement sont calculés en millisecondes, et non en secondes.
Elle assure le suivi des requêtes en suspens, de manière à déterminer rapidement si une requête met trop de temps à être traitée. Elle ne doit pas attendre que la requête soit traitée pour savoir que le serveur est lent.
Elle assure le suivi des temps de réponse pour chaque adresse. Pour un serveur, il est normal d'avoir de nombreuses connexions à la même adresse. Grâce au suivi par adresse et non par connexion, une connexion peut profiter des statistiques collectées à partir d'autres connexions.

REMARQUE :pour évaluer les requêtes LDAP, la fonction d'évaluation avancée des coûts de renvoi tient également compte de la réactivité des connexions privées.

19.1.3 Déploiement de l'évaluation avancée des coûts de renvoi

L'évaluation avancée des coûts de renvoi est généralement déployée sur une base Serveur à serveur. Les serveurs sur lesquels l'évaluation avancée des coûts de renvoi est activée peuvent être informés des nouvelles informations relatives à l'évaluation des coûts. Vous devez activer l'évaluation avancée des coûts de renvoi sur chaque serveur de l'environnement.

Considérations sur le déploiement

Il n'est pas utile d'activer l'évaluation avancée des coûts de renvoi sur tous les serveurs. La Figure 19-4 illustre une situation susceptible de nuire à l'efficacité des serveurs LDAP. Sur la figure, le serveur S4 héberge une copie de la partition verte, mais pas de la partition bleue. Pour être exécutée, toute requête LDAP de chaînage qui requiert des informations issues de la partition bleue doit être adressée au serveur S1, S2 ou S3. L'évaluation avancée des coûts de renvoi a été précisément conçue pour faire face ce genre de situation et se révèle efficace dans la plupart des cas.

Figure 19-4 Considérations relatives au déploiement de l'évaluation avancée des coûts de renvoi

Cependant, effectuer certaines opérations LDAP peut s'avérer difficile. Ainsi, même s'il est possible d'ajouter un utilisateur, par exemple, Bob.Blue.Novell, il se peut que l'opération échoue si vous essayez immédiatement de le modifier. La figure montre que Bob a bien été ajouté sur S2, mais que sa modification sur S3 a échoué, car S3 n'a pas encore été synchronisé avec S2 ou n'a pas encore reçu Bob. L'évaluation avancée des coûts de renvoi a la capacité de vous diriger vers un autre serveur, car elle est plus dynamique que la méthode standard d'évaluation des coûts.

Cette configuration fonctionne bien lorsque les serveurs présentent des coûts qui ne varient pas énormément et n'ont pas de problèmes de synchronisation. La désactivation de l'évaluation avancée des coûts de renvoi sur S4 permet de résoudre ce problème.

19.1.4 Activation de l'évaluation avancée des coûts de renvoi

L'évaluation avancée des coûts de renvoi est activée par défaut pour eDirectory. Pour la configurer à l'aide de NDS iMonitor, cliquez sur Configuration de l'agent, puis sur Paramètres des processus en arrière-plan. Les options Activer, Désactiver et Débogage sont également disponibles.

Figure 19-5 Écran de configuration d'agent de NDS iMonitor

NDSTrace

Pour activer l'évaluation avancée des coûts de renvoi sur toutes les plates-formes UNIX, utilisez l'outil NDSTrace.

Tableau 19-1 Activation de l'évaluation avancée des coûts de renvoi sous UNIX

set NDSTRACE =!ARC	Affiche le tableau gv_ResolveTimesTable à des fins de débogage.
set NDSTRACE =!ARC0	Désactive l'évaluation avancée des coûts de renvoi.
set NDSTRACE =!ARC1	Active l'évaluation avancée des coûts de renvoi.
set NDSTRACE =!ARC2	Active l'évaluation avancée des coûts de renvoi en mode débogage et affiche les coûts occasionnés par chaque renvoi sur le drapeau DSTrace de résolution de nom à chaque fois qu'une décision est prise en matière d'évaluation des coûts.

19.1.5 Optimisation de l'évaluation avancée des coûts de renvoi

Par défaut, l'évaluation avancée des coûts de renvoi ne doit pas être optimisée. Toutefois, il est possible de configurer des paramètres pour modifier le fonctionnement de l'évaluation avancée des coûts de renvoi, ou pour désactiver ou activer certaines fonctions. L'évaluation avancée des coûts de renvoi inclut 3 composants majeurs.

Évaluation avancée des coûts

Pour évaluer les coûts d'une adresse donnée, le système d'évaluation avancée des coûts de renvoi utilise les informations connues à propos de la connexion pour calculer le coût du renvoi en question. Si la fonction ARC est activée, l'évaluation avancée des coûts est toujours utilisée pour calculer le coût d'un renvoi.

Surveillance en arrière-plan

Un thread d'arrière-plan vérifie régulièrement les informations de l'horloge pour s'assurer qu'elles sont à jour. Lorsqu'un serveur est lent, son coût augmente et il est fort probable que la communication soit interrompue. Le thread d'arrière-plan vérifie régulièrement (par défaut, toutes les minutes) si un serveur présent dans le tableau n'a pas été mis à jour. Si le serveur n'a pas été mis à jour au cours des trois dernières minutes, le serveur effectue, en son nom, une demande de résolution de nom afin de vérifier son état de santé. Cette opération permet de créer une évaluation actualisée des coûts du serveur et de déterminer si ce dernier est maintenant moins occupé, ou en bonne santé, afin qu'un client ne doive pas subir des effets néfastes pour vérifier l'état de santé du serveur. Deux paramètres de configuration permanents peuvent être modifiés pour le thread d'arrière-plan :

ARC_MAX_WAIT : délai de péremption d'une horloge avant qu'une requête de vérification d'état de santé ne soit envoyée au serveur (par défaut, 180 secondes).
ARC_BG_INTERVAL : fréquence d'exécution du thread d'arrière-plan (par défaut, 60 secondes ; si ce paramètre est défini sur 0, il est désactivé et le thread ne s'exécute pas).

Pour plus d'informations, reportez-vous à la section 8.4.24 relative à la définition de paramètres de configuration permanents.

Informations d'état de santé distantes

Les serveurs utilisant l'évaluation avancée des coûts de renvoi demandent périodiquement des informations d'état de santé à un serveur distant. Il ne s'agit pas de requêtes supplémentaires sur le réseau, mais d'informations d'état de santé complémentaires renvoyées dans les requêtes de résolution de nom standard régulièrement envoyées par les serveurs. Ces informations sont ensuite utilisées par l'algorithme d'évaluation des coûts afin d'améliorer les réactions par rapport aux serveurs qui présentent une charge importante. Lorsqu'une demande de résolution de nom est envoyée à un serveur distant, si plus de 15 secondes se sont écoulées depuis la dernière mise à jour, les informations d'état de santé sont demandées au serveur distant et sont ajoutées à la réponse à la demande de résolution de nom.

Un paramètre peut être réglé pour la surveillance de l'état de santé à distance :

ARC_DS_INFO_INTERVAL : fréquence à laquelle les informations de verrouillage (état de santé) sont demandées dans le cadre de l'évaluation avancée des coûts de renvoi (par défaut, 15 secondes).

19.1.6 Surveillance de l'évaluation avancée des coûts de renvoi

Pour assurer le suivi de l'évaluation avancée des coûts de renvoi, vous pouvez imprimer le tableau des temps de résolution.

Pour ce faire, utilisez les commandes suivantes :

set DSTRACE = +DBG
set DSTRACE = !ARC

Ces commandes permettent d'imprimer le tableau des temps de résolution et les informations actuellement stockées pour chaque serveur. Ce tableau indique l'adresse de transport, le nombre de millisecondes écoulées depuis la dernière utilisation de l'adresse, le dernier coût utilisé dans une décision de renvoi et le nombre de requêtes en suspens pour cette adresse.

Un grand nombre de requêtes en suspens n'est pas nécessairement problématique. Cela peut simplement signifier que ce serveur est fréquemment utilisé.

Utilisation de l'évaluation avancée des coûts de renvoi à des fins de dépannage

L'une des fonctions les plus utiles de l'évaluation avancée des coûts de renvoi est sa capacité à identifier rapidement les problèmes de communication des serveurs.

Le tableau ci-dessous est un exemple de tableau des temps de résolution au format imprimé.

L'évaluation avancée des coûts de renvoi est actuellement activée.

Tableau 19-2 Coûts associés aux temps de résolution

Slot	Transport Address	Cost	LastUse	Checked	Waiters	LockTime
1	tcp:151.155.134.27:524	214	14	14	0	0
2	tcp:151.155.134.11:524	0	0	0	0	0
3	udp:151.155.134.11:524	0	0	0	0	0
4	cp:151.155.134.13:524	554759	280	0	27	582
5	tcp:151.155.134.59:524	0	179	179	0	0
6	udp:151.155.134.59:524	0	119	119	0	0
7	tcp:151.155.134.28:524	1543	119	119	0	0
8	tcp:151.155.134.15:524	124	14	14	0	0

La version imprimée du tableau montre que du point de vue de ce serveur, l'adresse 151.155.134.13 rencontre des difficultés. On peut également voir que le problème vient très probablement du serveur, et non du transport. Le serveur compte 27 demandes d'accès à la base de données qui sont en attente, et les requêtes prennent énormément de temps à obtenir le verrouillage de la base de données. Ce serveur compte deux requêtes qui n'ont jamais reçu de réponse de la part du serveur distant.

On peut également voir que les serveurs 151.155.134.11 et 151.155.134.59 sont très rapides, ne sont pas fortement sollicités ou les deux. On voit que les serveurs 151.155.134.59 et 151.155.134.11 ont tous deux eu des problèmes de communication via le protocole TCP à un moment donné, mais qu'il sont désormais en bonne santé, car ils disposent tous deux de connexions UDP. Les connexions UDP à un serveur ne sont utilisées qu'en cas de problème de communication avec ce serveur via le protocole TCP.

Les différents champs du tableau sont expliqués ci-dessous :

Transport Address : adresse du serveur distant.

Cost : coût actuel du serveur distant.

Last Use : nombre de secondes écoulées depuis la dernière communication avec le serveur.

Checked : nombre de secondes écoulées depuis la dernière fois que des informations d'état de santé ont été obtenues de la part du serveur distant.

#Req : nombre de requêtes en suspens adressées au serveur distant.

Waiters : nombre de requêtes adressées au serveur distant en attente du verrouillage de la base de données.

LockTime : période pendant laquelle un processus a maintenu la base de données verrouillée sur le serveur distant.

Le tableau ci-après montre bien que l'évaluation avancée des coûts de renvoi permet d'identifier rapidement un problème de communication, car on peut voir que le serveur ne peut pas communiquer actuellement avec 151.155.134.13 via le protocole TCP.

L'évaluation avancée des coûts de renvoi est actuellement activée.

Tableau 19-3 Coûts associés aux temps de résolution

Slot	Transport Address	Cost	LastUse	Checked	#Req	Waiters	LockTime
1	tcp:151.155.134.27:524	394	92	14	0	0	0
2	tcp:151.155.134.11:524	0	0	0	0	0	0
3	udp:151.155.134.11:524	0	0	0	0	0	0
4	tcp:151.155.134.13:524	5000000	180	180 est dans le CACHE DES ADRESSES INCORRECTES.

Lorsque vous consultez ces tableaux, gardez ceci à l'esprit :

Les requêtes en suspens ne sont pas nécessairement problématiques. En effet, il se peut que le serveur ait simplement de nombreuses requêtes à traiter. En revanche, elles constituent un problème lorsqu'elles sont adressées à un serveur dont le coût est élevé.
Le premier indicateur de l'état de santé d'un serveur est le coût actuel, lequel permet d'identifier facilement les serveurs problématiques.

REMARQUE :le temps d'aller-retour et la durée d'attente sont mesurés pour toutes les requêtes. Autrement dit, les temps de transport sont également pris en compte dans le calcul du coût. Si un serveur semble problématique selon ce tableau, mais fonctionne correctement indépendamment d'autres serveurs et ne présente manifestement aucun problème, le problème est peut être lié au transport.

Traces de thread d'arrière-plan

Le message ci-dessous est une trace montrant l'exécution de la tâche ARCBackgroundResolveTimerThread :

ARCBackGroundResolveTimerThread started Interval = 60 MaxWait = 180000

Updating timer info for tcp:151.155.134.11:524

Updating timer info for udp:151.155.134.11:524

Updating timer info for tcp:151.155.134.13:524 ARCBackGroundResolveTimerThread error -635 in DCConnectToAddress for tcp:151.155.134.59:524

ARCBackGroundResolveTimerThread completed in 0 seconds

8-total timers 4-stale timers 3-timers updated

La trace ci-dessus révèle que :

l'adresse TCP:151.155.134.11 n'a pas été utilisée pendant plus de 3 minutes ;
l'adresse UDP:151.155.134.11 n'a pas été utilisée pendant plus de 3 minutes ;
l'adresse TCP:151.155.134.13 n'a pas été utilisée pendant plus de 3 minutes.

Les informations de l'horloge ont été mises à jour pour tous les serveurs ci-dessus, avec les résultats suivants :

l'adresse TCP:151.155.134.59 n'est toujours pas accessible à partir de ce serveur.

La nouvelle évaluation des coûts est très dynamique et change très fréquemment. Pour suivre son évolution, vous pouvez définir le paramètre d'évaluation avancée des coûts de renvoi (ARC) en mode Débogage.

REMARQUE :une fois que vous avez fini de surveiller l'évaluation des coûts, veillez à désactiver le mode Débogage pour le paramètre ARC en exécutant la commande set NDSTRACE = !ARC1. S'ils ne sont pas indispensables, mieux vaut éviter des frais généraux d'impression.

Si les paramètres ARC et +RSLV sont activés, vous pouvez voir les coûts de renvoi individuels dans l'utilitaire DSTrace ou NDSTrace. Les balises restantes sont désactivées à l'aide de la commande set NDSTrace =nodebug.

Sorted results from DCAdjustCostAndSort follow:

137.65.10.3 cost of 217

137.65.10.9 cost of 222

137.65.10.10 cost of 400

Si un serveur distant est lent ou surchargé, les chiffres changent rapidement. L'évaluation des coûts du serveur ExRef s'ajuste dynamiquement toutes les secondes. Pour suivre l'évolution des coûts au fil du temps, il est donc recommandé de publier la trace dans un fichier journal.