Le chargement des objets

hiérarchie de l’annuaire.
Le premier défi posé par les tests de montée en charge d’AD était de trouver un grand nombre de données à  charger dans la base de données. On aurait pu écrire un programme pour générer 100 millions de noms et d’adresses, mais l’utilisation de données réelles génère une charge plus réaliste. De plus, les données réelles peuvent servir à  d’autres objectifs. Windows 2000 Magazine a obtenu d’infoUSA.com. un jeu de sept CD-ROMs contenant les numéros de téléphone des Etats-Unis organisés par états en fichiers zips. A l’évidence, on ne pouvait pas transférer directement les fichiers bruts dans AD et un programme a donc été écrit pour lire les données et créer des fichiers de chargement LDIF (LDAP Interchange Format).
Les fichiers LDIF sont de simples fichiers textes contenant des commandes pour insérer, mettre à  jour ou supprimer des enregistrements dans une base de données LDAP. Le s testeurs ont donc généré un fichier LDIF séparé pour chaque état. La première commande du fichier a créé une UO pour les enregistrements. Par exemple, la commande suivante a généré l’UO pour New Hampshire :
# Create the OU
dn: OU=USA, DC=Compaq,
DC=com
changetype: add
objectClass: organizationalUnit
Les commandes de fichiers suivantes ont créé un objet AD pour chaque numéro de téléphone. Les commandes ont lu un nombre limité d’attributs dans le fichier d’entrée et les ont transférés dans AD. Les commandes ont aussi procédé à  un traitement pour générer un DN unique pour chaque objet de l’UO et éliminer les enregistrements sans numéros de téléphone. La liste 1 montre la commande LDIF pour ajouter un objet contact typique.
Après avoir généré les fichiers LDIF, le laboratoire de test a utilisé l’utilitaire LDIFDE pour les charger dans AD. Elément du Kit de ressources, LDIFDE peut importer et exporter des données de tout annuaire LDAP, y compris AD. La commande suivante a été utilisée pour importer les données de New Hampshire :
C: > LDIFDE -k -y -i -f NH.LDF
Les commutateurs indiquent à  LDIFDE d’ignorer les messages d’erreur signalant que l’objet existe déjà  (-k), utilisent l’exécution différée pour écrire dans AD (-y), importent les données (-i) et spécifient le fichier d’importation nh.ldf (-f). Dans une exécution différée, LDIFDE charge les données en mémoire, puis continue, sans recevoir de confirmation de l’enregistrement des données sur le disque par le moteur de la base de données. Les données sont enregistrées plus tard, lorsque la charge du système le permet.
Le délai est acceptable si les données sont protégées en isolant les journaux de transactions de la base de données, et en veillant à  ce que toute antémémoire de réécriture utilisée sur le contrôleur de stockage soit protégée par batterie. Pendant le chargement des données pour la démonstration d’AD au Comdex, il s’est produit une panne de courant générale. Après le rétablissement du courant, le contrôleur de stockage a transféré dans le système les données contenues en cache protégé par batterie et le chargement s’est effectué sans aucune perte de transactions.
Il a fallu de 1 à  8 heures pour traiter et charger le fichier LDIF de chaque état, selon sa taille. Un programme VB (Visual Basic) a donc été créé pour parcourir l’annuaire où étaient générés les fichiers LDIF, chargés séquentiellement au fur et à  mesure qu’ils devenaient disponibles. Comme beaucoup d’enregistrements n’avaient pas de numéros de téléphone, les testeurs ont chargé deux états (le Texas et la Californie) deux fois pour atteindre le nombre magique de 100 millions d’enregistrements. Le processus de chargement complet a mis 3 semaines au total, mais le laboratoire de test ne chargeait pas continuellement pendant cette période. Du temps a été perdu, notamment pour adapter le programme de chargement et effectuer diverses autres tâches.
Les CD-ROMs d’InfoUSA.com groupaient les enregistrements de numéros de téléphone par état et chaque état a été chargé dans sa propre UO. Il était très facile de diviser un état en comtés ou en villes et à  utiliser une UO séparée pour chacun d’eux. La structure de base des UO n’a pas affecté les consultations et une recherche du nom de famille prenait généralement moins d’une seconde à  s’effectuer, sauf lorqu’un nom très répandu était spécifié, comme Smith, sans autre critère. La Figure 3 montre les résultats d’une recherche pour un nom moins répandu (Capellas) dans l’état du Texas. Comme on peut le voir, AD a trouvé trois enregistrements (sur 5.965.164 enregistrements de numéros de téléphone au Texas). La vitesse et l’efficacité des recherches prouvent la puissance du moteur de la base de données ESE. Pourquoi ne pas effectuer vous aussi une recherche dans la base de données ? Pour savoir comment, lisez l’encadré « Une démo Web ».
Les UO sont conçues pour diviser les données d’AD en tranches administrables. Ce ne serait pas une bonne idée de charger plus de 10.000 objets dans une UO. En effet, les performances des outils d’administration standards, comme le composant logiciel enfichable Utilisateurs et Ordinateurs AD de la MMC (Microsoft Management Console), baissent significativement si on leur demande d’aller chercher de grandes quantités de données chaque fois qu’une UO est étendue. Par défaut, les composants logiciels enfichables de la MMC extraient 2000 enregistrements lorsqu’ils ouvrent une UO. Il est possible de choisir une option pour extraire davantage d’enregistrements, mais les opérations en seraient ralenties. Il vaut mieux concevoir une structure d’UO stockant moins d’objets. Par exemple, l’annuaire AD des numéros de téléphone US aurait été beaucoup plus efficace si l’on avait établi une UO pour chaque comté d’un état et si l’on avait subdivisé davantage encore certains comtés importants.
Chaque numéro de téléphone est représenté dans AD comme un objet contact séparé. Les contacts sont plus petits que les objets utilisateurs, parce que ce ne sont pas des responsables de sécurité Windows 2000. Nous aurions pu créer des objets utilisateurs plutôt que des objets contacts, mais nous avons décidé de ne pas le faire, parce que le chargement aurait été plus lent. La base de données aurait aussi été plus grande (peut-être deux fois plus), mais les recherches auraient probablement mis autant de temps car AD utilise efficacement les index, quand il recherche des attributs comme un nom de famille.