Solución de problemas relacionados con la replicación de carpetas públicas – Parte 2: Solución de problemas de replicación de datos existentes
Artículo original publicado el lunes, 28 de noviembre de 2011
Publicado originalmente en el blog de Estados Unidos: 20 de enero de 2006
Esta es la segunda entrada de blog sobre cómo solucionar problemas de replicación de carpetas públicas. En la primera entrada discutimos la solución de problemas de replicación de nuevos cambios. En esta segunda entrada nos encargaremos de la solución de problemas de replicación de datos existentes y en la última entrada de esta serie abordaremos la solución de problemas de eliminación de réplicas y los problemas comunes. Para obtener una visión general, lea todo el material de referencia.
Solución de problemas de replicación de datos existentes
Cuando los nuevos cambios se replican, pero el contenido sin modificar no lo hace, entonces existe un problema de reposición. La situación más normal en la que se produce la reposición de jerarquía es cuando se crea un almacén público nuevo. El escenario de reposición de contenido más habitual se da cuando se agrega un almacén público a la lista de réplica de una carpeta.
Puede que si tiene un problema de reposición como este, ya se le haya ocurrido un sencillo remedio: hacer un cambio en todos los elementos. Al hacerlo, se evita el proceso de reposición interrumpido y se replica todo como nuevos cambios. A pesar de que he indicado las dos herramientas que se usan normalmente con este fin (PFDAVAdmin y ModifyItems), en general es mejor resolver el proceso de reposición y solucionar la causa raíz. Si se cambia todo para hacerlo replicar, se puede acabar con el mismo problema de reposición cuando las réplicas vuelvan a desincronizarse en el futuro. Dicho esto, pasemos a la reposición. Para comprender el proceso de reposición, primero es necesario entender cómo se realiza un seguimiento de los cambios.
A todas las carpetas y los mensajes del almacén se les asigna un CN (Change Number, Número de Cambio) durante su creación y siempre que se modifican. Cuando se produce la replicación, los CN de cada objeto se usan para determinar si ese objeto necesita ser replicado. Un grupo de CN se denomina CNSet. El CNSet de una carpeta que se encuentre en un servidor determinado se denomina información de estado. Esta información de estado se incluye en todos los mensajes de replicación. Todos los mensajes de tipo 0x2 contienen el estado de jerarquía del servidor remitente. Asimismo, todos los mensajes de tipo 0x4 contienen la información de estado de esa carpeta en concreto del servidor remitente. El resto de tipos de mensajes de replicación también contienen información de estado de sus respectivas carpetas.
Cuando se monta por primera vez un almacén público nuevo, este envía una solicitud de estado (de tipo 0x20) de la jerarquía a todos los almacenes públicos existentes. Del mismo modo, cuando se agrega un almacén nuevo a la lista de réplica de una carpeta, ese almacén enviará un 0x20 al resto de réplicas de esa carpeta. Al igual que los mensajes de replicación, una solicitud de estado contiene un CNSet de todos los CN de la carpeta en cuestión (o la jerarquía) que tiene el almacén de origen, y solicita a los otros almacenes que respondan si tienen CN que no tiene el originador. Hay que tener presente que antes de Exchange 2003 Sp2, no todas las réplicas recibían la solicitud de estado, por lo que algunos almacenes ignoran la solicitud aunque tengan cambios que el almacén de origen no tenga. Siempre que incluya cambios que el servidor de origen no contenga, un servidor 2003 Sp2 preguntará a todas las réplicas y responderá incluso si el servidor de origen no lo solicitó pidió de forma específica. Esto puede mejorar en gran medida las decisiones tomadas durante el proceso de reposición. Lo especial de una solicitud de estado es que no contiene datos que replicar; solo tiene una lista de números de cambio. El resto de almacenes responden con mensajes de estado (0x10), que enumeran sus propios CNSets de esa misma carpeta (o la jerarquía). Cuando el servidor de origen recibe los mensajes 0x10, compara los CNSet que contienen con su propio CNSet. Si el 0x10 incluye cambios que el almacén todavía no contiene, el proceso de reposición se inicia.
El primer paso en el proceso de reposición es agregar entradas a la matriz de reposición de la carpeta en cuestión. Estas entradas tienen un CNSet que describe los cambios que faltan, así como un valor de tiempo de espera que indica en qué momento el almacén solicita los datos que faltan. El tiempo de espera de reposición varía en función de la situación. Si se trata de un almacén público que se pone en línea o de una réplica nueva que se agregue, el valor inicial de tiempo de espera es de 15 minutos.
Las entradas de reposición también se pueden agregar a la matriz de reposición durante el proceso normal de funcionamiento. Imaginemos una situación en la que un almacén público ha difundido dos cambios en dos mensajes 0x2 independientes. Digamos que el administrador elimina de la cola el primero de los dos mensajes 0x2, pero el segundo mensaje pasa. Cuando el resto de servidores reciben este 0x2, verán que el CNSet incluido en la información de estado contiene unos CN que no han recibido. Por consiguiente, crearán entradas de reposición para esos datos. Las entradas de reposición para datos que faltan y que se descubrieron durante el curso normal de la replicación se iniciarán con un tiempo de espera de 6 horas si los datos están disponibles en el mismo grupo de enrutamiento (RG, Routing Group), o 12 horas si solo están disponibles en un RG diferente. Cada vez que se emita una solicitud de reposición, el siguiente tiempo de espera será 12 y después 24 horas para solicitudes intra-RG, o 24 y 48 horas para solicitudes inter-RG.
Cada cinco minutos el almacén comprobará si alguna de las entradas de reposición ha alcanzado su tiempo de espera. Si es así, se emitirá una solicitud de reposición (de tipo 0x8) para los CN que faltan y el tiempo de espera se establecerá en el siguiente intervalo. Una solicitud de reposición no es una difusión, sino que está dirigida a un único servidor (uno de los servidores que previamente indicó que tenía unos CN que faltaban en la información de estado enviada al servidor solicitante). Cuando ese servidor recibe el 0x8 entrante, inmediatamente procesa la solicitud y responde con una o más respuestas de reposición (0x80000002 para jerarquía o 0x80000004 para contenido), que contienen los datos reales de los números de cambio solicitados. Al igual que las solicitudes de reposición, las respuestas de reposición no son difusiones, sino que se únicamente se envían al servidor solicitante.
Si el servidor solicitante procesa correctamente la respuesta de reposición entrante, los CN que contenía se borran de la matriz de reposición de ese almacén. En realidad, cualquier mensaje entrante que contenga CN pendientes en la matriz de reposición provocará que esos CN se borren de la matriz.
Solución de problemas
Como puede comprobar, hay muchas más peguntas que contestar a la hora solucionar problemas del proceso de reposición.
1. ¿El almacén sabe que son datos que faltan?
Primero se debe determinar si el servidor se percata de que otros almacenes tienen cambios que necesita solicitar. Por desgracia, no hay ninguna herramienta o utilidad compatible que permita ver la matriz de reposición para comprobar su contenido. No obstante, hay otros métodos indirectos de averiguarlo.
Uno de los métodos es esperar. Si el servidor saben que son datos que faltan, los solicitará al menos una vez cada 24 o 48 horas. Esto significa que se puede elevar el registro y esperar a ver si sale un mensaje 0x8. Si no se ve un 0x8 para la carpeta en cuestión, pero se ven otros 0x8 para otras carpetas, puede que se haya alcanzado el límite de reposición pendiente, algo de lo que hablaremos en breve.
Otra opción es asegurarse de que el servidor recibe la información de estado más reciente. Recuerde que el servidor solo envía una solicitud de estado una vez que agregue la nueva réplica. Después de eso, la única información de estado que reciba será a través del curso normal de replicación. Por lo tanto, si su intento inicial por obtener el estado se perdió debido a que el 0x20 o el 0x10 de la respuesta se perdió o se eliminó, es posible que se quede estancado y no se percate de que falta algo. Existen varias maneras de asegurarnos de que el servidor haya recibido la información de estado de una carpeta.
- Vaya a un servidor que tenga todos los datos y haga un cambio en la carpeta agregando, eliminando o modificando un mensaje. En el caso de jerarquía, cree, elimine o modifique las propiedades de una carpeta. El 0x4 o 0x2 resultante incluirá información de estado de esa carpeta o la jerarquía, respectivamente. Cuando el servidor en el que faltan los datos procese correctamente el mensaje de replicación entrante, usted sabrá que ha agregado todas las entradas apropiadas a la matriz de reposición.
- Use la opción Sincronizar contenido del Administrador del sistema de Exchange 2003, que está oculta pero que es muy útil. Para encontrarla, vaya al árbol de carpetas públicas y localice la carpeta en cuestión. Resalte la carpeta en el panel de la izquierda. En el panel de la derecha, haga clic en la ficha Estado. Haga clic con el botón secundario en el servidor que contiene todos los datos y elija Sincronizar contenido. Esta acción hace dos cosas: provoca que el servidor emita una solicitud de estado 0x20 para la carpeta y hace que se agote inmediatamente el tiempo de espera de todas las entradas de reposición. Observe que he indicado que se debe sincronizar el contenido desde el servidor que ya contiene los datos. Se preguntará por qué debe hacerlo, cuando es el otro servidor el que tiene las entradas de reposición que necesitan agotar el tiempo de espera. Recuerde que en este punto solo estamos intentando asegurarnos de que el servidor en el que faltan los datos SEPA que tiene algo que reponer. Con ese fin, podemos usar la opción Sincronizar contenido desde el servidor que tiene los datos para enviar un 0x20 al servidor que no los tiene. En este caso no nos interesa ver una respuesta 0x10 de estado al 0x20. Tan solo queremos que el almacén que carece de los datos reciba un mensaje de replicación para la carpeta desde un almacén con contenido, para que así pueda agregar las entradas correspondientes a la matriz de reposición. El 0x20 del servidor con los datos sirve para este propósito. Tenga en cuenta que ahora en Exchange 2003 Sp2, la opción Sincronizar contenido está disponible para la jerarquía haciendo clic con el botón secundario en el nodo de carpetas públicas.
- Use el valor de registro de Indicadores de replicación (Replication Flags) (KB813629). Si coloca este valor, junto con el valor Habilitar replicación de mensajes en el inicio (Enable Replication Messages At Startup) de KB321082, hará que el almacén envíe una solicitud de estado 0x20 para todas las carpetas en el inicio. De nuevo, querrá usar esto en el servidor que contiene los datos; el motivo de este paso es obtener el servidor que tiene el contenido para enviar su información de estado al servidor que carece del contenido.
- Use el Administrador del sistema de Exchange 2003 para enviar una respuesta de reposición. En 2003 Sp1, puede usar la opción Enviar jerarquía para enviar una respuesta de reposición de jerarquía y la opción Enviar contenidos para enviar una respuesta de reposición de contenido de carpeta. En 2003 Sp2, ambas opciones se convirtieron en Reenviar cambios. Esta opción envía una respuesta de reposición para el rango de datos que se especifique, pero probablemente no debería especificar todo el rango ya que eso podría satisfacer todas las entradas de reposición pendientes con lo que acabaría evitando el problema original. En vez de eso, especifique un rango de solo uno o dos días. Esto hace que un 0x80000002 o un 0x80000004 vayan al servidor de destino, lo que sirve de nuevo para el propósito de proporcionarle información de estado para el almacén que contiene los datos.
Después de haber usado una de estas opciones para forzar la información de estado y de haber comprobado (mediante el registro de la aplicación) que el almacén que carece de los datos recibió el mensaje entrante, verá si el almacén sabe que le faltan datos.
2. ¿El almacén solicita los datos que le faltan?
Una vez que se haya asegurado de que el almacén sabe que necesita reponer algunos datos, ¿emite el almacén una solicitud de reposición? Recuerde que después de que el almacén haya intentado reponer los datos un par de veces, es posible que se deba esperar 24 o 48 horas hasta la próxima solicitud de reposición, ya que ese será el intervalo de tiempo de espera más largo para reposiciones “intrasitios” e “intersitios” respectivamente. Hay una manera de acelerar este proceso y es usando de nuevo la opción Sincronizar contenido, pero esta vez desde el servidor en el que faltan los datos. De este modo se agotará inmediatamente el tiempo de espera de las entradas de reposición para esa carpeta. No obstante, puede que el almacén no emita una solicitud de reposición para la carpeta en cuestión. En ese caso, observe el registro de aplicaciones durante las próximas 24-48 horas. Si el almacén está enviando solicitudes de reposición para otras carpetas, pero no para la carpeta que nos atañe, es posible que se haya alcanzado el límite de reposiciones pendientes.
Si se han agregado réplicas de un gran número de carpetas a un almacén nuevo y la replicación parece funcionar correctamente pero luego se para en seco durante los próximos dos días, es posible que se haya alcanzado el límite de reposiciones pendientes. Este límite es un mecanismo cuya función es regular la replicación. De forma predeterminada, el almacén solo permite 50 solicitudes de reposición a la vez. Cuando se haya alcanzado ese número, volverá a realizar esas 50 solicitudes una y otra vez hasta que queden satisfechas. Una vez que se haya satisfecho cualquiera de las entradas pendientes, se abrirá un hueco en el OBL (Oustanding Backfill Limit, Límite de Reposición Pendiente) para que se solicite un nuevo conjunto de datos. Esto significa que si, por cualquier motivo, las 50 solicitudes están experimentando problemas para ser satisfechas, la replicación no puede continuar.
Si observa este comportamiento, consulte el registro de aplicaciones para ver qué almacén está realizando la solicitud. Verá mensajes 0x8 periódicos para las 50 solicitudes de reposición pendientes actualmente y comprobará que no se recibe ninguna respuesta de reposición, razón por la cual todavía están pendientes. En ese punto debería intentar solucionar una de las carpetas que el almacén está intentando reponer, ya que si se resuelve ese problema el almacén podrá continuar con las otras carpetas.
Existe otra opción que es aumentar el OBL. Para ello, cree un valor de registro denominado Límite de Reposición Pendiente de Replicación (Replication Oustanding Backfill Limit) bajo la clave de registro de ese almacén. El valor máximo es 5000 decimal. No obstante, una vez hecho esto las compuertas de la replicación se abrirán y será difícil determinar qué carpetas provocaron el problema. Será necesario posponer la solución del problema hasta que la situación vuelva a la normalidad. Normalmente recomiendo dejar el límite en 50 y solucionar el problema en vez de aumentar el límite.
Si parece que problema no está en el OBL y continúan sin aparecer mensajes 0x8 salientes para la carpeta en cuestión, consulte los “problemas comunes” en la última entrada de esta serie.
3. ¿El otro almacén responde a la solicitud?
Una vez que tenga una solicitud de reposición en la que centrarse, será necesario determinar si el objetivo de la reposición llegó a recibir la solicitud. Compruebe el registro de aplicaciones en ese servidor y busque los 0x8 entrantes. También puede examinar el registro de aplicaciones para buscar el Id. de mensaje mencionado en el evento de salida del lado remitente. Si no indicios del mismo en el registro de aplicaciones, use el seguimiento de mensajes para ver hasta dónde llegó. Si recibió el 0x8, debería responder casi de inmediato con uno o más mensajes 0x80000002 o 0x80000004 (a menudo verá muchas respuestas de reposición a una única solicitud de reposición, ya que los cambios no se envían todos en un solo mensaje). Por supuesto, el tiempo necesario para generar los mensajes de repuesta de reposición variará en función de los datos de la carpeta y del límite de tamaño del mensaje de replicación. Por ejemplo, si se establece el tamaño máximo de mensaje de replicación en 1 GB, el servidor de respuesta intentaría empaquetar toda la jerarquía en una única respuesta de reposición, pero el paquete podría tardar una hora o más en ser creado.
4. ¿El servidor que emite la solicitud obtiene respuesta?
Ahora es el momento de comprobar el registro de aplicaciones en el servidor solicitante para ver si recibió la respuesta de reposición. Si no es así, realice un seguimiento del mensaje para observar hasta dónde llegó. Si recibió la respuesta de reposición y la anotó en el registro de aplicaciones, entonces la solicitud de reposición tuvo que ser satisfecha y debería ser capaz de continuar.
Como se mencionó anteriormente, si ve que el seguimiento de mensajes muestra que uno de estos mensajes se entregó en el almacén pero aun así el registro de aplicaciones no muestra el mensaje de replicación entrante, eche un vistazo a los “problemas comunes” en la última entrada de esta serie.
En la próxima entrada de blog: Solución de problemas de eliminación de réplicas y problemas comunes.
Esta entrada de blog es una traducción. Puede consultar el artículo original en Public Folder Replication Troubleshooting – Part 2: Troubleshooting the Replication of Existing Data