A 15 de setembro de 2026, todos os ambientes do Cloud Composer 1 e do Cloud Composer 2 versão 2.0.x vão atingir o fim da vida útil planeado e não vai poder usá-los. Recomendamos que planeie a migração para o Cloud Composer 3.

Esta página foi traduzida pela API Cloud Translation.

Recuperação de desastres com instantâneos do ambiente

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Esta página descreve como usar as capturas instantâneas do ambiente para a recuperação de desastres.

Definições

Este guia usa as seguintes definições:

Desastre é um evento em que o Cloud Composer ou outros componentes essenciais para o funcionamento do seu ambiente estão indisponíveis. Este evento requer uma comutação por falha para uma região diferente e ambientes do Cloud Composer. A causa de um desastre pode ser natural ou provocada pelo homem, incluindo o tempo de inatividade das regiões Google Cloud e as falhas na sua própria infraestrutura.
A recuperação de desastres (RD), no contexto do Cloud Composer, é um processo de restauro do funcionamento do ambiente após um desastre. O processo envolve recriar o ambiente, possivelmente noutra região. Para mais informações acerca da recuperação de desastres, consulte o Guia de planeamento de recuperação de desastres.
O ambiente principal é um ambiente do Cloud Composer para o qual quer ativar uma capacidade de DR.
O ambiente de failover é um ambiente do Cloud Composer designado para assumir as atividades do ambiente principal.
O cenário de recuperação de desastres (RD) a quente é uma variante da recuperação de desastres, em que usa um ambiente de comutação por falha em espera, que cria antes de ocorrer um desastre.
O cenário de recuperação de desastres a frio é uma variante da recuperação de desastres, em que cria um ambiente de comutação por falha após a ocorrência de um desastre.
A recuperação de desastres entre regiões é uma variante da recuperação de desastres a quente ou a frio em que o ambiente principal e o ambiente de alternativa estão localizados em regiões diferentes.

Acerca do procedimento de recuperação de desastres

O procedimento de recuperação de desastres resolve o problema quando o seu ambiente principal se torna inoperacional (danificado ou inacessível) devido a um desastre.

Este procedimento pressupõe que o seu ambiente principal não vai ser corrigido no local para resolver o desastre. Em alternativa, crie um segundo ambiente (de alternativa) lado a lado. Este ambiente funciona em vez do ambiente principal. Numa fase posterior, pode decidir voltar ao ambiente principal ou continuar a usar o ambiente de alternativa.

Uma vez que o procedimento usa um ambiente de comutação por falha, as alterações são introduzidas quando muda do ambiente principal. As alterações entre o ambiente principal e o ambiente de alternativa incluem (a lista não é exaustiva):

O URL do servidor Web vai ser diferente. Isto altera o endereço da IU do Airflow e o ponto final da API REST do Airflow.
O URL do contentor do ambiente vai ser diferente.
A configuração das autorizações de acesso e de rede pode ter de ser ajustada.

Se usar o cenário de recuperação de desastres (RD) parcial, conhece os valores do servidor Web, os endereços dos contentores do ambiente e a configuração de rede antecipadamente.

Antes de começar

A base de dados do Airflow tem de ter menos de 20 GB de dados para criar instantâneos.
O número total de objetos nas pastas /dags, /plugins e /data no contentor do ambiente tem de ser inferior a 100 000 para criar instantâneos.
Se usar o mecanismo XCom para transferir ficheiros, certifique-se de que o usa de acordo com as diretrizes do Airflow. A transferência de ficheiros grandes ou de um grande número de ficheiros através do XCom afeta o desempenho da base de dados do Airflow e pode originar falhas ao carregar instantâneos ou atualizar o seu ambiente. Considere usar alternativas, como o Cloud Storage, para transferir grandes volumes de dados.

Vista geral da preparação

Ambos os cenários de recuperação de desastres incluem os seguintes passos de preparação:

Crie um ambiente de alternativa.
- No cenário de recuperação de desastres (RD) quente, mantém este ambiente disponível.
- No cenário de recuperação de desastres a frio, cria este ambiente apenas para testar o seu procedimento de recuperação de desastres. Depois de concluir a preparação, pode eliminar este ambiente e criá-lo novamente após a ocorrência de um desastre.
Crie um contentor para instantâneos.
- O contentor tem de estar disponível na região de recuperação de desastres. Para a recuperação de desastres entre regiões, o contentor de instantâneos tem de ser multirregional ou estar localizado numa região diferente do ambiente principal.
- Verifique se os DAGs podem aceder a recursos regionais.
Configure a manutenção da base de dados.
Configure capturas de ecrã programadas.
Teste o procedimento de recuperação de desastres.

Vista geral da recuperação de desastres

Após a ocorrência de um desastre:

(Apenas para recuperação de desastres a frio) Crie um ambiente de comutação por falha.
Se possível, impedir que o ambiente principal execute DAGs.
Carregue um instantâneo do contentor de instantâneos para o ambiente de failover.
Se necessário, ajuste a configuração do ambiente de comutação por falha.
Decida o que fazer com o ambiente principal.

Passos de preparação

Siga os passos descritos abaixo para configurar a recuperação de desastres para o seu ambiente.

Crie um ambiente de alternativa

Crie um ambiente que funcione como um ambiente de alternativa.

Siga as diretrizes seguintes:

O ambiente principal e de ativação pós-falha tem de usar a mesma versão e compilação do Airflow.

Atenção: embora seja possível fazê-lo, não faça uma comutação por falha para uma versão ou uma compilação diferente do Airflow, uma vez que isto pode exigir alterações adicionais relacionadas com a compatibilidade. Por exemplo, duas compilações da mesma versão do Airflow podem ter pacotes PyPI pré-instalados diferentes.
No cenário de recuperação de desastres (RD) a quente, certifique-se de que atualiza e atualiza ambos os ambientes em sincronia. Por exemplo, se atualizar o ambiente principal para uma compilação do Airflow posterior ou instalar pacotes PyPI, o ambiente de comutação por falha também tem de ter estas alterações.
Recomendamos que crie o ambiente de alternativa numa região diferente do ambiente principal. Como resultado, é possível abranger uma gama mais ampla de possíveis cenários de desastres, como um desastre que afete a disponibilidade de toda a região.
Recomendamos que use o Terraform para criar ambientes principais e de comutação por falha, de modo que ambos tenham uma configuração consistente. Certifique-se de que as definições do Terraform para os ambientes principal e de alternativa estão sincronizadas.
Recomendamos que a configuração do ambiente de alternativa (como a dimensão do ambiente, o número de programadores e as autorizações da IAM) esteja em conformidade com a configuração do ambiente principal. As autorizações da IAM para ambos os ambientes têm de dar acesso adequado aos utilizadores e às imagens instantâneas.

Verifique a disponibilidade dos recursos

Os DAGs podem operar em recursos externos, e o acesso a esses recursos pode depender da configuração do ambiente (como autorizações concedidas à conta de serviço, à configuração de rede ou ao projeto do ambiente). Certifique-se de que esses recursos estão disponíveis para o ambiente de comutação por falha.

Um ambiente pode interagir com alguns recursos externos através de ligações armazenadas no Airflow. Verifique se estes recursos devem ser ajustados no ambiente de alternativa em comparação com o ambiente principal.

Crie um contentor de armazenamento para instantâneos

Crie um novo contentor de armazenamento para instantâneos do ambiente. Não use contentores de ambiente para recuperação de desastres, uma vez que a configuração da política de retenção e do ciclo de vida é aplicada ao nível do contentor.

Certifique-se de que este contentor de armazenamento tem autorizações da IAM, uma política de retenção e uma configuração do ciclo de vida definidas de forma a impedir a eliminação acidental ou o acesso não autorizado. Para mais informações sobre a configuração de um contentor para instantâneos, consulte o artigo Configurar instantâneos agendados.

Pode:

Crie um contentor numa região diferente.
Crie um contentor multirregional.

Configure a manutenção da base de dados

Mantenha a base de dados do Airflow pequena e dentro do limite de tamanho configurando a limpeza da base de dados. Esta ação torna o processo de guardar e carregar capturas de ecrã mais rápido. A base de dados do Airflow tem de ter menos de 20 GB de dados para criar instantâneos.

Configure instantâneos agendados

Configure instantâneos agendados para o ambiente principal.

Só é possível criar instantâneos num ambiente saudável. Por isso, os instantâneos têm de ser guardados antes da ocorrência do desastre.

Para mais informações sobre como funcionam as capturas instantâneas, consulte o artigo Guarde e carregue capturas instantâneas do ambiente. Consulte a secção Guarde um instantâneo do ambiente da documentação para obter informações sobre onde encontrar os instantâneos guardados.

(Opcional) Configure a monitorização das operações de instantâneos agendadas

Para instantâneos agendados com uma frequência de, pelo menos, uma vez a cada 12 horas, pode usar o Cloud Monitoring para receber alertas quando um instantâneo não é criado automaticamente.

Para agendamentos de menor frequência, usa a Google Cloud CLI para validar os resultados das operações de instantâneo. Consulte o artigo Valide as operações de guardar instantâneos.

Na Google Cloud consola, aceda à página Monitorização.
Aceder a Monitorização
No painel de navegação Monitorização, selecione Alertas.
Se não tiver criado os canais de notificação e quiser receber notificações, clique em Editar canais de notificação e adicione os seus canais de notificação. Regresse à página Alertas depois de adicionar os seus canais.
Na página Alertas, selecione Criar política.
Para selecionar a métrica, expanda o menu Selecione uma métrica e, em seguida, faça o seguinte:
1. Para limitar o menu a entradas relevantes, introduza Composer Snapshot na barra de filtros. Se não houver resultados depois de filtrar o menu, desative o botão Mostrar apenas recursos e métricas ativos.
2. Para o Tipo de recurso, selecione Ambiente do Cloud Composer.
3. Para a Categoria de métricas, selecione Ambiente.
4. Para a Métrica, selecione Quantidade de criações de instantâneos.
5. Selecione Aplicar.

Clique em Adicionar filtro e use os menus pendentes para adicionar os seguintes filtros:

Filtro	Comparador	Valor
Etiqueta do recurso > environment_name	=	O nome do ambiente onde quer monitorizar as cópias instantâneas agendadas.
Etiqueta de monitorização > resultado	=	`SUCCEEDED`

Na secção Transformar dados, defina os seguintes atributos:
- Para Período dinâmico, selecione o período de monitorização para este alerta. Este valor afeta a configuração do limite no passo seguinte.
  Valor recomendado para a monitorização de instantâneos agendada: 1 dia.
- Para Função de período flutuante, selecione delta.
Clicar em Seguinte.

As definições na página Configurar acionador de alerta determinam quando o alerta é acionado. Preencha esta página com as definições na tabela seguinte.

Campo	Valor
`Condition type`	`Threshold`
`Alert trigger`	`Any time series violates`
`Threshold position`	`Below threshold`
`Threshold value`	O número de capturas de ecrã agendadas que espera que sejam guardadas no período configurado como a janela contínua para o alerta. Calcule este valor através da seguinte fórmula: `(rolling window in hours / schedule frequency in hours) - 1` Nota: a dedução de `1` hora na fórmula destina-se a ter em conta os diferentes tempos de conclusão dos resumos. Isto ajuda a evitar a geração de falsos positivos se a captura de ecrã mais recente ainda estiver em execução durante uma verificação de monitorização. Exemplo: Se usar o período dinâmico recomendado de 1 dia, e a frequência do agendamento for uma vez a cada 2 horas, defina este valor como `11` (conforme o cálculo: `24 / 2 - 1 = 11`). Se a sua programação for executada corretamente, deve ter, pelo menos, 11 instantâneos em qualquer período de 24 horas. Se não o fizer, significa que uma operação de instantâneo não foi concluída com êxito e o Cloud Monitoring aciona este alerta.
`Condition name`	O nome personalizado da condição.

Clicar em Seguinte.
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, de seguida, clique em OK.
Opcional: atualize a Duração do encerramento automático do incidente. Este campo determina quando o Monitoring fecha incidentes na ausência de dados de métricas.
Opcional: clique em Documentação e, de seguida, adicione as informações que quer incluir numa mensagem de notificação.
Clique em Nome do alerta e introduza um nome para a política de alertas.
Clique em Criar política.

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

Teste o procedimento de recuperação de desastres

Certifique-se de que testa o procedimento de recuperação de desastres depois de o configurar e, em seguida, periodicamente. Isto permite-lhe resolver potenciais problemas que possam afetar o processo de recuperação de desastres real.

No cenário de RDF fria, pode eliminar o ambiente de comutação por falha após concluir os testes do procedimento de recuperação de desastres.

Valide as operações de guardar instantâneos

Pode usar a CLI do Google Cloud para obter a lista de operações de guardar instantâneo e verificar se os seus instantâneos estão prontos para cenários de recuperação de desastres.

Este método é útil se guardar as capturas de ecrã com menos frequência do que, pelo menos, uma vez a cada 12 horas. Para validar as capturas de ecrã guardadas com mais frequência, é melhor configurar os alertas do Cloud Monitoring. Consulte o artigo Configure a monitorização de operações de instantâneos agendadas.

gcloud

Liste todas as operações de instantâneo para um ambiente específico. Para a referência de comandos completa, 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

Substituir:

LOCATIONS com a lista de identificadores de regiões onde o ambiente está localizado
PROJECT_ID com o identificador do projeto onde o ambiente está localizado
ENVIRONMENT_ID com o identificador do ambiente onde quer verificar as operações de instantâneo

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 a ocorrência de um desastre

Siga os passos descritos abaixo após a ocorrência de um desastre para recuperar o seu ambiente principal.

(Apenas para recuperação de desastres a frio) Crie um ambiente de comutação por falha

Siga as instruções na secção Crie um ambiente de alternativa.

Impedir que o ambiente principal execute DAGs

Se possível, impeça o ambiente principal de executar DAGs:

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

Carregue um instantâneo para o ambiente de comutação por falha

Carregue uma captura instantânea do ambiente principal para o ambiente de alternativa.

Assim que a imagem instantânea é carregada para o ambiente de alternativa, agenda e executa tarefas como se nada tivesse sido executado pelo ambiente principal após a criação de uma imagem instantânea. No entanto, algumas dessas tarefas podem já ter sido executadas pelo ambiente principal. O ambiente de alternativa não tem meios para reconhecer que tarefas foram executadas após a criação da imagem instantânea e antes de um desastre. Como resultado, algumas tarefas podem ser executadas duas vezes (no ambiente principal e no ambiente de alternativa). Recomendamos que todas as tarefas sejam idempotentes e que as cópias de segurança instantâneas agendadas sejam criadas a cada duas horas.

(Se necessário) Ajuste a configuração do ambiente de comutação por falha

Em alguns casos, é recomendável alterar a configuração do ambiente de comutação por falha depois de carregar o instantâneo do ambiente principal no mesmo.

Por exemplo, num cenário de recuperação de desastres (RD) a frio, pode ter de usar um conjunto diferente de variáveis de ambiente do Airflow no ambiente de comutação por falha. Como outro exemplo, num cenário de recuperação de desastres (RD) a quente, pode ter de conceder autorizações aos utilizadores na IU do Airflow para que possam aceder ao ambiente de comutação por falha.

Pode fazer estas alterações manualmente ou preparar um script de shell com comandos que alterem a configuração do ambiente de alternativa executando comandos gcloud composer environment update.

Decida o que fazer com o ambiente principal

Alguns desastres podem ocorrer porque o ambiente principal não está acessível, mas continua operacional ou não funciona corretamente. Por exemplo, não pode aceder ao ambiente principal através da rede devido a uma falha de infraestrutura. Outro exemplo é o ambiente funcionar com alguns erros ou com capacidade reduzida, mas alguns DAGs continuarem a ser executados.

Se o ambiente original ainda estiver em execução, pode gerar custos diretamente relacionados com o Cloud Composer ou outros serviços acedidos através dos DAGs, mesmo que tenha sido criado um novo ambiente como substituição. Este 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 alternativa após o carregamento da captura instantânea.

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

O ambiente principal pode ser eliminado se todos os dados relevantes tiverem sido recuperados. Por exemplo, pode querer recuperar dados que não estão incluídos nas capturas instantâneas do ambiente, como a configuração de rede ou os conteúdos do contentor do ambiente fora das pastas /dags e /plugins.

Se o ambiente principal voltar a ficar acessível e em bom estado

Se o ambiente principal tiver ficado inacessível apenas temporariamente e voltar a ficar acessível e em bom estado, pode escolher uma abordagem:

Continuar a usar o ambiente de alternativa.
Regressar ao ambiente principal.

Para continuar a usar o ambiente de alternativa:

Se o ambiente principal continuar a executar DAGs, pause-os assim que possível.
Certifique-se de que todos os dados relevantes são recuperados e, em seguida, elimine o ambiente principal.
Repita os passos de preparação para a recuperação de desastres para o ambiente de comutação por falha, como a configuração de instantâneos agendados.

Para voltar ao ambiente principal:

Pause todos os DAGs no ambiente de comutação por falha.
Aguarde que todas as execuções de DAG sejam concluídas no ambiente de comutação por falha ou pare-as.
Guarde uma captura instantânea do ambiente de comutação por falha.
Carregue esta captura de ecrã para o ambiente principal.
Despause os DAGs no ambiente principal.
Se necessário, elimine o ambiente de ativação pós-falha.