Alta disponibilidad y resistencia de sitios

Se aplica a: Exchange Server 2013

Puede proteger sus bases de datos de buzones de correo de Exchange Server 2013 y los datos que contienen configurando los servidores de buzones de correo y las bases de datos para que tengan alta disponibilidad y resistencia de sitios. Exchange 2013 minimiza el coste y la complejidad de la implementación de una solución de mensajería altamente disponible y resistente, al tiempo que proporciona mayores niveles de disponibilidad de servicio y datos, y admitir buzones de mayor tamaño.

Exchange 2013 permite a los clientes de todos los tamaños y segmentos implementar de manera económica un servicio de continuidad de mensajería en su organización mediante la integración de funcionalidades de replicación nativas y una arquitectura de alta disponibilidad disponibles por primera vez con Exchange 2010. Para obtener una lista de los cambios respecto a Exchange 2010 y Exchange 2007, vea Cambios en la alta disponibilidad y resistencia de sitios respecto a versiones anteriores.

Terminología básica

Los siguientes términos clave son importantes a la hora de entender qué es la alta disponibilidad o la resistencia de sitios:

• Active Manager: componente interno de Exchange que se ejecuta dentro del servicio de replicación de Microsoft Exchange que es responsable de la supervisión de errores y la acción correctiva a través de la conmutación por error dentro de un grupo de disponibilidad de base de datos (DAG).

• AutoDatabaseMountDial: valor de propiedad de un servidor de buzones de correo que determina si una copia pasiva de base de datos se montará automáticamente como la nueva copia activa, en función del número de archivos de registro que falta en la copia que se va a montar.

• Replicación continua: modo de bloque: en modo de bloque, a medida que cada actualización se escribe en el búfer de registro activo de la copia de base de datos activa, también se envía a un búfer de registro en cada una de las copias de buzón pasivo en modo de bloque. Cuando se llena el búfer de registro, cada copia de base de datos genera, inspecciona y crea el siguiente archivo de registro en la secuencia de generación.

• Replicación continua: modo de archivo: en el modo de archivo, los archivos de registro de transacciones cerradas se insertan desde la copia de base de datos activa en una o varias copias pasivas de la base de datos.

• Grupo de disponibilidad de base de datos: un grupo de hasta 16 servidores de buzones de Exchange 2013 que hospedan un conjunto de bases de datos replicadas.

• Movilidad de la base de datos: la capacidad de una base de datos de buzón de Exchange 2013 para replicarse y montarse en otros servidores de buzones de Exchange 2013.

• Datacenter: normalmente se refiere a un sitio de Active Directory; sin embargo, también puede hacer referencia a un sitio físico. En el contexto de esta documentación, el centro de datos equivale al sitio de Active Directory.

• Modo de coordinación de activación del centro de datos: propiedad de la configuración dag que, cuando está habilitada, obliga al servicio de replicación de Microsoft Exchange a adquirir permiso para montar bases de datos al iniciarse.

• Recuperación ante desastres: cualquier proceso que se use para recuperarse manualmente de un error. Puede tratarse de un error que afecta a un único elemento o a toda la ubicación física.

• API de replicación de terceros de Exchange: una API proporcionada por Exchange que permite el uso de la replicación sincrónica de terceros para un DAG en lugar de la replicación continua.

• Alta disponibilidad: solución que proporciona disponibilidad del servicio, disponibilidad de datos y recuperación automática de errores que afectan al servicio o a los datos (como una red, un almacenamiento o un error del servidor).

• Implementación incremental: la capacidad de implementar alta disponibilidad y resistencia del sitio después de instalar Exchange 2013.

• Copia de base de datos de buzón de correo con retraso: copia de base de datos de buzón pasivo que tiene un tiempo de retardo de reproducción de registros mayor que cero.

• Copia de base de datos de buzón de correo: una base de datos de buzón (archivo y registros .edb), que es activa o pasiva.

• Resistencia del buzón: nombre de una solución unificada de alta disponibilidad y resistencia del sitio en Exchange 2013.

• Disponibilidad administrada: un conjunto de procesos internos compuestos por sondeos, monitores y respondedores que incorporan supervisión y alta disponibilidad en todos los roles de servidor y todos los protocolos.

• *sobre (pronunciada "estrella por encima"): abreviatura para conmutaciones y conmutaciones por error. Un cambio consiste en la activación manual de una o varias copias de bases de datos. Una conmutación por error consiste en la activación automática de una o varias copias de bases de datos después de un error.

• Red de seguridad: anteriormente conocida como contenedor de transporte, esta es una característica del servicio de transporte que almacena una copia de todos los mensajes durante X días. La configuración predeterminada es 2 días.

• Redundancia de sombra: una característica de servidor de transporte que proporciona redundancia para los mensajes durante todo el tiempo que están en tránsito.

• Resistencia del sitio: configuración que extiende la infraestructura de mensajería a varios sitios de Active Directory para proporcionar continuidad operativa al sistema de mensajería en caso de que se produzca un error en uno de los sitios.

Grupos de disponibilidad de base de datos

Un DAG es el componente esencial del marco de alta disponibilidad y resistencia de sitios que hay integrado en Exchange 2013. Un DAG es un grupo de hasta 16 servidores de buzones de correo que hospeda un conjunto de bases de datos y proporciona recuperación automática en el nivel de la base de datos de los errores que afectan a los servidores, las redes o las bases de datos individuales. Cualquier servidor en un DAG puede hospedar una copia de una base de datos de buzones de correo de cualquier otro servidor en el DAG. Cuando se agrega un servidor a un DAG, funciona con otros servidores en el DAG para proporcionar recuperación automática de errores que afectan a las bases de datos de buzones de correo, como un error de disco o de servidor. Para obtener más información acerca de los DAG, vea Grupos de disponibilidad de base de datos (DAG).

Copias de bases de datos de buzones de correo

Las funciones de alta disponibilidad y de resistencia de sitios se presentaron por primera vez en Exchange 2010 y se usan en Exchange 2013 para crear y mantener copias de bases de datos. Exchange 2013 también aprovecha el concepto de movilidad de bases de datos, que es la conmutación por error en el nivel de la base de datos administrada por Exchange.

La movilidad de la base de datos desconecta las bases de datos de los servidores y agrega compatibilidad para un máximo de 16 copias de una sola base de datos. También proporciona una experiencia nativa para crear copias de una base de datos.

La configuración de una copia de base de datos como base de datos de buzón activa se conoce como cambio. Cuando se produce un error que afecta a una base de datos o al acceso a una base de datos y una nueva base de datos se convierte en la copia activa, este proceso se conoce como conmutación por error. Este proceso también hace referencia a un error de servidor en el que uno o más servidores conectan las bases de datos que el servidor con el error se encargaba de conectar anteriormente. Cuando se produce un cambio o una conmutación por error, otros servidores de Exchange 2013 perciben dicho cambio casi al instante y redirigen el tráfico de mensajería y cliente a la nueva base de datos activa.

Por ejemplo, si se produce un error en una base de datos activa de un DAG debido a un error de almacenamiento subyacente, Active Manager efectuará una recuperación automática conmutando por error a una copia de base de datos en otro servidor de buzones de correo del DAG. En Exchange 2013, la disponibilidad administrada agrega nuevos comportamientos para recuperarse de la pérdida de acceso de protocolos a una base de datos, incluido el reciclado de los grupos de procesos de trabajo de aplicaciones, el reinicio de servicios y servidores, y el inicio de conmutaciones por error de bases de datos.

Para obtener más información acerca de las copias de bases de datos de buzones de correo, vea Copias de bases de datos de buzones de correo.

Active Manager

Exchange 2013 aprovecha el componente de Active Manager presentado en Exchange 2010 para administrar la replicación continua y el estado de bases de datos, copias de bases de datos y otros aspectos de la alta disponibilidad de servidores de buzones de correo. Para obtener más información acerca de Active Manager, vea Active Manager.

Resistencia de sitios

Aunque en Exchange 2013 se siguen usando los DAG y los clústeres de conmutación por error de Windows para la resistencia de sitios y la alta disponibilidad del rol de servidor Buzones de correo, la resistencia de sitios no es igual en Exchange 2013. En Exchange 2013 la resistencia de sitios es mucho mejor porque se ha simplificado. Los cambios de arquitectura subyacentes que se efectuaron en Exchange 2013 tienen un impacto considerable en los aspectos de recuperación de una configuración de resistencia de sitios.

En Exchange 2010, la recuperación de buzones (DAG) y de acceso de cliente (matriz del servidor de acceso de cliente) se realizaba de manera conjunta. Si perdía todos los servidores de acceso de cliente, el VIP de la matriz o una parte importante del DAG, se enfrentaba a una situación en la que era necesario realizar un cambio de centro de datos. Este proceso está bien explicado y documentado, aunque conlleva bastante tiempo y requiere la intervención humana para poder iniciarse.

En Exchange 2013, si pierde la matriz de servidor de acceso de cliente por cualquier motivo (por ejemplo, se produce un error en el equilibrador de carga), no es necesario realizar un cambio de centro de datos. Con la configuración adecuada, la conmutación por error se produce en el nivel de cliente y los clientes se redirigen automáticamente a un segundo centro de datos que tiene servidores de acceso de cliente operativos, y los servidores de acceso de cliente operativos vuelven a enviar la comunicación al servidor de buzones del usuario, lo que no se ve afectado por la interrupción (porque no se realiza una conmutación por error). En lugar de trabajar para recuperar el servicio, el servicio se recupera y puede centrarse en corregir el problema principal (por ejemplo, reemplazar el equilibrador de carga con errores).

Además, gracias a la simplificación de los espacios de nombres, a la consolidación de los roles de servidor, al desacoplamiento de los requisitos de los roles del servidor del sitio de Active Directory, a la separación de la matriz del servidor de acceso de cliente y la recuperación de DAG y a los cambios en el equilibrio de cargas, Exchange 2013 incorpora algunos cambios que ahora permiten habilitar la recuperación tanto del servidor de acceso de cliente como de DAG para que sea independiente y automática entre los sitios, lo que proporciona escenarios de conmutación por error de centros de datos cuando hay tres ubicaciones.

En Exchange 2010, podría implementar un DAG en dos centros de datos y hospedar el testigo en una tercera base de datos para habilitar la conmutación por error para el rol de servidor Buzón de correo para cualquiera de los centros de datos. Sin embargo, no obtendría la conmutación por error para la solución, porque aún debería cargarse manualmente el espacio de nombres para los roles de los servidores que no sean Buzón de correo.

En Exchange 2013, no es necesario mover el espacio de nombres con el DAG. Exchange aprovecha la tolerancia a errores incorporada en el espacio de nombre mediante el equilibrio de cargas de varias direcciones IP (y, de ser necesario, la capacidad de poner a los servidores fuera de servicio y en funcionamiento). Los clientes HTTP modernos funcionan con esta redundancia de manera automática. La pila HTTP puede aceptar varias direcciones IP para un nombre de dominio completo (FQDN) y, si la primera dirección IP que prueba tiene un error permanente (es decir, no se puede conectar), probará con la próxima dirección IP en la lista. En los errores temporales (la conexión se pierde después de que se establece la sesión, quizás debido a un error intermitente en el servicio en el que, por ejemplo, un dispositivo deja paquetes y debe colocarse fuera de servicio), es posible que el usuario deba actualizar el explorador.

Esto significa que el espacio de nombres ya no es un punto único de error, como sucedía en Exchange 2010. En Exchange 2010, el mayor punto único de error en el sistema de mensajería es posiblemente el FQDN que se proporciona a los usuarios porque les dice dónde ir. En el paradigma de Exchange 2010, cambiar el destino al que el FQDN se dirige no es sencillo porque se debe cambiar el DNS y, luego, controlar la latencia de DNS, lo que, en algunas partes del mundo, representa todo un desafío. También se deben administrar las cachés de nombres en los exploradores, lo que suele tardar aproximadamente 30 minutos.

Uno de los cambios incluidos en Exchange 2013 consiste en habilitar los clientes para que tengan más de un sitio al que dirigirse. Si suponemos que un cliente tiene la capacidad de usar más de un lugar al que dirigirse (casi todos los protocolos de acceso de cliente de Exchange 2013 están basados en HTTP, como Outlook, Outlook en cualquier lugar, EAS, EWS, OWA y EAC, y todos los clientes HTTP admitidos tienen la capacidad de usar varias direcciones IP), la conmutación por error se proporciona en el lado del cliente. Puede configurar DNS para entregar varias direcciones IP a un cliente durante la resolución de nombres. El cliente solicita mail.contoso.com y obtiene, por ejemplo, dos o cuatro direcciones IP. Sin embargo, el cliente usará muchas de las direcciones IP que obtiene de forma confiable. Esto mejora mucho la situación del cliente ya que, si se produce un error en una de las direcciones IP, tiene una o más direcciones IP a las que intentar conectarse. Si el cliente prueba una y genera un error, espera unos 20 segundos y, a continuación, prueba la siguiente de la lista. Por tanto, si pierde el VIP de la matriz de servidor de acceso de cliente, los clientes se recuperan automáticamente en 21 segundos aproximadamente.

Algunas de las ventajas son las siguientes:

• En Exchange 2010, si perdía el equilibrador de carga en su centro de datos principal y no tenía otro en el sitio, debía hacer un cambio de centro de datos. En Exchange 2013, si pierde el equilibrador de carga en su centro de datos principal, simplemente, debe desconectarlo (o, quizás, desconectar el VIP) y repararlo o remplazarlo. Los clientes que aún no están usando el VIP en el centro de datos secundario realizarán una conmutación por error automática al VIP secundario sin cambiar el espacio de nombre ni realizar cambios en el DNS. Esto no solo significa que ya no deberá realizar un cambio, sino también que no volverá a perder el tiempo que normalmente perdía con la recuperación del cambio de un centro de datos. En Exchange 2010, debía controlar la latencia de DNS (por lo que se recomendaba establecer el Valor del período de vida (TTL) en 5 minutos, y la introducción de la URL de conmutación por recuperación). En Exchange 2013, esto no es necesario, gracias a la rápida conmutación por error (20 segundos) del espacio de nombre entre VIP (centros de datos).

• Dado que puede realizar la conmutación por error del espacio de nombre entre centros de datos, lo único que se necesita para lograr una conmutación por error del centro de datos es un mecanismo para la conmutación por error del rol del servidor Buzón de correo en centros de datos. Para obtener una conmutación por error automática para el DAG, simplemente cree una solución donde el DAG se divida en partes iguales entre dos centros de datos y, luego, coloque el servidor testigo en una tercera ubicación para que los miembros del DAG puedan arbitrarla en cualquier centro de datos, independientemente del estado de la red entre los centros de datos que contienen los miembros del DAG. Si solo tiene dos centros de datos y no dispone de una tercera la ubicación física, puede colocar el servidor testigo en una máquina virtual de Microsoft Azure. Vea Usar una máquina virtual de Microsoft Azure como un servidor testigo del DAG para más información.

• En este escenario, los esfuerzos del administrador se enfocan simplemente en solucionar el problema y no se desperdician restaurando el servicio. Simplemente, se arregla el error, mientras el servicio continúa funcionando y se mantiene la integridad de los datos. La urgencia y el nivel de estrés que se sienten cuando se arregla un dispositivo dañado no se comparan con la urgencia y el nivel de estrés que se sienten cuando se trabaja para restaurar el servicio. Es mejor para el usuario final y menos estresante para el administrador.

Puede permitir que se produzcan conmutaciones por error sin tener que realizar retrocesos (a veces denominados conmutaciones por recuperación de manera incorrecta). Si pierde los servidores de acceso de cliente en el centro de datos principal y, como consecuencia, se produce una interrupción de 20 segundos para los clientes, no es necesario que se preocupe por las conmutaciones por recuperación. En este caso, su principal preocupación sería solucionar el problema principal (por ejemplo, reemplazar el equilibrador de carga erróneo). Una vez que esté de nuevo en línea y en funcionamiento, algunos clientes empezarán a usarlo y otros pueden permanecer operativos en el segundo centro de datos.

Exchange 2013 también ofrece una funcionalidad que permite a los administradores manejar los errores intermitentes. Un error intermitente es aquel en el que, por ejemplo, se puede establecer la conexión TCP, pero no ocurre nada después. Los errores intermitentes requieren realizar algún tipo de acción administrativa adicional porque pueden derivarse de un dispositivo de reemplazo que se ha puesto en funcionamiento. Mientras se produce el proceso de reparación, el dispositivo puede estar encendido y aceptar algunas solicitudes, pero puede que no esté listo del todo para prestar servicio a los clientes hasta que se realicen los pasos de configuración necesarios. En esta situación, el administrador puede realizar un cambio de espacio de nombres con tan solo quitar el VIP del dispositivo que se va a reemplazar del DNS. De este modo, durante ese período de servicio, ningún cliente intentará conectarse a él. Después de completarse el proceso de reemplazo, el administrador puede volver a agregar el VIP al DNS y los clientes podrán empezar a usarlo.

Para obtener información sobre cómo planear e implementar la resistencia de sitios, vea Planificación de alta disponibilidad y resistencia de sitios y Implementación de alta disponibilidad y resistencia de sitios.

API de replicación de terceros

Exchange 2013 también incluye una API de replicación de terceros con la que las organizaciones pueden usar soluciones de replicación sincrónica de terceros en lugar de la característica integrada de replicación continua. Microsoft admite soluciones de otros fabricantes que usen esta API, siempre y cuando la solución aporte las funciones necesarias para reemplazar todas las características de replicación continua que se deshabilitan debido al uso de la API. Las soluciones se admiten únicamente si la API se usa con un DAG para administrar y activar copias de bases de datos de buzones de correo. No se admite el uso de la API fuera de estos límites. Además, la solución debe cumplir los requisitos aplicables de compatibilidad de hardware de Windows. (No se requiere la validación de la prueba para la compatibilidad).

Al implementar una solución que usa la replicación integrada de otros fabricantes, debe comprobarse que el proveedor de dicha solución sea el responsable principal de la compatibilidad de la solución. Microsoft admite datos de Exchange para soluciones replicadas y no replicadas. Las soluciones que usan la replicación de datos deben cumplir la directiva de soporte técnico de Microsoft para la replicación de datos. Además, las soluciones que usan el modelo de recurso de clúster de conmutación por error de Windows deben cumplir los requisitos de compatibilidad de clúster de Windows especificados en el artículo de Microsoft Knowledge Base 943984, Directiva de compatibilidad de Microsoft para clústeres de conmutación por error de Windows Server 2008 o Windows Server 2008 R2 o Directiva de compatibilidad de Microsoft para clústeres de conmutación por error de Windows Server 2012.

La directiva de compatibilidad de restauración y copia de seguridad de Microsoft para implementaciones que usan soluciones basadas en API de replicaciones de terceros es la misma que la aplicada en implementaciones de replicaciones continuas nativas.

Si es un socio y busca información sobre la API de replicación de terceros, póngase en contacto con su representante de Microsoft.

Documentación de alta disponibilidad y resistencia de sitios

En la siguiente tabla se incluyen vínculos a los temas que le proporcionarán más información acerca de cómo administrar DAG, sobre las copias de bases de datos de buzones de correo, copias de seguridad y restauración para Exchange 2013.