Au niveau du backend
1. Paramétrage du cache (ou la zone tampon)
Le cache est en fait une copie partielle ou totale des données de l’annuaire dans la mémoire vive (RAM) du système. Ce mécanisme permet donc de fournir des réponses plus rapides, car l’accès au disque (i/o) n’est dans certains cas pas nécessaire. En effet, les accès aux disques impliquent un temps de traitement plus long que l’accès à la mémoire. Ainsi, il est possible de réserver un espace de mémoire appelé "cache ou zone tampon" permettant d’y stocker directement les entrées de l’annuaire évitant ainsi d’accéder au disque et notamment pour les requêtes de type lecture. En revanche, pour les opérations de type "écriture", l’application ne se servira pas du cache excepté si les accès aux disques sont lents (high i/o rate). Ce cache ne contiendra évidemment pas la totalité des entrées, mais celles récemment utilisées susceptibles d’être consultées à nouveau.
La valeur optimale est évidemment le nombre d’entrées de l’annuaire (le nombre total de DN). Cependant, comme la mémoire est plutôt coûteuse et que toutes les entrées de l’annuaire ne sont pas forcément utilisées à la même fréquence, il convient de choisir un nombre d’entrées plus raisonnable.
Pour ce faire, des paramètres (surlignés sur la figure 17-1) permettant de configurer ces espaces de "cache" existent au niveau de la configuration des "backend" en vue d’augmenter significativement les performances de son annuaire.
¬
Figure 17-1
	•	Le paramètre olcDbCacheSize possède une valeur de 1000 entrées par défaut. Sa valeur optimale devrait être la totalité des entrées de l’annuaire + 10 %. Si la mémoire n’est pas suffisante, il faut au moins mettre une valeur pouvant contenir le nombre des entrées les plus utilisées.
Pour connaître le nombre d’entrée de l’annuaire, il faut exécuter la commande ci-dessous :
ldapsearch -b dc=example,dc=com dn 2>/dev/null | grep ˆdn | wc -l
	•	Le paramètre olcDbIDLcacheSize permet de mettre en cache les résultats d’opération de recherche. Il est par défaut à "0", mais il est conseillé de configurer sa valeur à trois fois celle de olcDbCacheSize afin d’obtenir de meilleures performances.
Il y a également d’autres attributs qui devront se trouver dans un fichier nommé "DB_CONFIG" qu’il faudra créer et configurer et qui devra se trouver au même endroit que les fichiers de la base de données. Ce chemin peut être trouvé par l’attribut olcDbDirectory défini dans l’entrée de la base de données.
Exemple
dn: olcDatabase={1}bdb,cn=config 
objectClass: olcBdbConfig 
objectClass: olcDatabaseConfig 
olcDatabase: {1}bdb 
olcDbDirectory: /var/lib/lda 
. . .
Attention : chaque fois que l’une des valeurs du fichier "DB_CONFIG" sera modifiée, il faudra arrêter le service "slapd" puis reconfigurer la base avec la commande db.recover. Si par mégarde vous exécutiez cette commande alors que le service "slapd" est en cours d’exécution, vous risqueriez de corrompre la base de données. Il faut donc procéder comme suit :
service ldap stop 
db_recover -h /var/lib/data 
service ldap start
Au moment du démarrage du service "slapd", si aucun fichier "DB_CONFIG" n’est trouvé alors il sera créé avec les paramètres existants dans l’entrée de configuration de la base de données. En revanche, s’il est présent, l’entrée de configuration de la base de données sera mise à jour avec les valeurs contenues dans celui-ci. Par défaut, ce fichier n’existe pas.
Voici l’exemple ci-dessous d’un fichier "DB_CONFIG" :
set_cachesize 1 10485760 0 
 
# Data Directory 
#set_data_dir db 
 
# Transaction Log settings 
set_lg_regionmax 262144 
set_lg_bsize 2097152 
set_lg_max   8388608 
set_flags DB_LOG_AUTOREMOVE 
set_lg_dir /data/logs/ldap-transactions 
 
# Note: special DB_CONFIG flags are no longer needed for "quick" 
# slapadd(8) or slapindex(8) access (see their -q option). 
 
set_lk_max_locks 4000 
set_lk_max_lockers 200 
set_lk_max_objects 2000
Le premier paramètre set_cachesize définit la taille du cache où seront stockés les entrées et les index de la base de données afin de diminuer les accès au disque. Il se configure en trois parties :
set_cachesize <Gbytes> <bytes> <ncache>
Avec :
	•	<Gbytes> : le nombre de gigaoctets de mémoire à attribuer au cache.
	•	<bytes> : nombre d’octets de mémoire à attribuer au cache.
	•	<ncache> : le nombre de segments de cache à utiliser. Si cette valeur est définie sur 0 ou 1, Berkeley DB tentera d’allouer une section contiguë de mémoire pour le cache. Si cette valeur est supérieure à 1, le cache sera divisé en ce nombre de segments.
Ainsi dans l’exemple donné précédemment, il sera attribué 1 Go + 10 Mo de cache dans un espace mémoire contigu.
Les cinq autres paramètres (set_lg_regionmax, set_lg_bsize, set_lg_max, set_flags, set_lg_dir) permettent de configurer le comportement des fichiers de log appelés fichiers de transaction. Toujours dans le même exemple, la taille du cache du journal des transactions BDB est réglée à 2 Mo et les fichiers journaux des transactions sont stockés dans le répertoire /data/logs/ldap-transactions. De plus, un drapeau est configuré pour indiquer à BDB de supprimer les fichiers journaux des transactions dès que leur contenu a été vérifié et qu’ils ne sont plus nécessaires. Sans ce paramètre, les fichiers journaux de transactions continueraient à s’accumuler jusqu’à ce qu’une autre procédure de nettoyage les supprime (par exemple logrotate).
Idéalement, le répertoire de base de données et le répertoire des journaux de transaction doivent être créés tous les deux sur des disques distincts grâce aux paramètres set_data_dir et set_lg_dir.
¬
Rappel important : les paramètres contenus dans le fichier "DB_config" prennent le pas sur ceux définis dans le DIT de configuration (cn=config). Il faut donc être extrêmement vigilant et éviter d’y toucher à moins d’être vraiment certains de ce que l’on fait.
2. Paramétrage des index
L’indexation de l’annuaire est également une technique qui permettra d’améliorer considérablement les montées en charge de l’annuaire en optimisant les opérations de recherche, mais aussi celles d’écriture (ajout et modification des entrées de l’annuaire). Il faut donc rechercher et analyser les opérations LDAP les plus fréquentes pour ainsi déterminer les index à utiliser.
¬
Il ne faut pas ajouter trop d’index sous peine d’une consommation de mémoire élevée et ainsi obtenir l’effet inverse de celui désiré.
Les valeurs des entrées d’index olcDbIndex contiennent les attributs les plus fréquemment utilisés qui devront être déclarés au niveau de l’entrée de la configuration de la base de données du DIT (ex. dn: olcDatabase={1}hdb,cn=config). La figure 17-2 montre un exemple de configuration d’index.
¬
Figure 17-2 : Configuration des index
Par ailleurs, la recherche des attributs à indexer peut s’effectuer en activant le "debug" du service "slapd" (voir Annexe) et en recherchant les messages de ce type :
Jun  15 19:26:43 ldap01 slapd[5623]: <= bdb_substring_candidates: 
(employeeNumber) not indexed
Ainsi, OpenLDAP indique qu’il faudra indexer l’attribut employeeNumber avec un indice à sub.
a. Syntaxe
La syntaxe d’une directive de configuration d’index se présente ainsi :
# OLC (cn=config) 
olcDbIndex: attrlist | default indices 
 
# slapd.conf 
index attrlist | default indices 
 
Avec: indices = [pres [,approx] [,eq] [,sub] [,special]]
	•	attrlist : permet de spécifier (le ou) les attributs désirés séparés par des virgules. La valeur default permettra de désigner tous les autres attributs.
	•	indices : permet de spécifier l’action de recherche qui sera associée à l’attribut pour l’indexation. Ce qui permettra de correspondre au mieux aux filtres de recherche les plus utilisés.
Ainsi, nous aurons les valeurs suivantes :
	•	pres : permet d’indexer toutes les recherches LDAP reçues contenant l’attribut à indexer (ex. attribute=sn). C’est d’ailleurs celui qui sera paramétré par défaut.
	•	approx : permet d’indexer seulement les recherches ’approximative’ de l’attribut à indexer (ex. sn~=sdupont).
	•	eq : permet d’indexer seulement les recherches contenant une égalité (ex. sn=sdupont).
	•	sub : permet d’indexer seulement les recherches contenant des sous-chaînes (ex. sn=sdup*).
¬
Généralement, seuls les indices pres, eq et sub sont utilisés.
b. Exemples de configuration
Voici quelques exemples pour comprendre l’utilisation de cette directive.
La première ligne de l’exemple ci-dessous spécifie de ne pas indexer les attributs objectclass et userpassword, mais d’indexer tous les autres.
Cette configuration pourrait être utilisée pour des annuaires énormément sollicités en lecture.
Exemple
index objectclass,userpassword,createtimestamp,creatorsname none 
index default
La configuration ci-dessous sera en revanche plus utilisée sur des annuaires très sollicités en écriture. Ainsi, seuls les attributs cn, sn, uid, mail seront indexés avec notamment l’attribut cn qui le sera pour tous les types de recherche. 
Exemple
index cn 
index sn,uid,mail eq,sub 
index default none
Dans le cas de l’annuaire de démonstration, les index suivants ont été définis :
index objectClass                       eq,pres 
index ou,cn,mail,surname,givenname      eq,pres,sub 
index uidNumber,gidNumber,loginShell    eq,pres 
index uid,memberUid                     eq,pres,sub 
index nisMapName,nisMapEntry            eq,pres,sub 
index entryCSN              eq 
index entryUUID             eq
Ce paramétrage permet d’optimiser les requêtes en lecture sur cet annuaire pour les entrées utilisateurs, fort utile dans notre cas puisque sa fonction première consiste à authentifier des utilisateurs.
Par ailleurs, les deux derniers attributs concerneront l’indexation des opérations de réplication.
c. Application
Les index doivent être paramétrés dès la configuration initiale de l’annuaire. Si des modifications sont apportées par la suite, il faudra réaliser une opération de réindexation.
¬
La réindexation n’est normalement plus nécessaire avec la configuration en ligne (OLC)... mais il est tout de même conseillé de la réaliser.
Pour ce faire, il faudra procéder comme suit :
# Ajout des index dans la configuration (OLC) 
# /etc/init.d/slapd stop 
# slapindex -b dc=exemple,dc=com 
# /etc/init.d/slapd start
¬
Veillez à effectuer une sauvegarde de l’annuaire avant de réaliser l’opération de réindexation.