7.4 Utilitaire de chargement en bloc hors connexion

L'utilitaire ldif2dib permet de charger en bloc des données à partir des fichiers LDIF vers la base de données NetIQ eDirectory (DIB), lorsque le serveur eDirectory est hors ligne. eDirectory prend en charge cet utilitaire sur les plates-formes Linux et Windows. Cet outil hors ligne réalise des chargements en bloc plus rapidement que les autres outils en ligne. L'utilitaire utilise le répertoire existant et ne crée pas de nouvelle base de données lors de l'importation d'entrées d'un fichier LDIF vers la DIB.

L'utilitaire ldif2dib est nécessaire lorsque vous avez besoin de remplir une grande base de données utilisateur avec les entrées d'un fichier LDIF. Les outils en ligne tels que ICE ou ldapmodify sont plus lents que ldif2dib en raison des surcharges associées au chargement en bloc et en ligne, telles que la vérification du schéma, la traduction du protocole et les vérifications du contrôle d'accès. ldif2dib permet d'accélérer le temps de fonctionnement lorsqu'une base de données utilisateur volumineuse doit être remplie et que le temps d'arrêt initial n'est pas un problème.

7.4.1 Amélioration des performances de chargement par lots

eDirectory propose de nouvelles options pour accroître les performances de chargement en bloc. Voici les paramètres vous permettant d'ajuster les performances de chargement en bloc à l'aide de l'utilitaire Importation/Conversion/Exportation (ICE) NetIQ.

Reportez-vous également aux différents paramètres réglables de votre système d'exploitation.

Paramètres du cache eDirectory

Pour optimiser les performances de bulkload, allouez un pourcentage supérieur de cache eDirectory pour le cache de bloc. Pour plus d'informations, reportez-vous à la section Optimisation des sous-systèmes eDirectory du Guide d'optimisation NetIQ eDirectory.

Définition de la taille de transaction LBURP

La taille de transaction LBURP définit le nombre d'enregistrements qui sont envoyés au serveur LDAP par l'utilitaire ICE, durant une même transaction. En augmentant cette valeur, vous pouvez améliorer les performances du chargement par lot, en partant du principe que vous avez défini une mémoire suffisante et que l'augmentation n'entraîne pas de conflit d'entrées/sorties. La taille de transaction par défaut est 25, ce qui est suffisant pour les petits fichiers LDIF (moins de 100 000 opérations), mais non pour un nombre important d'enregistrements. La taille de transaction LBURP peut être définie entre 1 et 350.

Modification de la taille de transaction

Pour modifier la taille de transaction, changez la valeur requise dans le paramètre n4u.ldap.lburp.transize du fichier /etc/opt/novell/eDirectory/conf/nds.conf. Dans l'idéal, une taille de transaction plus élevée assure des performances plus rapides. Cependant, la taille de transaction ne doit pas être définie de façon arbitraire sur des valeurs élevées pour les raisons suivantes :

Une taille de transaction plus élevée exige que le serveur alloue plus de mémoire pour effectuer la transaction. Si le système commence à manquer de mémoire, cela peut provoquer un ralentissement dû aux permutations.
Le fichier LDIF doit être exempt d'erreurs et toutes les entrées préexistantes dans eDirectory doivent être mises en commentaire. Si la transaction présente ne serait-ce qu'une seule erreur (y compris les cas où l'objet à ajouter existe déjà dans l'annuaire), eDirectory ne tient pas compte du paramètre de la transaction LBURP et effectue une validation après chaque opération pour garantir l'intégrité des données.

Pour plus d'informations, reportez-vous à la section Dépannages des fichiers LDIF du Guide de dépannage de NetIQ eDirectory.
L'optimisation LBURP ne fonctionne que pour les objets Feuille. Si la transaction renferme à la fois un conteneur et les objets qui lui sont subordonnés, eDirectory la traite comme une erreur. Pour éviter ce problème, nous recommandons de charger les objets Conteneur d'abord à l'aide d'un fichier LDIF distinct ou d'activer l'utilisation des références en aval.

Pour plus d'informations, reportez-vous à la section Activation des références en aval du Guide de dépannage de NetIQ eDirectory.

Augmentation du nombre de requêtes asynchrones dans ICE

Cette option définit le nombre d'entrées que le client ICE peut envoyer au serveur LDAP en mode asynchrone avant de patienter pour obtenir les résultats renvoyés par le serveur. Le nombre de requêtes asynchrones peut être défini sur un nombre compris entre 10 et 200. La valeur par défaut est 100. Toute valeur inférieure au minimum (10) est ramenée à la valeur par défaut. La valeur minimale est suffisante pour les petits fichiers LDIF. Idéalement, une taille de fenêtre plus élevée assure de meilleures performances. Vous ne devez toutefois pas attribuer des valeurs arbitrairement élevées à la taille de fenêtre car une taille de fenêtre élargie oblige le client à allouer plus de mémoire au traitement des entrées dans le fichier LDIF. Si le système vient à manquer de mémoire, cela peut provoquer un ralentissement dû aux échanges. Vous pouvez modifier le nombre de requêtes asynchrones dans ICE à l'aide de l'option de ligne de commande ICE ou iManager.

Avec l'option de ligne de commande ICE

Il est possible de spécifier le nombre de requêtes asynchrones à l'aide de l'option de ligne de commande -Z de ICE. Elle est disponible dans le gestionnaire cible LDAP.

Pour définir 50 comme nombre de requêtes asynchrones envoyées au client ICE, entrez la commande suivante :

ice -SLDIF -f LDIF_file -a -c -DLDAP -d cn_of_admin -Z50 -w password

Avec l'Assistant ICE d'iManager

Pour définir le nombre de requêtes asynchrones envoyées par le client ICE via iManager, procédez comme suit :

Cliquez sur le bouton Rôles et tâches .
Cliquez sur Maintenance > Assistant Importation/Conversion/Exportation.
Entrez la valeur dans le champ Taille de la fenêtre LBURP dans les écrans du gestionnaire cible LDAP à la fois pour les tâches d'importation de données à partir d'un fichier et de migration de données entre les tâches des serveurs LDAP.
Cliquez sur Suivant.

Pour plus d'informations, consultez l'aide de l'Assistant.

Augmentation du nombre de threads d'écriture LDAP

Le serveur LDAP comporte désormais plusieurs threads d'écriture. Utilisez l'option de ligne de commande -F de ICE pour activer les références en aval afin d'éviter toute erreur possible due à un traitement concurrent, en entrant la commande suivante :

ice -SLDIF -f LDIF_file -a -c -DLDAP -d cn_of_admin -w password  -F

Désactivation de la validation de schéma dans ICE

Utilisez les options de ligne de commande -C et -n de ICE pour désactiver la validation de schéma au niveau du client ICE en entrant la commande suivante :

ice -C -n -SLDIF -f LDIF_file -a -c -DLDAP -d cn_of_admin -w password

Processus de liaison en amont (back linker)

La liaison en amont est un processus d'arrière-plan qui vérifie notamment l'intégrité référentielle dans le cadre des vérifications effectuées 50 minutes après l'activation du serveur eDirectory. Cette vérification s'effectue de nouveau après 13 heures. Veillez à ce que la liaison en amont ne s'exécute pas pendant le chargement par lots, qui risquerait alors d'être perturbé selon la durée du chargement et le nombre d'objets chargés

Désactivation des modèles ACL

Vous pouvez désactiver les modèles ACL (Access Control List - liste de contrôle d'accès) pour accroître les performances de chargement par lots. Certaines ACL risquent alors d'être manquantes, mais vous pouvez résoudre ce problème en ajoutant les ACL nécessaires au fichier LDIF ou en les appliquant ultérieurement.

Exécutez la commande suivante :

ldapsearch -D cn_of_admin -w password -b cn=schema -s base objectclasses=inetorgperson

Le résultat de cette commande sera similaire au suivant :

dn: cn=schema
objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP
 organizationalPerson STRUCTURAL MAY ( groupMembership $ ndsHomeDirectory
 $ loginAllowedTi meMap $ loginDisabled $ loginExpirationTime $
 loginGraceLimit $ loginGraceRem aining $ loginIntruderAddress $
 loginIntruderAttempts $ loginIntruderResetTim e $
 loginMaximumSimultaneous $ loginScript $ loginTime $
 networkAddressRestri ction $ networkAddress $ passwordsUsed $
 passwordAllowChange $ passwordExpirationInterval $
 passwordExpirationTime $passwordMinimumLength $ passwordRequired $
 passwordUniqueRequired $ printJobConfiguration $ privateKey $ Profile $ 
 publicKey $ securityEquals $ accountBalance $ allowUnlimitedCredit $
 minimum AccountBalance $ messageServer $ Language $ UID $
 lockedByIntruder $ serverHolds $ lastLoginTime $ typeCreatorMap $
 higherPrivileges $ printerControl $ securityFlags $ profileMembership $
 Timezone $ sASServiceDN $ sASSecretStore $ sASSecretStoreKey $
 sASSecretStoreData $ sASPKIStoreKeys $ userCertificate
 $nDSPKIUserCertificateInfo $ nDSPKIKeystore $ rADIUSActiveConnections $
 rADIUS AttributeLists $ rADIUSConcurrentLimit $ rADIUSConnectionHistory
 $ rADIUSDefa ultProfile $ rADIUSDialAccessGroup $ rADIUSEnableDialAccess
 $ rADIUSPassword $ rADIUSServiceList $ audio $ businessCategory $
 carLicense $ departmentNumbe r $ employeeNumber $ employeeType $
 givenName $ homePhone $ homePostalAddress  $ initials $ jpegPhoto $
 labeledUri $ mail $ manager $ mobile $ pager $ ldap Photo $
 preferredLanguage $ roomNumber $ secretary $ uid $ userSMIMECertifica te
 $ x500UniqueIdentifier $ displayName $ userPKCS12 ) X-NDS_NAME 'User' X
-NDS_NOT_CONTAINER '1' X-NDS_NONREMOVABLE '1' X-NDS_ACL_TEMPLATES ( '2#subtree#[Self]#[All Attributes Rights]' '6#entry#[Self]#loginScript' '1#subtree#[Root Template]#[Entry Rights]' '2#entry#[Public]#messageServer' '2#entry#[Root Template]#groupMembership' '6#entry#[Self]#printJobConfiguration' '2#entry#[Root  Template]#networkAddress') )

Dans le résultat obtenu à l'étape précédente, supprimez les informations figurant en gras.
Enregistrez le résultat révisé sous la forme d'un fichier LDIF.

Ajoutez les informations suivantes dans le nouveau fichier LDIF :

dn: cn=schema
changetype: modify
delete: objectclasses
objectclasses: ( 2.16.840.1.113730.3.2.2 )-add:objectclasses

Votre fichier LDIF devrait à présent ressembler à ceci :

dn: cn=schema
changetype: modify
delete: objectclasses
objectclasses: ( 2.16.840.1.113730.3.2.2) 
-
add:objectclasses
objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP
 organization alPerson STRUCTURAL MAY ( groupMembership $ ndsHomeDirectory
 $ loginAllowedTimeMap $ loginDisabled $ loginExpirationTime $
 loginGraceLimit $ loginGraceRem aining $ loginIntruderAddress $
 loginIntruderAttempts $ loginIntruderResetTime $
 loginMaximumSimultaneous $ loginScript $ loginTime $
 networkAddressRestri ction $ networkAddress $ passwordsUsed $
 passwordAllowChange $ passwordExpirationInterval $
 passwordExpirationTime $ passwordMinimumLength $ passwordRequired
 $passwordUniqueRequired $ printJobConfiguration $ privateKey $ Profile $ 
 publicKey $ securityEquals $ accountBalance $ allowUnlimitedCredit $
 minimum AccountBalance $ messageServer $ Language $ UID $
 lockedByIntruder $ serverHolds $ lastLoginTime $ typeCreatorMap $
 higherPrivileges $ printerControl $ securityFlags $ profileMembership $
 Timezone $ sASServiceDN $ sASSecretStore $ sASSecretStoreKey $
 sASSecretStoreData $ sASPKIStoreKeys $ userCertificate $
 nDSPKIUserCertificateInfo $ nDSPKIKeystore $ rADIUSActiveConnections $
 rADIUSAttributeLists $ rADIUSConcurrentLimit $ rADIUSConnectionHistory $
 rADIUSDefa ultProfile $ rADIUSDialAccessGroup $ rADIUSEnableDialAccess
 $rADIUSPassword $ rADIUSServiceList $ audio $ businessCategory $
 carLicense
 $ departmentNumbe r $ employeeNumber $ employeeType $ givenName $
 homePhone $ homePostalAddress  $ initials $ jpegPhoto $ labeledUri $ mail
 $ manager $ mobile $ pager $ ldap Photo $ preferredLanguage $ roomNumber
 $ secretary $ uid $ userSMIMECertifica te $ x500UniqueIdentifier $
 displayName $ userPKCS12 ) X-NDS_NAME 'User' X-ND S_NOT_CONTAINER '1' X
-NDS_NONREMOVABLE '1')

Saisissez la commande suivante :
```
ldapmodify -D cn_of_admin -w password -f LDIF_file_name
```
Pour plus d'informations sur l'utilisation des ACL, reportez-vous au Guide d'optimisation NetIQ eDirectory.

Activation/désactivation du cache en ligne

Le cache de changement en ligne peut être activé ou désactivé pour un serveur. Cette option ne peut toutefois être désactivée que si la synchronisation sortante est elle-même désactivée. L'activation de la synchronisation sortante active également le cache de changement en ligne. La désactivation de ce cache de changement en ligne le marque comme non valide pour cette réplique et lui attribue un drapeau invalide dans Configuration de l'agent > Partitions. Si le cache de changement en ligne est réactivé, le drapeau non valide est supprimé lors de la reconstruction du cache.

Augmentation du timeout de LBURP

Par défaut, le timeout pour un client est de 20 minutes (1 200 secondes). Mais pendant le chargement par lots, lorsque la taille de la transaction LBURP est de l'ordre de 250, que les objets comportent un grand nombre d'attributs dont les valeurs sont élevées et qu'un traitement LBURP est activé simultanément sur le serveur, le serveur est occupé à traiter les données provenant du client ICE sans lui répondre dans le délai imparti entraînant ainsi l'expiration de ce dernier

Dès lors, nous vous recommandons d'augmenter le timeout. Pour ce faire, exportez la variable d'environnement LBURP_TIMEOUT avec des valeurs élevées (en secondes). Par exemple, pour exporter la variable LBURP_TIMEOUT avec 1 200 secondes, entrez la commande suivante : export ICE_LBURP_TIMEOUT=1200

7.4.2 Utilisation de ldif2dib pour le chargement en bloc

Vous pouvez spécifier le fichier LDIF qui contient les données à importer et le chemin d'accès aux fichiers de base de données dans laquelle les données doivent être importées via l'interface de ligne de commande. Pour utiliser ldif2dib afin de charger des données en bloc, procédez comme suit :

Réalisez une sauvegarde de la DIB.

Pour plus d'informations sur la procédure de sauvegarde et de restauration, reportez-vous au Section 15.0, Sauvegarde et restauration de NetIQ eDirectory.
Arrêtez le serveur eDirectory.
Pour démarrer le chargement en bloc à partir du fichier LDIF, entrez la commande suivante :
```
ldif2dib <LDIF File Name> [Options]
```
Où
- LDIF File Name : indique le nom de fichier LDIF permettant le chargement en bloc.
- Options : elles sont facultatives et indiquent les différents paramètres que vous pouvez utiliser pour l'optimisation de cet utilitaire. Les options prises en charge par l'utilitaire ldif2dib sont répertoriées ci-dessous :
Par exemple, si vous souhaitez définir des options permettant de spécifier le mode de traitement par lots et la taille du cache, ainsi que des options de pourcentage du cache de blocs, entrez la commande suivante :
```
ldif2dib 1MillionUsers.ldif -b/novell/log/logfile.txt -c314572800 -p90
```
INDICATION :vous pouvez suspendre provisoirement le chargement en bloc en appuyant sur la touche s ou S. La touche d'échappement (ÉCHAP) peut être utilisée pour arrêter le chargement en bloc.

7.4.3 Instances multiples

ldif2dib peut être utilisé pour les entrées de chargement en bloc à partir des fichiers LDIF vers une instance spécifique d'eDirectory (DIB), en indiquant l'emplacement de son fichier nds.db à l'aide de l'option -n. Si l'emplacement du fichier nds.db n'est pas spécifié avec l'option -n et s'il existe une seule instance d'eDirectory configurée sur le système, ldif2dib détecte automatiquement l'emplacement de ses fichiers de base de données. Toutefois, s'il existe plusieurs instances, ldif2dib affiche un menu contenant toutes les instances configurées et vous permet de choisir une instance pour le chargement en bloc.

Pour plus d'informations sur les instances multiples d'eDirectory, reportez-vous à la section Utilisation de ndsconfig pour configurer plusieurs instances d'eDirectory 9.0 du Guide d'installation de NetIQ eDirectory.

7.4.4 Optimisation de ldif2dib

Cette section contient des informations sur les paramètres permettant d'ajuster ldif2dib :

Optimisation du cache

Le paramètre du cache de base de données est l'un des paramètres les plus importants qui affecte les performances d'eDirectory. S'il est trop faible, les opérations eDirectory ralentissent, car les informations doivent être récupérées à partir du disque plus souvent. S'il est trop élevé, la mémoire disponible ne suffit plus pour exécuter d'autres processus et l'ensemble du système ralentit. Pour plus d'informations sur le cache, reportez-vous à la section Modification des paramètres de cache FLAIM du Guide d'optimisation de NetIQ eDirectory.

En règle générale, les performances de chargement en bloc augmentent lorsque la taille du cache augmente. Toutefois, aucune amélioration des performances n'a été observée en augmentant la taille du cache au-delà d'une valeur correspondant à 3,8 fois la taille du fichier LDIF.

Taille de la transaction

La taille de la transaction définit la taille de la tranche exprimée en nombre d'objets par transaction. Si la taille de transaction est élevée, un petit nombre de tranches de grande taille consigne le résultat et lorsqu'elle est faible, un grand nombre de petites tranches consigne le résultat.

Les performances de chargement en bloc augmentent lorsque les tailles de transaction sont plus grandes. Une taille de transaction égale à zéro entraîne un cas spécial qui permet un nombre illimité d'objets par transaction. Lorsque la taille de transaction est de zéro, les performances sont élevées, car la validation est effectuée à la fin du chargement en bloc. Toutefois, nous vous déconseillons de définir la taille de transaction sur 0 pour les fichiers LDIF très volumineux (supérieurs à un million d'objets). Vous pouvez définir la taille de transaction sur 4 000 pour les fichiers LDIF très volumineux.

Index

Bien que l'utilisation des index améliore les performances de recherche, elle ralentit aussi le chargement en bloc, car les index doivent être mis à jour pour tous les objets chargés dans la DIB. Ceci est d'autant plus vrai pour les index de sous-chaîne. Par conséquent, lorsque vous chargez en bloc un grand nombre d'objets, vous pouvez mettre en attente les index afin d'accélérer le chargement en bloc. Les index sont automatiquement repris lorsque le serveur eDirectory est mis en service. Utilisez l'option-x pour désactiver les index avant de charger des entrées à l'aide de ldif2dib.

Pourcentage de cache de blocs

Si les index de sous-chaîne sont activés pour les attributs, il est recommandé de définir le pourcentage de cache de blocs sur 50 %. Toutefois, si les index de sous-chaîne sont désactivés pour les attributs, vous pouvez définir le pourcentage de cache de blocs sur 90 %.

Intervalle de point de contrôle

L'intervalle de point de contrôle est le délai pendant lequel la base de données patiente avant de lancer le thread d'arrière-plan de point de contrôle visant à uniformiser l'état de la version sur disque de la base de données avec celui de la base de données en mémoire (en cache). Ce thread de point de contrôle vide le dirty cache sur le disque, puis nettoie le fichier journal de transaction individuelle. Étant donné que le chargement en bloc est momentanément interrompu pendant l'exécution du thread de point de contrôle, nous vous recommandons de définir une valeur élevée pour l'intervalle de point de contrôle afin d'accélérer les chargements en bloc.

7.4.5 Limites

Cette section détaille les limites de l'utilitaire ldif2dib :

Schéma

Le fichier LDIF doit mentionner toutes les classes d'objet auxquelles appartient une entrée. Une entrée peut appartenir à plusieurs classes d'objet en raison d'un héritage. Par exemple, une entrée du type inetOrgPerson doit respecter la syntaxe suivante dans le fichier LDIF :
```
objectclass: inetorgperson
objectclass: organizationalPerson
objectclass: person
objectclass: top
```
Les syntaxes suivantes ne sont actuellement pas prises en charge :

Modèles ACL

Les ACL spécifiées dans les modèles ACL pour une classe d'objet ne sont pas ajoutées automatiquement pour les objets chargés en bloc à l'aide de ldif2dib.

Options

Sous Linux, si l'option -b est utilisée, l'écran d'affichage des statistiques disparaît une fois le chargement en bloc terminé. Les dernières statistiques, cependant, sont inscrites dans le fichier journal pour référence.

Mot de passe simple et LDIF

Sous Windows, pendant le téléchargement de LDIF associé à un mot de passe simple, ldif2dib risque d'échouer si les clés NICI des dossiers Système et Administrateur ne sont pas synchronisées. Pour résoudre ce problème, accédez aux clés du dossier nici/system comme suit :

Allez dans le dossier C:\Windows\system32\novell\nici\.
Sauvegardez les fichiers du dossier de l'administrateur.
Accédez au dossier Système et à ses fichiers en procédant comme suit :
1. Accédez à l'onglet Sécurité dans la fenêtre Propriétés du dossier System.
2. Sélectionnez Options avancées et accédez à l'onglet Propriétaire.
3. Sélectionnez Administrateur.
4. Retournez à l'onglet Sécurité et ajoutez Administrateur à la liste.
  
  Répétez la procédure pour obtenir un accès en lecture à tous les fichiers du dossier Système.
Remplacez les fichiers du dossier Administrator par ceux du dossier system.
Une fois le téléchargement terminé, copiez les fichiers sauvegardés dans le dossier de l'administrateur.
Rétablissez l'accès Administrateur au dossier Système et aux fichiers qu'il contient.

Classes personnalisées

Le chargement en bloc d'un fichier LDIF incluant un grand nombre d'objets Conteneur à l'aide de ldif2dib peut provoquer une saturation de la mémoire entraînant une erreur -150.

Répliques filtrées

eDirectory ne prend pas en charge les opérations de chargement en bloc pour les répliques filtrées.

7.4.6 Avertissements

Le comportement de ldif2dib n'est pas défini dans les scénarios suivants :

Entrées en double

Le téléchargement de fichiers LDIF qui possèdent des entrées en double ou qui possèdent des entrées déjà présentes dans la DIB, sans l'option -u, provoque l'ajout répété de l'entrée menant ainsi à un état incohérent de la DIB. Dès lors, si vous n'êtes pas certain que les entrées soient répétées dans le fichier LDIF ou qu'elles étaient présentes dans la DIB avant le chargement en bloc, utilisez l'option -u pendant le chargement en bloc.

Aucune vérification de schéma

ldif2dib n'effectue aucune vérification de schéma. Vous pouvez ainsi ajouter un attribut à un objet même si l'attribut n'appartient pas au schéma de cet objet. Cette opération entraîne l'incohérence de l'état de la base de données DIB. N'utilisez ldif2dib que lorsque vous êtes certain que ces données LDIF ne nécessitent pas de vérification de schéma.

Espace insuffisant sur le disque dur

Le comportement de ldif2dib est indéfini lorsque l'espace sur le disque dur est insuffisant pour tous les objets chargés. Vous devez vous assurer que l'espace est suffisant pour accueillir tous les objets avant de démarrer le chargement en bloc.

Arrêt forcé

L'arrêt forcé du processus ldif2dib peut entraîner un état incohérent de la DIB. Utilisez la touche ÉCHAP pour quitter sans problème le chargement en bloc.

Redimensionnement du terminal

Le redimensionnement du terminal pendant le chargement en bloc peut fausser les statistiques dans l'interface utilisateur. Il est déconseillé de redimensionner le terminal pendant le chargement en bloc.