Factores de rendimiento y procedimientos recomendados para migraciones híbridas
Hay muchas rutas de acceso para migrar datos de una organización de correo electrónico local a Microsoft 365 o Office 365. Al planear la migración, una pregunta común es cómo mejorar el rendimiento de la migración de datos y optimizar la velocidad de migración. En este artículo se describe el rendimiento de la migración para las implementaciones híbridas de Exchange. Para obtener información sobre el rendimiento sobre otros métodos de migración, consulte Microsoft 365 y Office 365 el rendimiento de la migración y los procedimientos recomendados.
La migración de implementación híbrida admite la migración sin problemas entre servidores de Exchange locales y Exchange Online en Microsoft 365 o Office 365.
La migración de implementación híbrida es, con diferencia, el método de migración más rápido para migrar datos de buzón a Microsoft 365 o Office 365. Hemos visto un rendimiento de hasta 100 GB/hora durante las implementaciones reales de clientes. En la tabla siguiente se proporciona una lista de factores que se aplican a los escenarios nativos de migración híbrida de Microsoft 365 y Office 365.
Si su entorno local contiene varios sitios en ubicaciones geográficamente dispersas, puede crear extremos de migración geográficamente próximos para mejorar el rendimiento de la migración. En estos casos, la migración usa la red de Microsoft en lugar de un extremo de migración centralizado que usa su red local.
Factor 1: Origen de datos (Exchange Server)
| Lista de comprobación | Descripción | Procedimientos recomendados |
|---|---|---|
| Rendimiento del sistema | La extracción de datos es una tarea intensiva. El sistema de origen debe disponer de los recursos suficientes, como memoria y tiempo de CPU, para proporcionar el mejor rendimiento de migración. En el momento de la migración, el sistema de origen suele estar cerca de la capacidad completa para atender la carga de trabajo de usuario final normal. La carga de trabajo de migración adicional a veces incluso reduce el acceso de los usuarios finales debido a la falta de recursos del sistema. | Supervise el rendimiento del sistema durante una prueba piloto de migración. Si el sistema está ocupado, le recomendamos evitar una programación de migraciones agresiva para el sistema determinado porque es posible que la migración se vea ralentizada y haya problemas con la disponibilidad del servicio. De ser posible, mejore el rendimiento del sistema de origen agregando recursos de hardware y reduciendo la carga del sistema trasladando tareas y usuarios a otros servidores que no participen en la migración. Para obtener más información, vea: estado y rendimiento de Exchange Server Descripción del rendimiento de Exchange 2010 Cuando se realice una migración desde una organización de Exchange local donde hay múltiples servidores de buzones de correo y múltiples bases de datos, recomendamos crear una lista de usuarios de migración que se distribuya uniformemente entre los múltiples servidores de buzones de correo. Basándose en el rendimiento de cada servidor, la lista puede optimizarse aún más para maximizar la capacidad de proceso. Por ejemplo, si el servidor A tiene un 50% más de disponibilidad de recursos que el servidor B, es comprensible que haya un 50% más de usuarios del servidor A en el mismo lote de migración. Se pueden aplicar procedimientos similares a otros sistemas de origen. Realice las migraciones cuando los servidores tengan la mayor disponibilidad de recursos posible, como puede ser después del horario laboral o en fines de semana y durante días festivos. |
| Tareas de back-end | Otras tareas de back-end que se ejecutan durante el proceso de migración. Debido a que realizar las migraciones después del horario laboral es un procedimiento recomendado, también es típico que las migraciones entren en conflicto con otras tareas de mantenimiento que se están ejecutando en los servidores locales, como las copias de seguridad de datos. | Revise las otras tareas del sistema que pueden estar ejecutándose durante la migración. Recomendamos que las migraciones se lleven a cabo cuando no se estén ejecutando otras tareas de uso intensivo de recursos. Nota: Para los clientes que usan Microsoft Exchange local, las tareas de back-end comunes son las soluciones de copia de seguridad y el mantenimiento del almacén de Exchange . |
Factor 2: Servidor de migración
La migración de implementaciones híbridas es un método de migración de extracción e inserción de datos iniciado en la nube, y un servidor híbrido de Exchange actúa como el servidor de migración. A menudo esto no se tiene en cuenta y los clientes usan una máquina virtual de baja escala como servidor híbrido. Esto empobrece el rendimiento de la migración.
Procedimiento recomendado del servidor de migración
Además de aplicar los procedimientos recomendados descritos anteriormente, probamos los siguientes procedimientos recomendados que mejoraron el rendimiento de la migración en migraciones de clientes reales:
- Use máquinas físicas de tipo servidor potentes en lugar de máquinas virtuales para los servidores híbridos de Exchange.
- Use múltiples servidores híbridos que estén detrás del equilibrador de carga de la red del cliente.
Por ejemplo, en migraciones de clientes reales, se logró una capacidad de proceso constante de 30 GB/hora con la configuración siguiente:
- Red: canalización saliente de 500 mb a Internet; red interna en 1 GB con una red troncal de fibra de 10 GB.
- Hardware: las especificaciones de los dos servidores de acceso de cliente/CONCENTRADOR (físico) son:
- CPU: Intel® Xeon® CPU E5520 de 2,27 GHz 2,26 GHz (2 procesadores).
- RAM: 24 GB.
- Discos: Ocho de 146 GB por disco. Configuración de volumen RAID-5 = 960 GB de espacio total no asignado.
- MRSProxy: configurado con una simultaneidad de 100.
Factor 3: Motor de migración
La migración de implementación híbrida usa herramientas nativas de Microsoft 365 y Office 365. Está sujeto a microsoft 365 y Office 365 limitación del servicio de migración.
Exchange 2003 frente a las versiones posteriores de Exchange
Existe una diferencia clave en la experiencia del usuario final cuando se realiza la migración desde Exchange 2003. A diferencia de las versiones posteriores de Exchange, los usuarios finales de Exchange 2003 no pueden acceder a los buzones de correo cuando se están migrando los datos. Por lo tanto, para los clientes de Exchange 2003 suele ser más importante cuándo programar las migraciones y el tiempo que tardan en llevarse a cabo, especialmente cuando el rendimiento de la migración es bajo porque el tamaño del buzón de correo es muy grande o porque la red es muy lenta.
Asimismo, la migración de Exchange 2003 es muy susceptible a interrupciones. Por ejemplo, en una migración de cliente real, durante la migración de un buzón de 10 GB, se produjo un incidente de servicio cuando la migración del buzón se completó al 50 %. Fue necesario reiniciar el servidor de acceso de cliente de Office 365 que procesaba la migración de datos para resolver el problema. En este caso, la migración de ese buzón tuvo que reiniciarse, lo que significaba que el cliente tenía que volver a migrar los 10 GB de datos. No fue posible reanudar la migración desde el punto en el que se detuvo. Sin embargo, Exchange 2010 y las versiones posteriores de Exchange tienen la capacidad de reanudar las migraciones después de sufrir interrupciones.
Procedimiento recomendado del motor de migración
Algunos clientes prefieren hacer migraciones de dos saltos para buzones de Exchange 2003 más grandes y sensibles:
- Primer salto: migre buzones de Exchange 2003 a un servidor de Exchange 2010 o posterior, que suele ser el servidor híbrido. El primer salto es un movimiento sin conexión, pero suele ser una migración muy rápida a través de una red local.
- Segundo salto: migre buzones de Exchange 2010 o versiones posteriores a Microsoft 365 o Office 365.
El segundo salto es un movimiento en línea, lo que proporciona una mejor experiencia del usuario y tolerancia a errores. Este enfoque de dos saltos necesita una licencia de Exchange para el buzón de correo local temporal del usuario.
Proxy del servicio de replicación de buzones (MRSProxy)
Proxy MRS es la característica de migración local que funciona con el servicio de replicación de buzones que se ejecuta en Microsoft 365 y Office 365 lado. Para obtener más información, vea la Descripción de solicitudes de movimiento
Procedimiento recomendado de MRSProxy
Se puede configurar el número máximo de conexiones de MRSProxy para el servidor híbrido de Exchange local. Ejecute el siguiente comando de Windows PowerShell.
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSMaxConnections <number between 0 and unlimited; default is 100>
Nota:
En la mayor parte de las migraciones de cliente no es necesario cambiar el valor predeterminado de MRSMaxConnections. Si necesita proteger el servidor de origen para que no se colapse con la carga de la migración, puede reducir el número de conexiones. Esta configuración se realiza en cada servidor MRSProxy. Si el cliente tiene dos servidores MRSProxy, cada uno con 10 conexiones, el número de conexiones MRSProxy que recibirán será de 20 (2x10). Para obtener más información sobre cómo configurar el servicio MRSProxy en la organización Exchange 2010 local, vea Iniciar el servicio MRSProxy en un servidor de acceso de cliente remoto.
Factor 4: Red
Pruebas de comprobación
Los clientes que utilizan Exchange 2010 o versiones posteriores pueden probar el rendimiento de la red en las migraciones híbridas realizando múltiples migraciones de buzones de prueba. Si no, también se pueden migrar buzones de usuarios reales con la opción "-SuspendWhenReadyToComplete" para obtener una indicación del rendimiento de la migración. Cuando finalice la prueba, elimine la solicitud de movimiento para que no influya en los usuarios finales.
Para obtener más información acerca de las solicitudes de traslado, consulte New-MoveRequest.
Factor 5: Servicio de Office 365
La limitación basada en el estado de los recursos de Microsoft 365 y Office 365 afecta a las migraciones mediante Las migraciones de implementación híbrida de Microsoft 365 o Office 365. Consulte la sección Factor 3: Motor de migración anterior para obtener más detalles.