Exportar (0) Imprimir
Expandir todo

Nuevas características de alta disponibilidad de Exchange 2007 SP1

 

Se aplica a: Exchange Server 2007 SP1

Última modificación del tema: 2009-03-18

Microsoft Exchange Server 2007 Service Pack 1 (SP1) presenta varias características de alta disponibilidad, así como mejoras de las funciones ya existentes. Las características nuevas y mejoradas amplían los escenarios donde se pueden obtener datos y disponibilidad de servicios para las funciones de servidor de Exchange 2007. Los escenarios nuevos permiten a las organizaciones separar los escenarios de alta disponibilidad de los escenarios de recuperación de sitios e implementar configuraciones diseñadas de acuerdo con las necesidades específicas de la organización en cada área independiente.

En Exchange 2007 SP1 están disponibles las siguientes características nuevas de alta disponibilidad y mejoras de las características ya existentes:

  • Réplica continua en suspensión (SCR)

  • Compatibilidad con las siguientes características de Windows Server 2008:

    • Clústeres de conmutación por error de varias subredes

    • Protocolo de configuración dinámica de host (DHCP), Protocolo de Internet versión 4 (IPv4)

    • IPv6

    • Configuración de redes de clústeres de conmutación por error y de Exchange

    • Nuevos modelos de quórum (testigo de disco y recursos compartidos)

  • Replicación continua (trasvase e inicialización de registros) sobre una red de clústeres redundantes en un entorno de replicación continua de clústeres (CCR)

  • Elaboración de informes y supervisión de las mejoras

  • Mejoras del rendimiento

  • Mejoras del contenedor de transporte

  • Mejoras de la Consola de administración de Exchange

Cada una de estas características se describe más adelante en este tema, junto con vínculos a la documentación sobre su planificación, implementación y administración. En la tabla siguiente, se resume la compatibilidad de Exchange 2007 con respecto a características de clúster de conmutación por error en Windows Server 2003 y Windows Server 2008.

Características de clúster de conmutación por error compatibles con Exchange 2007 SP1

Windows Server 2003 Windows Server 2008 Compatibilidad de Exchange 2007

Quórum de disco compartido

No mayoritario: quórum de sólo disco

Se admite aunque no se recomienda en Windows Server 2008.

Quórum de conjunto de nodos mayoritario

Quórum de nodos mayoritarios

Admitida.

Quórum de conjunto de nodos mayoritarios con testigo de recursos compartidos

Quórum de nodos y recursos compartidos mayoritarios

Se admite y se recomienda para CCR.

Quórum de disco compartido o quórum de conjunto de nodos mayoritarios con testigo de recursos compartidos

Quórum de mayoría de nodos y discos

Se admite y se recomienda para clústeres de copia única (SCC).

Clústeres de 8 nodos

Clústeres de 16 nodos

Clústeres de 8 nodos sólo para entornos SCC. (CCR es un clúster de 2 nodos).

Recursos de direcciones IPv4

Recursos de direcciones IPv4 e IPv6

Se admite; no obstante, Windows Server 2008 sí admite el protocolo de túnel de IPv6 en IPv4, pero Exchange 2007 no lo admite.

Direcciones IPv4 estáticas

Direcciones DHCP-IPv4

Se admite, aunque no se recomienda para entornos de producción.

Se requiere subred única para cada red de clústeres

Se admiten varias subredes para las redes de clústeres

Se admite para SCC y CCR.

SCR es una característica nueva de Exchange 2007 SP1. SCR amplía las características de replicación continua existentes en Exchange 2007 RTM y permite nuevos escenarios de disponibilidad de datos para servidores de buzones de Exchange 2007. SCR utiliza la misma tecnología de trasvase y reproducción de registros que la replicación continua local (LCR) y la CCR para proporcionar opciones y configuraciones de implementación adicionales. SCR es similar a LCR y CCR, aunque tiene características únicas:

  • SCR admite varios destinos por grupo de almacenamiento. LCR y CCR admiten sólo un destino de replicación por grupo de almacenamiento (copia pasiva).

  • SCR permite a un administrador especificar un pequeño retraso para la replicación. Esto resulta de gran utilidad en distintos escenarios. Por ejemplo, en el caso de una conmutación por error con pérdidas de Nodo A a Nodo B, si los archivos de registro perdidos se han reproducido en el Nodo M remoto, sería preciso reinicializar el Nodo M. Sin embargo, si los registros se han copiado pero no se han reproducido, es posible que éstos se hayan eliminado y los nuevos archivos de registro se podrán copiar y reproducir más adelante. En este caso, no sería necesaria la reinicialización de la copia en el Nodo M.

  • A diferencia de CCR y LCR, no se puede realizar una copia de seguridad de una copia de SCR. Al utilizar SCR, se actualizan los encabezados de base de datos para copias de SCR y se truncan los archivos de registro al realizar copias de seguridad en el grupo de almacenamiento origen.

SCR permite utilizar la replicación continua para los datos del servidor de buzones desde un servidor de buzones independiente o en clústeres en un entorno SCC o CCR.

El proceso de activación de copias de datos de servidor de buzones de correo que SCR ha creado y mantenido es manual y se ha diseñado para casos de error grave (y no para simples interrupciones del servidor que se pueden solucionar mediante el reinicio u otro método rápido). Puede activar un destino de SCR utilizando la portabilidad de bases de datos, la opción de recuperación del servidor (Setup /m:RecoverServer) o, si se trata de un servidor de buzones de correo en clúster, la opción de recuperación correspondiente (Setup /RecoverCMS). La opción que elija se basará en su configuración y en el tipo de fallo que se produzca.

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

Windows Server 2008 incluye nuevas características de alta disponibilidad compatibles con Exchange 2007 SP1. En Windows Server 2008, las mejoras de clústeres de conmutación por error (conocidos como clústeres de servidores en Windows Server 2003 y versiones anteriores) tienen como objetivo simplificar los clústeres, haciéndolos más seguros y mejorando su estabilidad. Además, se ha simplificado la configuración y administración de clústeres y se han mejorado los componentes de seguridad, redes y almacenamiento de clústeres subyacentes. Si desea obtener una lista completa de las mejoras realizadas en los clústeres de conmutación por error, consulte Failover Clustering with Windows Server 2008 (en inglés).

Además de admitir Windows Server 2008 como plataforma de sistema operativo, Exchange 2007 SP1 presenta también compatibilidad con las siguientes características de clúster de conmutación por error de Windows Server 2008. La compatibilidad con estas características también se ha incluido en el programa de instalación de Exchange 2007 para la versión de línea de comandos (Setup.com) y la versión de interfaz gráfica de usuario (GUI) (Setup.exe, también conocido como Asistente para la instalación de Exchange Server 2007).

La agrupación en clústeres de conmutación por error de Windows Server 2008 introduce nuevas funcionalidades de red que constituyen un cambio importante en los métodos utilizados por los clústeres heredados. Por ejemplo, los clústeres de conmutación por error de Windows Server 2008 presentan compatibilidad con múltiples subredes. Al ejecutarse en un clúster de conmutación por error de Windows Server 2008, Exchange 2007 SP1 incluye compatibilidad con clústeres dispersos geográficamente para la conmutación por error en dos subredes. Esta compatibilidad incluye SCC, así como servidores de buzones en un entorno CCR.

Partiendo de la agrupación en clústeres de conmutación por error de Windows Server 2008, los nodos de clúster individuales se pueden ubicar en redes enrutadas independientes. Los recursos que dependan de recursos de dirección de IP (por ejemplo, recursos del nombre de red) deberán implementar un operador lógico O, ya que es poco probable que los nodos del clúster tengan conexión directa local a cada red conocida por el clúster. De esta manera, se facilita la conexión de los recursos de dirección IP y nombre de red cuando los servicios o las aplicaciones conmutan por error a nodos remotos.

importantImportante:
Todos los nodos de un entorno SCC o CCR deben estar en el mismo sitio de Active Directory. Aunque los clústeres de conmutación por error de Windows Server 2008 presentan compatibilidad con nodos del clúster para poder ser miembros de diferentes sitios de Active Directory, Exchange 2007 no admite esta configuración.

Si se utilizan clústeres de conmutación por error de varias subredes, las direcciones de IP asociadas a un recurso Nombre de red se registrarán dinámicamente en el Sistema de nombres de dominio (DNS) (si está configurado para actualizaciones dinámicas) cuando se conecten. Por lo tanto, sólo se devuelven a los clientes aquellos recursos de dirección IP que estén conectados. Debido a que los nodos de clúster se pueden ubicar en diferentes redes enrutadas y se han modificado los mecanismos de comunicación para utilizar protocolos de sesión fiables implementados en el Protocolo de datagramas de usuario (UDP) (unidifusión), los requisitos de red para clústeres dispersos geográficamente de Windows Server 2003 ya no son aplicables en Windows Server 2008. Como resultado, las organizaciones pueden implementar un entorno SCC o CCR en dos centros de datos físicos sin tener que utilizar tecnología de LAN virtual (VLAN) para poder abarcar las subredes.

Cuando se produce un movimiento o una conmutación por error para un servidor de buzones de correo en clúster implementado en un clúster de conmutación por error de varias subredes geográficamente dispersas, el nombre del servidor de buzones de correo en clúster se mantiene, pero no la dirección IP asignada a dicho nombre. La disponibilidad de este servidor para clientes y otros servidores dependerá de la propagación de la nueva dirección IP a través de DNS. La propagación de DNS puede llevar un tiempo. Por este motivo, se recomienda configurar un valor del período de vida (TTL) de 10 minutos para el registro de host en el DNS del servidor de buzones de correo en clúster.

Aunque los clientes internos de Microsoft Outlook no precisan perfiles nuevos o ser reconfigurados para conectarse con la nueva dirección IP, deberán esperar a que se borre su memoria caché de DNS para que la resolución del nombre del servidor de buzones de correo en clúster cambie la antigua dirección IP por la nueva. Una vez que la dirección IP se ha propagado a los servidores de DNS adecuados, la memoria caché de DNS de los clientes de Outlook se puede borrar utilizando el comando siguiente en la línea de comandos del cliente.

ipconfig /flushdns

En la agrupación en clústeres de conmutación por error de Windows Server 2008, la capacidad existe si los recursos de dirección IP del clúster pueden obtener su dirección a través de servidores DHCP y entradas estáticas. Si los nodos del clúster se han configurado para que obtengan sus direcciones IP a través de un servidor DHCP, el comportamiento predeterminado será obtener automáticamente una dirección IP para todos los recursos de dirección IP del clúster. Si el nodo del clúster ha asignado estáticamente las direcciones IP, los recursos de dirección IP del clúster deberán configurarse también con las direcciones IP estáticas. Por tanto, la asignación de recursos de dirección IP sigue la configuración del nodo físico y cada interfaz específica del nodo.

Windows Server 2008 y el servicio de clúster admiten IPv6. Se incluye la compatibilidad con recursos de dirección IP de IPv6 y IPv4 solos o en combinación con un clúster. Además, los clústeres de conmutación por error admiten también el protocolo de direccionamiento automático de túneles internos (ISATAP) y direcciones IPv6 que permitan el registro dinámico en DNS (registros host AAAA y la zona de búsqueda IP6.ARPA inversa). Actualmente, existen tres tipos de dirección IPv6: global, de sitio local y de vínculo local. Los registros dinámicos de DNS no se realizarán para las direcciones de vínculo local y, por tanto, estas direcciones no podrán utilizarse en un clúster.

noteNota:
Sólo se admite el uso de direcciones del protocolo de Internet versión 6 (IPv6) e intervalos de direcciones IP si Exchange 2007 SP1 está instalado en un equipo que ejecute Windows Server 2008, IPv6 y IPv4 están habilitados en dicho equipo y la red es compatible con ambas versiones de dirección IP. Si Exchange 2007 SP1 está instalado en esta configuración, todas las funciones de servidor podrán enviar y recibir datos de dispositivos, servidores y clientes que utilicen direcciones IPv6. Una instalación predeterminada de Windows Server 2008 permite la compatibilidad para IPv4 e IPv6. Si Exchange 2007 SP1 está instalado en Windows Server 2003, no se admiten las direcciones IPv6. Para obtener más información acerca de la compatibilidad de Exchange 2007 SP1 con direcciones IPv6, consulte Compatibilidad con IPv6 en Exchange 2007 SP1 y SP2.

Al configurar un entorno SCC o CCR para Exchange 2007 SP1, tenga en cuenta los siguientes requisitos:

  • IPv6 y DHCP IPv4 sólo se admiten en Windows Server 2008. No se pueden utilizar si Exchange 2007 se ejecuta en Windows Server 2003.

  • Windows Server 2008 y el servicio de clúster no admiten DHCP IPv6. Como resultado, Exchange 2007 tampoco lo admite. Sólo se admiten las direcciones IPv6 dinámicas asignadas por el sistema.

  • Windows Server 2008 y el servicio de clúster admiten las direcciones IPv6 estáticas. No obstante, no es recomendable utilizar estas direcciones. Por tanto, Exchange 2007 no admite la configuración de direcciones IPv6 estáticas durante la instalación.

  • La agrupación en clústeres de Windows Server 2008 admite el protocolo de túnel de IPv6 en IPv4, aunque el programa de instalación de Exchange no permite crear este tipo de recurso de dirección IP.

El programa de instalación se ha modificado en Exchange 2007 SP1 para que admita los cambios anteriormente descritos. Cuando utilice el Asistente para la instalación de Exchange Server 2007, observe que existen páginas y campos adicionales para configurar los recursos de dirección IP y nombre de red del clúster. Además, las opciones /NewCMS y /RecoverCMS para Setup.com se han actualizado para admitir nuevos parámetros opcionales que se describen en la tabla siguiente.

En Exchange 2007 SP1, se han agregado parámetros opcionales para /NewCMS y /RecoverCMS

Parámetro Descripción

CMSIPV4Addresses

Lista separada por comas que se utiliza para especificar una o dos direcciones IPv4 estáticas para el servidor de buzones de correo en clúster. Si se especifican dos direcciones estáticas, éstas deben estar en diferentes subredes.

CMSIPV4Networks

Lista separada por comas que se utiliza para especificar uno o dos nombres de red de clústeres IPv4. Estos nombres se utilizarán en la creación de recursos DHCP-IPv4.

CMSIPV6Networks

Lista separada por comas que se utiliza para especificar uno o dos nombres de red de clústeres IPv6. Estos nombres se utilizarán en la creación de recursos IPv6. Este parámetro no se puede utilizar con los parámetros CMSIPV4Addresses o CMSIPV4Networks.

noteNota:
Los parámetros CMSIPV4Addresses y CMSIPV4Networks son exclusivos.

El parámetro CMSIPAddress, que era obligatorio para /NewCMS y /RecoverCMS en la versión RTM de Microsoft Exchange Server 2007, todavía se utiliza para especificar una única dirección IPv4 estática para el servidor de buzones de correo en clúster. Sin embargo, en Exchange 2007 SP1, el parámetro CMSIPAddress es opcional, ya que basta con especificar cualquiera de los cuatros parámetros disponibles en el programa de instalación.

Los parámetros de la tabla anterior sólo se pueden utilizar en Windows Server 2008.

Cuando se producen problemas de red, éstos pueden interferir en la comunicación entre los nodos de clúster. Un pequeño conjunto de nodos puede establecer comunicación en una parte de la red y, sin embargo, es posible que no pueda comunicarse con otro conjunto de nodos ubicados en otra parte de la red. Esta situación puede ocasionar graves problemas. En esta situación, al menos uno de los conjuntos de nodos debe dejar de ejecutarse como un clúster, aunque los conjuntos de nodos no dispongan de información exacta sobre el estado de otros nodos.

Para evitar problemas ocasionados por una división en el clúster, el software de clústeres requiere que cualquier conjunto de nodos ejecutado como un clúster utilice un algoritmo de voto para determinar si, en un momento específico, dicho conjunto tiene quórum. Debido a que un clúster determinado tiene un conjunto de nodos y una configuración de quórum específicos, el clúster sabrá cuántos votos constituyen una mayoría (un quórum). Si el número es inferior a la mayoría, el clúster deja de ejecutarse. Los nodos continuarán escuchando la presencia de otros nodos, en caso de que aparezca de nuevo otro nodo en la red, aunque no funcionarán como un clúster hasta que exista quórum.

La configuración de quórum en un clúster de conmutación por error determina el punto en el que muchos errores detendrán el clúster. En este contexto, se trata de errores de nodos o, en algunos casos, de un testigo de disco o de recursos compartidos (que contiene una copia de la configuración del clúster). Windows Server 2008 le permite elegir de entre cuatro posibles configuraciones de quórum:

  • Mayoría de nodos   Este modelo se recomienda para clústeres con un número impar de nodos. Puede soportar errores de la mitad de nodos menos 1. Por ejemplo, un clúster de 7 nodos puede admitir errores en 3 nodos.

  • Mayoría de nodos y disco   Este modelo se recomienda para clústeres con un número par de nodos. Puede soportar errores de la mitad de los nodos si el testigo de disco permanece conectado. Por ejemplo, un clúster de 6 nodos con un testigo de disco puede soportar errores de 3 nodos. También puede soportar errores de la mitad de los nodos menos 1 si el testigo de disco se desconecta o muestra error. Por ejemplo, un clúster de 6 nodos que muestra fallo del testigo de disco puede soportar errores de 2 nodos (3-1 = 2).

  • Mayoría de nodos y recursos compartidos   Este modelo se ha diseñado para clústeres con configuraciones especiales y se recomienda para servidores de buzones de correo en clúster en un entorno CCR. Funciona de igual modo que el modelo Mayoría de nodos y disco, aunque en lugar de un testigo de disco utiliza un testigo de recursos compartidos.

  • Sin mayoría: sólo disco   Este modelo, aunque se admite, no es recomendable. Puede soportar errores de todos los nodos excepto 1. Sin embargo, esta configuración no se recomienda debido a que el disco es el único punto de error.

En Exchange 2007 RTM, la copia e inicialización de todos los archivos de registro de transacciones en un entorno CCR tiene lugar en la red pública. Esta configuración presenta los siguientes límites:

  • Si el nodo pasivo no está disponible durante varias horas, se puede crear un número significativo de registros que deben transferirse. La transferencia de estos registros debe ser lo más rápida posible cuando el nodo pasivo esté disponible. Al copiar los registros a la red pública, la transferencia de los registros competirá con el tráfico de cliente. Esto afecta al tráfico de cliente y ralentiza la resincronización.

  • Si la red pública presenta error, la conmutación por error tendrá pérdidas, aunque los datos de registro estén disponibles.

  • El uso de una red aislada para la comunicación de registros le permite ofrecer seguridad para los datos de mensajería sin necesidad de cifrado y sin experimentar la penalización de rendimiento asociada.

  • En algunos casos, pueden producirse tormentas de registros. En tales casos, el sistema experimenta una carga de elevada replicación poco habitual. Esta situación puede provocar escasez de clientes si los datos de registro deben comunicarse a través de la misma red utilizada para la comunicación con clientes.

No todos estos problemas ocurrirán con la misma frecuencia. No obstante, se garantiza que el primer problema ocurrirá regularmente debido a que los nodos pasivos se desconectan para la ejecución del mantenimiento regular.

Exchange 2007 SP1 minimiza los efectos de los problemas anteriores permitiendo al administrador crear una o varias redes mixtas en el clúster (por ejemplo, una red de clústeres que admite tráfico de latidos de clústeres internos y tráfico de cliente) para el transporte de registros. Exchange 2007 SP1 permite también a un administrador indicar una red específica para la inicialización.

noteNota:
Las redes de clústeres que se utilizan para el trasvase y la inicialización de registros deben estar configuradas como redes mixtas. Una red mixta es una red de clústeres configurada tanto para tráfico de clúster (latidos) como para tráfico de acceso de cliente. Además, en el adaptador de red que se va a configurar con un nombre de host de replicación continua, el administrador debe activar la casilla Registrar estas direcciones de conexiones en DNS en el cuadro de diálogo de propiedades avanzadas de TCP/IP. El servidor DNS utilizado por el adaptador de red puede estar ubicado en la red pública o privada; sin embargo, independientemente de cuál sea su ubicación, debe estar accesible para ambos nodos para que pueda realizarse la resolución de nombre de host.

La compatibilidad con la copia de archivos de registro en una red mixta se configura mediante un nuevo cmdlet del Shell de administración de Exchange denominado Enable-ContinuousReplicationHostName. De forma similar, la desactivación de esta característica se logra mediante el cmdlet Disable-ContinuousReplicationHostName. Una vez que exista un servidor de buzones de correo en clúster en un entorno CCR, un administrador podrá ejecutar Enable-ContinuousReplicationHostName en ambos nodos del clúster y especificar las direcciones IP y nombres de host adicionales, que se crearán en los grupos de clústeres dedicados asociados con cada nodo. Tras esta tarea, el servicio de replicación de Microsoft Exchange utilizará la red recién creada para copiar registros poco después de la configuración y la confirmación del correcto funcionamiento de la nueva red. Si se crean varias redes, el servicio de replicación de Microsoft Exchange seleccionará aleatoriamente una de ellas. Si la red especificada deja de estar disponible, el servicio de replicación de Microsoft Exchange utilizará automáticamente otras redes de replicación o, si no hay ninguna disponible, utilizará la red pública para el trasvase de registros en 5 minutos. (La detección de la red del servicio de replicación de Microsoft Exchange se realiza cada 5 minutos). Cuando la red de replicación preferida se encuentre de nuevo disponible, el servicio de replicación de Microsoft Exchange volverá a utilizarla automáticamente para el trasvase de registros. Para obtener más información sobre estos cmdlets, consulte Enable-ContinuousReplicationHostName y Disable-ContinuousReplicationHostName.

La compatibilidad con la inicialización en una red de clústeres redundantes se configura mediante el cmdlet Update-StorageGroupCopy, que se ha actualizado en Exchange 2007 SP1 para incluir un parámetro nuevo denominado DataHostNames. Este parámetro se utiliza para especificar la red de clústeres que debe utilizarse para la inicialización. Para obtener más información acerca de los cambios realizados en el cmdlet Update-StorageGroupCopy de Exchange 2007 SP1, consulte Update-StorageGroupCopy.

Una vez creada una red de clústeres para la replicación continua, puede utilizar el cmdlet Get-ClusteredMailboxServerStatus para ver información actualizada sobre las redes de clústeres que se han habilitado para la actividad de replicación continua. Entre los nuevos detalles del resultado se incluyen:

  • OperationalReplicationHostNames:{Host1,Host2,Host3}

  • FailedReplicationHostNames:{Host4}

  • InUseReplicationHostNames:{Host1,Host2}

Para obtener más información acerca de los cambios realizados en el cmdlet Get-ClusteredMailboxServerStatus de Exchange 2007 SP1, consulte Get-ClusteredMailboxServerStatus.

Para obtener más información acerca de la habilitación de redes de clústeres para la replicación continua en Windows Server 2003, consulte Cómo habilitar redes de clúster redundantes para la inicialización y el transporte de registros en Windows Server 2003.

Para obtener más información acerca de la habilitación de redes de clústeres para la replicación continua en Windows Server 2008, consulte Cómo habilitar redes de clúster redundantes para la inicialización y el transporte de registros en Windows Server 2008.

Para obtener más información acerca de la deshabilitación de redes de clústeres para la replicación continua, consulte Cómo deshabilitar la replicación continua de una red de clústeres.

Exchange 2007 SP1 introduce también varios cambios que mejoran la capacidad de administración de Exchange 2007. Se mejoran las características de elaboración de informes del clúster en Exchange 2007 RTM y se incluye una funcionalidad adicional diseñada para la supervisión proactiva de entornos de replicación continua. Específicamente, los cambios y las mejoras corrigen deficiencias conocidas con el cmdlet Get-StorageGroupCopyStatus, introducen un nuevo cmdlet denominado Test-ReplicationHealth y ofrecen una mayor visibilidad en la ventana de pérdidas cubierta por el contenedor de transporte. Para obtener más información acerca de estas mejoras de elaboración de informes y supervisión, consulte Supervisión de la replicación continua.

Se han realizado mejoras de rendimiento en Exchange 2007 SP1 que benefician a las implementaciones de alta disponibilidad. Estas mejoras incluyen:

  • Reducciones de E/S en los discos que contienen copias pasivas de grupos de almacenamiento en entornos de replicación continua   En Exchange 2007 SP1, el diseño de la arquitectura de replicación continua se ha modificado de forma que la memoria caché de la base de datos se conserve en el nodo pasivo, entre los lotes de actividad de reproducción de registros. La persistencia de la memoria caché de la base de datos entre lotes de actividad de reproducción de registros permite al servicio de replicación de Microsoft Exchange aprovechar las características de almacenamiento en caché de la base de datos del motor de almacenamiento extensible (ESE), que a su vez, reduce la entrada/salida (E/S) de los discos que tiene lugar en los números de unidad lógica (LUN) de la copia pasiva. Por el contrario, en Exchange 2007 RTM, se crea una nueva caché de base de datos para cada lote de actividad de reproducción de registros, que en algunos casos hace que la actividad de E/S del disco en el nodo pasivo sea el doble o el triple que la del nodo activo.

    Desplazamiento más rápido de servidores de buzones de correo en clúster entre nodos en un entorno CCR   Estas mejoras permiten a los servidores de buzones de correo en clúster desplazarse entre nodos en dos minutos o menos. Esto incluye los desplazamientos realizados por un administrador (utilizando el cmdlet Move-ClusteredMailboxServer) y las conmutaciones por error administradas por el servicio de clúster. Para conseguir desplazamientos rápidos en un entorno CCR, las bases de datos se desconectan sin necesidad de vaciar la caché de la base de datos. En un SCC, se tarda aproximadamente cinco minutos en trasladar el servidor de buzones en clúster. El vaciado de la memoria caché de la base de datos continúa produciéndose antes de mover el servidor de buzones de correo en clúster. Se trata de un vaciado oportunista que permite a los clientes permanecer conectados a la base de datos. Este comportamiento reduce el tiempo de inactividad que se produce al mover el servidor de buzones de correo en clúster a otro nodo.

    Durante el proceso de conmutación por error, se registra dos veces el id. de evento 9868 para indicar el estado de la operación de vaciado y también se registra el id. de evento 113 para indicar el estado de la replicación. Estos eventos son similares a los siguientes:

     

    Id. de evento: 9868

    Origen: MSExchangeIS

    Categoría: General

    Escriba: Información

    Descripción: El intento de vaciar la memoria caché del servidor "<MailboxServerName>" se completó con 0 grupo(s) de almacenamiento que no pudieron llegar a la profundidad de control deseada.

     

    Id. de evento: 9868

    Origen: MSExchangeIS

    Categoría: General

    Escriba: Información

    Descripción: El intento de vaciar la memoria caché del servidor "<MailboxServerName>" se completó con 2 grupo(s) de almacenamiento que no pudieron llegar a la profundidad de control deseada.

     

    Id. de evento: 113

    Origen: MSExchangeRepl

    Categoría: Move (mover)

    Escriba: Información

    Descripción: No se ha completado el vaciado de la caché del almacén de información antes de mover el servidor de buzones en clúster '<MailboxServerName>'. Datos: Grupo de almacenamiento '<MailboxServerName>\<StorageGroupName>': el inicio de la profundidad de control fue 19 y la finalización, 17.

    Grupo de almacenamiento '<MailboxServerName>\<SecondStorageGroupName>': el inicio de la profundidad de control fue 19 y la finalización, 13.

El volcado de archivos transporte es una característica de la función del servidor Transporte de concentradores. El contenedor de transporte mantiene una cola de mensajes que se han entregado recientemente a los destinatarios cuyo buzón de correo se encuentra en un servidor de buzones de correo en clúster en un entorno CCR. Esta cola está vinculada al tiempo de almacenamiento del correo y al espacio total usado. Al producirse una conmutación por error sin pérdidas, el servidor de buzones de correo en clúster solicita automáticamente a cada servidor de transporte de concentradores del sitio Active Directory el reenvío de correo de la cola del contenedor de transporte.

En Exchange 2007 SP1, la característica del contenedor de transporte se ha mejorado de la siguiente manera:

  • Compatibilidad con LCR   El contenedor de transporte incluye ahora compatibilidad con las implementaciones LCR. A diferencia de CCR, donde la solicitud de reenvío del contenedor de transporte es una parte automática del proceso de recuperación, el proceso en un entorno LCR es manual. El cmdlet Restore-StorageGroupCopy se ha actualizado en Exchange 2007 SP1 para incluir la petición de reenvío del contenedor de transporte. Por consiguiente, cuando un administrador activa una copia pasiva de un grupo de almacenamiento en un entorno LCR con el cmdlet Restore-StorageGroupCopy, la solicitud de reenvío del contenedor de transporte tiene lugar como parte del proceso de activación.

  • Estadísticas del contenedor de transporte   Para informar mejor a un administrador antes de recuperar un servidor al que le faltan archivos de registro, el contenedor de transporte se ha mejorado para incluir información estadística sobre el estado actual de todos los servidores de transporte de concentradores que contengan mensajes para un grupo de almacenamiento afectado. Estas estadísticas incluyen el número de mensajes, así como la antigüedad del mensaje más antiguo, disponible en cada servidor de transporte de concentradores en el sitio de Active Directory. Estas estadísticas se pueden ver cuando se utiliza un parámetro nuevo en el cmdlet Get-StorageGroupCopyStatus, denominado DumpsterStatistics. Cuando se utiliza este valor nuevo, el resultado de Get-StorageGroupCopyStatus incluirá estadísticas del contenedor de transporte procedentes de todos los archivos de transporte de concentradores accesibles y una lista de los servidores de transporte de concentradores a los que no se puede obtener acceso. Los servidores accesibles se enumerarán en una estructura de varios valores denominada DumpsterStatistics y los servidores a los que no se puede obtener acceso se enumerarán como una cadena de varios valores denominada DumpsterStatisticsNotAvailable, tal como se ilustra a continuación:

    DumpsterStatistics: {HUB1 (la marca de tiempo más antigua; número de elementos en el contenedor; tamaño del contenedor), HUB2 (la marca de tiempo más antigua; número de elementos en el contenedor; tamaño del contenedor), HUB3 (la marca de tiempo más antigua; número de elementos en el contenedor; tamaño del contenedor)}

    DumpsterStatisticsNotAvailable: {HUB4,HUB5}

    En el ejemplo anterior, la marca de tiempo más antigua es la hora a la que se recibió el mensaje en el servidor de transporte de concentradores y no la hora a la que se entregó originalmente el mensaje al servidor de buzones de correo.

    El cmdlet Get-StorageGroupCopyStatus incluye también una nueva estructura de varios valores denominada OutstandingDumpsterRequests, que incluye servidores de transporte de concentradores con solicitudes pendientes y el intervalo de tiempo (bajo–alto) para las solicitudes pendientes, tal como se ilustra a continuación:

    OutstandingDumpsterRequests: {HUB1 (time-low;time_high), HUB5 (time_low;time_high)}

Exchange 2007 SP1 incluye nuevos elementos de GUI en la Consola de administración de Exchange que se han diseñado para mejorar la experiencia de administración y configuración de servidores de buzones de correo en clúster. Estas mejoras incluyen:

  • Asistente para administrar servidor de buzones de correo en clúster   Este asistente se utiliza para mover, detener o iniciar un servidor de buzones de correo en clúster, tanto en un entorno CCR como SCC. La funcionalidad para mover y detener incluye además los campos opcionales para comentarios del administrador, que permiten a un administrador introducir la razón por la cual se va a mover o detener dicho servidor. Este asistente equivale a utilizar los siguientes cmdlets de la Consola de administración de Exchange:

    • Move-ClusteredMailboxServer

    • Stop-ClusteredMailboxServer

    • Start-ClusteredMailboxServer

  • Administrar la replicación continua   Se han agregado controles de interfaz de usuario adicionales a la Consola de administración de Exchange que permiten a un administrador suspender, reanudar, actualizar y restaurar la replicación continua. Estos controles equivalen a utilizar los siguientes cmdlets de la Consola de administración de Exchange:

    • Suspend-StorageGroupCopy

    • Resume-StorageGroupCopy

    • Update-StorageGroupCopy

    • Restore-StoreGroupCopy

    Puede utilizar estos cmdlets y las tareas correspondientes de la Consola de administración de Exchange para administrar la replicación continua, tanto en un entorno LCR como CCR.

    noteNota:
    En un entorno CCR, el asistente para actualizar la copia del grupo de almacenamiento está disponible sólo desde el nodo pasivo, mientras que el asistente para restaurar la copia del grupo de almacenamiento únicamente está disponible desde el nodo activo.
  • Ficha Servidor de buzones de correo en clúster   Se ha agregado una ficha nueva al cuadro de diálogo Propiedades del servidor para los servidores de buzones de correo que existen en un clúster. Esta información está disponible para entornos CCR y SCC. La ficha nueva proporciona información detallada sobre el servidor de buzones de correo en clúster y permite a un administrador configurar el valor de la propiedad AutoDatabaseMountDial para los servidores de buzones de correo en clúster de un entorno CCR. Gran parte de la información mostrada en la ficha nueva está disponible también con el cmdlet Get-ClusteredMailboxServerStatus. Para obtener más información acerca de la ficha del servidor de buzones de correo en clúster, consulte Propiedades del servidor > Ficha Servidor de buzones de correo en clúster.

  • Página Replicación continua en clúster   Se ha agregado una página nueva al cuadro de diálogo Propiedades del grupo de almacenamiento para servidores de buzones de correo que se implementan en un entorno CCR. La nueva página de propiedades proporciona información detallada sobre el estado de la replicación continua en el clúster. Para obtener más información acerca de la página de replicación continua en clúster, consulte Propiedades del grupo de almacenamiento > Página Replicación continua en clúster.

Windows Server 2008 incluye varias características que han mejorado o han cambiado de nombre. Para obtener información acerca de los cambios de características entre Windows Server 2003 y Windows Server 2008, consulte Cambios terminológicos.

 
¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft