2.1 Base de données FLAIM

OpenText 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, OpenText 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.

2.1.1 Point de contrôle

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.

2.1.2 Index

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.

OpenText 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 OpenText Identity Console ou l'utilitaire LDAP (Lightweight Directory Access Protocol) ndsindex 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

Pour améliorer les performances de recherche à l'aide du tri côté serveur, utilisez l'option -a pour ajouter l'attribut AncestorID en préfixe à la liste des attributs transmis lors de la création d'un index.

Le tableau ci-dessous explique la tendance à augmenter la taille de la DIB lors de la création d'index simples/composés pour un certain nombre d'objets. Nous vous recommandons de vous reporter à ces données de test lors de la création d'index simples/composés :

Nombre d'objets

Augmentation de la taille de la DIB avec un index simple contenant une taille d'attribut de 20 caractères

Augmentation de la taille de la DIB avec un index simple contenant une taille d'attribut de 200 caractères

Augmentation de la taille de la DIB avec un index composé contenant une taille d'attribut de 200 caractères

23 000

24 Ko

3 Mo

7 Mo

47 000

50 Ko

6 Mo

15 Mo

0.5 millions

4 Mo

55 Mo

100 Mo

1 million

9 Mo

111 Mo

210 Mo

2.1.3 Fichier journal de transaction individuelle

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.

2.1.4 Mise en conteneur des attributs FLAIM

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. Par défaut, les attributs seront déplacés automatiquement vers le conteneur lorsque l'attribut :

  • contient plus de 25 valeurs ;

  • sa valeur est supérieure à 2 048 octets.

Pour désactiver la mise en conteneur automatique d'attributs, ajoutez disablemovetoattrcontainer =1 au fichier _ndsdb.ini, puis redémarrez OpenText eDirectory.

OpenText eDirectory vous offre la possibilité de 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 d'attributs, utilisez l'attribut dsContainerReadyAttrs iMonitor sur les objets serveur Pseudo dans Configuration de l'agent. L'utilisateur peut également trouver ces attributs qui sont marqués pour indexation dans État de santé de l'agent.

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>

Après avoir déplacé un attribut dans le conteneur d'attributs, OpenText 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.

REMARQUE :si un attribut a une valeur supérieure à 2 048 octets, la mise en conteneur s'effectue toujours, mais OpenText eDirectory ne crée pas d'index système.