Diseño de alta disponibilidad y resistencia de sitios

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

Última modificación del tema: 2016-11-28

Microsoft Exchange Server 2010 incluye un nuevo marco unificado para la resistencia de buzones que incluye nuevas características, como el grupo de disponibilidad de base de datos (DAG) y las copias de base de datos de buzones de correo. Si bien la implementación de estas nuevas características es un proceso simple y rápido, debe realizarse una planificación cuidadosa en forma anticipada para garantizar que cualquier solución de alta disponibilidad y resistencia de sitios que use estas características cumpla con sus expectativas y requisitos comerciales.

Durante la fase de planificación, los arquitectos del sistema, los administradores y otras partes interesadas clave deben identificar los requisitos para la implementación; particularmente, los requisitos de alta disponibilidad y resistencia de sitios. Existen requisitos generales que deben cumplirse para implementar estas características, así como requisitos de hardware, software y redes. Para obtener instrucciones sobre los requisitos de almacenamiento para los DAG, consulte Diseño del almacenamiento del servidor de buzones de correo.

Contenido

Requisitos generales

Requisitos de hardware

Requisitos de almacenamiento

Requisitos de software

Requisitos de red

Requisitos de servidor testigo

Planificación de resistencia de sitios

Planificación de cambios de centro de datos

Requisitos generales

Antes de implementar un DAG y crear copias de base de datos de buzones de correo, compruebe que se cumplan las siguientes recomendaciones relativas a todo el sistema:

• Se debe estar ejecutando el Sistema de nombres de dominio (DNS). En condiciones ideales, el servidor DNS debería admitir actualizaciones dinámicas. Si el servidor DNS no las admite, usted debe crear un registro de host DNS (A) para cada servidor de Exchange. En caso contrario, Exchange no funcionará correctamente.

• Cada servidor de buzones en un DAG debe ser un servidor miembro en el mismo dominio.

• No se permite agregar un servidor de buzones de Exchange 2010 que también sea un servidor de directorio de un DAG.

• El nombre que asigna al DAG debe ser un nombre de equipo válido, disponible y único de 15 caracteres o menos.

Requisitos de hardware

Generalmente, no hay requisitos de hardware especiales que sean específicos de los DAG o las copias de base de datos de buzones de correo. Los servidores usados deben cumplir con todos los requisitos estipulados en los temas para Requisitos previos de Exchange 2010 y Requisitos del sistema de Exchange 2010. Para obtener información de planificación de hardware, consulte los temas siguientes:

• Descripción de configuraciones de procesador y rendimiento de Exchange

• Descripción de configuraciones de memoria y rendimiento de Exchange

• Diseño del almacenamiento del servidor de buzones de correo

• Descripción de las proporciones de roles de servidor y rendimiento de Exchange

Requisitos de almacenamiento

En general, no hay requisitos de almacenamiento especiales que se apliquen específicamente a los DAG ni a las copias de bases de datos de buzones. Los DAG no requieren ni usan almacenamiento compartido administrado por clúster. El almacenamiento compartido administrado por clúster es compatible con un DAG únicamente cuando éste está configurado para usar una solución que aproveche la API de replicación de terceros integrada en Exchange 2010. Para obtener más información acerca de cómo planificar el almacenamiento, consulte Diseño del almacenamiento del servidor de buzones de correo.

Requisitos de software

Los DAG están disponibles en Exchange 2010 Standard Edition y Exchange 2010 Enterprise Edition. Asimismo, un DAG puede incluir una combinación de servidores que ejecuten Exchange 2010 Standard Edition y Exchange 2010 Enterprise Edition.

Cada miembro del DAG también debe ejecutar el mismo sistema operativo. Exchange 2010 se admite en los sistemas operativos Windows Server 2008 y Windows Server 2008 R2. Todos los miembros de un DAG deben ejecutar el sistema operativo Windows Server 2008 o Windows Server 2008 R2. No pueden incluir una combinación de Windows Server 2008 y Windows Server 2008 R2.

Además de cumplir con los requisitos previos para la instalación de Exchange 2010, existen requisitos del sistema operativo que deben cumplirse. Los DAG usan tecnología de clúster de conmutación por error de Windows y, por lo tanto, requieren la versión Enterprise de Windows.

Requisitos de red

Existen requisitos de red específicos que deben cumplirse para cada DAG y para cada miembro del DAG. Las redes del DAG son similares a las redes públicas, mixtas y privadas usadas en versiones anteriores de Exchange. Sin embargo, a diferencia de las versiones anteriores, es posible configurar una única red en cada miembro del DAG. Además, la terminología ha cambiado ligeramente. En lugar de redes públicas, privadas o mixtas, cada DAG cuenta con una única red MAPI, que es usada por otros servidores (p. ej., otros servidores de directorio, servidores de Exchange 2010, etc.) para comunicarse con el miembro del DAG, y ninguna o más redes de replicación, que son redes dedicadas al trasvase de registros y la inicialización.

Si bien se admite una única red, recomendamos que cada DAG tenga, al menos, dos redes: una única red MAPI y una única red de replicación. Esto ofrece redundancia para la red y la ruta de la red, y permite al sistema distinguir entre un error del servidor y un error de la red. El uso de un único adaptador de red evita que el sistema distinga entre dos tipos de errores.

Tenga en cuenta lo siguiente al diseñar la infraestructura de red para su DAG:

• Cada miembro del DAG debe tener, como mínimo, un adaptador de red que pueda comunicarse con los demás miembros del DAG. Si usa una única ruta de red, le recomendamos que use Gigabit Ethernet. Al usar un único adaptador de red en cada miembro del DAG, la red del DAG debe estar habilitada para la replicación y debe estar configurada como una red MAPI. Debido a que no hay otras redes, el sistema usará la red MAPI también como una red de replicación. Asimismo, al usar un único adaptador de red en cada miembro del DAG, recomendamos que diseñe la solución general teniendo en cuenta el adaptador de red único y la ruta.

• El uso de dos adaptadores de red en cada miembro del DAG le ofrece una red MAPI y una red de replicación, y los siguientes comportamientos de recuperación:

  • En caso de que ocurra un error que afecte la red MAPI, ocurrirá una conmutación por error del servidor (siempre que haya copias de base de datos de buzones de correo en buen estado que puedan activarse).

  • En caso de que ocurra un error que afecte la red de replicación, si la red MAPI no se ve afectada por el error, las operaciones de trasvase de registros e inicialización se revertirán para usar la red MAPI, aunque dicha red tenga su propiedad ReplicationEnabled establecida en False. Cuando se restaure la salud de la red de replicación y ésta esté lista para reanudar las operaciones de trasvase de registro e inicialización, deberá cambiar manualmente a la red de replicación. Para cambiar la replicación de la red MAPI a una red de replicación restaurada, puede suspender y reanudar la replicación mediante los cmdlets Suspend-MailboxDatabaseCopy y Resume-MailboxDatabaseCopy, o reiniciar el servicio de replicación de Microsoft Exchange. Recomendamos utilizar las operaciones de suspensión y reanudación para evitar el breve corte producido por el reinicio del servicio de replicación de Microsoft Exchange.

• Cada miembro del DAG debe tener el mismo número de redes. Por ejemplo, si planea usar un único adaptador de red en cada miembro del DAG, todos los miembros del DAG también deben usar un único adaptador de red.

• Cada DAG debe tener una red MAPI como máximo. La red MAPI debe proporcionar conectividad a los otros servicios y servidores de Exchange, como Active Directory y DNS.

• Se pueden agregar redes de replicación, según sea necesario. También puede evitar que un adaptador de red individual sea un punto de error único al usar la formación de equipos del adaptador de red o una tecnología similar. Sin embargo, incluso si se usa la formación de equipos, no se evitará que la red misma sea un único punto de error.

• Cada red de cada servidor miembro del DAG debe encontrarse en su propia subred de red. Cada servidor del DAG puede encontrarse en una subred diferente, pero las redes MAPI y las redes de replicación deben ser enrutables y suministrar conectividad, de modo que:

  • Cada red de cada servidor miembro del DAG se encuentra en su propia subred de red, que es independiente de la subred usada por cada una de las demás redes del servidor.

  • Cada red MAPI del servidor miembro del DAG puede comunicarse con cada una de las demás redes MAPI del miembro del DAG.

  • Cada red de replicación del servidor miembro del DAG puede comunicarse con cada una de las demás redes de replicación del miembro del DAG.

  • No existe un enrutamiento directo que permita el tráfico de latidos de la red de replicación en un servidor miembro del DAG a la red MAPI en otro servidor miembro del DAG, o viceversa, o entre varias redes de replicación del DAG.

• Independientemente de su ubicación geográfica en relación con otros miembros del DAG, cada miembro del DAG debe contar con una latencia de red de recorrido de ida y vuelta que no supere los 500 milisegundos (ms) entre cada uno de los demás miembros. A medida que la latencia de recorrido de ida y vuelta entre dos servidores de buzones que hospedan copias de una base de datos aumenta, el potencial de replicaciones desactualizadas también aumenta. Independientemente de la latencia de la solución, los clientes deben validar que las redes entre todos los miembros de DAG sean capaces de satisfacer la protección de datos y los objetivos de disponibilidad de la implementación. Las configuraciones con valores de latencia más altos pueden requerir un ajuste especial de los parámetros de DAG, replicación y red, como el aumento del número de bases de datos o la disminución del número de buzones por base de datos, para lograr los objetivos deseados.

• Es posible que los requisitos de latencia de ida y vuelta no sean los más estrictos en cuanto al ancho de banda de red y a la latencia para una configuración de varios centros de datos. Debe evaluar la carga de red total que incluye acceso de cliente, Active Directory, transporte, replicación continua y otro tráfico de aplicación para determinar los requisitos de red necesarios para su entorno.

• Las redes del DAG admiten el protocolo de Internet versión 4 (IPv4) e IPv6. La versión IPv6 sólo se admite cuando también se usa IPv4; no se admite un entorno de versión IPv6 exclusivamente. Sólo se admite el uso de direcciones IPv6 e intervalos de direcciones IP si están habilitadas las versiones IPv6 e IPv4 en dicho equipo y la red es compatible con ambas versiones de dirección IP. Si Exchange 2010 está implementado en esta configuración, todas las funciones del servidor podrán enviar datos a dispositivos, servidores y clientes que usen direcciones IPv6, así como recibir datos de ellos.

• La dirección IP privada automática (APIPA) es una función de Microsoft Windows que asigna automáticamente direcciones IP cuando no hay ningún servidor de protocolo de configuración dinámica de host (DHCP) disponible en la red. Las direcciones APIPA (incluidas las direcciones asignadas manualmente del intervalo de direcciones APIPA) no pueden ser usadas por los DAG ni por Exchange 2010.

Requisitos de dirección IP y nombre del DAG

Durante la creación, a cada DAG se le asigna un nombre único y una o más direcciones IP estáticas, o se lo configura para usar DHCP. Independientemente de que se usen direcciones asignadas en forma dinámica o estática, cualquier dirección IP asignada al DAG debe encontrarse en la red MAPI.

Cada DAG requiere, al menos, una dirección IP en la red MAPI. Un DAG requiere direcciones IP adicionales cuando la red MAPI se extiende en varias subredes. En la siguiente figura, se ilustra un DAG en el que todos los nodos del DAG tienen la red MAPI en la misma subred.

Grupo de disponibilidad de base de datos con la red MAPI en la misma subred

En este ejemplo, la red MAPI de cada miembro del DAG se encuentra en la subred 172.19.18.x. Como resultado, el DAG requiere una dirección IP única en dicha subred.

En la siguiente figura, se ilustra un DAG que tiene una red MAPI que se extiende en dos subredes: 172.19.18.x y 172.19.19.x.

Grupo de disponibilidad de base de datos con la red MAPI en varias subredes

En este ejemplo, la red MAPI de cada miembro del DAG se encuentra en una subred independiente. Como resultado, el DAG requiere dos direcciones IP, una para cada subred de la red MAPI.

Cada vez que la red MAPI del DAG se extiende en una subred adicional, debe configurarse una dirección IP adicional para dicha subred del DAG. Cada dirección IP configurada para el DAG se asigna al clúster de conmutación por error subyacente del DAG, y éste la usa. El nombre del DAG también se usa como el nombre para el clúster de conmutación por error subyacente.

En cualquier momento específico, el clúster para el DAG usará sólo una de las direcciones IP asignadas. Los clústeres de conmutación por error de Windows registran esta dirección IP en DNS cuando la dirección IP del clúster y los recursos de nombre de red se conectan. Además de usar una dirección IP y un nombre de red, se crea un objeto de nombre de clúster (CNO) en Active Directory. El sistema usa internamente el nombre, la dirección IP y el CNO para el clúster a fin de proteger el DAG y permitir la comunicación interna. Los administradores y los usuarios finales no necesitan conectarse a la dirección IP ni el nombre del DAG, ni usarlos como interfaz.

Configuración del adaptador de red para DAG

Cada adaptador de red debe configurarse correctamente según su uso previsto. Un adaptador de red usado para una red MAPI tiene una configuración diferente de la del adaptador de red usado para una red de replicación. Además de configurar cada adaptador de red de forma correcta, debe configurar el orden de conexión de red en Windows para que la red MAPI se encuentre al principio en el orden de conexión. Para obtener instrucciones detalladas acerca de cómo modificar el orden de la conexión de red, consulte Modificar el orden de enlaces de protocolo.

Configuración de adaptador de red MAPI

Un adaptador de red destinado para ser usado por una red MAPI debe configurarse como se describe en la siguiente tabla.

Las propiedades de TCP/IP v4 para un adaptador de red MAPI se configuran de la siguiente forma:

• La dirección IP de la red MAPI de un miembro de DAG se puede asignar o configurar manualmente para usar DHCP. Si se usa DHCP, recomendamos usar reservas persistentes para la dirección IP del servidor.

• La red MAPI usa habitualmente una puerta de enlace predeterminada, aunque no se requiere una.

• Se debe configurar al menos una dirección de servidor DNS. Se recomienda el uso de varios servidores DNS para obtener redundancia.

• La casilla Registrar la dirección de esta conexión en DNS debe estar activada.

Configuración de adaptador de red de replicación

Un adaptador de red destinado para ser usado por una red de replicación debe configurarse como se describe en la siguiente tabla.

Las propiedades de TCP/IP v4 para un adaptador de red de replicación se configuran de la siguiente forma:

• La dirección IP de la red de replicación de un miembro de DAG se puede asignar o configurar manualmente para usar DHCP. Si se usa DHCP, recomendamos usar reservas persistentes para la dirección IP del servidor.

• Las redes de replicación, por lo general, no poseen puertas de enlace predeterminadas; y si la red MAPI cuenta con una, ninguna otra red deberá tener puertas de enlace predeterminadas. El enrutamiento del tráfico de red en una red de replicación puede configurarse mediante el uso de rutas estáticas y persistentes a la red correspondiente en otros miembros del DAG usando direcciones de puerta de enlace con capacidad de enrutamiento entre las redes de replicación. Cualquier otro tráfico que no coincida con esta ruta estará controlado por la puerta de enlace predeterminada configurada en el adaptador para la red MAPI.

• No deben configurarse las direcciones del servidor DNS.

• La casilla Registrar la dirección de esta conexión en DNS no debe estar activada.

Requisitos generales

Requisitos de servidor testigo

Un servidor testigo es un servidor externo al DAG que se usa para alcanzar y mantener quórum cuando el DAG cuenta con un número par de miembros. Los DAG con un número impar de miembros no usan un servidor testigo. Todos los DAG con número par de miembros usarán un servidor testigo. El servidor testigo puede ser cualquier equipo que ejecute Windows Server. No es necesario que la versión del sistema operativo Windows Server del servidor testigo coincida con el sistema operativo usado por los miembros del DAG.

Se mantiene el quórum en el clúster, debajo del DAG. Un DAG tiene quórum cuando la mayoría de sus miembros están conectados y pueden comunicarse con los demás miembros conectados del DAG. Esta noción de quórum representa un aspecto del concepto de quórum en los clústeres de conmutación por error de Windows. El recurso de quórum es un aspecto relacionado y necesario del quórum en los clústeres de conmutación por error. El recurso de quórum es un recurso interno del clúster de conmutación por error que ofrece un medio para arbitrar las decisiones de pertenencia y de estado del clúster. El recurso de quórum también proporciona almacenamiento persistente para almacenar información de configuración. Un asistente del recurso de quórum es el registro de quórum, que es una base de datos de configuración para el clúster. Este registro contiene información, como los servidores que forman parte del clúster, los recursos instalados en el clúster y el estado de dichos recursos (por ejemplo, sin están conectados o no).

Es esencial que cada miembro del DAG tenga una vista uniforme de la forma en que está configurado el clúster subyacente del DAG. El quórum actúa como repositorio definitivo de toda la información de configuración relativa al clúster. El quórum se usa también como mecanismo para resolver empates con el fin de evitar el síndrome de "cerebro dividido". El síndrome de cerebro dividido es una condición que ocurre cuando los miembros del DAG no pueden comunicarse entre ello, pero se encuentran en ejecución. El síndrome de cerebro dividido se evita al requerir la disponibilidad e interacción de una mayoría de los miembros del DAG (y en el caso de los DAG con un número par de miembros, el servidor testigo del DAG) en forma permanente para que el DAG esté en funcionamiento.

Planificación de resistencia de sitios

Cada día, más y más empresas reconocen que el acceso a un sistema de mensajería confiable y disponible es fundamental para alcanzar el éxito. En muchas organizaciones, el sistema de mensajería forma parte de los planes de continuidad comercial; y la implementación de su servicio de mensajería está diseñada teniendo en cuenta la resistencia de sitios. Fundamentalmente, varias soluciones de resistencia de sitios implican la implementación de hardware en un centro de datos secundario.

En última instancia, el diseño general de un DAG, incluido el número de miembros del DAG y el número de copias de base de datos de buzones de correo, dependerá de los acuerdos de nivel de servicio (SLA) de recuperación de cada organización que cubren varios escenarios de conmutación por error. Durante la etapa de planificación, los administradores y los arquitectos de la solución identifican los requisitos para la implementación, en especial, los requisitos de resistencia de sitios. Identifican las ubicaciones que se usarán y los destinos requeridos de los acuerdos de nivel de servicio de recuperación. El SLA identificará dos elementos específicos que deben ser la base del diseño de una solución que ofrece alta disponibilidad y resistencia de sitios: el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Ambos valores se miden en minutos. El RTO representa el tiempo que se demora en restaurar el servicio. El RPO hace referencia al estado de actualización de los datos después de que se completa la operación de restauración. También puede definirse un SLA para la restauración del centro de datos principal en el servicio completo una vez que se corrigen sus problemas.

Los administradores y los arquitectos de la solución también identificarán el conjunto de usuarios que requerirán protección de resistencia de sitios, y determinarán si la solución de varios sitios tendrá una configuración activa/pasiva o activa/activa. En una configuración activa/pasiva, generalmente, no hay usuarios hospedados en el centro de datos en espera. En una configuración activa/activa, los usuarios se hospedan en ambas ubicaciones, y cierto porcentaje del número total de bases de datos dentro de la solución posee una ubicación activa preferida en un centro de datos secundario. En caso de ocurrir un error en el servicio para los usuarios de un centro de datos, dichos usuarios se activan en el otro centro de datos.

Construir los SLA correspondientes requiere, a menudo, que se respondan las siguientes preguntas básicas:

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

• ¿Los usuarios necesitan los datos o necesitan ú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?

Al responder estas preguntas, comenzará a dar forma al diseño de resistencia de sitios de su solución de mensajería. Uno de los requisitos fundamentales para la recuperación ante errores de sitios es crear una solución que envíe los datos necesarios a un centro de datos de copias de seguridad que hospede el servicio de mensajería de copias de seguridad.

Planificación de espacio de nombres

Exchange 2010 cambia la forma en que se planifica el diseño del espacio de nombres al implementar una configuración de resistencia de sitios. La planificación adecuada del espacio de nombres es esencial para que el cambio de centro de datos se realice correctamente. Desde una perspectiva del espacio de nombres, cada centro de datos usado en una configuración de resistencia de sitios se considera activo. Como resultado, cada centro de datos requerirá su propio espacio de nombres único para los diferentes servicios de Exchange 2010 en dicho sitio, incluidos los espacios de nombres para Outlook Web App, Outlook en cualquier lugar, Exchange ActiveSync, servicios Web Exchange, acceso de cliente de RPC, Protocolo de oficina de correos v.3 (POP3), Protocolo de acceso a mensajes de Internet versión 4 (IMAP4) y Protocolo simple de transferencia de correo (SMTP). Además, uno de los centros de datos aloja también el espacio de nombres de Detección automática. Este diseño también le permite realizar el cambio de una base de datos única del centro de datos principal a un centro de datos secundario para validar la configuración de los datos secundarios como parte de la validación y la práctica de un cambio de centro de datos.

Como procedimiento recomendado, se le sugiere que use la división de DNS para los nombres de host de Exchange usados por los clientes. La división DNS hace referencia a la configuración de un servidor de DNS, donde los servidores DNS internos devuelven una dirección IP interna para un nombre de host y los servidores DNS externos (expuestos a Internet) devuelven una dirección IP pública para el mismo nombre de host. Como la división DNS usa los mismos nombres de host de forma interna y externa, esta estrategia permite reducir el nombre de nombres de host necesarios.

En la figura siguiente, se ilustra la planificación del espacio de nombres para una configuración de resistencia de sitios.

Espacios de nombres para una implementación de DAG de resistencia de sitios

Como se muestra anteriormente, cada centro de datos usa un espacio de nombres independiente y único, y cada uno incluye servidores DNS en una configuración de división de DNS para dichos espacios de nombres. El centro de datos Redmond, que se considera el centro de datos principal, está configurado con el espacio de nombres protocolo.contoso.com. El centro de datos Portland está configurado con el espacio de nombres protocolo.enespera.contoso.com. Los espacios de nombres pueden incluir designaciones de "en espera", como se muestra en la figura de ejemplo, pueden basarse en la región (p. ej., protocolo.portland.contoso.com) o pueden basarse en otras convenciones de nomenclatura que se adapten a las necesidades de su organización. El requisito fundamental es que, independientemente de la convención de nomenclatura que use, cada centro de datos debe tener su propio espacio de nombres.

Configuración de FailbackURL

Algunos exploradores web, incluido Microsoft Internet Explorer, mantienen una memoria caché de nombres DNS durante cada sesión del explorador diferente de la memoria caché proporcionada por el sistema operativo. Durante la recuperación tras error en el centro de datos principal después de que se haya producido un cambio de centro de datos, el uso del navegador web de esta otra memoria caché del navegador web puede producir bucles de inicio de sesión a los usuarios de Outlook Web App, en los que los usuarios se redirección a la misma dirección URL en un bucle que se repite.

Durante el proceso de conmutación por recuperación, la dirección IP del espacio de nombres Outlook Web App se cambia en DNS desde un extremo en el centro de datos en espera nuevamente al extremo original del centro de datos principal. Una vez que el TTL del registro de DNS haya expirado e incluso después de que la memoria caché de DNS se haya borrado, los exploradores web que mantienen su propia memoria caché separada podrán continuar conectándose al extremo en el centro de datos en espera, aunque el espacio de nombres esté hospedado en el centro de datos principal.

Generalmente, el cierre del explorador web es suficiente para borrar la memoria caché de nombres separados y evitar los bucles de inicio de sesión. No obstante, para mitigar este problema para todos los navegadores web y usuarios de Outlook Web App, puede configurar la propiedad FailbackURL del directorio virtual de Outlook Web App. El parámetro FailbackUrl especifica el nombre de host que Outlook Web App utiliza para conectarse al servidor de acceso de cliente después de que se produzca una recuperación tras error a un sitio principal. Este espacio de nombres requiere una entrada DNS separada que apunta a la dirección IP del servidor de acceso de cliente original. El valor del parámetro FailbackUrl debe ser diferente del valor del parámetro ExternalUrl para el directorio virtual de Outlook Web App. Cuando un usuario de Outlook Web App proporciona las credenciales, el servidor de acceso de cliente detecta si la dirección URL es la misma que está visitando el usuario. Si las direcciones URL son las mismas, el servidor de acceso de cliente comprueba si el parámetro FailbackUrl está configurado:

• Si el parámetro FailbackUrl está configurado, redirecciona el usuario a la dirección URL donde podrían obtener acceso a Outlook Web App.

• Si el parámetro FailbackUrl no está configurado, el usuario recibe un mensaje de error que indica que el cambio de configuración de un servidor está evitando de manera temporal el acceso a su buzón. Este mensaje indica al usuario que cierre todas las ventanas del explorador (limpiando así la memoria caché del nombre del explorador) y que intente de nuevo en unos pocos minutos.

Planificación de certificado

No existen consideraciones de diseño especiales ni únicas para los certificados al implementar un DAG en un centro de datos único. Sin embargo, al extender un DAG entre varios centros de datos en una configuración de resistencia de sitios, existen ciertas consideraciones específicas en relación con los certificados. Generalmente, el diseño de su certificado dependerá de los clientes en uso, así como de los requisitos del certificado por parte de otras aplicaciones que usan certificados. Sin embargo, hay algunas recomendaciones específicas y procedimientos recomendados que debe seguir en relación con el tipo y el número de certificados.

Como procedimiento recomendado, debe minimizar la cantidad de certificados que usará para sus servidores de acceso de cliente, servidores proxy inversos y servidores de transporte (perimetral y concentrador). Se recomienda usar un único certificado para todos esos extremos del servicio en cada centro de datos. Este enfoque minimiza la cantidad de certificados necesarios, lo que reduce los costes y la complejidad de la solución.

Para los clientes de Outlook en cualquier lugar, recomendamos que use un certificado con nombre alternativo del sujeto (SAN) único para cada centro de datos e incluya varios nombres de host en el certificado. Para garantizar la conectividad de Outlook en cualquier lugar después de un cambio de base de datos, servidor o centro de datos, debe usar el mismo nombre principal del certificado en cada certificado y configurar el objeto de configuración de proveedor de Outlook en Active Directory con el mismo nombre principal, en el formato estándar de Microsoft (msstd). Por ejemplo, si usa el nombre principal del certificado correo.contoso.com, deberá configurar los atributos de la siguiente forma:

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Varias aplicaciones que se integran con Exchange cuentan con requisitos de certificados específicos que pueden exigir el uso de certificados adicionales. Exchange 2010 puede coexistir con Office Communications Server (OCS). OCS requiere certificados con 1024 bits o superiores que usen el nombre del servidor OCS para el nombre principal del certificado. Debido a que el uso de un nombre del servidor OCS para el nombre principal del certificado impedirá el funcionamiento correcto de Outlook en cualquier lugar, deberá usar un certificado adicional e independiente para el entorno del OCS.

Para obtener más información acerca de cómo usar certificados SAN para acceso de cliente de Exchange 2010, consulte Configurar certificados SSL para usar varios nombres de host del servidor de acceso de cliente.

Planificación de red

Además de los requisitos de red específicos que deben cumplirse para cada DAG, así como para cada servidor miembro del DAG, existen recomendaciones y requisitos específicos para la configuración de resistencia de sitios. Al igual que con todos los DAG, ya sea que los miembros del DAG estén implementados en un sitio único o en varios sitios, la latencia de red de regreso de recorrido de ida y vuelta entre los miembros del DAG no debe ser superior a 500 milisegundos (ms). Además, existen valores de configuración específicos recomendados para los DAG que se extienden a varios sitios:

• Las redes MAPI deben aislarse de las redes de replicación. Las directivas de red de Windows, las directivas de firewall de Windows o las listas de control de acceso (ACL) del enrutador deben usarse para bloquear el tráfico entre la red MAPI y las redes de replicación. Esta configuración es necesaria para evitar la interferencia de latidos de la red.

• Los registros DNS orientados al cliente deben tener un período de vida (TTL) de 5 minutos. La cantidad de tiempo de inactividad que experimentan los clientes depende no sólo de la rapidez con la que puede ocurrir un cambio, sino también de la rapidez con la que ocurre la replicación de DNS y la rapidez con la que los clientes consultan la información DNS actualizada. Los registros DNS de todos los servicios de cliente de Exchange, incluidos Outlook Web App, Exchange ActiveSync, servicios Web Exchange, Outlook en cualquier lugar, SMTP, POP3, IMAP4 y acceso de cliente de RPC en servidores DNS internos y externos, deben configurarse con un TTL de 5 minutos.

• Uso de rutas estáticas para configurar la conectividad entre las redes de replicación. Para proporcionar conectividad de red entre cada uno de los adaptadores de la red de replicación, use rutas estáticas persistentes. Ésta es una configuración única y rápida que se realiza en cada miembro del DAG al usar direcciones IP estáticas. Si usa DHCP a fin de obtener direcciones IP para sus redes de replicación, también puede usarlo para asignar rutas estáticas para la replicación; de esta manera, se simplifica el proceso de configuración.

Planificación general de resistencia de sitios

Además de los requisitos mencionados anteriormente para alta disponibilidad, existen otras recomendaciones para la implementación de Exchange 2010 en una configuración de resistencia de sitios (p. ej., extender un DAG a varios centros de datos). Lo que realice durante la fase de planificación tendrá un impacto directo en el éxito de su solución de resistencia de sitios. Por ejemplo, un diseño de espacio de nombres deficiente puede causar dificultades con los certificados, y una configuración de certificados incorrecta puede impedir que los usuarios obtengan acceso a los servicios.

Para minimizar el tiempo que demora la activación de un centro de datos secundario y permitir que éste aloje los extremos del servicio de un centro de datos que falló, debe realizarse la planificación adecuada. Por ejemplo:

• Los objetivos del acuerdo de nivel de servicio (SLA) para la solución de resistencia de sitios debe comprenderse y documentarse correctamente.

• Los servidores en el centro de datos secundario deben tener la capacidad suficiente para alojar la población de usuarios combinada de ambos centros de datos.

• El centro de datos secundario debe tener habilitados todos los servicios suministrados en el centro de datos principal (excepto que el servicio no esté incluido como parte del SLA de resistencia de sitios). Esto incluye Active Directory, infraestructura de red (DNS, TCP/IP, etc.), servicios de telefonía (si está en uso la mensajería unificada) e infraestructura del sitio (energía, refrigeración, etc.).

• A fin de que ciertos servicios puedan brindarse a los usuarios desde el centro de datos donde se produjo un error, deben tener configurados los certificados del servidor correctos. Ciertos servicios no permiten la instanciación (por ejemplo, POP3 e IMAP4) y sólo permiten el uso de un certificado único. En dichos casos, el certificado debe ser un certificado con nombre alternativo del sujeto (SAN) que incluya varios nombres, o los diferentes nombres deben ser lo suficientemente similares para que pueda usarse un certificado comodín (suponiendo que las directivas de seguridad de la organización permiten el uso de certificados comodín).

• Deben definirse los servicios necesarios en el centro de datos secundario. Por ejemplo, si el primer centro de datos tiene tres direcciones URL de SMTP distintas en diferentes servidores de transporte, debe definirse la configuración apropiada en el centro de datos secundario para habilitar al menos un servidor de transporte (si no se habilitan los tres) para alojar la carga de trabajo.

• Debe haberse realizado la configuración de red necesaria para admitir el cambio de centro de datos. Esto podría significar que debe asegurarse de que la configuración del equilibrio de carga se haya realizado, el DNS global esté configurado y la conexión a Internet esté habilitada con la configuración de enrutamiento apropiada.

• Debe comprenderse la estrategia para permitir los cambios de DNS necesarios a fin de realizar un cambio de centro de datos. Los cambios de DNS específicos, incluidos los valores del período de vida (TTL), deben definirse y documentarse para admitir los SLA vigentes.

• También debe establecerse e incluirse en el SLA una estrategia para probar la solución. La validación periódica de la implementación es la única forma de garantizar que la calidad y la viabilidad de la implementación no se perderán con el tiempo. Recomendamos que, una vez validada la implementación, se documente explícitamente la parte de la configuración que afecte de manera directa el éxito de la solución. Asimismo, recomendamos que mejore los procesos de administración de cambios en relación con dichos segmentos de la implementación.

Requisitos generales

Planificación de cambios de centro de datos

La planificación y la preparación adecuadas requieren la implementación de los recursos del centro de datos secundario, como los servidores de transporte de concentradores y de acceso de cliente, y la configuración previa de dichos recursos para minimizar los cambios necesarios como parte de una operación de cambio de centro de datos.

Para comprender mejor la forma en que funciona el proceso de cambio de un centro de datos, es útil entender el funcionamiento básico de un cambio de centro de datos de Exchange 2010.

Como se ilustra en la siguiente figura, una implementación de resistencia de sitios incluye un DAG que cuenta con miembros en ambos centros de datos.

Grupo de disponibilidad de base de datos con miembros en dos centros de datos

Cuando se extiende un DAG entre varios centros de datos, éste debe estar diseñado de forma que la mayoría de los miembros del DGA se ubiquen en el centro de datos principal o que, cuando cada centro de datos tenga el mismo número de miembros, el centro de datos principal aloje el servidor testigo. Este diseño garantiza que el servicio se suministrará en el centro de datos principal, incluso si la conectividad de red entre los dos centros de datos falla. Sin embargo, también implica que, cuando el centro de datos principal falle, se perderá el quórum de los miembros del centro de datos secundario.

Los errores parciales en el centro de datos también son posibles, y ocurrirán. Se presupone que si se pierde suficiente funcionalidad en el centro de datos principal como para impedir el servicio y la administración adecuados, debe realizarse un cambio de centro de datos para activar el centro de datos secundario. El proceso de activación implica la interrupción del servicio por parte del administrador que realiza la configuración de los servidores subsistentes con estado de funcionamiento parcial. A continuación, la activación puede continuar en el centro de datos secundario. Esto se realiza para impedir que ambos tipos de servicio intenten funcionar al mismo tiempo.

Como resultado de la pérdida de quórum, los miembros del DAG del centro de datos secundario no pueden conectarse automáticamente. Por lo tanto, la activación de los servidores de buzones del centro de datos secundario también requiere un paso en el que los servidores miembros del DAG sean forzados a crear quórum; en este punto, los servidores del centro de datos donde se produjo un error se quitan del DAG (sólo de manera temporal). Esto ofrece una solución de servicio parcial, que es estable y susceptible de experimentar cierto nivel de errores adicionales, y que aún continúa funcionando.

Éste es el proceso básico usado para volver a establecer la funcionalidad de la función del buzón en el centro de datos secundario. La activación de las demás funciones en el centro de datos secundario no implica acciones explícitas en los servidores afectados del centro de datos secundario. En cambio, los servidores del centro de datos secundario se convierten en los extremos del servicio para aquellos servicios habitualmente alojados en el centro de datos principal. Por ejemplo, un usuario alojado normalmente en el centro de datos principal podría usar https://mail.contoso.com/owa para conectarse a Outlook Web App. Después de que se produce el error en el centro de datos, dichos extremos del servicio se trasladan a los extremos del centro de datos secundario como parte de la operación de cambio. Durante la operación de cambio, los extremos del servicio del centro de datos principal se redirigen a direcciones IP alternativas para los mismos servicios en el centro de datos secundario. Esto minimiza el número de cambios que deben realizarse en la información de configuración almacenada en Active Directory durante el proceso de cambio. Por lo general, hay dos formas de completar este paso:

• Actualizar los registros DNS o

• Volver a configurar el DNS y el/los equilibrador(es) de carga para habilitar y deshabilitar las direcciones IP alternativas, moviendo así los servicios entre los centros de datos.

Se debe establecer una estrategia para probar la solución. Debe tenerse en cuenta en el SLA. La validación periódica de la implementación es la única forma de garantizar que la implementación no se perderá con el tiempo.

La finalización cuidadosa de estos pasos de planificación tendrá un impacto directo en el éxito del cambio de un centro de datos. Por ejemplo, un diseño de espacio de nombres deficiente puede causar dificultades con los certificados, y una configuración de certificados incorrecta puede impedir que los usuarios obtengan acceso a los servicios.

Recomendamos que, una vez validada la implementación, se documenten explícitamente todas las partes de la configuración que afecten de manera directa el éxito de un cambio de centro de datos. Asimismo, puede ser prudente mejorar los procesos de administración de cambios en relación con dichos segmentos de la implementación.

Para obtener más información acerca de los cambios de centro de datos, incluida la activación de un centro de datos secundario y la reactivación de un centro de datos (principal) con error, consulte Cambios en el centro de datos.

Requisitos generales

 © 2010 Microsoft Corporation. Reservados todos los derechos.