Diseño de la replicación continua de clústeres

 

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

Última modificación del tema: 2008-07-23

Aunque la implementación de la replicación continua en clúster (CCR) es similar a la de la replicación continua local (LCR) y la de un clúster de copia única (SCC), es necesario tener en cuenta algunas diferencias importantes. Hay requisitos generales que debe cumplir CCR, así como requisitos de hardware, software, redes y clústeres que también se deben cumplir.

Requisitos generales para la replicación continua en clúster

Antes de implementar la CCR, asegúrese de cumplir los siguientes requisitos generales del sistema:

• Se debe usar una base de datos única por grupo de almacenamiento. Al crear un grupo de almacenamiento en un entorno de CCR, éste sólo puede contener una única base de datos. Este enfoque crea una topología de almacenamiento de Microsoft Exchange más manejable que incrementa la capacidad de recuperación.

• Se debe estar ejecutando el Sistema de nombres de dominio (DNS). En condiciones ideales, el servidor DNS debería admitir actualizaciones dinámicas. Si el servidor DNS no las admite, debe crear un registro de host DNS (A) para cada servidor de buzones de correo en clústeres y uno para el mismo clúster. En caso contrario, Exchange no funcionará correctamente. Para obtener más información acerca de cómo configurar DNS para Exchange, consulte el artículo 322856 de Microsoft Knowledge Base, Cómo configurar DNS para usar con Exchange Server.

• Si los nodos del clúster pertenecen a una zona del servicio de nombres de directorios que tiene un nombre diferente al nombre del dominio de servicio de directorio Active Directory al que se conectó el equipo, la propiedad DNSHostName no incluye de forma predeterminada el nombre del subdominio. En este caso, es posible que necesite cambiar la propiedad DNSHostName para garantizar que algunos servicios, como el Servicio de replicación de archivos (FRS), funcionen correctamente. Para obtener más información, consulte el artículo 240942 de la Knowledge Base, La propiedad DNSHostName de Active Directory no incluye subdominio.

• Todos los nodos del clúster deben ser servidores pertenecientes al mismo dominio. Microsoft Exchange Server 2007 no es compatible con los nodos que también son servidores de Active Directory o nodos que pertenezcan a diferentes dominios de Active Directory.

• El clúster debe estar formado antes de la instalación de Exchange 2007. Para obtener información acerca de la creación de un clúster de conmutación por error de Windows Server 2008, consulte Instalación de la replicación continua en clúster en Windows Server 2008. Para obtener información acerca de la creación de un clúster de conmutación por error de Windows Server 2003, consulte Instalar un clúster de copia única.

• Los nombres de servidor de buzones de correo en clúster (CMS) deben tener un máximo de 15 caracteres.

• El clúster en el que está instalado Exchange 2007 no puede contener Exchange Server 2003, Exchange 2000 Server ni ninguna versión compatible con clústeres de Microsoft SQL Server. No se admite ejecutar Exchange 2007 en un clúster con cualquiera de estas aplicaciones. Se admite ejecutar Exchange 2007 en un clúster con Express Edition de SQL Server 2005 u otra aplicación de base de datos (como Access de Microsoft Office), siempre que la aplicación de la base de datos no esté en clúster.

• Antes de instalar Exchange 2007, asegúrese de que la carpeta en la que instalará los datos de Exchange esté vacía.

• Debe instalar la misma versión de Exchange 2007 en todos los nodos del clúster que estén configurados como hosts de un servidor de buzones en clúster. Además, el sistema operativo y los archivos de Exchange deben estar instalados en las mismas rutas de acceso y unidades para todos los nodos del clúster. Esto requiere que todos los equipos tengan una configuración de disco similar, aunque no idéntica.

• La cuenta de Servicio de clúster debe ser miembro del grupo Administradores local en cada nodo que pueda hospedar un servidor de buzones de correo en clúster.

• No instale, cree ni mueva recursos del grupo de clústeres predeterminado al grupo de recursos que contenga el servidor de buzones de correo en clúster. Ni tampoco instale, cree ni mueva recursos del grupo que contenga el servidor de buzones de correo en clúster al grupo de clústeres predeterminado. El grupo de clústeres predeterminado sólo debe contener la dirección IP del clúster, el nombre de la red y recursos de quórum. No se admite el movimiento ni la combinación de recursos con el grupo de clústeres predeterminado.

  Importante

  Los clústeres en los que se ejecuten versiones anteriores de Exchange necesitan una instancia en cluster del Coordinador de transacciones distribuidas de Microsoft (MSDTC). Exchange 2007 elimina el requisito del recurso MSDTC en clúster. Los servidores de buzones de correo en clúster en un entorno CCR no usan ni necesitan tener el recurso MSDTC instalado en el clúster de conmutación por error. Es posible que las aplicaciones de terceros precisen un recurso MSDTC debido a las dependencias de COM+. En Windows Server 2003, el recurso de clúster MSDTC requiere el uso del almacenamiento compartido en el clúster. No es recomendable agregar un almacenamiento compartido a un entorno CCR. Windows Server 2008 proporciona una instancia MSDTC no en clúster local que elimina el requisito de almacenamiento compartido en un clúster de conmutación por error de Windows Server 2008. Para obtener más información acerca de los cambios de MSDTC en Windows Server 2008, consulte la ayuda de Windows Server 2008.

Requisitos de hardware para la replicación continua en clúster

Para obtener información general acerca del planeamiento de hardware, consulte Planeación de configuraciones del procesador y Planear el almacenamiento en disco. Los requisitos de hardware específicos de entornos de CCR son los siguientes:

• Si se usa un quórum de Conjunto de nodos mayoritario (MNS) con el testigo de recurso compartido en Windows Server 2003, sólo pueden existir dos nodos en el clúster. Si sólo existe un nodo o más de dos nodos en el clúster, la característica de testigo de recurso compartido del quórum de MNS no se puede usar. En cambio, se deberá usar un quórum de MNS tradicional, que requiere tres nodos o más en el clúster.

• Cuando se usa quórum de nodos y archivos compartidos mayoritarios en Windows Server 2008, sólo pueden existir dos nodos en el clúster. Si sólo existe un nodo o más de dos nodos en el clúster, no se puede usar el quórum de nodos y archivos compartidos mayoritarios. En su lugar, se debe usar un quórum de nodos mayoritarios, que requiere tres nodos o más en el clúster.

  Nota

  Se recomienda usar un clúster de conmutación por error de dos nodos que use el quórum de MNS con testigo de recurso compartido, o el quórum de nodos y archivos compartidos mayoritarios. De este modo se elimina la necesidad de tener un tercer noto votante en el clúster.

• Los servidores usados se deben enumerar en el Catálogo de productos probados de Microsoft Windows para el sistema operativo en el que se vayan a instalar. Sin embargo, se no se usa almacenamiento compartido en el clúster, no será necesario enumerar los servidores en la categoría Clúster.

• Los dos servidores que hospedan las funciones del servidor de buzones deben ser comparables, pero no idénticos en:

  • CPU

  • Memoria

  • Capacidad de I/O (entrada/salida)

  • Conexión de red

  • Proveedor

  • Almacenamiento disponible en disco, lo que incluye espacio y funcionalidad de E/S

Requisitos de quórum para la replicación continua en clúster

Generalmente, las aplicaciones en clúster son independientes del tipo de quórum que usa el clúster en el que están instaladas. Cuando diseñe el componente quórum para el entorno de replicación continua en clúster, tenga en cuenta las recomendaciones y los requisitos siguientes:

• En Windows Server 2008, se recomienda el quórum de Recursos de nodos y archivos compartidos mayoritarios (MNS) como tipo de quórum para la CCR.

• En Windows Server 2003, se recomienda el quórum de MNS con testigo de recurso compartido como tipo de quórum para la CCR.

Si no se usa ninguno de los tipos de quórum anteriores para la CCR, no será necesario enumerar los nodos en el Catálogo de productos probados de Microsoft Windows Server.

Si se usa un quórum de almacenamiento compartido para la CCR, se deberá enumerar el sistema completo en el Catálogo de productos probados de Microsoft Windows Server.

En el Service Pack 1 (SP1) de Exchange Server 2007, el programa de instalación bloquea configuraciones de clúster de dos nodos si no hay ningún testigo de recurso compartido o el quórum Mayoría de recurso compartido de archivos configurados. Esto es así porque esa configuración no puede administrar la pérdida de un nodo en el clúster (porque no se mantiene la mayoría) y, como resultado, el clúster se desconecta.

Requisitos de software para la replicación continua en clúster

Los requisitos de software para entornos de CCR son los siguientes:

• Los dos nodos del clúster deben tener el sistema operativo Windows Server 2008 Enterprise o Windows Server 2003 Enterprise Edition instalado en cada nodo del clúster usando las mismas letras de unidad de sistema y de arranque. No puede tener un clúster en el que un nodo ejecute Windows Server 2008 y el otro nodo ejecute Windows Server 2003. No se admite la combinación de versiones del sistema operativo en un clúster de conmutación por error.

• Si está creando un entorno CCR con la versión de lanzamiento (RTM) de Exchange 2007 en Windows Server 2003, ambos nodos del clúster de conmutación por error deben tener instalado el Service Pack 2 (SP2) de Windows Server 2003, o bien Windows Server 2003 SP1 y la revisión del artículo de la Knowledge Base 921181, Está disponible una actualización que agrega una característica de testigo de recurso compartido y una característica de latidos de clúster configurables de clústeres de servidor basados en Service Pack 1 de Microsoft Windows Server 2003. Esta revisión se incluye en Windows Server 2003 SP2. Si está compilando un entorno CCR con Exchange 2007 SP1 en Windows Server 2003, ambos nodos del clúster de conmutación por error deben tener instalado Windows Server 2003 SP2.

• El clúster debe ser un clúster de tres nodos con un quórum MNS tradicional o un clúster de dos nodos con un quórum MNS con testigo de recurso compartido. Generalmente, se supone que en Windows Server 2003, se usará un clúster de dos nodos mediante un quórum de MNS con testigo de recurso compartido, y que en Windows Server 2008, se usará un clúster de dos nodos con un quórum archivos y nodos compartidos mayoritarios.

• No es necesario que el testigo de recurso compartido para el MNS o el quórum Mayoría de recurso compartido de archivos esté en un equipo dedicado. Puede estar en cualquier equipo que ejecute Windows Server. Sin embargo, es recomendable que hospede el testigo de recurso compartido en un servidor de transporte de concentradores (u otro servidor Exchange) para que esté bajo el control del administrador de Exchange.

• Sólo se puede instalar la función del servidor Buzón de correo en un clúster. No se pueden instalar más funciones de servidor en un equipo que forme parte de un clúster de conmutación por error.

Requisitos de red para la replicación continua en clúster

Es importante que las redes que se usan en las comunicaciones de los clientes y los clústeres estén configuradas correctamente. En esta sección se proporcionan vínculos a los procedimientos necesarios para comprobar que la configuración de la red privada y de la red pública es correcta. Asimismo, se debe asegurar de que el orden de conexión de la red esté configurado correctamente para el clúster. Tenga en cuenta lo siguiente a la hora de diseñar la infraestructura de red para el entorno de CCR:

• Cada nodo debe tener, al menos, dos adaptadores de red disponibles para los clústeres de Windows. Los servidores cliente y otros servidores sólo necesitan poder tener acceso a los nodos desde uno de los adaptadores de red. Los otros adaptadores de red se usan para la comunicación dentro del clúster. La configuración recomendada consiste en tener la red privada dedicada a las comunicaciones de clúster internas y la red pública definida como mixta.

• La red de clúster pública debería proporcionar conectividad a los otros servicios y servidores de Exchange, como Active Directory y DNS. Se puede evitar que esto sea un error puntual usando el aprendizaje de equipos del adaptador de red o una tecnología similar.

• Se debe proporcionar una red en clúster privada separada. La red privada se usa para el latido de clúster. La red privada no necesita DNS.

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

• Es recomendable que use Gigabit Ethernet para entornos de CCR para maximizar el tiempo de reinicialización. Para obtener más información acerca de por qué se recomienda Gigabit Ethernet, consulte la sección "Tamaño de base de datos y replicación continua en clúster" de este tema.

• En Exchange 2007 RTM, un grupo de recursos que contiene un servidor de buzones de correo en clúster sólo puede tener un recurso de nombre de red. Exchange 2007 RTM no admite tener más de un recurso de nombre de red en un grupo de recursos que contenga un servidor de buzones de correo en clúster. Sin embargo, esta limitación no existe en Exchange 2007 SP1. Si el servidor de buzones de correo en clúster se ha actualizado a Exchange 2007 SP1, puede existir más de un recurso de nombre de red en el grupo de recursos que contiene el servidor de buzones de correo en clúster.

Requisitos de red para la instalación de CCR en Windows Server 2008

Los requisitos de red para la instalación de CCR en Windows Server 2008 son ligeramente diferentes de los requisitos para la instalación de CCR en Windows Server 2003. Igual que ocurría en Windows Server 2003, si está instalando CCR en Windows Server 2008, debe tener suficientes direcciones IP disponibles para ambos nodos y para el servidor de buzones de correo en clúster (CMS). Sin embargo, hay algunas opciones adicionales disponibles en Windows Server 2008 que no existen en Windows Server 2003:

• Los nodos de clúster pueden residir en subredes diferentes. En Windows Server 2003, la interfaz de red de cada red de cada nodo debe estar en la misma subred que la red correspondiente en el otro nodo. Este requisito no existe en Windows Server 2008. En consecuencia, los nodos de un clúster de conmutación por error se pueden comunicar a través de enrutadores de red y no se necesita una tecnología LAN virtual (VLAN) para conectarlos.

• Cuando use varias subredes en un entorno CCR, la replicación de DNS puede afectar a la capacidad de un cliente de reconectarse a un CMS después de producirse una conmutación por error o relevo del CMS entre nodos. Los clientes y otros servidores que se comunican con un servidor de buzones de correo en clúster que tenga cambiadas las direcciones IP no podrán restablecer las comunicaciones con el servidor de buzones de correo en clúster hasta que el DNS no se haya actualizado con la nueva dirección IP, y se haya actualizado cualquier caché DNS local. Para minimizar el tiempo que se tarda en informar a clientes y otros servidores de los cambios de DNS, se recomienda configurar un valor Período de vida (TTL) para DNS de cinco minutos para el recurso de nombre de red del servidor de buzones de correo en clúster. En la mayor parte de los entornos, recomendamos establecer el valor TTL de DNS sólo para el recurso del nombre de red del servidor de buzones de correo en clúster. Sin embargo, en entornos con herramientas de administración que no sean de Exchange que conectan con el clúster por su nombre con fines de administración, se recomienda configurar un valor TTL menor en el recurso de nombre de red del clúster. Para obtener instrucciones detalladas acerca de cómo configurar los valores TTL de DNS para recursos de nombre de red para usarlos en un CMS de un entorno con varias subredes o una implementación de clústeres en espera, consulte Cómo configurar valores DNS TTL para recursos de nombres de red.

• 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 de Protocolo de configuración dinámica de host (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 también se deben configurar con las direcciones IP estáticas. Por tanto, la asignación de recursos de direcciones IP sigue la configuración del nodo físico y cada interfaz específica del nodo. No se recomienda usar DHCP para servidores de buzones de correo en clúster. Se recomienda que tenga en cuenta las siguientes consideraciones antes de usar DHCP para un CMS:

  • Si se modifica la dirección IP, el Servicio de clúster no abrirá un recurso Dirección IP con DHCP habilitado.

  • Los servidores DHCP se debe configurar para permitir una concesión ilimitada para todas las direcciones asignadas DHCP usadas por servidores de buzones de correo en clúster.

• Windows Server 2008 y el Servicio de clúster también admiten el Protocolo de Internet versión 6 (IPv6). Se incluye la compatibilidad con recursos de dirección IP de IPv6 e 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). Sólo se admite el uso de direcciones IPv6 e intervalos de direcciones IP si Exchange 2007 SP1 está instalado en un equipo que ejecute Windows Server 2008, IPv6 e 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 del servidor podrán enviar y recibir datos de dispositivos, servidores y clientes que usen direcciones IPv6. Una instalación predeterminada de Windows Server 2008 permite la compatibilidad con 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.

Requisitos de red para la instalación de CCR en Windows Server 2003

Si está instalando una replicación continua en clúster en Windows Server 2003, debe disponer de un número suficiente de direcciones IP estáticas al crear servidores de buzones de correo en clúster en un entorno de replicación continua en clúster de dos nodos. Se necesita una dirección IP para el clúster y para el servidor de buzones de correo en clúster. Asimismo, se requieren direcciones IP tanto para redes públicas como privadas en cada nodo:

• Direcciones privadas   Cada nodo requiere una dirección IP estática para cada adaptador de red que se usa en una red de clústeres privada. Debe usar direcciones IP estáticas que no estén en la misma subred o red que una de las redes públicas. Se recomienda usar 10.10.10.10 y 10.10.10.11 con una máscara de subred de 255.255.255.0 como direcciones IP privadas para los dos nodos, respectivamente. Si la red pública usa una red 10.x.x.x y una máscara de subred 255.255.255.0, se recomienda usar direcciones IP de redes privadas y máscara de subred alternativas. Si configura más de una red privada, se necesitan direcciones y subredes únicas para cada adaptador de red y red privada.

• Direcciones públicas   Cada nodo requiere una dirección IP estática para cada adaptador de red que se usa en una red de clústeres pública. Además, se requieren direcciones IP estáticas para el clúster del servidor y el servidor de buzones de correo en clúster para que clientes y administradores puedan tener acceso a ellos. Debe usar direcciones IP estáticas que no estén en la misma subred o red que una de las redes privadas.

La red privada para todos los nodos de un clúster debe estar en la misma subred, pero puede usar modificadores de VLAN en las interconexiones entre dos nodos. Si usa una VLAN, la latencia punto a punto de ida y vuelta debe ser menor que 0,5 segundos. Además, el vínculo entre dos nodos debe aparecer como una única conexión punto a punto desde la perspectiva del sistema operativo Windows Server 2003 que se está ejecutando en los nodos. Para evitar errores puntuales, use hardware de VLAN independiente para las diferentes rutas de acceso entre los nodos. No se aplica la misma restricción de subred a los clústeres de conmutación por error que se ejecutan en Windows Server 2008.

Las redes públicas para todos los nodos de un clúster deben estar en la misma subred y deben usar una subred distinta de la subred usada para redes privadas. No se aplica la misma restricción de subred a los clústeres de conmutación por error que se ejecutan en Windows Server 2008.

El orden de conexión de la red en clúster en Windows debe estar configurado de forma que las redes públicas estén al principio de la lista de orden de conexión; la prioridad de red del clúster debe estar configurada con las redes privadas enumeradas en la parte superior del orden de prioridad.

Si está instalando la CCR en una configuración múltiple de centros de datos de Windows Server 2003:

• Todas las redes usadas para acceso de cliente deben proporcionar el ancho de banda adecuado y una latencia lo suficientemente baja para permitir a los clientes tener acceso al servidor de buzones de correo en clúster desde cualquier centro de datos.

• Todas las redes que se usen para replicar registros de transacciones deben proporcionar también el ancho de banda adecuado y una latencia lo suficientemente baja para copiar los archivos de registro a tiempo, de modo que, siempre que sea posible, no haya archivos de registro atrasados.

• Las redes usadas para el latido de clúster deben poder enviar y recibir un paquete de latidos dentro del número requerido de intentos configurados. Si está instalando la CCR en el SP2 para Windows Server 2003 o el SP1 para Windows Server 2003 y la revisión del artículo 921181 de la Knowledge Base Está disponible una actualización que agrega una característica de testigo de recurso compartido y una característica de latidos de clúster configurables de clústeres de servidor basados en Service Pack 1 de Microsoft Windows Server 2003, los intentos de latidos de interfaz perdidos y los intentos de latido de nodo perdidos se exponen como propiedades de configuración de clúster. Si está instalando la CCR en Windows Server 2008, no será necesaria esta actualización. En cualquier caso, los latidos se siguen enviando cada 1,2 segundos, pero el clúster se puede configurar para dejar que se produzcan más pérdidas (de paquetes perdidos, latencia excesiva, error de interfaz o nodo) antes de realizar ninguna acción. Los valores de propiedad se expresan en unidades de latidos perdidos y no en tiempo transcurrido. Así, el clúster no se puede configurar para que sospeche de un error de interfaz después de cinco segundos, sino que se puede configurar para que sospeche de un error de interfaz después de cinco latidos perdidos y, en función del momento del período de latidos en que se produzca el error, cinco pérdidas pueden durar aproximadamente cinco o seis segundos. Ambas configuraciones tienen un tiempo permitido mínimo de 2 segundos y máximo de 20 segundos.

Optimización de los servicios de redes de Windows 2003 para CCR

Cuando se use CCR en Windows Server 2003, se recomienda optimizar la configuración de TCP/IP de Windows Server para su velocidad de vínculo de red y latencia específicas. En concreto, es posible que tenga que ajustar el tamaño de la ventana de recepción del Protocolo de control de transmisión (TCP) y las opciones de escalado de ventana Solicitud de comentarios (RFC) 1323 en los nodos activo y pasivo. Además, puede resultar beneficioso configurar los valores de expiración de caché del Protocolo de resolución de dirección (ARP) y deshabilitar las opciones de TCP/IP avanzadas del Paquete de funciones de red escalables (SNP) Windows Server 2003 en el Registro de Windows.

Además de estas recomendaciones, si su entorno incluye el uso del protocolo Seguridad IP (IPsec), recomendamos que configure IPsec de forma constante en todo su entorno CCR. Ambos nodos deberán usar IPsec, o bien, no usarlo ninguno de ellos. Si sólo se configura un nodo para que use IPsec, el proceso de asociación de seguridad IPsec puede provocar el retraso o pérdida de paquetes.

Ventanas de recepción de TCP y opciones de escalado de RFC 1323

El tamaño de la ventana de recepción de TCP representa la cantidad máxima de datos (en bytes) que se pueden recibir de una vez en una conexión. El equipo de envío sólo puede enviar la cantidad máxima de datos antes de esperar una confirmación y actualización de la ventana de TCP desde el equipo receptor. Puede resultar útil ajustar esta opción para aumentar el rendimiento durante el transporte de registros.

Para optimizar el rendimiento de TCP, el equipo de envío deberá transmitir suficientes paquetes para llenar el canal entre el remitente y el receptor. La capacidad del canal de red se basa en el ancho de banda del canal y su latencia (tiempo de retorno). Cuanto mayor sea la latencia, mayor será la capacidad del canal de red, ya que hay más tiempo para enviar datos entre confirmaciones. Al aumentar el tamaño de la ventana de TCP, el sistema se puede beneficiar del tiempo entre confirmaciones enviando más datos.

El estándar TCP/IP permite una ventana de recepción de hasta 65.535 octetos de tamaño, que es el valor máximo que se puede especificar en el campo de tamaño de ventana TCP/IP de 16 bits. Para mejorar el rendimiento en anchos de banda altos y redes de gran retraso, el TCP/IP de Windows Server admite la posibilidad de anunciar tamaños de ventana de recepción mayores de 65.535 octetos con ventanas escalables, según se describe en RFC 1323, Ampliaciones de TCP para un alto rendimiento. Al usar el escalado de ventanas, los host de una conversación pueden negociar un tamaño de ventana que permita varios paquetes grandes, como los que se usan en los protocolos de transporte de archivos, para que estén pendientes en los búferes del receptor. RFC 1323 describe al detalle un método para admitir tamaños de ventana de recepción más grandes para permitir a TCP negociar un factor de escalado para el tamaño de la ventana al establecer una conexión.

Se puede optimizar el tamaño de la ventana de recepción de TCP y las opciones de escalado de la ventana RFC 1323 en un equipo que ejecute Windows Server 2003 modificando dos entradas del Registro: TCPWindowSize y TCP1323Opts. Para obtener más información sobre estas características, consulte el artículo 224829 de Microsoft Knowledge Base, Descripción de las características TCP de Windows 2000 y Windows Server 2003.

Se recomienda usar la versión 13 o posterior de la calculadora de requisitos de almacenamiento de la función del servidor Buzón de correo de Exchange 2007 para determinar la configuración óptima para estas entradas del Registro en función del vínculo y la latencia de su red. Puede descargar la calculadora desde el blog del equipo de Exchange aquí. La calculadora de almacenamiento incluye también instrucciones paso a paso para introducir valores del Registro en sus servidores.

Expiración de la memoria caché de ARP

La memoria caché de ARP es una tabla en memoria que asigna direcciones IP a direcciones de Media Access Control (MAC). Se hace referencia a las entradas de la memoria caché de ARP cada vez que se envía un paquete saliente a la dirección IP de la entrada. De forma predeterminada, Windows Server 2003 ajusta automáticamente el tamaño de la memoria caché de ARP para satisfacer las necesidades del sistema. Si ningún datagrama saliente usa una entrada durante dos minutos, dicha entrada se elimina de la memoria caché de ARP. Las entradas a las que se está haciendo referencia se quitan de la memoria caché de ARP pasados diez minutos. Las entradas introducidas manualmente no se quitan automáticamente de la memoria caché.

Las pruebas internas del departamento de TI interno de Microsoft mostraron que la configuración de expiración de la memoria caché de ARP daba como resultado la pérdida de paquetes en entornos CCR y SCR. Cuando se produce la pérdida de un paquete, el servidor de envío debe volver a transmitir los datos perdidos. En un entorno de replicación continua, es importante que los archivos de registro se copien en el nodo pasivo lo mas rápidamente posible y la retransmisión de datos provocada por la pérdida de paquetes puede afectar negativamente al rendimiento del envío de registros.

Puede modificar el parámetro de TCP/IP ArpCacheMinReferencedLife del Registro de Windows para controlar la expiración de la memoria caché de ARP. Este parámetro determina el tiempo que deben permanecer las entradas referenciadas en la tabla de la memoria caché de ARP antes de que puedan eliminarse. De forma interna, Microsoft detectó que la configuración óptima para el valor del Registro de ArpCacheMinReferencedLife era usar el mismo valor que usaban los enrutadores de la red para la expiración de la memoria caché de ARP, que era de 4 horas.

Antes de modificar el valor de ArpCacheMinReferencedLife en su propio entorno, le recomendamos que use el Monitor de red de Microsoft o una herramienta de captura similar para recopilar y analizar el tráfico de la interfaz de red usada para copiar registros del nodo activo al nodo pasivo. Para obtener instrucciones detalladas para modificar el valor del Registro de ArpCacheMinReferencedLife, consulte Apéndice A: Parámetros de configuración TCP/IP.

Características avanzadas de TCP/IP del Paquete de funciones de red escalables

El Paquete de funciones de red escalables (SNP) de Windows Server 2003 es una actualización independiente de Windows Server 2003 que contiene descargas de paquetes a nivel de datos y sin estado para acelerar la pila de red de Windows. La actualización incluye la descarga de la Chimenea TCP, Escalabilidad de tráfico de entrada (RSS) y Acceso directo a memoria de red (NetDMA)

Chimenea TCP es una descarga de paquetes a nivel de datos. La descarga de la Chimenea TCP permite que se descargue el procesamiento TCP/IP para adaptadores de red cuyo hardware pueda realizar dicho procesamiento.

RSS y NetDMA son descargas sin estado. Cuando hay varias CPU en un único equipo, la pila de red de Windows limita el procesamiento del protocolo "recibir" a una única CPU. RSS soluciona este problema habilitando el equilibrado de los paquetes que se reciban desde un adaptador de red entre varias CPU. NetDMA permite un motor de Acceso directo a memoria de red (NetDMA) en el bus de interconexión de componentes periféricos (PCI). La pila de TCP/IP puede usar el motor DMA para copiar datos en lugar de interrumpir a la CPU que se encarga de la operación de copia. Un componente relacionado, TCPA, es otra función de descarga en la que se puede usar un motor DMA de hardware en el bus PCI para ayudar al proceso de recepción.

Estas características pueden ofrecer ventajas de rendimiento de red en algunos entornos; sin embargo, hay algunos escenarios en los que no se pueden usar debido al uso de otras tecnologías. Por ejemplo, la descarga de la Chimenea TCP y NetDMA no se pueden usar con alguna de las siguientes tecnologías:

• Windows Firewall

• Protocolo de seguridad de Internet (IPSec)

• Traducción de direcciones de red del protocolo de Internet (IPNAT)

• Firewalls de terceros

• Controladores intermedios NDIS 5.1

Además, se conocen problemas en algunos entornos, incluidos los entornos con Microsoft Exchange, en los que el rendimiento de red se puede ver reducido al usar estas características. Para obtener información detallada sobre alguno de estos problemas, consulte la publicación del blog del equipo de Exchange, Paquete de funciones de red escalables de Windows 2003 y sus posibles efectos sobre Exchange.

Recomendamos que deshabilite todas las características de entornos CCR que se ejecuten en el sistema operativo Windows Server 2003 tanto para el sistema operativo como para todas las tarjetas de interfaz de red (NIC) del sistema. Puede deshabilitar estas características del siguiente modo:

• Para deshabilitar la característica de descarga de la Chimenea TCP, abra una ventana de símbolo del sistema y ejecute el siguiente comando: Netsh int ip set chimney DISABLED

• Para deshabilitar otras características SNP, puede definir los valores de los parámetros del Registro TCP/IP EnableRSS y EnableTCPA a 0 en el Registro de Windows. Para ver los pasos detallados para hacerlo, consulte el artículo 936594 de Microsoft Knowledge Base, Puede experimentar problemas relacionados con la red después de instalar Windows Server 2003 SP2 o la Paquete Red Escalable en un equipo basado en Windows Server.

• Para deshabilitar estas características en las NIC del sistema, consulte las instrucciones que acompañaban a cada NIC o consulte al proveedor del hardware.

Para obtener más información sobre SNP, consulte el artículo 912222 de Knowledge Base, La versión Microsoft Windows Server 2003 Scalable Networking Pack y el sitio webScalable Networking.

Comportamiento de Outlook después de una conmutación por error del servidor de buzones de correo en clúster, en un clúster de conmutación por error de varias subredes

Cuando se produce un movimiento o una conmutación por error en un CMS implementado en un clúster de conmutación por error con varias subredes geográficamente dispersas, el nombre del CMS se mantiene. Sin embargo, la dirección IP asignada al nombre no se mantiene. La disponibilidad de este servidor para los clientes y otros servidores depende de la propagación de la nueva dirección IP en todo el DNS. La propagación de DNS puede tardar algún tiempo en producirse. Por este motivo, se recomienda configurar el Período de vida (TTL) para el host DNS del CMS en 5 minutos (300 segundos). Para obtener instrucciones detalladas acerca de la configuración del valor TTL de DNS para el CMS, consulte Cómo configurar valores DNS TTL para recursos de nombres de red. Después de configurar el valor TTL de DNS para el CMS, debe detener e iniciar después dicho servidor para que el cambio surta efecto.

Aunque los clientes internos de Microsoft Office Outlook no necesitan perfiles nuevos o reconfigurados para conectarse usando la nueva dirección IP, deberán esperar a que se borre la memoria caché de DNS local para que la resolución de nombres del nombre del CMS cambie de la dirección IP antigua a la nueva. Después de que la dirección IP se haya propagado a los servidores de DNS apropiados, se puede borrar la memoria caché DNS de los clientes de Outlook ejecutando el siguiente comando en un símbolo del sistema:

ipconfig /flushdns

En la siguiente sección se muestra el comportamiento de Outlook con diferentes configuraciones.

CCR extendido en Windows Server 2003 (una subred)

En esta configuración existe un recurso Nombre de red y un recurso de dirección IP del que depende el recurso Nombre de red. En DNS, el nombre de la red está asociado con la dirección IP. Todos los recursos, incluido el recurso de dirección IP, pueden moverse entre los dos nodos del clúster. Desde el punto de vista de Outlook, no se produce ningún cambio en la dirección IP, ya que el único cambio de red en caso de conmutación por error es la asociación de la dirección IP a la dirección MAC del equipo, lo que resulta transparente para los clientes.

CCR extendido en Windows Server 2008 (dos subredes, suponiendo IPv4)

En esta configuración, existe un recurso Nombre de red y dos direcciones IP de las que depende el recurso Nombre de red, como un "OR" lógico. En DNS, el nombre de la red está asociado con la dirección IP en línea. Durante la conmutación por error, cuando se conecta el recurso Nombre de red, el servicio de clúster actualiza la entrada DNS para el Nombre de red con la segunda dirección IP, lo que corresponde a la otra subred. La actualización del registro debe propagarse a través del DNS. Desde la perspectiva de Outlook, Outlook no se precisa un perfil nuevo ni reconfigurado, pero es necesario esperar a que la memoria caché del DNS local se vacíe para permitir que se resuelva el Nombre de red para la otra dirección IP. Esto puede hacerse manualmente en el cliente ejecutando:

IPConfig /flushdns

CCR local con SCR en sitio remoto (una o dos subredes)

En esta configuración existe un recurso Nombre de red y un recurso de dirección IP del que depende el Nombre de red. Todos los recursos, incluida la dirección IP, pueden moverse entre los dos nodos del clúster. En caso de conmutación por error del sitio en la que el destino de SCR se activa mediante la ejecución de Setup.com /recoverCMS, el CMS se mueve a un sitio/clúster diferente. Al ejecutar este comando, se proporciona la dirección IP que debería estar asociada con el Nombre de red del sitio remoto. La configuración crea los recursos Nombre de red y dirección IP, y el servicio de clúster actualiza el DNS con la nueva dirección IP. La actualización del DNS debe propagarse a través del DNS. Desde la perspectiva de Outlook, Outlook no se precisa un perfil nuevo ni reconfigurado, pero es necesario esperar a que la memoria caché del DNS local se vacíe para permitir que se resuelva el Nombre de red para la otra dirección IP. Esto puede hacerse manualmente en el cliente ejecutando:

IPConfig /flushdns

Requisitos de almacenamiento para la replicación continua en clúster

La CCR se ha diseñado para eliminar la necesidad de almacenamiento compartido en un clúster de Windows. El almacenamiento compartido era un requisito de las versiones anteriores de Exchange. Los únicos requisitos de almacenamiento para la CCR son un rendimiento y una capacidad suficientes de almacenamiento compatible con Windows.

La CCR no hace consideraciones especiales de E/S en el almacenamiento que usan las bases de datos y los grupos de almacenamiento. Al diseñar una solución de almacenamiento de CCR, es aconsejable que siga las siguientes prácticas recomendadas:

• La ubicación de las bases de datos y los grupos de almacenamiento debe ser idéntica en todos los nodos del clúster.

• Almacenar los archivos de base de datos y los de registros de transacciones en diferentes números de unidad lógica (LUN).

• Usar los puntos de montaje de volumen del sistema de archivos NFTS para sacar a la superficie los volúmenes del sistema operativo.

• Usar nombres característicos que se puedan relacionar de forma directa y obvia con la base de datos o el grupo de almacenamiento hospedados. Si se usan diferentes volúmenes para los registros y las bases de datos, las rutas de acceso deberían identificar los tipos de datos. Este enfoque puede evitar que se cometan errores humanos a medida que aumenta el número de bases de datos y grupos de almacenamiento. Si se realiza la instalación predeterminada, el grupo de almacenamiento y las bases de datos se crean en la ubicación de instalación Exchange 2007.

  Nota

  Exchange 2007 no admite ubicar registros de transacciones o archivos de bases de datos en la raíz de un volumen.

Un entorno de CCR requiere un almacenamiento con un rendimiento y capacidades adecuados. El almacenamiento equivalente para el rendimiento y las capacidades del sistema se debe configurar en ambos nodos con la misma ubicación (letra de unidad y rutas) para cada grupo de almacenamiento y base de datos.

Tamaño de base de datos y replicación continua en clúster

La primera línea de defensa para errores de almacenamiento catastróficos o daño de bases de datos con CCR consiste en revertir a la copia pasiva de los datos, no en recuperar a partir de copias de seguridad. Esto resta importancia a los objetivos de tiempo de recuperación (RTO) basados en la restauración a partir de archivos o cintas. En lugar de restaurar desde una cinta, se activa la copia pasiva de una base de datos y los datos están disponibles para los clientes en minutos y no en horas. En este sentido, la CCR se puede considerar un mecanismo de recuperación rápida en la misma categoría que las instantáneas basadas en hardware y los clones creados con el servicio de instantáneas de volumen (VSS) de Exchange Server 2003.

A menudo los administradores tienen que realizar operaciones en bases de datos sin conexión, como una reparación, debido a unas copias de seguridad incorrectas (por ejemplo, una cinta en mal estado o un error de restauración). Con la CCR, este escenario se evita y se reduce la posibilidad de tener que reparar una base de datos. Aunque el porcentaje de situaciones en que se necesita reparación se reduce drásticamente, es posible que sea necesaria en algunas ocasiones. Asegúrese de tener en cuenta la tolerancia al tiempo de inactividad del "peor de los casos" al decidir el tamaño de una base de datos.

La CCR permite tener mayores ventanas de mantenimiento en línea. Dado que la CCR permite realizar copias de seguridad a partir de la copia pasiva de un grupo de almacenamiento, puede ampliar la ventana de mantenimiento en línea en el nodo de clúster activo. En muchos casos, puede duplicar la ventana de mantenimiento en línea, lo que permite tener mayores buzones y bases de datos.

Otra característica de Exchange 2007, llamada resistencia a registros perdidos (LLR), reduce drásticamente los casos de inconsistencias en bases de datos debidas a la pérdida de registros. En general, el motivo más frecuente por el que un administrador repara una base de datos es para que sea consistente después de la pérdida o daños de los registros requeridos, lo que impide el montaje de la base de datos. La LLR proporciona resistencia para muchos escenarios de pérdida y daño del registro, lo que permite montar una base de datos sin necesidad de repararla. Para obtener más información acerca de las LLR, consulte Resistencia del registro perdido y actividad del registro de transacciones en Exchange 2007.

En este punto, puede parecer que la replicación continua permite ampliar las bases de datos hasta el tamaño deseado sin riesgo. Sin embargo, no es así. Un mantenimiento en línea que se pueda realizar en un intervalo de tiempo razonable por base de datos sigue siendo un factor que limita el tamaño de la base de datos. Pero con la CCR, la posibilidad de necesitar reinicializar las bases de datos también es un factor de restricción. La CCR proporciona redundancia de bases de datos, de modo que si se pierde o daña la copia activa de una base de datos, la recuperación se puede conseguir rápidamente activando la copia pasiva de la base de datos. La CCR proporciona activación automática a través del proceso conocido como conmutación por error.

Después de una conmutación por error, sólo se conserva una copia de la base de datos: la nueva copia activa. Dado que la copia pasiva ya no existe, la resistencia de la base de datos se puede ver afectada. De todos modos, debe tener una copia de seguridad. Para volver a habilitar la resistencia, es necesario quitar la base de datos que se ha perdido o dañado, crear una nueva copia pasiva de la base de datos y reinicializar a partir de la copia activa. En función del tamaño de la base de datos, esto puede llevar mucho tiempo. El peor escenario es la pérdida o daños de todas las copias activas, en que es necesario reinicializar todas las copias pasivas. Este escenario es uno de los motivos por los que recomendamos Gigabit Ethernet para entornos de CCR.

En un entorno CCR, puede esperar las velocidades siguientes a través de Gigabit Ethernet, que no permite cuellos de botella de disco o procesador:

• Reinicialización de una base de datos única: aproximadamente 25 megabytes (MB) por segundo

• Reinicialización de varias bases de datos (en paralelo): aproximadamente 100 MB por segundo (limitado por el ancho de banda de red)

Es posible usar un tamaño de base de datos máximo mayor si se usa la replicación continua. Recomendamos los tamaños de base de datos máximos siguientes para Exchange 2007:

• Bases de datos hospedadas en un servidor de buzones sin replicación continua: 100 gigabytes (GB)

• Bases de datos hospedadas en un servidor de buzones con replicación continua y Gigabit Ethernet: 200 GB

  Nota

  Es posible que las grandes bases de datos también requieran una tecnología de almacenamiento nueva para un mayor ancho de banda para las situaciones de reparación.

  Importante

  El tamaño máximo real de las bases de datos está determinado por el acuerdo de nivel de servicio (SLA) vigente de la organización. Para determinar el tamaño máximo de las bases de datos, debe determinar el tamaño máximo de base de datos que se puede copiar y restaurar en el período de tiempo especificado en el SLA de la organización.

Requisitos de Active Directory para la replicación continua en clúster

CCR tiene los mismos requisitos de infraestructura de Active Directory que un servidor independiente, además de otros requisitos adicionales. En una solución de múltiples centros de datos, los dos centros de datos deben tener una compatibilidad adecuada con la infraestructura de Active Directory, ya que alguno de ellos podría hospedar el servidor de buzones de correo en clúster. Esta capacidad debe estar presente incluso si los otros centros de datos no están disponibles. Además, todos los nodos del clúster deben estar en el mismo dominio y la cuenta del Servicio de clúster debe tener los permisos adecuados.

Requisitos de cuenta de servicio para la replicación continua en clúster

Si está instalando la CCR en Windows Server 2008, la cuenta del Servicio de clúster se ejecutará bajo la cuenta LocalSystem (SYSTEM).

Si está instalando la CCR Windows Server 2003, deberá usar una cuenta de dominio para la cuenta del Servicio de clúster. Todos los nodos del clúster deben ser miembros del mismo dominio y todos los nodos del clúster deben usar la misma cuenta del Servicio de clúster. La cuenta del Servicio de clúster también debe ser miembro del grupo Administradores local en cada nodo que pueda hospedar un servidor de buzones de correo en clúster.

La cuenta del Servicio de clúster es responsable de la creación y mantenimiento de la cuenta del equipo identificada y asociada con el recurso de nombre de red del clúster de conmutación por error cuando ese recurso se pone en línea. Para asegurarse de que la cuenta del Servicio de clúster tiene los permisos apropiados, consulte el artículo de la Knowledge Base 307532, Cómo solucionar problemas de la cuenta del Servicio de Cluster Server cuando modifica objetos de equipo. Para obtener más información, consulte el artículo 251335 de Knowledge Base, Los usuarios de dominio no pueden unir la estación de trabajo o el servidor a un dominio.

Replicación continua en clúster y bases de datos de carpetas públicas

CCR y la replicación de carpetas públicas son dos formas muy diferentes de replicación integradas en Exchange. Debido a las limitaciones de interoperabilidad entre la replicación continua y la replicación de carpetas públicas, si más de un servidor de buzones de correo de la organización de Exchange tiene una base de datos de carpetas públicas, se habilita la replicación de carpetas públicas y las bases de datos de carpetas públicas no se deberán hospedar en entornos CCR.

A continuación, se muestran las configuraciones recomendadas para usar bases de datos de carpetas públicas en CCR en su organización de Exchange:

• Si dispone de un único servidor de buzones en la organización de Exchange que sea un servidor de buzones de correo en clústeres en un entorno de CCR, el servidor de buzones puede hospedar una base de datos de carpetas públicas. En esta configuración hay una única base de datos de carpetas en la organización de Exchange. Por tanto, la replicación de carpetas públicas está deshabilitada. En este escenario, la redundancia de base de datos de carpetas públicas se logra con CCR; CCR mantiene dos copias de su base de datos de carpetas públicas.

• Si tiene varios servidores de buzones, podrá hospedar una base de datos de carpetas públicas en un entorno CCR siempre que sólo haya una base de datos de carpetas públicas en toda la organización de Exchange. En este escenario, la redundancia de base de datos de carpetas públicas se logra también con CCR. En esta configuración hay una única base de datos de carpetas en la organización de Exchange. Por tanto, la replicación de carpetas públicas está deshabilitada.

• Si está migrando datos de carpetas públicas en un entorno CCR, puede usar la replicación de carpetas públicas para mover el contenido de una base de datos de carpetas públicas desde un servidor de buzones de correo independiente o un servidor de buzones de correo en clúster en un entorno SCC a un servidor de buzones de correo en clúster que esté en un entorno CCR. Una vez creada la base de datos de carpetas públicas en un entorno CCR, las bases de datos de carpetas públicas adicionales sólo deben estar presentes hasta que los datos de carpetas públicas se hayan replicado completamente en el entorno CCR. Una vez que la replicación se haya completado correctamente, se deben quitar todas las bases de datos de carpetas públicas que no estén en el entorno CCR y no se debe hospedar ninguna otra base de datos de carpetas públicas en la organización de Exchange.

• Si está migrando datos de carpetas públicas fuera de un entorno CCR, puede usar la replicación de carpetas públicas para mover el contenido de una base de datos de carpetas públicas desde un servidor de buzones de correo en clúster en un entorno de CCR a un servidor de buzones de correo independiente o un servidor de buzones de correo en clúster que esté en un entorno SCC. Una vez creada la base de datos de carpetas públicas adicional fuera del entorno CCR, la base de datos de carpetas públicas del entorno CCR sólo deberá estar presente hasta que los datos de las carpetas públicas se hayan replicado completamente en las bases de datos de carpetas públicas adicionales. Una vez que la replicación se haya completado correctamente, se deben quitar todas las bases de datos de carpetas públicas de todos los entornos CCR y no se debe hospedar ninguna base de datos de carpetas públicas posterior en grupos de almacenamiento que tengan habilitada la replicación continua.

Durante cualquier período en el que haya más de una base de datos de carpetas públicas en la organización de Exchange, y una o más de ellas estén hospedadas en un entorno CCR (como en los escenarios de migración descritos anteriormente), tenga en cuenta las diferencias de comportamiento para cortes programados (sin pérdida) y no programados (con perdida):

• Si se produce un corte sin pérdida programado correctamente, la base de datos de carpetas públicas se conectará y la replicación de carpetas públicas debería continuar según lo previsto.

• Si se produce un corte inesperado, la base de datos de carpetas públicas no se conectará hasta que estén disponibles el servidor original y todos los registros del grupo de almacenamiento que hospeda la base de datos de carpetas públicas. Si debido al corte se pierde algún dato, la CCR no permitirá que la base de datos de carpetas públicas se conecte cuando está habilitada la replicación de carpetas públicas. En este caso, se debe poner en línea el nodo original para asegurar que no se hayan perdido datos, o bien se debe volver a crear la base de datos de carpetas públicas en el servidor de buzones de correo en clúster del entorno CCR, y recuperarse su contenido con la replicación de carpetas públicas a partir de las bases de datos de carpetas públicas que están fuera del entorno CCR.

Copia de seguridad, restauración y replicación continua en clúster

Las copias de seguridad para Exchange son compatibles tanto para la creación como para la copia de grupos de almacenamiento y bases de datos con la tecnología VSS. Las copias de seguridad de transmisión por secuencias sólo se admiten desde el nodo activo.

Las restauraciones para Exchange se pueden realizar usando soluciones de transmisión por secuencias o copia de seguridad de VSS. Las restauraciones para Exchange no se admiten para la copia pasiva.

Una vez restaurada una base de datos de una copia de seguridad en un grupo de almacenamiento de un entorno CCR, debe detener y, a continuación, reanudar la replicación continua del grupo de almacenamiento con Suspend-StorageGroupCopy y Resume-StorageGroupCopy, respectivamente. Este proceso es necesario para actualizar el servicio de replicación de Microsoft Exchange con la información de generación de registros correcta. Si no se detiene y se reanuda la replicación continua, el servicio de replicación de Microsoft Exchange tendrá una información de generación de registros no actualizada y detendrá la replicación de los archivos de registro.

Suma de comprobación de base de datos de mantenimiento y puesta a cero de páginas de la base de datos en línea, en Exchange 2007 SP1

La suma de comprobación es el proceso de comprobar la integridad de la base de datos. El barrido de páginas es el proceso de puesta a cero de las bases de datos al final de una copia de seguridad de transmisión por secuencias. La versión RTM de Exchange 2007 realiza una suma de comprobación de toda la base de datos cuando se hace una copia de seguridad de transmisión por secuencias completa de una base de datos en línea. Como se mencionó anteriormente, en un entorno de replicación continua, sólo se pueden realizar copias de seguridad de transmisión por secuencias de la copia activa de una base de datos. No se puede realizar una copia de seguridad de transmisión por secuencias de una copia pasiva de una base de datos. VSS se puede usar para realizar instantáneas completas o crear copias exactas completas de una copia pasiva. También se puede realizar una suma de comprobación de las instantáneas y las copias exactas completas. Pero generalmente, en un entorno de replicación continua, sólo se puede realizar una suma de comprobación de una de las copias de la base de datos (la activa o la pasiva) sin intervención del administrador y algún tiempo de inactividad. Esto se debe a lo siguiente:

• Resulta incómodo realizar copias de seguridad de transmisión por secuencias de una copia activa de una base de datos, y además realizar copias de seguridad VSS de la copia pasiva de la misma base de datos.

• Aunque VSS se puede usar para copias activas y pasivas de la base de datos, este procedimiento va en contra de la recomendación de descargar operaciones de copia de seguridad de la copia activa a la pasiva.

• Se puede reducir la resistencia temporalmente porque para realizar comprobaciones manualmente de la integridad mediante el uso de utilidades de bases de datos de Exchange (Eseutil) se necesita la suspensión de la replicación continua.

Para habilitar el barrido y la suma de comprobación de la base de datos en todas las copias de la base de datos sin experimentar los problemas descritos anteriormente o tener que resolverlos, Exchange 2007 SP1 presenta dos nuevas características: Suma de comprobación de base de datos de mantenimiento y Puesta a cero de páginas de la base de datos en línea. Estas características permiten que el administrador active el barrido de páginas en segundo plano y la suma de comprobación en segundo plano de una base de datos. Estas características se pueden habilitar por separado o conjuntamente mediante la configuración manual de valores del Registro en el servidor de buzones que contenga las bases de datos que se vayan a analizar y el reinicio posterior del servicio Almacén de información de Microsoft Exchange. Los valores del Registro se configuran en el nivel del almacén de información de Microsoft Exchange. Después de habilitarlas, todas las bases de datos del servidor de buzones ejecutarán la actividad en segundo plano configurada. Las entradas del Registro disponibles se describen más adelante en este tema.

Habilitar suma de comprobación de bases de datos de mantenimiento en línea

Ubicación: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Nombre: Suma de comprobación de mantenimiento en línea Escriba: REG_DWORD Valor: 0x00000001

Habilitar puesta a cero de páginas de la base de datos en línea

Ubicación: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Nombre: Puesta a cero de las páginas de la base de datos durante la suma de comprobación Escriba: REG_DWORD Valor: 0x00000001

Aceleración de la suma de comprobación de bases de datos de mantenimiento en línea

Ubicación: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Nombre: Acelerar suma de comprobación Escriba: REG_DWORD Valor: 0x00000000 (milisegundos)