eDirectory utilise la base de données FLAIM. La base de données FLAIM (Flexible Adaptable Information Manager) est utilisée pour les informations traditionnelles, volatiles et complexes. Ce moteur de base de données très évolutif prend en charge plusieurs opérations de lecture et un modèle de simultanéité à une seule opération d'écriture. Les opérations de lecture ne bloquent pas les opérations d'écriture et, réciproquement, les opérations d'écriture ne bloquent pas les opérations de lecture.
Physiquement, le gestionnaire FLAIM organise les données en blocs. Certains de ces blocs sont généralement conservés en mémoire. Ils représentent le cache de blocs. Quant au cache d'entrées (parfois appelé cache d'enregistrements), il met en cache des entrées logiques de la base de données. Les entrées sont construites à partir des éléments du cache de blocs. Le gestionnaire FLAIM conserve les tables de hachage des deux caches. La taille du compartiment de hachage est ajustée périodiquement en fonction du nombre d'éléments.
Par défaut, eDirectory utilise une taille de blocs de 4 Ko. Pour la mise en cache de l'intégralité de la base de données DIB, la taille du cache de blocs doit être égale à celle du fichier DIB ; la taille du cache d'entrées doit être deux à quatre fois supérieure à celle du fichier DIB.
Lors de la récupération d'une entrée, le gestionnaire FLAIM recherche d'abord l'entrée dans le cache d'entrées. Si l'entrée existe, la lecture à partir du cache de blocs n'est pas nécessaire. Lors de la récupération d'un bloc à partir du disque, le gestionnaire FLAIM recherche d'abord le bloc dans le cache. Si le bloc existe, la lecture du disque n'est pas nécessaire.
Lors de l'ajout ou de la modification d'une entrée, les blocs correspondant à cette entrée ne sont pas validés directement sur le disque, si bien que le disque et la mémoire peuvent ne pas être synchronisés. Toutefois, les mises à jour apportées à l'entrée sont consignées dans le fichier journal de transaction individuelle. Ce fichier journal permet de récupérer des transactions après une défaillance du système.
L'algorithme de remplacement LRU (Least Recently Used) est utilisé pour remplacer des éléments du cache.
Un point de contrôle adapte la version de la base de données sur disque à l'état de la base de données en mémoire (en cache). Le gestionnaire FLAIM peut réaliser un point de contrôle pendant l'activité de mise à jour minimale de la base de données. Il s'exécute toutes les secondes et écrit les blocs altérés (cache altéré) sur le disque. Les blocs qui sont modifiés dans le cache, mais ne sont pas encore écrits sur le disque, sont appelés « blocs altérés ». Le gestionnaire FLAIM acquiert un verrou sur la base de données et exécute la quantité maximale de travail possible jusqu'à ce que le point de contrôle se termine ou qu'un autre thread soit en attente pour mettre à jour la base de données. Afin d'éviter une trop forte désynchronisation de la base de données sur le disque, un point de contrôle est forcé dans certaines conditions, même si des threads attendent pour mettre à jour la base de données :
Si le thread de point de contrôle ne peut pas terminer un point de contrôle dans un intervalle de temps spécifié (la valeur par défaut est de 3 minutes), il est forcé et le cache altéré est nettoyé.
Si la taille du cache altéré est supérieure à la valeur maxdirtycache (si elle est définie), un point de contrôle est forcé afin de réduire la taille du cache altéré à la valeur mindirtycache (si elle est définie) ou à zéro.
Un index est un ensemble de clés organisées de manière à accélérer considérablement la recherche de clés spécifiques. Les clés d'index sont construites par extraction du contenu d'un ou de plusieurs champs (attributs) à partir des entrées. Les index sont conservés dans le cache de blocs. Toute modification des attributs indexés nécessite la modification des blocs d'index.
eDirectory définit un ensemble par défaut d'index pour les attributs (champs) système. Les attributs système tels que parentID et ancestorID sont utilisés pour les recherches à un seul niveau et dans les sous-arborescences. Ces index ne peuvent être ni suspendus ni supprimés. L'annuaire les utilise en interne. Les index par défaut sont définis pour les attributs tels que CN, Surname, Given Name, etc. Les index peuvent être de type Presence, Value et Substring. Ces index peuvent être suspendus. Lors d'une suppression, ils sont recréés automatiquement.
Vous pouvez utiliser iManager ou l'utilitaire LDAP (Lightweight Directory Access Protocol) pour créer des index. Les index sont propres au serveur.
En activant la balise du Gestionnaire de stockage (StrMan) dans DSTrace (ndstrace), vous pouvez afficher l'index choisi pour les recherches.
L'exemple suivant concerne le journal DSTrace d'une recherche dans une sous-arborescence à l'aide de "cn=admin", CN.
3019918240 StrMan: Iter #b239c18 query ((Flags&1)==1) && ((CN$217A$.Flags&8=="admin") && (AncestorID==32821))
3019918240 StrMan: Iter #b239c18 index = CN$IX$220
L'exemple suivant concerne le journal DSTrace d'une recherche dans une sous-arborescence à l'aide de "Description= This is for testing" ("Description= Ceci est un test"), AncestorID.
2902035360 StrMan: Iter #83075b0 query ((Flags&1)==1) && ((Description$225A$.Flags&8=="This is for testing") && (AncestorID==32821))
2902035360 StrMan: Iter #83075b0 index = AncestorID_IX
Le gestionnaire FLAIM enregistre les opérations de chaque transaction de mise à jour dans un fichier journal de transaction individuelle (RFL). Le fichier RFL permet de récupérer les transactions en cas de défaillance du système ou lors de la restauration à partir d'une sauvegarde. Ce fichier est tronqué à la fin de chaque point de contrôle, sauf s'il est activé (rflkeepfiles) à l'aide d'une sauvegarde à chaud et continue.
Pour garantir une utilisation optimale du cache d'entrée ainsi qu'une amélioration des performances des opérations de recherche d'attributs, FLAIM enregistre les attributs dont les valeurs sont plus élevées ou contenant un nombre supérieur de valeurs à un autre emplacement, à savoir, le conteneur d'attributs. Vous pouvez déplacer un attribut vers un conteneur d'attributs dans les cas suivants :
il contient plus de 25 valeurs ;
sa valeur est supérieure à 2 048 octets.
eDirectory offre la souplesse nécessaire pour planifier le déplacement des attributs. Vous voyez d'abord s'afficher les attributs prêts à être déplacés, puis planifiez leur transfert à votre convenance.
Pour afficher le nombre d'attributs prêts à être déplacés vers les conteneurs d'attributs, exécutez la commande ndscheck. Pour afficher les détails des attributs, utilisez l'attribut dsReadyContainerAttr iMonitor sur les objets Pseudo serveur.
Vous pouvez démarrer la mise en conteneur des attributs à l'aide de l'option Réparation d'objet unique de ndsrepair pour l'objet Pseudo serveur. Pour placer un attribut dans un conteneur, entrez la commande ndsrepair avec le nouveau paramètre avancé -am suivi du nom de l'attribut comme indiqué ci-dessous :
ndsrepair –J <Pseudo server object ID> –Ad –AM/–am <attribute name>
Pour activer la mise en conteneur automatique des attributs, ajoutez enablemovetoattrcontainer=1 au fichier _ndsdb.ini, puis redémarrez eDirectory.
Après avoir déplacé un attribut dans le conteneur d'attributs, eDirectory crée un index système avec le nom de l'attribut. Lorsqu'un attribut est mis en conteneur, vous ne pouvez pas le replacer dans son conteneur d'origine.