Compartir a través de

Recuperación ante desastres para Azure Automation

  • Artículo

Se aplica a: ✔️ Máquinas virtuales Linux ✔️ Máquinas virtuales Windows

En este artículo se explica la estrategia de recuperación ante desastres para controlar un error en toda la región o en toda la zona.

Debe tener una estrategia de recuperación ante desastres para controlar una interrupción del servicio en toda la región o un error en toda la zona para ayudar a reducir el impacto y los efectos derivados de eventos imprevisibles en su empresa y clientes. Usted es responsable de configurar la recuperación ante desastres de las cuentas de Automation y sus recursos dependientes, como módulos, conexiones, credenciales, certificados, variables y programaciones. Un aspecto importante de un plan de recuperación ante desastres es preparar la conmutación por error a la réplica de la cuenta de Automation creada de antemano en la región secundaria, si la cuenta de Automation de la región primaria deja de estar disponible. Asegúrese de que la estrategia de recuperación ante desastres tenga en cuenta la cuenta de Automation y los recursos dependientes.

Además de la alta disponibilidad que ofrecen las zonas de disponibilidad, algunas regiones se emparejan con otra región para proporcionar protección frente a desastres geográficos grandes o regionales. Independientemente de si la región primaria tiene un par regional o no, la estrategia de recuperación ante desastres para la cuenta de Automation sigue siendo la misma. Para más información sobre los pares regionales, haga clic aquí.

Habilitación de la recuperación ante desastres

Cada cuenta de Automation que cree requiere una ubicación que se debe usar para la implementación. Esta sería la región primaria de la cuenta de Automation e incluye activos, runbooks creados para la cuenta de Automation, datos de ejecución de trabajos y registros. Para la recuperación ante desastres, la cuenta de Automation de réplica debe estar ya implementada y lista en la región secundaria.

  • Empiece por crear una cuenta de Automation de réplica en cualquier región alternativa.
  • Seleccione la región secundaria de su elección: región emparejada o cualquier otra región en la que esté disponible Azure Automation.
  • Además de crear una réplica de la cuenta de Automation, replique los recursos dependientes (como runbooks, módulos, conexiones, credenciales,certificados, variables, programaciones y permisos asignados para la cuenta de ejecución e identidades administradas) de la cuenta de Automation en la región primaria a la cuenta de Automation en la región secundaria. Puede usar el script de PowerShell para migrar recursos de la cuenta de Automation de una región a otra.
  • Si usa plantillas de ARM para definir e implementar runbooks de Automation, puede usar estas plantillas para implementar los mismos runbooks en cualquier otra región de Azure donde cree la cuenta de Automation de réplica. En el caso de una interrupción de toda la región o un error en toda la zona en la región primaria, puede ejecutar los runbooks replicados en la región secundaria para que sigan funcionando de la forma habitual. Esto garantiza que la región secundaria siga el trabajo si la región primaria tiene una interrupción o un error.

Nota:

Debido a los requisitos de residencia de datos, los datos de trabajos y los registros presentes en la región primaria no están disponibles en la región secundaria.

Escenarios para trabajos híbridos y en la nube

Escenario: Ejecución de trabajos en la nube en la región secundaria

En el caso de los trabajos en la nube, habría un tiempo de inactividad insignificante, siempre que una cuenta de Automation de réplica y todos los recursos y runbooks dependientes ya estén implementados y disponibles en la región secundaria. Puede usar la cuenta de réplica para ejecutar trabajos como de costumbre.

Escenario: Ejecución de trabajos en Hybrid Runbook Worker implementados en una región diferente de la región primaria de error

Si Hybrid Runbook Worker de Windows o Linux se implementa mediante el enfoque basado en extensiones en una región diferente de la región primaria de error, siga estos pasos para continuar ejecutando los trabajos híbridos:

  1. Elimine la extensión instalada en Hybrid Runbook Worker en la cuenta de Automation de la región primaria.
  2. Agregue la misma instancia de Hybrid Runbook Worker a un grupo de Hybrid Worker en la cuenta de Automation de la región secundaria. La extensión de trabajador de Hybrid se instala en la máquina de la réplica de la cuenta de Automation.
  3. Ejecute los trabajos en la instancia de Hybrid Runbook Worker creada en el paso 2.

Para la instancia de Hybrid Runbook Worker implementada mediante el enfoque basado en agente, elija entre los siguientes:

Si Hybrid Runbook Worker de Windows se implementa mediante un enfoque basado en agente en una región diferente de la región primaria de error, siga los pasos para continuar ejecutando trabajos híbridos:

  1. Desinstale el agente de Hybrid Runbook Worker presente en la cuenta de Automation en la región primaria.
  2. Vuelva a instalar el agente en la misma máquina de la cuenta de Automation de réplica en la región secundaria.
  3. Ahora puede ejecutar trabajos en la instancia de Hybrid Runbook Worker creada en el paso 2.

Escenario: Ejecución de trabajos en la instancia de Hybrid Runbook Worker implementada en la región primaria de error

S Hybrid Runbook Worker se implementa en la región primaria y hay un error de proceso en esa región, la máquina no estará disponible para ejecutar trabajos de Automation. Debe aprovisionar una nueva máquina virtual en una región alternativa y registrarla como Hybrid Runbook Worker en la cuenta de Automation en la región secundaria.

Script para migrar recursos de cuenta de Automation de una región a otra

Puede usar estos scripts para la migración de recursos de cuenta de Automation desde la cuenta de la región primaria a la cuenta de la región secundaria. Estos scripts se usan para migrar solo runbooks, módulos, conexiones, credenciales, certificados y variables. La ejecución de estos scripts no afecta a la cuenta de Automation y sus recursos presentes en la región primaria.

Requisitos previos

  1. Asegúrese de que la cuenta de Automation en la región secundaria se crea y está disponible para que los recursos de la región primaria se puedan migrar a ella. Se prefiere si la cuenta de automatización de destino es una sin recursos personalizados, ya que evita posibles conflictos de recursos debido al mismo nombre y a pérdida de datos.

  2. Asegúrese de que las identidades administradas asignadas por el sistema están habilitadas en la cuenta de Automation de la región primaria.

  3. Asegúrese de que las identidades administradas asignadas por el sistema de la cuenta de Automation principal tienen acceso de colaborador a la suscripción a la que pertenece.

  4. Asegúrese de que la identidad administrada de la cuenta de Automation principal tenga acceso de colaborador con permisos de lectura y escritura a la cuenta de Automation en la región secundaria. Para habilitarla, proporcione los permisos necesarios en las identidades administradas de la cuenta de Automation secundaria. Más información.

  5. Asegúrese de que el script tiene acceso a los recursos de la cuenta de Automation en la región primaria. Por lo tanto, se debe ejecutar como un runbook en esa cuenta de Automation para llevar a cabo una migración correcta.

  6. Si la cuenta de Automation principal se implementa mediante una cuenta de ejecución, debe cambiarse a Identidad administrada antes de la migración. Más información.

  7. Los módulos necesarios son:

    • Az.Accounts (versión 2.8.0)
    • Az.Resources (versión 6.0.0)
    • Az.Automation (versión 1.7.3)
    • Az.Storage (versión 4.6.0)

  8. Asegúrese de que las cuentas de Automation de origen y destino pertenezcan al mismo inquilino de Microsoft Entra.

Creación y ejecución del runbook

Puede usar el script de PowerShell o el runbook de flujo de trabajo de PowerShell o importarlo desde la galería de Runbook y ejecutarlo para habilitar la migración de recursos de una cuenta de Automation a otra.

Siga los pasos para importar y ejecutar el runbook:

  1. Inicie sesión en Azure Portal.
  2. Vaya a la cuenta de Automation que desea migrar a otra región.
  3. En Automatización de procesos, seleccione Runbooks.
  4. Seleccione Examinar galería y, en la búsqueda, escriba Migrar recursos de cuenta de Automation de una región a otra y seleccione Script de PowerShell.
  5. En la página Importar un runbook, escriba un nombre para el runbook.
  6. Seleccione Versión del motor en tiempo de ejecución como 5.1 o 7.1 (versión preliminar)
  7. Escriba la descripción y seleccione Importar.
  8. En la página Editar runbook de PowerShell, edite los parámetros necesarios y ejecútelo.

Puede elegir cualquiera de las opciones para editar y ejecutar el script. Puede proporcionar los siete parámetros obligatorios como se indica en la opción 1 o tres parámetros obligatorios proporcionados en la opción 2 para editar y ejecutar el script.

Las opciones son:

Nombre Obligatorio Descripción
SourceAutomationAccountName True Nombre de la cuenta de Automation en la región primaria desde donde se deben migrar los recursos.
DestinationAutomationAccountName True Nombre de la cuenta de Automation en la región secundaria a la que se deben migrar los recursos.
SourceResourceGroup True Nombre del grupo de recursos de la cuenta de Automation en la región primaria.
DestinationResourceGroup True Nombre del grupo de recursos de la cuenta de Automation en la región secundaria.
SourceSubscriptionId True Identificador de suscripción de la cuenta de Automation en la región primaria
DestinationSubscriptionId True Identificador de suscripción de la cuenta de Automation en la región secundaria.
Tipo[] True Matriz que consta de todos los tipos de recursos que deben migrarse, los valores posibles son Certificados, Conexiones, Credenciales, Módulos, Runbooks y Variables.

Limitaciones

  • El script solo migra módulos de PowerShell personalizados. Los módulos predeterminados y los paquetes de Python no se migrarían a la cuenta de Automation de réplica.
  • El script no migra programaciones e identidades administradas presentes en la cuenta de Automation en la región primaria. Estos tendrían que crearse manualmente en la cuenta de Automation de réplica.
  • Los datos de trabajos y los registros de actividad no se migrarían a la cuenta de réplica.

Pasos siguientes