Instalación de la replicación continua en clúster en Windows Server 2008

Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1

Última modificación del tema: 2008-12-19

Aunque el proceso de implementación de la replicación continua en clúster (CCR) en Windows Server 2008 es similar al de la implementación de CCR en Windows Server 2003, existen algunas diferencias importantes. Antes de implementar la CCR, es aconsejable que revise atentamente replicación continua de clústeres. Además, asegúrese de que conoce todos los requisitos especificados en Diseño de la replicación continua de clústeres.

La instalación de CCR en Windows Server 2008 se realiza en varias fases diferentes:

1. Configuración del hardware, empezando por la creación y configuración de la red de clústeres.

2. Formación del clúster, empezando por el primer nodo y siguiendo con el segundo.

3. Configuración de las redes de clústeres y la tolerancia para latidos de clúster no encontrados.

4. Configuración y protección del testigo de recurso compartido de archivos.

5. Instalación de las funciones del servidor Buzón de correo activo y pasivo en el clúster. El servidor de buzones de correo en clúster se crea durante la instalación de la función del servidor Buzón de correo activo.

   Nota

   Se recomienda completar cada fase antes de comenzar la siguiente. Una vez finalizadas todas las fases, se recomienda comprobar la solución CCR antes de ponerla en producción.

Existen algunas tareas posteriores a la instalación que también deben realizarse:

• Ajuste de la configuración de control de la conmutación por error.

• Ajuste de la configuración predeterminada del contenedor de transporte.

• Comprobación de la posibilidad de mover un CMS entre los nodos del clúster.

• Habilitación de varias redes para la actividad de replicación continua.

Antes de realizar cualquiera de los procedimientos mencionados a continuación, debe asegurarse de que los equipos tengan instalados los componentes del sistema operativo para Windows Server 2008. Para obtener instrucciones detalladas acerca de cómo instalar los requisitos previos de Microsoft Exchange en Windows Server 2008, consulte Instalación de los requisitos previos de Exchange 2007 SP1 y SP2 en Windows Server 2008 o Windows Vista.

Las siguientes secciones explican cada fase de la instalación más detalladamente.

Formación y configuración de redes

Debe tener un número suficiente de direcciones IP disponibles al crear CMS en un entorno CCR de dos nodos en Windows Server 2008. Los clústeres de conmutación por error de Windows Server 2008 presentan nuevas capacidades de red que constituyen un cambio importante en el funcionamiento de clústeres heredados. Por ejemplo, los clústeres de conmutación por error de Windows Server 2008 introducen la compatibilidad con varias subredes, con el Protocolo de configuración dinámica de host (DHCP), y el Protocolo de Internet versión 4 (IPv4) y versión 6 (IPv6). Al ejecutar un clúster de conmutación por error de Windows Server 2008, el Service Pack 1 (SP1) de Microsoft Exchange Server 2007 incluye la compatibilidad con clústeres geográficamente dispersos para la conmutación por error entre dos subredes. Esta compatibilidad incluye tanto clústeres de copia única como servidores de buzones en un entorno CCR.

Empezando con los clústeres de conmutación por error de Windows Server 2008, los nodos de clúster individuales se pueden ubicar ahora en redes distintas enrutadas. Para esto es necesario que los recursos que dependen de recursos de dirección IP (por ejemplo, recursos de nombre de red) implementen una lógica OR, ya que es poco probable que todos los nodos de clúster tengan una conexión local directa con cada red de la que el clúster tiene conocimiento. Esto facilita la puesta en conexión de los recursos de dirección IP y nombre de red en caso de error de los servicios y aplicaciones en nodos remotos.

Todas las direcciones IP en línea asociadas con un recurso de nombre de red se registrarán dinámicamente en un Sistema de nombres de dominio (DNS) (si está configurado para las actualizaciones dinámicas) con la lista ordenada de modo que los recursos de dirección IP en línea se devuelven en primer lugar a los clientes. Dado que los nodos de clúster se pueden colocar en redes diferentes enrutadas y que se han modificado los mecanismos de comunicación para usar protocolos de sesión confiables implementados con Protocolo de datagramas de usuario (UDP) (unidifusión), los requisitos de red de los clústeres geográficamente dispersos ya no son aplicables. En consecuencia, las organizaciones pueden implementar un clúster de conmutación por error en dos centros de datos físicos sin necesidad de usar tecnología de LAN virtual (VLAN) para que las subredes de clústeres abarquen las dos ubicaciones.

Se requieren direcciones IP tanto para redes públicas como privadas. Los requisitos relacionados con las direcciones privadas y públicas son las siguientes:

• Direcciones privadas   Cada nodo requiere una dirección IP para cada adaptador de red que se usa en una red de clústeres privada. Puede usar una dirección IPv4 estática o una dirección IPv6 asignada de forma dinámica. Debe usar direcciones IP que no estén en la misma subred o red que una de las redes públicas. Se recomienda usar 10.10.10.10 y 10.10.10.11 con una máscara de subred de 255.255.255.0 como direcciones IP privadas para los tres nodos.

• Direcciones públicas   Cada nodo requiere una dirección IP para cada adaptador de red que se usa en una red de clústeres pública, a veces denominada red mixta. Además, se requieren direcciones IP para el clúster de conmutación por error y para el CMS de manera que clientes y administradores puedan tener acceso a ellos. Debe usar direcciones IP que no estén en la misma subred o red que una de las redes privadas. Puede usar direcciones IPv4 estáticas, direcciones IPv4 DHCP o direcciones IPv6 estáticas.

  Importante

  Todos los adaptadores de red de una red de clúster deben usar la misma versión de TCP/IP, esto es, todos deben usar sólo IPv4 o todos IPv4 e IPv6 simultáneamente.

Consejos de red para servidores de buzones de correo en clúster

Le recomendamos también que siga estos consejos para la sed de clúster:

• Use nombres significativos   La creación de un clúster le ofrece muchas oportunidades de usar nombres significativos en los nodos de clústeres, interfaces de redes de clústeres, el nombre del clúster y los nombres de servidores de buzones en clúster. Por ejemplo, la red usada para comunicarse con otros servidores y clientes de Exchange se denomina pública. La red usada para comunicarse entre los nodos del clúster se denomina privada. Use nombres que se puedan relacionar entre sí sin tener que revisar un mapa de la topología. Otra convención útil es relacionar los nodos de un clúster con el nombre del servidor de buzones de correo en clúster. Por ejemplo, use mbx01, mbx01-node1 y mbx01-node2 para el servidor de buzones de correo en clúster y los dos nodos, respectivamente.

• Use direcciones IP privadas para las interfaces de red privadas   Para obtener una lista de los intervalos de direcciones IP y máscaras de subred que se pueden usar en cada nodo para las interfaces de redes privadas, consulte la tabla siguiente.

  Intervalos de direcciones y máscaras de subred para interfaces de red privadas

  Red/nodo	Intervalo de direcciones IP	Máscara de subred
  Privado/NODO1	10.10.10.10-255	255.255.255.0
  Privado/NODO2	10.10.10.11-255	255.255.255.0

Tenga en cuenta lo siguiente:

• Si la red pública usa una red 10.x.x.x y una máscara de subred 255.255.255.0, se recomienda usar direcciones IP de redes privadas y máscara de subred alternativas.

• No se recomienda usar ningún adaptador tolerante a errores o temporizador de la red privada. Si necesita redundancia en la red privada, use múltiples adaptadores de red configurados sólo para el uso en clúster. Es importante comprobar que la firma del fabricante y el controlador han pasado la última revisión si usa esta tecnología. Para obtener información acerca de la compatibilidad en un clúster de servidor, póngase en contacto con el fabricante de adaptadores de red. Para obtener más información acerca del temporizador del adaptador de red en las implementaciones de clúster de conmutación por error, consulte el artículo 254101 de Microsoft Knowledge Base, El equipo de adaptador de red y clústeres de servidor.

Formación del clúster de conmutación por error

Un clúster de conmutación tras error se forma cuando el primer nodo se agrega al clúster. Este proceso da al clúster un nombre de red y una dirección IP de red únicos. Tanto el nombre como la dirección IP de red, que colectivamente forman la identidad de red del clúster, se mueven de un nodo a otro del clúster a medida que los nodos se conectan y desconectan. Por lo general, la identidad de red del clúster casi nunca se usa en la administración del servidor de buzones de correo en clúster.

Si está familiarizado con la implementación de clústeres de conmutación por error o clústeres de Exchange de versiones anteriores, la implantación de un clúster para la CCR le resultará bastante diferente. Si no conoce las soluciones de clúster, verá que la implementación es mucho más sencilla que una configuración típica de clúster.

Puede construir un clúster nuevo usando las instrucciones que aparecen en Cómo crear un clúster de conmutación por error de Windows Server 2008 para la replicación continua en clúster.

Agregar nodos adicionales

Una vez instalado el Servicio de clúster en el primer nodo, observará que se tarda menos tiempo en instalarlo en el segundo nodo. Esto es así porque el programa de instalación usa las opciones de configuración de red configuradas en el primer nodo como una base para la configuración de las opciones de red en nodos subsiguientes. Antes de agregar y configurar el segundo nodo, debe validar la configuración del clúster. Puede comprobar que el Servicio de clúster está funcionando y que el clúster está operativo ejecutando el grupo Cluster.exe desde el símbolo del sistema. El resultado que obtenga debe ser similar al siguiente.

C:\>cluster group
Listing status for all available resource groups:
Group                   Node            Status
------------------ ---------------      ------
Cluster Group         <NODEName>        Online

Le recomendamos que revise los registros de eventos en busca de errores y advertencias que puedan requerir su atención antes de proceder. Para obtener instrucciones detalladas acerca de cómo agregar el segundo nodo al clúster, consulte Cómo crear un clúster de conmutación por error de Windows Server 2008 para la replicación continua en clúster.

Configuración de las redes de clúster

Una vez agregados ambos nodos al clúster, se configurarán los componentes de red de clúster. Concretamente, se deben configurar redes para clúster y acceso de cliente, y establecer la configuración de tolerancia para latidos de clúster no encontrados. Se recomienda también cambiar el nombre de las redes de clúster por otros más significativos.

En la tabla siguiente se detallan las opciones disponibles para configurar las redes del clúster para el latido de clúster.

Opciones para configurar redes de clúster

Los CMS implementados en un entorno CCR requieren al menos dos tarjetas de red en ambos nodos para que sean compatibles. En Exchange 2007 SP1, cualquier red administrada por el servicio clúster y habilitada para el uso de clústeres y las conexiones de cliente (por ejemplo, configurada como una red mixta) se puede usar para las funciones de replicación continua, incluida la inicialización, el transporte de registros y la reinicialización. Esto se logra usando un nuevo cmdlet en Exchange 2007 SP1 denominado Enable-ContinuousReplicationHostName.

Establecimiento de la configuración de tolerancia para latidos de clúster no encontrados

Tras configurar las comunicaciones de clúster y la prioridad de la red, se recomienda establecer una configuración de tolerancia específica para los latidos de clúster no encontrados. Con esto se configura la supervisión del Servicio de clúster de la conectividad de red entre nodos de clúster para tolerar interrupciones de poca importancia. Esto evita conmutaciones por error en algunos casos en los que la interrupción en la red es breve. Se recomienda configurar las redes de clúster privadas y mixtas de todos los nodos para que admitan diez latidos no encontrados. Este nivel de configuración corresponde a aproximadamente 12 segundos.

Para obtener instrucciones detalladas acerca de cómo configurar los componentes de red del clúster, consulte Cómo configurar redes de clúster para un clúster de conmutación por error.

Configuración de las opciones de TTL para el recurso de nombre de red del servidor de buzones de correo en clúster

Existen dos escenarios de implementación en los que ejercitar las opciones de interrupción o recuperación implicará un cambio de la dirección IP asignada al servidor de buzones de correo en clúster:

• Un servidor de buzones de correo en clúster se implementa en un entorno con varias redes.

• Se usa un clúster en espera para recuperar un clúster con errores.

En ambos casos, el nombre del servidor de buzones de correo en clúster no cambia, pero sí lo hace la dirección IP que tiene asignada. Los clientes y otros servidores que se comunican con un servidor de buzones de correo en clúster que tenga cambiadas las direcciones IP no podrán restablecer las comunicaciones dicho servidor hasta que el DNS se haya actualizado con la nueva dirección IP, y se hayan actualizado las memorias caché de DNS locales. Para minimizar el tiempo que se tarda en informar a clientes y otros servidores de los cambios de DNS, se recomienda configurar un valor TTL de DNS de cinco minutos para el recurso de nombre de red del servidor de buzones de correo en clúster.

De forma predeterminada, el Servicio de clúster usa una opción de 20 minutos para el valor TTL de DNS de recursos de nombre de red. Aunque se pueden usar las herramientas de administración de DNS para ajustar manualmente el valor TTL para el nombre de host directamente en la base de datos de DNS, se sobrescribirá cada vez el valor de la base de datos de DNS y se establecerá en la opción predeterminada del Servicio de clúster de 20 minutos y se actualizará el registro del nombre de red en DNS. Se producirá una actualización del registro del nombre de red en DNS siempre que se inicie, se mueva o se vuelva a poner en línea el servidor de buzones de correo en clúster después de un error o una conmutación por error.

En Windows Server 2008, se ha agregado una nueva propiedad privada a los recursos de nombre de red en clústeres de conmutación por error. La nueva propiedad se denomina HostRecordTTL y se puede configurar usando Cluster.exe.

Para obtener instrucciones detalladas acerca de cómo configurar los valores TTL de DNS para un recurso de nombre de red CMS para usarlos en un CMS de un entorno con varias subredes o una implementación de clústeres en espera, consulte Cómo configurar valores DNS TTL para recursos de nombres de red.

Configuración del quórum de clúster

Una vez configuradas las redes de clúster, el paso siguiente es configurar el clúster de conmutación por error para que use un recurso de quórum Mayoría de recursos compartidos de archivo y nodo. Para obtener instrucciones detalladas acerca de cómo configurar un clúster de conmutación por error para usar el modelo de quórum de nodos y recursos compartidos de archivos mayoritarios, consulte Cómo configurar el quórum Mayoría de recursos compartidos de archivo y nodo.

Validación del clúster de conmutación por error

Windows Server 2008 incluye un nuevo asistente denominado Asistente para validar una configuración que se puede usar para comprobar el estado y la configuración de un clúster de conmutación por error. Se recomienda ejecutar este asistente antes de instalar Exchange 2007 en el clúster. Al ejecutar este asistente antes de instalar Exchange 2007, se pueden identificar y comprobar problemas de configuración dentro del clúster que podrían impedir la instalación de Exchange.

El Asistente para validar una configuración incluye cuatro grupos de pruebas diseñadas para comprobar que el clúster cumple los requisitos necesarios de compatibilidad con Microsoft. Estos requisitos se suman al requisito de que la solución de clúster lleve el logo de compatibilidad "Diseñado para Windows Server 2008".

Los cuatro grupos de pruebas son: Inventario, Red, Almacenamiento y Configuración del sistema. Puesto que CCR no usa el almacenamiento compartido, no es necesario ejecutar el grupo de pruebas Almacenamiento. Si se ejecuta el grupo de pruebas Almacenamiento para un clúster de conmutación por error que no tenga recursos de almacenamiento de clústeres, tales como un clúster de conmutación por error diseñado para CCR, se producirá un error en el grupo de pruebas Almacenamiento. Todos los errores del grupo de pruebas Almacenamiento se pueden omitir de forma segura ya que se espera la falta de almacenamiento compartido para un clúster de conmutación por error diseñado para CCR.

Para obtener instrucciones detalladas acerca de cómo validar el clúster de conmutación por error, consulte Cómo validar la configuración de un clúster de conmutación por error.

Instalación y configuración del servidor de buzones de correo en clúster

Puede instalar la función del servidor Buzón de correo en un clúster ejecutando unos pocos pasos en cada nodo. Después de formar y validar el clúster, y después de que el clúster esté configurado para usar el quórum de Conjuntos de nodos de mayoría (MNS) con el testigo de recurso compartido de archivos, deberá instalar la función del servidor Buzón de correo en el nodo activo. Para obtener instrucciones detalladas acerca de cómo instalar la función del servidor Buzón de correo en un nodo activo, consulte Cómo instalar la función de buzón en clústeres activo en un entorno CCR en Windows Server 2008.

Una vez instalados la función del servidor Buzón de correo y un CMS en el nodo activo, y comprobada la configuración del primer grupo de almacenamiento, deberá instalar la función del servidor Buzón de correo en el nodo pasivo. Para obtener instrucciones detalladas acerca de cómo instalar la función del servidor Buzón de correo en un nodo pasivo, consulte Instalación de la función de buzón en clústeres pasivo en un CCR en Windows Server 2008.

Una vez instalada la función del servidor Buzón de correo, puede ajustar la configuración de la conmutación por error. Para obtener más información acerca del ajuste de errores, consulte Cómo ajustar la configuración del montaje y la conmutación por error para la replicación continua en clúster.

Tareas posteriores a la instalación

Una vez instalada la función del servidor Buzón de correo en ambos nodos y creado un CMS, deberá realizar algunas tareas posteriores a la instalación. Entre ellas se incluyen:

• Habilitación de varias redes para la actividad de replicación continua.

• Ajuste de la configuración de control de la conmutación por error.

• Ajuste de la configuración predeterminada del contenedor de transporte.

• Comprobación de la posibilidad de mover un CMS entre los nodos del clúster.

Habilitación de varias redes para la actividad de replicación continua.

En el lanzamiento de la versión de fabricación (RTM) de Microsoft Exchange Server 2007, toda la copia e inicialización de archivos de registro se realiza a través de la red pública. En Exchange 2007, cualquier red de clúster configurada como red mixta puede habilitarse para una actividad de replicación continua. Esta actividad incluye la inicialización y reinicialización de grupos de almacenamiento y el trasvase de registros.

En Exchange 2007 SP1, sólo las redes de clústeres designadas como mixtas se pueden habilitar para una replicación continua. Una red mixta es cualquier red de clúster configurada tanto para un clúster (comunicación entre nodos) como para el tráfico de acceso de clientes. Las redes de clústeres configuradas para el acceso de clústeres, pero no para el acceso de clientes (algunas veces denominadas redes privadas) no se pueden habilitar para la replicación continua.

La admisión del transporte de registros a través de una red mixta se configura mediante un nuevo cmdlet denominado Enable-ContinuousReplicationHostName. De forma similar, la desactivación de esta característica se logra mediante el cmdlet Disable-ContinuousReplicationHostName. Después de que un CMS 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.

Para obtener instrucciones detalladas acerca de cómo habilitar redes de clústeres para una actividad de replicación continua, consulte Cómo habilitar redes de clúster redundantes para la inicialización y el transporte de registros en Windows Server 2008.

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.

Ajuste de la configuración de control de conmutación por error

La CCR incluye atributos que permiten controlar el comportamiento de la conmutación por error de un CMS. Puede configurar estos atributos mediante el cmdlet Set-MailboxServer. Estos atributos permiten al usuario controlar los dos siguientes algoritmos de decisión:

• Algoritmo 1   El algoritmo 1 controla si una base de datos se monta durante la conmutación por error. Durante la conmutación por error, si se detecta que la base de datos perdió menos registros que la cantidad configurada, se montará automáticamente. El número aceptable de registros perdidos puede configurarse mediante un valor denominado AutoDatabaseMountDial. Este parámetro, que se representa en Active Directory mediante un atributo de Exchange Server denominado msExchDataLossForAutoDatabaseMount, tiene tres valores: Lossless (Sin pérdida), Buena disponibilidad y Máxima disponibilidad. Lossless tiene un valor cero de pérdida de registros, el valor de Buena disponibilidad es de tres y Máxima disponibilidad tiene el valor predeterminado seis. Para obtener instrucciones detalladas acerca de la configuración de estos valores, consulte Cómo ajustar la configuración del montaje y la conmutación por error para la replicación continua en clúster.

• Algoritmo 2   El algoritmo 2 permite determinar si, con datos antiguos, es más importante estar en línea o sin conexión. Si se produce un error en el montaje de la base de datos basado en el algoritmo 1, se puede establecer el momento en el que se realizará una segunda comprobación. El atributo ForcedDatabaseMountAfter configura el tiempo que se va a esperar. El valor está en unidades de horas con un valor predeterminado de ilimitado.

  Importante

  Una vez alcanzado el valor de ForcedDatabaseMountAfter, la base de datos se montará, independientemente de si la copia del grupo de almacenamiento esté retrasada 1, 10 o 10.000 registros, lo que podría producir una pérdida significativa de datos. Por este motivo, este parámetro no se debe usar si los acuerdos de nivel de servicio (SLA) garantizan la cantidad máxima de datos que se puede perder.

Ajuste del contenedor de transporte

El volcado de archivos de transporte es una característica de la función del servidor Transporte de concentradores al usar la replicación continua local (LCR) o la replicación continua en clúster (CCR) y que sólo se puede usar para entornos de LCR o CCR. El volcado de archivos transporte envía un correo entregado recientemente después de un corte no programado. El volcado de archivos de transporte debe habilitarse siempre que se use la LCR o CCR. El contenedor de transporte se habilita para toda la organización estableciendo la cantidad de almacenamiento disponible por grupo de almacenamiento y el tiempo de retención de correo en el contenedor de transporte.

El servidor de transporte de concentradores mantiene una cola del correo entregado recientemente a un CMS. En el caso de que la conmutación por error no sea Lossless (sin pérdida), la CCR solicita automáticamente a todos los servidores de transporte de concentradores que reenvíen el correo desde la cola de volcado de archivos de transporte. En entornos de LCR, la solicitud de reenvío se realiza como parte de la tarea Restore-StorageGroupCopy. Cuando se produce el reenvío, el almacén de información elimina automáticamente los duplicados y reenvía el correo perdido. Puede usar el cmdlet Set-TransportConfig para cambiar los ajustes de configuración predeterminados para el contenedor de transporte, que se aplican a nivel de grupo de almacenamiento. Como alternativa, en Exchange 2007 SP1, puede usar la Consola de administración de Exchange para configurar los valores del volcado de archivos transporte.

Es recomendable que configure el tamaño máximo por grupo de almacenamiento (el parámetro MaxDumpsterSizePerStorageGroup) en un tamaño que sea 1,5 veces el tamaño del mensaje máximo que se puede enviar. Por ejemplo, si el tamaño máximo para los mensajes es de 10 megabytes (MB), deberá configurar el parámetro MaxDumpsterSizePerStorageGroup con un valor de 15 MB. Para organizaciones sin tamaños máximos de mensaje, se aconseja configurar el tamaño máximo por grupo de almacenamiento con un valor de 1,5 veces el tamaño del mensaje medio enviado en la organización.

Se recomienda también configurar el tiempo de retención máximo por grupo de almacenamiento (el parámetro MaxDumpsterTime) en un valor de 07.00:00:00, lo que equivale a 7 días. Este tiempo es suficiente para permitir que se produzca una interrupción ampliada sin que se pierda el correo electrónico. Al usar la función de contenedor de transporte, se necesita espacio en disco adicional en el servidor de transporte de concentradores para hospedar las colas del contenedor de transporte. La cantidad de espacio de almacenamiento necesario es aproximadamente igual al valor de MaxDumpsterSizePerStorageGroup multiplicado por el número de grupos de almacenamiento en todos los servidores de buzones que usan la replicación continua en el sitio de Active Directory que contiene el servidor de transporte de concentradores.

Para obtener instrucciones detalladas acerca de cómo habilitar y configurar el volcado de archivos de transporte, consulte Cómo configurar el volcado de archivos de transporte.

Comprobación de la solución CCR

Tras completar la instalación de una solución de CCR o después de realizar cambios significativos en la configuración, se recomienda comprobar el estado y el mantenimiento del CMS, así como que ambos nodos estén configurados correctamente para ser compatibles con el CMS.

El modo recomendado para comprobar el estado y el mantenimiento del CMS es ejecutar los cmdlets Test-ReplicationHealth, Get-StorageGroupCopyStatus y Get-ClusteredMailboxServerStatus:

• El cmdlet Test-ReplicationHealth es novedad en Exchange 2007 SP1. Este cmdlet está diseñado para la supervisión proactiva de la replicación continua y el canal de replicación continua. El cmdlet Test-ReplicationHealth comprueba todos los aspectos de la replicación, los servicios de clúster y el estado de la replicación y reproducción del grupo de almacenamiento, con el fin de proporcionar una descripción completa del sistema de replicación. Para obtener más información acerca del cmdlet Test-ReplicationHealth, consulte Test-ReplicationHealth.

• El cmdlet Get-StorageGroupCopyStatus proporciona la información de replicación actual para cada grupo de almacenamiento. Para obtener instrucciones detalladas acerca de cómo ver el estado de los grupos de almacenamiento en un entorno de CCR, consulte Cómo ver el estado de una copia de la replicación continua de clústeres mediante el Shell de administración de Exchange.

• El cmdlet Get-ClusteredMailboxServerStatus proporciona el estado operativo básico para el CMS. Para obtener instrucciones detalladas acerca de cómo conseguir el estado operativo básico de un CMS, consulte Cómo ver el estado de un servidor de buzón en clústeres.

El mejor modo de comprobar que ambos nodos pueden poner en conexión el CMS es usar el cmdlet Move-ClusteredMailboxServer para mover el CMS a cada nodo. En Exchange 2007 SP1, también puede usar el Asistente para administrar el servidor de buzones de correo en clúster en la Consola de administración de Exchange para mover un servidor de buzones de correo en clúster entre nodos para comprobar que ambos nodos pueden conectarlo.