Compartir a través de

Confiabilidad en Azure Storage Mover

  • Artículo

En este artículo se describe la compatibilidad con la confiabilidad en Azure Storage Mover y se trata tanto la resistencia dentro de la región con zonas de disponibilidad y recuperación ante desastres entre regiones y continuidad empresarial. Para obtener información general más detallada sobre los principios de confiabilidad de Azure, consulte Confiabilidad de Azure.

Compatibilidad de zonas de disponibilidad

Las zonas de disponibilidad de Azure son al menos tres grupos de centros de datos físicamente independientes dentro de cada región de Azure. Los centros de datos de cada zona están equipados con infraestructura de alimentación, refrigeración y red independientes. En el caso de un error en la zona local, las zonas de disponibilidad están diseñadas de manera que, si se ve afectada una zona, los servicios, la capacidad y la alta disponibilidad regionales serán proporcionadas por las dos zonas restantes.

Estos errores pueden abarcar desde errores de software y hardware hasta eventos como terremotos, inundaciones e incendios. La tolerancia a los errores se logra con la redundancia y el aislamiento lógico de los servicios de Azure. Para más información sobre las zonas de disponibilidad en Azure, consulte Regiones y zonas de disponibilidad.

Los servicios habilitados para zonas de disponibilidad de Azure están diseñados para proporcionar el nivel adecuado de confiabilidad y flexibilidad. Se pueden configurar de dos maneras. Pueden tener redundancia de zona, con una replicación automática entre zonas o ser zonales, con instancias ancladas a una zona específica. También puede combinar ambos enfoques. Para más información sobre la arquitectura zonal frente a la arquitectura con redundancia de zona, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.

Azure Storage Mover admite un modelo de implementación con redundancia de zona.

Al implementar un recurso de Azure Storage Mover, debe seleccionar una región determinada en la que se almacenan los metadatos de la instancia del recurso.

Si la región admite zonas de disponibilidad, los metadatos de la instancia se replican automáticamente en varias zonas de disponibilidad dentro de esa región.

Importante

Los metadatos de instancia de Azure Storage Mover incluyen proyectos, puntos de conexión, agentes, definiciones de tareas e historial de ejecución de tareas, pero no incluyen los datos reales que se van a migrar. Las cuentas de almacenamiento de Azure que se usan como destinos de migración tienen su propia compatibilidad con la confiabilidad.

Requisitos previos

Experiencia a nivel de zona

Durante una interrupción de toda la zona, no se requiere ninguna acción con fines de recuperación de zona. Azure Storage Mover está diseñado para autorecuperarse y reequilibrarse para aprovechar la zona correcta automáticamente.

Cualquier cuenta de almacenamiento de destino de migración puede requerir sus propios pasos de recuperación. Este requisito depende de las opciones de redundancia elegidas para cada cuenta de almacenamiento. Consulte la guía de recuperación ante desastres de la cuenta de almacenamiento para determinar si son necesarios más pasos.

Si se eligió un almacenamiento local en lugar de las opciones de redundancia, es posible que tenga que crear una nueva cuenta de almacenamiento para utilizarla en las migraciones durante la interrupción.

Recuperación ante desastres entre regiones y continuidad empresarial

La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.

En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.

Cuando se registra un agente Storage Mover, se conecta a la región en la que está registrado el recurso Storage Mover. Si la región Azure de un agente experimenta una interrupción, el agente en sí no se verá afectado, pero las operaciones de administración que dependen de Azure pueden no ser capaces de completarse. Además, cualquier migración de datos activa a cuentas de almacenamiento situadas en la región afectada puede fallar.

Storage Mover admite dos formas de recuperación ante desastres:

Importante

La recuperación ante desastres para orígenes de datos locales es responsabilidad del cliente.

Recuperación ante desastres iniciada por Azure

La recuperación ante desastres iniciada por Azure solo se aplica a las regiones que tienen pares de regiones. Cuando se usa la replicación entre regiones, los metadatos de instancia se replican en cada región, pero nunca se permite salir de la geografía.

Azure Storage Mover usa Cosmos DB para almacenar metadatos de instancia. La pérdida de datos solo puede producirse con un desastre irrecuperable en Azure Cosmos DB. Para más información, consulte la información sobre la Interrupción de regiones. La recuperación iniciada por Azure es activa-pasiva y la recuperación completa de una región puede ser de hasta 24 horas.

Recuperación ante desastres iniciada por el cliente

La recuperación ante desastres iniciada por el cliente no está restringida a regiones emparejadas.

Antes de que se produzca una interrupción regional:

  • Implemente un Storage Mover redundante por zonas creando recursos Storage Mover en una región que admita zonas de disponibilidad.

  • Periódicamente, ya sea según una programación o después de realizar cambios sustanciales, tome una instantánea de los recursos de Storage Mover. Almacenar las instantáneas mediante un sistema de control de versiones es una buena manera de almacenar y realizar un seguimiento del historial de las instantáneas. Usará la última instantánea correcta en caso de desastre en la que necesite recuperar los recursos en una nueva región.

Durante una interrupción regional:

Puede realizar una de estas dos acciones:

  • Elija esperar a que Azure recupere la región.
  • Minimice el tiempo de inactividad volviendo a implementar sus recursos a otra región. Dado que el acceso a sus recursos puede verse afectado durante una interrupción, querrá utilizar la última instantánea buena de sus recursos.

Sugerencia

Cualquiera de estas estrategias puede requerir que tome medidas adicionales antes de una catástrofe, así que asegúrese de revisar y planificar en consecuencia.

Implementación de recursos en otra región

Consulte la documentación sobre la exportación de plantillas para obtener más instrucciones sobre cómo exportar recursos como una plantilla de Azure Resource Manager (ARM).

Si su Storage Mover y los recursos relacionados residen en un contenedor sin recursos adicionales, debe realizar una exportación de Grupo de recursos para capturar el estado actual. Sin embargo, si el grupo de recursos contiene recursos no relacionados, es posible que tenga que quitar o excluir los recursos de la plantilla.

Los agentes existentes no se pueden volver a implementar en otra región. Si la región en la que se configuraron originalmente experimenta una interrupción, puede que no sea posible anular completamente el registro y volver a registrar el agente. En este documento se supone que los nuevos agentes se registran dentro de una nueva región.

Para usar la plantilla exportada para la recuperación ante desastres, se requieren algunos cambios en la plantilla.

  • En primer lugar, quite todos los recursos Microsoft.StorageMover/agents y Microsoft.HybridCompute/machines de la plantilla. Asegúrese de quitar también las referencias de dependencia a estos recursos.
  • A continuación, quite la propiedad agentResourceId de todas las definiciones de trabajo. Deberá asignarlos a un nuevo agente después de la implementación.
  • Después de eliminar todas las referencias al agente y a los recursos de máquina de Hybrid Compute, actualice la propiedad location del recurso Storage Mover de nivel superior. Reemplace el nombre de la región implementada actualmente por el nombre de la nueva región.
  • Por último, determine si se debe mantener el Id. de recurso de la cuenta de almacenamiento existente. Si es necesario, reemplácelo por otra cuenta de almacenamiento.

Tras completar los pasos anteriores y verificar que los parámetros de la plantilla son correctos, la plantilla está lista para su implementación en una nueva región. Debe desplegar la plantilla en un nuevo grupo de recursos que tenga la misma región predeterminada que la propiedad de ubicación de la plantilla.

Registro del nuevo agente

Siga los pasos descritos en el artículo Implementación de un agente de Azure Storage Mover para registrar un nuevo agente en el nuevo recurso de Storage Mover.

Asignación del agente a definiciones de trabajo

Después de que el nuevo agente se haya registrado e informe de que está en línea, utilice Azure Portal o PowerShell para asociar las definiciones de trabajo existentes al nuevo agente. El siguiente ejemplo de PowerShell se proporciona para mayor comodidad.

Consulte la sección Definir una nueva tarea de migración para saber cómo acceder a las definiciones de tareas de su proyecto.


## Update the agent in a job definition resource
$resourceGroupName  = "[Your resource group name]"
$storageMoverName   = "[Your storage mover name]"
$projectName        = "[Your project name]"
$jobDefName         = "[Your job definition name]"
$agentName          = "[The name of an agent previously registered to the same storage mover resource]"

Update-AzStorageMoverJobDefinition `
    -ResourceGroupName $resourceGroupName `
    -StorageMoverName $storageMoverName `
    -ProjectName $projectName `
    -Name $jobDefName `
    -AgentName $agentName

Conceder acceso al agente al contenedor de almacenamiento de destino

Debe asignar la función de colaborador de datos a la identidad administrada para realizar correctamente un trabajo de migración. Asigne el acceso de identidad administrada por el sistema del recurso informático híbrido al recurso de cuenta de almacenamiento de destino. El artículo Asignación de acceso de identidad administrada a un recurso proporciona instrucciones sobre cómo conceder acceso al recurso de destino.

Ya está listo para iniciar los trabajos de migración utilizando los recursos Storage Mover recién implementados.

Pasos siguientes