Compartir a través de

Descripción de alta disponibilidad y resistencia de sitios

  • Artículo

 

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

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

Las bases de datos de buzones y los datos que éstas contienen constituyen uno de los componentes más críticos (si no el más crítico de todos) de cualquier organización de Exchange. En Microsoft Exchange Server 2010, las bases de datos de buzones y los datos que hay en ellas se pueden proteger configurando dichas bases de datos para una alta disponibilidad y resistencia de sitios. Exchange 2010 reduce el costo y la dificultad inherentes a la implementación de una solución de mensajería altamente disponible y resistente de sitios, al tiempo que proporciona mayores niveles de disponibilidad de extremo a extremo y admite buzones de mayor tamaño. Basada en las posibilidades de replicación nativa incluidas en Exchange Server 2007, la nueva arquitectura de alta disponibilidad en Exchange 2010 proporciona un marco simplificado y unificado para una alta disponibilidad y resistencia de sitios. Exchange 2010 integra la alta disponibilidad en la arquitectura principal de Exchange, hace posible que clientes de todos los tamaños y en todos los segmentos se puedan permitir implementar un servicio de mensajería continua.

¿Está buscando tareas de administración relacionadas con la alta disponibilidad y la resistencia de sitios? Consulte Administración de la alta disponibilidad y la resistencia de sitios.

Contenido

Terminología básica

Características principales de la solución de Exchange Server 2010

Movilidad de la base de datos

Implementación incremental

Grupos de disponibilidad de base de datos

Copias de bases de datos de buzones de correo

Active Manager

Cambios en la alta disponibilidad de versiones anteriores de Exchange

Alta disponibilidad en roles de servidor que no son Buzón de correo

Resistencia de sitios

Disponibilidad de un extremo a otro

Terminología básica

Los siguientes términos son de aplicación:

  • Servicio de libreta de direcciones
    Servicio en el servidor de acceso de cliente que proporciona un extremo de acceso al directorio para clientes de Microsoft Outlook.
  • Replicación continua, modo de bloque
    Nueva forma de replicación continua en SP1 en la que cada actualización se escribe en el búfer de registro activo de la copia de base de datos activa; también se incluye en un búfer de registro de cada una de las copias de buzones pasivos. 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
    Nombre de la forma original de replicación continua en el lanzamiento de la versión RTM (para fabricantes) de Exchange 2010, según la cual los archivos de registros de transacción cerrados se envían de la copia de base de datos activa a una o varias copias de bases de datos pasivas.
  • Grupo de disponibilidad de base de datos (DAG)
    Grupo de hasta 16 servidores de buzones de correo de Exchange 2010 que hospeda un conjunto de bases de datos replicadas.
  • Movilidad de la base de datos
    La capacidad que tiene una sola base de datos de buzones de correo de Exchange 2010 de replicarse y montarse en otros servidores de buzones de correo de Exchange 2010.
  • Recuperación ante desastres
    Cualquier proceso que sirve 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
    API que Exchange suministra y que permite usar la replicación sincrónica de terceros para un grupo de disponibilidad de base de datos en lugar de la replicación continua.
  • Alta disponibilidad
    Solución que ofrece disponibilidad de servicio, disponibilidad de datos y recuperación automática de los errores que afectan al servicio o a los datos (como un error de red, de almacenamiento o de servidor).
  • Implementación incremental
    La capacidad de implementar una alta disponibilidad y resistencia de sitios después de instalar Exchange 2010.
  • Copia de base de datos de buzones con retardo
    Copia pasiva de una base de datos de buzones que presenta un tiempo de retardo de reproducción de registro superior a cero.
  • Copia de base de datos de buzones
    Base de datos de buzones (archivo .edb y registros), ya sea en estado activo o pasivo.
  • Resistencia de buzón
    Nombre de una solución unificada de alta disponibilidad y resistencia de sitios en Exchange 2010.
  • Servicio de acceso de cliente RPC
    Servicio en el servidor de acceso de cliente que proporciona un extremo de MAPI para clientes de Microsoft Outlook.
  • Resistencia de sitios
    Un proceso manual de recuperación ante desastres usado para activar un centro de datos alternativo o en espera cuando el centro de datos principal ya no puede proporcionar un nivel de servicio suficiente para satisfacer las necesidades de la organización. También incluye el proceso de reactivación de un centro de datos principal que se haya recuperado, restaurado o vuelto a crear. Puede configurar la solución de mensajería para alta disponibilidad, así como habilitar la resistencia de sitios, mediante las características y funcionalidad integradas en Exchange 2010.
  • Redundancia de instantánea
    Característica de servidor de transporte que proporciona redundancia de mensajes para todo el tiempo en que éstos están en tránsito.
  • *over (pronounced "star over")
    Abreviatura para cambio y conmutación 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.

Volver al principio

Características principales de la solución de Exchange Server 2010

Exchange 2007 redujo los costos de la alta disponibilidad e hizo que la resistencia de sitios fuera más económica al incluir nuevas tecnologías, como la replicación continua de clúster (CCR) y la replicación continua en espera (SCR). Aun así, quedaron algunos desafíos pendientes:

  • La agrupación en clústeres de conmutación por error de Windows puede resultar confusa por su complejidad.

  • Lograr un alto nivel de tiempo de actividad puede requerir mucha intervención por parte del administrador.

  • Cada tipo de replicación continua estaba administrado de forma diferente y por separado.

  • La recuperación de un error de una sola base de datos en un servidor de buzones de correo podía resultar en una interrupción temporal del servicio para todos los usuarios de dicho servidor.

  • La característica de recuperación del elemento eliminado de transporte de un servidor Transporte de concentradores solamente podía proteger mensajes destinados a buzones de un entorno CCR. Si un servidor Transporte de concentradores da error durante el procesamiento de mensajes y no se puede recuperar, podrían perderse los datos.

Exchange 2010 incluye modificaciones principales muy significativas que integran la alta disponibilidad en la arquitectura, lo que hace que sea más económico y fácil de implementar y mantener que las versiones anteriores de Exchange. Exchange 2010 incluye una nueva plataforma unificada a fin de obtener alta disponibilidad y resistencia de sitios.

Gracias a estas notables mejoras realizadas en Exchange 2010, el tamaño máximo de base de datos de buzones de correo recomendado al usar la replicación continua ha pasado de 200 gigabytes (GB) en Exchange 2007 a 2 terabytes en Exchange 2010. Cada vez más compañías se dan cuenta de lo importante que es disponer de buzones de gran tamaño (entre 2 GB y 10 GB), por lo que es posible que muy pronto se disponga de bases de datos más grandes. Dar cabida a estas bases de datos más voluminosas implica dejar atrás los mecanismos de recuperación heredados (como la copia de seguridad y la restauración) y pasar a adoptar métodos de protección más rápidos y novedosos, como la replicación de datos o la redundancia de servidor. En última instancia, el tamaño de sus bases de datos de buzones depende de muchos factores basados en el proceso de planeación de Exchange 2010. Para obtener instrucciones detalladas sobre la planeación de buzones de correo y servidores de buzones, consulte Diseño del almacenamiento del servidor de buzones de correo.

Exchange 2010 combina las características principales de disponibilidad y resistencia de CCR y SCR en una única solución que se encarga de la replicación de datos tanto en el sitio como fuera de éste. Los servidores de buzones de correo se pueden definir como parte de un DAG para proporcionar recuperación automática en el nivel de la base de datos de buzones en lugar de en el nivel del servidor. En Exchange 2010 se presentan nuevos conceptos de alta disponibilidad, como movilidad de base de datos e implementación incremental.

Volver al principio

Movilidad de la base de datos

Exchange 2007 incluía un gran número de modificaciones de arquitectura pensadas para que la implementación de las soluciones de alta disponibilidad y resistencia de sitios de Exchange fuera más rápida y sencilla. Estas mejoras incluyen una experiencia de instalación integrada, opciones de configuración optimizadas y la posibilidad de administrar la mayoría de los aspectos de la solución de alta disponibilidad mediante herramientas de administración nativas de Exchange.

Con todo, la administración de una solución de alta disponibilidad de Exchange 2007 requería dominar algunos conceptos de clúster complejos, como los de mover identidades de red y administrar recursos de clúster. Además, al solucionar problemas relacionados con un servidor de buzones de correo en clúster, se usaban herramientas de Exchange y herramientas de clúster para revisar y correlacionar registros y eventos de dos fuentes diferentes: Exchange y el clúster.

Teniendo como base los comentarios de los clientes, se han vuelto a evaluar y diseñar otros dos aspectos que limitan la arquitectura de Exchange 2007:

  • Los servidores en clúster de Exchange 2007 requieren hardware dedicado. Sólo se pudo instalar el rol de servidor Buzón de correo en un nodo, en el clúster. Esto significa que se necesitaba un mínimo de cuatro servidores Exchange para lograr una redundancia total de los componentes primarios de una implementación, es decir, los roles de servidor principales (Buzón de correo, Transporte de concentradores y Acceso de cliente).

  • En Exchange 2007, la conmutación por error de un servidor de buzones de correo en clúster se produce en el nivel de servidor. Como resultado, si se producía un solo error en la base de datos, el administrador tenía que conmutar todo el servidor de buzones de correo en clúster a otro nodo del clúster (lo que resultaba en un breve período de inactividad para todos los usuarios del servidor y no solamente para aquellos usuarios con un buzón en la base de datos afectada), o dejar sin conexión a los usuarios de la base de datos con errores (tal vez durante horas) mientras se restauraba la base de datos desde la copia de seguridad.

Exchange 2010 se ha diseñado con el concepto de movilidad de base de datos. La movilidad de la base de datos amplía el uso de la replicación continua del sistema al replicar una base de datos en varios servidores diferentes que están agrupados. Este modelo proporciona una mejor protección de la base de datos y una mayor disponibilidad. Además, la protección de conmutación por error automática y el control de cambio manual se suministran en el nivel de base de datos de buzones, y no en el nivel de servidor.

En caso de que se produzcan errores, los otros servidores que tengan copias de la base de datos pueden montar la base de datos. Como resultado de esto y otras modificaciones en la arquitectura, ahora las acciones de conmutación por error se completan más rápidamente que en versiones anteriores de Exchange. Por ejemplo, la conmutación por error de un servidor de buzones de correo en clúster de un entorno CCR que ejecuta Exchange 2007 con Service Pack 1 se completa en unos dos minutos (siempre y cuando sea un error entre sitios en el que la dirección IP del servidor de buzones de correo en clúster permanece inalterada). En comparación, la conmutación por error de una base de datos de buzones en un entorno de Exchange 2010 se completa en 30 segundos (desde el momento en que se detecta el error hasta que la copia de la base de datos se monta, y siempre y cuando que la copia disponible esté en buen estado y actualizada con la reproducción de registros). La combinación de una conmutación por error en el nivel de la base de datos y un tiempo de conmutación por error significativamente más rápido mejora el tiempo de actividad general de una organización.

Volver al principio

Implementación incremental

Exchange 2010 presenta el concepto de implementación incremental, que permite implementar la disponibilidad del servicio y los datos para todos los servidores y bases de datos de buzones de correo una vez que se ha instalado Exchange. La redundancia de servicios y datos se logra mediante nuevas características de Exchange 2010, como DAG y copias de bases de datos.

En las versiones anteriores de Exchange, la disponibilidad de los roles de servidor Buzón de correo se lograba mediante la implementación de Exchange en un clúster de conmutación por error de Windows. Para implementar Exchange en un clúster, primero tiene que crear un clúster de conmutación por error y luego instalar los archivos de programa de Exchange. Mediante este proceso se crea un servidor de buzones de correo especial llamado servidor de buzones de correo en clúster (o servidor virtual de Exchange en versiones anteriores de Exchange). Si ya tiene instalados los archivos de programa de Exchange en un servidor que no está en clúster y ha decidido que quiere un servidor de buzones de correo en clúster, deberá crear un clúster con un nuevo hardware, o bien eliminar Exchange del servidor existente, instalar un clúster de conmutación por error y volver a instalar Exchange.

Volver al principio

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 2010. Se trata de 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 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.

Exchange 2007 presentó una tecnología de replicación de datos integrada denominada replicación continua. La replicación continua, disponible en tres formas, local, en clúster y en espera, reducía considerablemente el costo derivado de la implementación de una infraestructura de Exchange altamente disponible y que, asimismo, proporcionaba una experiencia de administración e implementación mucho mejor con respecto a las versiones anteriores de Exchange. Aun con todas estas mejoras y ahorro económico, el uso de una infraestructura de Exchange 2007 altamente disponible precisaba, sin embargo, de mucho tiempo y de una gran experiencia, ya que la integración entre Exchange y la agrupación de clústeres de conmutación por error de Windows no era perfecta. Además, los clientes querían disponer de una forma más sencilla de replicar sus datos de correo electrónico a una ubicación remota a fin de proteger sus entornos de Exchange de posibles desastres en el nivel de sitio.

Exchange 2010 emplea la misma tecnología de replicación continua que Exchange 2007. Exchange 2010 combina la replicación de datos en el sitio (CCR) y la replicación de datos fuera del sitio (SCR) en un único marco conocido como grupo de disponibilidad de base de datos (DAG). Tras agregar los servidores a un DAG, se podrán agregar copias de bases de datos replicadas de forma incremental (hasta un total de 16) y Exchange 2010 alternará entre estas copias automáticamente para, así, mantener la disponibilidad.

Al contrario de lo que sucedía en Exchange 2007, donde los servidores de buzones en clúster necesitaban un hardware dedicado, los servidores de buzones de correo de un DAG pueden hospedar otros roles de Exchange (Acceso de cliente, Transporte de concentradores y Mensajería unificada), con lo cual se logra plena redundancia de los servicios y datos de Exchange con tan solo dos servidores.

Esta nueva arquitectura de alta disponibilidad, que se puede implementar en una amplia gama de tipos de almacenamiento, también ofrece una recuperación simplificada de distintos tipos de error (nivel de disco, nivel de servidor y nivel de centro de datos).

Para obtener más información acerca de los DAG, consulte Descripción de grupos de disponibilidad de base de datos.

Volver al principio

Copias de bases de datos de buzones de correo

Las características de alta disponibilidad y resistencia de sitios ya incluidas en Exchange 2007 se usan en Exchange 2010 para crear y mantener copias de bases de datos con el fin de que pueda alcanzar sus objetivos de disponibilidad en Exchange 2010. Exchange 2010 también incluye el concepto de movilidad de base de datos, que es la conmutación por error en el nivel de la base de datos administrada por Exchange.

La movilidad de base de datos desconecta las bases de datos de los servidores, incluye soporte para hasta 16 copias de una sola base de datos y ofrece una experiencia nativa para agregar copias de bases de datos a una base de datos. En Exchange 2007, una característica llamada portabilidad de base de datos también le permite mover una base de datos de buzones de correo entre servidores. Sin embargo, una diferencia fundamental entre la portabilidad de base de datos y la movilidad de base de datos es que todas las copias de una base de datos tienen el mismo GUID.

El proceso por el cual una copia de base de datos se establece como la base de datos de buzones se denomina cambio. En esta misma línea, si se produce un error que afecta a una base de datos y una nueva base de datos pasa a ser la copia activa, se produce lo que 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 un cambio o una conmutación por error tiene lugar, otros roles de servidor de Exchange 2010 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 caso de que la base de datos no cumpla los criterios de montaje automático y no se pueda montar de forma automática, se puede realizar una conmutación por error de la base de datos manualmente.

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

Volver al principio

Active Manager

En Exchange 2007 y en versiones anteriores, Exchange empleaba un modelo de administración de recursos de clúster para instalar, implementar y administrar la solución de alta disponibilidad de los servidores de buzones de correo. Históricamente, la creación de un servidor de buzones de correo altamente disponible conllevaba crear antes un clúster de conmutación por error de Windows y, a continuación, ejecutar el programa de instalación de Exchange en modo de clúster. En este modo, el archivo DLL de recurso de clúster de Exchange (exres.dll) estaría registrado y permitiría la creación de un servidor de buzones de correo en clúster (conocido como servidor virtual de Exchange en versiones anteriores). Al implementar clústeres de almacenamiento compartido heredados o clústeres de copia única, era necesario realizar algunos pasos más para configurar el almacenamiento antes y después de crear el clúster de conmutación y, asimismo, después de crear el grupo de almacenamiento y el servidor de buzones de correo en clúster.

Exchange 2010 incluye un nuevo componente denominado Active Manager que proporciona una funcionalidad que sustituye las características de modelo de recursos y administración de conmutación que se obtenían de la integración con el servicio de clúster en versiones anteriores de Exchange. Para obtener más información acerca de Active Manager, consulte Descripción de Active Manager.

Volver al principio

Cambios en la alta disponibilidad de versiones anteriores de Exchange

Existen diversos cambios en la arquitectura principal de Exchange 2010 que producen un efecto directo tanto en la manera en que Exchange se configura para alta disponibilidad como en la forma en que se lleva a cabo la recuperación de sitio. Uno de los más reseñables es la eliminación de los servidores de buzones en clúster y el uso del modelo de recursos de clúster de conmutación por error de Windows. Entre los otros cambios, igualmente significativos, encontramos la globalización de las bases de datos y las mejoras en la tecnología de replicación continua integrada que se incluyó inicialmente en Exchange 2007.

Eliminación de los servidores de buzones en clúster

En Exchange 2010, Exchange deja de ser una aplicación en clúster, al tiempo que el modelo de recursos de clúster ya no se usa para la alta disponibilidad de Exchange. De igual modo, exres.dll y todos los recursos de clúster de Exchange que antes se proporcionaban ya no se incluyen, y lo mismo sucede con los servidores de buzones en clúster. En su lugar, Exchange 2010 usa su propio modelo interno de alta disponibilidad. Algunos componentes del clúster de conmutación por error de Windows se siguen usando, si bien ahora están integrados en otra funcionalidad de Exchange 2010.

Globalización de las bases de datos

En Exchange 2010, una base de datos está asociada a una única secuencia de registro dedicada, representada por una serie de archivos de registro de 1 MB nombrados de manera secuencial. El concepto de grupos de almacenamiento también ha desaparecido de Exchange 2010. La consecuencia de estos cambios es que las bases de datos de Exchange ya no comparten las secuencias de registros con el resto de bases de datos, dado que cuentan con una secuencia de registros dedicada.

Al contrario de lo que sucedía en versiones anteriores de Exchange, las bases de datos ya no están estrechamente vinculadas con un servidor de buzones de correo específico. Además, la identificación de las bases de datos ya no depende de los servidores de buzones de correo en los que residen y los nombres de los servidores dejan de formar parte de las identidades de las bases de datos. Estos cambios provocan que ahora las bases de datos sean objetos globales en Active Directory y en cada organización de Exchange. Al usar la Consola de administración de Exchange, ahora las bases de datos se administran desde el nodo Buzón en el nodo Configuración de la organización.

Cada servidor de buzones de correo puede hospedar un máximo de 100 bases de datos (que es el número combinado total de bases de datos activas y pasivas). El número total de bases de datos es igual al número combinado de bases de datos activas y pasivas en un servidor. La base de datos de recuperación no cuenta para el límite de base de datos de 100.

Cambios en la replicación continua de Exchange Server 2010 RTM

La tecnología de replicación continua, que se incorporó en Exchange 2007, también sigue disponible en Exchange 2010. Sin embargo, la característica ha evolucionado de forma considerable para admitir las nuevas funciones de disponibilidad y una mayor escalabilidad. A continuación se enumeran algunos de estos cambios en la arquitectura:

  • Dado que los grupos de almacenamiento se han quitado de Exchange 2010, ahora la replicación continua se produce en el nivel de base de datos. Exchange 2010 sigue usando una base de datos de Motor de almacenamiento extensible (ESE) que genera registros de transacción que se replican a una o varias ubicaciones y se reproducen en una o más copias de una base de datos de buzones. Cada base de datos de buzones de correo puede tener hasta 16 copias.

  • El trasvase de registros ya no usa el Bloque de mensajes del servidor (SMB) ni las notificaciones de sistema de archivos de Windows. El trasvase de registros ya no usa un modelo de extracción, donde la copia pasiva extrae de la copia activa un archivo de registro cerrado. En su lugar, la copia pasiva utiliza notificaciones basadas en TCP para notificar a la copia activa de los archivos que dicha copia pasiva necesita. A continuación, la copia activa envía los archivos de registro a cada copia pasiva configurada a través del socket TCP.

  • La replicación continua de Exchange 2010 usa un único puerto TCP definido por el administrador para la transferencia de datos. Además, Exchange 2010 incluye opciones integradas para el cifrado y la compresión de la red para la secuencia de datos.

  • La propagación ya no está restringida al uso de la copia activa de la base de datos. Las copias pasivas de bases de datos de buzones de correo ahora pueden especificarse como fuentes para la propagación y repropagación de copias de bases de datos.

  • Las copias de bases de datos sólo se ofrecen para bases de datos de buzones de correo. Para la redundancia y la alta disponibilidad de las bases de datos de carpetas públicas, recomendamos usar la replicación de carpetas públicas. A diferencia de CCR, donde no podía haber varias copias de una base de datos de carpetas públicas en el mismo clúster, puede usar la replicación de carpetas públicas para replicar bases de datos de carpetas públicas entre servidores en un DAG.

  • En Exchange 2007, el servicio de replicación de Microsoft Exchange se encargaba de reproducir los registros en las copias de base de datos pasivas. Al activarse la copia pasiva, la memoria caché de la base de datos que el servicio de replicación de Microsoft Exchange había creado como resultado de la actividad de reproducción se podría perder cuando el servicio de almacenamiento de información de Microsoft Exchange montara la base de datos en cuestión. De esta forma, la memoria caché de la base de datos pasaba al denominado estado frío. La memoria caché de la base de datos, que se usa para almacenar en caché las operaciones de lectura/escritura, es pequeña (está fría) durante este periodo. Por lo tanto, su capacidad para reducir las operaciones de E/S de lectura disminuye considerablemente En Exchange 2010, la funcionalidad de reproducción de copia pasiva que antes realizaba el servicio de replicación de Microsoft Exchange ahora ha pasado al servicio de almacenamiento de información de Microsoft Exchange. En consecuencia, existe una memoria caché de base de datos activa y disponible de forma inmediata para su uso tras un cambio o una conmutación por error.

Varios conceptos usados en la replicación continua de Exchange 2007 también están presentes en Exchange 2010. Entre ellos se incluyen los conceptos de administración de la conmutación por error, divergencia, uso del marcado de montaje de base de datos automático y uso de redes de replicación y de acceso de cliente (MAPI).

Cambios en la replicación continua de Exchange Server 2010 SP1

En la versión RTM de Exchange 2010 y en todas las versiones de Exchange Server 2007, la replicación continua funciona enviando copias de los archivos de registro generados por la copia de la base de datos activa a todas las copias de base de datos pasivas. A partir de Exchange 2010 SP1, esta forma de replicación continua se denomina replicación continua, modo de archivo. Asimismo, SP1 incorpora una forma nueva de replicación continua que se denomina replicación continua, modo de bloque. En modo de bloque, como cada actualización se escribe en el búfer de registro activo de la copia de base de datos activa; también se incluye en un búfer de registro de cada una de las copias de buzones pasivos. 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. Si un error afecta a la copia activa, las copias pasivas se habrán actualizado con casi toda o toda la información más reciente. No hace falta que la copia activa espere a que concluya la replicación para impedir que los problemas de replicación afecten a la experiencia del cliente.

El modo de bloque reduce drásticamente la latencia entre el intervalo de tiempo en que se hace un cambio en la copia activa y que dicho cambio se replica en las copias pasivas. Aparte de replicar determinadas escrituras de archivo de registro, el modo de bloque cambia el proceso de activación de una copia pasiva. Si al producirse un error una copia está en modo de bloque, el sistema utiliza cualquier contenido de registro parcial que esté disponible durante el proceso de activación. Eso elimina cualquier error en el archivo de registro actual de la copia activa.

El modo inicial de funcionamiento predeterminado es el modo de archivo. El modo de bloque esta activo sólo cuando la replicación continua está al día en modo de archivo. La copia de registros realiza automáticamente la transición de entrada y salida del modo de bloque. Cuando la copia pasiva solicita el archivo de registro actual, indica que la replicación continua está al día (la cola de copias es 0); en principio, el sistema debe pasar automáticamente de modo de archivo a modo de bloque.

Se puede determinar si una copia de base de datos pasiva está en modo de bloque observando el contador de rendimiento Modo de bloqueo de replicación continua: activo en el objeto de rendimiento Replicación de MSExchange. Cada copia de base de datos tiene su propia instancia de este contenedor. El valor del contador se define en 1 cuando la copia pasiva está en modo de bloque y en 0 cuando está en modo de archivo. También puede determinarse el valor de este contador mediante los cmdlets Get-Counter o Get-WMIObject, como se muestra en los ejemplos siguientes:

Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active"
Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

Cambios en la recuperación del elemento eliminado de transporte de Exchange 2007

El rol de servidor Transporte de concentradores de Exchange 2010 incluye una característica, denominada recuperación del elemento eliminado de transporte, que apareció por primera vez en Exchange 2007. El propósito de la recuperación del elemento eliminado de transporte es evitar la pérdida de datos, para lo cual mantiene una cola de todos los mensajes de correo electrónico recientes que se han enviado a usuarios cuyos buzones estaban protegidos mediante CCR o LCR. Cuando se produce una pérdida en cualquiera de estos entornos, la mayor parte de los datos que, en situaciones normales, se hubiera perdido a causa de este error se recupera automáticamente gracias a la recuperación del elemento eliminado de transporte.

El contenedor de transporte se usa sólo para bases de datos de buzones replicadas. No protege los mensajes enviados a las carpetas públicas ni los mensajes enviados a destinatarios en bases de datos de buzones que no se replican. La cola de la recuperación del elemento eliminado de transporte de una base de datos de buzones específica se encuentra en todos los servidores Transporte de concentradores de los sitios de Active Directory que contienen el DAG.

En Exchange 2007, los mensajes se retenían en el contenedor de transporte hasta que se llegaba al límite temporal definido por el administrador o al límite de tamaño. En Exchange 2010, el contenedor de transporte recibe información del canal de replicación para determinar qué mensajes se han entregado y replicado. Así, cuando un mensaje atraviesa los servidores Transporte de concentradores en su periplo hacia una base de datos de buzones de correo replicada y ubicada en un DAG, se conserva una copia en la cola de transporte (mail.que) hasta que los registros de transacción que representan al mensaje se han replicado correctamente y han sido inspeccionados por todas las copias de la base de datos de buzones de correo. Una vez que los registros se han replicado y todas las copias de base de datos los han inspeccionado, los mensajes de esos registros se truncan en el contenedor de transporte. Gracias a esto, la cola de la recuperación del elemento eliminado de transporte es más pequeña, por cuanto solo conserva copias de los mensajes cuyos registros de transacción aún no se han replicado.

Cada Active Manager del DAG control el valor de la última vez que se inspeccionó el registro en cada copia de base de datos pasiva. El cliente de Active Manager que se ejecuta en el servidor Transporte de concentradores obtiene esta información del Standby Active Manager (SAM) del DAG y la convierte en una marca de agua basada en tiempo. A continuación, el servidor Transporte de concentradores compara la hora de entrega del contenedor de transporte con la marca de agua Si la hora de entrega de un mensaje es más antigua que la marca de agua, el mensaje se trunca en el contenedor de transporte.

La recuperación del elemento eliminado de transporte también se ha mejorado para que tenga en cuenta los cambios que se producen en el rol de servidor Buzón de correo que permite que una sola base de datos de buzones de correo se mueva entre los sitios de Active Directory. Además, los DAG se pueden extender a varios sitios de Active Directory, de tal modo que una sola base de datos de buzones en un sitio de Active Directory podrá conmutar por error a otro sitio de Active Directory. Cuando esto sucede, las solicitudes de reenvío de la recuperación del contenedor de transporte se enviarán a los dos sitios de Active Directory: el original y el nuevo.

Cambios en el comportamiento de enrutamiento al ubicar Transportador de concentradores y Buzón de correo en un DAG

Cuando el servidor Transporte de concentradores comparte ubicación con un servidor de buzones de correo miembro de un DAG, se producen cambios en el comportamiento del enrutamiento a fin de asegurar que las características de resistencia en los dos roles de servidor van a proporcionar la protección necesaria para los mensajes enviados y recibidos por usuarios de ese servidor. El rol de servidor Transporte de concentradores se ha modificado de manera que ahora intenta volver a enrutar un mensaje para un servidor de buzones de correo local a otro servidor Transporte de concentradores en el mismo sitio, si el servidor Transporte de concentradores también es miembro del DAG y tiene una copia de la base de datos de buzones de correo montada localmente. Este salto adicional se agregó para colocar el mensaje en la recuperación del elemento eliminado de transporte de otro servidor Transporte de concentradores.

Por ejemplo, EX1 hospeda los roles de servidor Transporte de concentradores y Buzón de correo y es, además, miembro de un DAG. Cuando llega un mensaje en transporte para EX1 dirigido a un destinatario cuyo buzón también está en EX1, el transporte volverá a enrutar dicho mensaje a otro servidor Transporte de concentradores del sitio (por ejemplo, EX2) y ese servidor enviará el mensaje al buzón de EX1.

Hay un segundo cambio de comportamiento similar con respecto al servicio de entrega de correo de Microsoft Exchange. Este servicio se ha modificado para que no envíe mensajes a un rol de servidor Transporte de concentradores local cuando el servidor de buzones de correo o el servidor Transporte de concentradores sea miembro de un DAG. En este escenario, el comportamiento del transporte consiste en equilibrar la carga de solicitudes de entrega entre otros servidores Transporte de concentradores del mismo sitio de Active Directory y revertirlas al servidor Transporte de concentradores, en el caso de no haber otros servidores Transporte de concentradores disponibles en el mismo sitio.

Volver al principio

Alta disponibilidad en roles de servidor que no son Buzón de correo

La gran disponibilidad de los roles de servidor Transporte de concentradores, 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 e ida y vuelta de DNS, así como servidores, servicios y administración de infraestructuras proactivos. En términos generales, se puede conseguir alta disponibilidad para los roles de servidor Acceso de cliente, Transporte de concentradores, Transporte perimetral y Mensajería unificada mediante el uso de las siguientes estrategias y tecnologías:

  • Transporte perimetral   Puede implementar varios servidores Transporte perimetral y usar diversos registros de recursos MX de DNS para equilibrar la actividad a través de esos servidores. También puede usar el equilibrio de carga de red (NLB) para proporcionar equilibrio de carga y una alta disponibilidad a los servidores Transporte perimetral.

  • Acceso de cliente   Puede usar NLB o un dispositivo de equilibrio de carga de red basado en hardware de terceros para disfrutar de la máxima disponibilidad del servidor de acceso de cliente.

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

    • Servidor Transporte de concentradores a servidor Transporte de concentradores (dentro de la organización)   La comunicación entre servidores Transporte de concentradores dentro de una organización equilibra automáticamente la carga entre los servidores Transporte de concentradores que hay disponibles en el sitio de Active Directory de destino.

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

    • Servidor de mensajería unificada a servidor Transporte de concentradores   El servidor de mensajería unificada equilibra automáticamente la carga de las conexiones entre todos los servidores Transporte de concentradores que hay disponibles en el mismo sitio de Active Directory.

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

    Para obtener una mayor redundancia (por ejemplo, en aplicaciones que requieren retransmisión SMTP), puede crear un registro DNS (por ejemplo, retransmisión.empresa.com), asignar una dirección IP y usar un equilibrador de carga de hardware para redirigir esa dirección IP a varios servidores Transporte de concentradores. También puede usar NLB para los conectores de cliente en servidores Transporte de concentradores. Al utilizar un equilibrador de carga de hardware es preciso confirmar que no habrá tráfico interno de la organización atravesando el equilibrador de carga de hardware, ya que dicho tráfico usa algoritmos de equilibrio de carga integrados, tal y como se ha descrito anteriormente.

  • 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 harán una llamada a un servidor de mensajería unificada y si la llamada se rechaza, ésta pasará a otro servidor que proporcione redundancia en el momento de establecer la llamada.

Volver al principio

Resistencia de sitios

Exchange 2010 presenta una plataforma unificada para alta disponibilidad y resistencia de sitios. Al combinar la compatibilidad nativa de la resistencia de sitios de Microsoft Exchange 2010 con una planeación adecuada, es posible activar rápidamente un segundo centro de datos para atender los clientes del centro de datos en el que se ha producido un error. Un error en el sitio o el centro de datos no se administra igual que los tipos de errores que pueden provocar la conmutación por error de un servidor o una base de datos. En una configuración de alta disponibilidad, la recuperación automática es iniciada por el sistema, y el error, por lo general, deja el sistema de mensajería en un estado completamente funcional. Por otro lado, un error en el centro de datos se considera un evento de recuperación ante desastres. La recuperación debe realizarse y completarse de forma manual para que el servicio de cliente se restaure y para que la interrupción finalice. El proceso que realiza se denomina cambio de centro de datos. Como sucede con muchas situaciones de recuperación ante desastres, la planificación y la preparación anticipadas de un cambio de centro de datos pueden simplificar el proceso de recuperación y reducir la duración de la interrupción.

Para obtener información sobre cómo planear e implementar la resistencia de sitios, consulte Diseño de alta disponibilidad y resistencia de sitios, Implementación de alta disponibilidad y resistencia de sitio y Cambios en el centro de datos.

Volver al principio

Disponibilidad de un extremo a otro

Exchange 2010 también incluye muchas características diseñadas para aumentar la disponibilidad de un extremo a otro del sistema. Entre estas características se incluyen:

  • Redundancia de instantánea

  • Movimiento del buzón en línea

  • Protección flexible de buzón

  • Resincronización incremental

  • API de replicación de terceros

Redundancia de instantánea

Aparte de las mejoras realizadas en la recuperación del elemento eliminado de transporte y el comportamiento del enrutamiento descritas anteriormente, se ha agregado una nueva característica al servidor Transporte de concentradores llamada redundancia de instantánea. La redundancia de instantánea proporciona redundancia a los mensajes durante todo el tiempo en que están en tránsito. La solución implica una técnica similar a la de la recuperación del elemento eliminado de transporte. Con la redundancia de instantánea, la eliminación de un mensaje de la base de datos de transporte se retrasa hasta que el servidor de transporte verifica que todos los saltos siguientes de ese mensaje han completado la entrega. Si alguno de esos saltos da error antes de que se informe de que la entrega ha sido correcta, el mensaje se reenvía al paso siguiente para su entrega. Para obtener más información acerca de la redundancia de instantánea, consulte Descripción de redundancia de instantánea.

Movimiento del buzón en línea

Exchange 2010 incluye una nueva característica que le permite mover los buzones de forma asincrónica. En Exchange 2007, cuando se usaba el cmdlet Move-Mailbox para mover un buzón, dicho cmdlet se registraba en la base de datos tanto de origen como de destino y movía el contenido de un buzón a otro. Había varias desventajas en dejar que los cmdlets realizaran la operación de movimiento:

  • Los movimientos de los buzones tardaban horas en completarse y, mientras tanto, los usuarios no podían tener acceso a sus buzones.

  • Si la ventana de símbolo del sistema usada para ejecutar el cmdlet Move-Mailbox se cerraba, el movimiento finalizaba y debía volver a iniciarse desde el principio.

  • El equipo usado para realizar el movimiento participaba en la transferencia de datos. Si un administrador ejecutaba cmdlets desde su estación de trabajo, los datos del buzón fluían desde el servidor de origen a la estación de trabajo del administrador y, a continuación, al servidor de destino.

El nuevo cmdlet New-MoveRequest de Exchange 2010 sirve para realizar movimientos asincrónicos. A diferencia de Exchange 2007, los cmdlets no realizan el traslado real. El movimiento lo realiza el Servicio de replicación de buzones de Microsoft Exchange, un nuevo servicio que se ejecuta en el servidor de acceso de cliente. El cmdlet New-MoveRequest envía solicitudes al servicio de replicación de buzones de Microsoft Exchange. Para obtener más información acerca del movimiento de buzón en línea, consulte Descripción de solicitudes de movimiento.

Protección flexible de buzón

Se han producido varias modificaciones en la arquitectura principal de Exchange 2010 que afectan directamente a la manera de proteger las bases de datos de buzones y los buzones que éstas contienen.

Un cambio significativo es la eliminación de grupos de almacenamiento. En Exchange 2010, cada base de datos está asociada con una secuencia de registro, representada por una serie de archivos de registro de 1 MB. Cada servidor puede hospedar un máximo de 100 bases de datos.

Otro cambio significativo para Exchange 2010 es que las bases de datos ya no están estrechamente vinculadas con un servidor de buzones de correo específico. La movilidad de la base de datos amplía el uso de la replicación continua del sistema al replicar una base de datos en varios servidores diferentes. Esto proporciona una mejor protección de la base de datos y una mayor disponibilidad. En caso de que se produzcan errores, los otros servidores que tienen copias de la base de datos pueden montar la base de datos.

La posibilidad de disponer de varias copias de una base de datos hospedadas en múltiples servidores significa que, si dispone de un número suficiente de copias de bases de datos, puede utilizarlas como copias de seguridad. Para obtener más información acerca de esta estrategia, consulte Descripción de la copia de seguridad, restauración y recuperación ante desastres.

Resincronización incremental

Exchange 2007 incluía los conceptos de resistencia del registro perdido (LLR) y de reinicialización incremental. La resistencia del registro perdido es un componente interno de ESE que permite recuperar bases de datos de buzones de Exchange aun cuando uno o varios de los archivos de registro de transacción más recientes se hayan perdido o dañado. Asimismo, permite que una base de datos de buzones se monte incluso aunque los archivos de registro generados recientemente no estén disponibles. La resistencia del registro perdido funciona retrasando las escrituras en la base de datos hasta que se ha generado el número especificado de registros. De igual modo, retrasa las actualizaciones recientes de la base de datos durante un breve período. El tiempo que se retrasan las escrituras depende de la velocidad a la que se generen los registros.

Exchange 2007 también presentó el concepto de reinicialización incremental, que ofrecía la posibilidad de corregir divergencias en la secuencia de registros de transacción entre un grupo de almacenamiento de origen y otro de destino, confiando en la capacidad de respuesta con retraso de la resistencia del registro perdido. La reinicialización incremental no proporcionaba un medio para corregir divergencias en la copia pasiva de una base de datos después de que los registros divergentes se reprodujeran, lo que obligaba a realizar una reinicialización completa. A diferencia de Exchange 2007, no hay ningún nivel de pérdida de registros que precise una reinicialización completa en Exchange 2010.

En Exchange 2010, la resincronización incremental es el nuevo nombre para la característica que corrige divergencias de manera automática en copias de bases de datos, en las siguientes condiciones:

  • Después de una conmutación por error automática para todas las copias de una bases de datos configuradas.

  • Cuando se habilita una nueva copia y ya existen algunas bases de datos y archivos de registro en la ubicación de la copia.

  • Cuando se reanuda una replicación después de una suspensión o reinicio del servicio de replicación de Microsoft Exchange.

Gracias a estos cambios, ahora la resistencia del registro perdido está codificada de forma rígida en un archivo de registro para todas las bases de datos de buzones de Exchange 2010.

Cuando se detecta una divergencia entre una base de datos activa y una copia de la misma, la resincronización incremental realiza las siguientes tareas:

  • Busca el historial en la secuencia de archivos de registro para encontrar el punto de divergencia.

  • Busca las páginas de bases de datos cambiadas en la copia divergente.

  • Lee las páginas cambiadas de la copia activa y copia los archivos de registro necesarios de la copia activa.

  • Aplica los cambios de la página de base de datos a la copia divergente.

  • Ejecuta una recuperación en la copia divergente y vuelve a reproducir los archivos de registro necesarios en la copia de la base de datos.

API de replicación de terceros

Exchange 2010 también incluye una nueva 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 fabricante 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. No se admite el uso de la API fuera de estos límites. Además, la solución debe cumplir los correspondientes requisitos de compatibilidad de hardware de Windows (para la admisión no se necesita prueba de validación).

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 replicación de datos deben cumplir la directiva de compatibilidad de Microsoft, como se detalla en el artículo de Microsoft Knowledge Base 895847, Compatibilidad de la replicación de datos de varios sitios en Exchange Server (en inglés). Asimismo, las soluciones que usan el modelo de recursos de clúster de conmutación por error de Windows deben cumplir los requisitos de compatibilidad de clústeres 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 (en inglés).

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 asociado y busca información sobre la API de replicación de terceros, póngase en contacto con su representante de Microsoft. Para obtener información sobre productos de asociados para Exchange 2010, consulte la página de asociados de Microsoft Exchange.

Volver al principio

 © 2010 Microsoft Corporation. Reservados todos los derechos.