Die im Verzeichnis gespeicherten Nachrufe haben bereits einige Verwirrung gestiftet, was dazu führte, dass einige Benutzer sich schlechte Geschäftspraktiken im Umgang damit angeeignet haben. Im Gegensatz zu einigen anderen Verzeichnisdienstprodukten stellt eDirectory eine Verweisintegrität zwischen Objekten sicher. Wenn sich zum Beispiel in Gruppe A ein Mitglied, Benutzer B, befindet und Benutzer B später gelöscht wird, so entfernt das Verzeichnis automatisch den Verweis auf Benutzer B aus Gruppe A. Nachrufe sind Vorgangsattribute, die eDirectory in Objekten platziert, um so ebenfalls die Verweisintegrität beim Löschen, Verschieben, Umbenennen, Wiederherstellen und bei anderen Vorgängen sicherzustellen.
Es gibt drei allgemeine Arten von Nachrufen: primäre, sekundäre und Verfolgungsnachrufe. Primäre Nachrufe sind Nachrufe vom Typ "Inaktiv" (0001), "Wiederhergestellt" (0000), "Verschoben" (0002), "Neue RDN" (0005) und "Baum neue RDN" (0008). Sekundäre Nachrufe sind in der Regel mit einem primären Nachruf verknüpft und stellen die Agenten und Partitionen dar, die über den im primären Nachruf angegebenen Vorgang benachrichtigt werden müssen. Sekundäre Nachrufe sind Nachrufe vom Typ "Backlink" (0006), "Genutzt durch" (000C) und "Baum verschieben" (000a). Verfolgungsnachrufe sind "Verschieben sperren" (0003), "Alte RDN" (0004) und "Baum alte RDN" (0007).
Abgesehen von den Verfolgungsnachrufen müssen Nachrufe eine Reihe von Synchronisierungszuständen durchlaufen.
Die Zustände werden im Flaggenfeld im Nachrufattribut protokolliert. Bevor ein Nachruf in den nächsten Zustand übergehen kann, muss der aktuelle Zustand mit allen Reproduktionen des echten Objekts synchronisiert sein. Um festzustellen, ob alle Reproduktionen im Ring einen gegebenen Nachrufzustand erkannt haben, wird anhand des transitiven Vektors ein Vektor berechnet. In eDirectory 8.6 wird ein nicht gespeicherter Nachrufvektor verwendet. In früheren Versionen von eDirectory wird der Entfernvektor verwendet. Wenn der Änderungszeitstempel (MTS) auf dem Nachruf älter als der beschädigte Vektor ist, so kann der Server, der für diesen Nachruf zuständig ist, diesen in den nächsten Zustand überführen.
Für einen sekundären Nachruf vom Typ "Backlink" ist der Agent, der die Masterreproduktion des Objekts mit dem Nachruf enthält, dafür zuständig, den Nachruf in die nächsten Zustände zu versetzen. Für einen sekundären Nachruf vom Typ "Genutzt durch" ist der Reproduktionsagent, der ihn erstellt hat, dafür zuständig, den Nachruf in die nächsten Zustände zu befördern, und zwar so lange wie die Reproduktion besteht. Wenn die Reproduktion nicht mehr vorhanden ist, so übernimmt es der Agent mit der Masterreproduktion dieser Partition, den Nachruf vom Typ "Genutzt durch" in die nächsten Zustände zu versetzen. Bei einem Nachruf vom Typ "Baum verschieben" ist die Masterreproduktion der Stammpartition dafür zuständig, den Nachruf in die nächsten Zustände zu versetzen.
Primäre Nachrufe können nur dann in die nächsten Zustände versetzt werden, wenn alle sekundären Nachrufe alle Zustände durchlaufen haben. Wenn ein primärer Nachruf seinen letzten Zustand erreicht hat und dieser Zustand mit allen Servern im Ring synchronisiert ist, so bleibt nur die Objekthülle übrig, also ein Objekt ohne Attribute, das folglich durch den Entfernvorgang aus dem System entfernt werden kann. Verfolgungsnachrufe werden entfernt, sobald der primäre Nachruf entfernt werden kann. Bei "Verschieben sperren" wird der Verfolgungsnachruf entfernt, sobald der primäre Nachruf in den Zustand OBF_NOTIFIED auf der Masterreproduktion übergegangen ist.
Die für die Verarbeitung der Nachrufe zuständige Reproduktion erledigt dies im Hintergrund (im Nachrufvorgang), der auf pro-Partition-Basis geplant ist und ausgeführt wird, wenn eine gegebene Partition einen Eingangssynchronisierungszyklus abgeschlossen hat. Sind keine anderen Reproduktionen der Partition vorhanden, so wird der ausgehende Reproduktionsvorgang weiterhin im Heartbeat-Intervall geplant. Der ausgehende Reproduktionsvorgang startet dann den Nachrufvorgang. Der Nachrufvorgang kann nicht manuell geplant werden, was jedoch auch nicht erforderlich ist. Bei der Synchronisierung werden die transitiven Vektoren aktualisiert und geben den Entfernvektor und den Nachrufvektor weiter. Wenn diese Vektoren in den nächsten Zustand versetzt werden, können die Nachrufe ebenfalls in die nächsten Zustände übergehen. Zusammen mit der automatischen Planung durch die Eingangssynchronisierung schließt dies den Nachrufvorgangszyklus ab. Somit stellt die Objektsynchronisierung den Lebensnerv der Nachrufverarbeitung dar.
Nachdem alle Nachrufe, deren verknüpfte primäre Nachrufe vom Typ "Inaktiv" sind, in den letzten Zustand (Entfernbar) versetzt wurden und dieser Zustand mit allen Reproduktionen synchronisiert wurde, ist nun für ein Objekt, das entfernt wird, ein neuer Vorgang zur Entfernung der verbleibenden Eintragshülle aus der Datenbank zuständig. Der Entfernvorgang wird automatisch ausgeführt, um diese Hüllen zu entfernen. Auf
der Seite Agentenkonfiguration in iMonitor kann der Entfernvorgang manuell geplant und sein automatisches Planintervall geändert werden.Dieser Abschnitt enthält die folgenden Beispiele:
Wenn der Nachruf ein primärer Nachruf ist, es keine sekundären Nachrufe gibt und die Änderungszeit (MTS) des Attributs im Nachruf älter als der Tilgungsvektor ist, so haben alle Server diese Änderung erfasst und dieser Nachruf wird entfernt.
Wenn es sich bei dem Nachruf um einen Backlink-Nachruf handelt und dieser Server der Master ist, so ist dieser Server für die Verarbeitung dieses Nachrufs zuständig.
Durchführung des für diesen Zustand erforderlichen Vorgangs, falls noch nicht erfolgt. In den meisten Fällen erfolgt dies durch Benachrichtigung eines externen Verweises.
Wenn der Nachruf ein Nachruf vom Typ "Genutzt durch" ist und dieser Server der Server ist, auf dem der Löschvorgang ausgeführt wurde (was durch Vergleichen der Reproduktionsnummer in der Änderungszeit (MTS) im Nachruf mit unserer Reproduktionsnummer festgestellt wird), so ist dieser Server für die Verarbeitung dieses Nachrufs zuständig.
Der Vorgang "Verschieben" ist dem Vorgang Löschen sehr ähnlich, unterscheidet sich jedoch in den folgenden Punkten davon:
Objekte mit Nachrufen werden immer dann in Betracht gezogen, wenn ein Agent ausgehend synchronisiert. Sie werden auch vom Nachrufvorgang in Betracht gezogen, der planmäßig am Ende eines Eingangssynchronisierungszyklus ausgeführt wird.
Erstellen Sie in regelmäßigen Abständen den Bericht "Serverinformationen in iMonitor". Dieser Bericht führt durch den gesamten Baum, kommuniziert mit jedem vorgefundenen NCP-Server und meldet alle gefundenen Fehler. Mit Hilfe dieses Berichts können Zeitsynchronisierung und Limberprobleme diagnostiziert werden oder es kann herausgefunden werden, ob der aktuelle Server mit allen anderen Servern aus der Sicht dieses Servers kommunizieren kann. Nach der entsprechenden Auswahl auf der Konfigurationsseite kann dieser Server auch für jeden Server im Baum Informationen zum NDS-Agentenzustand generieren. Weitere Informationen zur Erstellung des Berichts "Serverinformationen" finden Sie unter Berichtkonfiguration.
Wenn Sie iMonitor 2.0 oder höher verwenden, stellen Sie sicher, dass die folgenden Berichtsoptionen aktiviert sind: Teilberichte zu Fehlern und Zustand. Die folgenden Punkte werden überprüft. Sie sollten den Bericht durchsuchen und sicherstellen, dass keine Fehler aufgetreten sind.
Wenn Sie iMonitor 1.5 verwenden, wählen Sie die Berichtart "Fehler" aus. Die folgenden Punkte werden überprüft. Sie sollten den Bericht durchsuchen und sicherstellen, dass keine Fehler aufgetreten sind.
Mit Hilfe der iMonitor-Berichte "Nachrufliste" oder "Objektstatistik" finden Sie alle Nachrufe, die sich auf Ihrem System befinden. Sollten Sie Nachrufe finden, die anscheinend nicht verarbeitet werden, erhalten Sie Informationen dazu unter Tipps zur Fehlersuche.
Es gibt im Allgemeinen zwei Ursachen für nicht verarbeitete Nachrufe: Der Nachruf ist entweder bezugslos (das heißt, er ist auf einigen Servern vorhanden, jedoch nicht auf allen) oder der Nachruf wurde blockiert (was bedeutet, dass er auf allen Servern vorhanden ist, aus irgendeinem Grund aber nicht in die nächsten Zustände überführt wird).
Gehen Sie bei bezugslosen oder blockierten Nachrufen zur Fehlersuche wie folgt vor:
die Kommunikationsprobleme -625, -622, -634 und -635. Weitere Informationen finden Sie unter Bericht der Serverinformationen.
-601 und -603 geben an, dass einige Server nicht richtig entfernt wurden oder dass das Serverobjekt möglicherweise die Basisklasse "Unbekannt" hat.
Verwenden Sie die entsprechende Lösung wie unter Tipps zur Fehlersuche angegeben.
Vor der Anwendung dieser Lösungen müssen Sie sicherstellen, dass Ihre Daten gesichert sind. Sie müssen eventuell die Verzeichnisdatenbankdateien, die Serverkonfiguration und die Trustees sichern. Um die Wahrscheinlichkeit zu erhöhen, dass die Aktion erfolgreich ist und um zukünftige Probleme zu minimieren, rüsten Sie auf die neuesten eDirectory Support Packs auf.
- Bevorzugte Methode: Wenn eDirectory 8.6. oder höher auf einem der Server im Reproduktionsring installiert ist, wechseln Sie zu dem Objekt in iMonitor und wählen Sie die Option zum Senden eines Einzeleintrags. Dadurch wird ein nicht autorisierter Sendevorgang an alle anderen Reproduktionen ausgeführt.
- Nachrangige Methode: Aktivieren Sie "Erweiterter Modus" in iMonitor, wechseln Sie zu dem Objekt und wählen Sie "Erweiterte Optionen" und danach "Zeitstempeleintrag" aus. Dadurch wird das Objekt, das sich so auf diesem Server befindet, zu einer autorisierten Kopie. Novell rät aus praktischen Gründen davon ab, Objekte zu autorisieren.
- Nur bei Alternativlosigkeit anzuwenden: Wenn alle Server im Reproduktionsring mit einer Kopie des bezugslosen Nachrufs älter sind als eDirectory 8.6, laden Sie DSBrowse mit der Option -a, wechseln Sie zum Objekt und wählen Sie dann "Gewähltes Objekt erneut senden", um den Eintrag mit einem Zeitstempel zu versehen. Dadurch wird das Objekt, das sich so auf diesem Server befindet, zu einer autorisierten Kopie. Novell rät aus praktischen Gründen davon ab, Objekte zu autorisieren.
Bezugslose Nachrufe auf externen Verweisen auflösen
- Bevorzugte Methode: Führen Sie die neueste Version von DSRepair mit der Option -XK3 aus. Überprüfen Sie jedoch zuerst, ob alle von -XK3 durchgeführten Operationen akzeptabel sind.
- Nachrangige Methode: Verschieben Sie eine echte Reproduktion auf den Server. Warten Sie auf ihren Start und die Verarbeitung des Nachrufs. Wenn der Nachruf nicht verarbeitet wird, gehen Sie entsprechend der Informationen unter Tipps zur Fehlersuche vor, um das Problem aufzulösen, nachdem es sich jetzt in einer echten Reproduktion befindet. Nach Verarbeitung des Nachrufs kann die Reproduktion, falls gewünscht, entfernt werden.
OBT_INHIBIT_MOVE-Nachrufe auflösen
- Bevorzugte Methode: Wenn das Zielobjekt erstellt ist, sehen Sie nach, ob das Ursprungsobjekt noch vorhanden ist. Ist das Ursprungsobjekt vorhanden und noch mit dem Attribut OBT_MOVED versehen, finden Sie heraus, warum OBT_MOVED nicht abgeschlossen wurde, und beheben Sie das Problem. Ist kein Ursprungsobjekt vorhanden, geben Sie mit Hilfe der Optionen des erweiterten Modus von iMonitor den OBT_MOVE_INHIBIT-Nachruf auf der Masterreproduktion des Zielobjekts frei. Wenn das Zielobjekt unvollständig ist, geben Sie den OBT_MOVE_INHIBIT-Nachruf frei und entfernen Sie das Zielobjekt.
In der Vergangenheit wurden einige verschiedene Strategien angewandt, um blockierte Nachrufe zu löschen. Einige dieser Strategien basieren auf teuren Partitionierungsvorgängen oder verwenden nicht dokumentierte Eigenschaften, die in der Zukunft möglicherweise Probleme verursachen. Einige der unten aufgeführten Strategien sollten nicht angewandt werden.
Die erste Strategie bestand darin, die Reproduktion umzustellen, auf der sich der Master befand. Dies funktioniert in einigen Fällen, da der Master der Agent ist, der dafür zuständig ist, die Backlink-Nachrufe in ihre nächsten Zustände zu versetzen. Wenn die Reproduktion inkonsistent war und der Master das gelöschte Objekt nicht enthielt, gab die Umstellung der Master auf einen Agenten, der den gelöschten Eingang mit den Nachrufen enthielt, dem neuen Agenten die Genehmigung, die Nachrufe in ihre nächsten Zustände zu versetzen und sie schließlich zu tilgen. Die Option "Einzeleintrag senden" ist eine viel sauberere und weniger gefährliche Methode zur Auflösung von Nachrufen, die aufgrund der inkonsistenten Reproduktion blockiert wurden.
Die zweite Strategie bestand darin, DSRepair mit bestimmten Parametern auszuführen, um alle Nachrufe zu löschen. (Es gibt eine Drittanbieter-Anwendung, die blockierte Nachrufe beim Start von DSRepair löscht.) Das Entwicklungsteam von eDirectory rät von dieser Strategie ab. Durch diese Parameter werden alle Nachrufe auf diesem Agenten gelöscht, was bedeutet, dass möglicherweise auch nicht blockierte Nachrufe entfernt und so neue inkonsistente Reproduktionen und weitere blockierte Nachrufe erzeugt werden. Da es sich hierbei nicht um eine dezentrale Operation handelt, müssen Sie DSRepair auf allen Servern mit blockierten Nachrufen ausführen, wodurch die Wahrscheinlichkeit erhöht wird, dass einer dieser Server Nachrufe für eine andere Partition enthält, die dadurch vorzeitig gelöscht werden. Wenn Nachrufe vorzeitig gelöscht werden, kann dies zusätzliche bezugslose Nachrufe erzeugen und wiederum Probleme schaffen, die erst Jahre später auftauchen, wenn Sie Reproduktionstypen ändern, neue Reproduktionen hinzufügen oder andere Partitionsvorgänge durchführen.
Bei der dritten Strategie wurden Objekte autorisiert, indem entweder DSBrowse im erweiterten Modus ausgeführt und der Eintrag mit einem Zeitstempel versehen oder DSRepair mit dem Parameter -0T ausgeführt wurde. Dadurch wird der Eintrag gezwungenermaßen autorisiert und mit allen anderen Reproduktionen synchronisiert. Zeitstempel und autorisierte Objekte sollten mit Vorsicht eingesetzt werden, da Sie dadurch möglicherweise Daten verlieren, die auf anderen Servern geändert werden. Das Entwicklungsteam von eDirectory rät Ihnen, diese Methode der Nachruflöschung nur sehr selten anzuwenden.
Weitere Informationen zu den Marken von NetIQ finden Sie im Internet unter http://www.netiq.com/company/legal/.