Utiliza Data Box para migrar de Network Attached Storage (NAS) a compartición de archivos de Azure

✔️ Se aplica a: Recursos compartidos de archivos SMB clásicos creados con el proveedor de recursos Microsoft.Storage

✖️ No se aplica a: Todos los recursos compartidos de archivos NFS, incluidos los recursos compartidos de archivos creados con el proveedor de recursos Microsoft.FileShares o los recursos compartidos de archivos clásicos creados con el proveedor de recursos Microsoft.Storage

Este artículo sobre migración es uno de varios que involucran las palabras clave NAS y Azure Data Box. Compruebe si este artículo se aplica a su escenario:

  • Origen de datos: almacenamiento conectado a la red (NAS)
  • Ruta de migración: NAS ⇒ Data Box ⇒ Azure archivo compartido
  • Sin almacenamiento en caché de archivos en el entorno local: dado que el objetivo final es usar los recursos compartidos de archivos de Azure directamente en la nube, no hay ningún plan para usar Azure File Sync.

Si el escenario es diferente, examine la tabla de guías de migración.

Nota:

Data Box soporta NFS como protocolo de copia, así que puedes usarlo para copiar datos de un NAS que sirve a NFS. Sin embargo, Data Box no admite importar datos directamente en los archivos compartidos de NFS Azure. Esta guía cubre únicamente los objetivos de compartición de archivos SMB.

Este artículo le guía de forma detallada por el planeamiento, implementación y configuración de las redes necesarias para migrar del dispositivo NAS a recursos compartidos de archivos de Azure funcionales. Esta guía utiliza Azure Data Box para el transporte masivo de datos (transporte de datos offline).

Objetivos de la migración

El objetivo es migrar los recursos compartidos del dispositivo NAS a Azure y convertirlos en recursos compartidos de archivos de Azure nativos. Puede usar estos recursos compartidos sin necesidad de una instancia de Windows Server. Esta migración se debe realizar de forma que garantice la integridad de los datos de producción y la disponibilidad durante la migración. Esta última requiere que el tiempo de inactividad sea mínimo, para ajustarse o solo superar ligeramente las ventanas de mantenimiento regulares.

Información general sobre la migración

El proceso de migración consta de varias fases. Primero, desplega cuentas de almacenamiento de Azure y comparte archivos y configura la red. Luego, migra tus archivos usando Azure Data Box y RoboCopy para ponerte al día con los cambios. Por último, migra tus usuarios y aplicaciones a los recursos compartidos de archivos de Azure recién creados. En las secciones siguientes se describen detalladamente las fases del proceso de migración.

Sugerencia

Si vuelve a este artículo, use la navegación del lado derecho para ir a la fase de migración en la que se quedó.

Fase 1: Identificación de cuántos recursos compartidos de archivos de Azure se necesitan

Determina cuántos archivos compartidos de Azure necesitas. Es posible que tenga más carpetas en los volúmenes que actualmente comparte localmente como recursos compartidos SMB para los usuarios y las aplicaciones. Dependiendo del número de recursos compartidos de archivos que quieras migrar a la nube, elige una asignación uno a uno o una agrupación de recursos compartidos.

Uso de una asignación 1:1

Si tienes un pequeño número de comparticiones, utiliza un mapeo uno a uno. La forma más sencilla de visualizar este escenario es imaginar un recurso compartido local que se corresponde de forma unívoca con un recurso compartido de archivos en Azure.

Uso de la agrupación de recursos compartidos

Si tiene una cantidad elevada de recursos compartidos de archivos, plantéese la posibilidad de agrupar recursos compartidos. Por ejemplo, si el departamento de RR. HH. tiene 15 recursos compartidos, podría considerar la posibilidad de almacenar todos los datos de RR. HH. en un solo recurso compartido de archivos de Azure. De este modo, solo se necesita un único recurso compartido de archivos de Azure en la nube para este grupo de recursos compartidos locales.

Fase 2: Implementación de recursos de almacenamiento de Azure

En esta fase, provisiona las cuentas de almacenamiento de Azure y los archivos compartidos dentro de ellas.

Recuerde que un recurso compartido de archivos de Azure se implementa en la nube en una cuenta de almacenamiento de Azure. En el caso de los recursos compartidos de archivos HDD (estándar), esa disposición convierte la cuenta de almacenamiento en un objetivo de escalado para parámetros de rendimiento como IOPS y ancho de banda. Si coloca varios recursos compartidos de archivos en una única cuenta de almacenamiento, está creando un grupo compartido de IOPS y rendimiento para esos recursos compartidos.

Como regla general, puede agrupar varios recursos compartidos de archivos de Azure en la misma cuenta de almacenamiento si tiene recursos compartidos de archivo o que espera que tengan escasa actividad diaria. Sin embargo, si tienes recursos compartidos de archivos muy activos (recursos compartidos usados por muchos usuarios y aplicaciones), implementa cuentas de almacenamiento con un único recurso compartido de archivos cada una. Estas limitaciones no se aplican a las cuentas de almacenamiento FileStorage (SSD), donde el rendimiento se aprovisiona y garantiza explícitamente para cada compartición.

Nota:

Hay un límite de 250 cuentas de almacenamiento por suscripción por cada región de Azure. Con un aumento de cuota, podría crear hasta 500 cuentas de almacenamiento por región. Para más información, consulte Aumento de las cuotas de la cuenta de Azure Storage.

Otra consideración a la hora de implementar una cuenta de almacenamiento es la redundancia. Consulte Redundancia de Azure Files.

Si haces una lista de tus recursos compartidos, asigna cada recurso compartido a la cuenta de almacenamiento en la que lo crees.

Los nombres de los recursos también son importantes. Por ejemplo, si agrupas varias comparticiones del departamento de RRHH en una cuenta de almacenamiento de Azure, nombra la cuenta de almacenamiento adecuadamente. De manera similar, cuando nombres los recursos compartidos de archivos de Azure, usa nombres similares a los que se usan en sus equivalentes locales.

Ahora, implemente el número adecuado de cuentas de almacenamiento de Azure con el número adecuado de recursos compartidos de archivos de Azure en estas. Para ello, siga las instrucciones de Creación de un recurso compartido de archivos SMB. En la mayoría de los casos, asegúrate de que la región de cada una de tus cuentas de almacenamiento sea la misma.

Fase 3: Determinación del número de dispositivos de Azure Data Box que necesita

Empieza este paso solo cuando completes la fase anterior. En este punto, deberías haber creado tus recursos de almacenamiento en Azure, incluyendo cuentas de almacenamiento y compartidos de archivos. Durante tu pedido de Data Box, necesitas especificar a qué cuentas de almacenamiento traslada los datos.

En esta fase, mapea los resultados del plan de migración de la fase anterior hasta los límites de las opciones disponibles de Data Box. Estas consideraciones te ayudan a planificar qué opciones de Data Box elegir y cuántas necesitas para mover tus compartidos NAS a los compartidos de archivos de Azure.

Para determinar el número de dispositivos que necesita de cada tipo, tenga en cuenta estos límites importantes:

  • Cualquier Azure Data Box puede mover datos a hasta 10 cuentas de almacenamiento.
  • Cada opción de Data Box tiene su propia capacidad utilizable. Consulte opciones de Data Box.

Consulta tu plan de migración para conocer cuántas cuentas de almacenamiento decidiste crear y los recursos compartidos en cada una de ellas. A continuación, examine el tamaño de cada uno de los recursos compartidos de NAS. Combinar esta información te permite decidir qué dispositivo debe enviar datos a qué cuentas de almacenamiento. Puedes hacer que dos dispositivos Data Box muevan archivos a la misma cuenta de almacenamiento, pero no dividas el contenido de un único recurso compartido entre dos dispositivos Data Box.

Opciones de Data Box

Para una migración estándar, elige una o una combinación de estas dos opciones de Data Box:

  • Data Box Esta opción es la más común. Es un dispositivo de caja de datos robusto que funciona de forma similar a un NAS. Se entrega con una capacidad útil de 80 TiB. Para más información, consulte la documentación de Data Box.
  • Caja de datos pesada Esta opción cuenta con un aparato robusto de caja de datos sobre ruedas que funciona de forma similar a un NAS, con una capacidad de 1 PiB. La capacidad utilizable es aproximadamente un 20 % menos debido a la sobrecarga del sistema de archivos y el cifrado. Para más información, consulte la documentación de Data Box Heavy.

Advertencia

Data Box Disks no se recomienda para las migraciones a recursos compartidos de archivos de Azure. Data Box Disks no conserva los metadatos de archivo, como permisos de acceso (ACL) y otros atributos.

Fase 4: Aprovisionamiento de una instancia de Windows Server temporal

Mientras esperas a que lleguen tus appliances Azure Data Box, ya puedes desplegar uno o más servidores de Windows que necesitas para ejecutar trabajos de RoboCopy. Para los requisitos de la versión del sistema operativo, consulta la nota importante en la sección RoboCopy.

  • Utiliza estos servidores para copiar archivos en la caja de datos.
  • Utiliza estos servidores para ponerte al día con los cambios que ocurren en el dispositivo NAS mientras la Caja de Datos está en traslado. Este enfoque reduce al mínimo el tiempo de inactividad en el lado de origen.

La velocidad a la que funcionan tus trabajos de RoboCopy depende principalmente de estos factores:

Ten en cuenta los detalles referenciados al decidir la RAM y el número de hilos que proporcionas a tu(s) Windows Server(s) temporal(es).

Fase 5: Preparación para el uso de recursos compartidos de archivos de Azure

Para ahorrar tiempo, continúa con esta fase mientras esperas a que llegue tu Data Box. Con la información de esta fase, puedes decidir cómo tus servidores y usuarios pueden usar tus compartidos de archivos en Azure. Las decisiones más críticas son las siguientes:

  • Redes: habilite las redes para enrutar el tráfico SMB.
  • Autenticación: configure cuentas de almacenamiento de Azure para la autenticación Kerberos. Microsoft Entra Connect y la unión de dominio a tu cuenta de almacenamiento permiten que tus aplicaciones y usuarios usen su identidad AD para autenticación.
  • Autorización: Las ACLs a nivel de recurso para cada recurso compartido de archivos de Azure permiten a los usuarios y grupos de AD acceder a un determinado tipo de share, y dentro de un recurso compartido de archivos de Azure, las ACLs nativas NTFS toman el control. La autorización basada en ACL de archivos y carpetas funciona del mismo modo que en los recursos compartidos SMB locales.
  • Continuidad del negocio: La integración de los recursos compartidos de archivos de Azure en un entorno existente suele implicar preservar las direcciones de los mismos recursos. Si aún no usa espacios de nombres DFS, considere la posibilidad de implementarlos en su entorno. Puedes mantener sin cambios las direcciones de compartir que usan tus usuarios y scripts. DFS-N se usaría como servicio de enrutamiento de espacios de nombres para SMB, ya que redirigiría los destinos de espacio de nombres DFS a recursos compartidos de archivos de Azure después de la migración.

Este vídeo es una guía y demostración sobre cómo exponer de forma segura recursos compartidos de archivos de Azure directamente para las aplicaciones y trabajadores de la información en cinco sencillos pasos.
La documentación dedicada del vídeo hace referencia a la documentación dedicada para los temas siguientes. Tenga en cuenta que Azure Active Directory es ahora Microsoft Entra ID. Para obtener más información, consulte Nuevo nombre para Azure AD.

Fase 6: Copiar archivos en tu Data Box

Cuando llegue tu Data Box, configura tu Data Box con conectividad de red sin obstáculos a tu dispositivo NAS. Sigue la documentación de configuración del tipo de Data Box que has pedido.

Dependiendo del tipo de Data Box, podrías tener acceso a las herramientas de copia de Data Box. En este punto, no los utilices para migraciones a compartidos de archivos de Azure porque no copian tus archivos con fidelidad total al Data Box. En su lugar, use RoboCopy.

Cuando reciba su Data Box, tendrá disponibles recursos compartidos SMB preconfigurados para cada cuenta de almacenamiento que haya especificado al realizar el pedido.

  • Si los archivos se colocan en un recurso compartido de archivos de Azure en un SSD, habrá un recurso compartido SMB por cada cuenta de almacenamiento "File storage" de SSD.
  • Si los archivos se colocan en una cuenta de almacenamiento HDD, habrá tres recursos compartidos SMB por cada cuenta de almacenamiento HDD de pago por uso. Solo el archivo compartido que termina con _AzFile es relevante para tu migración. Omita los recursos compartidos de blob en bloques y en páginas.

Cómo Data Box asigna carpetas a recursos compartidos de archivos de Azure

Bajo el <storage-account-name>_AzFile recurso compartido de dispositivos, cada carpeta de primer nivel se asigna a un recurso compartido de archivos de Azure en la cuenta de almacenamiento destino:

  • El nombre de la carpeta de primer nivel se convierte en el nombre de la compartición de archivos de Azure durante la ingestión. Si un recurso compartido con ese nombre no existe ya en la cuenta de almacenamiento de destino, Data Box lo crea. Si dicho recurso compartido existe, Data Box copia los datos en ese recurso compartido ya existente.

  • No copies los archivos directamente a la raíz del _AzFile compartido. Todos los datos deben ir dentro de una carpeta de primer nivel.

  • Para una asignación uno a uno con tus recursos compartidos SMB de origen, crea una carpeta de primer nivel para cada recurso compartido de origen (usando el nombre deseado del recurso compartido de archivos de Azure) y copia cada recurso compartido de origen en la carpeta correspondiente. Por ejemplo:

    \\<DataBox-IP>\<storage-account-name>_AzFile\Share1
\\<DataBox-IP>\<storage-account-name>_AzFile\Share2
\\<DataBox-IP>\<storage-account-name>_AzFile\Share3

Para más información, véase Conectar a la caja de datos.

Siga los pasos descritos en la documentación de Azure Data Box:

  1. Conexión a un dispositivo Data Box
  2. Copia de datos a un dispositivo Data Box
  3. Revisa el archivo de registro de RoboCopy para detectar errores y confirmar que todos los archivos se han copiado correctamente.
  4. Prepara tu Data Box para la salida hacia Azure

La documentación enlazada de Data Box especifica un comando RoboCopy. Sin embargo, el comando no es adecuado para preservar toda la fidelidad de archivos y carpetas. Este comando se usa /MT:32 porque es una copia local en LAN a la Data Box con latencia insignificante, por lo que un mayor número de hilos es apropiado aquí que para la copia de recuperación basada en WAN en la Fase 7:

Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path>
  • Para obtener más información acerca de los detalles de cada marca de RoboCopy, consulte la tabla en sección de RoboCopy más adelante.
  • Para obtener más información acerca de cómo ajustar correctamente el número de subprocesos /MT:n, optimizar la velocidad de RoboCopy y hacer que RoboCopy funcione adecuadamente en el centro de datos, eche un vistazo a la sección de solución de problemas de RoboCopy.

Sugerencia

Como alternativa a RoboCopy, Data Box ofrece un servicio de copia de datos. Puede usar este servicio para cargar archivos en Data Box con plena fidelidad. Siga este tutorial sobre el servicio de copia de datos y asegúrese de establecer el destino correcto del recurso compartido de archivos de Azure.

Fase 7: Puesta al día de RoboCopy a partir del NAS

Después de que Data Box indique que ha colocado todos los archivos y carpetas en los recursos compartidos de archivos de Azure previstos, continúe con esta fase. Solo necesitas un RoboCopy de sincronización si es posible que los datos del NAS hayan cambiado desde que se inició la copia con Data Box. En algunos escenarios en los que se usa un recurso compartido con fines de archivado, es posible que pueda detener los cambios en el recurso compartido del NAS hasta que se complete la migración. También podría cumplir los requisitos de su empresa al configurar recursos compartidos de NAS en modo solo lectura durante la migración.

En los casos en los que necesita que un recurso compartido sea de lectura y escritura durante la migración y solo pueda permitirse un pequeño período de inactividad, será importante que complete este paso de RoboCopy de puesta al día antes de la conmutación por error del acceso del usuario directamente al recurso compartido de archivos de Azure.

En este paso, ejecuta trabajos de Robocopy para actualizar tus recursos compartidos en la nube con los cambios más recientes de tu NAS desde que copiaste tus recursos compartidos a Data Box. Esta puesta al día de RoboCopy puede finalizar rápidamente o tardar unos minutos en función de la cantidad de abandonos que haya ocurrido en los recursos compartidos de NAS.

Ejecute la primera copia local en la carpeta de destino de Windows Server:

  1. Identifique la primera ubicación en el dispositivo NAS.
  2. Identifique el recurso compartido de archivos de Azure correspondiente.
  3. Monte el archivo compartido de Azure como una unidad de red local en su Windows Server temporal.
  4. Inicie la copia con RoboCopy como se describe.

Montaje de un recurso compartido de archivos de Azure

Antes de que pueda usar RoboCopy, debe hacer que el recurso compartido de archivos de Azure sea accesible a través de SMB. La manera más fácil consiste en montar el recurso compartido como una unidad de red local en la instancia de Windows Server que está planeando usar para RoboCopy.

Importante

Para poder montar correctamente un recurso compartido de archivos de Azure en una instancia local de Windows Server, debe completar la fase 5: Preparación para usar recursos compartidos de archivos de Azure.

Cuando estés listo, consulta el artículo con instrucciones sobre cómo usar un recurso compartido de archivos de Azure con Windows y monta el recurso compartido de archivos de Azure para el que quieres iniciar RoboCopy para la puesta al día del NAS.

RoboCopy

El siguiente comando RoboCopy copia solo las diferencias (archivos y carpetas actualizados) de tu almacenamiento NAS a tu archivo compartido de Azure.

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Switch Significado
/MT:n Permite que Robocopy se ejecute en modo multiproceso. El valor predeterminado para n es 8. La cantidad máxima es de 128 subprocesos. Aunque un número elevado de subprocesos contribuye a saturar el ancho de banda disponible, no significa que la migración sea siempre más rápida con más subprocesos. Las pruebas realizadas con Azure Files indican que entre 8 y 20 proporcionan un rendimiento equilibrado para la ejecución de una copia inicial. Las ejecuciones subsiguientes de /MIR se ven afectadas progresivamente por el proceso disponible en comparación con el ancho de banda de red disponible. Para las ejecuciones posteriores, haga coincidir más estrechamente el valor del número de subprocesos con el número de núcleos del procesador y el número de subprocesos por núcleo. Considere si es necesario reservar los núcleos para otras tareas que quizá tenga un servidor de producción. Las pruebas realizadas con Azure Files han demostrado que, con un máximo de 64 subprocesos, se obtiene un buen rendimiento, pero solo si los procesadores pueden mantenerlos activos al mismo tiempo.
/R:n Número máximo de reintentos para un archivo que no se puede copiar en el primer intento. Robocopy lo intentará n varias veces antes de que el archivo deje de copiarse definitivamente en la ejecución. Para optimizar el rendimiento de la ejecución, elija un valor de dos o tres si cree que hubo problemas de tiempo de espera que causaron errores en el pasado. Esto puede ser más habitual a través de vínculos WAN. Elija no reintentarlo o un valor de uno si cree que el archivo no se pudo copiar porque estaba en uso de forma activa. Volver a intentarlo unos segundos más tarde puede no ser suficiente tiempo para que cambie el estado de “en uso” del archivo. Es posible que los usuarios o aplicaciones que tienen abierto el archivo necesiten más tiempo. En este caso, puede que, si acepta que el archivo no se ha copiado y lo incluye en una ejecución posterior planeada de Robocopy, el archivo se copie finalmente. Esto ayuda a que la ejecución en curso finalice más rápido al no prolongarla con muchos reintentos que, al final, dan lugar a una mayoría de errores de copia porque los archivos siguen abiertos después del tiempo de espera de reintento.
/W:n Especifica el tiempo que espera Robocopy antes de intentar copiar un archivo que no se ha copiado correctamente en el último intento. n es el número de segundos de espera entre reintentos. /W:n a menudo se usa junto con /R:n.
/B Ejecuta Robocopy en el mismo modo que usaría una aplicación de copia de seguridad. Este conmutador permite que Robocopy mueva los archivos para los que el usuario actual no tiene permisos. El modificador de la copia de seguridad depende de la ejecución del comando Robocopy en una consola con privilegios elevados de administrador o en una ventana de PowerShell. Si usas Robocopy para Azure Files, asegúrate de montar el recurso compartido de archivos de Azure usando la clave de acceso de la cuenta de almacenamiento en lugar de una identidad de dominio. Si no lo hace, es posible que los mensajes de error no lo lleven intuitivamente a una solución del problema.
/MIR (Reflejar origen en destino). Permite que Robocopy solo tenga que copiar las diferencias entre el origen y el destino. Se copiarán los subdirectorios vacíos. Se copiarán los elementos (archivos o carpetas) que hayan cambiado o no existan en el destino. Los elementos que existan en el destino, pero no en el origen, se purgarán (se eliminarán) del destino. Cuando use este conmutador, haga coincidir exactamente con las estructuras de carpetas de origen y de destino. Coincidencia significa que se copia desde el nivel de carpeta y origen correctos en el nivel de carpeta del destino coincidente. Solo entonces se puede realizar correctamente una copia de "puesta al día". Cuando el origen y el destino no coinciden, el uso de /MIR dará lugar a eliminaciones y nuevas copias a gran escala.
/IT Garantiza que se conserve la fidelidad en ciertos escenarios de reflejo.
Por ejemplo, si un archivo experimenta un cambio de ACL y una actualización de atributo entre dos ejecuciones de Robocopy, se marca como oculto. Sin /IT, Robocopy podría omitir el cambio de ACL y no se transferiría a la ubicación de destino.
/COPY:[copyflags] Fidelidad de la copia del archivo. Predeterminado: /COPY:DAT. Marcas de copia: D = datos, A = atributos, T = marcas de tiempo, S = seguridad = ACL de NTFS, O = información del propietario, U = información de auditoría. No se puede almacenar la información de auditoría en un recurso compartido de archivos de Azure.
/DCOPY:[copyflags] Fidelidad de la copia de directorios. Predeterminado: /DCOPY:DA. Marcas de copia: D = Datos, A = Atributos, T = Marcas de tiempo.
/NP Especifica que no se mostrará el progreso de la copia de cada archivo y carpeta. Mostrar el progreso reduce significativamente el rendimiento de la copia.
/NFL Especifica que los nombres de archivo no se han registrado. Mejora el rendimiento de la copia.
/NDL Especifica que los nombres de directorio no se han registrado. Mejora el rendimiento de la copia.
/XD Especifica los directorios que se excluirán. Cuando ejecute Robocopy en la raíz de un volumen, considere la posibilidad de excluir la carpeta System Volume Information oculta. Si se usa como está previsto, toda la información que contiene es específica del volumen exacto en este sistema exacto y se puede recompilar a petición. Copiar esta información no es útil en la nube ni cuando los datos se copian de nuevo a otro volumen de Windows. Dejar este contenido atrás no es pérdida de datos.
/UNILOG:<file name> Escribe el estado en el archivo de registro como Unicode. (Sobrescribe el registro existente).
/L Solo para una serie de pruebas
Los archivos solo se muestran en la lista. No se copiarán, no se eliminarán y no tendrán marca de tiempo. Por lo general, se usa con /TEE para la salida de la consola. Es posible que las marcas del script de ejemplo, como /NP, /NFL y /NDL, se tengan que quitar para lograr los resultados de la prueba documentados correctamente.
/Z Usar con precaución
Copia los archivos en modo de reinicio. Este conmutador solo se recomienda en un entorno de red inestable. Reduce significativamente el rendimiento de la copia debido al registro adicional.
/ZB Usar con precaución
Usa el modo de reinicio. Si se deniega el acceso, esta opción utiliza el modo de copia de seguridad. Esta opción reduce significativamente el rendimiento de la copia debido a los puntos de control.

Importante

Si es posible, utiliza Windows Server 2022 o versiones posteriores. Al usar Windows Server 2019, asegúrate de que el último nivel de parche o al menos el KB5005103 de actualización del sistema operativo esté instalado. Contiene correcciones importantes para determinados escenarios de Robocopy.

Sugerencia

Consulte la sección de solución de problemas si RoboCopy está afectando a su entorno de producción, si notifica un gran número de errores o si no progresa tan rápido como se espera.

Migración total de los usuarios

Al ejecutar por primera vez el comando RoboCopy, los usuarios y las aplicaciones siguen accediendo a los archivos en la ubicación de NAS y pueden modificarlos. Es posible que RoboCopy haya procesado un directorio, pase al siguiente y, después, un usuario en la ubicación de origen (NAS) agregue, cambie o elimine un archivo que no se procesará en esta ejecución actual de RoboCopy. Este comportamiento es normal.

La primera ejecución consiste en migrar la mayor parte de los datos renovados al recurso compartido de archivos de Azure. Esta primera copia puede tardar unos minutos. Consulte la sección de solución de problemas para obtener más información acerca de lo que puede afectar a la velocidad de RoboCopy.

Una vez completada la primera partida, ejecuta el comando de nuevo.

La segunda vez que ejecutas RoboCopy para el mismo recurso compartido, termina más rápido, porque solo necesita transferir los cambios que se produjeron desde la última ejecución. Puede ejecutar trabajos repetidos para el mismo recurso compartido.

Si considera que el tiempo de inactividad es aceptable, debe quitar el acceso de usuario a los recursos compartidos basados en NAS. Para ello, siga los pasos que impidan que los usuarios cambien el contenido y la estructura de archivos y carpetas. Un ejemplo es dirigir DFS-Namespace a una ubicación no existente o cambiar las ACL raíz del recurso compartido.

Ejecute una última ronda de RoboCopy. Detecta cualquier cambio que se haya pasado por alto. El tiempo necesario para hacer este último paso depende de la velocidad del análisis de RoboCopy. Para realizar un cálculo estimado del tiempo (que equivale al tiempo de inactividad) averigüe cuánto tardó en realizarse la ejecución anterior.

Cree un recurso compartido en la carpeta de Windows Server y, eventualmente, ajuste esta carpeta como destino de la implementación de DFS-N. Asegúrese de establecer los mismos permisos de nivel de recurso compartido que en el recurso compartido de SMB de NAS. Si tuviera un NAS unido a un dominio de clase empresarial, los SID de usuario coincidirían automáticamente a medida que los usuarios se encuentren en Active Directory y RoboCopy copia los archivos y metadatos con total fidelidad. Si ha utilizado usuarios locales en la ubicación de NAS, debe volver a crearlos como usuarios locales de Windows Server y asignar los SID existentes que RoboCopy ha transferido a la instancia de Windows Server a los SID de los nuevos usuarios locales de Windows Server.

Has terminado de migrar un recurso compartido o un grupo de recursos compartidos a una raíz o volumen comunes.

Puede intentar ejecutar algunas de estas copias en paralelo. Procesa el alcance de un recurso compartido de archivos de Azure a la vez.

Solución de problemas

La velocidad y la tasa de éxito de una partida con RoboCopy dependen de varios factores:

  • El número de IOPS en el almacenamiento de origen y de destino.
  • El ancho de banda de red disponible entre el origen y el destino.
  • La capacidad de procesar rápidamente archivos y carpetas en un espacio de nombres.
  • el número de cambios entre ejecuciones de RoboCopy
  • el tamaño y el número de archivos que debe copiar

Consideraciones sobre el ancho de banda y el número de IOPS.

En esta categoría, debe tener en cuenta la capacidad del almacenamiento de origen, el almacenamiento de destinoy la red que los conecta. El mayor rendimiento posible viene determinado por el más lento de estos tres componentes. Asegúrese de que la infraestructura de red se haya configurado para admitir las mejores velocidades de transferencia.

Precaución

Aunque es deseable copiar lo más rápido posible, tenga en cuenta el uso de la red local y el dispositivo NAS en otras tareas que suelen ser críticas para la empresa.

Copiar lo más rápido posible podría no ser deseable si existe el riesgo de que la migración acapare los recursos disponibles.

  • Tenga en cuenta cuándo es mejor para su entorno hacer migraciones: durante el día, fuera del horario laboral o en los fines de semana.
  • Considere también la calidad de servicio de redes en Windows Server para limitar la velocidad de RoboCopy.
  • Evite trabajo innecesario a las herramientas de migración.

RoboCopy puede introducir retrasos entre paquetes al especificar el modificador /IPG:n, en donde el valor n se calcula en milisegundos entre los paquetes de RoboCopy. El uso de este interruptor puede ayudar a evitar la monopolización de recursos tanto en dispositivos restringidos de E/S como en enlaces de red saturados.

/IPG:n no se puede usar para limitar la red a un número exacto de megabits por segundo. En su lugar, use la calidad de servicio de red de Windows Server. RoboCopy se basa íntegramente en el protocolo SMB para todas las necesidades de red. El uso de SMB es el motivo por el que RoboCopy no puede influir en el propio rendimiento de la red, pero puede ralentizar su uso.

Un enfoque similar se aplica a las operaciones de IOPS observadas en el dispositivo NAS. El tamaño del clúster en el volumen de NAS y los tamaños de paquete, entre otros factores, influyen en las IOPS observadas. La introducción de retraso entre paquetes suele ser la manera más fácil de controlar la carga en el dispositivo NAS. Prueba múltiples valores, como desde unos 20 milisegundos (n=20) hasta múltiplos de ese número. Después de introducir un retraso, puedes evaluar si tus otras aplicaciones pueden funcionar como esperas. Esta estrategia de optimización te ayuda a encontrar la velocidad óptima de RoboCopy en tu entorno.

Velocidad de procesamiento

RoboCopy recorre el espacio de nombres que especifícas y evalúa cada archivo y carpeta para copiarlos. Evalúa cada archivo durante una copia inicial y durante las copias de recuperación. Por ejemplo, ejecuciones repetidas de RoboCopy /MIR en las mismas ubicaciones de almacenamiento de origen y destino. Estas ejecuciones repetidas minimizan el tiempo de inactividad para usuarios y aplicaciones, y mejoran la tasa de éxito general de los archivos migrados.

El ancho de banda suele considerarse el factor más limitante en una migración, y eso puede ser cierto. Pero la posibilidad de enumerar un espacio de nombres puede influir en el tiempo total de copia para espacios de nombres más largos con archivos más pequeños. Considera que copiar 1 TiB de archivos pequeños lleva considerablemente más tiempo que copiar 1 TiB de archivos menos pero más grandes, suponiendo que todas las demás variables permanezcan igual. Por lo tanto, puede experimentar una transferencia lenta si va a migrar un gran número de archivos pequeños. Se espera esta diferencia.

La razón de esta diferencia es la potencia de procesamiento necesaria para recorrer un espacio de nombres. RoboCopy admite copias multiproceso mediante el parámetro /MT:n, donde n indica el número de subprocesos que se van a usar. Por lo tanto, al aprovisionar una máquina específicamente para RoboCopy, tenga en cuenta el número de núcleos de procesador y su relación con el número de subprocesos que proporcionan. Lo más habitual son dos subprocesos por núcleo. El número de núcleos y subprocesos de una máquina es un punto de datos importante para determinar qué valores multiproceso /MT:n se deberían especificar. Tenga en cuenta también cuántos trabajos de RoboCopy tiene previsto ejecutar al mismo tiempo en una máquina determinada.

Más hilos copian el ejemplo de 1 TiB de archivos pequeños considerablemente más rápido que menos hilos. Al mismo tiempo, la inversión extra de recursos en 1 TiB de archivos más grandes podría no aportar beneficios proporcionales. Un número mayor de subprocesos intentará copiar simultáneamente más archivos grandes a través de la red. Esta actividad de red adicional aumentará la probabilidad de sufrir restricciones asociadas al rendimiento o a las operaciones de IOPS de almacenamiento.

Durante un primer RoboCopy en un destino vacío o una ejecución diferencial con una gran cantidad de archivos modificados, es probable que esté restringido por el rendimiento de la red. Comience con un número elevado de subprocesos para una ejecución inicial. Un alto número de subprocesos, incluso más allá de los subprocesos disponibles actualmente en la máquina, ayuda a saturar el ancho de banda de red disponible. Las ejecuciones /MIR posteriores se verán afectadas progresivamente por el procesamiento de elementos. Menos cambios en una ejecución diferencial significa menos transporte de datos a través de la red. La velocidad ahora depende más de la capacidad de procesar elementos de espacio de nombres que de moverlos a través del vínculo de red. Para las ejecuciones posteriores, haga coincidir el valor del número de subprocesos con el número de núcleos del procesador y el número de subprocesos por núcleo. Considere si es necesario reservar los núcleos para otras tareas que quizá tenga un servidor de producción.

Sugerencia

Regla general: la primera ejecución de RoboCopy, que moverá una gran cantidad de datos de una red de mayor latencia, se beneficia del aprovisionamiento excesivo del número de subprocesos (/MT:n). Las ejecuciones posteriores copiarán menos diferencias y es más probable que se cambie de un rendimiento restringido de red a otro restringido por proceso. En estas circunstancias, a menudo es mejor que el número de subprocesos de RoboCopy coincida con los subprocesos disponibles realmente en la máquina. El aprovisionamiento excesivo en ese escenario puede generar más cambios de contexto en el procesador, lo que podría ralentizar la copia.

Evitar el trabajo innecesario

Evite cambios a gran escala en el espacio de nombres. Por ejemplo, mover archivos entre directorios, cambiar propiedades a gran escala o cambiar permisos (ACL de NTFS). Los cambios en la ACL en especial pueden tener una importante repercusión, ya que con frecuencia tienen un efecto de cambio en cascada en los archivos de nivel inferior en la jerarquía de carpetas. Entre las consecuencias, cabe destacar las siguientes:

  • La ampliación del tiempo de ejecución del trabajo de RoboCopy, ya que será necesario actualizar cada archivo y carpeta a los que afecte un cambio de ACL.
  • Es posible que haya que volver a copiar los datos que se migraron anteriormente. Por ejemplo, es necesario copiar más datos cuando las estructuras de carpetas cambian después de que los archivos ya se hayan copiado. Un trabajo de RoboCopy no puede "reproducir" un cambio del espacio de nombres. El siguiente trabajo debe purgar los archivos transportados previamente en la estructura de carpetas antigua y volver a cargar los archivos en la nueva estructura de carpetas.

Otro aspecto importante es usar la herramienta RoboCopy de forma eficaz. Al usar el script recomendado de RoboCopy, creas y guardas un archivo de registro para detectar errores. Se pueden producir errores de copia y es normal. Estos errores suelen hacer que sea necesario ejecutar varias rondas de una herramienta de copia como RoboCopy. Por ejemplo, una ejecución inicial, digamos de un NAS a Data Box o de un servidor a un recurso compartido de archivos de Azure, y una o más ejecuciones extra con el /MIR switch para capturar y volver a intentar archivos que no se copiaron.

Debe estar preparado para ejecutar varias rondas de RoboCopy en el ámbito de un espacio de nombres determinado. Las ejecuciones sucesivas terminan más rápido porque hay menos datos que copiar, pero dependen cada vez más de la velocidad de procesamiento del espacio de nombres. Cuando ejecute varias rondas, puede acelerar cada una de ellas si evita que RoboCopy intente copiarlo todo en una misma ejecución. Los siguientes modificadores RoboCopy pueden marcar una diferencia importante:

  • /R:n n = la frecuencia con la que se vuelve a intentar copiar un archivo con errores
  • /W:n n = el número de segundos que hay que esperar entre reintentos

/R:5 /W:5 es un valor razonable que puede ajustar a su gusto. En este ejemplo, un archivo con errores se intentará volver a copiar cinco veces, con un tiempo de espera de cinco segundos entre un reintento y otro. Si el archivo sigue sin copiarse, el siguiente trabajo de RoboCopy lo volverá a intentar. A menudo, los archivos que no se pueden copiar porque están en uso o debido a problemas de tiempo de espera, finalmente se pueden copiar con éxito de esta forma.

Consulte también

  • Last updated on