Omówienie technik śledzenia zmian

Istnieje kilka sposobów, na które mechanizmy śledzenia zmian mogą się różnić:

• Zakres śledzenia zmian: aplikacja może śledzić zmiany w pojedynczym atrybucie pojedynczego obiektu, do wszystkich obiektów w domenie itd. Jeśli mechanizm spełnia wymagania aplikacji, aplikacja otrzymuje co najmniej nieistotne dane, co zwiększa wydajność.

• Terminowość: Aplikacja jest powiadamiana o każdej zmianie w momencie jej wystąpienia lub może być powiadamiana o całościowym efekcie zmian w ciągu kilku minut lub godzin.

  Przetwarzanie mniej czasochłonnych danych może być bardziej wydajne, ponieważ kilka zmian może zostać zwiniętych do jednego. Na przykład, jeśli atrybut zmieni się trzy razy w ciągu jednej godziny, aplikacja, powiadamiana o zmianach skumulowanych w ciągu tej godziny, zostanie poinformowana tylko o jednej zmianie atrybutu, a nie trzech.

  Podczas myślenia o osi czasu należy wziąć pod uwagę wpływ opóźnienia replikacji. Aktualizacja pochodząca z jednego kontrolera domeny nie jest natychmiast replikowana do innego kontrolera domeny. Wymóg śledzenia zmian w czasie znacznie krótszym niż zakładane opóźnienie replikacji często nie przynosi aplikacji rzeczywistej korzyści.

• Sondowanie a powiadomienie: W przypadku sondowania aplikacja okresowo wysyła żądanie do kontrolera domeny w celu odbierania danych śledzenia zmian. Po powiadomieniu kontroler domeny wysyła zmiany do aplikacji tylko wtedy, gdy wystąpią zmiany.

  Obciążenie związane z sondowaniem jest oczywiste: aplikacja może zażądać danych śledzenia zmian, gdy nic znaczącego nie wystąpiło. Obciążenie powiadomienia jest bardziej subtelne. Serwer musi przechowywać dane dotyczące żądań powiadomień i musi skonsultować się z danymi, aby zdecydować, czy wysłać powiadomienie. Może to dodawać obciążenie do normalnych żądań aktualizacji.

• Wyrażanie wiedzy aplikacji: trwałe i tymczasowe: każdy mechanizm śledzenia zmian musi zawierać jakąś metodę dla serwera przechowującego dane śledzone, aby zrozumieć stan wiedzy aplikacji, aby pomysł "zmiany" był dobrze zdefiniowany. Na przykład stan wiedzy aplikacji może być wyrażony jako "Zaktualizowano o wszystkie zmiany, które wystąpiły na kontrolerze domeny d przed godziną t". Mechanizm oparty na tym sposobie wyrażania stanu wiedzy aplikacji zapewni wydajny sposób uzyskiwania przez aplikację zmian, które wystąpiły później niż określony czas.

  Jeśli wyrażenie wiedzy aplikacji może być utrwalane, czyli przechowywane w sposób odzyskany, jak w pliku lub bazie danych, ponowne uruchomienie aplikacji jest mniej obciążające zasoby, niż jeśli nie może. W powyższym przykładzie można utrwalać wyrażenie wiedzy aplikacji poprzez zarejestrowanie DC d i czasu t. Niektóre mechanizmy powiadamiania o zmianie nie zezwalają na utrwalanie tych danych. Serwer i aplikacja muszą synchronizować się z innym mechanizmem po uruchomieniu aplikacji. Jest to intensywne wykorzystanie zasobów, jeśli zaangażowanych jest wiele obiektów i może obejmować złożone programowanie.

Użyj następujących technik, aby śledzić zmiany w usługach Active Directory Domain Services:

• Użyj kontrolki powiadamiania o zmianie, aby zainicjować trwałe, asynchroniczne wyszukiwanie zmian pasujących do określonego filtru. Aby uzyskać więcej informacji, zobacz Powiadomienia o zmianach w usługach domenowych Active Directory.
• Użyj wyszukiwania synchronizacji katalogów (DirSync), aby pobrać zmiany, które wystąpiły od poprzedniego wyszukiwania DirSync. Aby uzyskać więcej informacji, zobacz Sondowanie Zmian przy użyciu Kontrolki DirSync.
• Użyj atrybutu USNChanged, aby wyszukać obiekty, które uległy zmianie od poprzedniego wyszukiwania. Aby uzyskać więcej informacji, zobacz sondowanie zmian przy użyciuUSNChanged.

Kontrolka powiadamiania o zmianie jest przeznaczona dla aplikacji lub usług, które wymagają szybkiego powiadamiania o rzadko występujących zmianach. Przykładem jest usługa lub program, który przechowuje dane konfiguracji na serwerze usługi Active Directory i musi być powiadamiany natychmiast po wystąpieniu zmiany. Należy pamiętać, że istnieją ograniczenia kontrolki powiadomień.

• Szybkość powiadomień zależy od opóźnienia replikacji i miejsca, w którym nastąpiła zmiana. Możesz zostać powiadomiony natychmiast, gdy zmiana jest replikowana do monitorowanej repliki, ale zmiana mogła pochodzić znacznie wcześniej na innej replice.
• Kontrolka jest ograniczona do monitorowania pojedynczego obiektu lub bezpośrednich elementów podrzędnych kontenera. Aplikacje, które muszą monitorować wiele kontenerów lub niepowiązanych obiektów, mogą rejestrować maksymalnie pięć żądań powiadomień.
• Jeśli zbyt wielu klientów nasłuchuje zmian, które występują często, będzie to miało wpływ na wydajność serwera. Ogólnie rzecz biorąc, aplikacje powinny ograniczyć korzystanie z tej kontrolki ze względów wydajności na serwerze. Jeśli nie musisz od razu wiedzieć o zmianach, najlepiej okresowo sprawdzać zmiany zamiast korzystania z powiadomień o zmianach.

Techniki wyszukiwania DirSync i USNChanged są przeznaczone dla aplikacji, które zachowują spójność między danymi na serwerze usługi Active Directory i odpowiednimi danymi w innym magazynie. Te techniki są używane przez aplikacje, które okresowo sondują pod kątem zmian. Technika narzędzia DirSync jest oparta na kontrolce serwera LDAP, której można używać za pośrednictwem interfejsów API ADSI lub LDAP. Wady kontrolki DirSync są takie, że mogą być używane tylko przez wysoce uprzywilejowane konto, takie jak administrator domeny. Poniżej znajduje się lista ograniczeń kontrolki DirSync:

• Kontrolka DirSync może być używana tylko przez wysoce uprzywilejowane konto, takie jak administrator domeny.
• Kontrolka DirSync może monitorować tylko cały kontekst nazewnictwa. Nie można ograniczyć zakresu wyszukiwania DirSync do monitorowania tylko określonego poddrzewa, kontenera lub obiektu w kontekście nazewnictwa.

Technika USNChanged nie ma tych ograniczeń, chociaż jest nieco bardziej skomplikowana do użycia niż DirSync.