Stockage physique des données
Cette section traitera de l’emplacement du stockage physique des données de l’annuaire, mais également de la façon dont elles seront exploitées par le système d’exploitation.
1. Disques locaux ou architecture de stockage de données
Durant la phase de conception de l’architecture LDAP, il est également nécessaire de se pencher sur la volumétrie des données générées pour ainsi déterminer si de simples disques locaux seront suffisants, ou bien s’il faut songer à utiliser des architectures de stockage de type SAN ou NAS.
Ceci dit, cette question est juste là pour être posée, car dans le cas d’un serveur LDAP, il n’y a guère de gros volumes de données qui nécessiteraient l’utilisation d’une architecture de stockage de données. En effet, ce type de service n’est pas destiné à manipuler des fichiers numériques du type photographie ou vidéo qui sont eux très volumineux et gourmands en espace disque. Cependant, une architecture de stockage est aussi un garant de la haute disponibilité des données, et dans ce cas une infrastructure de serveur LDAP avec réplication des données ne serait pas nécessaire. Ainsi, la figure 3-5 montre l’intérêt d’un SAN qui offre une volumétrie plus importante, une haute disponibilité des données, la suppression du mécanisme de réplication et également de meilleures performances d’accès aux données dans le cas d’une liaison en fibre optique.
¬
Figure 3-5 : Architecture LDAP avec SAN
2. Base de données, moteurs de stockage (backend)
La plupart des annuaires LDAP stockent toutes leurs données (c’est-à-dire les informations exploitées par les utilisateurs ainsi que les informations de configuration de l’annuaire LDAP lui-même) dans des bases de données. Ainsi, l’annuaire LDAP d’IBM appelé SDS (anciennement ITDS) conserve ses données dans des bases de données de type DB2, Active Directory de Microsoft utilise sa propre base de données propriétaire alors que OpenLDAP stocke ses informations dans un moteur de base de données (aussi appelé backend) nommé Berkeley DB. Il n’y a donc pas de choix à faire à ce niveau, car chaque fournisseur de serveur LDAP embarquera sa propre méthode de stockage des données dans son produit.
3. Le format LDIF
Ainsi, afin de pouvoir importer ou exporter des informations entre annuaires utilisant des bases de données différentes, il a alors fallu créer un format texte standardisé appelé LDIF pour LDAP Data Interchange Format qui pourra être utilisé par tous types d’opérations LDAPv3. Cela se traduit par l’utilisation d’un même fichier LDIF pour créer une nouvelle entrée que ce soit dans un annuaire LDAP OpenLDAP ou bien dans un annuaire LDAP IBM. On s’affranchit donc du type de base de données utilisée par les serveurs LDAP et de l’utilisation qui serait trop complexe de requêtes SQL (si d’ailleurs supporté par la base de données de chacun des serveurs LDAP). Par ailleurs, le fichier LDIF permettra également de créer et de modifier un grand nombre d’entrées avec une seule commande LDAP. C’est notamment ce format qui est utilisé pour le peuplement ou la restauration (et donc la sauvegarde) des annuaires.
La syntaxe de ce fichier est assez simple, car il va contenir des paragraphes décrivant chacune des entrées de l’annuaire LDAP... donc un paragraphe représentera une entrée ou autrement dit un DN. Il faut cependant que l’ordre des paragraphes soit croissant : partant de la racine (ou suffixe) vers les extrémités des branches de notre DIT. Puis, il faudra définir pour cette entrée DN une ou plusieurs classes d’objets ainsi que les attributs obligatoires. Il est également possible d’inclure des commentaires par le caractère (#). Par ailleurs, chaque paragraphe devra être séparé par une ligne vide.
Exemple
# Commentaire 
dn: <distinguished name> 
objectClass: <object class name> 
objectClass: <object class name> 
... 
<attribute name:<attribute value> 
<attribute name:<attribute value> 
 
# Commentaire 
dn: <distinguished name> 
...