Diseño de la replicación continua en espera

 

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

Última modificación del tema: 2008-09-11

Aunque la implementación de la replicación continua en espera (SCR) es similar a la de la replicación continua local (LCR), es necesario considerar algunas diferencias importantes. Hay unos requisitos generales que deben cumplirse para la SCR.

Requisitos generales para la replicación continua en espera

Antes de habilitar cualquier grupo de almacenamiento para SCR, recomendamos que se familiarice con los siguientes requisitos previos de orígenes y destinos de SCR:

  • Un origen puede tener varios destinos. Por ejemplo, un origen podría tener un destino en el mismo centro de datos que el origen, y un segundo destino en otro centro de datos distinto. No existe límite para el número de destinos que puede tener cada origen. Sin embargo, se recomienda no usar más de cuatro destinos por cada origen. Si se configura más de cuatro destinos, se debe comprobar y planear la repercusión adicional en el servidor de origen en consecuencia.

  • Cada destino puede tener varios servidores de origen. Tanto en el servidor de origen como en el de destino se debe estar ejecutando Exchange 2007 SP1. El sistema operativo puede ser cualquiera admitido por Exchange 2007 SP1 (por ejemplo, Windows Server 2008 o Windows Server 2003); sin embargo, todos los equipos de destino de SCR deben ejecutar el mismo sistema operativo que su equipo de origen de SCR. No se admite el uso de sistemas operativos diferentes en un origen de SCR y sus destinos (por ejemplo, cuando el origen de SCR es Windows Server 2003 y el destino es Windows Server 2008, o viceversa).

  • El equipo de destino para SCR debe tener instalada la función del servidor Buzón de correo en Exchange 2007 SP1. Si el equipo de destino de SCR es un nodo de clúster, el nodo debe ser un nodo pasivo (p. ej., que esté instalada la función de buzones en clústeres pasivo) y el clúster no puede contener ningún servidor de buzones en clúster.

  • Debe planear las rutas de instalación del servidor de Exchange con más cuidado si utiliza SCR y tiene previsto usar un clúster en espera y la característica de recuperación del servidor de buzones de correo en clúster (Setup /RecoverCMS) como parte del proceso de activación del destino para SCR. Para usar el proceso de recuperación del servidor, la ruta de instalación del servidor de Exchange debe coincidir en el equipo de origen de SCR y el equipo de destino de SCR. Si el servidor de Exchange está instalado en %Archivos de programa%\Microsoft\Exchange Server en el equipo de origen de SCR, debe estar instalado también en %Archivos de programa%\Microsoft\Exchange Server en todos los equipos que serán destinos de SCR para el servidor de origen de SCR. Si se instalan rutas que no coinciden, Setup /RecoverCMS producirá un error porque la ruta de instalación del Registro no coincidirá con el valor del atributo msExchInstallPath del objeto del servidor de buzones en el servicio de directorio de Active Directory.

  • Si el proceso de activación incluye la recuperación de un servidor de buzones en clúster, debe deshabilitarlo para todos los grupos de almacenamiento del servidor de buzones en clúster antes de utilizar Setup /RecoverCMS como parte del proceso de activación. Si no deshabilita la SCR para todos los grupos de almacenamiento, Setup /RecoverCMS causará un error.

  • Las rutas del grupo de almacenamiento y de la base de datos del origen de SCR y de todos los destinos no deben estar en conflicto con ninguna otra ruta de grupo de almacenamiento o de base de datos. El grupo de almacenamiento y las rutas de la base de datos se deben planear con mayor cuidado al usar SCR, ya que el grupo de almacenamiento y la ruta de la base de datos que utiliza un origen de SCR se usará en la copia del grupo de almacenamiento y base de datos el todos los destinos de SCR del origen.

  • Los equipos de origen y de destino de SCR deben estar dentro del mismo dominio de Active Directory, pero se pueden encontrar en el mismo sitio o en sitios distintos de Active Directory.

  • Cada equipo de destino admite como máximo 50 destinos SCR (50 grupos de almacenamiento replicados) cuando se usa Exchange 2007 Enterprise Edition, y un máximo de 5 destinos de SCR cuando se usa Exchange 2007 Standard Edition.

Restricciones en los equipos de destino de SCR

Cuando se configura un nodo pasivo o un servidor de buzones independiente como destino de SCR, se bloquean las opciones siguientes:

  • Un servidor de buzones de correo independiente designado como destino de SCR no puede tener la LCR habilitada para ningún grupo de almacenamiento El Servicio de replicación de Microsoft Exchange no se ha diseñado ni modificado para controlar la administración de la LCR y la replicación desde otro origen.

  • Un nodo pasivo diseñado como destino de SCR debe ser miembro de un clúster de conmutación por error que no tenga servidores de buzones en clúster. Esto se llama un clúster en espera. Para obtener más información acerca de los clústeres en espera, consulte Alta disponibilidad.

SCR y bases de datos de carpetas públicas

SCR 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 replicación continua y 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 deberán hospedarse en entornos SCR.

Nota

Dado que la portabilidad de bases de datos se puede utilizar únicamente en las bases de datos de buzones, la activación de una copia de destino de SCR de una base de datos de carpetas públicas sólo se puede realizar dentro de una operación de recuperación de servidores o servidores de buzones en clúster (por ejemplo, Setup /m:recoverServer o Setup /recoverCMS).

Las siguientes son las configuraciones recomendadas para usar bases de datos de carpetas públicas y SCR en su organización de Exchange:

  • Si tiene un único servidor de buzones de correo en su organización de Exchange, y se trata de un servidor de buzones de correo independiente o un servidor de buzones de correo en clúster en un SCC, el servidor de buzones de correo puede hospedar una base de datos de carpetas públicas y el grupo de almacenamiento que contiene la base de datos de carpetas públicas se puede habilitar para SCR, siempre que el grupo de almacenamiento no esté habilitado para LCR. 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 utilizando SCR; SCR mantiene dos copias de su base de datos de carpetas públicas.

  • Si tiene varios servidores de buzones de correo y sólo uno de ellos contiene una base de datos de carpetas públicas, y se trata de un servidor de buzones de correo independiente o un servidor de buzones de correo en clúster en un SCC, el servidor de buzones de correo puede hospedar una base de datos de carpetas públicas y el grupo de almacenamiento que contiene la base de datos de carpetas públicas se puede habilitar para SCR, siempre que el grupo de almacenamiento no esté habilitado para LCR. 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 también utilizando SCR

  • Si está migrando datos de carpetas públicas a un grupo de almacenamiento habilitado para SCR, 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 SCC al grupo de almacenamiento habilitado para SCR. 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 grupos de almacenamiento habilitados para SCR 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 grupo de almacenamiento habilitado para SCR, puede usar la replicación de carpetas públicas para mover el contenido de una base de datos de carpetas públicas desde el grupo de almacenamiento a un servidor de buzones de correo independiente o un servidor de buzones de correo en clúster en un SCC. 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 grupos de almacenamiento habilitados para SCR y no se debe hospedar ninguna base de datos de carpetas públicas posterior en grupos de almacenamiento que tengan habilitado SCR.

En cualquier momento en el que haya más de una base de datos de carpetas públicas en la organización de Exchange y una o varias bases de datos de carpetas públicas estén hospedadas en un grupo de almacenamiento habilitado para SCR, si se produce un error del grupo de almacenamiento de origen de SCR y es necesario activar una base de datos de carpetas públicas de destino de SCR, ésta sólo puede montarse si están disponibles todos los registros del grupo de almacenamiento que hospeda la base de datos de carpetas públicas. Si falta alguno de estos registros o no está disponible como resultado del error del origen de SCR, no podrá activar la copia de destino de SCR de la base de datos de carpetas públicas. En este caso, el origen de SCR se debe poner en línea para garantizar que no se hayan perdido datos, o bien, se debe volver a crear la base de datos de carpetas públicas en el origen de SCR y a recuperar su contenido con la replicación de carpetas públicas a partir de una base de datos de carpetas públicas distinta de la copia de destino de SCR.

SCR y las copias de seguridad

No se puede realizar una copia de seguridad de una copia de destino de SCR. LCR y CCR admiten copias de seguridad tanto de la copia activa como de la pasiva. SCR admite copias de seguridad sólo del origen de SCR. Los encabezados de base de datos de un destino de SCR se actualizarán, y los registros de archivo se truncarán cuando se realice una copia de seguridad admitida del grupo de almacenamiento del origen de SCR. Si el grupo de almacenamiento del origen de SCR está habilitado para CCR o LCR, los encabezados de la base de datos del destino de SCR se actualizarán y los archivos de registro se truncarán cuando se hagan copias de seguridad de la copia pasiva o la copia activa del grupo de almacenamiento del origen de SCR.

SCR y restauraciones

Cuando se sustituye una base de datos de origen de SCR por una versión anterior de la base de datos, debe detener y, a continuación, reanudar la replicación continua para el grupo de almacenamiento utilizando 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 tendrá una información de generación de registros no actualizada y detendrá la replicación de los archivos de registro.

SCR y el truncamiento del archivo de registro

En la versión RTM de Exchange 2007, se aplican reglas para que, en un entorno de replicación continua, un archivo de registro no se elimine a no ser que se haya realizado una copia de seguridad y se haya reproducido en la copia de la base de datos. Esta regla se modifica cuando se utiliza SCR. SCR (que introduce el concepto de copias múltiples de la base de datos) permite truncar los registros de archivo en el origen de SCR en cuanto sean inspeccionados por todos los equipos de destino de SCR. El truncamiento de registro en el origen de SCR no espera a que se hayan reproducido todos los registros en todos los destinos de SCR, porque las copias del destino de SCR se pueden configurar con grandes retrasos de la reproducción del registro. Sin embargo, el truncamiento de registros de un origen de SCR no se producirá si uno o varios destinos de SCR de un mismo grupo de almacenamiento están inactivos Para que los registros se trunquen en un origen de SCR, el/los equipo(s) de destino de SCR deben estar en línea y accesibles para el origen.

En un destino de SCR, cada tres minutos se ejecuta un subproceso en segundo plano para determinar si hace falta truncar algún archivo de registro. Si se cumplen los tres criterios siguientes, se truncará un archivo de registro en un destino de SCR:

  • El archivo de registro se ha truncado en el origen de SCR.

  • La secuencia de generación del archivo de registro se encuentra por debajo del punto de control del archivo de registro para el grupo de almacenamiento.

  • El archivo de registro es anterior a ReplayLagTime + TruncationLagTime. (Para obtener una descripción de estos parámetros, consulte "Actualizaciones de cmdlet para SCR" en el tema Replicación continua en espera)

En un entorno de replicación continua local (LCR) o de replicación continua en clúster (CCR) ampliado con SCR, si se cumplen los tres criterios siguientes, se truncará un archivo de registro en la copia activa y la pasiva en el entorno de LCR o CCR:

  • Se ha realizado una copia de seguridad del archivo de registro.

  • La secuencia de generación del archivo de registro se encuentra por debajo del punto de control del archivo de registro para el grupo de almacenamiento.

  • Todos los destinos de SCR han inspeccionado el archivo de registro.

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

Aunque no se necesitan optimizaciones de red cuando se usa SCR en Windows Server 2008, al utilizarlo en Windows Server 2003 es recomendable optimizar la configuración 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 un equipo de origen de SCR y en los equipos de destino de SCR. 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 SCR. Tanto el origen de SCR como todos sus destinos de SCR deberán utilizar IPsec, o bien no utilizar IPSec ni el origen de SCR ni ninguno de sus destinos. Si sólo se configura un nodo para que utilice 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 pueden recibirse 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 que usted tenga, ya que hay más tiempo para enviar datos entre confirmaciones. Al aumentar el tamaño de la ventana de TCP, el sistema puede beneficiarse 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 puede especificarse 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 utilizando ventanas escalables, según se describe en RFC 1323, Ampliaciones de TCP para un alto rendimiento. Al utilizar 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 suelen utilizar en los protocolos de transferencia 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. Para descargar la calculadora, consulte Calculadora de requisitos de almacenamiento de la función del servidor Buzón de correo de Exchange 2007 en el blog del equipo de Exchange. La calculadora de almacenamiento incluye también instrucciones paso a paso para introducir valores del Registro en sus servidores.

Nota

UNRESOLVED_TOKEN_VAL(exBlog)

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 utiliza 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 descubrió 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 utilice el Monitor de red de Microsoft o una herramienta de captura similar para recopilar y analizar el tráfico de la interfaz de red utilizada para copiar registros del nodo activo al nodo pasivo. Para ver los pasos detallados para modificar el valor del Registro de ArpCacheMinReferencedLife, consulte Apéndice A: Parámetros de configuración de 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.

A pesar de que estas características pueden ofrecer ventajas de rendimiento de red en algunos entornos, hay algunos escenarios en los que no se pueden utilizar 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.

Nota

UNRESOLVED_TOKEN_VAL(exBlog)

Recomendamos que deshabilite todas las características de entornos SCR 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 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 web Scalable Networking.