Site Resilience Configurations

 

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-29

En los últimos años, cada vez más empresas han reconocido que la mensajería es esencial para su éxito. En muchas organizaciones, el sistema de envío de mensajes debe formar parte de los planes de continuidad del negocio, y la resistencia de sitios debe integrarse en la implementación del servicio de mensajería. Numerosas soluciones de resistencia de sitios implican la instalación de hardware de copia de seguridad en un segundo centro de datos, lo que suele provocar las siguientes cuestiones básicas:

  • ¿Qué nivel de servicio es necesario en caso de error del centro de datos principal?

  • ¿Necesitan los usuarios los datos, o únicamente los servicios de mensajería?

  • ¿Con qué rapidez se requieren los datos?

  • ¿A cuántos usuarios hay que admitir?

  • ¿Cómo tendrán acceso los usuarios a sus datos?

  • ¿Cuál es el acuerdo de nivel de servicio (SLA) para la activación del centro de datos en espera?

  • ¿Cómo se traslada de nuevo el servicio al centro de datos principal?

  • ¿Están dedicados los recursos a la solución de resistencia de sitios?

Respondiendo a estas preguntas, da comienzo el diseño de la solución de mensajería de resistencia de sitios. Uno de los requisitos fundamentales para la recuperación de errores en sitios es crear una solución que envíe los datos de mensajería necesarios a un centro de datos de copias de seguridad que hospede el servicio de mensajería.

En este tema se proporciona información acerca de varias configuraciones de resistencia de sitio para la versión RTM Microsoft Exchange Server 2007 y Exchange 2007 Service Pack 1 (SP1). Antes de empezar a evaluar estas soluciones, es recomendable familiarizarse con los siguientes términos:

  • Clúster extendido   También denominado clúster geográficamente disperso; se trata de una configuración de clúster en la que hay nodos del clúster en más de un centro de datos.

  • Portabilidad de bases de datos   Tarea administrativa que permite cambiar el destino de los buzones a un servidor distinto cuando se traslada su base de datos host.

  • Sitio de Active Directory extendido   Sitio de servicio de directorio de Active Directory que contiene equipos de más de un centro de datos (por ejemplo, un sitio de Active Directory que abarca varias ubicaciones físicas).

  • Pertenencia a sitio de Active Directory   Miembro de un sitio de Active Directory específico basado en la dirección IP principal del equipo. Al cambiar la dirección IP o el sitio de Active Directory que contiene esa dirección IP, se cambia la pertenencia al sitio de Active Directory del equipo.

  • Centro de datos de producción   Centro de datos que hospeda los servidores activos de un servicio y su infraestructura asociada.

  • Centro de datos de copias de seguridad activo   Centro de datos de copias de seguridad que está preparado de forma inmediata para asumir la propiedad del servicio y seguir proporcionándolo. Para ejecutar el servicio en esta ubicación no se requiere una configuración especial.

  • Centro de datos de copias de seguridad semiactivo   Centro de datos de copias de seguridad que tiene servidores disponibles para asumir la propiedad del servicio y seguir proporcionándolo. La activación del servicio en este centro de datos requiere una intervención manual.

  • Centro de datos de copias de seguridad en frío   Centro de datos de copias de seguridad con la capacidad y la infraestructura potencial para asumir la propiedad del servicio. Antes de que el servicio se encuentre operativo en este centro de datos, se requiere un esfuerzo significativo.

  • Dedicados   Servidores asignados en exclusiva a los usuarios del centro de datos principal.

  • No dedicados   Servidores que admiten a los usuarios del centro de datos principal y a usuarios de otras ubicaciones.

Los términos como producción, semiactivo y dedicado pueden combinarse para describir una implementación de resistencia de sitios. Por ejemplo, un centro de datos de producción respaldado por un centro de datos de copias de seguridad, dedicado y configurado en su mayor parte, se podría llamar Producción: Semiactivo (Dedicado).

Funciones que admiten la creación de una solución de resistencia de sitios

Exchange 2007 dispone de varias características que se pueden usar como piezas para construir una solución de resistencia de sitios. Son las siguientes:

  • Clústeres extendidos, que se pueden usar para la replicación de datos o para simplificar la activación del centro de datos de copias de seguridad.

  • Portabilidad de bases de datos, que se puede utilizar para activar los datos replicados.

  • Sitios Active Directory extendidos, que se pueden usar como apoyo de los clústeres extendidos o para habilitar un centro de datos de copias de seguridad.

  • El cambio de la pertenencia a un sitio de Active Directory de un equipo, que se puede realizar como parte de la activación de un centro de datos de copias de seguridad.

  • Copias de seguridad regulares en cinta almacenadas fuera del sitio, que se pueden utilizar para recuperar los datos de los buzones en el centro de datos de copias de seguridad.

Asimismo, otros fabricantes ofrecen productos para la replicación de datos, que se pueden emplear para la transferencia a un centro de datos de copias de seguridad. Estos productos se pueden usar junto con servidores independientes, clústeres de recuperación o un clúster de copia única extendido (SCC). En estas configuraciones, los datos del servidor o clúster principal se replican en un segundo servidor o configuración de clúster situado en otro centro de datos. En caso de error del sitio, el clúster o servidor del segundo centro de datos se activa de forma manual.

Exchange 2007 SP1 incorpora una nueva característica denominada replicación continua en espera (SCR), diseñada específicamente para escenarios de resistencia de sitios. Como su mismo nombre indica, está diseñada para casos en los que se usa o permite el uso de replicación continua en espera. SCR amplía las características de replicación continua que se encontraban en Exchange 2007 RTM y permite nuevos escenarios de disponibilidad de datos para servidores de buzón de correo que ejecuten Exchange 2007 SP1. SCR usa la misma tecnología para el envío y la reproducción de registros que se usa para la replicación continua local (LCR) y la replicación continua en clúster (CCR), con el fin de proporcionar configuraciones y opciones adicionales de implementación.

La SCR permite una separación de alta disponibilidad (integrada por disponibilidad de datos y de servicio) y la resistencia del sitio. Por ejemplo, SCR se puede combinar con CCR para replicar grupos de almacenamiento de manera local en un centro de datos principal (con CCR para alta disponibilidad), y de manera remota en un centro de datos secundario o de copia de seguridad (con SCR para resistencia del sitio). El centro de datos secundario podría contener un nodo pasivo en un clúster de conmutación por error que hospeda los destinos para SCR. Este tipo de clúster se conoce como clúster en espera, porque no contiene servidores de buzones de correo en clúster, sino que se puede proveer rápidamente con un servidor de buzones de correo en clúster de sustitución en un escenario de recuperación. Si el centro de datos principal produce un error o se pierde por algún otro motivo, los destinos para SCR hospedados en este clúster en espera se pueden activar rápidamente.

Para obtener más información acerca de SCR, consulte Replicación continua en espera.

Soluciones para obtener resistencia de sitios

Una organización tiene diversas posibilidades en cuanto a soluciones de resistencia de sitios. En el resto de este tema se ofrece información acerca de las soluciones de resistencia de sitios siguientes:

  • Producción: En frío (Dedicado)

  • Producción: Semiactivo (Dedicado)

  • Producción: Semiactivo (No dedicado) con dos sitios de Active Directory

  • Producción: Producción (No dedicado) con un sitio de Active Directory

En las soluciones que se describen en este tema se supone que se ha perdido la totalidad de la infraestructura de mensajería cuando el centro de datos de producción produce un error. El centro de datos de copias de seguridad debe disponer de conexión a Internet y de todos los servicios necesarios para hospedar Exchange. Además, sus procesos de activación deben estar incluidos en un script y se deben probar con regularidad.

Producción: En frío (Dedicado)

La solución de resistencia de sitios de mensajería más básica consiste en que la organización posee contratos para el hardware y las instalaciones, pero no tiene un centro de datos de copias de seguridad activo. Regularmente, se realizan copias de seguridad de todos los datos de los buzones, que se guardan fuera del sitio. Los datos de Active Directory se controlan de forma similar. La activación de la solución de resistencia de sitios requiere adquirir e implementar el hardware. Para reducir el tiempo total de interrupción del servicio, la organización puede disponer de contratos de entrega rápida con los proveedores de los principales elementos de hardware.

Una variación de esta solución es establecer una relación con un proveedor de recuperación ante desastres que disponga de un almacén de hardware propio. Este tipo de relación permite mantener los datos de copias de seguridad en la ubicación del proveedor para reducir el tiempo de recuperación. El almacenamiento dedicado en la ubicación del proveedor puede ser los destinos de replicación de los datos de buzones y Active Directory.

Por simplicidad, lo más probable es que las configuraciones que vayan a ser implementadas acaben siendo similares al entorno de producción o a una parte del mismo. Durante un proceso de recuperación, lo mejor es trabajar con una tecnología y unas instalaciones que resulten tan familiares como sea posible.

Producción: Semiactivo (Dedicado)

En el modelo de recuperación Producción: Semiactivo (Dedicado), el centro de datos de producción tiene asignado un centro de datos de copias de seguridad con equipos dedicados. Los equipos dedicados se utilizan cuando no se puede disponer del centro de datos de producción. Como ya se ha mencionado, el centro de datos de copias de seguridad no se activa automáticamente. El administrador debe activarlo de forma manual. La activación reconfigura el equipo de copias de seguridad y la infraestructura dedicados para proporcionar del suministro del servicio de mensajería. En la figura siguiente se muestra una configuración Producción: Semiactivo (Dedicado).

Ejemplo de una implementación de Producción: Semiactivo (Dedicado)

Producción:Implementación templada (dedicada)

En la figura anterior se muestra el centro de datos de producción (A) que hospeda las funciones de los servidores Transporte perimetral, Transporte de concentradores, Acceso de cliente y Buzón de correo. El centro de datos de copias de seguridad semiactivo (B) tiene servidores de copias de seguridad dedicados para cada función y para Active Directory. En la figura se muestra que la redundancia simple se utiliza para todas las funciones de servidor salvo la de Buzón. La redundancia del servidor Buzón la controla un clúster o una configuración de servidor en espera con una solución de replicación adecuada.

Las posibles soluciones de redundancia de buzón son:

  • Replicación continua en clúster (CCR) en una configuración de clúster extendido   CCR utiliza el trasvase de registros para crear y administrar una segunda copia de los datos de buzón. De este modo, el clúster de dos nodos de CCR tiene un nodo en cada centro de datos. Con esta configuración, el servicio de clúster Windows requiere subredes extendidas entre ambas ubicaciones. Mediante el clúster extendido, el servidor de buzones de correo en clúster puede realizar una conmutación por error con sólo volver a registrar la dirección IP que tiene asignada en el nodo del otro centro de datos.

  • Clúster de copia única (SCC) con replicación asincrónica en asociado   Con la replicación en asociado, el sistema dispone de dos copias de los datos del servidor de buzones. Como en el caso de CCR, se requiere una subred extendida para poder efectuar la conmutación por error del clúster.

  • Clúster en espera con replicación en asociado   Los datos del buzón se replican en un segundo clúster en el centro de datos de de copias de seguridad, y se utiliza el proceso de recuperación ante desastres del servidor para restablecer el servicio. La replicación puede ser sincrónica o asincrónica. Los clústeres no son necesarios, ni se requiere una subred extendida.

  • Servidor en espera con replicación en asociado   Los datos del buzón se replican en un segundo servidor en el centro de datos de copias de seguridad, y se utiliza el proceso de recuperación ante desastres del servidor o la portabilidad de bases de datos para restablecer el servicio. La replicación puede ser sincrónica o asincrónica. Los clústeres no son necesarios, ni se requiere una subred extendida.

  • Replicación continua local (LCR) con segunda copia hospedada en un segundo centro de datos   Esta no es la mejor solución, pero puede bastar para algunas organizaciones. En esta configuración se usan medios de almacenamiento de Internet SCSI (iSCSI) para guardar la copia pasiva de los datos. Las características de red de la conexión deben hacer posible que la copia pasiva y la copia activa permanezcan relativamente coherentes. En esta configuración, LCR no está disponible para la activación local rápida porque lo más probable es que la latencia y el ancho de banda de la red no admitan el acceso de cliente.

En la figura anterior se muestra el uso de una de las soluciones agrupadas. El motivo es que el servidor de buzones se muestra en el sitio de Active Directory del centro de datos de producción. En una solución con clústeres, las redes de cada uno de los nodos del clúster deben hallarse en la misma subred. En una solución no agrupada, no es necesario (aunque sí recomendable) que la subred sea única. En caso necesario se puede utilizar una subred distinta.

Suponiendo que se utiliza una solución agrupada, la sucesión normal de operaciones sería como sigue:

  1. Todo el correo entrante de Internet pasaría a través del servidor de transporte perimetral del Centro de datos A.

  2. Todo el correo destinado a los servidores de buzones del sitio de Active Directory Redmond-Prod se procesaría en los servidores de transporte de concentradores en Redmond-Prod.

  3. Los servidores de buzones de correo en clúster del sitio Active Directory  Redmond-Prod se hospedarían en sus nodos configurados en el centro de datos A o en el centro de datos B. El nodo A y el nodo B son parte de Redmond-Prod y están aprovisionados por los servidores de transporte de concentradores y de acceso a clientes de Redmond-Prod.

  4. Dado que CCR admite dos nodos, el segundo nodo debe estar ubicado en el centro de datos B. Esto significa que un error de nodo activo en el centro de datos A fuerza a que el servidor de buzones de correo en clúster se traslade al centro de datos B; en tal caso, le proporcionarán servicio los servidores de transporte de concentradores y de acceso de cliente del centro de datos A.

  5. Un SCC con tres servidores y dos copias de los datos se puede configurar de modo que un error haga que el servidor de buzones de correo en clúster permanezca en el centro de datos A en vez de conmutar al centro de datos B. Sin embargo, si el error está relacionado con el almacenamiento, seguirá siendo necesario activar el nodo pasivo del centro de datos B.

Los requisitos de ancho de banda de red entre ambos centros de datos están condicionados por tres factores:

  • Requisitos de latencia del servicio de clúster   El servicio de clúster exige un tiempo de retorno entre los nodos del clúster inferior a medio segundo.

  • Requisitos de ancho de banda para replicación   CCR exige menos ancho de banda que la mayor parte de soluciones de replicación de otros fabricantes, ya que la replicación CCR se basa en el trasvase de registros y no en la copia de bases de datos. El ancho de banda que exige una solución CCR depende de diversos factores que suelen ser exclusivos de cada entorno, y los requisitos incluyen ancho de banda para lo siguiente:

    • Trasvase de registros

    • Notificaciones del sistema de archivos, que informan al servicio de replicación de Microsoft Exchange cuando hay un nuevo archivo de registro listo para su trasvase

    • Tráfico del servidor de directorios

    • Tráfico de clientes, si los clientes no se encuentran en la misma ubicación física que el servidor de buzones en clúster

    • Tráfico de latidos del clúster

    • Actualizaciones de bases de datos del clúster

    • Otras aplicaciones que utilicen la red

  • Los servidores de transporte ce concentradores y de acceso de cliente requieren comunicaciones LAN entre ellos y los servidores de buzones a los que dan servicio   Para los servidores de acceso de cliente, este requisito es aún más importante porque ofrece servicio a usuarios en línea. El acceso del buzón a los controladores de dominio se puede efectuar a través de una conexión de red de área extensa (WAN), y su latencia afecta al acceso MAPI en línea.

Los requisitos de latencia y ancho de banda pueden reducirse si se implementa una solución no organizada en clústeres. Los requisitos de red para la replicación siguen siendo significativos. Sin embargo, casi todos los demás requisitos dejan de ser necesarios a menos que esté previsto activar el servidor de buzones de correo de copias de seguridad sin que haya ocurrido un error total del centro de datos A.

En caso de error del centro de datos de producción, el administrador puede restablecer el flujo de correo y los servicios de mensajería con una de las siguientes opciones:

  • Trasladar los servidores de buzones del centro de datos de copias de seguridad al sitio de Active Directory Redmond-DR.

  • Trasladar los servidores de transporte de concentradores, acceso de cliente y directorio del centro de datos de copias de seguridad al sitio de Active Directory Redmond-Prod.

La segunda opción es la estrategia recomendada, porque minimiza el impacto en el resto del entorno. Por ejemplo, los servidores de Exchange de cualquier sucursal no necesitan modificar el enrutamiento que perciben para el correo en cola. Simplemente se conectan cuando los servidores correctos están activos y disponibles.

La activación del centro de datos B sigue estos pasos de alto nivel:

  1. La infraestructura de red se pone en línea.

  2. La infraestructura de Active Directory se pone en línea.

  3. El servidor de buzón restante se pone en línea. Este paso puede requerir forzar al clúster a que se ponga en línea con el servidor restante.

  4. El sitio de Active Directory Redmond-Prod se actualiza con las direcciones IP de los servidores de transporte de concentradores, acceso de cliente y directorio de Redmond-DR.

  5. El registro MX de los dominios de la organización se actualiza con las direcciones IP del servidor de transporte perimetral del centro de datos B.

  6. El servidor de acceso de cliente que se acaba de trasladar se agrega a una configuración de equilibrado de carga de red (NLB).

  7. El servicio de mensajería del centro de datos A se restablece en el centro de datos B.

Cuando el centro de datos A está disponible, el centro de datos B se puede desactivar siguiendo estos pasos de alto nivel:

  1. Los servidores individuales del centro de datos A se ponen en línea. Estos servidores participarán en el suministro del servicio a menos que los servicios de Exchange se detengan o deshabiliten manualmente. Al migrar de vuelta, deje que los servidores del centro de datos A se pongan en línea.

  2. Permitir que los servidores de transporte de concentradores del centro de datos B vacíen sus colas y, a continuación, dejarlos sin conexión.

  3. Quite los servidores de acceso de cliente del centro de datos B de la configuración NLB. De este modo, los clientes se conectarán a través de los servidores del centro de datos A.

  4. El registro MX de los dominios de la organización se actualiza con las direcciones IP del servidor de transporte perimetral del centro de datos A.

  5. Efectúe las actualizaciones de infraestructura de red que sean necesarias.

  6. Traslade los servidores de buzones en clúster al centro de datos A.

  7. Actualice el sitio Active Directory Redmond-DR con las direcciones IP de los servidores que se trasladaron durante la activación.

  8. El servicio de mensajería del centro de datos A se restablece.

Como en todas las soluciones contra errores de sitios, la activación del centro de datos de producción y el de copias de seguridad debe estar incluida en un script y se debe probar con regularidad. El uso de una solución en clústeres para el servidor de buzón de correo reduce los tiempos de activación del centro de datos de copias de seguridad. Otras soluciones pueden requerir replicación del Sistema de nombres de dominio (DNS) y de Active Directory que puede afectar a la reanudación del flujo de correo y al acceso de los clientes a su buzón.

La solución Producción: Semiactivo (Dedicado) tiene la ventaja de que el nivel de servicio de los equipos dedicados es predecible.

Producción: Semiactivo (No dedicado) con dos sitios de Active Directory

En la configuración Producción: Semiactivo (Dedicado), los servidores de transporte perimetral, transporte de concentradores y acceso de cliente del centro de datos de copias de seguridad son recursos en espera dedicados para el centro de datos A. Ese tipo de configuración representa una inversión significativa en hardware que no se usa completamente. En la figura siguiente se presenta un modelo alternativo.

Ejemplo de una implementación de Producción: Semiactivo (No dedicado)

Ejemplo producción:Implementación templada (no dedicada)

Producción: Semiactivo (No dedicado) requiere que el administrador inicie manualmente la activación del centro de datos de copias de seguridad. Al iniciar el proceso de activación, este reconfigura parte del equipo e infraestructura del centro de datos de copias de seguridad para que se haga cargo del servicio de mensajería para los usuarios del centro de datos A.

Como en la solución Producción: Semiactivo (Dedicado), en la solución Producción: Semiactivo (No dedicado) hay dos sitios de Active Directory. Pero, a diferencia de lo que ocurre en la solución Producción: Semiactivo (Dedicado), ambos sitios de Active Directory abarcan el otro centro de datos. Los recursos dedicados en el centro de datos de copias de seguridad se han convertido en servidores redundantes para una configuración de producción distinta en este centro de datos de copias de seguridad. Con esta estrategia, los recursos están disponibles para utilizarlos con normalidad, con lo que se crean dos centros de datos de producción, y cada uno de ellos es, en realidad, el respaldo del otro.

Por ejemplo, tal como se muestra en la figura Ejemplo de implementación Producción: Semiactivo (No dedicado) implementación, cuando se produce un error en el centro de datos A, el servidor de transporte de concentradores 4, el servidor de acceso de cliente 4 y el servidor de catálogo global 4 se agregan al sitio Active Directory Redmond y, junto con el nodo B de Redmond, ofrecen el servicio de mensajería a los usuarios del centro de datos A. Cuando el sitio produce un error, los dos entornos de producción se ejecutan ahora con una menor capacidad y redundancia en comparación con su estado normal. Suponiendo que puedan asumir la carga continua, esta configuración es aceptable. Por ejemplo, el correo de Internet pasa por el servidor de transporte perimetral del centro de datos B. Para poder reaccionar ante una interrupción prolongada del centro de datos, la empresa puede disponer de contratos con proveedores que le suministren hardware adicional con rapidez. El hardware agregado puede entonces usarse para restablecer la redundancia o aumentar la capacidad.

El funcionamiento normal de las instalaciones de los sitios de Active Directory de Redmond y Dublín sería el mismo para esta solución que para la solución Producción: Semiactivo (Dedicado). De forma similar, el ancho de banda de red entre las dos ubicaciones estaría condicionado por los mismos factores, salvo que los servidores de Redmond y Dublín necesitan soporte simultáneo.

Para activar el centro de datos de copias de seguridad se debe:

  • Trasladar el nodo activo y el servidor de buzones de correo en clúster al sitio de Active Directory del centro de datos operativo.

  • Trasladar los servidores de transporte de concentradores, acceso de cliente y directorio del centro de datos de copias de seguridad al sitio de Active Directory del centro de datos en el que se ha producido un error.

La solución de activación recomendada es trasladar los servidores de transporte de concentradores y acceso de cliente al sitio de Active Directory del centro de datos en el que se ha producido un error. Esta es la solución más sencilla y cuya activación causa menos interrupciones.

En esta solución, la recuperación del centro de datos A se efectúa mediante estos pasos de alto nivel:

  1. La infraestructura de red se pone en línea. Es posible que no sea necesario efectuar cambio alguno en la infraestructura de la red, porque el correo de Internet ya se recibe en el centro de datos B.

  2. La infraestructura de Active Directory para el centro de datos A se pone en línea (sitio Active Directory Redmond).

  3. El servidor de buzones restante se pone en línea. Este paso puede requerir forzar al clúster a que se ponga en línea con el servidor restante.

  4. El sitio Active Directory Redmond se actualiza con las direcciones IP de los servidores de transporte de concentradores 4, acceso de cliente 4 y catálogo global 4.

  5. El servidor de acceso de cliente 3 se agrega a la configuración NLB de Redmond.

  6. El servicio de mensajería del centro de datos A se restablece.

Cuando el centro de datos A está disponible, se puede restablecer la configuración normal del centro de datos B siguiendo estos pasos de alto nivel:

  1. Los servidores individuales del centro de datos A se ponen en línea. Estos servidores participarán en el suministro del servicio a menos que los servicios de Exchange se detengan o deshabiliten manualmente. Al migrar de vuelta, deje que los servidores del centro de datos A se pongan en línea.

  2. Permita que el servidor de transporte de concentradores 4 vacíe sus colas y, a continuación, déjelo sin conexión.

  3. Quite el servidor de acceso de cliente 4 de la configuración NLB. Los clientes podrán aún conectarse a los servidores del centro de datos A.

  4. Efectúe las actualizaciones de infraestructura de red que sean necesarias.

  5. Traslade los servidores de buzones en clúster al centro de datos A.

  6. Actualice el sitio Active Directory Dublín con las direcciones IP de los servidores que se trasladaron durante la activación.

  7. Ambos centros de datos se han restablecido a su estado original.

Como en todas las soluciones contra errores de sitios, la activación del centro de datos de producción y el de copias de seguridad debe estar incluida en un script y se debe probar con regularidad. El uso de una solución en clúster para el servidor de buzones reduce los tiempos de activación del centro de datos de copias de seguridad. Otras soluciones de buzón pueden requerir replicación de DNS y de Active Directory que puede afectar a la reanudación del flujo de correo y al acceso de los clientes a su buzón.

Con esta solución, los servidores utilizados para resistencia de sitios se pueden utilizar en el funcionamiento normal del centro. De esta forma se reduce el costo de la solución de resistencia, pero se corre el riesgo de que no sea capaz de soportar toda la carga del sistema cuando sea necesario. Por ejemplo, si la carga en los servidores de transporte de concentradores del centro de datos B crece hasta usar el 80 por ciento de la capacidad, la activación del centro de datos de copias de seguridad para A superará la capacidad de transporte de concentradores. Con esta solución, los administradores deberán supervisar cuidadosamente la utilización del sistema a lo largo del tiempo para garantizar la constante viabilidad. Si la carga aumenta, se deberá adquirir e implementar nuevo hardware.

Producción: Producción (No dedicado) con un sitio de Active Directory

Las organizaciones que necesitan una solución que admita la activación automática de un sitio de copias de seguridad deberán recurrir a la solución Producción: Producción (No dedicado). En esta solución se implementan servidores redundantes en un único sitio de Active Directory que abarca ambos centros de datos, según se muestra en la figura siguiente.

Ejemplo de una implementación de Producción: Producción (Dedicado)

Producción:Implementación de producción (no dedicada)

En esta solución se implementan los recursos de ambos centros de datos en un único sitio de Active Directory. Cualquiera de los recursos del sitio puede ofrecer servicio a casi cualquier solicitud. Por ejemplo, un servidor de transporte perimetral del centro de datos A puede usar un servidor de transporte de concentradores del centro de datos B para enviar un mensaje a un usuario cuyo buzón se encuentra en un servidor de buzones de correo en clúster hospedado en el centro de datos A. De forma similar, el tráfico de Active Directory no tiene, de forma predeterminada, localización de referencia. Por estas razones no se recomienda emplear esta solución.

La activación del centro de datos de copias de seguridad es similar a la recuperación de múltiples errores de servidor. La recuperación de la activación requiere simplemente restablecer el servicio en los servidores que han producido un error. Como sucede en las soluciones no dedicadas comentadas anteriormente, una mala administración de la capacidad puede hacer que la carga supere la capacidad del servicio tras el error de un centro de datos. Los administradores deben garantizar que la solución es capaz de admitir la carga esperada tras el error de un centro de datos. Los errores en la administración de capacidad pueden provocar un error total del servicio de mensajería tras el error de un solo centro de datos.