Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure Storage Mover es un servicio de migración totalmente administrado que le permite migrar los archivos y carpetas de cubos locales o aws S3 a Azure Storage, a la vez que minimiza el tiempo de inactividad de la carga de trabajo.
Es posible usar Storage Mover para diferentes escenarios de migración, como migrar mediante lift-and-shift, y para migraciones que tenga que repetir con regularidad. Azure Storage Mover también ayuda a mantener la supervisión y administrar la migración de todos los recursos compartidos de archivos distribuidos globalmente desde un único recurso de mover de almacenamiento. Mover también se puede implementar en la nube de Azure Government. Para obtener más información, consulte ¿Qué es Azure Government?.
Orígenes y destinos compatibles
La versión actual de Azure Storage Mover admite migraciones de fidelidad completa para combinaciones específicas de pares de destino de origen. Use siempre la versión más reciente del agente para beneficiarse de estos orígenes y destinos admitidos:
| Protocolo de origen | Destino | Comentarios |
|---|---|---|
| AWS S3 | Contenedor de blobs de Azure | Los cubos de AWS (Amazon Web Services) S3 con clases de almacenamiento Glacier o Glacier Deep Archive no se pueden migrar y deben restaurarse para que Mover los migre. |
| AWS FSx – SMB (Vista previa) | Azure Files SMB | Requiere conectividad de red privada al recurso compartido SMB de FSx y credenciales SMB con acceso al recurso compartido de origen. |
| GCS S3 (Vista previa) | Contenedor de blobs de Azure | Asegúrate de que el bucket GCS sea accesible a través de la API compatible con S3 antes de la migración. Debes restaurar objetos en clases de almacenamiento archivístico antes de la migración. |
| Contenedor de blobs de Azure | Contenedor de blobs de Azure | Los contenedores de blobs pueden estar en dos suscripciones y cuentas de almacenamiento diferentes, pero deben pertenecer al mismo inquilino. Los contenedores soportados incluyen aquellos con las funciones de Flatnamespace (FNS) y Servicio de Espacio de Nombres Jerárquico (HNS) activadas. La migración utiliza el conjunto de API REST de la generación 2 de ADLS. |
| Contenedor de blobs de Azure | Contenedor de blobs de Azure | Los contenedores de blobs pueden estar en suscripciones diferentes y en cuentas de almacenamiento diferentes, pero deben encontrarse en el mismo inquilino. Se admiten contenedores con flatnamespace (FNS) y la característica servicio de espacio de nombres jerárquico (HNS) habilitada y se usa el conjunto de API REST de ADLS Gen2 para la migración. |
| Montaje SMB 2.x y 3.x | Recurso compartido de archivos de Azure (SMB) | Actualmente no se admiten orígenes SMB 1.x ni recursos compartidos de archivos de Azure NFS. |
| Montaje SMB 2.x y 3.x | Contenedor de blobs de Azure | Se admiten contenedores con flatnamespace (FNS) y la característica servicio de espacio de nombres jerárquico (HNS) habilitada y se usa el conjunto de API REST de ADLS Gen2 para la migración. |
| Montaje de SMB 2.x y 3.x (sin agente) | Recurso compartido de archivos de Azure (SMB) | Requiere conectividad privada al recurso compartido SMB de origen y credenciales de SMB almacenadas en Azure Key Vault. |
| Montaje de SMB 2.x y 3.x (sin agente) | Contenedor de blobs de Azure | Se admiten contenedores con flatnamespace (FNS) y la característica servicio de espacio de nombres jerárquico (HNS) habilitada y se usa el conjunto de API REST de ADLS Gen2 para la migración. Requiere conectividad privada al recurso compartido SMB de origen y acceso a las credenciales SMB almacenadas en Azure Key Vault. |
| Montaje de NFS 3 y 4 | Compartición de archivos de Azure (NFS 4.1) | Los recursos compartidos de archivos NFS de Azure admiten NFS v3 y v4 como origen. |
| Montaje de NFS 3 y 4 | Compartición de archivos de Azure (NFS 4.1) | Las comparticiones de archivos de Azure NFS son compatibles con NFS v3/4. |
Un contenedor de blobs de Azure sin la característica de servicio de espacio de nombres jerárquico no tiene un sistema de archivos tradicional. Un contenedor de blobs estándar usa carpetas "virtuales" para imitar esta funcionalidad. Cuando se usa este enfoque, los archivos de las carpetas del origen obtendrán su ruta de acceso antepuesta a su nombre y se colocarán en una lista plana en el contenedor de blobs de destino.
Al migrar datos desde un punto de conexión de origen mediante el protocolo SMB, Storage Mover admite el mismo nivel de fidelidad de archivos que el recurso compartido de archivos de Azure subyacente. Se mantienen la estructura de carpetas y los valores de metadatos, como las marcas de tiempo de archivo y carpeta, las ACL y los atributos de archivo. Durante una migración de datos desde un origen NFS, el servicio Storage Mover representa carpetas vacías como un blob vacío en el destino. Los metadatos de la carpeta de origen se conservarán en el campo de metadatos personalizados de este blob, al igual que con los archivos.
Sin embargo, la migración de datos desde un punto de conexión de origen mediante el protocolo NFS puede requerir carpetas "virtuales" durante la migración. Dado que los contenedores de blobs de Azure sin compatibilidad con HNS no tienen un sistema de archivos tradicional, Storage Mover usa estas carpetas para imitar un sistema de archivos local. Cuando los archivos se encuentran dentro de carpetas en un punto de conexión de origen, Storage Mover antepone sus rutas de acceso a sus nombres y coloca el archivo en una lista plana dentro del contenedor de blobs de destino.
Migraciones totalmente administradas
Solo necesita implementar una instancia de Storage Mover en su suscripción para controlar las migraciones de varios recursos compartidos de origen, incluso si se encuentran en diferentes partes del mundo. El propio recurso del mover de almacenamiento no procesa los archivos y carpetas. En su lugar, implementará un agente de migración cerca del recurso compartido de origen para enviar los datos directamente a los destinos seleccionados en Azure.
Azure Storage Mover proporciona un conjunto de recursos de administración que se pueden usar en todos los recursos compartidos que quiere migrar. Por ejemplo, puede expresar el plan de migración y conservar la supervisión sobre el progreso y los resultados de la migración por recurso compartido. Para aprovechar esta funcionalidad, cree un proyecto de migración para cada carga de trabajo que migre. En el proyecto, defina la configuración de origen, destino y migración para cada recurso compartido de origen en el que depende la carga de trabajo. Puede permanecer en control total sobre cuándo iniciar la migración de un recurso compartido, realizar un seguimiento del progreso y ver sus resultados.
El artículo jerarquía de recursos tiene más información sobre los recursos individuales de Storage Mover y cómo usarlos mejor para la migración. También puede obtener más detalles de planeamiento de implementación en el artículo planeamiento de una implementación de Azure Storage Mover.
Un servicio en la nube híbrida
Azure Storage Mover admite cargas de trabajo de migración sin agente y basadas en agente. En el caso de las cargas de trabajo basadas en agente, una máquina virtual del agente de migración se ejecuta en el entorno cerca del almacenamiento de origen. En el caso de las cargas de trabajo sin agente, no se requiere ninguna máquina virtual del agente de migración.
El servicio en la nube proporciona orquestación y administración de la migración para ambos tipos de carga de trabajo. Para cargas de trabajo basadas en agente, consulte los artículos sobre la implementación y el registro del agente de Storage Mover.
Uso de Azure Storage Mover y Azure Data Box
Al realizar la transición de cargas de trabajo locales a Azure Storage, reducir el tiempo de inactividad y garantizar que los períodos predecibles de falta de disponibilidad son cruciales para los usuarios y las operaciones empresariales. Para la migración masiva inicial, puede usar Azure Data Box y combinarla con Azure Storage Mover para ponerse al día en línea.
El uso de Azure Data Box conserva un ancho de banda de red significativo. Sin embargo, las cargas de trabajo activas en el almacenamiento de origen pueden someterse a cambios mientras Data Box está en tránsito a un centro de datos de Azure. La fase de "puesta al día en línea" implica actualizar el almacenamiento en la nube con estos cambios antes de cortar completamente la carga de trabajo para usar los datos en la nube. Normalmente, esta fase requiere un ancho de banda mínimo, ya que la mayoría de los datos ya residen en Azure y solo se necesita transferir el delta. Azure Storage Mover destaca en esta tarea.
Azure Storage Mover detecta diferencias entre el almacenamiento local y el almacenamiento en la nube, transfiriendo actualizaciones y nuevos archivos no capturados por la transferencia de Data Box. Además, si el único cambio en un archivo está limitado a sus metadatos (por ejemplo, permisos), Azure Storage Mover carga solo los nuevos metadatos en lugar de todo el contenido del archivo.
Obtenga más información sobre cómo usar Azure Storage Mover con Azure Data Box en el blog de Azure Storage.
Pasos siguientes
Estos artículos pueden ayudarle a familiarizarse más con el servicio Storage Mover.