Obituarios

Se han producido gran confusión en relación a los obituarios almacenados en el directorio y, en consecuencia, algunas personas han desarrollado prácticas empresariales poco recomendables para trabajar con ellos. A diferencia de otros productos de directorio, eDirectory garantiza la integridad referencial entre objetos. Por ejemplo, si el grupo A tiene al usuario B como componente y éste se suprime, el directorio quita automáticamente la referencia a dicho usuario en el grupo A. Los obituarios existen como atributos operativos que eDirectory coloca en los objetos como método alternativo de asegurar la integridad referencial durante las operaciones de supresión, movimiento, renombrado y restauración, entre otras.

Hay tres clasificaciones generales para los obituarios: Primario, Secundario y Seguimiento. Los obituarios primarios son del tipo Muerto (0001), Restaurado (0000), Movido (0002), Nuevo nombre completo relativo (RDN) (0005) y Nombre completo relativo (RDN) nuevo de árbol (0008). Por lo general, los obituarios secundarios están asociados a uno primario y representan los agentes y particiones de la operación especificada en este último que deben notificarse. Los obituarios secundarios son del tipo Enlace en segundo plano (0006), Usado por (000C) y Mover árbol (000a). Los obituarios de seguimiento son del tipo Inhibir Mover (0003), Nombre completo relativo (RDN) antiguo (0004) y Nombre completo relativo (RDN) antiguo de árbol (0007).

Los obituarios, excepto los de seguimiento, deben pasar por un conjunto de estados de sincronización:

Los estados están registrados en el campo Indicadores del atributo del obituario. Antes de que un obituario pueda pasar al siguiente estado, el actual debe sincronizarse con todas las réplicas del objeto real. Para determinar si todas las réplicas del anillo han presentado un estado de obituario determinado, se calcula un vector a partir del vector transitivo. En eDirectory 8.6 y versiones posteriores, se utiliza un vector de obituario no almacenado. En las versiones anteriores, se utiliza un vector de limpieza. Si la marca horaria de modificación (MTS) del obituario es anterior al vector dañado, el servidor responsable de dicho obituario puede pasarlo al siguiente estado.

En el caso de un obituario secundario del tipo Enlace en segundo plano, el agente que contiene la réplica principal del objeto con el obituario se encargará de pasarlo de un estado a otro. En los obituarios secundarios del tipo Usado por, el agente de réplicas que los crea es el responsable de pasarlos de un estado a otro mientras las réplicas existan. Si ya no existen, el encargado de pasar los obituarios Usado por de un estado a otro será el agente que contiene la réplica principal de la partición. En el caso de un obituario Mover árbol, la réplica principal de la partición raíz es la responsable de hacerlo pasar de un estado a otro.

Los obituarios primarios sólo pueden pasar al estado siguiente una vez que los secundarios han pasado por todos los suyos. Cuando un obituario primario llega a su último estado y éste se sincroniza con todos los servidores del anillo, sólo queda la “cáscara” del objeto, es decir, un objeto sin atributos que posteriormente puede limpiarse del sistema durante el proceso de limpieza. Los obituarios de seguimiento se quitan una vez que el obituario primario está listo para quitarse. En el caso de Inhibit_move, el obituario de seguimiento se quita una vez que el obituario primario ha pasado al estado OBF_NOTIFIED en la réplica principal.

La réplica responsable de procesar obituarios realiza esta tarea durante un proceso en segundo plano (el proceso de obituario), que se programa partición por partición cuando una en concreto finaliza un ciclo de sincronización entrante. Si no existen otras réplicas de la partición, el proceso de réplica saliente se programa durante el intervalo de subejecución. A continuación, el proceso de réplica saliente inicia el proceso de obituario. El proceso de obituario no se puede programar manualmente ni tampoco hay necesidad de hacerlo así. Durante la sincronización se actualizan los vectores transitivos, con lo que también se actualizan los vectores de limpieza y de obituario. A medida que estos vectores se actualizan, también pueden hacerlo los estados de los obituarios. Esta acción, junto con la programación automática que se realiza durante la sincronización entrante, se completa el ciclo de procesamiento de obituarios. Por lo tanto, la base del procesamiento de obituarios es la sincronización de objetos.

En cuanto a la supresión de objetos, una vez que todos los obituarios cuyo obituario primario asociado es del tipo MUERTO han alcanzado el último estado (Limpiable) y dicho estado se ha sincronizado con todas las réplicas, un proceso nuevo se encarga de quitar de la base de datos la “cáscara” de la entrada que aún permanece. Para lograrlo, el proceso de limpieza se ejecuta automáticamente. Es posible programar manualmente este proceso y modificar el intervalo de programación automática desde la página Configuración de agente de iMonitor.

Ejemplos

Contiene los siguientes ejemplos:

Supresión de un objeto

  1. Adición del obituario primario OBT_DEAD.
  2. El atributo Enlace en segundo plano contiene una lista de los servidores interesados en este objeto y a los que se debe notificar los cambios que se produzcan en esta entrada. Por cada DN enumerado en el atributo Enlace en segundo plano y todos los servidores enumerados en el atributo de réplica de la partición de la entrada, eDirectory añade un obituario Enlace en segundo plano. La hora de creación del obituario primario OBT_DEAD se almacena en el obituario secundario.
  3. El atributo Usado por contiene una lista de las particiones interesadas en este objeto y a las que se debe notificar los cambios que se produzcan en esta entrada. Por cada DN enumerado en el atributo Usado por, eDirectory añade un obituario Usado por. La hora de creación del obituario primario OBT_DEAD se almacena en el obituario secundario.
  4. Supresión de todos los atributos excepto los obituarios.
  5. A continuación, el proceso de réplica saliente sincroniza este cambio en todos los servidores del anillo de réplica.
  6. Durante la siguiente sincronización entrante de esta partición, se inicia el proceso de obituario, que realiza las siguientes acciones:

    Si se trata de un obituario primario, no existen obituarios secundarios y la hora de modificación del atributo (MTS) de este es anterior al vector de limpieza, significa que todos los servidores han visto el cambio y se quitará el obituario.

    Si se trata de un obituario Enlace en segundo plano y éste es el servidor principal, este servidor será el responsable de procesarlo.

    Si todavía no se ha llevado a cabo, realice la operación necesaria para este estado. En la mayoría de casos, esta acción se efectúa notificando una referencia externa.

    Si se trata de un obituario Usado por y el servidor es aquel en el que se ha producido la supresión (esto se determina comparando el número de réplicas de la MTS del obituario con nuestro número de réplicas), este servidor es el responsable de procesar dicho obituario.

Movimiento de un objeto

El movimiento es similar a la supresión, si bien algunos aspectos son distintos:

  1. Antes de colocar el obituario primario en el origen del movimiento, se crea una entrada parcial en el contenedor de destino, en la que se ubica un obituario de seguimiento (OBT_INHIBIT_MOVE). Éste sirve para evitar que la entrada se mueva o forme parte de una operación de partición antes de que la entrada completa se transfiera desde el origen.
  2. En la entrada de origen, el obituario primario es OBT_MOVED.
  3. Una vez que este obituario primario (OBT_MOVED) pasa al estado Notificado (lo que significa que todas las réplicas del origen tienen constancia de que la entrada se está moviendo) y todas las referencias externas han recibido la notificación, el obituario de seguimiento (OBT_INHIBIT_MOVE) se quita de la entrada de destino.

Repercusión de los obituarios bloqueados o huérfanos

Los objetos con obituarios se tienen en cuenta en el proceso de obituario, programado para ejecutarse al final de un ciclo de sincronización entrante, y cada vez que un agente saliente se sincroniza.

Prevención

Ejecute el informe del servidor iMonitor de forma periódica. Este informe recorre todo el árbol, se comunica con todos los servidores NCP que encuentra e informa de los errores que detecta. Puede utilizar este informe para diagnosticar los problemas de sincronización horaria y de proceso limber, o bien para descubrir si el servidor actual puede comunicarse con el resto de servidores desde su perspectiva. Si se selecciona en la página de configuración, este servidor también puede generar información sobre la actividad del agente NDS en cada servidor del árbol. Para obtener más información acerca de la ejecución del informe del servidor, consulte Configuración del informe.

Si utiliza iMonitor 2.0 o una versión posterior, asegúrese de que están habilitadas las siguientes opciones del informe: Errores y Subinforme de actividad. Se verificarán los siguientes elementos. Debe examinar el informe y asegurarse de que no haya errores.

Si utiliza iMonitor 1.5, seleccione la opción del informe Errores. Se verificarán los siguientes elementos. Debe examinar el informe y asegurarse de que no haya errores.

Utilice el informe del listado de obituarios de iMonitor o el informe de las estadísticas de objetos de iMonitor para encontrar los obituarios del sistema. Si encuentra alguno que, en su opinión, no está siendo procesado, consulte Sugerencias para la resolución de problemas.

Sugerencias para la resolución de problemas

Existen dos razones generales por los que los obituarios no se procesan: que sean huérfanos (es decir, que existan en algunos servidores pero no en todos) o que estén bloqueados (es decir, que existan en todos los servidores pero que no pasen de un estado a otro por algún motivo).

Utilice los siguientes elementos para resolver los problemas de los obituarios huérfanos o bloqueados:

Solución

Utilice la solución adecuada de las propuestas en Sugerencias para la resolución de problemas.

Antes de recurrir a alguna de estas soluciones, asegúrese de que todos los datos están a salvo. Es posible que deba realizar copias de seguridad de los archivos de la base de datos, la configuración del servidor y los Trustees del directorio. Para aumentar la probabilidad de éxito y minimizar problemas futuros, actualice a los últimos paquetes de soporte de eDirectory.

Resolución de obituarios huérfanos

Resolución de obituarios huérfanos en referencias externas

Resolución de obituarios OBT_INHIBIT_MOVE

Prácticas anteriores

Anteriormente, se utilizaban diversas estrategias para limpiar obituarios bloqueados. Algunas de éstas obligaban a realizar costosas operaciones de partición o a utilizar funciones no documentadas que podían provocar problemas a posteriori. Muchas de las estrategias que se enumeran a continuación no deben utilizarse.

La primera consistía en conmutar la réplica principal. Esto funcionaba en algunas ocasiones porque la réplica principal es el agente responsable de pasar los obituarios Enlace en segundo plano de un estado a otro. En el caso de que una réplica fuera incoherente y la réplica principal no retuviera el objeto suprimido, el hecho de convertir en réplica principal al agente que retenía la entrada suprimida con los obituarios correspondientes otorgaba al nuevo agente permiso para modificar el estado de los obituarios y, finalmente, limpiarlos. Utilizar el envío de una única entrada es un método más limpio y menos peligroso de resolver los problemas con los obituarios bloqueados a causa de la incoherencia de las réplicas.

La segunda estrategia es ejecutar DSRepair con determinadas conmutaciones para suprimir todos los obituarios. (Existe una aplicación de otro fabricante que limpia los obituarios bloqueados lanzando DSRepair.) El equipo de desarrollo de eDirectory no recomienda esta estrategia. El uso de estas conmutaciones suprimirá todos los obituarios del agente, lo que significa que es posible que se supriman también obituarios que no están bloqueados. Esto crearía más incoherencias en las réplicas y más obituarios bloqueados. Dado que no se trata de una operación distribuida, debe ejecutar DSRepair en todos los servidores donde haya obituarios bloqueados, lo que aumenta las posibilidades de que uno de éstos presente obituarios de otra partición, que se suprimirían prematuramente. La supresión prematura de obituarios puede provocar la aparición de obituarios huérfanos adicionales, lo que a su vez causaría problemas que no se detectarían hasta años después, al modificar o añadir tipos de réplicas o al realizar otras operaciones de partición.

La tercera estrategia consiste en convertir objetos en autorizados utilizando DSBrowse en el modo avanzado y otorgando una marca horaria a la entrada, o bien ejecutando DSRepair con la conmutación –0T. De esta manera, se obliga a la entrada a convertirse en autorizada y a sincronizarse con el resto de réplicas. La asignación de marcas horarias y la conversión de objetos en autorizados son operaciones delicadas porque pueden provocar la pérdida de datos modificados en otros servidores. El equipo de desarrollo de eDirectory recomienda utilizar este método para limpiar obituarios en contadas ocasiones.

Para obtener información acerca de las marcas comerciales de NetIQ, consulte http://www.netiq.com/company/legal/.