Optimización de la carga de red
Las tramas gigantes son tramas Ethernet de un tamaño superior a los 1500 bytes predeterminados. El tamaño habitual de las tramas gigantes es de 9000 bytes. El aumento del tamaño del marco en el servidor de base de datos de origen, en todos los dispositivos de red intermedios, como los conmutadores, y en los servidores Intel R3load reduce el consumo de CPU y aumenta el rendimiento de la red. El tamaño del marco debe ser idéntico en todos los dispositivos, ya que de lo contrario, se produce una conversión con un uso intensivo de los recursos.
Las características de redes adicionales, como la tecnología Ajuste de escala en lado de recepción (RSS), pueden activarse o configurarse para distribuir el procesamiento de red entre varios procesadores. Se ha demostrado que la ejecución de servidores R3load en VMware hace más complejo el ajuste de red para las tramas gigantes y RSS, por lo que no se recomienda, a menos que el nivel de conocimientos sea muy elevado.
R3load exporta los datos de las tablas DBMS y comprime esos datos sin procesar independientes de formato en archivos de volcado. Estos archivos de volcado deben cargarse en Azure e importarse en la base de datos de SQL Server de destino.
El rendimiento de la copia y la carga en Azure de estos archivos de volcado es un componente fundamental en el proceso de migración global.
Hay dos enfoques básicos para la carga de archivos de volcado R3load:
Copia desde servidores de exportación de R3load locales a Azure Blob Storage a través de la red pública de Internet con AzCopy
Ejecute una copia de AzCopy en cada uno de los servidores R3load con esta línea de comandos:
Azcopy copy "C:\ExportServer_1\Dumpfiles" "https://[storage_account].blob.core.windows.net/ExportServer_1/Dumpfiles?[SAS_Token]" --recursive
Para aumentar el rendimiento, establezca la variable de entorno AZCOPY_CONCURRENCY_VALUE. Esta variable especifica el número de solicitudes simultáneas que pueden producirse.
Si el equipo tiene menos de 5 CPU, el [valor] de esta variable se establece en 32. En caso contrario, el valor predeterminado es igual a 16 multiplicado por el número de CPU. El valor máximo predeterminado de esta variable es 300, pero puede establecerlo manualmente en un valor mayor o menor:
| Sistema operativo | Get-Help |
|---|---|
| Windows | set AZCOPY_CONCURRENCY_VALUE=[value] |
| Linux | export AZCOPY_CONCURRENCY_VALUE=[value] |
| macOS | export AZCOPY_CONCURRENCY_VALUE=[value] |
Use azcopy env para comprobar el valor actual de la variable de entorno AZCOPY_CONCURRENCY_VALUE. Si el valor está en blanco, puede leer el valor que se está usando al examinar el principio de cualquier archivo de registro de AzCopy. El valor seleccionado, y el motivo por el que se seleccionó, se indican allí.
Antes de establecer el valor de simultaneidad, realice una prueba comparativa. El proceso de esta prueba indica cuál es el valor de simultaneidad recomendado. Como alternativa, si las condiciones de red y las cargas varían, establezca esta variable en la palabra AUTO en lugar de en un número concreto. El valor AUTO hace que AzCopy ejecute siempre el mismo proceso de ajuste automático que utiliza en las pruebas del banco de pruebas.
El valor de la simultaneidad puede aumentarse si un cliente tiene un servidor potente y una conexión a Internet rápida. Sin embargo, si se aumenta demasiado, se pierde la conexión con el servidor de exportación de R3load debido a la saturación de la red. Supervise el rendimiento de la red en el Administrador de tareas de Windows. Se puede lograr fácilmente un rendimiento de copia de más de 1 Gigabit por segundo por servidor de exportación de R3load. Dicho rendimiento puede escalarse verticalmente si se tienen más servidores R3load (en el diagrama anterior se muestran cuatro).
Debe ejecutarse un script similar en los servidores de importación de R3load en Azure para copiar los archivos desde el Blob a un sistema de archivos al que R3load pueda acceder.
Copia desde servidores de exportación R3load locales a una máquina virtual de Azure o al almacenamiento de blobs mediante una conexión de ExpressRoute dedicada con AzCopy, Robocopy o una herramienta similar
Robocopy C:\Export1\Dump1 \\az_imp1\Dump1 /MIR /XF *.SGN /R:20 /V /S /Z /J /MT:8 /MON:1 /TEE /UNILOG+:C:\Export1\Robo1.Log
En el siguiente diagrama de bloques, se muestran cuatro servidores Intel R3load en los que se ejecuta R3load. Robocopy empieza a cargar archivos de volcado en segundo plano. Al finalizar las tablas de división y los paquetes completos, el archivo SGN se copia de forma manual o mediante un script. Cuando el archivo SGN de un paquete llega al servidor de importación R3load, desencadena la importación del paquete de forma automática.
Nota:
La copia de archivos mediante NFS o protocolos SMB de Windows no es tan rápida ni tan sólida como otros mecanismos, por ejemplo, AzCopy. Se recomienda probar el rendimiento de ambas técnicas de carga de archivos. Se recomienda notificar a Soporte técnico de Microsoft los proyectos de migración de VLDB, ya que las operaciones de red de rendimiento muy elevado se pueden identificar erróneamente como ataques por denegación de servicio.