Recuperação de desastres com snapshots de ambiente

Esta página descreve como usar snapshots de ambiente para recuperação de desastres.

Definições

Este guia usa as seguintes definições:

• Desastre é um evento em que o Airflow gerenciado ou outros componentes essenciais para a operação do ambiente ficam indisponíveis. Esse evento exige um failover para uma região e ambientes do Airflow gerenciado diferentes. A causa de um desastre pode ser natural ou causada pelo homem, incluindo tempo de inatividade de Cloud de Confiance by S3NS regiões e interrupções na sua própria infraestrutura.
• Recuperação de desastres (DR), no contexto do Airflow gerenciado, é um processo de restauração da operação do ambiente após um desastre. O processo envolve a recriação do ambiente, possivelmente em outra região. Para mais informações sobre a recuperação de desastres, consulte o Guia de planejamento de recuperação de desastres.
• Ambiente principal é um ambiente do Airflow gerenciado para o qual você quer ativar um recurso de DR.
• Ambiente de failover é um ambiente do Airflow gerenciado designado para assumir as atividades do ambiente principal.
• Cenário de DR quente é uma variante da recuperação de desastres em que você usa um ambiente de failover de espera, que é criado antes que um desastre ocorra.
• Cenário de DR frio é uma variante da recuperação de desastres em que você cria um ambiente de failover após a ocorrência de um desastre.
• DR entre regiões é uma variante da recuperação de desastres quente ou fria em que o ambiente principal e o de failover estão localizados em regiões diferentes.

Sobre o procedimento de recuperação de desastres

O procedimento de recuperação de desastres resolve o problema quando o ambiente principal fica inoperante (quebrado ou inacessível) devido a um desastre.

Esse procedimento pressupõe que o ambiente principal não será corrigido no local para resolver o desastre. Em vez disso, você cria um segundo ambiente (de failover) lado a lado. Esse ambiente opera em vez do principal. Em um estágio posterior, você pode decidir voltar ao ambiente principal ou continuar usando o de failover.

Como o procedimento usa um ambiente de failover, as mudanças serão introduzidas quando você mudar do ambiente principal. As mudanças entre o ambiente principal e o de failover incluem (a lista não é abrangente):

• O URL do servidor da Web será diferente. Isso muda o endereço da interface do Airflow e o endpoint de API REST do Airflow.

• O URL do bucket do ambiente será diferente.

• A configuração de permissões de rede e acesso pode exigir ajustes.

Se você usar o cenário de DR quente, saberá os valores do servidor da Web, os endereços do bucket do ambiente e a configuração de rede com antecedência.

Antes de começar

• O banco de dados do Airflow precisa ter menos de 20 GB de dados para criar snapshots.

• O número total de objetos nas pastas /dags, /plugins e /data no bucket do ambiente precisa ser menor que 100.000 para criar snapshots.

• Se você usar o mecanismo XCom para transferir arquivos, certifique-se de que você o use de acordo com as diretrizes do Airflow. A transferência de arquivos grandes ou de um grande número de arquivos usando o XCom afeta a performance do banco de dados do Airflow e pode levar a falhas ao carregar snapshots ou fazer upgrade do ambiente. Considere usar alternativas como o Cloud Storage para transferir grandes volumes de dados.

Visão geral da preparação

Os dois cenários de DR incluem as seguintes etapas de preparação:

1. Crie um ambiente de failover.

   • No cenário de DR quente, você mantém esse ambiente disponível.
   • No cenário de DR frio, você cria esse ambiente apenas para testar o procedimento de recuperação de desastres. Depois de concluir a preparação, exclua esse ambiente e crie-o novamente após um desastre.

2. Crie um bucket para snapshots.

   • O bucket precisa estar disponível na região de DR. Para DR entre regiões, o bucket de snapshots precisa ser multirregional ou estar localizado em uma região diferente do ambiente principal.

   • Verifique se os DAGs podem acessar recursos regionais.

3. Configure a manutenção do banco de dados.

4. Configure snapshots programados.

5. Teste o procedimento de recuperação de desastres.

Visão geral da recuperação de desastres

Depois que um desastre acontece:

1. (Somente DR frio) Crie um ambiente de failover.
2. Se possível, impeça que o ambiente principal execute DAGs.
3. Carregue um snapshot do bucket de snapshots para o ambiente de failover
4. Se necessário, ajuste a configuração do ambiente de failover.
5. Decida o que fazer com o ambiente principal.

Etapas de preparação

Siga as etapas descritas abaixo para configurar a recuperação de desastres para seu ambiente.

Criar um ambiente de failover

Crie um ambiente que funcione como um ambiente de failover.

Siga estas diretrizes:

• O ambiente principal e o de failover precisam usar a mesma versão e build do Airflow.

• No cenário de DR quente, certifique-se de que você atualize e faça upgrade dos dois ambientes em sincronia. Por exemplo, se você fizer upgrade do ambiente principal para um build mais recente do Airflow, ou instalar pacotes PyPI, o ambiente de failover também precisará ter essas mudanças.

• Recomendamos criar o ambiente de failover em uma região diferente do ambiente principal. Como resultado, uma variedade maior de possíveis cenários de desastres pode ser coberta, como um desastre que afeta a disponibilidade de toda a região.

• Recomendamos usar o Terraform para criar ambientes principais e de failover, para que os dois tenham uma configuração consistente. Verifique se as definições do Terraform para ambientes principais e de failover estão sincronizadas.

• Recomendamos que a configuração do ambiente de failover (como tamanho do ambiente, número de programadores e permissões do IAM) esteja em conformidade com a configuração do ambiente principal. As permissões do IAM para os dois ambientes precisam dar acesso adequado a usuários e snapshots.

Verificar a disponibilidade de recursos

Os DAGs podem operar em recursos externos, e o acesso a esses recursos pode depender da configuração do ambiente (como permissões concedidas à conta de serviço do ambiente, configuração de rede ou projeto). Verifique se esses recursos estão disponíveis para o ambiente de failover.

Um ambiente pode interagir com alguns recursos externos por meio de conexões armazenadas no Airflow. Verifique se esses recursos precisam ser ajustados no ambiente de failover em comparação com o ambiente principal.

Criar um bucket de armazenamento para snapshots

Crie um novo bucket de armazenamento para snapshots de ambiente. Não use buckets de ambiente para recuperação de desastres, já que a configuração da política de retenção e do ciclo de vida é aplicada no nível do bucket.

Verifique se esse bucket de armazenamento tem permissões do IAM, uma política de retenção e uma configuração de ciclo de vida definidas de maneira a evitar exclusão acidental ou acesso não autorizado. Para mais informações sobre como configurar um bucket para snapshots, consulte Como configurar snapshots programados.

Você pode:

• Criar um bucket em uma região diferente.
• Criar um bucket multirregional.

Configurar a manutenção do banco de dados

Mantenha o banco de dados do Airflow pequeno e dentro do limite de tamanho configurando a limpeza do banco de dados. Isso acelera o processo de salvar e carregar snapshots. O banco de dados do Airflow precisa ter menos de 20 GB de dados para criar snapshots.

Configurar snapshots programados

Configure snapshots programados para o ambiente principal.

Os snapshots só podem ser criados em um ambiente íntegro. Portanto, eles precisam ser salvos antes que o desastre ocorra.

Para mais informações sobre como os snapshots funcionam, consulte Salvar e carregar snapshots de ambiente. Consulte a seção Salvar um snapshot de ambiente da documentação para saber onde encontrar os snapshots salvos.

(Opcional) Configurar o monitoramento de operações de snapshot programadas

Para snapshots programados com uma frequência de pelo menos uma vez a cada 12 horas, você pode usar o Cloud Monitoring para receber alertas quando um snapshot não for criado automaticamente.

Para programações de frequência mais baixa, use a Google Cloud CLI para verificar os resultados das operações de snapshot. Consulte Verificar operações de snapshot de salvamento.

1. No Cloud de Confiance console do, acesse a página Monitoring.

   Acessar Monitoring

2. No painel de navegação do Monitoring, selecione notifications Alertas:
3. Se você não tiver criado seus canais de notificação e quiser receber uma notificação, clique em Editar canais de notificação e adicione-os. Retorne para a página Alertas depois de adicionar seus canais.
4. Na página Alertas, clique em Criar política.
5. Para selecionar a métrica, expanda o menu Selecionar uma métrica e faça isto:
   1. Para limitar o menu a entradas relevantes, insira Composer Snapshot na barra de filtros. Se não houver resultados depois de filtrar o menu, desative a opção Mostrar somente recursos e métricas ativos.
   2. Em Tipo de recurso, selecione Ambiente do Cloud Composer.
   3. Em Categoria da métrica, selecione Ambiente.
   4. Em Métrica, selecione Contagem de criação de snapshots.
   5. Selecione Apply.
6. Clique em Adicionar filtro e use os menus suspensos para adicionar os seguintes filtros:

   Filtro	Comparador	Valor
   Rótulo do recurso > environment_name	=	O nome do ambiente em que você quer monitorar snapshots programados.
   Rótulo do monitor > resultado	=	SUCCEEDED

7. Na seção Transformar dados, defina os seguintes atributos:
   • Em Janela contínua, selecione a janela de monitoramento para esse alerta. Esse valor afeta a configuração de limite na próxima etapa.

     Valor recomendado para monitoramento de snapshots programados: 1 dia.

   • Em Função de janela contínua, selecione delta.
8. Clique em Próxima.
9. As configurações da página Configurar acionador de alertas determinam quando o alerta é acionado. Preencha esta página com as configurações na tabela a seguir.
   

   Campo	Valor
   Condition type	Threshold
   Alert trigger	Any time series violates
   Threshold position	Below threshold
   Threshold value	O número de snapshots programados que você espera que sejam salvos dentro do período configurado como a Janela contínua para o alerta. Calcule esse valor usando a seguinte fórmula: (rolling window in hours / schedule frequency in hours) - 1 Observação:a dedução de 1 hora na fórmula é para considerar os tempos de conclusão de snapshots variáveis. Isso ajuda a evitar falsos positivos se o snapshot mais recente ainda estiver em execução durante uma verificação de monitoramento. Exemplo: Se você usar a janela contínua recomendada de 1 dia, e a frequência da programação for uma vez a cada 2 horas, defina esse valor como 11 (de acordo com o cálculo: 24 / 2 - 1 = 11). Se a programação for executada corretamente, você terá pelo menos 11 snapshots em qualquer janela de 24 horas. Se não, isso significa que uma operação de snapshot não foi concluída com êxito e o Cloud Monitoring aciona esse alerta.
   Condition name	Seu nome personalizado para a condição.

10. Clique em Próxima.
11. Opcional: para adicionar notificações à sua política de alertas, clique em Canais de notificação. Na caixa de diálogo, selecione um ou mais canais de notificação no menu e clique em OK.
12. Opcional: Atualize a Duração do fechamento automático do incidente. Este campo determina quando o Monitoring fecha incidentes na ausência de dados de métrica.
13. Opcional: clique em Documentação e adicione as informações que quer incluir em uma mensagem de notificação.
14. Clique em Nome e digite um nome para a política de alertas.
15. Clique em Criar política.

Testar o procedimento de recuperação de desastres

Teste o procedimento de recuperação de desastres depois de configurá-lo e, em seguida, periodicamente. Isso permite resolver possíveis problemas que possam afetar o processo real de recuperação de desastres.

No cenário de DR frio, você pode excluir o ambiente de failover depois de terminar de testar o procedimento de recuperação de desastres.

Verificar operações de snapshot de salvamento

Você pode usar a Google Cloud CLI para recuperar a lista de operações de snapshot de salvamento e verificar se os snapshots estão prontos para cenários de recuperação de desastres.

Esse método é útil se você salvar snapshots com menos frequência do que pelo menos uma vez a cada 12 horas. Para verificar snapshots salvos com mais frequência, é melhor configurar alertas do Cloud Monitoring. Consulte Configurar o monitoramento de operações de snapshot programadas.

gcloud composer operations list \
    --locations LOCATION \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND 
    metadata.resource=projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_ID"
    --format yaml

gcloud composer operations list \
    --locations us-central1 \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND 
    metadata.resource=projects/my-project/locations/us-central1/environments/my-environment"
    --format yaml

Depois que um desastre acontece

Siga as etapas descritas abaixo depois que um desastre acontecer para recuperar o ambiente principal.

(Somente DR frio) Criar um ambiente de failover

Siga as instruções na seção Criar um ambiente de failover.

Impedir que o ambiente principal execute DAGs

Se possível, impeça que o ambiente principal execute DAGs:

• Se o ambiente principal ainda estiver acessível, pause todos os DAGs.
• Se o bucket do ambiente principal estiver acessível, mova todos os DAGs do bucket do ambiente ou para uma pasta fora de /dags no bucket do ambiente principal.

Carregar um snapshot para o ambiente de failover

Carregue um snapshot do ambiente principal para o ambiente de failover.

Depois que o snapshot é carregado no ambiente de failover, ele programa e executa tarefas como se nada tivesse sido executado pelo ambiente principal após a criação de um snapshot. No entanto, algumas dessas tarefas já podem ter sido executadas pelo ambiente principal. O ambiente de failover não tem como reconhecer quais tarefas foram executadas após a criação do snapshot e antes de um desastre. Como resultado, algumas tarefas podem ser executadas duas vezes (no ambiente principal e no de failover). Recomendamos que todas as tarefas sejam idempotentes e que os snapshots programados sejam criados a cada duas horas.

(Se necessário) Ajustar a configuração do ambiente de failover

Em alguns casos, talvez seja necessário mudar a configuração do ambiente de failover depois de carregar o snapshot do ambiente principal nele.

Por exemplo, em um cenário de DR frio, talvez seja necessário usar um conjunto diferente de variáveis de ambiente do Airflow no ambiente de failover. Como outro exemplo, em um cenário de DR quente, talvez seja necessário conceder permissões aos usuários na interface do Airflow para que eles possam acessar o ambiente de failover.

Você pode fazer essas mudanças manualmente ou preparar um script de shell com comandos que mudam a configuração do ambiente de failover executando gcloud composer environment update comandos.

Decidir o que fazer com o ambiente principal

Alguns desastres podem acontecer porque o ambiente principal não está acessível, mas ainda está operacional ou não funciona corretamente. Por exemplo, não é possível acessar o ambiente principal pela rede devido a uma falha de infraestrutura. Como outro exemplo, o ambiente opera com alguns erros ou com capacidade reduzida, mas alguns DAGs ainda são executados.

Se o ambiente original ainda estiver em execução, ele poderá gerar custos diretamente relacionados ao Airflow gerenciado ou a outros serviços acessados pelos DAGs, mesmo que um novo ambiente tenha sido criado como substituto. Esse ambiente ainda pode executar alguns DAGs. Como resultado, algumas operações podem ser executadas duas vezes: no ambiente principal que ainda está em execução e no ambiente de failover após o carregamento do snapshot.

Se o ambiente principal existir, mas não funcionar corretamente

O ambiente principal pode ser excluído se todos os dados relevantes forem recuperados. Por exemplo, talvez seja necessário recuperar dados que não estão incluídos nos snapshots do ambiente, como configuração de rede ou conteúdo do bucket do ambiente fora das pastas /dags e /plugins.

Se o ambiente principal ficar acessível e íntegro novamente

Se o ambiente principal ficou inacessível apenas temporariamente e ficou acessível e íntegro novamente, você pode escolher uma abordagem:

• Continue usando o ambiente de failover.
• Retorne ao ambiente principal.

Para continuar usando o ambiente de failover:

1. Se o ambiente principal ainda executar DAGs, pause-os o mais rápido possível.
2. Verifique se todos os dados relevantes foram recuperados e exclua o ambiente principal.
3. Repita as etapas de preparação de DR para o ambiente de failover, como configurar snapshots programados.

Para retornar ao ambiente principal:

1. Pause todos os DAGs no ambiente de failover.
2. Aguarde a conclusão de todas as execuções de DAG no ambiente de failover ou interrompa-as.
3. Salve um snapshot do ambiente de failover.
4. Carregue esse snapshot para o ambiente principal.
5. Retome os DAGs no ambiente principal.
6. Se necessário, exclua o ambiente de failover.

A seguir

• Configurar snapshots programados
• Criar ambientes