Directrices de implementación para replicar datos de varios sitios de Exchange Server

Última modificación del tema: 2006-09-01

La tecnología de replicación puede ofrecer una alta disponibilidad para los datos de Microsoft® Exchange Server. Este tema está destinado a ayudarle a conocer mejor la tecnología de almacenamiento de replicación y el modo de utilizarla en el entorno de Exchange Server.

La replicación admite una alta disponibilidad a través de la redundancia de datos en varios sitios, pero no impide que se produzcan daños en los datos. Si se escriben datos dañados en el dispositivo de almacenamiento principal que producen daños en la base de datos, estos mismos datos se replicarán en los sitios remotos y dañarán las bases de datos de los sitios remotos. De modo que la replicación de datos no sustituye a los procesos de mantenimiento de bases de datos como, por ejemplo, la copia de seguridad de la base de datos que valida periódicamente la integridad de la base de datos.

En este tema se analizan los datos a los que se accede a través de la ejecución de servicios de Exchange, por ejemplo, las peticiones de E/S de escritura realizadas mediante un proceso de Exchange. Aquí no se analiza la replicación de datos del sistema/SO

Microsoft tiene directivas de compatibilidad para varios tipos de soluciones de replicación. Para obtener información sobre estas directivas de compatibilidad, consulte el artículo 895847 de Microsoft Knowledge Base "Compatibilidad de datos de multisitio para Exchange 2003 y Exchange 2000 con réplica".

Mecanismos de replicación

La finalidad del uso de la replicación de datos es mantener réplicas actuales de los datos en sitios remotos. Los servidores de Exchange pueden utilizar las réplicas de estos sitios remotos para continuar con el servicio de correo electrónico si se produce una interrupción del servicio de almacenamiento o del sitio en la ubicación principal. La replicación de datos se puede propagar de forma sincrónica o asincrónica. Por definición, cuando los datos se replican sincrónicamente, los host sólo reciben una respuesta de escritura completa del almacén cuando se ha validado la escritura de E/S en las ubicaciones locales y remotas. Es decir, el almacén local y el remoto deben implementar el cambio antes de que se confirme que la escritura se ha realizado correctamente en el host. En el modo asincrónico, el host recibe una escritura completa del almacén cuando la escritura se ha validado en el almacén local, sin que sea necesario esperar la confirmación de que la réplica también se ha actualizado en el almacén remoto.

Replicación asincrónica

En general, la aplicación de host no es tan sensible en cuanto al aumento de la latencia de escritura en función de la distancia de replicación cuando se utiliza replicación asincrónica, como lo sería en modo de replicación sincrónica. No obstante, cuando se implementa replicación asincrónica se deben tener en cuenta las cuestiones siguientes:

• Pérdida de datos   Dependiendo de la frecuencia de la replicación de datos, los cambios de los datos en el sitio remoto pueden retrasar los cambios realizados en el sitio principal. En caso de una interrupción en el sitio principal, la réplica del sitio remoto no será la más actualizada. Aunque este retraso se puede configurar en la mayoría de las soluciones de almacenamiento, debe tener en cuenta la posibilidad de pérdida de datos debida a este comportamiento.
• Integridad de los datos (mantenimiento del orden de la escritura)   Exchange tiene dependencias en el orden de la escritura entre la base de datos y los registros de transacciones asociados. Exchange siempre escribe los cambios en los archivos de registro en primer lugar, antes de validar estos cambios en los archivos de base de datos. Cuando se encuentra en modo de replicación sincrónica, la aplicación controla el orden de la escritura. Sin embargo, en modo asincrónico, la solución de replicación controla cuando se replican los datos. Si la solución no mantiene el orden de la escritura durante la replicación, podría dañar los archivos de la base de datos e impedir el montaje de las bases de datos si se produce un desastre en el sitio principal.
• Impacto en el rendimiento   Muchos proveedores afirman que sus soluciones asincrónicas no influyen en el rendimiento del almacenamiento pero, en realidad, cuando se ejecuta una replicación asincrónica se produce una degradación del rendimiento. Dependiendo de la implementación de la solución, las expectativas de rendimiento no se pueden describir con una sola cifra. Por ello, los clientes deben probar la solución antes de implementarla, y el objetivo es verificar que puede proporcionar un rendimiento de almacenamiento adecuado para los usuarios de Exchange.

Algunos proveedores de soluciones utilizan diferentes tecnologías para responder al problema de la conservación del orden de la escritura. Para implementar correctamente una solución replicada de forma asincrónica, el cliente deberá trabajar con el proveedor para asegurarse de que su tecnología asincrónica cumple los siguientes requisitos:

• Puede mantener la coherencia del orden de la escritura de todos los dispositivos de un grupo de almacenamiento, incluida la coherencia continua entre ellos;
• demuestra que es recuperable, sobre todo en los entornos de laboratorio y producción;
• El proveedor que la suministra dispone de un plan de soporte técnico para los datos replicados.

Replicación sincrónica

La principal preocupación de la replicación asincrónica en la implementación de Exchange está relacionada con el rendimiento. Las pruebas han demostrado que la experiencia del cliente está estrechamente vinculada a la latencia de escritura. Con una solución de replicación sincrónica, se reduce el número de buzones que se puede alojar en cada servidor de Exchange. El impacto del rendimiento depende en gran medida de la distancia de la replicación, el ancho de banda del vínculo de replicación y la utilización. La replicación sincrónica puede producir una reducción de hasta el 75 por ciento en la escalabilidad de buzones/servidores. Cuando trabaje en la metodología de diseño de la capacidad de Exchange debe tener en cuenta esta reducción de la escalabilidad. Para obtener más información, consulte "Diseño de la implementación de replicación sincrónica" en este tema.

Generalmente, la replicación sincrónica se ha considerado una solución que garantiza que no se pierdan datos porque las réplicas están completamente sincronizadas con los archivos de datos del almacén principal. Sin embargo, al contrario de esta creencia común, existen situaciones en las que las soluciones de replicación sincrónica pueden perder datos. El ejemplo siguiente ilustra este tipo de situaciones.

Normalmente, las soluciones de replicación de datos de almacenamiento gestionan el fallo de un vínculo de replicación de los dos modos siguientes:

• Continúan validando la E/S de escritura sólo en el dispositivo de almacenamiento principal, registran todos los cambios realizados en todos los dispositivos que utilizan el vínculo de replicación en un archivo de registro y almacenan el registro en el almacén principal.
• No realizan la operación de escritura para que la aplicación gestione el fallo como si el disco estuviera dañado.

Si la solución de replicación utiliza el primer método de gestión, se pueden perder datos. Durante una condición de error del vínculo seguida de un error del sitio principal, los datos que se hayan validado después del error del vínculo no se replicarán y, por lo tanto, se perderán junto con el error del almacén principal. Cuando diseñe la solución de replicación de almacenamiento, tenga en cuenta estos tipos de condiciones de error para crear un sistema que reduzca estas situaciones. En este ejemplo, es posible que el cliente desee considerar la posibilidad de implementar vínculos de replicación redundantes para reducir la probabilidad de perder datos.

Soluciones de replicación sincrónicas

Las soluciones de replicación sincrónicas se clasifican, en función del lugar en el que se produce la replicación, como replicación basada en host o replicación basada en almacenamiento. La replicación basada en host utiliza software basado en host (controlador de filtro) para interrumpir la secuencia de E/S y gestionar la replicación. La replicación basada en almacenamiento se produce fuera del host, en el nivel del dispositivo de almacenamiento. Ambas soluciones de replicación se pueden implementar como parte de lo siguiente:

• Organización en clústeres dispersos geográficamente (Geocluster)   En esta categoría, los nodos que pertenecen al mismo clúster están situados en sitios diferentes. Generalmente, los servidores de Exchange se alojan activamente en el sitio principal a través de los nodos. Las soluciones proporcionan replicación sincrónica de los datos de Exchange en los sitios remotos. En caso de desastre en el sitio principal, los servidores virtuales de Exchange realizan la conmutación por errores a los nodos pasivos del sitio remoto y se ponen en línea utilizando los datos replicados de Exchange.
  El servidor de catálogo de Microsoft Windows® tiene una categoría para soluciones de organización en clústeres dispersos geográficamente. Puede buscar Laboratorios de calidad de hardware de Windows (WHQL)-soluciones de organización en clústeres dispersos geográficamente en https://go.microsoft.com/fwlink/?LinkId=28572.
• Otras  En esta categoría se incluyen todos los demás tipos de implantaciones de replicación sincrónicas que no utilizan organización en clústeres dispersos geográficamente. Estas soluciones se basan en otros medios para utilizar datos replicados de Exchange en los sitios remotos en caso de error del sitio principal (por ejemplo, una solución en espera; replicación unida a procesos de recuperación de desastres).

Microsoft recomienda encarecidamente que los clientes obtengan garantías de los proveedores de soluciones de replicación para las siguientes cuestiones:

• ¿La solución está incluida en la categoría de organización de clústeres dispersos geográficamente? Si es así, ¿está certificado por WHQL? Si no es una solución de esta categoría ¿el dispositivo de almacenamiento está incluido en una de las soluciones descritas en la sección "Soluciones de clústeres, solución de organización en clústeres dispersos geográficamente" del catálogo de Windows Server?
• ¿La solución de replicación evitará cualquier posible pérdida de datos a menos que se produzca una interrupción del servicio en todos los sitios al mismo tiempo?
• ¿Cuáles son los procedimiento para realizar una conmutación por error o una recuperación tras error?
• ¿La solución de replicación y la latencia esperada pueden encargarse de la carga de usuarios de Exchange planificada y proporcionar una experiencia de calidad al cliente?

Datos de Exchange que se replican

Exchange es una aplicación de servidor basada en datos. La replicación de datos de Exchange en un sitio secundario proporciona redundancia en caso de errores relacionados con el almacenamiento. La determinación de la clase de datos que se va a replicar es una decisión de la empresa. Debe evaluar la tolerancia de su empresa frente a la pérdida de los distintos tipos de datos que se describen aquí.

Datos cuya replicación es obligatoria

Los datos siguientes se deben replicar:

• Archivos de la base de datos de buzones de Exchange que almacenan datos del mensaje. Cada base de datos consta de dos archivos:
  • Archivo de base de datos (.edb) que contiene mensajes y contenido MAPI.
  • Archivo de secuencias (.stm), que contiene contenido nativo, distinto al contenido MAPI.
• Archivos de registro de transacciones (.log) que registra cada transacción que se valida en la base de datos.
• Archivos de puntos de control (.chk) que contienen información sobre las entradas de los archivos de registro que se han escrito en el disco.

Todos estos archivos son fundamentales para que los clientes puedan obtener acceso al servidor de buzones y a la recuperación de software de los cambios de la base de datos que se conservan en la memoria y se pierden si los almacenes del servidor de Exchange no se cierran correctamente como, por ejemplo, en caso de un corte del suministro eléctrico. Debido a la importancia de estos archivos, este conjunto de datos se debe replicar. Las rutas de los archivos de la base de datos se especifican en la página de propiedades de la base de datos y cada base de datos tiene su propia ruta. La ruta del archivo de registro de transacciones y del archivo de punto de control se especifica en la página de propiedades del grupo de almacenamiento y dependen de todas las bases de datos de ese grupo de almacenamiento.

La decisión de replicar bases de datos de carpetas públicas es mucho más compleja. Hacerlo o no depende en parte del diseño de la topología de Exchange de su implementación. A diferencia de los datos de los buzones, Exchange Server puede replicar directamente los datos de las carpetas públicas. Puede tener varias réplicas de almacenes de carpetas públicas que repliquen cambios (contenido). La replicación de estos datos no se realiza de modo sincrónico.

Las soluciones Geocluster requieren la replicación sincrónica de las carpetas públicas dentro del clúster. Este requisito es necesario para que el clúster se encuentre completamente funcional en el sitio secundario. Las bases de datos de buzones que se encuentran dentro del clúster deben señalar al almacén de carpetas públicas (“Almacén público predeterminado”) que también está alojado dentro del clúster para que los clientes puedan iniciar la sesión inmediatamente después de que el clúster se encuentre disponible en el sitio secundario. Las carpetas públicas que se encuentran dentro del geocluster sólo necesitan alojar la jerarquía y no necesariamente el contenido completo para facilitar el inicio de sesión en el buzón durante una condición de error. La opción de alojar el contenido completo de la carpeta pública y replicarlo sincrónicamente dentro de las carpetas públicas alojadas en el geocluster es una decisión de la empresa. Si los datos de la carpeta pública son fundamentales para las actividades empresariales básicas, es decir, si sólo se puede admitir una pérdida mínima de datos, deberá considerar la posibilidad de utilizar una solución de geocluster en lugar del mecanismo de replicación de carpetas públicas de Exchange Server. Si no necesita este grado de disponibilidad de los datos de las carpetas públicas, puede utilizar una solución de replicación sincrónica distinta a geocluster para los datos de los buzones, combinada con el mecanismo de replicación que se encuentra en las carpetas públicas de Exchange.

Datos cuya replicación es recomendable

Los datos de cola local del Protocolo simple de transferencia de correo (SMTP) (directorio Mailroot) se conservan temporalmente en el dispositivo de almacenamiento mientras Exchange Server los procesa. Este diseño evita la pérdida de datos en caso de error del servidor. Por ejemplo, si no se puede obtener acceso a un servidor de destino, los mensajes que se enrutarían a ese servidor se almacenan en el directorio de cola de servidor local hasta que se pueden entregar. Si el disco que almacena los datos de la cola tiene un error, todos los mensajes de la cola se perderán. Debido al carácter transitorio de los datos de la cola, no existe un proceso definido para realizar una copia de seguridad de las colas de correo como el que existe para realizar copias de seguridad de las bases de datos de Exchange Server. La tolerancia a errores y/o las soluciones de alta disponibilidad para el almacén en el que se conserva esta información en cola le pueden proteger de una posible pérdida de datos. También es recomendable que los datos de cola MTA (directorio MTADATA) se repliquen en entornos en los que no se puedan perder los mensajes transitorios debido a errores del sitio.

La ruta del Mailroot de SMTP (incluidos los directorios de cola, correo erróneo para cada instancia de servidor virtual) se especifica en la ficha de mensajes de la página de propiedades del servidor virtual del Administrador del sistema Exchange (ESM) y en la página de propiedades de X.400 para la ruta de cola MTA. Debe mirar el perfil para decidir si es necesario replicar los datos de cola de Exchange. Si ya dispone de una topología de Exchange, puede decidir si puede admitir la pérdida de datos en la cola local. Puede medir la cantidad de datos esperada de la cola local mediante el uso de la longitud de cola local del Monitor de rendimiento (Perfmon.msc) o el Visor de cola del Administrador del sistema de Exchange (ESM) durante períodos de carga intensa. Si se necesita replicación de los datos de la cola, es importante probar el rendimiento del procesamiento de mensajes en el entorno de replicación, de modo que la latencia de replicación que se introduzca no cree un cuello de botella en el transporte. Puede utilizar la herramienta Exchange Server Stress and Performance 2003 para probar la capacidad de transporte en un entorno de replicación sincrónico en el que se repliquen datos de cola. Esta herramienta se puede descargar del sitio Web Exchange Server Stress and Performance 2003.

Datos cuya replicación es opcional

Los registros de seguimiento de mensajes contienen información sobre todos los mensajes transferidos a, desde y dentro de un servidor de Exchange. Estos datos pueden ser importantes para fines de diagnóstico. De forma predeterminada, el seguimiento de mensajes no está habilitado. Sin embargo, si estos datos son importantes para su empresa, se pueden replicar para evitar su pérdida si se produce un desastre. La ruta del registro de seguimiento de mensajes se especifica en la página de propiedades de Exchange Server en ESM.

Prácticas recomendadas para la configuración de mecanismos de replicación

Cada proveedor tiene varias implementaciones propias de mecanismos de replicación que proporcionan para diferentes opciones de replicación. Debe analizar los detalles de la solución con el proveedor para determinar si la solución que propone es la más adecuada para satisfacer las necesidades de su organización y el Acuerdo de nivel de servicio (SLA) para recuperación de desastres. Las recomendaciones siguientes sólo se pueden aplicar a algunas soluciones de replicación:

• Configure la replicación en el nivel del volumen de punto lógico o de montaje.
  Aunque los datos que se deben replicar se conservan en los archivos que se describen en la sección "Datos de Exchange que se replican" de este tema, debe asegurarse de que, en el nivel del host, la replicación esté configurada para la unidad de un volumen de punto lógico o de montaje. Por ejemplo, si la ruta de datos de los buzones es G:\MDB1\MDB1.EDB, la unidad G deberá ser la unidad base para efectuar la replicación. Como resultado, todos los datos de la unidad G se replicarán. El ajuste de la replicación para que se efectúe en el nivel de archivo o de subdirectorio es proclive a errores humanos y Microsoft no lo admite.
• Cree muchos puntos de replicación.
  Para reducir la cola de varias E/S que están destinadas al mismo punto de replicación, configure el almacén para que cree todos los puntos de replicación que sea posible. Equilibre la carga de E/S entre varios puntos de replicación. Dependiendo de la solución de almacenamiento/replicación, este enfoque puede reducir la latencia de lectura/escritura de E/S gracias a la reducción de la cola de E/S.
• Conserve los registros de transacciones en volúmenes lógicos diferentes.
  Cuando se están replicando los datos, cada petición de E/S de escritura se pone en cola en el nivel de punto de replicación. Exchange escribe registros en un patrón secuencial y, si estas E/S están destinadas al mismo punto de replicación, es muy probable que cada E/S se ponga en cola para escritura. Esta situación puede contribuir a que el tiempo de respuesta de escritura sea más largo, lo que puede ser un factor muy negativo en el rendimiento o la escalabilidad de Exchange. Por este motivo, Microsoft recomienda la segmentación de los registros de transacciones de diferentes grupos de almacenamiento o en distintos volúmenes lógicos con varios puntos de replicación.
• Utilice varios vínculos de replicación.
  Con frecuencia, el rendimiento o la escalabilidad de la solución de replicación mejora mediante la configuración de varios vínculos de replicación entre los sitios principales y secundarios. La implementación de este enfoque puede resultar costosa y no es necesaria para la replicación de datos de Exchange. No obstante, existen implementaciones que deben utilizar varios vínculos de replicación para obtener la escalabilidad o el rendimiento deseados para una solución de replicación de datos de Exchange determinada. También puede ser necesario equilibrar la carga de los puntos de replicación entre los vínculos de replicación disponibles para obtener un rendimiento óptimo de replicación.
  Dado que Exchange tiene dependencia en el orden de escritura entre las bases de datos y los registros de transacciones asociados, es importante configurar un grupo de puntos de replicación que respalde los volúmenes lógicos del grupo de almacenamiento (que incluye el número de unidad lógica de base de datos (LUN) y el registro LUN) para que utilicen el mismo vínculo de replicación. Esta configuración es necesaria para conservar el orden de la escritura en el nivel del grupo de almacenamiento, que es fundamental para mantener la integridad de los datos en el sitio remoto en caso de situaciones de error, como un error del vínculo.
  El uso de varios vínculos de replicación con múltiples puntos de replicación puede ser un enfoque eficaz para escalar una solución de replicación de datos de Exchange. Además, este enfoque puede reducir la posibilidad de perder datos. Esto se analiza en el ejemplo de la sección anterior "Replicación sincrónica".

Prácticas recomendadas para la configuración de Exchange para replicación sincrónica

Cuando Exchange se implementa en un entorno de replicación sincrónica, se puede mejorar el rendimiento y la escalabilidad del servidor con unos cuantos cambios en la configuración. Es importante conocer estos cambios en la fase de diseño para poder implementarlos durante el diseño del almacenamiento y la replicación. Las prácticas recomendadas para configuración son las siguientes:

• Cree el número máximo de grupos de almacenamiento para cada servidor de Exchange.
  El incremento del número de grupos de almacenamiento en una solución de Exchange replicada sincrónicamente puede beneficiar al rendimiento y la escalabilidad de la implementación mediante transacciones de escritura del registro de equilibrio de carga en varios volúmenes lógicos y, como consecuencia, en varios puntos de replicación. En general, existirán más procesos de escritura de registros paralelos, lo que puede reducir la latencia de escritura del registro de transacciones general (reducción de la cola de E/S) en un entorno de replicación sincrónico. Exchange Server 2003 Enterprise Edition admite cuatro grupos de almacenamiento en cada servidor de Exchange.
• Aumente el tamaño del búfer de registro de transacciones.
  La latencia de E/S de escritura del registro de Exchange es un factor muy importante de la escalabilidad en las soluciones de replicación sincrónica de Exchange. Las E/S de escritura del registro son secuenciales y con un único subproceso, de modo que es probable que la latencia de la E/S del registro sea un cuello de botella para el sistema. Las E/S del registro se escriben en los búferes de registro en primer lugar y, a continuación, el búfer se limpia mediante una ejecución no perezosa o una validación de capacidad. Una ejecución no perezosa significa que el búfer de registro se escribe en el disco inmediatamente. Una validación de capacidad significa que el búfer de registro se escribe en el disco cuando el búfer está lleno.
  Al aumentar el tamaño del búfer de registro, disminuye la frecuencia de los volcados de capacidad, aumenta el tamaño de escritura de registro y, como consecuencia, se reduce la latencia de escritura general. La reducción de la latencia de escritura de E/S es un modo eficaz de mejorar el rendimiento y la escalabilidad de la implementación de Exchange.
  Se recomienda incrementar el tamaño del búfer hasta 9.000 como máximo, si la replicación se efectúa a través de canales de fibra. En el caso de vínculos con ancho de banda bajo, como los vínculos TCP/IP, no resulta fácil determinar un valor óptimo para este parámetro. Si el vínculo muestra saturación para el aumento del tamaño de escritura de registro, lo que reduce la velocidad de la replicación, deberá realizar pruebas detalladas para determinar el tamaño óptimo del búfer de registro que pueda reducir al mínimo la latencia de escritura de registro. Para obtener información sobre el modo de modificar este parámetro, consulte en Microsoft Knowledge Base el artículo 328466, "Búferes ESE de registro que se establecen demasiado en bajos pueden provocar que el servicio Almacén de información de Microsoft Exchange deje de responder". También puede consultar este valor con su proveedor de soluciones.

Diseño de la implementación de replicación sincrónica

Aunque la solución de almacenamiento de replicación sincrónica haya seguido las recomendaciones anteriores, puede seguir produciendo problemas de rendimiento a los clientes de Exchange si la no se ha probado completamente antes de implementarla. No existen reglas definitivas sobre los efectos negativos de la implementación de replicación sincrónica con Exchange para la escalabilidad y el rendimiento. Cada solución de replicación de Exchange tiene distintos factores que influyen en el rendimiento, entre los que se incluyen, sin limitarse a ellos, los siguientes: distancia entre los sitios, mecanismo de transporte de replicación, número de vínculos de replicación, número de puntos de replicación, número de grupos de almacenamiento de Exchange, opciones de configuración de la base de datos o el registro de Exchange, arquitectura de almacenamiento y replicación, y perfil del cliente de Exchange. Cada solución es única y se necesita un diseño y pruebas detallados para que la implementación se efectúe correctamente.

La latencia de escritura de E/S que se atribuye a las soluciones de replicación sincrónicas es el elemento fundamental de la limitación de la escalabilidad de Exchange. Este aumento de la latencia de E/S crea una carga en el servidor que puede influir considerablemente en la experiencia del cliente de Exchange. En concreto, la elevada latencia de escritura ocasiona el incremento de la latencia de RPC y, como consecuencia, el cliente experimenta mayor lentitud. Aunque la replicación sincrónica proporciona alta disponibilidad a los datos de Exchange, también conlleva una elevada penalización del rendimiento de E/S. Esta penalización de la escritura, y a veces la lectura, de E/S, es un factor decisivo a la hora de determinar el número máximo de usuarios que se puede admitir en una plataforma determinada.

En la fase de diseño, realice los pasos siguientes para validar el diseño:

1. Para conocer el modo más adecuado de diseñar y implementar el almacenamiento para Exchange, consulte Optimización del almacenamiento de Exchange 2003.
2. Utilice las pruebas de Jetstress para validar la velocidad de almacenamiento cuando está configurada la replicación sincrónica. Para descargar la herramienta Jetstress, consulte el sitio Web Microsoft Exchange Server Jetstress Tool.
3. Mida el efecto que tiene el aumento de la latencia de escritura en el cliente de correo electrónico mediante la ejecución de una prueba de Exchange Server Load Simulator 2003 (LoadSim) adaptada a su entorno. Para descargar LoadSim, consulte el sitio Web Microsoft Exchange Server 2003 Load Simulator (LoadSim).
4. Mida el rendimiento promedio del disco cuando ejecute LoadSim. El rendimiento del disco debe ser mayor o igual que el rendimiento promedio pico esperado en el entorno de producción que está simulando (IOPS/buzón). Para obtener información sobre el modo de medir el rendimiento promedio pico del disco, consulte Optimización del almacenamiento de Exchange 2003.
5. Preste atención al contador de latencia promedio del servidor y al tiempo de respuesta del cliente después de ejecutar las pruebas de LoadSim. Al analizar los resultados de la prueba, tenga en cuenta que los tres contadores deben cumplir los criterios que se indican a continuación.
   Latencia promedio de RPC
   Este contador muestra la cantidad de tiempo promedio necesaria para responder a una sola solicitud de llamada a procedimiento remoto (RPC). El aumento de la carga de usuarios o de la distancia de replicación causa un incremento de la latencia promedio de RPC. El límite máximo promedio es de 50 ms y el valor máximo debe ser de 100 ms. Si los resultados de la prueba muestran un promedio superior a 50 ms, es probable que el cliente experimente lentitud en general. Si el promedio es inferior a 50 ms pero, de vez en cuando, es superior a 100 ms, el cliente experimentará lentitud durante los picos.
   Contadores de latencia de disco
   El equipo de producto de Microsoft Exchange ha probado varias soluciones de replicación sincrónica de hardware. Los resultados indican la conexión entre la latencia promedio de RPC y la latencia de disco. Como regla general, la solución se puede encargar de la carga proporcionada cuando el promedio de latencia de lectura de base de datos sea inferior a 20 ms y el promedio de latencia de lectura y escritura de registro sea inferior a 20 ms. Los valores máximos de estas latencias se deben mantener por debajo de 40 ms. Por encima de estos umbrales, los clientes experimentarán lentitud en la respuesta.
   Tiempo de respuesta del cliente
   Puede confirmar la experiencia global del cliente mediante la ejecución de lslog.exe en todos los equipos del cliente. Esta actividad devuelve el promedio ponderado del percentil 95; este valor debe ser inferior a 1.000 ms. lslog.exe forma parte de la herramienta LoadSim. En la documentación de LoadSim se describe el modo de utilizar lslog.exe y de interpretar los resultados que ofrece.
   Para obtener más información sobre el rendimiento, consulte Solucionar problemas de rendimiento de Exchange 2003 (en inglés).
6. Pruebe la solución del perfil de buzón con la distancia de replicación diseñada. La distancia del vínculo de replicación tiene una limitación física. Al aumentar la distancia, el tiempo de respuesta del cliente/servidor disminuye como resultado del incremento de las latencias de escritura que genera la replicación sincrónica con la distancia. Generalmente, 100 Km se considera el umbral para replicación sincrónica de almacenamiento de datos de Exchange Server. Este valor de umbral puede variar en función de la implementación de la solución.
7. Cree un plan de copia de seguridad para validar la integridad de la base de datos con regularidad. La replicación no sustituye al proceso de copia de seguridad.
8. Asegúrese de que dispone de un plan integral de recuperación de desastres que se haya probado tan exhaustivamente como el rendimiento de replicación de la solución. Existen varios métodos de recuperación de datos, servidores y sitios de Exchange. Debe implementar un plan de recuperación de desastres que satisfaga las necesidades de su empresa y Acuerdos de nivel de servicio que le orienten durante la recuperación con rapidez y eficacia si se produce un desastre. Pruebe y valide el plan mediante la simulación de varios tipos de condiciones de error de una implementación de Exchange, a través de uso de replicación sincrónica en condiciones de carga elevada.