Migración desde un almacenamiento conectado a la red (NAS) a una implementación de nube híbrida con Azure File Sync

  • Artículo

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

  • Origen de datos: almacenamiento conectado a la red (NAS)
  • Ruta de migración: NAS ⇒ Windows Server ⇒ Carga y sincronización con recursos compartidos de archivos de Azure
  • Almacenamiento en caché de archivos locales: sí, el objetivo final es una implementación de Azure File Sync.

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

Azure File Sync funciona en ubicaciones de almacenamiento de conexión directa (DAS) y no admite la sincronización con ubicaciones de almacenamiento conectado a la red (NAS). Es por esto que resulta necesario migrar los archivos y en este artículo encontrará una guía para planear y ejecutar dicha migración.

Se aplica a

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

Objetivos de la migración

La idea es mover los recursos compartidos SMB del dispositivo NAS a Windows Server y, a continuación, usar Azure File Sync para una implementación en la nube híbrida. En general, las migraciones se deben realizar de forma que garanticen la integridad de los datos de producción, así como su 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

Como se mencionó en Migrar a recursos compartidos de archivos de Azure SMB, es importante usar la herramienta de copia y el enfoque correctos. El dispositivo NAS expone los recursos compartidos de SMB directamente en la red local. Puede usar Azure Storage Mover o RoboCopy para mover los archivos.

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. Una sola instancia de Windows Server (o clúster) puede sincronizar hasta 30 recursos compartidos de archivos de Azure.

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. 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. Si tiene un número suficientemente pequeño de recursos compartidos, por debajo de 30 para una sola instancia de Windows Server, se recomienda una asignación 1:1.

Si tiene más de 30 recursos compartidos, a menudo no es necesaria la asignación 1:1 de recursos compartidos locales a un recurso compartido de archivos de Azure. Considere las opciones siguientes.

Agrupación de 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. El almacenamiento de varios recursos compartidos locales en un recurso compartido de archivos de Azure no evita que tenga que crear los 15 recursos compartidos de SMB habituales en la instancia local de Windows Server. Solo significa que organiza las carpetas raíz de estos 15 recursos compartidos como subcarpetas en una carpeta común. A continuación, sincronizará esta carpeta común con un 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.

Sincronización de volúmenes

Azure File Sync admite la sincronización de la raíz de un volumen con un recurso compartido de archivos de Azure. Si sincroniza la raíz del volumen, todas las subcarpetas y los archivos van al mismo recurso compartido de archivos de Azure.

La sincronización de la raíz del volumen no siempre es la mejor opción. La sincronización de varias ubicaciones ofrece varias ventajas. Por ejemplo, ayuda a disminuir el número de elementos por ámbito de sincronización. Probamos los recursos compartidos de archivos de Azure y Azure File Sync con 100 millones de elementos (archivos y carpetas) por recurso compartido. Pero un procedimiento es intentar mantener el número por debajo de 20 o 30 millones en un solo recurso compartido. La configuración de Azure File Sync con un número de elementos menor no solo es beneficiosa para la sincronización de archivos. Un menor número de elementos también beneficia a escenarios como estos:

  • El examen inicial del contenido de la nube puede realizarse más rápido, lo que a su vez reduce la espera de que aparezca el espacio de nombres en un servidor habilitado para Azure File Sync.
  • La restauración en la nube a partir de una instantánea de recursos compartidos de archivos de Azure se hará con mayor rapidez.
  • La recuperación ante desastres de un servidor local puede acelerarse de forma considerable.
  • Los cambios hechos directamente en un recurso compartido de archivos de Azure (sin sincronización) se pueden detectar y sincronizar más rápido.

Sugerencia

Si no está seguro de cuántos archivos y carpetas tiene, consulte la herramienta TreeSize de JAM Software GmbH.

Un enfoque estructurado de una asignación de implementación

Antes de implementar el almacenamiento en la nube en un paso posterior, es importante crear una asignación entre carpetas locales y recursos compartidos de archivos de Azure. Esta asignación informará de cuántos recursos del grupo de sincronización de Azure File Sync se van a aprovisionar y de cuáles van a ser. Un grupo de sincronización está relacionado con el recurso compartido de archivos de Azure y la carpeta de su servidor, y establece una conexión de sincronización.

Para decidir cuántos recursos compartidos de archivos de Azure necesita, revise los límites y procedimientos recomendados siguientes. Eso le va a ayudar a optimizar la asignación.

  • Un servidor donde está instalado el agente de Azure File Sync puede sincronizarse con hasta 30 recursos compartidos de archivos de Azure.

  • Un recurso compartido de archivos de Azure se implementa en una cuenta de almacenamiento. Esta disposición hace que la cuenta de almacenamiento sea un destino de escalado para los números de rendimiento, como IOPS y rendimiento.

    Preste atención a las limitaciones de IOPS de una cuenta de almacenamiento al implementar recursos compartidos de archivos de Azure. Lo ideal sería asignar recursos compartidos de archivos 1:1 con cuentas de almacenamiento. Pero quizás no sea posible debido a diversos límites y restricciones, tanto de su organización como de Azure. Cuando no sea posible tener un solo recurso compartido de archivos implementado en una cuenta de almacenamiento, tenga en cuenta qué recursos compartidos estarán muy activos y cuales estarán menos activos, con el fin de asegurarse de que los recursos compartidos de archivos más activos no se colocan en la misma cuenta de almacenamiento.

    Si tiene previsto mover una aplicación a Azure que usará el recurso compartido de archivos de Azure de forma nativa, es posible que necesite un mayor rendimiento del recurso compartido de archivos de Azure. Si este tipo de uso es una posibilidad, incluso en el futuro, lo mejor es crear un único recurso compartido de archivos de Azure estándar en su propia cuenta de almacenamiento.

  • Hay un límite de 250 cuentas de almacenamiento por suscripción por cada región de Azure.

Sugerencia

Teniendo en cuenta esta información, suele ser necesario agrupar varias carpetas de nivel superior de sus volúmenes en un nuevo directorio raíz común. Luego se sincroniza este nuevo directorio raíz y todas las carpetas agrupadas en él, en un solo recurso compartido de archivos de Azure. Esta técnica permite permanecer dentro del límite de 30 sincronizaciones de recursos compartidos de archivos de Azure por servidor.

Esta agrupación bajo una raíz común no afecta al acceso a sus datos. Las ACL se mantienen como están. Solo tiene que ajustar algunas rutas de acceso a los recursos compartidos (como las de los recursos compartidos SMB o NFS) que podría haber en las carpetas de servidor locales que ahora han cambiado a una raíz común. No cambia nada más.

Importante

El vector de escala más importante para Azure File Sync es el número de elementos (archivos y carpetas) que tienen que sincronizarse. Para más información, revise los objetivos de escala de Azure File Sync.

Se recomienda mantener bajo el número de elementos por ámbito de sincronización. Ese es un factor importante que se debe tener en cuenta en la asignación de carpetas a recursos compartidos de archivos de Azure. Azure File Sync se prueba con 100 millones elementos (archivos y carpetas) por recurso compartido. Pero a menudo es mejor mantener el número de elementos por debajo de 20 o 30 millones en un solo recurso compartido. Divida el espacio de nombres en varios recursos compartidos si empieza a superar estos números. Puede seguir agrupando varios recursos compartidos locales en el mismo recurso compartido de archivos de Azure, siempre y cuando se mantenga aproximadamente por debajo de estos números. Esto le proporcionará más espacio para crecer.

En una situación tal, es posible que un conjunto de carpetas pueda sincronizarse de forma lógica con el mismo recurso compartido de archivos de Azure (mediante el nuevo enfoque de carpeta raíz común mencionado anteriormente). Pero puede que siga siendo mejor reagrupar carpetas de modo que se sincronicen con dos recursos compartidos de archivos de Azure en lugar de uno. Puede usar este enfoque para mantener equilibrado el número de archivos y carpetas por recurso compartido de archivos en el servidor. También puede dividir los recursos compartidos locales y sincronizarlos entre más servidores locales, lo que agrega la posibilidad de sincronizar 30 recursos compartidos de archivos de Azure más por cada servidor adicional.

Escenarios y consideraciones comunes de sincronización de archivos

# Escenario de sincronización Compatible Consideraciones (o limitaciones) Solución (o solución alternativa)
1 Servidor de archivos con varios discos o volúmenes y varios recursos compartidos en el mismo recurso compartido de archivos de Azure de destino (consolidación) No Un recurso compartido de archivos de Azure de destino (punto de conexión en la nube) solo admite la sincronización con un grupo de sincronización.

Un grupo de sincronización solo admite un punto de conexión de servidor por servidor registrado.		 1) Comience con la sincronización de un disco (su volumen raíz) para el recurso compartido de archivos de Azure de destino. Empezar con el disco o volumen más grande, ayudará con los requisitos de almacenamiento locales. Configure la nube por niveles para organizar en capas todos los datos en la nube, lo que libera espacio en el disco del servidor de archivos. Mueva datos de otros volúmenes o recursos compartidos al volumen actual que se está sincronizando. Continúe los pasos uno por uno hasta que todos los datos estén en capas en la nube o migrados.
2) Tenga un solo volumen raíz (disco) como destino a la vez. Use la nube por niveles para organizar en capas todos los datos para tener como destino el recurso compartido de archivos de Azure. Quite el punto de conexión de servidor del grupo de sincronización, vuelva a crear el punto de conexión con el siguiente volumen o disco raíz, sincronice y repita el proceso. Nota: Es posible que sea necesario volver a instalar el agente.
3) Se recomienda usar varios recursos compartidos de archivos de Azure de destino (misma o diferente cuenta de almacenamiento en función de los requisitos de rendimiento)
2 Servidor de archivos con un único volumen y varios recursos compartidos en el mismo recurso compartido de archivos de Azure de destino (consolidación) Sí No se pueden tener varios puntos de conexión de servidor por servidor registrado que se sincronicen con el mismo recurso compartido de archivos de Azure de destino (igual que anteriormente) Sincronice la raíz del volumen que contiene varios recursos compartidos o carpetas de nivel superior. Consulte Concepto de agrupación de recursos compartidos y Sincronización de volúmenes para obtener más información.
3 Servidor de archivos con varios recursos compartidos o volúmenes en varios recursos compartidos de archivos de Azure en una sola cuenta de almacenamiento (asignación de recursos compartidos de 1:1) Sí Una sola instancia de Windows Server (o clúster) puede sincronizar hasta 30 recursos compartidos de archivos de Azure.

Una cuenta de almacenamiento es un destino de escalado para el rendimiento. IOPS y el rendimiento se comparten entre recursos compartidos de archivos.

Mantenga el número de elementos por grupo de sincronización por debajo de 100 millones de elementos (archivos y carpetas) por recurso compartido. Idealmente, es mejor permanecer por debajo de 20 o 30 millones por recurso compartido.		 1) Use varios grupos de sincronización (número de grupos de sincronización = número de recursos compartidos de archivos de Azure con los que sincronizar).
2) Solo se pueden sincronizar 30 recursos compartidos en este escenario a la vez. Si tiene más de 30 recursos compartidos en ese servidor de archivos, use el concepto de agrupación de recursos compartidos y la sincronización de volúmenes para reducir el número de carpetas raíz o de nivel superior en el origen.
3) Use servidores File Sync adicionales locales y divida o mueva datos a estos servidores para solucionar las limitaciones del servidor Windows de origen.
4 Servidor de archivos con varios recursos compartidos o volúmenes en varios recursos compartidos de archivos de Azure en una cuenta de almacenamiento diferente (asignación de recursos compartidos de 1:1) Sí Una sola instancia de Windows Server (o clúster) puede sincronizar hasta 30 recursos compartidos de archivos de Azure (la misma cuenta de almacenamiento o una diferente).

Mantenga el número de elementos por grupo de sincronización por debajo de 100 millones de elementos (archivos y carpetas) por recurso compartido. Idealmente, es mejor permanecer por debajo de 20 o 30 millones por recurso compartido.		 El mismo enfoque que más arriba
5 Varios servidores de archivos con un único (volumen raíz o recurso compartido) en el mismo recurso compartido de archivos de Azure de destino (consolidación) No Un grupo de sincronización no puede usar el punto de conexión en la nube (recurso compartido de archivos de Azure) ya configurado en otro grupo de sincronización.

Aunque un grupo de sincronización puede tener puntos de conexión de servidor en distintos servidores de archivos, los archivos no pueden ser distintos.		 Siga las instrucciones del escenario n.º 1 anterior con una consideración adicional sobre tener un único servidor de archivos como destino a la vez.

Creación de una tabla de asignación

Diagram that shows an example of a mapping table. Download the following file to experience and use the content of this image.

Use la información anterior para decidir cuántos recursos compartidos de archivos de Azure necesita, y qué partes de los datos existentes terminarán en cuál recurso compartido de archivos de Azure.

Cree una tabla para registrar sus ideas, de modo que pueda consultarla cuando sea necesario. La organización es importante, ya que puede ser fácil perder detalles del plan de asignación cuando se aprovisionan muchos recursos de Azure a la vez. Descargue el siguiente archivo de Excel para usarlo como plantilla para ayudar a crear la asignación.


Excel icon that sets the context for the download. Descargue una plantilla de asignación de espacios de nombres.

Fase 2: Aprovisionamiento de una instancia de Windows Server adecuada en el entorno local

  • Cree una máquina virtual de Windows Server 2022 o Windows Server 2019, o implemente un servidor físico. También se admite un clúster de conmutación por error de Windows Server.

  • Aprovisione o agregue almacenamiento de conexión directa (DAS en lugar de NAS, que no se admite).

    La cantidad de almacenamiento que aprovisione puede ser menor que la que usa actualmente en el dispositivo NAS. Esta opción de configuración requiere que use también la característica de nube por niveles de Azure File Sync. Sin embargo, cuando en una fase posterior copie los archivos del espacio de NAS más grande al volumen más pequeño de Windows Server, tendrá que trabajar en lotes:

    1. Mueva un conjunto de archivos que quepa en el disco.
    2. Deje que la sincronización de archivos y la nube por niveles interactúen
    3. Cuando se cree más espacio disponible en el volumen, continúe con el siguiente lote de archivos. También puede revisar el comando RoboCopy en la sección sobre RoboCopy de este artículo para usar el nuevo conmutador /LFSM. El uso de /LFSM puede simplificar significativamente los trabajos de RoboCopy, pero no es compatible con otros modificadores de RoboCopy de los que podría depender. Use el conmutador /LFSM solo cuando el destino de la migración sea el almacenamiento local. No se admite cuando el destino es un recurso compartido de SMB remoto.

    Puede evitar este enfoque de procesamiento por lotes si aprovisiona el espacio equivalente en la instancia de Windows Server que ocupan los archivos en el dispositivo NAS. Considere la desduplicación en NAS/Windows. Si no quiere confirmar de manera permanente esta gran cantidad de almacenamiento en la instancia de Windows Server, puede reducir el tamaño del volumen después de la migración y antes de ajustar las directivas de nube por niveles. Esto crea una caché local más pequeña de los recursos compartidos de archivos de Azure.

La configuración de recursos (de proceso y RAM) de la instancia de Windows Server que implemente depende principalmente del número de elementos (archivos y carpetas) que se van a sincronizar. Se recomienda trabajar con una configuración de rendimiento más alto si tiene problemas.

Aprenda a cambiar el tamaño de un servidor de Windows Server según el número de elementos (archivos y carpetas) que necesite sincronizar.

Nota:

El artículo vinculado anteriormente presenta una tabla con un intervalo de memoria del servidor (RAM). Puede orientarse hacia el número más pequeño para el servidor, pero espere que la sincronización inicial tarde mucho más.

Fase 3: Implementación del recurso de nube de Azure File Sync

Para completar este paso, necesita las credenciales de la suscripción a Azure.

El recurso principal para configurar Azure File Sync se denomina servicio de sincronización de almacenamiento. Se recomienda implementar solo uno para todos los servidores que sincronizan el mismo conjunto de archivos ahora o en el futuro. Solo debe crear varios servicios de sincronización de almacenamiento si tiene distintos conjuntos de servidores que nunca deben intercambiar datos. Por ejemplo, podría tener servidores que nunca deben sincronizar el mismo recurso compartido de archivos de Azure. De lo contrario, el procedimiento recomendado es contar con un único servicio de sincronización de almacenamiento.

Elija una región de Azure para el servicio de sincronización de almacenamiento que esté cerca de su ubicación. Todos los demás recursos de nube se deben implementar en la misma región. Para simplificar el proceso de administración, cree un nuevo grupo de recursos en la suscripción para hospedar los recursos de sincronización y almacenamiento.

Para más información, consulte la sección sobre la implementación del servicio de sincronización de almacenamiento en el artículo sobre la implementación de Azure File Sync. Siga solo esta sección del artículo. En pasos posteriores, tendrá vínculos a otras secciones del artículo.

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

En esta fase, consulte la tabla de asignación de la fase 1 y úsela para aprovisionar el número correcto de cuentas de almacenamiento de Azure y recursos compartidos de archivos que contienen.

Un recurso compartido de archivos de Azure en la nube en una cuenta de almacenamiento de Azure. Aquí se aplica otro nivel de consideraciones relativas al rendimiento.

Si tiene recursos compartidos muy activos (recursos compartidos que usan muchos usuarios o aplicaciones), dos recursos compartidos de archivos de Azure podrían alcanzar el límite de rendimiento de una cuenta de almacenamiento.

Un procedimiento recomendado es implementar cuentas de almacenamiento con un recurso compartido de archivos cada una. 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.

Estas consideraciones se aplican más al acceso directo a la nube (a través de una VM de Azure) que a Azure File Sync. Si tiene pensado usar solo Azure File Sync en estos recursos compartidos, es correcta la agrupación de varios en una sola cuenta de almacenamiento de Azure.

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

En la fase anterior, estableció el número adecuado de recursos compartidos. En este paso, tiene una asignación de cuentas de almacenamiento a recursos compartidos de archivos. Ahora debe implementar el número adecuado de cuentas de almacenamiento de Azure con el número adecuado de recursos compartidos de archivos de Azure en ellas.

Asegúrese de que la región de cada una de las cuentas de almacenamiento sea la misma y coincida con la región del recurso del servicio de sincronización de almacenamiento que ya ha implementado.

Precaución

Si crea un recurso compartido de archivos de Azure con un límite de 100 TiB, ese recurso compartido puede usar solo las opciones de redundancia de almacenamiento con redundancia local o de zona. Tenga en cuenta sus necesidades de redundancia de almacenamiento antes de usar recursos compartidos de archivos de 100 TiB.

Los recursos compartidos de archivos de Azure todavía se crean con un límite de 5 TiB de forma predeterminada. Para crear un recurso compartido de archivos grande, siga los pasos de Creación de un recurso compartido de archivos de Azure.

Otra consideración a la hora de implementar una cuenta de almacenamiento es la redundancia de Azure Storage. Consulte las Opciones de redundancia de Azure Storage.

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.

Fase 5: Implementar el agente de Azure File Sync

En esta sección se instala el agente de Azure File Sync en una instancia de Windows Server.

En la guía de implementación se explica que es preciso desactivar la configuración de seguridad mejorada de Internet Explorer. Esta medida de seguridad no se puede aplicar con Azure File Sync. Si la desactiva, puede autenticarse en Azure sin ningún problema.

Abra PowerShell. Instale los módulos de PowerShell necesarios mediante los siguientes comandos. Asegúrese de instalar el módulo completo y el proveedor de NuGet cuando se le solicite hacerlo.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Si tiene algún problema para conectarse a Internet desde el servidor, ahora es el momento de solucionarlo. Azure File Sync usa cualquier conexión de red disponible a Internet. También se admite la exigencia de un servidor proxy para tener acceso a Internet. Ya puede configurar un proxy en toda la máquina, o bien, durante la instalación del agente, especificar un proxy que solo va a usar Azure File Sync.

Si para configurar un proxy debe abrir los firewalls del servidor, es posible que ese enfoque le resulte aceptable. Al final de la instalación del servidor, después de haber completado el registro del servidor, un informe de conectividad de red le mostrará las direcciones URL exactas de los puntos de conexión en Azure, con las que Azure File Sync necesita comunicarse en la región que ha seleccionado. El informe también indica por qué se necesita la comunicación. Puede usar el informe para bloquear los firewalls del servidor en direcciones URL específicas.

También puede adoptar un enfoque más conservador y no abrir totalmente los firewalls. En su lugar puede limitar el servidor para que se comunique con espacios de nombres DNS de nivel superior. Para más información, consulte Configuración del proxy y el firewall de Azure File Sync. Siga sus propios procedimientos recomendados de redes.

Al final del Asistente para la instalación del servidor, se abrirá un Asistente para el registro del servidor. Registre el servidor en el recurso de Azure del servicio de sincronización de almacenamiento anterior.

Estos pasos se describen con más detalle en la guía de implementación, que incluye los módulos de PowerShell que se deben instalar primero: Instalación de agente de Azure File Sync.

Use el agente más reciente. Puede descargarlo del Centro de descarga de Microsoft: Agente de Azure File Sync.

Después de una instalación y un registro del servidor correctos, puede confirmar que ha completado correctamente este paso. Vaya al recurso de Storage Sync Service en Azure Portal. En el menú de la izquierda, vaya a Servidores registrados. Verá que el servidor aparece en esa lista.

Fase 6: Configuración de Azure File Sync en el servidor de Windows Server

El servidor registrado de Windows Server debe estar preparado y conectado a Internet para este proceso.

Este paso une todos los recursos y carpetas que ha configurado en la instancia de Windows Server durante los pasos anteriores.

  1. Inicie sesión en Azure Portal.
  2. Busque el recurso del servicio de sincronización de almacenamiento.
  3. Cree un nuevo grupo de sincronización en el recurso del servicio de sincronización de almacenamiento para cada recurso compartido de archivos de Azure. En la terminología de Azure File Sync, el recurso compartido de archivos de Azure se convertirá en punto de conexión de la nube en la topología de sincronización que describe con la creación de un grupo de sincronización. Cuando cree el grupo de sincronización, asígnele un nombre descriptivo para poder reconocer qué conjunto de archivos se sincroniza allí. Asegúrese de hacer referencia al recurso compartido de archivos de Azure con un nombre coincidente.
  4. Después de haber creado el grupo de sincronización, aparecerá una fila para él en la lista de grupos de sincronización. Seleccione el nombre (un vínculo) para mostrar el contenido del grupo de sincronización. Verá el recurso compartido de archivos de Azure en Puntos de conexión en la nube.
  5. Busque el botón Agregar punto de conexión de servidor. La carpeta del servidor local que ha aprovisionado se convertirá en la ruta de acceso de este punto de conexión del servidor.

Importante

La nube por niveles es la característica de Azure File Sync que permite al servidor local tener menos capacidad de almacenamiento de la que está almacenada en la nube y, a pesar de ello, disponer de todo el espacio de nombres. Los datos de interés local (nivel de acceso frecuente) también se almacenan en caché para conseguir un rendimiento de acceso rápido. La nube por niveles es una característica opcional de cada "punto de conexión de servidor" de Azure File Sync.

Advertencia

Si aprovisionó menos almacenamiento en los volúmenes del servidor de Windows que los datos usados en el dispositivo NAS, la nube por niveles es obligatoria. Si no activa la nube por niveles, el servidor no liberará espacio para almacenar todos los archivos. De forma temporal para realizar la migración, establezca la directiva de almacenamiento por niveles en el 99 % de espacio disponible en el volumen. Asegúrese de volver a la configuración de nube por niveles una vez que se haya completado la migración y establézcala en un nivel de utilidad a más largo plazo.

Repita los pasos de creación de grupos de sincronización y adición de la carpeta de servidor correspondiente como un punto de conexión de servidor para todos los recursos compartidos de archivos de Azure o las ubicaciones del servidor, que deban configurarse para la sincronización.

Después de crear todos los puntos de conexión de servidor, la sincronización funciona. Puede crear un archivo de prueba y ver que se sincroniza desde la ubicación del servidor con el recurso compartido de archivos de Azure conectado (como se describe en el punto de conexión en la nube del grupo de sincronización).

En las dos ubicaciones, las carpetas del servidor y los recursos compartidos de archivos de Azure están vacíos y a la espera de datos. En el paso siguiente, comenzará a copiar archivos a la instancia de Windows Server para que Azure File Sync los transfiera a la nube. En caso de que haya habilitado la nube por niveles, el servidor comenzará a organizar los archivos en niveles, si se queda sin capacidad en los volúmenes locales.

Fase 7: Copia de datos mediante Azure Storage Mover o RoboCopy

Ahora puede usar Azure Storage Mover o RoboCopy para copiar datos del dispositivo NAS a Windows Server y usar Azure File Sync para mover los datos a recursos compartidos de archivos de Azure. En esta guía se usa RoboCopy para la copia inicial. Si prefiere usar Azure Storage Mover, consulte Migrar a recursos compartidos de archivos de Azure SMB con Azure Storage Mover.

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

  • Identifique la primera ubicación en el dispositivo NAS.
  • Identifique la carpeta coincidente en el servidor de Windows Server, que ya tiene Azure File Sync configurado.
  • Inicie la copia.

El comando de RoboCopy siguiente copiará los archivos desde el almacenamiento NAS a la carpeta de destino de la instancia de Windows Server. Windows Server los sincronizará con los recursos compartidos de archivos de Azure.

Si ha aprovisionado menos almacenamiento en la instancia de Windows Server que el que ocupan los archivos en el dispositivo NAS, ha configurado la nube por niveles. A medida que el volumen local de Windows Server se llena, la nube por niveles se iniciará y organizará por niveles los archivos que ya se han sincronizado correctamente. La nube por niveles generará espacio suficiente para continuar con la copia desde el dispositivo NAS. La nube por niveles realiza comprobaciones cada hora para averiguar qué se ha sincronizado y para liberar espacio en disco para alcanzar el 99 % de espacio libre del volumen.

Es posible que RoboCopy mueva los archivos más rápido de lo que se pueden sincronizar con la nube y el nivel localmente, y por tanto quedarse sin espacio en el disco local. En este caso, RoboCopy producirá un error. Se recomienda trabajar con los recursos compartidos en una secuencia que impida esto. Por ejemplo, no inicie trabajos de copia para todos los recursos compartidos al mismo tiempo, o bien transfiera solo los recursos compartidos que se ajusten a la cantidad actual de espacio disponible en la instancia de Windows Server.

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>
Modificador 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.
/LFSM Solo para destinos con almacenamiento en niveles. No se admite cuando el destino sea un recurso compartido de SMB remoto.
Especifica que Robocopy funciona en "modo de espacio libre bajo". Este modificador solo es útil para los destinos con almacenamiento en niveles que podrían quedarse sin capacidad local antes de que finalice Robocopy. Se agregó específicamente para su uso con un destino habilitado de nube por niveles de Azure File Sync. Se puede usar con independencia de Azure File Sync. En este modo, Robocopy se pondrá en pausa siempre que una copia de archivo haga que el espacio disponible del volumen de destino se sitúe por debajo de un valor de "suelo". El formato /LFSM:n de la marca puede especificar este valor. El parámetro n se especifica en la base 2: nKB, nMB o nGB. Si /LFSM se especifica sin ningún valor floor explícito, floor se establece en el 10 por ciento del tamaño del volumen de destino. El modo de espacio libre bajo no es compatible con /MT, /EFSRAW ni /ZB. Se agregó compatibilidad con /B en Windows Server 2022. Consulte la sección Windows Server 2022 y RoboCopy LFSM a continuación para obtener más información, incluidos detalles sobre un error y una solución alternativa relacionados.
/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.

Fase 8: 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 mover la mayor parte de los datos a la instancia de Windows Server y, después, a la nube a través de Azure File Sync. Esta primera copia puede tardar mucho tiempo, en función de lo siguiente:

  • El ancho de banda de descarga.
  • El ancho de banda de carga.
  • La velocidad de la red local y el número de subprocesos de RoboCopy que coincidan de forma óptima con ella.
  • El número de elementos (archivos y carpetas) que deben procesar RoboCopy y Azure File Sync

Una vez completada la ejecución inicial, vuelva a ejecutar el comando.

La segunda vez se completará más rápido, ya que solo necesita transportar los cambios posteriores a la última ejecución. Durante esta segunda ejecución, de todos modos se pueden acumular cambios nuevos.

Repita este proceso hasta que considere que el tiempo que tarda en completarse una operación de RoboCopy para una ubicación concreta se encuentra dentro una ventana de inactividad aceptable.

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

Ha terminado de migrar un recurso compartido o un grupo de recursos compartidos a un volumen o una raíz comunes. (Según la asignación de la fase 1)

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.

Advertencia

Cuando haya movido todos los datos de su ubicación de NAS a Windows Server y se haya completado la migración: vuelva a todos los grupos de sincronización de Azure Portal y ajuste el valor porcentual de espacio libre en el volumen de la nube por niveles a un valor más adecuado para el uso de la memoria caché, por ejemplo, un 20 %.

La directiva de espacio libre en el volumen de la nube por niveles actúa en un nivel de volumen desde el que se pueden sincronizar varios puntos de conexión de servidor. Si olvida ajustar el espacio disponible en un punto de conexión del servidor, la sincronización seguirá aplicando la regla más restrictiva e intentará mantener un 99 % de espacio libre en disco, lo que hará que la memoria caché local no funcione según lo previsto. A menos que el objetivo sea tener solamente el espacio de nombres para un volumen que solo contiene datos de archivo a los que se accede con poca frecuencia y reserve el resto del espacio de almacenamiento para otro escenario.

Solución de problemas

El problema que puede experimentar más probablemente es que el comando de RoboCopy produzca el error "Volumen lleno" en el lado de Windows Server. La nube por niveles actúa una vez cada hora para evacuar el contenido del disco local de Windows Server, que se ha sincronizado. Su objetivo es alcanzar el 99 % de espacio libre en el volumen.

Permita que el progreso de la sincronización y la nube por niveles liberen espacio en disco. Puede observarlo en el Explorador de archivos en Windows Server.

Cuando Windows Server tenga capacidad suficiente disponible, el problema se resolverá al volver a ejecutar el comando. Si se da esta situación, no se interrumpe nada y puede avanzar con confianza. La única consecuencia es el inconveniente de tener que volver a ejecutar el comando.

Consulte el vínculo de la sección siguiente para solucionar problemas de Azure File Sync.

Pasos siguientes

Los artículos siguientes le ayudarán a comprender las opciones de implementación, los procedimientos recomendados y los pasos para solucionar problemas.