Nachrufe

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.

Beispiele

Dieser Abschnitt enthält die folgenden Beispiele:

Objekt löschen

  1. Primären Nachruf OBT_DEAD hinzufügen.
  2. Das Backlink-Attribut enthält eine Liste der Server, die ein Interesse an diesem Objekt haben und über Änderungen dieses Eintrags benachrichtigt werden müssen. Für jeden DN, der im Backlink-Attribut aufgeführt ist, und für alle Server, die im Partitionsreproduktionsattribut des Eintrags aufgeführt sind, fügt eDirectory einen Backlink-Nachruf hinzu. Der Zeitpunkt der Erstellung des primären Nachrufs, nämlich OBT_DEAD, wird im sekundären Nachruf gespeichert.
  3. Das Attribut "Genutzt durch" enthält eine Liste der Server, die ein Interesse an diesem Objekt haben und über Änderungen dieses Eintrags benachrichtigt werden müssen. Für jeden DN, der im Attribut "Genutzt durch" aufgeführt ist, fügt eDirectory einen Nachruf "Genutzt durch" hinzu. Der Zeitpunkt der Erstellung des primären Nachrufs, nämlich OBT_DEAD, wird im sekundären Nachruf gespeichert.
  4. Entfernen aller Attribute außer der Nachrufe.
  5. Der ausgehende Reproduktionsvorgang synchronisiert dann diese Änderung mit allen anderen Servern im Reproduktionsring.
  6. Bei der nächsten Eingangssynchronisierung dieser Partition wird der Nachrufvorgang gestartet, der Folgendes ausführt:

    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.

Objekt verschieben

Der Vorgang "Verschieben" ist dem Vorgang Löschen sehr ähnlich, unterscheidet sich jedoch in den folgenden Punkten davon:

  1. Vor Platzierung des primären Nachrufs im Ursprungseintrag für den Verschiebevorgang wird ein Teileintrag im Zielcontainer erstellt und ein Verfolgungsnachruf (OBT_INHIBIT_MOVE) in diesem Teileintrag platziert. Dieser Verfolgungsnachruf wird platziert, um zu verhindern, dass der Eintrag verschoben wird oder an einem Partitionsvorgang beteiligt ist, bevor der gesamte Eintrag aus dem Ursprung übertragen wurde.
  2. Der primäre Nachruf im Ursprungseintrag ist vom Typ OBT_MOVED.
  3. Nachdem der primäre Nachruf OBT_MOVED in den Zustand "Benachrichtigt" versetzt wurde (was bedeutet, dass alle Reproduktionen des Ursprungs nun darüber informiert sind, dass der Eintrag verschoben wird) und alle externen Verweise benachrichtigt wurden, wird der Verfolgungsnachruf (OBT_INHIBIT_MOVE) aus dem Zieleintrag entfernt.

Auswirkungen blockierter und bezugsloser Nachrufe

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.

Vorbeugende Maßnahme

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.

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:

Lösungen

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.

Bezugslose Nachrufe auflösen

Bezugslose Nachrufe auf externen Verweisen auflösen

OBT_INHIBIT_MOVE-Nachrufe auflösen

Frühere Vorgehensweisen

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/.