Freigeben über

Übersicht über Änderungsnachverfolgung Techniken

  • Artikel

Es gibt mehrere Möglichkeiten, die Änderungsnachverfolgungsmechanismen unterscheiden können:

  • Bereich für die Nachverfolgung von Änderungen: Eine Anwendung kann Änderungen an einem einzelnen Attribut eines einzelnen Objekts, an allen Objekten in einer Domäne usw. nachverfolgen. Wenn der Mechanismus den Anforderungen der Anwendung entspricht, erhält die Anwendung ein Minimum an irrelevanten Daten, was die Leistung verbessert.

  • Zeitachsen: Eine Anwendung wird über jede Änderung benachrichtigt oder kann über den Nettoeffekt von Änderungen über einen Zeitraum von Minuten oder Stunden informiert werden.

    Die Verarbeitung von weniger zeitsparenden Daten kann effizienter sein, da mehrere Änderungen möglicherweise in eine unterteilt werden. Wenn sich ein Attribut beispielsweise innerhalb eines Intervalls von einer Stunde dreimal ändert, wird eine Anwendung, die über Änderungen benachrichtigt wird, die sich über eine Stunde kumuliert haben, nur über eine Attributänderung benachrichtigt, nicht über drei.

    Wenn Sie über Zeitachsen nachdenken, sollten Sie die Auswirkungen der Replikationslatenz berücksichtigen. Ein Update, das von einem Domänencontroller stammt, wird nicht sofort auf einen anderen Domänencontroller repliziert. Das Erfordern von Änderungsnachverfolgungszeitachsen ist viel besser als die erwartete Replikationslatenz, was häufig keinen wirklichen Nutzen für die Anwendung bringt.

  • Abfrage versus Benachrichtigung: Bei Der Abfrage stellt eine Anwendung regelmäßig eine Anforderung an einen Domänencontroller, um Änderungsnachverfolgungsdaten zu empfangen. Mit Benachrichtigung sendet der Domänencontroller Änderungen nur an die Anwendung, wenn Änderungen auftreten.

    Der Aufwand der Abfrage ist offensichtlich: Die Anwendung kann Änderungsnachverfolgungsdaten anfordern, wenn nichts Wesentliches aufgetreten ist. Der Aufwand für Benachrichtigungen ist subtiler. Der Server muss Daten zu Benachrichtigungsanforderungen verwalten und diese Daten konsultieren, um zu entscheiden, ob eine Benachrichtigung gesendet werden soll oder nicht. Dies kann zu zusätzlichem Mehraufwand für normale Updateanforderungen führen.

  • Das Wissen der Anwendung zum Ausdruck bringen: persistent oder temporär: Jeder Änderungsnachverfolgungsmechanismus muss eine Methode für den Server enthalten, der die nachverfolgten Daten enthält, um den Wissensstand der Anwendung zu verstehen, sodass die Idee der "Änderung" gut definiert ist. Beispielsweise kann der Wissensstatus der Anwendung als "Aktualisiert mit allen Änderungen, die an DC d vor dem Zeitpunkt t aufgetreten sind" ausgedrückt werden. Ein Mechanismus, der auf dieser Art zum Ausdrücken des Wissensstatus einer Anwendung basiert, bietet eine effiziente Möglichkeit für die Anwendung, Änderungen abzurufen, die später als zu einem angegebenen Zeitpunkt aufgetreten sind.

    Wenn der Ausdruck des Wissens der Anwendung beibehalten werden kann, d. h. wiederherstellbar wie in einer Datei oder Datenbank gespeichert werden kann, ist der Anwendungsneustart weniger ressourcenintensiv, als wenn er dies nicht kann. Im obigen Beispiel kann der Ausdruck des Wissens der Anwendung beibehalten werden, indem der DC d und die Zeit t aufgezeichnet werden. Einige Änderungsbenachrichtigungsmechanismen lassen es nicht zu, dass diese Daten beibehalten werden. Server und Anwendung müssen beim Starten der Anwendung mit einem anderen Mechanismus synchronisiert werden. Dies ist ressourcenintensiv, wenn mehrere Objekte beteiligt sind, und kann eine komplexe Programmierung erfordern.

Verwenden Sie die folgenden Techniken, um Änderungen in Active Directory Domain Services nachzuverfolgen:

Das Änderungsbenachrichtigungssteuerelement ist für Anwendungen oder Dienste konzipiert, die eine angemessene zeitnahe Benachrichtigung über seltene Änderungen erfordern. Ein Beispiel ist ein Dienst oder Ein Programm, das Konfigurationsdaten auf dem Active Directory-Server speichert und sofort benachrichtigt werden muss, wenn eine Änderung eintritt. Beachten Sie, dass es Einschränkungen für das Benachrichtigungssteuerelement gibt.

  • Die Eingabeaufforderung von Benachrichtigungen hängt von der Replikationslatenz und dem Ort der Änderung ab. Sie werden möglicherweise umgehend benachrichtigt, wenn eine Änderung in das von Ihnen überwachte Replikat repliziert wird, aber die Änderung ist möglicherweise viel früher auf einem anderen Replikat entstanden.
  • Das Steuerelement ist auf die Überwachung eines einzelnen Objekts oder der unmittelbar untergeordneten Elemente eines Containers beschränkt. Anwendungen, die mehrere Container oder nicht verwandte Objekte überwachen müssen, können bis zu fünf Benachrichtigungsanforderungen registrieren.
  • Wenn zu viele Clients auf Änderungen lauschen, die häufig auftreten, wirkt sich dies auf die Leistung des Servers aus. Im Allgemeinen sollten Anwendungen die Verwendung dieses Steuerelements aus Leistungsgründen auf dem Server einschränken. Wenn Sie änderungen nicht sofort kennen müssen, empfiehlt es sich, regelmäßig nach Änderungen abzufragen, anstatt änderungsbenachrichtigungen zu verwenden.

Die Suchtechniken DirSync und USNChanged sind für Anwendungen konzipiert, die die Konsistenz zwischen Daten auf dem Active Directory-Server und entsprechenden Daten in einem anderen Speicher gewährleisten. Diese Techniken werden von Anwendungen verwendet, die in regelmäßigen Abständen nach Änderungen abfragen. Die DirSync-Technik basiert auf einem LDAP-Serversteuerelement, das Sie über ADSI oder LDAP-APIs verwenden können. Die Nachteile des DirSync-Steuerelements sind, dass es nur von einem Konto mit hoher Berechtigung verwendet werden kann, z. B. von einem Domänenadministrator. Im Folgenden finden Sie eine Liste der Einschränkungen des DirSync-Steuerelements:

  • Das DirSync-Steuerelement kann nur von einem Konto mit hohen Berechtigungen verwendet werden, z. B. von einem Domänenadministrator.
  • Das DirSync-Steuerelement kann nur einen gesamten Benennungskontext überwachen. Sie können den Bereich einer DirSync-Suche nicht einschränken, um nur eine bestimmte Unterstruktur, einen bestimmten Container oder ein bestimmtes Objekt in einem Benennungskontext zu überwachen.

Die USNChanged-Technik weist diese Einschränkungen nicht auf, obwohl die Verwendung etwas komplizierter ist als DirSync.