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 totalmente administrado que migra archivos y carpetas a Azure Storage y mantiene los archivos sincronizados entre cuentas de almacenamiento. Use Storage Mover cuando mueva datos a Azure o cuando necesite mantener los datos sincronizados entre diferentes ubicaciones dentro de Azure.
Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de capacidades para apoyar la resiliencia y la recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.
En este artículo se describe cómo Azure Storage Mover responde a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, errores de zona de disponibilidad y errores en toda la región. También se describe cómo proteger la configuración de Storage Mover.
Important
En este artículo se describe la confiabilidad del servicio Azure Storage Mover y sus recursos únicamente. La confiabilidad de una migración de un extremo a otro depende de todos los componentes: el servicio Storage Mover, los agentes de Storage Mover que implemente, el entorno de origen y la conectividad de red y la cuenta de almacenamiento de destino. Es responsable de la confiabilidad de los agentes, los sistemas de origen y el almacenamiento de destino. Para obtener más información sobre la confiabilidad de Azure Storage, consulte Confiabilidad en Azure Blob Storage y Confiabilidad en Azure Files.
Introducción a la arquitectura de confiabilidad
En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.
Arquitectura lógica
Azure Storage Mover está diseñado para migrar y sincronizar datos entre ubicaciones de almacenamiento, no para atender solicitudes en la ruta de acceso en tiempo de ejecución de una carga de trabajo de producción. Tiene una jerarquía de recursos que define los componentes que implementa y administra. El recurso de nivel superior se denomina mover de almacenamiento. Dentro de un mover de almacenamiento, se definen proyectos que contienen definiciones de trabajo que describen qué migrar y dónde. Los puntos de conexión definen las ubicaciones de origen y destino para un trabajo de migración o sincronización.
En algunos escenarios, como las migraciones desde entornos locales, también se implementan uno o varios agentes de Storage Mover. Un agente es software que se ejecuta en una máquina que controla, como una máquina virtual o una máquina física. Algunos escenarios no requieren un agente.
El servicio almacena metadatos de configuración, incluidos proyectos, puntos de conexión, registros de agente, definiciones de trabajo y historial de ejecución de trabajos. Estos metadatos no incluyen los datos que migras.
Arquitectura física
El servicio Azure Storage Mover se ejecuta en una infraestructura administrada por Microsoft. Los agentes se ejecutan en el hardware que administras. Usted es responsable de la confiabilidad de los agentes, que está fuera del ámbito de este artículo.
Resistencia a errores transitorios
Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.
Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para más información, vea Recomendaciones para gestionar errores temporales.
Si un error transitorio afecta a la comunicación entre un agente y el servicio Storage Mover, o al conectarse a un origen o destino, el agente vuelve a intentarlo automáticamente. Para los trabajos de Azure a Azure, el servicio también es resistente a muchos errores transitorios. Cuando se restaura la conectividad, los trabajos de migración en curso se reanudan.
En algunos casos, los errores transitorios aparecen como errores en el historial de ejecución de trabajos. Para obtener una descripción de los códigos de error, incluidos los errores transitorios, consulte Azure Storage códigos de estado y tipos de error de Mover. Para obtener instrucciones sobre cómo resolver problemas de conectividad de red persistentes, consulte Solución de problemas de conectividad de red de Azure Storage Mover.
Resistencia a errores de zona de disponibilidad
Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.
En las regiones que admiten zonas de disponibilidad, la plataforma distribuye los metadatos de configuración de un storage mover entre zonas en la medida de lo posible, pero este comportamiento no está garantizado. Si sus migraciones de almacenamiento deben soportar la pérdida de una zona, diseñe el proceso de migración para que tolere la pérdida de un migrador de almacenamiento y revise Resiliencia ante fallos en toda una región.
Tenga en cuenta el efecto de un error de zona en el contexto de cómo se usa Storage Mover. El servicio orquesta la migración y la sincronización de datos, y normalmente no forma parte de la ruta de ejecución de su carga de trabajo de producción. Si un mecanismo de traslado de almacenamiento no está disponible durante un fallo de zona, un trabajo de migración o sincronización suele retrasarse en lugar de provocar una interrupción en producción, y se puede reanudar o reintentar después de que el servicio se recupere. Storage Mover tampoco ofrece un acuerdo de nivel de servicio (SLA) de disponibilidad, por lo que el diseño no debe suponer que el servicio está disponible continuamente. Si la carga de trabajo depende de la sincronización en curso, evalúe si este tipo de retraso es aceptable para su escenario.
En el diagrama siguiente se muestra un mover de almacenamiento con metadatos de infraestructura y configuración distribuidos entre tres zonas:
Note
La confiabilidad de cualquier migración de datos también depende de las cuentas de almacenamiento y los agentes que use. Por ejemplo, si la cuenta de almacenamiento de destino usa almacenamiento con redundancia local (LRS), no es resistente a un error de zona. Para que una migración sea resistente a un error de zona, use una cuenta de almacenamiento de destino con redundancia de zona.
Requirements
Compatibilidad regional: La distribución según el criterio de máximo esfuerzo de los metadatos de configuración entre zonas solo puede darse en una región que sea compatible tanto con Storage Mover como con las zonas de disponibilidad. Compruebe la disponibilidad de la región de Storage Mover y compárela con la lista de regiones que admiten zonas de disponibilidad. Incluso en estas regiones, la resiliencia zonal no está garantizada.
Costo
Storage Mover no ofrece compatibilidad con zonas de disponibilidad configurables, por lo que no incurre en ningún costo adicional relacionado con las zonas de disponibilidad. Para obtener más información sobre cómo se factura Storage Mover, consulte Descripción de la facturación de Azure Storage Mover.
Configurar soporte de zonas de disponibilidad
Storage Mover no ofrece compatibilidad con zonas de disponibilidad configurables, por lo que no hay nada para habilitar o participar. Para obtener más información sobre cómo crear un recurso de Storage Mover, consulte Planeamiento de implementación para Azure Storage Mover.
Comportamiento cuando todas las zonas están en buen estado
En esta sección se describe qué esperar cuando un mover de almacenamiento está en una región que admite zonas de disponibilidad y todas las zonas están operativas.
Operación entre zonas: La infraestructura de cualquiera de las zonas de disponibilidad de la región podría servir a las operaciones de administración y al acceso a metadatos. Las conexiones de los agentes pueden acceder al servicio a través de cualquier zona.
Distribución de datos entre zonas: El servicio tiene como objetivo replicar de forma sincrónica los metadatos de configuración en las zonas de disponibilidad de la región.
Comportamiento durante un fallo de zona
En esta sección se describe qué esperar cuando un mover de almacenamiento está en una región que admite zonas de disponibilidad y hay una interrupción en una de las zonas.
- Detección y respuesta: La plataforma está diseñada para detectar la pérdida de una zona de disponibilidad y redirigir el tráfico a zonas correctas, pero esta respuesta es el mejor esfuerzo y no está garantizada.
- Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas. También puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.
Solicitudes activas: Las operaciones de administración en curso que dependen de la infraestructura de la zona afectada pueden producir errores y debe reintentarlas. Los trabajos de migración de datos activos que se ejecutan en agentes podrían seguir ejecutándose, pero las operaciones de administración que dependen del servicio de metadatos podrían no estar disponibles.
Pérdida de datos esperada: Los datos que está migrando un mover de almacenamiento no se pierden durante un error de zona.
Dado que Storage Mover no garantiza que los metadatos de configuración se distribuyan entre zonas, un error de zona podría hacer que algunos de los metadatos de configuración del mover de almacenamiento no estén disponibles temporalmente hasta que se recupere la zona.
Tiempo de inactividad esperado: La plataforma intenta restaurar las operaciones mediante otra zona, pero en algunas situaciones es posible que las operaciones no estén disponibles hasta que se recupere la zona afectada. Prepare la carga de trabajo siguiendo las instrucciones de control de errores transitorios.
Redistribución: Si la plataforma redirige el tráfico a zonas de disponibilidad en buen estado, lo hace en la medida de lo posible.
Recuperación de zona
Cuando se recupera una zona de disponibilidad, la plataforma pretende restaurar la capacidad en la zona recuperada y reequilibrar el tráfico entre zonas. Este comportamiento se realiza en la medida de lo posible y no está garantizado. No es necesario realizar ninguna acción para iniciar la recuperación de zona.
Prueba de fallos de zona
No se puede iniciar ni simular un error de zona de disponibilidad para un Storage Mover. Dado que Storage Mover no garantiza la resiliencia de la zona, no se debe dar por sentado que un Storage Mover sobrevivirá a un error de zona. Si el proceso de migración necesita soportar la pérdida de una zona, valide por su cuenta la resiliencia integral de ese proceso y revise Resilience to region-wide failures para conocer enfoques que le permitan controlar la conmutación por error.
Resistencia a errores en toda la región
Azure Storage Mover es un servicio de una sola región. Al implementar un recurso de Azure Storage Mover, seleccione una región para almacenar los metadatos de configuración del recurso. Si la región del mover de almacenamiento experimenta una interrupción, es posible que las operaciones de administración que realice el agente y que dependen de Azure no se completen. Además, es posible que se produzca un error en las migraciones de datos activas a cuentas de almacenamiento ubicadas en la región afectada.
Si su Storage Mover se encuentra en una región de Azure con un par, sus metadatos de configuración se replican en la región de Azure emparejada con fines de recuperación ante desastres, y Microsoft puede activar la conmutación por error a la región emparejada durante un desastre que afecte a su región principal.
Si su Storage Mover se encuentra en una región no emparejada, Microsoft no replica los metadatos de configuración y no existe una conmutación por error integrada a otra región. Sin embargo, puede implementar recursos independientes en varias regiones. En este escenario, es responsabilidad suya administrar la replicación, la distribución del tráfico y la conmutación por error. Si utiliza una región no emparejada o si la replicación de metadatos integrada no satisface sus necesidades, puede crear una estrategia de conmutación por error multirregional personalizada.
Note
Usted es responsable de la recuperación ante desastres de sus orígenes de datos (incluidos los de Azure y los locales), los destinos y los agentes.
Conmutación por error administrada por Microsoft en una región emparejada
Si el recurso de Storage Mover está en una región que se empareja con otra región, Microsoft replica los metadatos de configuración del mover de almacenamiento en la región emparejada.
En caso de interrupción del servicio en una región, Microsoft podría realizar una conmutación por error a la región emparejada utilizando los metadatos de configuración replicados. Este proceso es una opción predeterminada y no requiere intervención de usted.
La conmutación por error de los recursos de Storage Mover puede producirse en un momento diferente a cualquier conmutación por error de otros servicios de Azure.
Important
Es poco probable que Microsoft inicie la conmutación por error salvo tras un retraso significativo, y esta se lleva a cabo según el principio de mejor esfuerzo. Si necesita cumplir plazos específicos para la recuperación de Storage Mover, o si el comportamiento predeterminado de replicación y conmutación por error no se ajusta a sus necesidades, utilice soluciones multirregionales personalizadas para la resiliencia con el fin de planificar e iniciar su propia conmutación por error.
La replicación entre regiones solo se aplica a los metadatos de configuración. No se aplica a los datos de origen ni a la cuenta de almacenamiento de destino, que tiene sus propias opciones de confiabilidad y replicación. Para obtener más información, consulte Confiabilidad en Azure Blob Storage y Confiabilidad en Azure Files.
Requirements
Compatibilidad con regiones: la replicación entre regiones administrada por Microsoft solo está disponible para los recursos de Storage Mover que implemente en una región que tenga una región emparejada. Para los recursos ubicados en regiones no emparejadas, no se proporciona replicación ni conmutación por error entre regiones. Para lograr resistencia entre regiones en regiones no emparejadas, use una solución personalizada de varias regiones.
Costo
Storage Mover no cobra por la replicación entre regiones administrada por Microsoft de la configuración del mover de almacenamiento. Sin embargo, puede haber un pequeño coste por la replicación entre regiones. Para obtener más información, consulte Precios del ancho de banda.
Configuración de la compatibilidad con varias regiones
La replicación entre regiones administrada por Microsoft se habilita automáticamente para los recursos de Storage Mover en regiones emparejadas. No configuras ni optas por este comportamiento.
Comportamiento cuando todas las regiones están en buen estado
En esta sección se describe qué cabe esperar cuando un migrador de almacenamiento está configurado para la replicación entre regiones y la conmutación por error, mientras la región primaria está operativa.
Operación entre regiones: El recurso de Storage Mover en la región primaria atiende todas las solicitudes. La región emparejada solo se usa en caso de una conmutación por error iniciada por Microsoft.
Replicación de datos entre regiones: La región primaria replica la configuración de forma asincrónica en la región emparejada. Dado que la replicación es asincrónica, es posible que los cambios recientes en la configuración no se reflejen en la región emparejada en el momento de un error.
Comportamiento durante una falla de región
En esta sección se describe qué cabe esperar cuando un servicio de transferencia de almacenamiento está configurado para la replicación entre regiones y la conmutación por error, y se produce una interrupción en la región primaria.
- Detección y respuesta: Microsoft detecta los errores en las regiones y decide si iniciar una conmutación por error. Es poco probable que Microsoft inicie la conmutación por error salvo tras un retraso significativo, y dicha conmutación se lleva a cabo según el principio de mejor esfuerzo.
Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo:
Puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas.
Puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle los problemas.
Solicitudes activas: Las solicitudes de administración activas se descartan y deben volver a intentarse una vez finalizada la conmutación por error. Las tareas de migración de datos activas que se estén ejecutando en los agentes pueden generar un error si dependen de la región que está sufriendo la interrupción del servicio.
Pérdida de datos esperada: Dado que la replicación entre regiones es asincrónica, es posible que se pierdan los cambios de metadatos de configuración que no se replican en la región emparejada en el momento de la interrupción.
Tiempo de inactividad esperado: Una conmutación por error de región puede tardar hasta 24 horas en completarse. Durante este tiempo, el Storage Mover no estará disponible.
Redistribución: Una vez completada la conmutación por error, Storage Mover comienza a ejecutar tareas desde la región emparejada.
Sin embargo, es necesario volver a registrar los agentes en el Storage Mover de la región emparejada.
Recuperación de regiones
Cuando la región principal original se recupere, Microsoft coordinará la conmutación de retorno. Debes volver a registrar los agentes en el Storage Mover de la región principal.
Prueba de fallos de región
La plataforma Azure Storage Mover administra la replicación entre regiones, la conmutación por error y la recuperación de regiones. Dado que Microsoft administra íntegramente esta característica, no puedes iniciar ni probar una conmutación por error de región.
Soluciones personalizadas de varias regiones para la resistencia
Si necesita controlar cuándo se produce la conmutación por error, o si se encuentra en una región no emparejada pero aun así necesita que su recurso de Storage Mover sea resistente a caídas regionales, implemente recursos de Storage Mover independientes en varias regiones de Azure. Usted es responsable de todos los aspectos de este enfoque, entre los que se incluyen:
- Crear y mantener proyectos, puntos de conexión, agentes y definiciones de trabajo equivalentes en cada región.
- Detección de errores en las regiones y decisión sobre cuándo realizar la conmutación por error.
- Redirigir agentes y trabajos de migración a la región secundaria.
- Sincronización del estado de los trabajos y del historial de ejecuciones entre regiones.
Una solución multirregional personalizada funciona tanto para regiones emparejadas como para regiones no emparejadas, y ofrece un control total sobre el proceso de conmutación por error.
Para obtener más información, consulte Recuperación ante desastres iniciada por el cliente para Azure Storage Mover.
Copias de seguridad y restauración
Azure Storage Mover es un servicio de orquestación de movimiento de datos y migración. No almacena los datos migrados. El servicio solo almacena metadatos de configuración, como proyectos, puntos de conexión, definiciones de trabajo y historial de ejecución de trabajos. No hay datos de migración para realizar copias de seguridad.
Para proteger tu configuración de Storage Mover, define tus recursos mediante infraestructura como código, como los archivos Bicep, y almacena esas definiciones en el control de código fuente. Si necesita volver a crear un recurso, puede volver a implementarlo desde la configuración almacenada.
Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.
Resistencia al mantenimiento del servicio
Microsoft aplica periódicamente actualizaciones de servicio y realiza otro mantenimiento. La plataforma Azure controla estas actividades automáticamente, lo que garantiza que el mantenimiento sea transparente y sin problemas. No se prevé ningún tiempo de inactividad durante las operaciones de mantenimiento, a menos que se te haya informado a través de el mantenimiento planificado de Azure Service Health.
Los agentes de Storage Mover se actualizan automáticamente.
Acuerdo de nivel de servicio
Storage Mover es un servicio de migración y no ofrece un contrato de nivel de servicio (SLA) de disponibilidad. Sin embargo, la documentación de Storage Mover describe los objetivos de escala y rendimiento esperados. Estos objetivos se basan en migraciones simuladas y no constituyen una garantía ni un compromiso.