Instalación de replicación continua en clústeres
Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Última modificación del tema: 2007-10-30
Antes de implementar la replicación continua en clúster (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 un entorno de CCR en Windows Server 2003 se realiza en varias fases diferentes:
Configuración del hardware, empezando por la creación y configuración de la red de clústeres.
Formación del clúster, empezando por el primer nodo y siguiendo con el segundo.
Configuración y protección del testigo del recurso compartido de archivos, y configuración de las redes de clústeres y la tolerancia para los latidos de clúster no encontrados.
Instalación de las funciones activas y pasivas de servidor de buzones de correo en el clúster. El servidor de buzones de correo en clúster (CMS) se crea durante la instalación de la función del servidor Buzón de correo.
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.
También se deben llevar a cabo algunas tareas posteriores a la instalación del CMS:
Ajustar la configuración de control de la conmutación por error.
Ajustar la configuración predeterminada del volcado de archivos de transporte.
Comprobar la posibilidad de mover un servidor de buzones de correo en clúster entre los nodos del clúster.
Habilitar una o varias redes mixtas para el transporte y la inicialización de registros.
En las siguientes secciones se explica cada una de las fases de instalación de forma más detallada.
Formación y configuración de redes
Debe disponer de un número suficiente de direcciones IP estáticas al crear servidores de buzones de correo en clúster en una configuración de replicación continua en clúster de dos nodos. Las direcciones IP son necesarias para las redes públicas y privadas y todas las direcciones para cada red de clúster deben estar en la misma subred. Los requisitos relacionados con direcciones públicas y privadas son los siguientes:
Direcciones privadas Cada nodo requiere una dirección IP estática para cada adaptador de red que se utiliza en una red de clústeres privada. Debe usar direcciones IP estáticas 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 estática para cada adaptador de red que se utiliza en una red de clústeres pública. Además, se requieren direcciones IP estáticas para el clúster de conmutación tras error y el servidor de buzones de correo en clúster para que clientes y administradores puedan tener acceso a ellos. Debe usar direcciones IP estáticas que no estén en la misma subred o red que una de las redes privadas.
Prácticas recomendadas 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. Utilice 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, utilice mbx01, mbx01-node1 y mbx01-node2 para el servidor de buzones de correo en clúster y los dos nodos, respectivamente.
Utilice 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 pueden utilizarse para las interfaces de redes privadas, consulte la tabla siguiente.
Intervalos de direcciones y máscaras de subred para interfaces de red privadas
Red Intervalo de direcciones IP Máscara de subred Privada 1
10.10.10.10-255
255.255.255.0
Privada 2
10.10.10.11-255
255.255.255.0
Tenga en cuenta lo siguiente:
Si la red pública utiliza 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 recomendamos el uso de ningún tipo de adaptador tolerante a errores o Temporizador de la red privada. Si la red privada requiere redundancia, utilice varios adaptadores de red para establecerlos a una comunicación interna únicamente y definir su prioridad de red en la configuración del clúster. Es importante comprobar que la firma del fabricante y el controlador han pasado la última revisión si utiliza esta tecnología. Póngase en contacto con el fabricante de adaptadores de red para obtener información acerca de compatibilidad en un clúster de servidor. Para obtener más información acerca del temporizador del adaptador de red en las implementaciones de clúster de servidor, consulte el artículo 254101 de Microsoft Knowledge Base, temporizador del adaptador de red y clústeres de servidores (en inglés).
Para configurar las redes del clúster para su uso con una solución de replicación continua en clúster de MicrosoftExchange Server 2007, configure las redes públicas y privadas realizando los pasos siguientes que se describen en Cómo configurar las conexiones de red en una replicación continua en clústeres.
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 utiliza 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 utilizando las instrucciones que aparecen en Cómo crear un clúster de conmutación por error de Windows Server 2003 para la replicación continua en clúster. Este procedimiento contiene instrucciones para interfaz gráfica de usuario y para interfaz de línea de comandos para la formación del clúster de conmutación por error, la adición del segundo nodo a dicho clúster y la configuración del clúster para que use un quórum de Conjunto de nodos mayoritario (MNS).
Nota
La CCR en Windows Server 2003 requiere un modelo de quórum denominado quórum de MNS con testigo del recurso compartido de archivos. Este modelo de quórum está disponible en Windows Server 2003 Service Pack 2 (SP2), que es necesario para Exchange 2007 Service Pack 1 (SP1). Para usar el quórum de MNS con testigo del recurso compartido de archivos con la versión RTM de Exchange 2007 y Windows Server 2003 SP1, debe instalar una revisión en cada nodo antes de implementar la CCR. La revisión se describe en el artículo 921181 de Knowledge Base, Está disponible una actualización que agrega una característica de testimonio compartido de archivo y una característica de latidos configurables agrupados para clústeres de servidores basados en Microsoft Windows Server 2003 Service Pack 1 (en inglés). Para obtener información detallada sobre cómo instalar la revisión, consulte Cómo instalar la característica de testigo de recurso compartido de archivos del conjunto de nodos mayoritario.
Configuración posterior a la instalación del clúster de conmutación por error
Una vez que el clúster de conmutación por error se ha formado y se ha configurado con un quórum de MNS, es necesario realizar ciertas tareas antes de instalar Exchange en cualquiera de los nodos. Debe configurar las redes de clúster, la tolerancia para los latidos de clúster no encontrados y el componente de testigo del recurso compartido de archivos del quórum de MNS.
Configuración de las redes de clúster
Una vez agregados los dos nodos al clúster, se configurarán los componentes de red del clúster. De forma específica, deben configurarse las redes de clúster, la prioridad de las redes de cluster y la configuración de la tolerancia para latidos de clúster no encontrados. En la tabla siguiente se detallan las opciones disponibles para configurar redes de clúster.
Opciones para configurar redes de clúster
| Opción | Descripción |
|---|---|
Sólo acceso de clientes (red pública) |
Seleccione esta opción si desea que el servicio de Cluster Server utilice este adaptador de red sólo para la comunicación externa con otros clientes. No se producirá tráfico de comunicación entre nodos ni de actualización de bases de datos de clúster en este adaptador de red. |
Sólo comunicaciones internas del clúster (red privada) |
Seleccione esta opción si desea que el servicio de clúster use exclusivamente esta red para el tráfico de comunicación entre nodos y la actualización de bases de datos de clúster. |
Todas las comunicaciones (red mixta) |
Seleccione esta opción si desea que el servicio de clúster use el adaptador red para el tráfico de comunicación entre nodos del clúster y la actualización de bases de datos de clúster, así como para la comunicación con clientes externos. Esta opción está elegida de forma predeterminada para todas las redes. |
Los CMS implementados en un entorno CCR requieren al menos dos tarjetas de red en ambos nodos para que sean compatibles. En un entorno CCR, se recomienda configurar una red como red privada y configurar la otra red como mixta. Si se configura una red como red privada y la otra red se configura como pública, entonces la red privada representa un error puntual para el CMS.
Para obtener los pasos detallados sobre cómo configurar los componentes de red del clúster, consulte Cómo configurar los componentes de red del clúster y la prioridad.
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 los dos nodos para que admitan diez latidos no encontrados. Este nivel de configuración corresponde a aproximadamente 12 segundos.
Para obtener los pasos detallados sobre cómo configurar la tolerancia del servicio de clúster para latidos no encontrados, consulte How to Configure Tolerance Settings for Missed Cluster Heartbeats.
Configuración de un testigo de recurso compartido de archivos
Después de formar y configurar un clúster, deberá configurarse el testigo de recurso compartido de archivos. La CCR emplea el testigo de recurso compartido de archivos en un tercer equipo para evitar que se produzca una partición de la red dentro del clúster, lo que se conoce también como síndrome de cerebro dividido. El síndrome de cerebro dividido ocurre en un entorno de CCR cuando:
Se produce un error en todas los redes designadas para transportar las comunicaciones internas del clúster.
Ninguno de los dos nodos puede recibir las señales de latido entre ellos.
Ambos nodos se convierten en el nodo activo poniendo o intentando poner en conexión el CMS.
El recurso compartido de archivos puede hospedarse en cualquier servidor que funcione con el sistema operativo Microsoft Windows. Sin embargo, se recomienda utilizar un servidor de transporte de concentradores en el sitio del servicio de directorio de Active Directory que contenga los nodos de clúster para hospedarlo. Se recomienda un servidor de transporte de concentradores para garantizar a un administrador de Exchange la autoridad y el control plenos sobre el recurso compartido. Para obtener información detallada sobre cómo configurar el recurso compartido de archivos como testigo de recurso compartido de archivos, consulte Cómo configurar el testigo del uso compartido de archivos.
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 realizando 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 utilizar el quórum de MNS con el testigo de recurso compartido de archivos, deberá instalar la función del servidor Buzón de correo en el nodo activo. El proceso de instalación del nodo activo instala la función del servidor Buzón de correo en el nodo y, a continuación, crea un CMS en el nodo.
Para obtener los pasos detallados sobre 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 de correo en clúster activo en un entorno CCR en Windows Server 2003.
Nota
Si va a instalar el nodo activo en un equipo en que se ejecuta Windows Server 2003 que no está en el mismo sitio de Active Directory que el controlador de dominio con la función de controlador de dominio principal (PDC), primero debe crear una cuenta de equipo con el nombre que piense usar para el CMS. La cuenta de equipo debe estar habilitada y el objeto de equipo debe estar disponible en el sitio de Active Directory local. Si no existe una cuenta de equipo para el CMS y el PDC no está en el sitio de Active Directory local, el programa de instalación se detendrá.
Una vez instalada la función del servidor Buzón de correo en el nodo activo, le recomendamos que compruebe que la configuración de la primera base de datos del grupo de almacenamiento y los registros de transacciones es la que deseaba. Puede que deba moverlas antes de continuar con el segundo nodo. De forma predeterminada, el grupo de almacenamiento inicial y la base de datos se ubican en %Archivos de programa%\Microsoft\Exchange Server\Mailbox\First Storage Group.
Para obtener los pasos detallados sobre cómo configurar el primer grupo de almacenamiento de un clúster, consulte Cómo mover un grupo de almacenamiento y su base de datos (en inglés).
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. El proceso de instalación del nodo pasivo instala la función del servidor Buzón de correo en el nodo pasivo. Para instrucciones detalladas sobre 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 2003.
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:
Ajustar la configuración de control de la conmutación por error.
Ajustar la configuración predeterminada del volcado de archivos de transporte.
Comprobar la posibilidad de mover un servidor de buzones de correo en clúster entre los nodos del clúster.
Permitir varias redes para una actividad de replicación continua.
Ajuste de la configuración de control de la 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), Good Availability (Buena disponibilidad) y Best Availability (Disponibilidad óptima). Lossless tiene un valor cero de pérdida de registros, el valor de Good Availability es de tres y Best Availability tiene el valor predeterminado seis. Al configurar el sistema para Good Availability o Best Availability, no utilice espacios. Por ejemplo, utilice GoodAvailability y BestAvailability.
Algoritmo 2 El algoritmo 2 permite determinar si, con datos antiguos, es más importante estar en línea o sin conexión. Si el montaje de la base de datos basado en el algoritmo 1 falla, 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 de grupo de almacenamiento está retrasada 1, 10 o 1.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.
Para obtener más información acerca de la configuración de la conmutación por error, consulte Cómo ajustar la configuración de la conmutación por error y el montaje para la replicación continua de clústeres.
Ajuste del volcado de archivos de transporte
El contenedor de transporte es una característica de la función del servidor Transporte de concentradores que envía el correo entregado recientemente tras una interrupción no programada. El volcado de archivos de transporte deberá activarse siempre cuando se utilice la replicación continua en clúster (CCR) o local (LCR). 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. El almacén de información elimina automáticamente los duplicados y reenvía el correo perdido. Puede utilizar la Consola de administración de Exchange o el cmdlet Set-TransportConfig del Shell de administración de Exchange para cambiar los ajustes de configuración predeterminados para el volcado de archivos de transporte, que se aplican al nivel de grupo de almacenamiento.
Se recomienda configurar el parámetro MaxDumpsterSizePerStorageGroup, que especifica el tamaño máximo de la cola del contenedor de transporte para cada grupo de almacenamiento, en un tamaño que sea 1,5 veces el tamaño de mensaje máximo que puede enviarse. 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. También se recomienda configurar el parámetro MaxDumpsterTime, que especifica cuánto tiempo deberá permanecer un mensaje de correo electrónico en la cola de volcado de archivos de transporte, en un valor de 7.00:00:00, que significa siete días. Este es un tiempo suficiente para que se produzca una interrupción ampliada sin pérdida de mensajes de correo electrónico. Al utilizar la característica de volcado de archivos de transporte, se necesita espacio adicional en el disco del servidor de transporte de concentradores para hospedar las colas de volcado de archivos 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 CMS en un entorno de CCR y todos los grupos de almacenamiento con replicación continua local habilitados en el sitio de Active Directory que contiene el servidor de transporte de concentradores.
Para obtener instrucciones detalladas sobre 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 Get-StorageGroupCopyStatus y Get-ClusteredMailboxServerStatus:
El cmdlet Get-StorageGroupCopyStatus proporciona la información de replicación actual para cada grupo de almacenamiento. Para obtener instrucciones detalladas sobre 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 información detallada sobre 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 utilizar el cmdlet Move-ClusteredMailboxServer para mover el CMS a cada nodo.
Permitir varias redes para una Actividad de replicación continua.
En la versión RTM de Exchange 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 redundante 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 trasporte de registros.
En Exchange 2007 SP1, sólo las redes de clúster designadas como mixtas pueden habilitarse 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úster configuradas para el acceso de clústeres, pero no para el acceso de clientes (algunas veces denominadas redes privadas) no pueden habilitarse para la replicación continua.
La admisión del transporte de registros a través de una red mixta se configura mediante el cmdlet 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 satisfactoria y después de confirmar que la red mixta está operativa.
Para obtener los pasos detallados 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 2003.
Nota
Además del nombre de host, la dirección IP y el grupo de clúster que se crea en el clúster de conmutación por errores, cada vez que ejecuta el cmdlet Enable-ContinuousReplicationHostName, se crea también una cuenta de equipo en el dominio Active Directory que contiene el CMS. De forma predeterminada, en Windows Server 2003, el número máximo de cuentas de equipo que puede agregar un usuario que no tenga delegados los privilegios de administrador de dominio y al que no se hayan concedido las entradas de control de acceso (ACE) Crear objetos de equipo y Eliminar objetos de equipo es 10. Un administrador de Exchange que ejecute con frecuencia los cmdlets Enable-ContinuousReplicationHostName y Disable-ContinuousReplicationHostName y no tenga privilegios de administrador de dominio o las ACE anteriores puede alcanzar rápidamente el límite de cuenta de 10. Existen dos soluciones alternativas para este problema, que aparecen documentadas en el artículo 307532 de Knowledge Base, Cómo solucionar problemas de la cuenta del Servicio de Cluster Server cuando modifica objetos de equipo. Para obtener más información, consulte el artículo 251335 de Knowledge Base, Los usuarios de dominio no pueden unir la estación de trabajo o el servidor a un dominio.
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á utilizarse 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.