Utilisation de SLAMD pour les benchmarks LDAP

Lorsqu'on réalise des études comparatives sur les annuaires LDAP, il est fréquent que le client demande d'établir des tests de performances, pour s'assurer que la solution en place sera capable de répondre à ses exigences.

Pour faire cela, j'utilisais souvent les outils authrate ou searchrate présents dans les binaires des annuaires de Forgerock ou Ping.

Si ces outils permettent de tester de manière unitaire, et avec un certain nombre de paramètres, ils manquait certaines possibilités / fonctionnalités :

• pas de possibilité de lancer plusieurs clients en parallèle, de manière synchronisée
• pas de reporting de base
• pas de réutilisation des modèles de "tirs"

Dans le cadre d'un nouveau projet d'étude, je suis tombé sur l'outil SLAMD disponible sur GitHub.

Présentation de SLAMD

Il s'agit d'un outil écrit en Java, par un ancien employé de Sun qui travaillait sur les annuaires OpenDS notamment.

On trouve également chez Oracle (qui a racheté Sun il y a plusieurs années), les binaires à télécharger : Oracle SLAMD Downloads

L'outil se présente comme "Distributed Load Generation Engine", ce qui donne une idée de son architecture répartie. En effet, SLAMD est articulé autour de plusieurs composants :

• un serveur, qui tourne dans un serveur Tomcat, qui permet de paramétrer les jobs, et construire les rapports
• un (ou plusieurs) clients, qui vont communiquer avec le serveur pour récupérer les jobs à traiter, et qui vont effectuer les requêtes demandées (ce sont eux qui vont vraiment faire le travail)
• un service de monitoring que l'on peut installer sur les serveurs LDAP pour remonter les informations au serveur SLAMD.

L'outil a été développé à l'origine pour remplacer / améliorer les authrate et autres, avec une orientation LDAP, mais peut aussi être utilisé pour d'autres protocoles réseau (http, smtp, pop,imap).

Utilisation

Une fois qu'on a récupéré les binaires ou compilé à partir de GitHub et installé les composants sur les serveurs, est de définir les jobs qui seront ensuite activés.

Ceci se fait via l'option de menu "Schedule a job", dans laquelle on voit toute la richesse de l'outil.

Pour les tests LDAP, on dispose d'une vingtaine de modèle prédéfinis, notamment :

• Add and Delete : ajout et suppression, utilisé pour les tests d'écriture
• Basic Bind : connexion simple, sans recherche préalable
• Basic Search and Bind : connexion après recherche de l'utilisateur ; c'est ce que j'utilise pour tester les mécanismes d'authentification
• Comprehensive Search : possibilité de mettre plusieurs serveurs, plusieurs filtres et de préciser les attributs retournés
• Mix load : mélange de Add, Bind, Search, etc

Paramétrage du Search + Bind

Dans la majorité des cas en mode Authentification, celle-ci se passe en 2 étapes :

• on fait d'abord une recherche de l'utilisateur dans la base, via le RDN (ou un autre attribut)
• une fois le DN récupéré, on va faire une tentative de connexion avec le mot de passe.

Pour tester ceci, on va utiliser différents paramètres (en mode Basic) :

• Durée du Job
• Nombre de clients (à savoir que si on n'a pas assez de clients disponibles, le job ne va pas démarrer)
• Nombre de threads par client
• Durée de montée en charge / descente de charge
• Nom et port du serveur LDAP, ainsi que la méthode de sécurité (aucune, StartTLS ou SSL)
• Bind DN et mot de passe utilisé pour la recherche (généralement, un compte de service)
• DN de base pour la recherche (par exemple : ou=Users,dc=example,dc=com)
• Périmètre de recherche (scope = subtree, single-level, base)
• Search Filter Pattern : le motif de recherche.
• Mot de passe utilisateur

Pour que cela fonctionne, on aura au préalable inséré dans l'annuaire des utilisateurs de tests, avec le même mot de passe, puisque celui-ci est donné dans la configuration.

Le motif de recherche LDAP peut être variabilisé. Par exemple, si j'ai généré des utilisateurs avec un uid=userXXXXX (XXXXX = numérique de 1 à 99999), je peux avoir différents motifs pour mon filtre LDAP :

• (uid=user[1-100000]) : recherche de user1 à user100000 de manière aléatoire
• (uid=user[1:100000]) : recherche de user1 à user100000 de manière séquentielle

Un bouton permet de tester les paramètres (connexion à l'annuaire, existence du Base DN, etc).

Une fois le job préparé, on peut l'activer pour qu'il soit traité par les clients. Il passe alors en état "Running".

Lorsqu'il est terminé, il passe à l'état "Completed".

On peut dupliquer / cloner un job si on veut le relancer tel quel, ou le modifier pour changer ses paramètres.

Données récupérées

Une fois que le job est terminé, on peut avoir accès aux données recueillies par les clients et centralisées sur le serveur.

Les données peuvent être affichées sous forme de graphique, directement sur le serveur, ou être générées sous forme de rapport HTML ou PDF.

Le rapport contient pas mal d'informations par défaut :

• le nom du job, sa description
• les informations de planification : durée, nombre de clients, nombre de threads
• paramètres du job
• les informations d'exécution : date de début et fin, durée, nom des machines clients
• les résultats des différentes requêtes : nombre, moyenne / seconde, moyenne / intervalle de collecte, ainsi qu'un graphe des données, et la même chose en temps de réponse.
• répartition des requêtes par statut et temps de réponse.

Autres éléments

Un système de "folders" permet de regrouper ses différents jobs ce qui peut être intéressant pour gérer les séances de tests, soit par type d'annuaire si on en compare plusieurs, soit par type de tests si on fait par exemple changer le nombre de threads.