Recuperação de desastres para a Automação do Azure
Aplica-se a: ✔️ VMs Linux VMs ✔️ Windows
Este artigo explica a estratégia de recuperação de desastres para lidar com uma falha em toda a região ou em toda a região.
Você deve ter uma estratégia de recuperação de desastres 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 sua empresa e clientes. Você é responsável por configurar a recuperação de desastres de contas de automação e seus recursos dependentes, como módulos, conexões, credenciais, certificados, variáveis e agendas. Um aspeto importante de um plano de recuperação de desastres é preparar-se para fazer failover para a réplica da conta de Automação criada antecipadamente na região secundária, se a conta de Automação na região primária ficar indisponível. Certifique-se de que sua estratégia de recuperação de desastres considere 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 geográficos de grande porte. Independentemente de a região principal ter um par regional ou não, a estratégia de recuperação de desastres para a conta de automação permanece a mesma. Para mais informações sobre pares regionais, saiba mais.
Habilite a recuperação de desastres
Cada conta de automação que você cria requer um local que você deve usar para implantação. Essa seria a região principal da sua conta de Automação e inclui Ativos, runbooks criados para a conta de Automação, dados de execução de tarefas e logs. Para recuperação de desastres, a conta de automação de réplica já deve 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 - região emparelhada ou qualquer outra região onde a 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, agendas e permissões atribuídas para a conta Run As 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 você estiver usando modelos ARM para definir e implantar runbooks de Automação, poderá usar esses modelos para implantar os mesmos runbooks em qualquer outra região do Azure onde você criar a conta de Automação de réplica. No caso de uma interrupção em toda a região ou falha em toda a zona na região primária, você pode executar os runbooks replicados na região secundária para continuar os negócios normalmente. Isso garante que a região secundária se aproxime para continuar o trabalho se a região primária tiver uma interrupção ou falha.
Nota
Devido aos requisitos de residência de dados, os dados e logs de trabalhos presentes na região primária não estão disponíveis na região secundária.
Cenários para trabalhos na nuvem e híbridos
Cenário: Executar trabalhos na nuvem na região secundária
Para trabalhos em nuvem, haveria um tempo de inatividade insignificante, desde que uma conta de automação de réplica e todos os recursos e runbooks dependentes já estejam 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 Runbook Worker híbrido implantado em uma região diferente da região primária de falha
Se o Runbook Worker Híbrido do Windows ou Linux for 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:
- Exclua a extensão instalada no Runbook worker híbrido na conta de automação na região primária.
- Adicione o mesmo trabalhador de Runbook Híbrido a um grupo de Trabalhadores Híbridos na conta de Automação na região secundária. A extensão de trabalho híbrido é instalada na máquina na réplica da conta de automação.
- Execute os trabalhos no trabalhador Runbook Híbrido criado na Etapa 2.
Para o Runbook worker híbrido implantado usando a abordagem baseada em agente, escolha uma das opções abaixo:
Se o Runbook Worker Híbrido do Windows for 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 trabalhos Híbridos:
- Desinstale o agente do trabalhador Runbook Híbrido presente na conta de Automação na região primária.
- Reinstale o agente na mesma máquina na conta de automação da réplica na região secundária.
- Agora você pode executar trabalhos no trabalhador Runbook Híbrido criado na Etapa 2.
Cenário: Executar trabalhos no Runbook Worker híbrido implantado na região primária de falha
Se o Runbook Worker Híbrido for implantado na região primária e houver uma falha de computação nessa região, a máquina não estará disponível para executar trabalhos de Automação. Você deve provisionar uma nova máquina virtual em uma região alternativa e registrá-la como Trabalhador de Runbook Híbrido na conta de Automação na região secundária.
- Consulte as etapas de instalação em como implantar um Windows ou Linux User Hybrid Runbook Worker baseado em extensão.
- Consulte as etapas de instalação em como implantar um Windows Hybrid Worker baseado em agente.
- Consulte as etapas de instalação em como implantar um Linux Hybrid Worker baseado em agente.
Script para migrar ativos de conta de automação de uma região para outra
Você pode usar esses scripts para migrar ativos de 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 apenas Runbooks, Módulos, Conexões, Credenciais, Certificados e Variáveis. A execução desses scripts não afeta a conta de automação e seus ativos presentes na região primária.
Pré-requisitos
Certifique-se de que a conta de automação na região secundária esteja criada e disponível para que os ativos da região primária possam ser migrados para ela. É preferível se a conta de automação de destino for uma sem recursos personalizados, pois evita possíveis conflitos de recursos devido ao mesmo nome e perda de dados.
Verifique se as identidades gerenciadas atribuídas ao sistema estão habilitadas na conta de Automação na região primária.
Certifique-se de que as identidades gerenciadas atribuídas ao sistema da conta de automação principal tenham acesso de colaborador à assinatura à qual pertence.
Verifique se a identidade gerenciada da conta de Automação principal tem acesso de Colaborador com permissões de leitura e gravação para a 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. Mais informações.
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.
Se a conta de Automação principal for implantada usando uma conta Run as, ela deverá ser trocada para Identidade Gerenciada antes da migração. Mais informações.
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
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 importar da galeria Runbook 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:
- Inicie sessão no portal do Azure.
- Vá para Conta de automação que você deseja migrar para outra região.
- Em Automação de processos, selecione Runbooks.
- Selecione Procurar galeria e, na pesquisa, insira Migrar ativos de conta de automação de uma região para outra e selecione Script do PowerShell.
- Na página Importar um runbook, insira um nome para o runbook.
- Selecione a versão do tempo de execução como 5.1 ou 7.1 (visualização)
- Insira a descrição e selecione Importar.
- Na página Editar Runbook do PowerShell, edite os parâmetros necessários e execute-o.
Você pode escolher uma das opções para editar e executar o script. Você pode fornecer os sete parâmetros obrigatórios 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 | True | Nome da conta de automação na região primária de onde os ativos precisam ser migrados. |
| DestinationAutomationAccountName | True | Nome da conta de automação na região secundária para a qual os ativos precisam ser migrados. |
| SourceResourceGroup | True | Nome do grupo de recursos da conta de Automação na região primária. |
| DestinationResourceGroup | True | Nome do grupo de recursos da conta de Automação na região secundária. |
| SourceSubscriptionId | True | ID de assinatura da conta de automação na região principal |
| DestinationSubscriptionId | True | ID de assinatura da conta de automação na região secundária. |
| Tipo[] | True | Matriz que consiste em 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 Python não seriam migrados para a conta de automação de réplica.
- O script não migra agendas e identidades gerenciadas presentes na conta de automação na região primária. Eles teriam que ser criados manualmente na conta de automação de réplica.
- Os dados de trabalhos e os logs de atividades não seriam migrados para a conta de réplica.
Próximos passos
- Saiba mais sobre as regiões que suportam zonas de disponibilidade.