Recuperação de desastres com snapshots do ambiente

Cloud Composer 1 | Cloud Composer 2

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

Definições

Neste guia, usamos as seguintes definições:

• Desastre é um evento em que o Cloud Composer ou outros componentes essenciais para a operação do seu ambiente ficam indisponíveis. Esse evento requer um failover para uma região e ambientes do Cloud Composer diferentes. A causa de um desastre pode ser natural ou causada por humanos, incluindo a inatividade nas regiões do Google Cloud e as interrupções na própria infraestrutura.
• A recuperação de desastres (DR), no contexto do Cloud Composer, é 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.
• O ambiente principal é um ambiente do Cloud Composer para o qual você quer ativar um recurso de DR.
• O ambiente de failover é um ambiente do Cloud Composer designado para assumir as atividades do ambiente principal.
• O cenário de DR com estado salvo é uma variante da recuperação de desastres, em que você usa um ambiente de failover em espera, criado antes da ocorrência de um desastre.
• O 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.
• A DR entre regiões é uma variante da recuperação de desastres com estado salvo ou frio 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 se torna inoperante (corrompido ou inacessível) devido a um desastre.

Este procedimento pressupõe que seu ambiente principal não será corrigido no local para lidar com o desastre. Em vez disso, crie um segundo ambiente lado a lado. Esse ambiente opera em vez do ambiente principal. Posteriormente, é possível voltar para o ambiente principal ou continuar usando o ambiente de failover.

Como o procedimento usa um ambiente de failover, alterações serão introduzidas quando você alternar do ambiente principal. Veja a seguir algumas alterações entre o ambiente principal e o de failover (a lista não é abrangente):

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

• O URL do bucket do ambiente será diferente.

• Talvez seja preciso ajustar a configuração de permissões de rede e acesso.

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

Antes de começar

• O Cloud Composer é compatível com snapshots programados nas versões 2.0.32 e posteriores. Os snapshots do ambiente são compatíveis com as versões 2.0.9 e posteriores.

Visão geral da preparação

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

1. Crie um ambiente de failover.

   • No cenário de DR com estado salvo, mantenha 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, você exclui esse ambiente e o cria 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 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

Após um desastre:

1. (Apenas 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 abaixo para configurar a recuperação de desastres no ambiente.

Criar um ambiente de failover

Crie um ambiente que atue como um ambiente de failover.

Siga estas diretrizes:

• Os ambientes principal e de failover precisam usar a mesma versão do Cloud Composer e do Airflow.

  Cuidado: não realize um failover para uma versão mais recente do Cloud Composer ou do Airflow, porque isso pode exigir outras alterações relacionadas à compatibilidade.

• No cenário de DR em estado salvo, atualize e faça upgrade dos dois ambientes em sincronia. Por exemplo, se você fizer upgrade do ambiente principal para uma versão posterior do Cloud Composer ou instalar pacotes PyPI, seu ambiente de failover também precisará ter essas alterações.

• Recomendamos a criação do ambiente de failover em uma região diferente do ambiente principal. Assim, é possível abordar uma gama mais ampla de possíveis cenários de desastre, como um desastre que afeta a disponibilidade de toda a região.

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

• A configuração do ambiente de failover (como tamanho do ambiente, número de programadores e permissões do IAM) é recomendada para estar em conformidade com a configuração do ambiente principal. As permissões do IAM para ambos os ambientes precisam conceder acesso apropriado a usuários e snapshots.

Verificar a disponibilidade do recurso

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, à configuração de rede ou ao projeto do ambiente. 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.

Crie um bucket de armazenamento para snapshots

Crie um novo bucket de armazenamento para snapshots do 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 definida de modo a impedir exclusões acidentais ou acessos não autorizados. Para mais informações sobre como configurar um bucket para snapshots, consulte Como configurar snapshots programados.

É possível:

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

Cuidado: se você criar um bucket na mesma região do ambiente principal, não será possível cobrir alguns cenários de desastre, como um desastre que afeta a disponibilidade de toda a região.

Configurar a manutenção do banco de dados

Execute o DAG de manutenção do banco de dados para manter o banco de dados de metadados do Airflow pequeno. Isso acelera o processo de salvar e carregar snapshots. O banco de dados de metadados do Airflow precisa ter menos de 20 GB de dados para aceitar 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 do ambiente. Consulte a seção Salvar um snapshot do ambiente da documentação para saber onde encontrar os snapshots salvos.

Observação: os limites de cota permitem até 52 operações de salvamento de snapshot por dia para um único ambiente. Se você quiser que os snapshots programados sejam tirados em intervalos regulares, o intervalo entre eles precisa ser de pelo menos 30 minutos.

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

Para snapshots programados com frequência de pelo menos uma vez a cada 12 horas, é possível usar o Cloud Monitoring para alertar quando um snapshot não for criado automaticamente.

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

1. No Console do Google Cloud, acesse a página Monitoring.

   Acessar Monitoring

2. No painel de navegação do Monitoring, selecione  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. Volte 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 o seguinte:
   1. Para limitar o menu a entradas relevantes, insira Composer Snapshot na barra de filtro. 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:

   Filtrar	Comparador	Valor
   Rótulo do recurso > Environment_name	=	O nome do ambiente em que você quer monitorar snapshots programados.
   Monitorar rótulo > resultado	=	SUCCEEDED

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

     Valor recomendado para monitoramento de snapshot programado: 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 da 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 serão salvos no período configurado como a Janela contínua do alerta. Calcule esse valor usando a seguinte fórmula: (rolling window in hours / schedule frequency in hours) - 1 Observação:deduzir 1 hora na fórmula leva em conta os tempos variados de conclusão do snapshot. Isso ajuda a evitar a geração de 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 duas horas, defina esse valor como 11 (conforme 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 você não fizer isso, uma operação de snapshot não foi concluída 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.

Para mais informações, consulte Políticas de alertas.

Testar o procedimento de recuperação de desastres

Teste o procedimento de recuperação de desastres depois de configurá-lo e depois periodicamente. Isso permite que você resolva possíveis problemas que podem afetar o processo real de recuperação de desastres.

No cenário de DR frio, é possível excluir o ambiente de failover depois de terminar de testar o procedimento de recuperação de desastres.

Verificar operações de salvamento de snapshot

É possível usar a Google Cloud CLI para recuperar a lista de operações de salvar snapshot 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 Como configurar o monitoramento de operações de snapshot programadas.

gcloud

Liste todas as suas operações de snapshot para um ambiente específico. Para ver a referência completa de comandos, consulte gcloud composer Operations list.

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

Substitua:

• LOCATIONS pela lista de identificadores de região em que o ambiente está localizado;
• PROJECT_ID pelo identificador do projeto em que o ambiente está localizado
• ENVIRONMENT_ID pelo identificador do ambiente em que você quer verificar as operações de snapshot

Exemplo:

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

Após um desastre

Siga as etapas descritas abaixo após um desastre para recuperar seu ambiente principal.

(Apenas DR frio) Criar um ambiente de failover

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

Interromper a execução de DAGs pelo ambiente principal

Se possível, interrompa a execução de DAGs no ambiente principal:

• 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 no ambiente de failover

Carregue um snapshot do ambiente principal no 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 do snapshot. No entanto, algumas dessas tarefas já podem ter sido executadas pelo ambiente principal. O ambiente de failover não tem nenhum meio para reconhecer quais tarefas foram executadas depois de criar o 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, convém alterar 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 com estado salvo, talvez seja necessário conceder permissões aos usuários na IU do Airflow para que eles possam acessar o ambiente de failover.

É possível realizar essas alterações manualmente ou preparar um script de shell com comandos que alteram a configuração do ambiente de failover executando comandos gcloud composer environment update.

Decidir o que fazer com o ambiente principal

Alguns desastres podem acontecer porque o ambiente principal não é acessível, mas ainda opera ou não opera corretamente. Por exemplo, não é possível acessar o ambiente principal pela rede devido a uma falha na 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 Cloud Composer ou a outros serviços acessados por meio dos 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 existe, mas não funciona corretamente

O ambiente principal poderá ser excluído se todos os dados relevantes tiverem sido recuperados. Por exemplo, talvez você queira recuperar dados não incluídos nos snapshots do ambiente, como a configuração de rede ou o conteúdo do bucket do ambiente fora das pastas /dags e /plugins.

Se o ambiente principal se tornar acessível e íntegro novamente

Se o ambiente principal estiver inacessível apenas temporariamente e se tornar acessível e íntegro novamente, escolha uma abordagem:

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

Para continuar usando o ambiente de failover:

1. Se o ambiente principal ainda executar DAGs, pause-os assim que 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. Pausar 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 este snapshot no 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