Se han producido algunos malentendidos 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™ de Novell® garantiza la integridad referencial entre objetos. Por ejemplo, si el grupo A tiene por miembro al usuario B 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 realmacenamiento, entre otras.
Los obituarios se clasifican en tres grandes categorías: primarios, secundarios y de 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).
Excepto los de seguimiento, los obituarios 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 retiene 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 retiene 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 siguiente estado 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 puede programarse manualmente ni tampoco hay necesidad de hacerlo así. Durante la sincronización se actualizan los vectores transitivos, con lo que los vectores de limpieza y de obituario avanzan. A medida que avanzan estos vectores, 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.Esta sección contiene los ejemplos siguientes:
Si se trata de un obituario primario, no existen obituarios secundarios y la hora de modificación del atributo (MTS) de éste 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 el servidor es la réplica principal, este último será el responsable de procesarlo.
Si todavía no se ha llevado a cabo, realice la operación necesaria para este estado. La mayoría de las veces, esta acción se efectúa notificando una referencia externa.
Si se trata de un obituario Usado por y el servidor es aquél 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 último es el responsable de procesar dicho obituario.
El movimiento es similar a la supresión, si bien algunos aspectos son distintos:
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, cada vez que un agente saliente se sincroniza.
Por lo general, debe ejecutar el Informe del servidor iMonitor. 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 todos los demás 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 de 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 hay 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 hay 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.
Existen dos razones generales para que los obituarios no se procesen: 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:
-625, -622, -634 y -635. Para obtener más información, consulte el Informe del servidor.
-601 y -603, que indican servidores que se han quitado de manera incorrecta o bien que es posible que el objeto Servidor presente una clase básica Desconocido.
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
- Método preferido: Si en alguno de los servidores del anillo de réplica se dispone de eDirectory 8.6 o una versión posterior, busque el objeto en iMonitor y seleccione el envío de una única entrada. De esta manera, se realizará un envío no autorizado a todas las demás réplicas.
- Método mucho menos recomendado: Si todos los servidores del anillo de réplica que disponen de una copia del obituario huérfano son posteriores a eDirectory 8.6, cargue DSBrowse con la opción -a, busque el objeto y seleccione <visit> para colocar una marca horaria en la entrada. De esta manera, el objeto que existe en este servidor se convertirá en la copia autorizada. Novell desaconseja convertir los objetos en autorizados como práctica habitual.
Resolución de obituarios huérfanos en referencias externas
- Método menos recomendado: Ejecute la versión de DSRepair <visit> con la opción <visit> seleccionada.
- Método menos recomendado: Mueva una réplica real al servidor, espere a que se active y, a continuación, espere a que el obituario se procese. Si éste no se procesa, utilice la información recopilada en Sugerencias para la resolución de problemas para resolver el problema ahora que el objeto se encuentra en una réplica real. Una vez que el obituario ha sido procesado, puede quitar la réplica si lo desea.
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 ciertas 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 todas las otras 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.
Un símbolo de marca comercial (®, TM, etc.) indica una marca comercial de Novell. Un asterisco (*) indica una marca comercial de otro fabricante. Para obtener información sobre marcas comerciales, consulte Información legal.