Compartir a través de

Introducción a las técnicas de Change Tracking

  • Artículo

Hay varias maneras en que los mecanismos de seguimiento de cambios pueden diferir:

  • Ámbito de seguimiento de cambios: una aplicación puede realizar un seguimiento de los cambios en un único atributo de un solo objeto, en todos los objetos de un dominio, etc. Si el mecanismo coincide con los requisitos de la aplicación, la aplicación recibe un mínimo de datos irrelevantes y, por tanto, esto mejora el rendimiento.

  • Escalas de tiempo: se notifica a una aplicación cada cambio a medida que ocurre o se puede notificar el efecto neto de los cambios durante un período de minutos o horas.

    El procesamiento de datos menos oportunos puede ser más eficaz, ya que es posible que se contraigan varios cambios en uno. Por ejemplo, si un atributo cambia tres veces en un intervalo de una hora, se notificará a una aplicación de los cambios acumulados durante una hora solo de un cambio de atributo, no tres.

    Al pensar en escalas de tiempo, tenga en cuenta el efecto de la latencia de replicación. Una actualización que se origina en un controlador de dominio no se replica instantáneamente en otro controlador de dominio. Requerir escalas de tiempo de seguimiento de cambios mucho mejor que la latencia de replicación esperada a menudo no proporciona ninguna ventaja real a la aplicación.

  • Sondeo frente a notificación: con el sondeo, una aplicación realiza periódicamente una solicitud a un controlador de dominio para recibir datos de seguimiento de cambios. Con la notificación, el controlador de dominio envía los cambios a la aplicación solo cuando se producen cambios.

    La sobrecarga del sondeo es obvia: la aplicación puede solicitar datos de seguimiento de cambios cuando no se ha producido nada significativo. La sobrecarga de la notificación es más sutil. El servidor debe mantener datos sobre las solicitudes de notificación y debe consultar estos datos para decidir si deben enviar o no una notificación. Esto puede agregar sobrecarga a las solicitudes de actualización normales.

  • Expresar el conocimiento de la aplicación: persistente frente a temporal: cada mecanismo de seguimiento de cambios debe incluir algún método para que el servidor que contiene los datos de los que se realiza el seguimiento comprenda el estado de conocimiento de la aplicación, de modo que la idea de "cambio" esté bien definida. Por ejemplo, el estado de conocimiento de la aplicación podría expresarse como "Actualizado con todos los cambios que se produjeron en DC d antes del tiempo t". Un mecanismo basado en esta forma de expresar el estado de conocimiento de una aplicación proporcionaría una manera eficaz de que la aplicación obtenga los cambios que se han producido más adelante que un tiempo especificado.

    Si se puede conservar la expresión del conocimiento de la aplicación, es decir, almacenarse recuperablemente, como en un archivo o base de datos, el reinicio de la aplicación es menos intensivo de recursos que si no lo puede. En el ejemplo anterior, la expresión del conocimiento de la aplicación se puede conservar mediante la grabación del controlador de dominio d y el tiempo t. Algunos mecanismos de notificación de cambios no permiten que estos datos se conserven. El servidor y la aplicación deben sincronizarse con algún otro mecanismo cuando se inicia la aplicación. Esto consume muchos recursos si hay varios objetos implicados y puede implicar una programación compleja.

Use las técnicas siguientes para realizar un seguimiento de los cambios en Servicios de dominio de Active Directory:

El control de notificación de cambios está diseñado para aplicaciones o servicios que requieren una notificación razonable de cambios poco frecuentes. Un ejemplo es un servicio o programa que almacena datos de configuración en el servidor de Active Directory y se debe notificar rápidamente cuando se produce un cambio. Tenga en cuenta que hay limitaciones del control de notificación.

  • La solicitud de las notificaciones depende de la latencia de replicación y de dónde se produjo el cambio. Es posible que se le notifique rápidamente cuando un cambio se replica en la réplica que está supervisando, pero es posible que el cambio se haya originado mucho antes en alguna otra réplica.
  • El control está restringido a supervisar un solo objeto o a los elementos secundarios inmediatos de un contenedor. Las aplicaciones que deben supervisar varios contenedores o objetos no relacionados pueden registrar hasta cinco solicitudes de notificación.
  • Si hay demasiados clientes escuchando cambios que se producen con frecuencia, afectará al rendimiento del servidor. En general, las aplicaciones deben limitar su uso de este control por motivos de rendimiento en el servidor. Si no necesita conocer los cambios inmediatamente, puede ser mejor sondear periódicamente los cambios en lugar de usar la notificación de cambios.

Las técnicas de búsqueda DirSync y USNChanged están diseñadas para aplicaciones que mantienen la coherencia entre los datos del servidor de Active Directory y los datos correspondientes en algún otro almacenamiento. Estas técnicas las usan las aplicaciones que sondean periódicamente los cambios. La técnica DirSync se basa en un control de servidor LDAP que puede usar a través de ADSI o API LDAP. Las desventajas del control DirSync son que solo se puede usar en una cuenta con privilegios elevados, como un administrador de dominio. A continuación se muestra una lista de las limitaciones del control DirSync:

  • El control DirSync solo puede ser utilizado por una cuenta con privilegios elevados, como un administrador de dominio.
  • El control DirSync solo puede supervisar un contexto de nomenclatura completo. No se puede limitar el ámbito de una búsqueda DirSync para supervisar solo un subárbol, contenedor u objeto específico en un contexto de nomenclatura.

La técnica USNChanged no tiene estas limitaciones, aunque es algo más complicado de usar que DirSync.