Administración de la replicación continua agrupada
Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Última modificación del tema: 2009-06-10
Además de las tareas de administración diaria de una organización de Exchange, existen tareas específicas de administración de un entorno de replicación continua en clúster (CCR). En general, las tareas administrativas para CCR se agrupan en dos categorías:
Tareas relacionadas con un servidor de buzones de correo en clúster
Tareas relacionadas con los grupos de almacenamiento y las bases de datos en un servidor de buzones de correo en clúster
Tareas relacionadas con un servidor de buzones de correo en clúster
Entre las tareas administrativas asociadas a un servidor de buzones de correo en clúster en un entorno CCR, se incluyen las siguientes:
Administrar volúmenes de disco
Ver opciones de configuración
Supervisar la actividad de replicación
Ver y recopilar datos de rendimiento
Administrar servidores de buzones de correo en clúster, que incluye la puesta en conexión y fuera de conexión y el traslado de servidores de buzones de correo en clúster entre nodos
Administrar la replicación y respuesta de archivos de registro
Administrar volúmenes de disco
Cuando se administra un entorno de replicación continua en clúster, es posible que sea necesario administrar volúmenes que estén relacionados con el clúster de replicación continua en clúster. Por ejemplo, es probable que sea necesario desconectar el volumen del sistema temporalmente por motivos de mantenimiento, entre otros. Si esta acción debe realizarse en el grupo de almacenamiento o en la base de datos activos, deben desmontarse las bases de datos del grupo de almacenamiento. Si se va a realizar esta operación en la copia pasiva del grupo de almacenamiento o de la base de datos, todas las E/S de replicación al volumen se deberán detener mediante la interrupción de la replicación.
Para obtener más información acerca de la administración de volúmenes de disco, consulte el artículo de la Knowledge Base Cómo preparar las Actividades de administración de volumen de discos para una copia de replicación (página en inglés).
Ver opciones de configuración
Después de habilitar CCR para un servidor, puede usar la Consola de administración de Exchange y el Shell de administración de Exchange para ver la configuración de las bases de datos y los grupos de almacenamiento del servidor.
Entre la información de configuración, se incluyen las ubicaciones del grupo de almacenamiento y los archivos de la base de datos. Además, puede revisar la configuración relacionada con el servidor de buzones de correo en clúster mediante el Shell de administración de Exchange.
Para conocer los pasos detallados para ver la información de configuración del control de conmutación por errores de CCR, consulte el artículo de la Knowledge Base Cómo ver la configuración de control de la conmutación por error (página en inglés).
Supervisar la actividad de replicación
La copia pasiva de una base de datos sólo es útil si está actualizada. Aunque CCR no requiere ninguna supervisión especial, se recomienda realizar la supervisión periódica de cada grupo de almacenamiento para comprobar que los archivos de registro se replican correctamente. El Módulo de administración de Microsoft Exchange Server 2007 para Operations Manager 2005 Microsoft incluye alertas para varios problemas críticos relacionados con entornos CCR:
El servicio de replicación de Microsoft Exchange no se está ejecutando en el nodo pasivo. El evento que genera esta alerta no aparece varias veces una vez detenido el servicio, de manera que cualquier alerta asociada a él se perdería si se eliminara.
La copia pasiva tiene el estado Error.
La copia pasiva tiene el estado Correcto, pero está retrasada de manera significativa en la copia de registros o reproducción.
También se recomienda agregar una regla de eventos personalizada a Operations Manager Microsoft que se desencadene al no detectar la ejecución de un nodo pasivo y que forma parte del clúster que contiene un nodo activo. Cuando ocurre esta condición, el servicio de Cluster Server registra un evento en el registro de eventos del sistema. Se recomienda usar los criterios siguientes para la regla de eventos, que formará parte del evento registrado por el servicio de Cluster Server:
Origen del evento: ClusSvc
Id. del evento: 1135
Para obtener más información acerca de la creación de reglas de eventos en Microsoft Operations Manager, consulte Monitoring Security Events with MOM.
Deberá investigar y solucionar lo más rápidamente posible cualquier alerta anterior generada por el Paquete de administración de Exchange 2007 o una regla de eventos personalizada.
Una alternativa al uso del Paquete de administración de Exchange 2007 para Microsoft Operations Manager 2005 consiste en ejecutar de manera regular un script que ejecute a su vez el cmdlet Get-StorageGroupCopyStatus en el Shell de administración de Exchange. El cmdlet Get-StorageGroupCopyStatus asigna longitudes de cola que incorporan el número de registros generados por el nodo activo. Por motivos de rendimiento, los contadores de rendimiento de longitud de cola sólo facilitan información conocida por el Servicio de replicación de Microsoft Exchange. En condiciones poco habituales, esto puede no ser coherente con el estado del nodo activo. Para obtener más información acerca del cmdlet Get-StorageGroupCopyStatus, consulte "Visualizar el estado de las copias del grupo de almacenamiento" más adelante en este tema.
Ver y recopilar datos de rendimiento
Puede determinar el progreso de la replicación mediante los contadores de rendimiento. Para obtener más información acerca del uso de contadores de rendimiento para CCR, consulte Cómo ver contadores de rendimiento para replicación continua de clústeres.
Administración de servidores de buzones de correo en clúster
Las tres tareas administrativas principales para la administración de un servidor de buzones de correo en clúster son la puesta en conexión y fuera de conexión del servidor y el traslado del servidor entre los nodos del clúster. También puede implicar el cierre o reinicio de uno de los nodos del clúster como parte de la administración de actualizaciones u otras operaciones de mantenimiento.
Inicio y detención de un servidor de buzones de correo en clúster
La herramienta de administración del clúster de conmutación por error (Windows Server 2008), el administrador de clústeres (Windows Server 2003) y la herramienta de línea de comandos Cluster.exe (en ambos sistemas operativos) tienen la capacidad de poner en conexión recursos, así como de dejarlos sin conexión. La desconexión de un servidor de buzones de correo en clúster se denomina detención y la conexión de un servidor de buzones de correo en clúster de denomina inicio. El modo recomendado de iniciar un servidor de buzones de correo en clúster es usar el cmdlet Start-ClusteredMailboxServer. El modo recomendado de detener un servidor de buzones de correo en clúster es usar el cmdlet Stop-ClusteredMailboxServer. En Exchange 2007 Service Pack 1 (SP1) se puede usar también el asistente para administrar el servidor de buzones de correo en clúster de la Consola de administración de Exchange para iniciar o detener un servidor de buzones de correo en clúster.
Para conocer los pasos detallados para poner un servidor de buzones de correo en clúster en conexión, consulte Cómo iniciar un servidor de buzón de correo en clúster. Para conocer los pasos detallados para desconectar un servidor de buzones de correo en clúster, consulte Cómo detener un servidor de buzón en clústeres.
Traslado de un servidor de buzones de correo en clúster entre nodos
El traslado manual de un servidor de buzones de correo en clúster entre los nodos se denomina relevo o corte programado. Para mover un servidor de buzones de correo en clúster utilice el cmdlet Move-ClusteredMailboxServer. En el SP1 de Exchange 2007, es posible usar el asistente para administrar el servidor de buzones de correo en clúster en la Consola de administración de Exchange para realizar la entrega de un servidor de buzones en clúster. Aunque la herramienta de administración del clúster de conmutación por error (Windows Server 2008), el administrador de clústeres (Windows Server 2003) y la herramienta de la línea de comandos Cluster.exe (en ambos sistemas operativos) se pueden usar para mover un servidor de buzones de correo en clúster entre nodos, se recomienda utilizar una de las herramientas de administración de Exchange destinadas a tal fin, ya que permiten especificar una razón para la entrega. Además:
El uso de las herramientas de clúster omite la comprobación del estado de la copia pasiva que realizan las herramientas de administración de Exchange. Por eso, su utilización puede provocar una interrupción extendida mientras el nodo realiza las operaciones para que la base de datos se pueda montar.
El uso de las herramientas de clúster también puede dejar una base de datos indefinidamente sin conexión debido a una replicación incorrecta. Asimismo, las herramientas de clúster, a diferencia de las herramientas de administración de Exchange, no pueden determinar el estado de la replicación antes de mover el grupo de recursos.
Nota
El movimiento de un buzón en clúster entre nodos provocará una breve interrupción del servicio. Además, se detendrá cualquier copia de seguridad de cualquier grupo de almacenamiento en el servidor de buzones de correo en clúster.
Si la replicación es incorrecta o si estas comprobaciones determinan que el nodo pasivo no es un estado aceptable para un relevo, las herramientas de administración de Exchange no realizarán dicho relevo. Si sucede esto pero tiene que mover el CMS al nodo pasivo, puede usar las herramientas de administración del clúster para hacerlo.
Al mover un servidor de buzón en clúster de un clúster de conmutación por error en el que exista latencia de red entre los nodos, se recomienda realizar la operación de movimiento desde el nodo pasivo.
Para conocer los pasos detallados para trasladar un servidor de buzones de correo en clúster entre nodos, consulte Cómo mover un servidor de buzones de correo en clúster en un entorno CCR.
Realización del mantenimiento del clúster
El mantenimiento debe realizarse siempre en el nodo pasivo del clúster. Las actualizaciones, revisiones y otras aplicaciones generalmente no deben instalarse en el nodo activo (un nodo que actualmente posee un servidor de buzones de correo en clúster). Para consultar los pasos detallados sobre la instalación de paquetes acumulativos de actualizaciones de Exchange en un entorno de replicación continua en clúster, consulte Aplicación de paquetes acumulativos de actualizaciones de Exchange 2007 a servidores de buzones de correo en clúster.
Si el mantenimiento debe realizarse en el nodo activo, entonces el servidor de buzones de correo en clúster debe trasladarse primero a un nodo pasivo utilizando el cmdlet Move-ClusteredMailboxServer. Tras el traslado al servidor de buzones de correo en clúster, el nodo anteriormente activo se convierte en el nodo pasivo y el nodo pasivo anterior es ahora el nodo activo. Entonces se puede realizar el mantenimiento y, además, un relevo que traslada el servidor de buzones de correo en clúster en la dirección opuesta.
Los entornos CCR permiten programar una interrupción de sistema de un nodo específico sin necesidad de una interrupción del servidor de buzones de correo en clúster. En un entorno de CCR, los nodos sólo se pueden desconectar de uno en uno. Si se desconecta más de uno, se producirá una interrupción en el servicio.
Un corte programado se inicia mediante el cmdlet Move-ClusteredMailboxServer del Shell de administración de Exchange. En el tema Cómo mover un servidor de buzones de correo en clúster en un entorno CCR se facilita un procedimiento para realizar un corte programado.
Antes de cerrar o reiniciar cualquier nodo en un entorno CCR, se recomienda comprobar el nodo que actualmente hospeda el servidor de buzones de correo en clúster. Esta información se puede conseguir mediante el cmdlet Get-ClusteredMailboxServerStatus.
Realización del mantenimiento del clúster
El mantenimiento debe realizarse siempre en el nodo pasivo del clúster. Las actualizaciones y otras aplicaciones generalmente no se deben instalar en el nodo activo (el nodo actualmente propietario del servidor de buzones de correo en clúster). Para consultar los pasos detallados sobre la instalación de paquetes acumulativos de actualizaciones de Exchange en un entorno de replicación continua en clúster, consulte Aplicación de paquetes acumulativos de actualizaciones de Exchange 2007 a servidores de buzones de correo en clúster.
Si el mantenimiento se debe realizar en el nodo activo, el servidor de buzones de correo en clúster primero se debe trasladar al nodo pasivo utilizando el cmdlet Move-ClusteredMailboxServer. Tras el traslado al servidor de buzones de correo en clúster, el nodo anteriormente activo se convierte en el nodo pasivo y el nodo pasivo anterior es ahora el nodo activo. Entonces se puede realizar el mantenimiento y, además, un relevo que traslada el servidor de buzones de correo en clúster en la dirección opuesta.
Cierre de nodos en el clúster
Si todos los nodos del clúster deben cerrarse, incluido el nodo activo, primero debe detener el servidor de buzones de correo en clúster. El proceso de cierre de Windows no tiene en cuenta Exchange. Por lo tanto, recomendamos que sólo cierre nodos pasivos. Si un nodo activo se debe cerrar o reiniciar, recomendamos que mueva el servidor de buzones de correo en clúster a otro nodo disponible. Para obtener información detallada sobre cómo pasar un servidor de buzones de correo en clúster a otro nodo, consulte Cómo mover un servidor de buzones de correo en clúster en un entorno CCR.
Si el servidor de buzones de correo en clúster no se puede trasladar al nodo pasivo (quizás porque ya se haya cerrado el nodo pasivo), entonces deberá detenerse antes de cerrar el nodo activo.
Si es necesario reiniciar o cerrar el nodo activo y no se puede trasladar el servidor de buzón en clúster al nodo pasivo, se recomienda usar Directiva de grupo para garantizar que el servidor de buzón en clúster se detiene antes de reiniciar o cerrar un nodo activo. Windows Server dispone de un conjunto de scripts de apagado de equipos controlados por directiva que se puede administrar con el complemento Directiva de grupo. Este complemento incluye extensiones que permiten especificar un script que se ejecuta al apagar el equipo.
Por ejemplo, puede crear un script de apagado que ejecute los cmdlet Move-ClusteredMailboxServer o Stop-ClusteredMailboxServer con los parámetros apropiados. También se recomienda usar un script de apagado porque reduce al mínimo las posibilidades de que el sistema sea apagado o reiniciado por un administrador que no sepa que es necesario mover o detener el servidor de buzones de correo en clúster antes de apagar el nodo activo.
Importante
Los scripts se ejecutan en la cuenta Sistema local. Para que estos scripts se puedan ejecutar correctamente, debe conceder permiso a la cuenta de sistema local (cuenta de equipo del nodo local) para administrar el servidor de buzones de correo en clúster.
Administración de la replicación y respuesta de archivos de registro
La administración de la replicación en un entorno CCR conlleva las siguientes actividades principales:
Administrar conmutaciones por error al detener la replicación
Detener y reiniciar la replicación en las copias del grupo de almacenamiento
Configurar una o más redes redundantes para la replicación
Administrar conmutaciones por error al detener la replicación
La detención de la replicación detiene la propagación de todos los cambios del grupo de almacenamiento activo a la copia durante el período de suspensión. Si en ese momento se produce una conmutación por error, la copia del grupo de almacenamiento no tendrá los últimos cambios realizados. En función del volumen del cambio que se haya producido en el nodo activo, la falta de los últimos cambios puede evitar que el sistema monte la copia en el equipo pasivo. Por este motivo, puede usar la versión disponible del grupo de almacenamiento del nodo pasivo o esperar hasta que se recupere el servidor original. Es importante minimizar el tiempo que se detiene la replicación para minimizar esta exposición.
Si no monta la versión de los datos en el nodo pasivo cuando el equipo de origen esté disponible, el sistema de replicación copiará los registros que faltan y montará automáticamente la copia de la base de datos en el nodo activo nuevo.
Puede producirse una conmutación por error después de que se haya reanudado la replicación, cuando aún falten registros en la copia pasiva o cuando tenga todos los registros pero todavía no se hayan reproducido. Si se copian los registros, pero no se reproducen, una conmutación por error activará la reproducción de los registros pendientes en la base de datos. Así, este grupo de almacenamiento tendrá un tiempo de recuperación ampliado como parte de la conmutación por error, aunque no afecte a otros grupos de almacenamiento. Sin embargo, si hay suficientes registros disponibles para cumplir los criterios de montaje automático configurados, el sistema montará finalmente la base de datos con los últimos datos disponibles. Éste es uno de los riesgos de este proceso: uno de los registros que se van a reproducir podría estar dañado e impedir una reproducción correcta. En este caso, la reproducción provocaría un error y se bloquearían las demás actividades de reproducción. Si esto ocurre, la copia del grupo de almacenamiento se encontrará en un estado denominado Error. En este estado de error, puede recuperarla mediante la versión de la base de datos activa en ese momento. De lo contrario, será necesario esperar hasta que el servidor original se encuentre disponible y se vuelva a copiar el registro que no está dañado.
Detener y reiniciar la replicación en las copias del grupo de almacenamiento
Ocasionalmente, puede ser necesario controlar las actividades de la copia pasiva. Para ello, es posible que tenga que detener y reiniciar la actividad de replicación. La replicación se controla en el nivel del grupo de almacenamiento. Dado que un grupo de almacenamiento sólo puede contener una base de datos, la replicación se localiza en una base de datos.
La replicación tiene lugar cuando los dos nodos del clúster están en funcionamiento, el servicio de replicación de Microsoft Exchange está en ejecución en el nodo de destino y el grupo de almacenamiento tiene habilitada la función de copia. Si la ubicación de origen o destino de CCR no está disponible, deberá detener la replicación. Además, algunas tareas administrativas de CCR, como la reinicialización, la realización de una comprobación de integridad o la reconfiguración de almacenamiento, requieren que se detenga la replicación de una copia del grupo de almacenamiento. Si necesita detener todo tipo de acceso a los archivos de registro del destino y al directorio de registros, deberá detener la replicación.
Exchange 2007 requiere que se detengan todas las actividades de replicación si ha cambiado la ubicación del grupo de almacenamiento o la base de datos.
Para obtener más información acerca de la detención de actualizaciones de la copia de bases de datos, consulte el artículo de la Knowledge Base Cómo detener la replicación de una copia de replicación continua en clúster (página en inglés). Para obtener más información acerca del reinicio de actualizaciones de la copia de bases de datos, consulte el artículo de la Knowledge Base Cómo reiniciar la replicación en una copia de replicación continua de clústeres (página en inglés).
Para obtener más información acerca de cómo realizar una comprobación de integridad en los registros de transacciones de CCR y archivos de base de datos, consulte el artículo de la Knowledge Base Cómo comprobar una copia de réplica continua agrupada con Eseutil (página en inglés).
Configurar una o más redes redundantes para la replicación
El SP1 de Exchange 2007 permite configurar redes de clústeres redundantes que se pueden usar para el trasvase de registros e inicialización en un entorno CCR. La red redundante deberá configurarse como red de clúster mixta. Una red de clúster mixta es cualquier red de clúster configurada tanto para un clúster (latido) como para el tráfico de acceso de clientes
Cuando se haya configurado una red de clúster mixta con nombres de host y direcciones IP de replicación continua, Exchange 2007 usará dicha red para el trasvase de registros. Además, la red configurada estará disponible para la inicialización de administrador por medio del cmdlet Update-StorageGroupCopy. Se pueden especificar múltiples redes mixtas y, si existe más de una red, Exchange 2007 selecciona aleatoriamente una de las redes. Si la red que se está usando no está disponible, Exchange 2007 selecciona automáticamente una red que sí lo esté.
La admisión del transporte de registros a través de una red mixta se configura mediante el cmdlet Enable-ContinuousReplicationHostName. Del mismo modo, la desactivación de esta función se realiza mediante el cmdlet Disable-ContinuousReplicationHostName. Después de que un servidor de buzones en clúster exista en un entorno CCR, un administrador puede ejecutar Enable-ContinuousReplicationHostName en ambos nodos del clúster y especificar dos direcciones IP y nombres de host. Después de hacerlo, el sistema selecciona aleatoriamente una red mixta para la copia de registros después de la configuración correcta y después de confirmar que la red mixta está operativa.
La inicialización y reinicialización en un entorno CCR se realiza mediante el cmdlet Update-StorageGroupCopy. En Exchange 2007 SP1, este cmdlet se ha ampliado para incluir un nuevo parámetro denominado DataHostNames. Este parámetro se usa para especificar qué red deberá usarse para la inicialización y reinicialización. El valor es una lista de múltiples valores de dos nombres: un nombre completo de dominio (FQDN) o un nombre de host. Uno de estos nombres debe identificar el nodo pasivo.
Para obtener más información acerca de la configuración de redes redundantes para el trasvase de registros y la inicialización, consulte los siguientes temas:
CCR en Windows Server 2008:
CCR en Windows Server 2003:
Tareas relacionadas con los grupos de almacenamiento y las bases de datos de un servidor de buzones de correo en clúster
Las tareas administrativas relacionadas con los grupos de almacenamiento y las bases de datos de un servidor de buzones de correo en clúster en un entorno CCR son las siguientes:
Cambio de ubicación de los archivos del grupo de almacenamiento o de una base de datos
Ver el estado de las copias del grupo de almacenamiento
Montar y desmontar bases de datos
Comprobar la integridad de una copia del grupo de almacenamiento
Recuperar datos dañados en un grupo de almacenamiento de producción o una copia del grupo de almacenamiento
Restaurar la CCR después de un error o de algún tipo de daños en los datos
Excepto en el grupo de almacenamiento de recuperación, que es un grupo de almacenamiento de una clase especial, todos los grupos de almacenamiento de un entorno CCR se habilitan automáticamente para la replicación continua. Aunque la replicación y la reproducción se pueden suspender, la deshabilitación de la replicación continua de uno o más grupos de almacenamiento en un entorno CCR no es posible porque se podría producir una interrupción para impedir el acceso a bases de datos determinadas.
Cuando se crea un nuevo grupo de almacenamiento en un entorno CCR, la reinicialización de la copia de la base de datos en el nodo pasivo se produce automáticamente. Si por algún motivo la reinicialización no se produjera automáticamente, deberá inicializar la copia de la base de datos de forma manual. Para obtener instrucciones detalladas acerca de como reinicializar una copia de la base de datos, consulte Cómo incializar una copia de replicación continua de clústeres.
Cambiar la ubicación de los archivos del grupo de almacenamiento o una base de datos
Es posible que sea necesario cambiar la ubicación de archivos del grupo de almacenamiento o de una base de datos en un entorno CCR. El tiempo empleado en cambiar la ubicación de los archivos dependerá del tamaño de la base de datos y del número de archivos de registro de transacción que se estén moviendo, además de las características de rendimiento del almacenamiento. Durante un desplazamiento, la base de datos se desmontará.
En un entorno CCR, la reubicación de un grupo de almacenamiento requiere que las dos copias se reubiquen de un modo coherente, ya que la ubicación del nodo activo y del nodo pasivo debe ser la misma. Antes de que se pueda mover un grupo de almacenamiento o su base de datos, debe desmontar la base de datos y suspender la replicación. Con la copia activa, pude hacerlo mediante el uso del cmdlet Dismount-Database del Shell de administración de Exchange. Para el servicio de replicación de Microsoft Exchange, use el cmdlet Suspend-StorageGroupCopy y el cmdlet Resume-StorageGroupCopy.
Nota
El servicio de replicación de Microsoft Exchange controla continuamente los archivos en la ubicación de la copia y en los registros del nodo activo. Por este motivo, si se manipulan los registros activos de cualquier modo, deberá suspender la actividad de ese grupo de almacenamiento mediante el cmdlet Suspend-StorageGroupCopy, que detiene la replicación.
Para obtener instrucciones detalladas acerca del cambio de ubicación de los archivos del grupo de almacenamiento en un entorno CCR, consulte Cómo mover un grupo de almacenamiento en un entorno CCR. Para obtener instrucciones detalladas acerca del cambio de ubicación de una base de datos en un entorno CCR, consulte Cómo mover una base de datos en un entorno CCR.
Visualizar el estado de las copias del grupo de almacenamiento
En la versión sólo para fabricantes (RTM) de Microsoft Exchange 2007, la información del estado de CCR sólo se puede ver usando el Shell de administración de Exchange. En el SP1 de Exchange 2007, parte de la información de estado incluida en la tabla siguiente se puede ver en la Consola de administración de Exchange.
Exchange 2007 publica una variedad de informaciones de estado para las copias de los grupos de almacenamiento. En la siguiente tabla se describe la información de estado que está disponible. En la siguiente tabla, se enumeran los atributos en el orden en el que aparecen en la salida completa del cmdlet Get-StorageGroupCopyStatus. Para obtener instrucciones detalladas acerca de cómo ver la información de estado, consulte el artículo de la Knowledge Base Cómo ver el estado de una copia de la replicación continua de clústeres mediante el Shell de administración de Exchange (página en inglés).
Información de estado disponible para grupos de almacenamiento con CCR habilitada.
| Atributo | Descripción |
|---|---|
Identity |
Identidad del grupo de almacenamiento consultado. Este atributo proporciona el <ServerName>\<StorageGroupName>. |
StorageGroupName |
Nombre del grupo de almacenamiento consultado. Este atributo proporciona el nombre del grupo de almacenamiento. |
SummaryCopyStatus |
Estado general actual de la copia pasiva. Los valores posibles son:
Exchange 2007 SP1 agrega los siguientes valores de estado adicionales:
|
Error |
La comprobación de la base de datos o los registros, que detectó una incoherencia que impide la replicación. También puede ocurrir que haya un problema de configuración o de acceso con la copia activa o pasiva. Los valores posibles son Verdadero y Falso. |
FailedMessage |
Mensaje de texto que identifica el estado que provocó el error de replicación. es posible que no sea la única área con problemas de replicación. |
Inicializando |
Indica que la inicialización está en curso. Los valores posibles son Verdadero y Falso. |
Suspendido |
Indica que se ha detenido la replicación de la copia pasiva. Este estado impide que avance la base de datos y que los registros se copien. Los valores posibles son Verdadero y Falso. |
SuspendComment |
Área de comentarios opcional en la que el administrador puede indicar un motivo o incluir una nota con una explicación de la detención de la actividad de replicación. |
CopySuspend |
Indica que se ha detenido la copia de registros de la copia pasiva. Esto impide el cambio del directorio de copia de registros. Los valores posibles son Verdadero y Falso. |
CopySuspendComment |
Comentario opcional de administrador que indica un motivo o incluye una nota con una explicación de la detención de actividad de copia de registros. |
CopyQueueLength |
Número de archivos de registro de transacciones a la espera de ser copiados en la carpeta de archivos de registro de copia pasiva. Una copia no se considera finalizada hasta que se haya realizado una comprobación de los daños. |
ReplayQueueLength |
Número de archivos de registro de transacciones a la espera de reproducirse en la copia pasiva. |
LatestAvailableLogTime |
Marca de tiempo en el grupo de almacenamiento de origen del archivo de registro de transacciones detectado más recientemente. |
LastCopyNotificationedLogTime |
Hora asociada al último registro nuevo generado por el grupo de almacenamiento activo y conocido para la copia. |
LastCopiedLogTime |
Marca de tiempo en el grupo de almacenamiento de origen de la última copia correcta de un archivo de registro de transacciones. |
LastInspectedLogTime |
Marca de tiempo en el grupo de almacenamiento de destino de la última inspección correcta de un archivo de registro de transacciones. |
LastReplayedLogTime |
Marca de tiempo en el grupo de almacenamiento de destino de la última reproducción correcta de un archivo de registro de transacciones. |
LastLogGenerated |
Último número de generación de registro conocido generado en la copia activa del grupo de almacenamiento. |
LastLogCopied |
El último número de generación de registro que se copió correctamente en la carpeta de registro de la copia pasiva. |
LastLogNotified |
Último número de generación de registro generado por el grupo de almacenamiento activo y conocido para la copia. |
LastLogInspected |
Último número de generación de registro inspeccionado para comprobar su coherencia y si está dañado. |
LastLogReplayed |
El número de generación del último registro que se reprodujo correctamente en la copia pasiva de la base de datos. |
LatestFullBackupTime |
Hora de la última copia de seguridad completa. |
LastestIncrementalBackupTime |
Hora de la última copia de seguridad incremental. |
SnapshotBackup |
Indica si la última copia de seguridad completa realizada era una copia de seguridad de secuencias heredadas o una instantánea de copia de seguridad de Servicio de instantáneas de volumen (VSS). |
SnapshotLatestFullBackup |
Hora de la última copia de seguridad completa de instantánea. |
SnapshotLatestIncrementalBackup |
Hora de la última copia de seguridad incremental de instantánea. |
SnapshotLatestDifferentialBackup |
Hora de la última copia de seguridad diferencial de instantánea. |
SnapshotLatestCopyBackup |
Hora de la última copia de seguridad de copia de instantánea. |
OutstandingDumpsterRequests |
Solicitudes pendientes y el intervalo de tiempo (reducido-amplio) para las solicitudes pendientes. |
DumpsterStatistics |
Estadísticas de volcado de archivos de transporte desde todos los servidores de transporte de concentradores accesibles. Este valor sólo se muestra cuando el parámetro DumpsterStatistics se utiliza con el comando Get-StorageGroupCopyStatus. |
DumpsterStatisticsNotAvailable |
Lista de servidores de transporte de concentradores inaccesibles. |
Puede evaluar rápidamente el estado de una copia del grupo de almacenamiento mirando los valores de SummaryCopyStatus, CopyQueueLength, ReplayQueueLength y LastInspectedLogTime. Estos atributos muestran si la copia del grupo de almacenamiento funciona correctamente y si la copia del grupo de almacenamiento está relativamente al día, tanto en el registro de copia como en el de repetición. Si se producen las siguientes condiciones, debe determinar la causa y corregir el problema:
La copia no está en buenas condiciones.
La longitud de cola de la copia es superior a 5.
La longitud de cola de repetición es superior a 20.
La hora del último registro inspeccionado no es reciente. La inactividad del grupo de almacenamiento puede ser la causa de esta situación, pero también puede indicar que el servicio de replicación de Microsoft Exchange se ha detenido.
Puede calcular los dos números de cola en unidades de tiempo de este modo:
Cola de copia en tiempo = LatestAvailableLogTime – LastCopiedLogTime
Cola de repetición en tiempo = LatestCopiedLogTime – LastInspectedLogTime
Los valores de longitud de la cola de replicación y de la cola de copia están disponibles como contadores de rendimiento. Son los contadores de rendimiento CopyQueueLength y ReplayQueueLength del objeto de rendimiento del servicio de replicación de Microsoft Exchange.
En algunos escenarios poco comunes, el estado de replicación puede ser malinterpretado. A continuación, se ofrece una lista de esos escenarios:
Un grupo de almacenamiento no activo (es decir, que no cambia) puede mostrar un estado que indica que está en buenas condiciones, aunque esto no sea correcto. Esta situación pudo producirse porque no se puede detectar que no está en buenas condiciones hasta que se vuelva a reproducir un registro.
Durante la inicialización de la replicación, se está reevaluando el estado de replicación y es posible que no sea preciso. Cuando se complete la inicialización, se actualizará el estado.
El valor del campo LastLogGenerated puede ser incorrecto cuando se desmonta una base de datos. Sin embargo, se replican todos los registros con el contenido de usuario final si se está replicando la copia del grupo de almacenamiento.
Cuando faltan uno o varios registros en medio de una secuencia de registros, la copia pasiva continúa intentando recuperarlos. Al hacerlo, el estado de replicación cambia entre estados con error y sin error. Las colas de copia y reproducción seguirán creciendo.
En muy raras ocasiones, puede que se compruebe un registro correctamente, pero que no se pueda reproducir. En esta situación, el sistema alternará entre estados con error y sin error mientras intenta recuperarlo. Las colas de copia y reproducción seguirán creciendo.
Nota
En Exchange 2007 SP1, también puede usar un cmdlet nuevo denominado Test-ReplicationHealth para comprobar las condiciones y el estado de los grupos de almacenamiento habilitados para la replicación continua. Para obtener más información acerca del cmdlet Test-ReplicationHealth, consulte Test-ReplicationHealth.
Montaje y desmontaje de bases de datos
En ocasiones, es posible que sea necesario montar o desmontar bases de datos en un entorno de replicación continua en clúster. Es posible que esto sea necesario para realizar una reconfiguración o para corregir problemas con el servidor o la base de datos. Cuando se desmonta la base de datos, se inmoviliza para impedir más cambios. No se pueden cambiar ni la base de datos ni los archivos de registro mientras la base de datos esté desmontada.
Para obtener más información acerca de cómo montar bases de datos en un entorno CCR, consulte el artículo de la Knowledge Base Cómo montar una base de datos en un entorno de replicación continua de clústeres (página en inglés). Para obtener más información acerca de cómo montar bases de datos en un entorno de replicación continua en clúster, consulte el artículo de la Knowledge Base Cómo desmontar una base de datos en un entorno de replicación continua de clústeres (página en inglés).
Comprobar la integridad de una copia del grupo de almacenamiento
Cuando se usa CCR, se recomienda comprobar la integridad de la copia pasiva periódicamente ejecutando una comprobación de coherencia física en los archivos de base de datos y registro de transacciones. En la comprobación de coherencia física se examinan los archivos de la base de datos y del registro de transacciones para ver si están dañados. Puede realizar esta comprobación mediante la aplicación Utilidades de base de datos (Eseutil.exe) de Exchange Server. Para ver los pasos detallados que explican cómo usar Eseutil con el fin de comprobar si los archivos de la base de datos y del registro de transacciones están dañados, consulte el artículo de la Knowledge Base Cómo comprobar una copia de réplica continua agrupada con Eseutil (página en inglés).
Nota
Antes de ejecutar una comprobación de la coherencia física en una base de datos, debe suspender temporalmente toda la actividad de replicación en la copia del grupo de almacenamiento. Para ello, utilice el cmdlet Suspend-StorageGroupCopy del Shell de administración de Exchange. Cuando la comprobación de coherencia se haya completado, puede reanudar la actividad de reproducción de registros de transacciones mediante el cmdlet Resume-StorageGroupCopy.
Recuperación de datos dañados en un entorno de replicación continua en clúster (CCR)
CCR permite la recuperación de datos dañados o errores en un grupo de almacenamiento de producción al iniciar un corte programado. Si los archivos de registro no están dañados, no debería producirse ninguna pérdida de datos debido a la recuperación. Sin embargo, si los archivos de registro no están disponibles, la recuperación únicamente puede devolver el grupo de almacenamiento a un momento concreto que sea coherente con el último conjunto de cambios no dañados que haya recibido la copia. Una restricción adicional es que no pueden faltar datos de cambios ni haber datos de cambios dañados que sean anteriores a ese momento determinado.
Para obtener instrucciones detalladas sobre cómo recuperarse de datos dañados o errores en un entorno CCR, consulte los siguientes artículos de la Knowledge Base (página en inglés):
Restaurar la CCR tras sufrir daños o errores
CCR proporciona una funcionalidad de autorecuperación después de un error. Sin embargo, en algunos casos sigue siendo necesaria la recuperación manual. Estos casos son los siguientes:
El archivo de la base de datos tiene datos dañados en la copia pasiva Para obtener instrucciones detalladas acerca de cómo restaurar la CCR después de que se produzcan daños en la base de datos, consulte el artículo de la Knowledge Base Cómo restaurar después de que una base de datos resulte dañada (página en inglés).
Se ha producido un error en la base de datos o en un volumen de registro de la copia pasiva Para obtener instrucciones detalladas acerca de cómo restaurar la CCR después de un error de volumen, consulte el artículo de la Knowledge Base Cómo restaurar después de un error en un volumen (página en inglés).
Se ha producido un error o divergencia en la base de datos La CCR detecta y comunica que se ha producido una divergencia en la base de datos como resultado de un error. En general, esto ocurre cuando está disponible una copia de la base de datos y la copia en la que se produce el error tiene más cambios que los que permiten los criterios de montaje automático aceptable. Para obtener instrucciones detalladas acerca de cómo restaurar la CCR después de un error de una base de datos o una divergencia, consulte Cómo restaurar la funcionalidad CCR después de un error o divergencia.