Replicación continua en espera: Fiabilidad de sitios con clúster en espera

  • Artículo

 

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

Última modificación del tema: 2008-11-18

En este tema se ofrecen detalles de cómo una organización, Contoso, Ltd., utiliza replicación continua en espera (SCR) en un escenario de fiabilidad de sitios. En esta situación, se produce un error en el centro de datos principal y Contoso, Ltd. toma la decisión de activar el centro de datos secundario. Después de activar el centro de datos secundario, se reconfigura el centro de datos principal y, finalmente, se restaura como centro de datos principal en un conmutador controlado. Contoso, Ltd. tiene dos centros de datos: un centro de datos principal denominado Active Directory SITEA y un segundo centro de datos de copias de seguridad, denominado Active Directory SITEB. SITEA está ubicado en Portland, Oregón y SITEB en San José, California.

SITEA contiene los siguientes componentes de la infraestructura:

  • Servidor de directorios, DC1, que también proporciona servicios de Sistema de nombres de dominio seguro e integrado en Active Directory.

  • Servidor de acceso de cliente, CAS1

  • Servidor transporte de concentradores, HUB1

  • Servidor de buzones de correo en clúster, EXCMS1, que se ejecuta en un clúster de copia única de dos nodos (SCC), EXCLUS1 y contiene NODEA y NODEB. Tenga en cuenta lo siguiente:

    • Los nodos del clúster de conmutación por error se ejecutan en el sistema operativo Windows Server 2008 y el clúster de conmutación por error está configurado con un quórum de nodos y discos mayoritarios.

    • El valor de período de vida (TTL) de DNS para el recurso del nombre de red del servidor de buzones de correo en clúster se configura para cinco minutos. Para configurarlo se ejecutó el siguiente comando, deteniendo e iniciando el servidor de buzones de correo en clúster.

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300

      Nota

      La propiedad HostRecordTTL sólo está disponible en los clústeres de conmutación por error que ejecutan Windows Server 2008. Este comando no se puede usar en los clústeres de conmutación por error que se ejecutan en el sistema operativo Windows Server 2003.

SITEB contiene los siguientes componentes de la infraestructura:

  • Servidor de directorios, DC2, que también proporciona servicios de Sistema de nombres de dominio seguro e integrado en Active Directory.

  • Servidor de acceso de cliente, CAS2

  • Servidor transporte de concentradores, HUB2

  • Clúster de un solo nodo, DRCLUS1, que se usará como clúster de conmutación por error en espera. Tenga en cuenta lo siguiente:

    • El nodo de este clúster, NODEC, es el único nodo del clúster de conmutación por error en espera y ejecuta Windows Server 2008. El clúster de conmutación por error en espera se configura con un quórum de nodos mayoritarios.

      Nota

      En los clústeres de conmutación por error que ejecutan Windows Server 2003, el clúster de conmutación por error en espera de un solo nodo se puede configurar con un quórum local.

    • El servidor de buzones pasivo se instala en NODEC utilizando la misma ruta de instalación que EXCLUS1. Esto es necesario para poder realizar una recuperación de servidor con Setup /RecoverCMS, como parte del proceso de activación de destino SCR. Para usar el proceso de recuperación de servidor, la ruta de instalación de Exchange Server debe ser igual para el equipo de origen y el equipo de destino de SCR. Si Exchange Server está instalado en %Archivos de programa%\Microsoft\Exchange Server en el equipo de origen de SCR, también se debe instalar en %Archivos de programa%\Microsoft\Exchange Server en todos los equipos que vayan a ser destino de SCR para el servidor de origen de SCR. Si estas rutas no coinciden, el proceso de recuperación de servidor será incorrecto porque la ruta de instalación del Registro no coincidirá con el valor del atributo msExchInstallPath del objeto de servidor de buzones de Active Directory.

    • Mediante el complemento Usuarios y equipos de Active Directory, la cuenta del equipo para DRCLUS1 se configura con permisos completos en el objeto de equipo EXCMS1. Esto se lleva a cabo para que la cuenta del equipo para EXCMS1 se pueda restablecer mediante DRCLUS1 en caso de que se active SITEB debido a un error de SITEA.

      Nota

      Este paso sólo se usa en clústeres de conmutación por error que ejecuten Windows Server 2008. Esto se debe a que el servicio de clúster se ejecuta en el contexto de seguridad del sistema local. Este paso no es necesario en los clústeres de conmutación por error que ejecutan Windows Server 2003 cuando se usa la misma cuenta de servicio de clúster para ambos clústeres de conmutación por error.

Todos los servicios de los dos sitios de Active Directory están configurados para usar servidores de DNS integrados en Active Directory. El intervalo de replicación de Active Directory para los dos sitios de Active Directory se configura para 15 minutos.

SCR se configura de modo que los archivos de registro de transacciones se repliquen desde tres grupos de almacenamiento de EXCMS1 en destinos de SCR en NODEC. Para la configuración se usaron los siguientes comandos:

Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC

Nota

Para habilitar simultáneamente todos los grupos de almacenamiento en EXCMS1 para SCR, ejecute el siguiente comando: Get-StorageGroup -Server EXCMS1 | Enable-StorageGroupCopy -StandbyMachine NODEC

El estado y el mantenimiento de SCR en cada grupo de almacenamiento se comprobaron mediante los cmdlets Test-ReplicationHealth y Get-StorageGroupCopyStatus del Shell de administración de Exchange. Por ejemplo:

Get-StorageGroupCopyStatus EXCMS1\SG1 -StandbyMachine NODEC

Se ha comprobado que los movimientos del servidor de buzones de correo en clúster han funcionado como se esperaba, así como las copias de seguridad y el truncamiento de registros.

Error del sitio principal y activación del sitio de copia de seguridad

De repente y sin previo aviso, se produce un importante terremoto en Portland. Aunque nadie ha sufrido lesiones graves, se han producido muchos daños en el SITEA, ya que ha sido necesario desconectar servicios públicos muy importantes, como energía eléctrica, agua y gas natural. Dado que pueden transcurrir varios meses hasta que Contoso, Ltd. vuelva a usar SITEA, se toma la decisión de realizar una activación manual de SITEB y proporcionar todos los servicios y los datos de mensajería desde este sitio.

La activación de SITEB comienza con la comprobación de los servicios de directorio y la resolución de DNS. Dado que SITEB contiene un servidor de directorio que también hospeda DNS integrado en Active Directory, se considera que estos servicios son correctos, actuales y no se han visto afectados por la interrupción de SITEA. Después de comprobar los servicios de directorio y DNS, el paso siguiente consiste en activar los destinos de SCR y realizar una recuperación del servidor de buzones de correo en clúster. Para hacerlo, siga los pasos siguientes en orden.

  1. El Shell de administración de Exchange se abre en NODEC, y se ejecutan los siguientes comandos para preparar el montaje de los destinos de SCR.

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Force
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Force

    Importante

    Siempre se debe especificar el parámetro Force cuando el origen de SCR no está disponible.

    Nota

    Una alternativa a la ejecución de tres comandos Restore-StorageGroupCopy independientes que se muestra en el paso 1 es usar de un nuevo script incluido en Microsoft Exchange Server 2007 Service Pack 1 (SP1) denominado GetSCRSources.ps1 y canalizar la salida del script hacia una única tarea Restore-StorageGroupCopy, como se indica a continuación: GetSCRSources | Restore-StorageGroupCopy -StandbyMachine $env:ComputerName -Force

  2. Use el complemento Administración de DNS para quitar el registro existente de DNS para EXCMS1 desde DNS.

    Nota

    Este paso sólo se usa en clústeres de conmutación por error que ejecuten Windows Server 2008. Esto se debe a que el servicio de clúster se ejecuta en el contexto de seguridad del sistema local. Este paso no es necesario en los clústeres de conmutación por error que ejecutan Windows Server 2003 cuando se usa la misma cuenta de servicio de clúster para ambos clústeres de conmutación por error.

  3. SCR está deshabilitada para todos los grupos de almacenamiento con el objeto de preparar el proceso /RecoverCMS. Si SCR no está deshabilitada para todos los grupos de almacenamiento, Setup /RecoverCMS da error. Puede deshabilitar SCR con los siguientes comandos:

    Disable-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEC -Confirm:$False
Disable-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEC -Confirm:$False

  4. El servidor de buzones de correo en clúster (EXCMS1) se recupera con el uso de la opción /RecoverCMS para el programa de instalación. La recuperación tiene lugar en NODEC mediante el uso del siguiente comando:

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    Tenga en cuenta lo siguiente:

    • El valor de CMSIPAddress del comando anterior podría ser una dirección IP diferencia de la original para EXCMS1. Esto se debe a que EXCMS1 se está recuperando fuera del sitio. Es decir, estaba hospedado originalmente en SITEA y se está recuperando en SITEB.

    • Setup /RecoverCMS finalizará correctamente después de que se haya producido la replicación de DNS y se haya vaciado la memoria caché DNS (NODEC) del servidor de recuperación. Si se produce un error en el programa de instalación, deberá usar NSLookup desde el controlador de dominio principal (PDC) y desde NODEC para comprobar que la dirección IP correcta se resuelve en NODEC y, a continuación, volver a ejecutar el programa de instalación después de la comprobación.

    • En los clústeres de conmutación por error que ejecuten Windows Server 2003, el objeto de equipo para EXCMS1 se reinicia durante el procesoSetup /RecoverCMS. Es necesario que este reinicio se replique en el sitio local de Active Directory para que el programa de instalación finalice correctamente. Si el PDC no se encuentra en el sitio local de Active Directory, asegúrese de que haya vínculos del sitio de Active Directory en funcionamiento entre el PDC y el sitio local de Active Directory.

    • Una vez que se haya completado el proceso de recuperación del programa de instalación, se habrá recuperado EXCMS1 en SITEB y estará hospedado en NODEC, en un SCC de un solo nodo denominado DRCLUS1.

    • Como resultado de la operación de recuperación del servidor de buzones de correo en clúster, el TTL del DNS para EXCMS1 ha vuelto a tener el valor predeterminado de 20 minutos. Se debe volver a configurar en cinco minutos mediante la ejecución del siguiente comando y, a continuación, detener e iniciar el servidor de buzones de correo en clúster.

      Cluster.exe res EXCMS1 /priv HostRecordTTL=300

  5. A continuación, las bases de datos de los tres grupos de almacenamiento se montarán mediante la tarea Mount-Database.

  6. En este escenario, no es necesario realizar una operación de recuperación para otras funciones del servidor (en concreto, Acceso de cliente y Transporte de concentradores) porque CAS2 y HUB2 ya existen en SITEB.

    Nota

    Como parte de la operación de recuperación para el servidor de acceso de cliente, es necesario reconfigurar la dirección URL externa para que señale a los servidores Acceso de cliente de SITEB.

    Nota

    En este ejemplo de escenario no se incluye la recuperación de servidores de transporte perimetral. Si existían servidores de transporte perimetral en SITEA y también se perdieron durante el error del sitio, será necesario conectar nuevos servidores de transporte perimetral en SITEB y actualizar los registros del intercambiador de correo electrónico (MX) de DNS para los dominios del Protocolo simple de transferencia de correo (SMTP) de Contoso, para que señalen los nuevos servidores de transporte perimetral.

  7. Si la organización de Contoso incluye sitios adicionales de Active Directory, los mensajes se pondrán en cola en el sitio principal de Active Directory. Una vez que la información de pertenencia al sitio para EXCMS1 se haya replicado en todos los demás sitios de Active Directory, las colas de SMTP que contengan mensajes destinados al sitio principal se podrán reintentar manualmente. (Si no se realiza ningún reintento manual, el motor de transporte reintentará la cola automáticamente la cola después de 12 horas.) Esto volverá a clasificar los mensajes. Una vez que los mensajes se hayan vuelto a clasificar, se entregarán a EXCMS1 en SITEB.

En este momento, siempre que los servidores de DNS utilizados por clientes y otros servidores tengan la dirección IP correcta para EXCMS1, todos los clientes podrán obtener acceso a sus buzones mediante los métodos de acceso originales (por ejemplo, Microsoft Outlook Web Access, Exchange ActiveSync y Microsoft Office Outlook).

Reconfiguración del sitio principal

Dado que ahora el sitio secundario (SITEB) está actuando como centro de datos principal, se debe reconfigurar el centro de datos principal original (SITEA) para que los servicios que están hospedados ahora en SITEB no entren en conflicto con los servicios conectados, una vez que SITEA se vaya a activar para usarlo nuevamente. SITEA se debe conectar de un modo controlado por el administrador, realizando los pasos siguientes:

  1. En primer lugar conecte los servicios de directorio y de resolución de nombres DNS y, para ello, conecte DC1.

  2. Cuando DC1 esté conectado, conecte CAS1 y HUB1.

    Tenga en cuenta que cuando se haya conectado HUB1, un administrador deberá comprobar que se hayan entregado todos los mensajes de las colas. Si existen mensajes bloqueados en las colas, se podrán enviar nuevamente con el siguiente comando.

    Retry-queue [queue name] -Resubmit $True

  3. Conecte los nodos en los que se hospede el clúster EXCLUS1. En este escenario, NODEA se conectará en primer lugar, y después NODEB.

  4. Cuando los dos nodos estén conectados, el servidor de buzones de correo en clúster seguirá en estado de desconexión. Esto incluye todos los recursos que forman el servidor de buzones de correo en clúster, sobre todo el recurso Nombre de red. Este recurso no se puede activar porque EXCMS1 ya está activado y utiliza el mismo nombre de red. Si se conectara EXCMS1 en NODEA o NODEB se produciría una colisión de nombres en la red.

  5. En el nodo al que pertenece actualmente el grupo de recursos que contiene el servidor de buzones de correo en clúster, un administrador debe borrar el servidor de buzones de correo en clúster y sus recursos del clúster de conmutación por error. Para ello, el administrador primero quita cualquier recurso que no sea de Exchange del grupo de clúster que contiene el servidor de buzón en clúster. A continuación, el administrador ejecuta el siguiente comando en NODEA:

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

    Tenga en cuenta lo siguiente:

    • Después de que el servidor de buzones de correo en clúster y sus recursos se han borrado de EXCLUS1, se recomienda usar el Administrador de clústeres o el complemento Administración del clúster por conmutación de error para comprobar que se han quitado todos los recursos del servidor de buzones de correo en clúster.

    • Ahora EXCLUS1 es un clúster de conmutación por error con dos nodos pasivos, NODEA y NODEB, cada uno de los cuales tiene instalada la función del servidor Buzón de correo pasiva. En este momento, no hay ningún servidor de buzones de correo en clúster en EXCLUS1.

  6. Dado que los nodos del clúster ejecutan Windows Server 2008, después de ejecutar Setup /ClearLocalCMS se deshabilitará el objeto del equipo virtual (VCO). Para volver a habilitar el VCO, haga clic en Inicio, Todos los programas, Herramientas administrativas y, a continuación, en Usuarios y equipos de Active Directory. Expanda el dominio, expanda Equipos, haga clic con el botón secundario en EXCMS1 VCO y, a continuación, haga clic en Habilitar cuenta.

  7. Para prepararse para un conmutador controlado de SITEB a SITEA, NODEA se convertirá en un destino de SCR para los grupos de almacenamiento hospedados en EXCMS1, en SITEB. Esto se lleva a cabo mediante los siguientes comandos en NODEC:

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEA
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEA

    Nota

    Si el almacenamiento utilizado por el clúster de conmutación por error original no se ha visto afectado por el error de SITEA y las bases de datos originales y sus registros de transacciones para los tres grupos de almacenamiento todavía existen en NODEA, será posible usarlos para fines de replicación continua sin necesidad de realizar una reproducción completa de cada grupo de almacenamiento en NODEA. Si los archivos existentes no se pueden usar, o si el registro circular se hubiera configurado para el servidor de buzones de correo en clúster original, se deberá realizar una reproducción completa de cada grupo de almacenamiento mediante la ejecución del cmdlet Update-StorageGroupCopy.

En este escenario se usa un SCC como ejemplo. Si el escenario de recuperación utiliza un servidor de buzones de correo en clúster en un entorno de replicación continua en clúster (CCR), se recomienda un paso adicional en el que el nodo pasivo también está preparado para el conmutador controlado mediante su preparación con las bases de datos y los archivos de registro. Este paso se realiza exclusivamente para fines de optimización con el objetivo de eliminar la necesidad de reproducir los grupos de almacenamiento pasivo después de que el entorno CCR se haya devuelto a SITEA. Esta tarea se realiza mediante uno de estos dos métodos:

  • Suspensión de la replicación continua para los tres destinos de SCR y copia de los archivos y las bases de datos del grupo de almacenamiento de NODEA a las ubicaciones apropiadas de NODEB.

  • Habilitación de NODEB como destino de SCR de EXCMS1.

Conmutador controlado para sitio principal original

Una vez que SITEA haya sido aprobado para su uso, se podrá realizar una conmutación manual y controlada de datos y servicios de SITEB a SITEA. Los pasos que se realizan para realizar la conmutación controlada son los inversos a los que se realizaron para activar SITEB:

  1. El primer paso consiste en desmontar todas las bases de datos de EXCMS1. Esto se realiza para detener la generación del archivo de registro de transacciones para activación de los destinos de SCR en NODEA. Las bases de datos se pueden desmontar con la Consola de administración de Exchange o el cmdlet Dismount-Database del Shell de administración de Exchange.

  2. En NODEA, un administrador prepara todos los grupos de almacenamiento para montaje. Esta tarea se realiza mediante la ejecución de los siguientes comandos:

    Restore-StorageGroupCopy -Identity EXCMS1\SG1 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG2 -StandbyMachine NODEA
Restore-StorageGroupCopy -Identity EXCMS1\SG3 -StandbyMachine NODEA

    Tenga en cuenta lo siguiente:

    • En los tres comandos anteriores, no se usa el parámetro Force porque el servidor de origen de SCR está disponible. Dado que no se usa el parámetro Force, la tarea intenta copiar automáticamente todos los archivos de registro del origen de SCR.

    • Una vez que se haya completado cada tarea, el administrador deberá comprobar que todos los archivos de registro de cada grupo de almacenamiento se hayan copiado en NODEA y que se haya deshabilitado SCR.

    • Si se ha configurado NODEB como destino de SCR, será necesario deshabilitar y restaurar antes de continuar. En este escenario, se recomienda ejecutar Restore-StorageGroupCopy en primer lugar en NODEB y, a continuación, en NODEA, y después ejecutar Setup /RecoverCMS en NODEA.

  3. El servidor de buzones de correo en clúster (EXCMS1) de DRCLUS1 se debe detener. Esta tarea se debe realizar desde NODEC con el Asistente para administrar servidores de buzones de correo en clúster de la Consola de administración de Exchange o con el cmdlet Stop-ClusteredMailboxServer del Shell de administración de Exchange.

  4. El registro A de EXCMS1 se debe quitar de DNS mediante el complemento Administración de DNS.

    Nota

    Sólo es necesario quitar el registro A de EXCMS1 cuando el clúster de conmutación por error se está ejecutando en Windows Server 2008. Si se está ejecutando en Windows Server 2003, no es necesario realizar este paso.

  5. El servidor de buzones de correo en clúster (EXCMS1) se recupera con el uso de la opción /RecoverCMS para el programa de instalación. La recuperación tiene lugar en NODEA mediante el uso del siguiente comando:

    Setup.com /RecoverCMS /CMSName:EXCMS1 /CMSIPAddress:<IPAddress>

    Tenga en cuenta lo siguiente:

    • El valor CMSIPAddress en el comando anterior puede ser la dirección IP original para EXCMS1. Esto se debe a que EXCLUS1 se está recuperando en su ubicación original.

    • Una vez que se haya completado el proceso de recuperación del programa de instalación, se habrá recuperado EXCMS1 en SITEA y estará hospedado en NODEA, en un SCC de un solo nodo denominado EXCLUS1.

    Nota

    Nuevamente, en este escenario se usa un SCC como ejemplo. Si el escenario de recuperación utiliza un servidor de buzones de correo en clúster en un entorno de CCR, es posible que sea necesario realizar pasos adicionales. La operación /RecoverCMS suspende la replicación continua, en este caso, de NODEA a NODEB. Un administrador debe ejecutar Resume-StorageGroupCopy para que los grupos de almacenamiento vuelvan a establecer actividades de replicación y reproducción. A continuación, el administrador debe comprobar que se ha reanudado la actividad de replicación. Si la preparación de NODEB, de acuerdo con la descripción anterior, no es correcta, será necesario volver a reproducir las copias pasivas de los grupos de almacenamiento.

    • Como resultado de la operación de recuperación del servidor de buzones de correo en clúster, el TTL del DNS para EXCMS1 ha vuelto a tener el valor predeterminado de 20 minutos. Se debe volver a configurar en cinco minutos mediante la ejecución del siguiente comando y, a continuación, detener e iniciar el servidor de buzones de correo en clúster:

      Cluster.exe res "Network Name (EXCMS1)" /priv HostRecordTTL=300

  6. Las bases de datos de los tres grupos de almacenamiento se montarán mediante el cmdlet Mount-Database.

  7. En este escenario, no es necesario realizar una operación de recuperación para otras funciones del servidor (como Acceso de cliente y Transporte de concentradores) porque CAS1 y HUB1 ya existen en SITEA.

    Nota

    Como parte de la operación de recuperación para el servidor de acceso de cliente, es necesario reconfigurar la dirección URL externa para que señale a los servidores Acceso de cliente de SITEA.

    Nota

    En este ejemplo de escenario no se incluye la recuperación de servidores de transporte perimetral. Si se usan servidores de transporte perimetral, será necesario actualizar los registros DNS del intercambiador de correo (MX) para los dominios SMTP de Contoso para que señalen a los servidores correctos de transporte perimetral.

  8. Si la organización de Contoso incluye sitios adicionales de Active Directory, los mensajes se pondrán en cola en el sitio principal de Active Directory. Una vez que la información de pertenencia al sitio para EXCMS1 se haya replicado en todos los demás sitios de Active Directory, las colas de SMTP que contengan mensajes destinados al sitio principal se podrán reintentar manualmente. (Si no se realiza ningún reintento manual, el motor de transporte reintentará la cola automáticamente la cola después de 12 horas.) Esto volverá a clasificar los mensajes. Una vez que los mensajes se hayan vuelto a clasificar, se entregarán a EXCMS1 en SITEA.

  9. En este momento, siempre que los servidores de DNS utilizados por clientes y otros servidores tengan la dirección IP correcta para EXCMS1, todos los clientes podrán obtener acceso a sus buzones mediante los métodos de acceso originales (por ejemplo, Outlook Web Access, Exchange ActiveSync y Outlook). Además, después de que se hayan replicado los cambios de DNS en SITEB y de que se haya replicado la pertenencia al sitio de EXCMS1, los servidores de transporte perimetral enrutarán mensajes al sitio correcto de Active Directory. Un administrador también puede forzar manualmente el reenvío de mensajes que pueden estar en cualquier cola de HUB1 o HUB2. Esta tarea se puede realizar mediante la ejecución del siguiente comando:

    Retry-queue [queue name] -Resubmit $True

Reconfiguración del sitio de copia de seguridad

Una vez que se haya completado una conmutación manual y controlada de SITEB a SITEA, SITEB podrá volver a su estado operativo como centro de datos de copia de seguridad. Esto incluye el borrado del servidor de buzones de correo en clúster en espera del clúster de conmutación por error de SITEB y la rehabilitación de NODEC como destino de SCR para los tres grupos de almacenamiento de EXCMS1. Para hacerlo, siga los pasos siguientes en orden.

  1. Durante la conmutación controlada, el servidor de buzones de correo en clúster que se ejecuta en DRCLUS1, en SITEB, se detuvo para que se pudiera conectar a EXCLUS1 en SITEA. Después de volver a poner en producción EXCMS1 correctamente en EXCLUS1, es necesario quitar su información de configuración de DRCLUS1. La información de la configuración se puede borrar, y EXCMS1 se puede quitar por completo de DRCLUS1, si se quita cualquier recurso que no sea de Exchange del grupo de clúster que contenga el servidor de buzón en clúster y, a continuación, se ejecuta el siguiente comando:

    Setup.com /ClearLocalCMS /CMSName:EXCMS1

  2. Dado que los nodos del clúster ejecutan Windows Server 2008, después de ejecutar Setup /ClearLocalCMS se deshabilitará el VCO. Para volver a habilitar el VCO, haga clic en Inicio, Todos los programas, Herramientas administrativas y, a continuación, en Usuarios y equipos de Active Directory. Expanda el dominio, expanda Equipos, haga clic con el botón secundario en EXCMS1 VCO y, a continuación, haga clic en Habilitar cuenta.

  3. Después de que el servidor de buzones de correo en clúster y sus recursos se han borrado de DRCLUS1, un administrador debe usar el Administrador de clústeres o el complemento Administración del clúster por conmutación de error para comprobar que se han quitado todos los recursos del servidor de buzones de correo en clúster.

  4. SCR se configura de modo que los archivos de registro de transacciones se repliquen desde tres grupos de almacenamiento de EXCMS1 en destinos de SCR en NODEC. Para la configuración se usan los siguientes comandos:

    Enable-StorageGroupCopy EXCMS1\SG1 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG2 -StandbyMachine NODEC
Enable-StorageGroupCopy EXCMS1\SG3 -StandbyMachine NODEC

    Nota

    Antes de habilitar SCR para replicar los grupos de almacenamiento desde EXCMS1 a NODEC, se debe asegurar de que no existan conflictos de grupos de almacenamiento ni de rutas de base de datos. También debe asegurarse de que se hayan quitado de las rutas de acceso originales todos los grupos de almacenamiento y archivos de base de datos antiguos o innecesarios.

  5. A continuación, el estado y el mantenimiento de SCR en cada grupo de almacenamiento se comprueban mediante los cmdlets Test-ReplicationHealth y Get-StorageGroupCopyStatus. También se debe comprobar el funcionamiento correcto de los movimientos del servidor de buzones de correo en clúster entre los nodos, así como las operaciones de copia de seguridad y truncamiento de registros. Una vez que se hayan completado todas las comprobaciones, el centro de datos principal y el secundario volverá a los modos de funcionamiento originales de acuerdo con el sistema de mensajería de Exchange 2007.