Les notices nécrologiques stockées dans l'annuaire ont souvent été mal comprises de sorte que nombreux sont ceux qui n'ont pas appris à les utiliser de façon adéquate. À la différence de certains produits d'annuaire, eDirectory garantit l'intégrité des références entre les différents objets. Par exemple, si un groupe A compte un membre, Utilisateur B, et que celui-ci vient à être supprimé, l'annuaire supprime automatiquement toute référence à l'utilisateur B dans le Groupe A. Les notices nécrologiques sont des attributs opérationnels placés sur les objets par eDirectory et constituent un moyen supplémentaire de garantir l'intégrité référentielle lors des opérations telles que suppression, déplacement, changement de nom ou restauration
Il existe trois grandes catégories de notices nécrologiques : Primaire, Secondaire et Suivi. Les notices nécrologiques primaires incluent les types Mort (0001), Restauré (0000), Déplacé (0002), Nouveau RDN (0005) et Nouveau RDN de l'arborescence (0008). Les notices nécrologiques secondaires sont généralement associées à une notice primaire et représentent les agents et les partitions qui doivent être avertis de l'opération spécifiée dans la notice primaire. Elles incluent les types Lien en amont (0006), Utilisé par (000C) et Déplacement d'arborescence (000a). Les notices nécrologiques de suivi incluent Non déplaçable (0003), Ancien RDN (0004) et Ancien RDN de l'arborescence (0007).
Les notices nécrologiques, hormis celles de la dernière catégorie, doivent passer par une succession d'états de synchronisation :
Ces états sont enregistrés dans le champ Drapeaux de l'attribut de notice nécrologique. Pour que la notice nécrologique puisse passer à l'état suivant, l'état actuel doit avoir été synchronisé pour toutes les répliques de l'objet réel. Pour déterminer si un état de notice nécrologique a été attribué à toutes les répliques de l'anneau, un vecteur est calculé à partir du vecteur de transition. Dans eDirectory 8.6 (ou version ultérieure), un vecteur de notice nécrologique non stocké est utilisé. Les versions précédentes utilisaient le vecteur de purge. Si le tampon horaire de modification de la notice nécrologique est postérieur au vecteur endommagé, le serveur responsable de cette notice peut la faire passer à l'état suivant.
Dans le cas d'une notice nécrologique secondaire de type Lien en amont, l'agent qui contient la réplique maîtresse de l'objet associé à cette notice prend en charge le passage aux états suivants. Dans le cas d'une notice nécrologique secondaire de type Utilisé par, cette tâche incombe à l'agent de réplique qui a créé cette notice, et ce tant que la réplique existe. Si la réplique vient à disparaître, l'agent qui contient la réplique maîtresse de cette partition se chargera de faire passer la notice Utilisé par aux états suivants. Dans le cas d'une notice nécrologique de type Déplacer l'arborescence, ce passage aux états suivants est assuré par la réplique maîtresse de la partition racine.
Les notices nécrologiques primaires ne peuvent passer à leur état suivant qu'après que toutes les notices secondaires sont elles-mêmes passées par tous leurs états successifs. Lorsque la notice nécrologique primaire a atteint son dernier état et que celui-ci est synchronisé pour tous les serveurs de l'anneau, il ne reste plus que l'enveloppe d'objet, c'est-à-dire un objet dépourvu d'attributs qui peut ensuite être purgé du système par le processus de purge. Les notices nécrologiques de suivi sont supprimées dès que la notice primaire est prête à être supprimée ou, dans le cas d'une notice non déplaçable, dès qu'elle est passée à l'état OBF_NOTIFIED maîtresse.
La réplique chargée du traitement des notices nécrologiques effectue ce traitement dans un processus en arrière-plan (le processus Notice nécrologique) qui est planifié pour chaque partition après qu'une partition donnée a achevé un cycle de synchronisation entrante. S'il n'existe pas d'autre réplique de la partition, le processus de réplication sortante reste planifié en fonction de l'intervalle de pulsation. Le processus de réplication sortante démarre alors le processus de notice nécrologique. Ce dernier ne peut pas être planifié manuellement et n'a pas besoin de l'être. Lorsque la synchronisation se produit, les vecteurs de transition sont mis à jour, ce qui a pour effet de faire avancer le vecteur de purge et le vecteur de notice nécrologique. À mesure que ces vecteurs progressent, les états de notice nécrologique sont également autorisés à avancer. Ceci, combiné à la planification automatique effectuée durant la synchronisation entrante, complète le cycle de traitement des notices nécrologiques. L'élément essentiel du processus Notice nécrologique est donc la synchronisation des objets.
Pour un objet sur le point d'être supprimé, une fois que toutes les notices qui sont associées à une notice primaire de type Mort sont passées au dernier état (Purgeable) et que cet état a été synchronisé pour toutes les répliques, un nouveau processus est chargé de supprimer de la base de données l'enveloppe d'entrée résiduelle. Le processus de purge s'exécute automatiquement pour supprimer ces enveloppes. Vous pouvez planifier manuellement le processus de purge et modifier son intervalle automatique dans
la page Configuration de l'agent d'iMonitor.Cette section comprend les exemples suivants :
S'il s'agit d'une notice primaire, qu'aucune notice secondaire n'existe et que le tampon horaire de modification de l'attribut est postérieur au vecteur de purge, tous les serveurs ont été avertis de la modification et la notice est supprimée.
S'il s'agit d'une notice Lien en amont et du serveur principal, c'est à ce dernier qu'il incombe de traiter la notice.
exécutez l'opération requise pour cet état si cela n'a pas encore été fait. Dans la plupart des cas, vous procéderez en notifiant une référence externe.
S'il s'agit d'une notice « Utilisé par » et que ce serveur est celui sur lequel la suppression a été effectuée (ce que vous déterminez en comparant le numéro de votre réplique avec celui du tampon horaire de modification de la notice), c'est à ce dernier qu'il incombe de traiter la notice.
Le déplacement est similaire à la suppression, à quelques différences près :
Les objets qui possèdent des notices nécrologiques sont pris en considération à chaque synchronisation sortante d'un agent, ainsi que par le processus de notice nécrologique qui est planifié pour s'exécuter à la fin d'un cycle de synchronisation entrante.
Exécutez régulièrement le rapport d'information sur le serveur iMonitor. Ce rapport parcourt l'intégralité de l'arborescence, communique avec tous les serveurs NCP qu'il détecte et signale toutes les erreurs éventuelles repérées. Vous pouvez l'utiliser pour diagnostiquer des problèmes de synchronisation horaire et de contrôleur de connectivité (limber) ou pour savoir si le serveur actuel est apte à communiquer avec tous les autres serveurs. S'il a été sélectionné dans la page de configuration, ce serveur peut également générer des informations sur l'état de santé de l'agent NDS pour chaque serveur de l'arborescence. Pour plus d'informations sur l'exécution du rapport Informations sur le serveur, reportez-vous à Configuration du rapport.
Si vous utilisez iMonitor 2.0 ou une version ultérieure, vérifiez que les options de rapport suivantes sont activées : Erreurs et Sous-rapport de santé. Les éléments suivants sont vérifiés. Parcourez le rapport et vérifiez qu'il est exempt d'erreurs.
Si vous utilisez iMonitor 1.5, sélectionnez l'option Rapport d'erreurs. Les éléments suivants sont vérifiés. Parcourez le rapport et vérifiez qu'il est exempt d'erreurs.
À l'aide du rapport de la liste des notices nécrologiques iMonitor ou des statistiques d'objets iMonitor, vous pouvez rechercher toutes les notices nécrologiques qui existent dans votre système. Si vous trouvez des notices nécrologiques que vous suspectez de ne pas avoir été traitées, reportez-vous à la section Conseils de dépannage.
Deux raisons expliquent généralement que les notices nécrologiques n'aient pas été traitées : la notice est orpheline (autrement dit, elle n'existe que sur certains serveurs) ou bloquée (elle existe sur tous les serveurs mais, pour une raison quelconque, son état ne progresse pas).
Appliquez les consignes suivantes pour remédier à un problème de notice nécrologique bloquée ou orpheline :
-625, -622, -634 et –635, qui sont des problèmes de communication. Pour plus d'informations, reportez-vous à Rapport d'informations sur le serveur.
-601 et -603, qui indiquent que des serveurs n'ont pas été correctement supprimés ou que l'objet Serveur a une classe de base inconnue.
Utilisez la solution appropriée indiquée dans Conseils de dépannage.
Avant d'appliquer une de ces solutions, vérifiez que vos données sont sécurisées. Vous devrez peut-être effectuer une sauvegarde des fichiers de la base de données d'annuaire, de la configuration du serveur et des ayants droit. Pour augmenter vos chances de succès et réduire les risques de problèmes futurs, installez les derniers Support Pack pour eDirectory.
Résolution des problèmes de notices nécrologiques orphelines
- Méthode privilégiée : si eDirectory 8.6 (ou version ultérieure) est installé sur l'un des serveurs de l'anneau de répliques, dans la liste des objets d'iMonitor, sélectionnez Envoyer une unique entrée. Vous effectuez ainsi un envoi non expert à toutes les autres répliques.
- Méthode la moins recommandée : activez le mode avancé dans iMonitor, recherchez l'objet, sélectionnez Options avancées, puis Assigner un tampon horaire à l'entrée. L'objet, tel qu'il existe sur ce serveur, devient ainsi la copie experte. Toutefois, Novell déconseille cette dernière méthode qui est contraire aux bonnes pratiques.
- Méthode vivement déconseillée : si tous les serveurs de l'anneau de répliques qui possèdent une copie de la notice nécrologique orpheline disposent d'une version postérieure à eDirectory 8.6, chargez DSBrowse avec l'option -a, recherchez l'objet, puis sélectionnez « Renvoyer l'objet sélectionné » pour associer un tampon horaire à l'entrée. L'objet, tel qu'il existe sur ce serveur, devient ainsi la copie experte. Toutefois, Novell déconseille cette dernière méthode qui est contraire aux bonnes pratiques.
Résolution des problèmes de notices nécrologiques orphelines dans les références externes
- Méthode privilégiée : exécutez la dernière version de DSRepair avec l'option -XK3. Toutefois, commencez par vérifier si toutes les opérations exécutées par -XK3 sont acceptables.
- Méthode vivement déconseillée : déplacez une réplique réelle vers le serveur, attendez qu'elle soit active, puis que la notice nécrologique soit traitée. Si la notice nécrologique n'est pas traitée, utilisez les informations fournies dans Conseils de dépannage pour résoudre le problème maintenant que l'objet est dans une réplique réelle. Une fois la notice nécrologique traitée, vous pouvez supprimer la réplique si vous le souhaitez.
Résolution des problèmes liés aux notices nécrologiques OBT_INHIBIT_MOVE
- Méthode privilégiée : si l'objet cible est complet, vérifiez si la source existe toujours. S'il existe toujours et qu'il possède l'attribut OBT_MOVED, corrigez les problèmes qui ont empêché le traitement de OBT_MOVED. S'il n'existe pas d'objet source, utilisez les options iMonitor du mode avancé pour libérer OBT_MOVE_INHIBIT maîtresse de l'objet cible. Si l'objet cible est incomplet, libérez OBT_MOVE_INHIBIT et supprimez cet objet cible.
Dans le passé, plusieurs méthodes ont été employées pour remédier au blocage des notices nécrologiques. Certaines impliquaient des opérations de partition onéreuses ou l'utilisation de fonctions qui ne faisaient l'objet d'aucune documentation et pouvaient provoquer des problèmes dans le futur. La plupart des méthodes listées ci-après sont donc déconseillées.
La première consiste à changer la réplique qui contient le maître. Cette méthode fonctionnait dans certains cas, puisque le maître est l'agent chargé de faire passer les notices nécrologiques Lien en amont par leurs différents états. Quand la réplique est incohérente et que le maître ne contient pas l'objet supprimé, le remplacement des maîtres par un agent qui contient l'entrée supprimée avec ses notices nécrologiques permet à ce dernier de faire passer les notices par leurs différents états successifs pour finalement les purger. L'envoi d'une unique entrée est un moyen beaucoup moins dangereux de résoudre les problèmes de notices nécrologiques bloquées à cause d'une réplique incohérente.
La deuxième méthode consiste à exécuter DSRepair avec certains paramètres afin de supprimer toutes les notices nécrologiques. (Il existe une application tierce qui répare toutes les notices nécrologiques bloquées en lançant DSRepair.) L'équipe de développement d'eDirectory déconseille cette méthode. L'utilisation de ces paramètres supprime toutes les notices nécrologiques de l'agent, y compris celles qui ne sont pas bloquées, avec le risque de provoquer de nouvelles incohérences et davantage de blocages de notices nécrologiques. Comme il ne s'agit pas d'une opération distribuée, vous devez exécuter DSRepair sur tous les serveurs qui contiennent des notices nécrologiques bloquées, ce qui augmente les risques de supprimer prématurément les notices nécrologiques d'un de ces serveurs qui abriterait celles d'une autre partition. En supprimant prématurément des notices nécrologiques, vous risquez de créer d'autres notices orphelines et de provoquer des problèmes qui ne seront pas détectés avant plusieurs années, lorsque vous modifierez les types de réplique, ajouterez des répliques ou effectuerez d'autres opérations de partitionnement.
La troisième méthode consiste à rendre les objets experts soit en utilisant DSBrowse en mode avancé et en associant un tampon horaire à l'entrée, soit en exécutant DSRepair avec le paramètre -0T. Cette méthode rend l'entrée experte et celle-ci se synchronise avec toutes les autres répliques. Elle doit être utilisée avec une grande prudence, parce que vous risquez de perdre des données modifiées sur d'autres serveurs. L'équipe de développement d'eDirectory recommande de l'utiliser aussi rarement que possible.
Pour plus d'informations sur les marques de NetIQ, rendez-vous sur le site http://www.netiq.com/company/legal/.