다음을 통해 공유

변경 내용 추적 기술 개요

  • 아티클

변경 내용 추적 메커니즘이 다를 수 있는 몇 가지 방법이 있습니다.

  • 변경 내용 추적 범위: 애플리케이션은 단일 개체의 단일 특성, 도메인의 모든 개체 등에 대한 변경 내용을 추적할 수 있습니다. 메커니즘이 애플리케이션의 요구 사항과 일치하는 경우 애플리케이션은 관련이 없는 최소 데이터를 수신하므로 성능이 향상됩니다.

  • 타임라인: 애플리케이션은 변경이 발생할 때마다 알림을 받거나 몇 분 또는 몇 시간 동안 변경 내용의 순 효과에 대해 알림을 받을 수 있습니다.

    몇 가지 변경 내용이 하나로 축소될 수 있으므로 시기 적절한 데이터를 덜 처리하는 것이 더 효율적일 수 있습니다. 예를 들어 특성이 1시간 간격 내에 세 번 변경되는 경우 1시간 동안 누적된 변경 내용에 대해 알림을 받은 애플리케이션은 3개가 아닌 하나의 특성 변경에 대한 알림을 받습니다.

    타임라인을 고려할 때 복제 대기 시간의 영향을 고려합니다. 한 도메인 컨트롤러에서 시작되는 업데이트는 다른 도메인 컨트롤러에 즉시 복제되지 않습니다. 예상된 복제 대기 시간보다 변경 내용 추적 타임라인을 훨씬 더 잘 요구하면 애플리케이션에 실질적인 이점이 없는 경우가 많습니다.

  • 폴링 및 알림: 폴링을 사용하면 애플리케이션이 변경 내용 추적 데이터를 수신하도록 도메인 컨트롤러에 주기적으로 요청합니다. 알림을 통해 도메인 컨트롤러는 변경이 발생할 때만 애플리케이션에 변경 내용을 보냅니다.

    폴링 오버헤드는 분명합니다. 중요한 문제가 발생하지 않은 경우 애플리케이션에서 변경 내용 추적 데이터를 요청할 수 있습니다. 알림의 오버헤드는 더 미묘합니다. 서버는 알림 요청에 대한 데이터를 유지해야 하며 이 데이터를 참조하여 알림을 보낼지 여부를 결정해야 합니다. 이렇게 하면 일반 업데이트 요청에 오버헤드가 추가됩니다.

  • 애플리케이션의 지식 표현: 영구 및 임시: 모든 변경 내용 추적 메커니즘에는 "변경"이라는 개념이 잘 정의되도록 추적된 데이터를 보유하는 서버의 몇 가지 방법이 포함되어야 합니다. 예를 들어 애플리케이션의 지식 상태는 "시간 t 전에 DC d에서 발생한 모든 변경 내용으로 업데이트됨"으로 표시될 수 있습니다. 애플리케이션의 지식 상태를 표현하는 이러한 방법을 기반으로 하는 메커니즘은 애플리케이션이 지정된 시간보다 늦게 발생한 변경 내용을 가져올 수 있는 효율적인 방법을 제공합니다.

    애플리케이션 지식의 식을 유지할 수 있는 경우, 즉 파일 또는 데이터베이스에서와 같이 복구 가능한 상태로 저장되면 애플리케이션 다시 시작은 리소스를 덜 많이 사용합니다. 위의 예제에서는 DC d 및 time t를 기록하여 애플리케이션 지식의 식을 유지할 수 있습니다. 일부 변경 알림 메커니즘에서는 이 데이터를 유지할 수 없습니다. 서버 및 애플리케이션은 애플리케이션이 시작될 때 다른 메커니즘과 동기화해야 합니다. 이는 여러 개체가 관련되어 있고 복잡한 프로그래밍을 포함할 수 있는 경우 리소스를 많이 사용합니다.

다음 기술을 사용하여 Active Directory Domain Services 변경 내용을 추적합니다.

변경 알림 컨트롤은 자주 변경되지 않는 변경에 대해 합리적으로 프롬프트 알림이 필요한 애플리케이션 또는 서비스를 위해 설계되었습니다. 예를 들어 Active Directory 서버에 구성 데이터를 저장하고 변경이 발생할 때 즉시 알림을 받아야 하는 서비스 또는 프로그램이 있습니다. 알림 컨트롤의 제한 사항이 있습니다.

  • 알림의 프롬프트는 복제 대기 시간과 변경이 발생한 위치에 따라 달라집니다. 변경 내용이 모니터링 중인 복제본(replica) 복제될 때 즉시 알림을 받을 수 있지만 다른 복제본(replica) 훨씬 일찍 변경이 시작되었을 수 있습니다.
  • 컨트롤은 단일 개체 또는 컨테이너의 직동 자식을 모니터링하도록 제한됩니다. 여러 컨테이너 또는 관련 없는 개체를 모니터링해야 하는 애플리케이션은 최대 5개의 알림 요청을 등록할 수 있습니다.
  • 너무 많은 클라이언트가 자주 발생하는 변경 내용을 수신 대기하는 경우 서버의 성능에 영향을 줍니다. 일반적으로 애플리케이션은 서버의 성능상의 이유로 이 컨트롤의 사용을 제한해야 합니다. 변경 내용을 즉시 알 필요가 없는 경우 변경 알림을 사용하는 대신 변경 내용을 주기적으로 폴링하는 것이 가장 좋습니다.

DirSync 및 USNChanged 검색 기술은 Active Directory 서버의 데이터와 다른 스토리지의 해당 데이터 간에 일관성을 유지하는 애플리케이션을 위해 설계되었습니다. 이러한 기술은 변경 내용을 주기적으로 폴링하는 애플리케이션에서 사용됩니다. DirSync 기술은 ADSI 또는 LDAP API를 통해 사용할 수 있는 LDAP 서버 컨트롤을 기반으로 합니다. DirSync 컨트롤의 단점은 도메인 관리자와 같은 권한이 높은 계정에서만 사용할 수 있다는 것입니다. 다음은 DirSync 컨트롤의 제한 사항 목록입니다.

  • DirSync 컨트롤은 도메인 관리자와 같은 권한이 높은 계정에서만 사용할 수 있습니다.
  • DirSync 컨트롤은 전체 명명 컨텍스트만 모니터링할 수 있습니다. 명명 컨텍스트에서 특정 하위 트리, 컨테이너 또는 개체만 모니터링하도록 DirSync 검색의 scope 제한할 수 없습니다.

USNChanged 기술에는 DirSync보다 사용하기가 다소 복잡하지만 이러한 제한 사항은 없습니다.