Compartilhar via

Recuperação de desastre da Automação do Azure

  • Artigo

Aplica-se a: ✔️ VMs do Linux ✔️ VMs do Windows

Este artigo explica a estratégia de recuperação de desastre para lidar com uma falha em toda uma região ou zona.

Você precisa ter uma estratégia de recuperação de desastre para lidar com uma interrupção de serviço em toda a região ou falha em toda a zona para ajudar a reduzir o impacto e os efeitos decorrentes de eventos imprevisíveis em seus negócios e clientes. Você é responsável por configurar a recuperação de desastre de contas de Automação e dos respectivos recursos dependentes, como Módulos, Conexões, Credenciais, Certificados, Variáveis e Agendamentos. Um aspecto importante de um plano de recuperação de desastre é preparar o failover para a réplica da conta de Automação criada com antecedência na região secundária, caso a conta de Automação na região primária fique indisponível. Verifique se a estratégia de recuperação de desastre considera sua conta de Automação e os recursos dependentes.

Além da alta disponibilidade oferecida pelas zonas de disponibilidade, algumas regiões são emparelhadas com outra região para fornecer proteção contra desastres regionais ou contra grandes desastres geográficos. Independentemente da região primária ter um par regional, a estratégia de recuperação de desastre da conta de Automação permanece a mesma. Saiba mais sobre pares regionais.

Habilitar a recuperação de desastre

Cada conta de Automação que você cria exige um local que você precisa usar para implantação. Essa seria a região primária de sua conta de Automação e inclui ativos, runbooks criados para a conta de Automação, dados de execução de trabalho e logs. Para recuperação de desastre, a conta de Automação de réplica já precisa estar implantada e pronta na região secundária.

  • Comece criando uma conta de Automação de réplica em qualquer região alternativa.
  • Selecione a região secundária de sua escolha – a região emparelhada ou qualquer outra região em que Automação do Azure esteja disponível.
  • Além de criar uma réplica da conta de Automação, replique os recursos dependentes – como Runbooks, Módulos, Conexões, Credenciais, Certificados, Variáveis, Agendamentos – e permissões atribuídas para a conta Executar como e Identidades Gerenciadas na conta de Automação na região primária para a conta de Automação na região secundária. Você pode usar o script do PowerShell para migrar ativos da conta de Automação de uma região para outra.
  • Se estiver usando modelos do ARM para definir e implantar runbooks de Automação, você poderá usar esses modelos para implantar os mesmos runbooks em qualquer outra região do Azure em que criar a conta de Automação de réplica. No caso de uma interrupção em toda a região ou de falha em toda a zona na região primária, você pode executar os runbooks replicados na região secundária para dar continuidade aos negócios como de costume. Isso garante que a região secundária dê continuidade ao trabalho caso a região primária apresente uma interrupção ou falha.

Observação

Devido aos requisitos de residência de dados, os dados de trabalhos e os logs presentes na região primária não ficam disponíveis na região secundária.

Cenários para trabalhos de nuvem e híbridos

Cenário: executar trabalhos de nuvem na região secundária

Para trabalhos de nuvem, haveria tempo de inatividade insignificante, desde que uma conta de Automação de réplica e todos os recursos dependentes e runbooks já estivessem implantados e disponíveis na região secundária. Você pode usar a conta de réplica para executar trabalhos como de costume.

Cenário: executar trabalhos no Hybrid Runbook Worker implantado em uma região diferente da região primária de falha

Se o Hybrid Runbook Worker do Windows ou Linux foi implantado usando a abordagem baseada em extensão em uma região diferente da região primária de falha, siga estas etapas para continuar executando os trabalhos híbridos:

  1. Exclua a extensão instalada no Hybrid Runbook Worker na conta de Automação na região primária.
  2. Adicione o mesmo Hybrid Runbook Worker a um grupo do Hybrid Worker na conta de Automação na região secundária. A extensão do Hybrid Worker é instalada no computador na réplica da conta de Automação.
  3. Execute os trabalhos no Hybrid Runbook Worker criado na Etapa 2.

Para o Hybrid Runbook Worker implantado usando a abordagem baseada em agente, escolha uma opção abaixo:

Se o Hybrid Runbook Worker do Windows foi implantado usando uma abordagem baseada em agente em uma região diferente da região primária de falha, siga as etapas para continuar executando os trabalhos híbridos:

  1. Desinstale o agente do Hybrid Runbook Worker presente na conta de Automação na região primária.
  2. Reinstale o agente no mesmo computador na conta de Automação de réplica na região secundária.
  3. Agora, você pode executar trabalhos no Hybrid Runbook Worker criado na Etapa 2.

Cenário: executar trabalhos no Hybrid Runbook Worker implantado na região primária de falha

Se o Hybrid Runbook Worker foi implantado na região primária e houver uma falha de computação nessa região, o computador não estará disponível para executar trabalhos de Automação. Você precisa provisionar uma nova máquina virtual em uma região alternativa e registrá-la como Hybrid Runbook Worker na conta de Automação na região secundária.

Script para migrar ativos da conta de Automação de uma região para outra

Você pode usar esses scripts para migração de ativos da conta de Automação da conta na região primária para a conta na região secundária. Esses scripts são usados para migrar somente Runbooks, Módulos, Conexões, Credenciais, Certificados e Variáveis. A execução desses scripts não afeta a conta de Automação e os respectivos ativos presentes na região primária.

Pré-requisitos

  1. Verifique se a conta de Automação na região secundária foi criada e está disponível para que os ativos da região primária possam ser migrados para ela. É preferível que a conta de automação de destino não tenha recursos personalizados, pois isso impede possíveis conflitos de recursos devido ao mesmo nome, bem como perda de dados.

  2. Verifique se as identidades gerenciadas atribuídas pelo sistema estão habilitadas na conta de Automação na região primária.

  3. Verifique se as identidades gerenciadas atribuídas pelo sistema da conta de Automação primária têm acesso de colaborador à assinatura à qual ela pertence.

  4. Verifique se a identidade gerenciada da conta de Automação primária tem acesso de Colaborador com permissões de leitura e gravação à conta de Automação na região secundária. Para habilitar, forneça as permissões necessárias nas identidades gerenciadas da conta de Automação secundária. Saiba mais.

  5. Verifique se o script tem acesso aos ativos da conta de Automação na região primária. Portanto, ele deve ser executado como um runbook nessa conta de Automação para uma migração bem-sucedida.

  6. Se a conta de Automação primária foi implantada usando uma conta Executar como, ela precisa ser alternada para a Identidade Gerenciada antes da migração. Saiba mais.

  7. Os módulos necessários são:

    • Az.Accounts versão 2.8.0
    • Az.Resources versão 6.0.0
    • Az.Automation versão 1.7.3
    • Az.Storage versão 4.6.0

  8. Verifique se as contas de Automação de origem e de destino devem pertencer ao mesmo locatário do Microsoft Entra.

Criar e executar o runbook

Você pode usar o script do PowerShell ou o runbook do fluxo de trabalho do PowerShell ou pode importar da galeria de Runbooks e executá-lo para habilitar a migração de ativos de uma conta de Automação para outra.

Siga as etapas para importar e executar o runbook:

  1. Entre no portal do Azure.
  2. Acesse a conta de Automação que deseja migrar para outra região.
  3. Em Automação de Processo, selecione Runbooks.
  4. Selecione Procurar na galeria e, na pesquisa, insira Migrar ativos da conta de Automação de uma região para outra e selecione Script do PowerShell.
  5. Na página Importar um runbook, insira um nome para o runbook.
  6. Selecione Versão do runtime como 5.1 ou 7.1 (versão prévia)
  7. Insira a descrição e selecione Importar.
  8. Na página Editar Runbook do PowerShell, edite os parâmetros necessários e execute-os.

Você pode escolher uma das opções para editar e executar o script. Você pode fornecer os sete parâmetros obrigatórios conforme fornecidos na Opção 1 ou três parâmetros obrigatórios fornecidos na Opção 2 para editar e executar o script.

As opções são:

Nome Obrigatório Descrição
SourceAutomationAccountName Verdadeiro Nome da conta de automação na região primária de onde os ativos precisam ser migrados.
DestinationAutomationAccountName Verdadeiro Nome da conta de automação na região secundária para a qual os ativos precisam ser migrados.
SourceResourceGroup Verdadeiro Nome do grupo de recursos da conta de Automação na região primária.
DestinationResourceGroup Verdadeiro Nome do grupo de recursos da conta de Automação na região secundária.
SourceSubscriptionId Verdadeiro ID da assinatura da conta de Automação na região primária
DestinationSubscriptionId Verdadeiro ID da assinatura da conta de Automação na região secundária.
Tipo[] Verdadeiro Matriz composta por todos os tipos de ativos que precisam ser migrados, os valores possíveis são Certificados, Conexões, Credenciais, Módulos, Runbooks e Variáveis.

Limitações

  • O script migra apenas módulos personalizados do PowerShell. Módulos padrão e pacotes do Python não seriam migrados para a conta de Automação de réplica.
  • O script não migra Agendamentos e Identidades gerenciadas presentes na conta de Automação na região primária. Eles precisariam ser criados manualmente na conta de Automação de réplica.
  • Os logs de atividades e os dados de trabalhos não seriam migrados para a conta de réplica.

Próximas etapas