Diagnotiquer les problèmes de load balancing sous SharePoint

Dec 13, 2016

Il y a quelques semaines j’ai eu l’occasion d’intervenir sur une ferme cliente qui posait des problèmes de performances. Il y avait aussi des problèmes de consistances des données affichées entre plusieurs appels.

J’ai très rapidement suspecté un problème de configuration du load balancer qui répartissait les appels entre les différents serveurs. Cependant n’ayant accès uniquement à la ferme SharePoint, j’ai dû fournir une preuve à l’équipe réseau pour qu’ils déclenchent un incident.

La question suivante s’est donc posée, comment entre deux appels http peut-on déterminer quel serveur a répondu ?

La plupart de la documentation propose de mettre un fichier texte contenant le nom du serveur à la racine des applications web. Cependant je n’aime pas cette solution pour plusieurs raisons:

  • Ajouter/supprimer des fichiers à SharePoint n’est pas une chose à faire à la légère, surtout si on connait mal SharePoint

  • Il est possible, selon la configuration du load balancer, qu’un serveur réponde à une requête, et un autre à la suivante (justement s’il est mal configuré). Il faudrait donc déterminer le serveur répondant pour chaque requête.

Je fais évidemment l’impasse sur les solutions de types « déployer une solution contenant un webpart qui l’affichera ».

J’ai donc choisi d’ajouter un en-tête http de réponse qui sera envoyé par le serveur à chaque requête http.

L’unique inconvénient de ce genre de solution c’est que ça induit un recyclage du pool applicatif, et donc une interruption de service.

Pour cela rendez-vous dans la console IIS et sélectionnez l’application web qui vous intéresse.

Cliquez ensuite sur « http response headers »

39.png

Ajoutez en un avec le nom que vous voulez et le nom du serveur en valeur.

40.png

(répétez l’opération pour chacun des serveurs)

A l’aide de n’importe quel navigateur, si vous ouvrez les outils de développeur (généralement F12), que vous activez le suivit des requêtes et que vous allez dans la section en-tête de réponse, vous pourrez voir votre en-tête.

41.png

Une fois que vous avez terminé, n’oubliez pas d’enlever votre en-tête pour deux raisons :

  • Les en-tête http, avant HTTP2 (qui n’est pas implémenté dans la plupart des cas), ne sont pas compressé, le trafic réseau va donc augmenter

  • Pour des raisons des sécurité, vous ne devriez pas exposer les noms de vos serveurs

Bon troubleshooting de load balancers.


Edité la dernière fois le 27 May 2021 par Vincent Biret


Tags: