Uso de DataBox para migrar desde un almacenamiento conectado a la red (NAS) a los recursos compartidos de archivos de Azure

  • Artículo

Este artículo de migración es uno de varios que implican 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 ⇒ DataBox ⇒ recurso compartido de archivos de Azure
  • 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.

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. En esta guía se usa Azure Data Box para el transporte de datos masivo (transporte de datos sin conexión).

Se aplica a

Tipo de recurso compartido de archivos SMB NFS
Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS Sí No
Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS Sí No
Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS Sí No

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. Deberá implementar cuentas de almacenamiento y recursos compartidos de archivos de Azure y configurar las redes. A continuación, migrará los archivos mediante Azure DataBox y usará RoboCopy para ponerse al día con los cambios. Por último, hará la transición de los usuarios y las 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

En este paso, establecerá cuántos recursos compartidos de archivos de Azure se necesitan. Es posible que tenga más carpetas en los volúmenes que actualmente comparte localmente como recursos compartidos de SMB en sus usuarios y aplicaciones. En función del número de recursos compartidos de archivos que quiera migrar a la nube, puede optar por usar una asignación 1:1 o una agrupación de recursos compartidos.

Uso de una asignación 1:1

Si tiene un número suficientemente pequeño de recursos compartidos, se recomienda una asignación 1:1. La manera más sencilla de visualizar este escenario es imaginar un recurso compartido local que asigne 1:1 a un recurso compartido de archivos de 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, aprovisionará las cuentas de almacenamiento de Azure y los recursos compartidos de archivos que se encuentren en estas.

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, esta disposición hace que la cuenta de almacenamiento sea un destino de escalado para los números de rendimiento, como IOPS y rendimiento. 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 tiene recursos compartidos muy activos (recursos compartidos usados por muchos usuarios o aplicaciones), es conveniente implementar cuentas de almacenamiento con un recurso compartido de archivos cada una. Estas limitaciones no se aplican a las cuentas de almacenamiento de FileStorage (prémium), donde el rendimiento se aprovisiona y garantiza explícitamente para cada recurso compartido.

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 obtener 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.

Los recursos compartidos de archivos de Azure se crean con un límite de 5 TiB de manera predeterminada. Si necesita más capacidad, puede crear un recurso compartido de archivos grande (hasta 100 TiB). Sin embargo, ese recurso compartido solo puede las opciones de redundancia de almacenamiento con redundancia local o de almacenamiento con redundancia de zona. Tenga en cuenta sus necesidades de redundancia de almacenamiento antes de usar recursos compartidos de archivos de 100 TiB.

Si ha creado una lista de recursos compartidos, tiene que asignar cada recurso compartido a la cuenta de almacenamiento en la que se creará.

Los nombres de los recursos también son importantes. Por ejemplo, si agrupa varios recursos compartidos para el Departamento de Recursos Humanos en una cuenta de almacenamiento de Azure, debe asignar el nombre adecuado a la cuenta de almacenamiento. Del mismo modo, al asignar el nombre a los recursos compartidos de archivos de Azure, tiene que usar nombres similares a los que se usan para sus homólogos 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, se recomienda asegurarse de que la región de cada una de las cuentas de almacenamiento es la misma.

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

Inicie este paso solo cuando haya completado la fase anterior. Los recursos de almacenamiento de Azure Storage (cuentas de almacenamiento y recursos compartidos de archivos) se deben crear en este momento. Durante el pedido de DataBox, debe especificar a qué cuentas de almacenamiento se mueven los datos de DataBox.

En esta fase, debe asignar los resultados del plan de migración de la fase anterior a los límites de las opciones de DataBox disponibles. Estas consideraciones le ayudarán a crear un plan para las opciones de DataBox que debe elegir, así como cuántas necesitará para mover los recursos compartidos de NAS a recursos 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 instancia de Azure DataBox puede mover datos a un máximo de 10 cuentas de almacenamiento.
  • Cada opción de DataBox tiene su propia capacidad utilizable. Consulte Opciones de DataBox.

Consulte el plan de migración para conocer el número de cuentas de almacenamiento que ha decidido 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. La combinación de esta información le permitirá optimizar y decidir qué dispositivo debe enviar datos a las cuentas de almacenamiento. Puede tener dos dispositivos de DataBox para trasladar los archivos a la misma cuenta de almacenamiento, pero no divida el contenido de un solo recurso compartido de archivos en dos instancias de DataBox.

Opciones de DataBox

Para una migración estándar, se debe elegir una combinación de estas dos opciones de DataBox:

  • DataBox: esta es la opción más común. Se le enviará un dispositivo DataBox resistente, que funciona de forma similar a un NAS. Tiene una capacidad utilizable de 80 TiB. Para obtener más información, consulte la Documentación de DataBox.
  • DataBox Heavy: esta opción presenta un dispositivo DataBox resistente en 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 obtener más información, consulte la Documentación de DataBox Heavy.

Advertencia

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

Fase 4: Aprovisionamiento de una instancia de Windows Server temporal

Mientras espera a que lleguen los dispositivos Azure Data Box, ya puede implementar una o varias instancias de Windows Server que necesitará para ejecutar trabajos de RoboCopy.

  • Estos servidores se usarán primero para copiar los archivos en el dispositivo Data Box.
  • Después, se usarán para ponerse al día con los cambios que se han producido en el dispositivo NAS mientras el dispositivo Data Box estaba transportándose. Este enfoque reduce al mínimo el tiempo de inactividad en el lado de origen.

La velocidad con la que funcionan los trabajos de RoboCopy depende principalmente de los siguientes factores:

  • El número de IOPS en el almacenamiento de origen y de destino.
  • el ancho de banda de red disponible entre ellos
    Puede encontrar más detalles en la sección de solución de problemas: Consideraciones de IOPS y ancho de banda
  • la capacidad de procesar rápidamente archivos y carpetas en un espacio de nombres
    Busque más detalles en la sección de solución de problemas: Velocidad de procesamiento
  • el número de cambios entre ejecuciones de RoboCopy
    Puede encontrar más detalles en la sección de solución problemas: Evitación de trabajo innecesario

Es importante tener en cuenta los detalles a los que se hace referencia al elegir la RAM y el número de subprocesos que se proporcionarán a las instancias temporales de Windows Server.

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

Para ahorrar tiempo, debe continuar con esta fase mientras espera a que llegue el dispositivo Data Box. Con la información de esta fase, podrá decidir cómo se habilitarán los servidores y los usuarios dentro y fuera de Azure para usar los recursos compartidos de archivos de 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. Unir su cuenta de almacenamiento a un dominio e instancia de AD Connect permitirá que las aplicaciones y los usuarios usen su identidad de AD para la autenticación
  • Autorización: las ACL de nivel de recurso compartido para cada recurso compartido de archivos de Azure permitirán a los usuarios y grupos de AD acceder a un recurso compartido determinado. Además, dentro de un recurso compartido de archivos de Azure, las ACL nativas de NTFS asumirán el control. La autorización basada en ACL de archivos y carpetas funciona del mismo modo que en los recursos compartidos SMB locales.
  • Continuidad empresarial: la integración de recursos compartidos de archivos de Azure en un entorno existente suele implicar la conservación de las direcciones de recursos compartidos existentes. Si aún no está usando los espacios de nombres DFS, considere la posibilidad de configurarlos en su entorno. De este modo, podría conservar sin cambios las direcciones de recursos compartidos que usan los usuarios y los 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: Copia de archivos en el dispositivo Data Box

Cuando llegue el dispositivo DataBox, deberá configurarlo con conectividad de red no impedida a su dispositivo NAS. Siga la documentación de configuración del tipo de DataBox que solicitó.

En función del tipo de DataBox, puede que haya herramientas de copia de DataBox disponibles. En este momento, no se recomiendan para las migraciones a recursos compartidos de archivos de Azure, ya que no copian los archivos con plena fidelidad en el dispositivo DataBox. En su lugar, use RoboCopy.

Cuando llegue el dispositivo DataBox, tendrá recursos compartidos de SMB aprovisionados previamente disponibles para cada cuenta de almacenamiento que especificó en el momento del pedido.

  • Si los archivos entran en un recurso compartido de archivos prémium de Azure, habrá un recurso compartido de SMB por cuenta de almacenamiento de "almacenamiento de archivos" prémium.
  • Si los archivos entran en una cuenta de almacenamiento estándar, habrá tres recursos compartidos de SMB por cuenta de almacenamiento estándar (GPv1 y GPv2). Solo los recursos compartidos de archivos que terminan con _AzFiles son relevantes para la migración. Omita los recursos compartidos de blob en bloques y en páginas.

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

  1. Conexión a un dispositivo Data Box
  2. Copia de datos a un dispositivo Data Box
  3. Preparación del dispositivo DataBox para su salida a Azure

La documentación vinculada de DataBox especifica un comando RoboCopy. Sin embargo, el comando no es adecuado para conservar la fidelidad total de archivos y carpetas. En su lugar, use este comando:

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 ha creado 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

Una vez que el dispositivo Data Box informe de que todos los archivos y carpetas se han colocado en los recursos compartidos de archivos de Azure planeados, puede continuar con esta fase. Un comando RoboCopy de puesta al día solo es necesario si es posible que los datos del NAS hayan cambiado desde que se inició la copia de 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, ejecutará trabajos de RoboCopy para poner al día los recursos compartidos en la nube con los cambios más recientes del NAS desde el momento en que bifurcó los recursos compartidos en el dispositivo DataBox. 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 recurso compartido de archivos de Azure como una unidad de red local en la instancia temporal de Windows Server.
  4. Inicie la copia con RoboCopy como se describió.

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

Antes de que pueda montar correctamente un recurso compartido de archivos de Azure en una instancia local de Windows Server, debe haber completado la fase Preparación para el uso de recursos compartidos de archivos de Azure.

Una vez listo, revise el artículo de procedimientos Uso de un recurso compartido de archivos de Azure con Windows y monte el recurso compartido de archivos de Azure para el que quiere iniciar el comando RoboCopy de puesta al día del NAS.

RoboCopy

El siguiente comando RoboCopy solo copiará las diferencias (archivos y carpetas actualizados) desde el almacenamiento NAS al recurso compartido de archivos 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>
Conmutador 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 prueba n veces antes de determinar que el archivo, definitivamente, no se copia 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 usa Robocopy para Azure Files, asegúrese de montar el recurso compartido de archivos de Azure con 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 aDditorí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 será útil en la nube ni cuando los datos se vuelvan a copiar en otro volumen Windows. Dejar este contenido atrás no debe considerarse una 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

Se recomienda usar Windows Server 2022. Cuando use Windows Server 2019, asegúrese de que está instalado con el nivel de revisión más reciente o, al menos, la actualización KB5005103 del sistema operativo. 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 ejecución inicial, vuelva a ejecutar el comando.

La segunda vez que ejecute RoboCopy para el mismo recurso compartido se completará más rápido, ya que solo necesita transportar los cambios posteriores a 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. Recuperará todos los cambios que puedan haberse omitido. El tiempo necesario para realizar este último paso dependerá 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.

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

Puede intentar ejecutar algunas de estas copias en paralelo. Se recomienda procesar el ámbito de un recurso compartido de archivos de Azure a la vez.

Solución de problemas

La velocidad y la tasa de éxito de una ejecución determinada de RoboCopy dependerán 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 modificador puede ayudar a evitar el acaparamiento de los recursos en dispositivos de E/S restringidos y vínculos 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. Pruebe varios valores, por ejemplo, de 20 milisegundos (n = 20) a múltiplos de ese número. Una vez que introduzca un retraso, podrá valorar si las otras aplicaciones funcionan según lo esperado. Esta estrategia de optimización le permitirá encontrar la velocidad de RoboCopy óptima para su entorno.

Velocidad de procesamiento

RoboCopy recorrerá el espacio de nombres al que se apunta y evaluará cada archivo y carpeta con fines de copia. Los archivos se evaluarán durante una copia inicial y durante las copias de puesta al día. Por ejemplo, ejecuciones repetidas de RoboCopy/MIR en las mismas ubicaciones de almacenamiento de origen y de destino. Estas ejecuciones repetidas son útiles para minimizar el tiempo de inactividad de los usuarios y las aplicaciones, así como para mejorar la tasa de éxito general de los archivos migrados.

A menudo, el ancho de banda suele considerarse como el factor más restrictivo en una migración, algo que 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. Tenga en cuenta que copiar 1 TiB de archivos pequeños tardará mucho más que copiar 1 TiB de un número inferior de archivos de mayor tamaño, si se supone que todas las demás variables permanecen iguales. Por lo tanto, es posible que se experimente una transferencia lenta si va a migrar una gran cantidad de archivos pequeños. Este es un comportamiento esperado.

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.

Un número mayor de subprocesos copiarán nuestro ejemplo de 1 TiB de archivos pequeños considerablemente más rápido que un número menor de subprocesos. Al mismo tiempo, la inversión adicional en recursos en 1 TiB de archivos de más grandes podría no aportar ventajas 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 una primera ejecución de RoboCopy en un destino vacío o una ejecución diferencial con una gran cantidad de archivos modificados, es probable que el rendimiento de la red plantee restricciones. 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, habrá que copiar más datos si cambian las estructuras de carpetas, aunque los archivos se hubieran copiado anteriormente. 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. Con el script de RoboCopy recomendado, se creará y guardará un archivo de registro de los errores. Es normal que puedan producirse errores de copia. Estos errores suelen hacer que sea necesario ejecutar varias rondas de una herramienta de copia como RoboCopy. Una ejecución inicial, por ejemplo, de un dispositivo NAS a DataBox o de un servidor a un recurso compartido de archivos de Azure. Y una o varias ejecuciones adicionales con el modificador /MIR para identificar los archivos que no se han copiado y volver a intentarlo.

Debe estar preparado para ejecutar varias rondas de RoboCopy en el ámbito de un espacio de nombres determinado. Las sucesivas ejecuciones finalizarán más rápido, ya que tienen menos que copiar, pero cada vez tendrán más restricciones debido a 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 generan errores por estar en uso o debido a problemas de tiempo de espera se pueden copiar correctamente de esta manera.

Pasos siguientes

Hay más información sobre los recursos compartidos de archivos de Azure. Los artículos siguientes le ayudarán a comprender las opciones avanzadas, los procedimientos recomendados y también contienen ayuda para la solución de problemas. Estos artículos se vinculan a la documentación de recursos compartidos de archivos de Azure según corresponda.