Alta disponibilidad

  • Artículo

 

Se aplica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Última modificación del tema: 2009-04-01

En esta sección sobre alta disponibilidad se incluyen temas que puede usar para diseñar, crear y usar un sistema de mensajería de gran disponibilidad basado en la versión RTM de Microsoft Exchange Server 2007 y Exchange 2007 Service Pack 1 (SP1). Los temas de esta área son:

Se recomienda revisar la documentación al respecto antes de diseñar o implementar una solución de mensajería de alta disponibilidad basada en Exchange 2007 SP1.

La documentación de esta área se ha actualizado para incluir las últimas prácticas recomendadas para la implementación de Exchange 2007 SP1 en Windows Server 2008 y Windows Server 2003 Service Pack 2 (SP2).

Alta disponibilidad para Exchange Server 2007

Aunque los requisitos mínimos de tiempo de funcionamiento varían entre las distintas organizaciones, cada organización tiene como objetivo alcanzar un alto nivel del mismo. Las organizaciones en las que la mensajería cobra una importancia fundamental suelen diseñar un sistema de mensajería con alta disponibilidad para proporcionar este tiempo de funcionamiento.

Exchange 2007 RTM y Exchange 2007 SP1 incluyen las siguientes características integradas de recuperación rápida, alta disponibilidad y resistencia de sitios en los servidores de buzones de Exchange 2007:

  • Replicación continua local (LCR) LCR es una solución de servidor único que usa tecnología de trasvase de registros asincrónico integrada para crear y mantener una copia de un grupo de almacenamiento en un segundo conjunto de discos que están conectados al mismo servidor que el grupo de almacenamiento de producción. LCR proporciona trasvase de registros, reproducción de registros y cambio manual rápido a una copia secundaria de los datos.

  • Replicación continua en clúster (CCR)   CCR, que es una solución de clúster de conmutación por error de almacenamiento no compartido, es uno de los dos tipos de implementación de servidores de buzones en clúster disponibles en Exchange 2007. CCR es una solución en clúster (conocida como entorno CCR) que usa tecnología de trasvase de registros asincrónico integrado para crear y mantener una copia de cada grupo de almacenamiento en un segundo servidor en un clúster de conmutación por error. La CCR está diseñada para actuar como solución de uno o de dos centros de datos, y proporciona tanto alta disponibilidad como resistencia de sitios. CCR es muy distinta a las soluciones de clústeres de versiones anteriores de Exchange Server. Para obtener información detallada acerca de algunas de las diferencias, consulte Recursos de clúster de Exchange para los servidores de buzón en clústeres y Comportamiento de la recuperación de la replicación continua en clústeres.

  • Replicación continua en espera (SCR)   SCR es una nueva característica introducida en Exchange 2007 SP1. 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 existentes y permite nuevos escenarios de disponibilidad de datos para servidores de buzones de correo de Exchange 2007. SCR usa la misma tecnología de trasvase y reproducción de registros que usan LCR y CCR con el fin de proporcionar opciones y configuraciones de implementación adicionales al proporcionar al administrador la capacidad de crear copias del grupo de almacenamiento adicionales. SCR se puede usar para replicar datos desde servidores de buzones independientes y servidores de buzones de correo en clúster.

  • Clústeres de copia única (SCC)   SCC, que es una solución de clúster de conmutación por error de almacenamiento compartido, es el otro tipo de implementación de servidores de buzones en clústeres disponible en Exchange 2007. SCC es una solución en clústeres que usa una copia única de un grupo de almacenamiento en un almacenamiento compartido entre los nodos del clúster. SCC se parece en cierto modo a las soluciones de clústeres de las versiones anteriores de Exchange Server; pero, además de contener numerosas mejoras, presenta algunos cambios significativos. Para obtener más información acerca de algunos de estos cambios, consulte Modelo de recurso de clúster de copia única y Comportamiento de la recuperación de clúster de copia única.

Para obtener información más detallada sobre otras características y funcionalidades de alta disponibilidad introducidas en SP1, consulte Nuevas características de alta disponibilidad de Exchange 2007 SP1.

Alta disponibilidad para servidores de buzones

La alta disponibilidad para servidores de buzones se presenta de dos formas: disponibilidad de servicio y disponibilidad de datos. La disponibilidad de servicios se proporciona mediante el uso de un clúster de conmutación por error de Windows Server. La disponibilidad de datos se proporciona a través de una característica integrada llamada replicación continua.

Servidor de buzones de correo en clúster

Tanto CCR como SCC son soluciones que se implementan en un clúster de conmutación por error de Windows Server. Sólo se puede instalar la función del servidor Buzón de correo en una conmutación por errores de clúster. No es posible instalar ninguna otra función en una conmutación por errores de clúster. A un servidor de buzones implementado en un clúster de conmutación por error se le conoce como servidor de buzones de correo en clúster. Los servidores de buzones de correo en clúster que se ejecutan en un entorno CCR son muy diferentes de los servidores de buzones de correo en clúster que se ejecutan en un entorno SCC. Además, los servidores de buzones de correo en clúster en Exchange 2007 RTM y Exchange 2007 SP1 son muy diferentes de los servidores de buzones de correo en clúster de versiones anteriores de Microsoft Exchange.

Puede usar Get-MailboxServer <CMSName> | fl Name, ClusteredStorageType en el Shell de administración de Exchange para determinar si un servidor de buzones de correo en clúster está hospedado en un entorno CCR o SCC. Un valor NonShared indica que el servidor de buzones de correo en clúster está en un entorno CCR y un valor Shared indica que el servidor de buzones de correo en clúster está en un SCC. Un valor Disabled indica que el servidor de buzones de correo es un servidor independiente.

También se puede comprobar Active Directory para determinar si un servidor de buzones de correo en clúster está hospedado en un entorno CCR o SCC examinando el valor del atributo msExchClusterStorageType del objeto del servidor de buzones. Un valor de 1 en el atributo msExchClusterStorageType indica que el servidor de buzones de correo en clúster está hospedado en un entorno CCR y un valor de 2 indica que el servidor de buzones de correo en clúster está en un SCC. Un valor <Not Set> indica que el servidor de buzones es un servidor independiente.

Entornos CCR

Exchange 2007 RTM y Exchange 2007 SP1 admiten un máximo de dos nodos que tengan la función del servidor Buzón de correo instalada (uno activo y otro pasivo) en un entorno CCR. También admite un clúster de conmutación por error de tres nodos que use un nodo de votante y un quórum Conjunto de nodos mayoritario tradicional, pero éste no constituye el mejor modelo de clúster. No obstante, se recomienda que la mayoría de clientes implementen entornos CCR que usen únicamente dos nodos, y o bien un quórum Mayoría de recurso compartido de archivos y nodo (Windows Server 2008) o bien un Conjunto de nodos mayoritario con un quórum Testigo del recurso compartido de archivos (Windows Server 2003). Por tanto, la documentación acerca de CCR está orientada hacia los clústeres de conmutación por error de dos nodos que usan uno de estos modelos de quórum.

Nota

También se admite un clúster de conmutación por error de un solo nodo implementado en un entorno CCR, pero no se considera una solución de alta disponibilidad porque no existe redundancia en el clúster. Cuando use un clúster de conmutación por error de un solo nodo implementado en un entorno CCR, debe usar un quórum Conjunto de nodos mayoritario (tradicional, sin testigo del recurso compartido de archivos).

Clústeres de copia única

Exchange 2007 RTM y Exchange 2007 SP1 admiten un máximo de ocho nodos en SCC. Algunas de las combinaciones válidas de SCC de Exchange 2007 SP1 en clústeres de conmutación por error de Windows Server son:

  • 7 activos/1 pasivo

  • 6 activos/1 ó 2 pasivos

  • 5 activos/1, 2 ó 3 pasivos

  • 4 activos/1, 2, 3 ó 4 pasivos

  • 3 activos/1, 2, 3, 4 ó 5 pasivos

  • 2 activos/1, 2, 3, 4, 5 ó 6 pasivos

  • 1 activo / 0, 1, 2, 3, 4, 5, 6 o 7 pasivos

    Nota

    La versión de 64 bits de Windows Server 2008 admite hasta 16 nodos en un clúster de conmutación por error único; sin embargo, Exchange 2007 admite un máximo de 8 nodos en el clúster. El clúster de conmutación por error puede seguir conteniendo hasta 16 nodos, pero Exchange 2007 debe instalarse en no más de 8 nodos en el clúster de conmutación por error.

Generalmente, no es necesario más de un nodo pasivo en el clúster para cada nodo activo del mismo. En consecuencia, una configuración de un nodo activo y un nodo pasivo es preferible a configuraciones con un nodo activo y múltiples nodos pasivos. Cuando use un SCC de un solo nodo, puede usar un quórum de almacenamiento compartido o un quórum Conjunto de nodos mayoritario (tradicional, sin testigo del recurso compartido de archivos). Aunque se admiten los SCC de nodo único, no se consideran una solución de alta disponibilidad porque no existe redundancia en el clúster.

Clúster extendido

Un clúster extendido, también denominado clúster geográficamente disperso, es un clúster de conmutación por error que se extiende (se amplía) por más de un centro de datos físico. Los clústeres extendidos se pueden usar como parte del diseño de resistencia del sitio para la organización de Exchange Dado que CCR no usa el almacenamiento compartido, se puede implementar fácilmente en un clúster de conmutación por error geográficamente disperso, incluido un clúster extendido de varias subredes en Windows Server 2008. Un clúster extendido también admite SCC; sin embargo, requiere tecnología de replicación sincrónica de terceros. Para obtener más información acerca de clústeres extendidos, consulte Site Resilience Configurations.

Clúster en espera

Hay otro tipo de clúster admitido por Exchange 2007 y Exchange 2007 SP1 al que se le llama clúster en espera. Un clúster en espera es un clúster de conmutación por error de Windows Server que no contiene un servidor de buzones de correo en clúster, pero al que se le puede suministrar rápidamente un servidor de buzones de correo en clúster de sustitución en caso de producirse un desastre, otro error en el clúster de conmutación por error de producción o alguna otra situación de recuperación.

Replicación continua

La replicación continua, también conocida como trasvase de registros, es el proceso de automatización de la replicación de los archivos de registros de transacción cerrados desde un grupo de almacenamiento de producción a una copia del grupo de almacenamiento ubicada en un segundo conjunto de discos en el equipo local o en otro servidor distinto. Después de haberse copiado en esta segunda ubicación, los archivos de registro se vuelven a reproducir en la copia de la base de datos, manteniendo los grupos de almacenamiento sincronizados con un pequeño retraso.

La replicación continua se presenta de dos formas en Exchange 2007 RTM (LCR y CCR) y en tres formas en Exchange 2007 SP1 (LCR, CCR y SCR).

Alta disponibilidad en otras funciones del servidor

La gran disponibilidad de las funciones del servidor Transporte perimetral, Acceso de cliente y Mensajería unificada se consigue a través de una combinación de redundancia de servidor, equilibrio de carga de red (NLB), equilibrio de carga de hardware, Round robin de sistema de nombres de dominio (DNS), así como servidores proactivos, servicios y administración de infraestructuras. En términos generales, se puede conseguir alta disponibilidad para las funciones del servidor de acceso de cliente, Transporte de concentradores, Transporte perimetral y Mensajería unificada mediante el uso de las siguientes estrategias y tecnologías:

  • Transporte perimetral   Es posible implementar múltiples servidores de transporte perimetral y usar varios registros de intercambio de correo (MX) DNS para equilibrar la actividad a través de esos servidores. También puede usar NLB para proporcionar equilibrio de carga y alta disponibilidad a los servidores de transporte perimetral.

  • Acceso de cliente   Es posible usar NLB o un dispositivo de equilibrio de carga de red basado en hardware de terceros para la máxima disponibilidad del servidor de acceso de cliente. Para obtener más información acerca de NLB, consulte Windows Server TechCenter.

  • Transporte de concentradores   Es posible implementar varios servidores de transporte de concentradores para obtener una gran disponibilidad del transporte interno. En la función del servidor Transporte de concentradores se ha implementado la recuperación de las siguientes maneras:

    • Servidor de transporte de concentradores a servidor de transporte de concentradores (dentro de la organización)   La comunicación de servidor de transporte de concentradores a servidor de transporte de concentradores dentro de una organización equilibra la carga automáticamente entre servidores de transporte de concentradores del sitio del servicio de directorios de Active Directory de destino.

    • Servidor de buzones a servidor de transporte de concentradores (dentro del sitio de Active Directory)   El servicio de entrega de correo de Microsoft Exchange en los servidores de buzones equilibra la carga automáticamente entre todos los servidores de transporte de concentradores del mismo sitio de Active Directory.

    • Servidor de mensajería unificada a servidor de transporte de concentradores   El servidor de mensajería unificada equilibra automáticamente la carga de las conexiones entre todos los servidores de transporte de concentradores del mismo sitio de Active Directory.

    • Servidor de transporte perimetral a servidor de transporte de concentradores   El servidor de transporte perimetral equilibra automáticamente la carga del tráfico del Protocolo simple de transferencia de correo (SMTP) entrante en todos los servidores de transporte de concentradores del sitio de Active Directory al que está suscrito el servidor de transporte perimetral.

    Para obtener mayor redundancia (por ejemplo, en aplicaciones que requieren relevo SMTP), puede crear un nuevo registro DNS (por ejemplo, relevo.empresa.com), asignar una dirección IP y usar un equilibrador de carga de hardware para redirigir esa dirección IP a varios servidores de transporte de concentradores. En Exchange 2007 SP1, también puede usar el equilibrio de carga de red para los conectores de cliente en servidores de transporte de concentradores. Al usar un equilibrador de carga de hardware, se necesita confirmar que no habrá tráfico de Exchange 2007 en la organización que atraviese el equilibrador de carga de hardware ya que dicho tráfico usa algoritmos de equilibrio de carga integrados, tal como se había descrito anteriormente. Para obtener más información acerca del equilibrio de carga y de los servidores de transporte, consulte Opciones de implementación para servidores de transporte de concentradores y Equilibrio de carga y tolerancia a errores para servidores de transporte.

  • Mensajería unificada   Las implementaciones de mensajería unificada pueden hacerse más resistentes implementando varios servidores de mensajería unificada donde dos o más estén en un único plan de marcado. Las puertas de enlace de voz sobre IP (VoIP) compatibles con la mensajería unificada pueden configurarse para enrutar llamadas a servidores de mensajería unificada por turnos. Además, estas puertas de enlace pueden recuperar la lista de servidores para un plan de marcado desde DNS. En cualquier caso, las puertas de enlace VoIP presentarán una llamada a un servidor de mensajería unificada y si la llamada no es aceptada, dicha llamada se presentará a otro servidor que proporcione redundancia en el momento de establecer la llamada.

Alcanzar gran disponibilidad con redundancia de datos y servicios

La premisa básica de la arquitectura de gran disponibilidad de Exchange 2007 es introducir la redundancia en la implementación. Un error se recupera mediante el resto de recursos informáticos para admitir los servicios de Exchange. Cuando se reparan los errores, los recursos informáticos están nuevamente disponibles para Exchange y sus clientes. En este contexto, los recursos informáticos pueden ser equipos o almacenamiento para un buzón u otros datos de Exchange.

La redundancia puede introducirse en un único centro de datos. Esto normalmente se hace para prestar protección frente a los errores de un servidor individual. Por ejemplo, la introducción de un segundo servidor de transporte perimetral en el centro de datos principal de su organización habilita el flujo de correo para que continúe en caso de error de uno de los dos servidores.

De forma alternativa, o además de ello, podría introducirse la redundancia en un segundo centro de datos. Dos configuraciones de centro de datos permiten la continuidad del servicio en caso de error en un centro de datos. Si se introduce un servidor de transporte de concentradores adicional en un centro de datos secundario, existe la oportunidad de tener un segundo servidor de transporte de concentradores que administre el flujo de correo cuando se produzca un error en el servidor de transporte de concentradores primario o cuando el centro de datos de producción no esté disponible. Si se implementan tres servidores de transporte de concentradores, dos de ellos pueden estar en el centro de datos de producción y el tercero puede estar en el centro de datos secundario.

El punto de implementación fundamental es que la redundancia puede evitar interrupciones que sin la redundancia provocarían diversos errores. La forma en que se implementan los equipos y servicios redundantes determina los errores que pueden producirse sin afectar a los datos o a la disponibilidad del servicio. Las organizaciones deben comprender sus requisitos y, a continuación, observar los problemas operativos para entender cuál es la mejor solución para ellas. Por ejemplo, puede que una organización desee activar un centro de datos de copias de seguridad solamente después de un error de 20 minutos del centro de datos de producción. En este caso, la organización debe haber establecido los procesos necesarios para validar regularmente la activación y el funcionamiento del centro de datos de copias de seguridad. Una organización diferente puede decidir que una validación en curso del centro de datos de copias de seguridad sea fundamental para su éxito y, de ese modo, se deriva en una configuración de implementación diferente para esa organización.