O Cloud Composer 1 está no modo pós-manutenção. O Google não lança mais atualizações do Cloud Composer 1, incluindo novas versões do Airflow, correções de bugs e atualizações de segurança. Recomendamos planejar a migração para o Cloud Composer 2.

Esta página foi traduzida pela API Cloud Translation.

Recuperação de desastres com snapshots de ambiente

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

Nesta página, descrevemos como usar snapshots de ambiente para recuperação de desastres.

Definições

Este guia usa as seguintes definições:

Desastres é um evento em que o Cloud Composer ou outros componentes essenciais para o funcionamento do ambiente não estão disponíveis. Este evento requer um failover para uma região diferente, e o Cloud Composer e ambientes de teste. A causa de um desastre pode ser natural ou causado pelo homem, incluindo inatividade das regiões do Google Cloud e interrupções por conta própria do Google Cloud.
Recuperação de desastres (DR), no contexto do Cloud Composer, é uma de recuperação da operação do ambiente após um desastre. O a recriação do ambiente, possivelmente em outra região. Para mais informações sobre a recuperação de desastres, consulte Guia de planejamento de recuperação de desastres.
O ambiente principal é um ambiente do Cloud Composer que você 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 morna é uma variante da recuperação de desastres, em que você usa uma ambiente de failover, que é 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 no ambiente de failover após a ocorrência de um desastre.
A DR entre regiões é uma variante da recuperação de desastres morna ou a frio, em que o primário e de failover ficam em diferentes regiões.

Sobre o procedimento de recuperação de desastres

O procedimento de recuperação de desastres resolve o problema o ambiente se tornou inoperante (corrompido ou inacessível) porque de um desastre.

Para este procedimento, presumimos que seu ambiente principal não será corrigido para lidar com o desastre. Em vez disso, crie um segundo (failover) do seu ambiente lado a lado. Esse ambiente opera em vez do de nuvem. Posteriormente, é possível voltar para a versão principal ou continuar usando o ambiente de failover.

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

O URL do servidor da Web será diferente. Isso altera o endereço interface do Airflow e o endpoint de API REST do Airflow
O URL do bucket do ambiente será diferente.
A configuração das permissões de acesso e rede pode precisar de ajustes.

Ao usar o cenário de DR quente, você conhece os valores do servidor da Web, os endereços dos buckets do seu ambiente de execução e a configuração de rede com antecedência.

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 seguintes etapas de preparação:

Crie um ambiente de failover.
- No cenário de DR quente, esse ambiente é mantido disponível.
- No cenário de DR frio, você cria esse ambiente apenas para testar procedimento de recuperação de desastres. Depois de concluir a preparação, excluir esse ambiente e criá-lo novamente após um desastre.
Criar um bucket para snapshots.
- O bucket precisa estar disponível na região de DR. Para DR entre regiões, o de snapshots do bucket precisa ser multirregional ou estar localizado em um uma região diferente do ambiente principal.
- Verifique se os DAGs podem acessar recursos regionais.
Configure a manutenção do banco de dados.
Configure snapshots programados.
Teste o procedimento de recuperação de desastres.

Visão geral da recuperação de desastres

Após um desastre:

(Apenas DR frio) Crie um ambiente de failover.
Se possível, interrompa o ambiente principal de executar DAGs.
Carregar um snapshot do bucket de snapshots no failover de nuvem.
Se necessário, ajustar a configuração do ambiente de failover.
Decida o que fazer com o ambiente principal.

Etapas de preparação

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

Criar um ambiente de failover

Crie um ambiente que funcione como um ambiente de failover.

Siga estas diretrizes:

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

Cuidado: não realize um failover para uma versão mais recente do o Cloud Composer ou o Airflow, já que isso pode exigir mais mudanças relacionadas à compatibilidade.
No cenário de DR com estado salvo, atualize faça upgrade dos dois ambientes em sincronia. Por exemplo, se você Fazer upgrade do ambiente principal para um Cloud Composer posterior ou instalar pacotes PyPI, o ambiente de failover também essas mudanças.
Recomendamos a criação do ambiente de failover em uma região diferente da ambiente principal. Assim, uma maior variedade de possíveis desastres diferentes cenários podem ser cobertos, como um desastre que afete a disponibilidade de toda a região.
Recomendamos usar o Terraform para criar instâncias primárias para que ambos tenham configuração consistente. Certifique-se de que As definições do Terraform para os ambientes primário e de failover são sincronizados.
A configuração do ambiente de failover (como o tamanho do ambiente, número de programadores e permissões do IAM) é recomendado de acordo com a configuração do ambiente principal. As permissões do IAM para ambos os ambientes devem conceder acesso apropriado a usuários e snapshots.

Verificar a disponibilidade de recursos

Os DAGs podem operar em recursos externos, e o acesso a eles pode ser depende da configuração do ambiente (como permissões concedidas a conta de serviço, configuração de rede ou projeto do ambiente). Marca que esses recursos estejam disponíveis no ambiente de failover.

Um ambiente pode interagir com alguns recursos externos conexões armazenadas no Airflow. Marca de seleção se esses recursos precisarem ser ajustados no ambiente de failover em comparação com do ambiente principal.

Criar um bucket de armazenamento para snapshots

Crie um novo bucket de armazenamento para os snapshots do ambiente. Não use buckets de ambiente para recuperação de desastres, pois a configuração para a política de retenção e o ciclo de vida são aplicados no nível do bucket.

Verifique se o bucket de armazenamento tem permissões do IAM, política de retenção e uma configuração de ciclo de vida definida de modo a impedir 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:

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

Configurar a manutenção do banco de dados

Mantenha o banco de dados de metadados do Airflow pequeno executando o DAG de manutenção de banco de dados. Isso faz com que o processo de salvar e o carregamento de snapshots mais rápido. O banco de dados de metadados do Airflow precisa ter menos mais de 20 GB de dados para oferecer suporte a snapshots.

Configurar snapshots programados

Configure os snapshots programados da instância principal. de nuvem.

Snapshots só podem ser criados em um ambiente íntegro, portanto, os snapshots devem ser salvas antes que o desastre aconteça.

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

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

Para snapshots programados com uma 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 mais baixa, use a Google Cloud CLI para verificar os resultados das operações de snapshots. Consulte Verificar operações para salvar snapshots.

No Console do Google Cloud, acesse a página Monitoring.
Acessar Monitoring
No painel de navegação do Monitoring, selecione Alertas:
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.
Na página Alertas, clique em Criar política.
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 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 de métrica, selecione Ambiente.
4. Em Métrica, selecione Contagem de criação de snapshots.
5. Selecione Apply.

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 os snapshots programados.
Monitorar rótulo > resultado	=	`SUCCEEDED`

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 do limite na próxima etapa.
  Valor recomendado para o monitoramento programado de snapshots: 1 dia.
- Em Função de janela contínua, selecione delta.
Clique em Next.

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 você espera que sejam salvos dentro do período configurado como 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:deduzir `1` hora na fórmula é considerar diferentes tempos de conclusão de snapshots. Isso ajuda a evitar gerar falsos positivos se o snapshot mais recente ainda estiver em execução. durante uma verificação de monitoramento. Exemplo: Se você usar o período contínuo recomendado 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 sua programação for executada corretamente, em qualquer janela de 24 horas deve ter pelo menos 11 snapshots. Se você não fizer isso, isso significa que 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.

Clique em Next.
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.
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.
Opcional: clique em Documentação e adicione as informações que quer incluir em uma mensagem de notificação.
Clique em Nome e digite um nome para a política de alertas.
Clique em Criar política.

Saiba mais em Políticas de alertas.

Testar o procedimento de recuperação de desastres

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

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

Verificar operações para salvar snapshots

Use a Google Cloud CLI para recuperar a lista de opções para salvar snapshot operações e verificar se os snapshots estão prontos para a recuperação de desastres diferentes.

Este 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, configure Alertas do Cloud Monitoring. Consulte Configure o monitoramento para operações de snapshot programados.

gcloud

Liste todas as operações de snapshot para um ambiente específico. Para a referência completa do comando, 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á localizada
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

Após um desastre, siga as etapas abaixo para recuperar a instância principal de nuvem.

(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 no ambiente principal

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

Se o ambiente principal ainda estiver acessível, pausar todos os DAGs.
Se o bucket do ambiente principal estiver acessível, mova todos os DAGs do do bucket do ambiente de execução ou para uma pasta fora de /dags na instância bucket do seu ambiente de execução.

Carregar um snapshot no ambiente de failover

Carregar 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 criar um snapshot. No entanto, algumas dessas tarefas podem já ter sido executados pelo ambiente principal. O ambiente de failover não tem significa 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 (em ambos os ambientes primário e de failover). Recomendamos que todas as tarefas são idempotentes e que os snapshots programados criada a cada duas horas.

Ajuste a configuração do ambiente de failover (se necessário)

Em alguns casos, pode ser necessário alterar a configuração do failover depois de carregar nele o snapshot do ambiente principal.

Por exemplo, em um cenário de DR frio, pode ser 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 a interface do Airflow para que possam acessar o ambiente de failover.

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

Decida o que fazer com o ambiente principal

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

Se o ambiente original ainda estiver em execução, talvez gerar custos diretamente relacionados ao Cloud Composer ou a outros serviços acessados pelos DAGs, mesmo que um novo ambiente tenha sido criado substituta. 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 depois de carregar o snapshot.

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

O ambiente principal poderá ser excluído se todos os dados relevantes tiverem sido recuperados. Para por exemplo, convém recuperar dados que não estão incluídos nos snapshots do ambiente; como a configuração de rede ou o conteúdo fora das pastas /dags e /plugins.

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

Se o ambiente principal fica inacessível apenas temporariamente e se torna acessível e saudável novamente, escolha uma abordagem:

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

Para continuar usando o ambiente de failover:

Se o ambiente principal ainda executar DAGs, pause-os assim que sempre que possível.
Recupere todos os dados relevantes e exclua a conta principal de nuvem.
Repita as etapas de preparação da DR para o ambiente de failover, como configurar e configurar snapshots programados.

Para retornar ao ambiente principal:

Pausar todos os DAGs no ambiente de failover.
Aguarde a conclusão de todas as execuções do DAG no ambiente de failover ou as interrompa.
Salve um snapshot do ambiente de failover.
Carregue esse snapshot no ambiente principal.
Retome os DAGs no ambiente principal.
Se necessário, exclua o ambiente de failover.