Descripción de alta disponibilidad y resistencia de sitios

  • Artículo

Se aplica a: Exchange Server 2010

Última modificación del tema: 2009-12-07

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

Disponibilidad de un extremo a otro

Terminología básica

Los siguientes términos son de aplicación:

  • 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
    Nuevo servicio que proporciona un extremo de MAPI para los clientes de Microsoft Outlook.
  • Resistencia de sitios
    Proceso manual de recuperación de desastres que se usa para recuperarse de un error de sitio global. 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 es una activación manual de una o varias bases de datos, mientras que una conmutación por error es una activación automática de una o varias bases de datos tras 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). Aún 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.

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 teniendo en mente el concepto de movilidad de base de datos, gracias al cual se expande el uso de la replicación continua del sistema en tanto que una base de datos se puede replicar a varios servidores diferentes agrupados entre sí. 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 (disponible de tres maneras: local, en clúster y en espera) que 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 2007

La tecnología de replicación continua subyacente que antes se hallaba en CCR y SCR continúa en Exchange 2010 y ha evolucionado para admitir nuevas características de alta disponibilidad. A continuación se enumeran algunos de estos cambios en la arquitectura:

  • Dado que los grupos de almacenamiento se han eliminado 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 puede contener un máximo de 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. Tampoco usa un modelo de extracción, donde la copia pasiva extrae de la copia activa un archivo de registro cerrado, sino que la copia pasiva usa notificaciones basadas en TCP para informar a la copia activa de los archivos de registro 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 que 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 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.

La recuperación del elemento eliminado de transporte se usa únicamente con bases de datos de buzones replicadas; es decir, no protege los mensajes enviados a las carpetas públicas, ni los 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 eran retenidos por la recuperación del elemento eliminado de transporte hasta que se alcanzaba el límite de tamaño o de tiempo establecido por el administrador, pero en Exchange 2010 la recuperación del elemento eliminado de transporte recibe información procedente de la canalización de la replicación para averiguar qué mensajes se han enviado 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 la canalización de la replicación informa al servidor Transporte de concentradores de que los registros de transacción que representan al mensaje se han replicado correctamente y que todas las copias de la base de datos de buzones de correo han inspeccionado dichos registros. Una vez que los registros se han replicado y todas las copias de base de datos los han inspeccionado, se trunca la recuperación del elemento eliminado 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.

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 elemento eliminado 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 envie 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

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áneas

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áneas 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áneas, 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 movimiento real, sino que lo efectúa 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.

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. Para obtener información sobre productos de asociados para Exchange 2010, consulte la página de asociados de Microsoft Exchange. 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.

Volver al principio