Implementación de alta disponibilidad y resistencia de sitio

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2015-03-09

Para crear un servidor de buzones de alta disponibilidad utilizando versiones anteriores de Exchange, se solía instalar Exchange en un servidor que estuviera configurado como miembro de un clúster de conmutación de Microsoft Windows. Si se deseaba un servidor de buzones de alta disponibilidad, era necesario desarrollar y configurar el clúster antes de ejecutar el programa de instalación de Exchange. El programa de instalación de Exchange (y otros componentes de Exchange, como el almacén de Exchange y el servicio Operador de sistema de Microsoft Exchange) era compatible con clústeres y, por lo tanto, funcionaba de manera diferente a cuando se lo ejecutaba en un servidor autónomo. Si Exchange ya estaba instalado en un servidor autónomo de Windows, no se podía configurar ese servidor para que contara con alta disponibilidad sin antes quitar Exchange, desarrollar un clúster y, a continuación, reinstalar Exchange con la versión compatible con clústeres del programa de instalación.

Microsoft Exchange Server 2010 utiliza, tanto para la alta disponibilidad como para la resistencia de sitio, un concepto conocido como implementación incremental. A diferencia de las versiones anteriores, Exchange 2010 ya no usa el modelo de recurso de clúster para tener una alta disponibilidad. Como consecuencia de este cambio en la arquitectura, ya no existe una versión compatible con clústeres del programa de instalación y la alta disponibilidad no se configura durante el proceso de instalación. En cambio, simplemente se instalan todos los servidores Exchange 2010 como servidores independientes, y luego se configuran de forma incremental los servidores de buzón y las bases de datos de buzón para que haya una alta disponibilidad y resistencia de sitios según sea necesario.

Introducción al proceso de implementación

Si bien los pasos concretos que cada organización utiliza pueden variar levemente, el proceso general de implementación de Exchange 2010 en una configuración de alta disponibilidad o de sitio resistente, es generalmente el mismo. Después de llevar a cabo la planeación y las tareas de diseño necesarias para desarrollar e implementar un grupo de disponibilidad de base de datos (DAG) y crear copias de bases de datos de buzones de correo, es necesario:

1. Crear un DAG. Para obtener instrucciones detalladas, consulte Crear un grupo de disponibilidad de la base de datos.

2. Si es necesario, preconfigure el objeto de nombre de clúster (CNO). Se requiere la preconfiguración de CNO al implementar un DAG con servidores de buzones que ejecutan Windows Server 2012. La preconfiguración también se requiere en entornos donde la creación de cuentas de equipo se encuentra restringida o donde las cuentas se crean en un contenedor que no es el predeterminado. Para conocer los pasos detallados, consulte Ensayo del objeto de nombre de clúster para un grupo de disponibilidad de base de datos.

3. Agregar dos o más servidores de buzones al DAG. Para obtener instrucciones detalladas, consulte Administrar pertenencia al grupo de disponibilidad de la base de datos.

4. Configurar las propiedades del DAG según sea necesario:

   1. De manera opcional, configure el cifrado y la compresión del DAG, el puerto de replicación, las direcciones IP del DAG y otras propiedades. Para obtener instrucciones detalladas, consulte Configurar las propiedades del grupo de disponibilidad de la base de datos.

   2. Si el DAG contiene al menos tres servidores de buzones implementados en varios sitios de Active Directory, se debe habilitar el modo coordinación de activación de centros de datos (DAC). Para obtener más información, consulte Descripción del modo de coordinación de activación de centros de datos.

   3. Para obtener instrucciones detalladas acerca de cómo crear una red de grupo de disponibilidad de base de datos, consulte Crear una red de grupo de disponibilidad de la base de datos. Para administrar una red del DAG, consulte Configurar las propiedades de la red del grupo de disponibilidad de la base de datos.

5. Agregar copias de la base de datos de buzones de correo en todos los servidores de buzones del DAG. Para obtener instrucciones detalladas, consulte Agregar una copia de la base de datos de buzones.

Ejemplo de implementación: DAG de cuatro miembros en dos centros de datos

En este ejemplo, se describe cómo la organización Contoso Ltd. configura e implementa un DAG de cuatro miembros que se extenderá a través de dos ubicaciones físicas: un centro de datos principal denominado Active Directory SITEA y un segundo centro de datos, denominado Active Directory SITEB. SITEA está ubicado en Redmond, Washington, EE. UU. y SITEB en Dublín, Irlanda.

Infraestructura de base

Cada ubicación contiene los elementos de infraestructura necesarios para operar una infraestructura de mensajería basada en Exchange 2010, a saber:

• Servicios de directorio (Active Directory o Servicios de dominio de Active Directory (AD DS))

• Resolución de nombres del Sistema de nombres de dominio (DNS)

• Al menos un servidor de acceso de cliente de Exchange 2010

• Uno o más servidores de transporte de concentradores de Exchange 2010

• Al menos un servidor de buzones de Exchange 2010

En la siguiente figura, se ilustra la configuración de Contoso.

Grupo de disponibilidad de base de datos extendido en dos sitios

A excepción de los servidores de buzones, todos los servidores del entorno Contoso están ejecutando el sistema operativo Windows Server 2008 R2 Standard. Los servidores de buzones, que se planificaron teniendo en cuenta a los DAG, ejecutan Windows Server 2008 R2 Enterprise.

Además de los componentes de infraestructura mencionados, cada ubicación tiene otros elementos de mensajería, como servidores de transporte perimetral y mensajería unificada.

Configuración de red

Tal como se ilustra en la figura anterior, la solución involucra el uso de varias subredes y redes. Cada servidor de buzones del DAG tiene dos adaptadores de red en subredes diferentes. En cada servidor de buzones, uno de los adaptadores de red se utilizará para la red MAPI (192.168.x.x) y el otro para la red de replicación (10.0.x.x). Sólo la red MAPI proporciona conectividad a Active Directory, a los servicios DNS y a otros servidores y clientes de Exchange. El adaptador utilizado para la red de replicación de cada miembro proporciona conectividad solamente a los adaptadores de red de replicación de los otros miembros del DAG.

En la siguiente tabla se detalla la configuración de todos los adaptadores de red de cada nodo.

Como se muestra en la tabla anterior, los adaptadores utilizados para las redes de replicación no utilizan puertas de enlace predeterminadas. Para brindar conectividad de red entre cada uno de los adaptadores de red de replicación, Contoso usa rutas estáticas persistentes, que se configuran mediante la herramienta Netsh.exe. Netsh.exe es una herramienta que se puede usar para configurar y supervisar los equipos basados en Windows en la ventana del símbolo del sistema. Con la herramienta Netsh.exe, se pueden dirigir los comandos contextuales ingresados en la aplicación auxiliar apropiada, y la aplicación auxiliar luego lleva a cabo el comando. La aplicación auxiliar es un archivo de biblioteca de vínculos dinámicos (.dll) que extiende la funcionalidad de la herramienta Netsh.exe al brindar configuración, control y soporte de uno o más servicios, utilidades o protocolos.

Para configurar el enrutamiento de los adaptadores de red de replicación en MBX1A y MBX2A se ejecutó el siguiente comando en cada servidor.

netsh interface ipv4 add route 10.0.2.0/24 <NetworkName> 10.0.1.254

Para configurar el enrutamiento de los adaptadores de red de replicación en MBX1B y MBX2B se ejecutó el siguiente comando en cada servidor.

netsh interface ipv4 add route 10.0.1.0/24 <NetworkName> 10.0.2.254

También se han configurado los siguientes parámetros de red adicionales:

• La casilla de verificación Registrar estas direcciones de conexiones en DNS se selecciona para cada adaptador de red MAPI del miembro DAG y se la destilda para cada adaptador de red de replicación.

• Al menos una dirección de servidor DNS está configurada para cada adaptador de red MAPI del miembro DAG y ninguna está configurada para los adaptadores de red de replicación. Para conseguir redundancia, Contoso utiliza múltiples direcciones de servidor DNS en los adaptadores de red MAPI.

• Contoso no utiliza IPv6 y deshabilitó el protocolo en sus servidores.

• Además, no utiliza Firewall de Windows, y está desactivado en los servidores.

Después de configurar los adaptadores de red, Contoso está listo para crear un DAG y agregarle los servidores de buzones.

Creación y configuración de grupos de disponibilidad de base de datos

El administrador ha decidido crear un script de interfaz de línea de comandos de Windows PowerShell que realiza varias tareas:

• Utiliza el cmdlet New-DatabaseAvailabilityGroup para crear el DAG. Dado que SITEA se considera el centro de datos principal, Contoso decidió utilizar un servidor testigo en el mismo centro de datos, HUB-A.

• Utiliza el cmdlet Set-DatabaseAvailabilityGroup para preconfigurar un servidor testigo alternativo y un directorio testigo alternativo en caso de que sea necesaria una conmutación de sitio.

• Utiliza el cmdlet Add-DatabaseAvailabilityGroupServer para agregar cada uno de los cuatro servidores de buzones al DAG.

• Utiliza el cmdlet Set-DatabaseAvailabilityGroup para configurar el DAG en el modo DAC. Para obtener más información acerca del modo DAC, consulte Descripción del modo de coordinación de activación de centros de datos.

Los comandos utilizados en el script son:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer HUB-A -WitnessDirectory C:\DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8

El comando anterior crea un DAG llamado DAG1, configura el servidor Hub-A para que actúe como servidor testigo, configura un directorio testigo específico (C:\DAGWitness\DAG1.contoso.com) y configura dos direcciones IP para el DAG (una para cada subred de la red MAPI).

Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer HUB-B

El comando anterior configura el grupo DAG1 para que utilice Hub-B como servidor testigo alternativo y un directorio testigo alternativo en Hub-B que usa la misma ruta de acceso que se configuró en Hub-A.

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1B
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2B

Los comandos anteriores agregan cada uno de los servidores de buzones, uno por vez, al DAG. Los comandos también instalan el componente de clúster de conmutación por error de Windows en cada servidor de buzones (si no está ya instalado), crean una agrupación en clústeres de conmutación por error de Windows y vinculan cada servidor de buzones al clúster recién creado.

Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

El comando anterior habilita el modo DAC para el DAG.

Bases de datos de buzones de correo y copias

Después de crear el DAG y agregar los servidores de buzones al DAG, Contoso se prepara para crear bases de datos de buzones de correo y copias de éstas. Para cumplir con su criterio de resistencia a errores, Contoso está planeando configurar cada base de datos de buzones de correo con tres copias de bases de datos no atrasadas y una copia de base de datos atrasada. La copia atrasada tendrá configurado un retraso de la reproducción del registro de tres días.

Esta configuración proporciona un total de cuatro copias para cada base de datos (una activa, dos pasivas no atrasadas y una pasiva atrasada). Contoso planea tener cuatro bases de datos activas por servidor. Con cuatro bases de datos activas por servidor y tres copias pasivas de cada base de datos, la solución de Contoso contiene un total de 16 copias de bases de datos.

Como se muestra en la figura siguiente, Contoso tiene un diseño equilibrado de sus bases de datos.

Diseño de la copia de base de datos de Contoso, Ltd

Cada servidor de buzones hospeda una copia de base de datos de buzones de correo, dos copias pasivas no atrasadas y una copia pasiva atrasada. La copia atrasada de cada base de datos de buzones de correo activa se hospeda en un servidor de buzones del otro sitio.

Para crear esta configuración, el administrador ejecuta varios comandos.

En MBX1A, ejecute los comandos siguientes.

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX1B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -SuspendComment "Seed from MBX2B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX1B -SourceServer MBX2B
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -ActivationOnly

En MBX2A, ejecute los comandos siguientes.

Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX2B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -SuspendComment "Seed from MBX1B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX2B -SourceServer MBX1B
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -ActivationOnly

En MBX1B, ejecute los comandos siguientes.

Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -SuspendComment "Seed from MBX2A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1A -SourceServer MBX2A
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -ActivationOnly

En MBX2B, ejecute los comandos siguientes.

Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -SuspendComment "Seed from MBX1A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2A -SourceServer MBX1A
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -ActivationOnly

En los ejemplos anteriores para el cmdlet Add-MailboxDatabaseCopy, no se ha especificado el parámetro ActivationPreference. La tarea incrementa el número de preferencia de activación automáticamente con cada copia que se agrega. La base de datos original siempre tiene un número de preferencia 1. A la primera copia agregada con el cmdlet Add-MailboxDatabaseCopy se le asigna automáticamente el número de preferencia 2. Siempre y cuando no se quiten copias, la siguiente copia agregada recibirá el número de preferencia 3, y así sucesivamente. Por lo tanto, en los ejemplos anteriores, la copia pasiva en el mismo centro de datos que la copia activa tiene un número de preferencia de activación 2, la copia pasiva no atrasada en el centro de datos remoto tiene un número de preferencia de activación 3 y la copia pasiva atrasada en el centro de datos remoto tiene un número de preferencia de activación 4.

Si bien hay dos copias de cada base de datos activa a través de la WAN de la otra ubicación, la propagación sobre la WAN sólo se llevó a cabo una vez. Esto se debe a que Contoso está aprovechando la capacidad de Exchange 2010 de utilizar una copia pasiva de base de datos como fuente para la propagación. El uso del cmdlet Add-MailboxDatabaseCopy con el parámetro SeedingPostponed evita que la tarea propague automáticamente la nueva copia de base de datos creada. Así, el administrador puede suspender la copia no propagada y, mediante el uso del cmdlet Update-MailboxDatabaseCopy con el parámetro SourceServer, puede especificar la copia local de la base de datos como fuente de la operación de propagación. Como resultado, la propagación de la segunda copia de la base de datos agregada a cada ubicación se realiza localmente y no sobre la WAN.

Contoso ha configurado una de las copias pasivas de cada base de datos de buzones de correo como copia atrasada, para proporcionar una protección contra el inusual pero catastrófico caso de que se produzcan daños lógicos en la base de datos. Por lo tanto, el administrador configura las copias atrasadas con activación bloqueada mediante el uso del cmdlet Suspend-MailboxDatabaseCopy con el parámetro ActivationOnly. Esto asegura que las copias de la base de datos atrasadas no se activen si se produce un error de base de datos o servidor.

Validación de la solución

Después de implementar y configurar la solución, el administrador lleva a cabo varias acciones que validan la preparación del sistema, antes de mover los buzones de producción a las bases de datos del DAG. Se debe someter la solución a varios métodos de prueba e inspección, incluida la simulación de errores. Para validar la solución, el administrador realiza varias tareas.

Para comprobar el mantenimiento global del DAG, el administrador ejecuta el cmdlet Test-ReplicationHealth. Este cmdlet comprueba varios aspectos del estado de la replicación y la reproducción, para proporcionar información acerca de los servidores de buzones y la copia de base de datos del DAG.

Para comprobar la actividad de replicación y reproducción, el administrador ejecuta el cmdlet Get-MailboxDatabaseCopyStatus. Este cmdlet puede proporcionar información de estado en tiempo real acerca de una copia de base de datos de buzones de correo específica ubicada en un servidor específico. Para obtener más información acerca de cómo supervisar el mantenimiento y el estado de las bases de datos replicadas de un DAG, consulte Supervisión de la alta disponibilidad y la resistencia de sitios.

Para comprobar que los cambios funcionen como está previsto, el administrador utiliza el cmdlet Move-ActiveMailboxDatabase para realizar una serie de cambios de base de datos y de servidor. Una vez que estas tareas se completan con éxito, el administrador utiliza el mismo cmdlet para devolver las copias de base de datos activas a sus ubicaciones originales.

Para comprobar el comportamiento esperado en varios escenarios de error, el administrador realiza varias tareas que simulan errores o los causan realmente. Por ejemplo, el administrador puede:

• Desconectar el cable de alimentación en MBX1A, lo que desencadena una conmutación por error de un servidor. Luego, el administrador comprueba que DB1 se active en otro servidor (preferentemente MBX2A, de acuerdo con los valores de preferencia de activación).

• Desconectar el cable de red del adaptador de red MAPI de MBX2A, desencadenando una conmutación por error de servidor. Luego, el administrador comprueba que DB2 se active en otro servidor (preferentemente MBX1A, de acuerdo con los valores de preferencia de activación).

• Desconectar el disco utilizado por la copia activa de DB3, desencadenando una conmutación por error de base de datos. Luego, el administrador comprueba que DB3 se active en otro servidor (preferentemente MBX2B, de acuerdo con los valores de preferencia de activación).

Es posible que la organización compruebe otros escenarios de conmutación por error, de acuerdo con las necesidades de la empresa. Después de simular un error individual (como desenchufar el cable de alimentación) y comprobar el comportamiento de recuperación de la solución, el administrador puede volverla a su configuración original. En algunos casos, se puede probar la solución para varios errores simultáneos. En última instancia, el plan de pruebas creado para la solución determinará si se la devuelve a su configuración original después de cada simulación de error realizada.

De manera adicional, un administrador puede decidir interrumpir la conexión de red entre los dos centros de datos, simulando así un error en el sitio. La realización de un cambio de centros de datos es un proceso mucho más complejo y coordinado; no obstante, si la solución implementada se diseñó para proporcionar resistencia de sitio a los servicios y datos de mensajería, se recomienda llevarlo a cabo. Para obtener información detallada acerca de cambios de centros de datos, consulte Cambios en el centro de datos.

Transición a operaciones

Una vez implementada la solución, se la puede extender aún más mediante una implementación incremental. En este punto, la administración de la solución también realiza una transición a procesos de operación, en los que se llevan a cabo las siguientes tareas:

• Supervisión del mantenimiento y el estado de los DAG y las copias de la base de datos de buzones de correo. Para obtener más información, consulte Supervisión de la alta disponibilidad y la resistencia de sitios.

• Realización de cambios de base de datos y servidor según sea necesario. Para obtener instrucciones detalladas acerca de cómo realizar una conmutación de base de datos, consulte Activar una copia de la base de datos de buzones. Para obtener instrucciones detalladas acerca de cómo realizar una conmutación de servidor, consulte Realizar un cambio de servidor. Si es necesario, inicie un cambio de centros de datos. Para obtener más información acerca de las conmutaciones de centros de datos, consulte Cambios en el centro de datos.

Para obtener más información acerca de la administración de la solución, consulte Administración de la alta disponibilidad y la resistencia de sitios.

 © 2010 Microsoft Corporation. Reservados todos los derechos.