Cenários de recuperação de desastres para aplicativos

Last reviewed 2023-05-25 UTC

Este artigo faz parte de uma série sobre a recuperação de desastres (DR) no Google Cloud. Nesta parte, você verá cenários comuns de recuperação de desastres em aplicativos.

A série contém estas partes:

Introdução

Neste artigo, incluímos os cenários de DR para aplicativos em termos de padrões de DR que indicam quanto tempo leva para o aplicativo se recuperar de um evento de desastre. São usados os conceitos abordados no artigo Elementos básicos da recuperação de desastres para descrever como é possível implementar um plano de DR completo e apropriado nas metas de recuperação.

Para começar, considere algumas cargas de trabalho comuns para ilustrar como a lógica das suas metas e da arquitetura de recuperação tem uma influência direta no plano de DR.

Cargas de trabalho de processamento em lote

As cargas de trabalho de processamento em lote não costumam ser essenciais. Portanto, na maioria dos casos, não é necessário incorrer no custo de projetar uma arquitetura de alta disponibilidade (HA, na sigla em inglês) para maximizar o tempo de atividade. No geral, as cargas de trabalho de processamento em lote lidam com interrupções. Esse tipo de carga de trabalho aproveita produtos econômicos, como instâncias de VMs preemptivas, que você cria e executa a um preço muito mais baixo do que as instâncias tradicionais. No entanto, o Compute Engine encerrará à força essas instâncias, se precisar de acesso a esses recursos para outras tarefas, e elas serão encerradas em até 24 horas depois de serem iniciadas.

Com a implementação de checkpoints normais como parte da tarefa de processamento, o job de processamento continua a partir do ponto de falha quando novas VMs são iniciadas. Se você estiver usando o Cloud Dataproc, o processo de inicialização dos nós de trabalho preemptivos será administrado por um grupo de instâncias gerenciadas. Isso é considerado um padrão morno, em que há uma breve pausa que aguarda a substituição das VMs para continuar o processamento.

Sites de comércio eletrônico

Em sites de comércio eletrônico, algumas partes do aplicativo podem ter valores de RTO maiores. Por exemplo, o canal de compras real precisa ter alta disponibilidade, mas o processo de e-mail que envia notificações de pedidos aos clientes pode tolerar o atraso de algumas horas. Os clientes sabem sobre a compra e, ainda que esperem receber um e-mail de confirmação, a notificação não é uma parte essencial do processo. Essa é uma mistura de padrões quentes (compra) e mornos/frios (notificação).

A parte transacional do aplicativo precisa de um tempo de atividade alto com um valor mínimo de RTO. Portanto, você usa a alta disponibilidade (HA, na sigla em inglês), o que maximiza a disponibilidade dessa parte do aplicativo. Essa abordagem pode ser considerada um padrão quente.

O cenário de comércio eletrônico ilustra como é possível ter valores de RTO variáveis ​​no mesmo aplicativo.

Streaming de vídeo

Uma solução de streaming de vídeo tem muitos componentes que precisam estar altamente disponíveis, desde a experiência de pesquisa até o processo real de fazer streaming do conteúdo para o usuário. Além disso, o sistema requer baixa latência para criar uma experiência do usuário satisfatória. Se algum aspecto da solução não fornecer uma ótima experiência, será ruim para o fornecedor e para o cliente. Além do mais, os clientes podem recorrer a um produto da concorrência hoje em dia.

Nesse cenário, uma arquitetura de alta disponibilidade é essencial, e pequenos valores de RTO são necessários. Esse cenário exige um padrão quente em toda a arquitetura do aplicativo para garantir um impacto mínimo no caso de um desastre.

Arquiteturas de DR e alta disponibilidade para produção no local

Esta seção examina como implementar três padrões (frio, morno e quente) quando o aplicativo é executado no local e sua solução de DR está no Google Cloud.

Padrão frio: recuperação para o Google Cloud

Em um padrão frio, você tem recursos mínimos no projeto de DR do Google Cloud (o suficiente para permitir um cenário de recuperação). Quando há um problema que impede que o ambiente de produção execute cargas de trabalho de produção, a estratégia de failover requer que um espelho do ambiente de produção seja iniciado no Google Cloud. Em seguida, os clientes começam a usar os serviços do ambiente de recuperação de desastres.

Nesta seção, examinaremos um exemplo desse padrão. No exemplo, o Cloud Interconnect é configurado com uma solução de VPN autogerenciada (que não seja do Google Cloud) para fornecer conectividade ao Google Cloud. Os dados são copiados para o Cloud Storage como parte do ambiente de produção.

Elementos básicos de DR:

  • Cloud DNS
  • Cloud Interconnect
  • Solução de VPN autogerenciada
  • Cloud Storage
  • Compute Engine
  • Cloud Load Balancing
  • Deployment Manager

Essa arquitetura de exemplo é ilustrada no diagrama a seguir:

Arquitetura para padrão frio quando a produção é local

Veja nas etapas a seguir como configurar o ambiente:

  1. Crie uma rede VPC.
  2. Configure a conectividade entre a rede local e a rede do Google Cloud.
  3. Crie um bucket do Cloud Storage como o destino do backup de dados.
  4. Gere uma chave para uma conta de serviço dedicada. Esse arquivo é usado para transmitir as credenciais a um script automatizado.

  5. Copie a chave da conta de serviço para a máquina local em que você executará o script que faz o upload dos backups de banco de dados. Esse pode ser o servidor de banco de dados, mas as políticas de segurança talvez não permitam a instalação de outro software nele.

  6. Crie uma política do IAM para restringir quem tem acesso ao bucket e aos objetos dele. Inclua a conta de serviço criada especificamente para essa finalidade. Adicione também a conta de usuário ou o grupo à política do seu operador ou administrador do sistema, concedendo a todas essas identidades as permissões aplicáveis. Para detalhes sobre as permissões de acesso ao Cloud Storage, consulte Permissões do IAM para o Cloud Storage.

  7. Veja se é possível fazer upload e o download dos arquivos no bucket de destino.

  8. Crie um script de transferência de dados.

  9. Crie uma tarefa programada para executar o script.

  10. Crie imagens personalizadas que sejam configuradas para cada servidor no ambiente de produção. Cada imagem precisa ter a mesma configuração que o equivalente local dela.

    Como parte da configuração de imagem personalizada do servidor de banco de dados, crie um script de inicialização que copie automaticamente o backup mais recente de um bucket do Cloud Storage para a instância. Depois, invoque o processo de restauração.

  11. Configure o Cloud DNS para apontar para os serviços voltados à Internet.

  12. Elabore um modelo do Deployment Manager que criará servidores de aplicativos na rede do Google Cloud usando as imagens personalizadas configuradas anteriormente. Esse modelo também precisa configurar as regras de firewall apropriadas necessárias.

Você precisa implementar processos para garantir que as imagens personalizadas tenham a mesma versão do aplicativo que no local. Certifique-se de incorporar upgrades a elas como parte do ciclo de atualização padrão. Além disso, garanta que o modelo do Deployment Manager esteja usando a imagem personalizada mais recente.

Processo de failover e tarefas pós-reinicialização

Se ocorrer um desastre, será possível recuperar o sistema que está sendo executado no Google Cloud. Para isso, inicie o processo de recuperação para criar o ambiente correspondente usando o modelo do Deployment Manager criado. Quando as instâncias no ambiente de recuperação estiverem prontas para aceitar o tráfego de produção, ajuste o DNS para apontar ao servidor da Web no Google Cloud.

Veja a seguir uma sequência de recuperação comum:

  1. Use o modelo do Deployment Manager para criar uma implantação no Google Cloud.
  2. Aplique o backup de banco de dados mais recente no Cloud Storage ao servidor de banco de dados em execução no Google Cloud. Siga as instruções do sistema de banco de dados para recuperar os arquivos de backup.
  3. Aplique os registros de transação mais recentes no Cloud Storage.
  4. Teste se o aplicativo funciona conforme o esperado, simulando cenários de usuário no ambiente recuperado.
  5. Quando os testes forem concluídos, configure o Cloud DNS para apontar para o serviço da Web no Google Cloud. Por exemplo, é possível usar um endereço IP anycast em um balanceador de carga do Google Cloud com vários servidores da Web.

O ambiente recuperado é mostrado no diagrama a seguir:

Configuração do padrão frio para recuperação quando a produção é local

Quando o ambiente de produção é novamente executado no local e aceita cargas de trabalho de produção, você inverte as etapas seguidas para o failover no ambiente de recuperação do Google Cloud. Veja a seguir uma sequência comum para retornar ao ambiente de produção:

  1. Selecione um backup do banco de dados em execução no Google Cloud.
  2. Copie o arquivo de backup para seu ambiente de produção.
  3. Aplique o arquivo de backup ao sistema de banco de dados de produção.
  4. Evite conexões com o aplicativo no Google Cloud. Por exemplo, impeça conexões com o balanceador de carga global. Nesse momento, o aplicativo ficará indisponível até você concluir a restauração do ambiente de produção.
  5. Copie os arquivos de registros de transação para o ambiente de produção e aplique-os ao servidor de banco de dados.
  6. Configure o Cloud DNS para apontar para o serviço da Web no local.
  7. Verifique se o processo de cópia de dados no Cloud Storage está funcionando conforme o esperado.
  8. Exclua a implantação.

Espera morna: recuperação para o Google Cloud

Um padrão morno é normalmente implementado para manter o valor de RTO e de RPO o menor possível sem o esforço e a despesa de uma configuração de alta disponibilidade completa. Quanto menores os valores de RTO e de RPO, maiores os custos à medida que você se aproxima de um ambiente totalmente redundante que pode disponibilizar tráfego de dois ambientes. Portanto, a implementação de um padrão morno para seu cenário de recuperação de desastres apresenta um bom custo-benefício de orçamento e disponibilidade.

Um exemplo dessa abordagem é usar o Cloud Interconnect configurado com uma solução de VPN autogerenciada para fornecer conectividade ao Google Cloud. Um aplicativo de multicamadas está sendo executado no local enquanto usa um conjunto de recuperação mínimo no Google Cloud. O conjunto de recuperação consiste em uma instância do servidor de banco de dados operacional no Google Cloud. Essa instância precisa ser executada o tempo todo para que possa receber transações replicadas por meio de técnicas de replicação assíncronas ou semissíncronas. Para reduzir custos, é possível executar o banco de dados no menor tipo de máquina capaz de executar o serviço de banco de dados. Como é possível usar uma instância de execução longa, os descontos por uso prolongado serão aplicados.

Elementos básicos de DR:

  • Cloud DNS
  • Cloud Interconnect
  • Solução de VPN autogerenciada
  • Compute Engine
  • Deployment Manager

Os snapshots do Compute Engine são uma maneira de fazer backups que podem ser revertidos para um estado anterior. Os snapshots são usados neste exemplo porque as páginas da Web atualizadas e os binários do aplicativo são gravados com frequência na Web de produção e nos servidores de aplicativos. Essas atualizações são regularmente replicadas para o servidor da Web de referência e para as instâncias do servidor de aplicativos no Google Cloud. Os servidores de referência não aceitam tráfego de produção. Eles são usados para criar os snapshots.

O diagrama a seguir ilustra uma arquitetura que implementa essa abordagem. Os alvos de replicação não são mostrados no diagrama.

Arquitetura para um padrão morno quando a produção é local

Veja nas etapas a seguir como configurar o ambiente:

  1. Crie uma rede VPC.
  2. Configure a conectividade entre a rede local e a rede do Google Cloud.
  3. Replique os servidores locais para as instâncias de VM do Google Cloud. Uma opção é usar uma solução de parceiro. O método adotado varia de caso a caso.
  4. Crie uma imagem personalizada do servidor de banco de dados no Google Cloud que tenha a mesma configuração que o servidor de banco de dados local.
  5. Crie snapshots das instâncias do servidor da Web e de aplicativos.
  6. Inicie uma instância de banco de dados no Google Cloud usando a imagem personalizada que você criou anteriormente. Utilize o menor tipo de máquina capaz de aceitar dados replicados do banco de dados de produção local.
  7. Anexe discos permanentes à instância de banco de dados do Google Cloud para os bancos de dados e registros de transações.
  8. Configure a replicação entre o servidor de banco de dados local e o do Google Cloud. Basta seguir as instruções do software de banco de dados.
  9. Defina a sinalização de exclusão automática nos discos permanentes anexados à instância do banco de dados como no-auto-delete.
  10. Configure uma tarefa programada para criar snapshots regulares dos discos permanentes da instância de banco de dados no Google Cloud.
  11. Crie reservas para garantir a capacidade do servidor da Web e dos servidores de aplicativos conforme necessário.
  12. Teste o processo de criar snapshots dos discos permanentes e de criar instâncias com base neles.
  13. Crie instâncias do servidor da Web e de aplicativos usando os snapshots criados anteriormente.
  14. Crie um script que copie as atualizações para o aplicativo da Web e para o servidor dele sempre que os servidores locais correspondentes forem atualizados. Grave o script para criar um snapshot dos servidores atualizados.
  15. Configure o Cloud DNS para apontar para o serviço voltado à Internet no local.

Processo de failover e tarefas pós-reinicialização

Para gerenciar um failover, você normalmente usa seu sistema de monitoramento e alerta para chamar um processo de failover automatizado. Quando o aplicativo local precisa fazer failover, configure o sistema de banco de dados no Google Cloud para aceitar o tráfego de produção. Inicie também instâncias do servidor da Web e de aplicativos.

Veja no diagrama a seguir a configuração após o failover para o Google Cloud, permitindo que as cargas de trabalho de produção sejam disponibilizadas do Google Cloud:

Configuração do padrão morno para recuperação quando a produção é local

Veja a seguir uma sequência de recuperação comum:

  1. Redimensione a instância do servidor de banco de dados para que ela possa processar as cargas de produção.
  2. Use o servidor da Web e os snapshots do aplicativo no Google Cloud para criar novas instâncias do servidor da Web e do aplicativo.
  3. Teste se o aplicativo funciona conforme o esperado, simulando cenários de usuário no ambiente recuperado.
  4. Quando os testes forem concluídos, configure o Cloud DNS para apontar para o serviço da Web no Google Cloud.

Quando o ambiente de produção é novamente executado no local e aceita cargas de trabalho de produção, você inverte as etapas seguidas para o failover no ambiente de recuperação do Google Cloud. Veja a seguir uma sequência comum para retornar ao ambiente de produção:

  1. Selecione um backup do banco de dados em execução no Google Cloud.
  2. Copie o arquivo de backup para seu ambiente de produção.
  3. Aplique o arquivo de backup ao sistema de banco de dados de produção.
  4. Evite conexões com o aplicativo no Google Cloud. Uma maneira de fazer isso é modificar as regras de firewall para impedir conexões com o servidor da Web. Nesse momento, o aplicativo ficará indisponível até você concluir a restauração do ambiente de produção.
  5. Copie os arquivos de registros de transação para o ambiente de produção e aplique-os ao servidor de banco de dados.
  6. Teste se o aplicativo funciona conforme o esperado, simulando cenários de usuário no ambiente de produção.
  7. Configure o Cloud DNS para apontar para o serviço da Web no local.
  8. Exclua as instâncias do servidor da Web e de aplicativos que estejam em execução no Google Cloud. Deixe os servidores de referência em execução.
  9. Redimensione o servidor de banco de dados no Google Cloud ao tamanho mínimo de instância que aceita dados replicados do banco de dados de produção local.
  10. Configure a replicação entre o servidor de banco de dados local e o do Google Cloud. Basta seguir as instruções do software de banco de dados.

Alta disponibilidade quente no local e no Google Cloud

Se você tiver pequenos valores de RTO e de RPO, só poderá alcançá-los executando a alta disponibilidade em todo o ambiente de produção e no Google Cloud simultaneamente. Essa abordagem fornece um padrão quente, já que tanto o local quanto o Google Cloud estão disponibilizando tráfego de produção.

A principal diferença do padrão morno é que os recursos nos dois ambientes são executados no modo de produção e disponibilizam tráfego de produção.

Elementos básicos de DR:

  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • Grupos de instâncias gerenciadas
  • Cloud Monitoring
  • Cloud Load Balancing

Essa arquitetura de exemplo é ilustrada no diagrama a seguir. Ao implementá-la, você terá um plano de DR que requer intervenção mínima no caso de um desastre.

Arquitetura para um padrão quente quando a produção é local

Veja nas etapas a seguir como configurar o ambiente:

  1. Crie uma rede VPC.
  2. Configure a conectividade entre a rede local e a rede do Google Cloud.
  3. Crie imagens personalizadas no Google Cloud que sejam configuradas para cada servidor no ambiente de produção local. Cada imagem do Google Cloud precisa ter a mesma configuração que o equivalente local dela.

  4. Configure a replicação entre o servidor de banco de dados local e o do Google Cloud. Basta seguir as instruções do software de banco de dados.

    Muitos sistemas de banco de dados permitem apenas uma única instância de banco de dados gravável ao configurar a replicação. Portanto, pode ser necessário garantir que uma das réplicas do banco de dados atue como um servidor somente leitura.

  5. Crie modelos de instâncias individuais que usem as imagens nos servidores da Web e de aplicativos.

  6. Configure grupos regionais de instâncias gerenciadas nos servidores da Web e de aplicativos.

  7. Configure verificações de integridade usando o Cloud Monitoring.

  8. Configure o balanceamento de carga usando os grupos regionais de instâncias gerenciadas que foram configurados anteriormente.

  9. Configure uma tarefa programada para criar snapshots regulares dos discos permanentes.

  10. Configure um serviço de DNS para distribuir o tráfego entre o ambiente local e o do Google Cloud.

Com essa abordagem híbrida, você precisa usar um serviço de DNS que aceite o roteamento ponderado para os dois ambientes de produção. Assim, é possível disponibilizar o mesmo aplicativo de ambos.

Você precisa projetar o sistema para falhas que possam ocorrer em apenas parte do ambiente (falhas parciais). Nesse caso, o tráfego precisa ser redirecionado para o serviço equivalente no outro ambiente de backup. Por exemplo, se os servidores da Web locais ficarem indisponíveis, você poderá desativar o roteamento de DNS para esse ambiente. Se o serviço DNS oferecer suporte a verificações de integridade, isso ocorrerá automaticamente quando a verificação de integridade determinar que os servidores da Web em um dos ambientes não podem ser acessados.

Se você estiver usando um sistema de banco de dados que permite apenas uma única instância gravável, em muitos casos o sistema de banco de dados promoverá automaticamente a réplica somente leitura para ser a principal gravável quando o sinal de funcionamento entre o banco de dados gravável original e a réplica de leitura perder o contato. Certifique-se de compreender esse aspecto da sua replicação de banco de dados, caso seja necessário intervir após um desastre.

Implemente processos para garantir que as imagens de VM personalizadas no Google Cloud tenham a mesma versão do aplicativo que as versões locais. Incorpore upgrades às imagens personalizadas como parte do ciclo de atualização padrão. Além disso, garanta que o modelo do Deployment Manager esteja usando a imagem personalizada mais recente.

Processo de failover e tarefas pós-reinicialização

Na configuração descrita neste artigo para um cenário quente, um desastre significa que um dos dois ambientes não está disponível. Não há processo de failover da mesma maneira que há no cenário morno ou frio, em que é necessário mover dados ou processá-los para o segundo ambiente. No entanto, talvez você precise lidar com as alterações de configuração a seguir:

  • Se o serviço de DNS não redirecionar automaticamente o tráfego com base em uma falha de verificação de integridade, você precisará reconfigurar manualmente o roteamento de DNS para enviar tráfego ao sistema que ainda está ativo.
  • Se o sistema de banco de dados não promover automaticamente uma réplica somente leitura como a principal falha gravável, será necessário intervir para garantir que a réplica seja promovida.

Quando o segundo ambiente é novamente executado e pode processar o tráfego de produção, é necessário ressincronizar os bancos de dados. Como os dois ambientes aceitam cargas de trabalho de produção, você não precisa executar nenhuma outra ação para alterar qual banco de dados é o principal. Depois que os bancos de dados forem sincronizados, será possível permitir que o tráfego de produção seja distribuído aos dois ambientes novamente, ajustando as configurações de DNS.

Arquiteturas de DR e alta disponibilidade para produção no Google Cloud

Quando você projeta a arquitetura do aplicativo para carga de trabalho de produção no Google Cloud, os recursos de alta disponibilidade da plataforma têm uma influência direta sobre a arquitetura de recuperação de desastres.

Frio: servidor de aplicativos recuperável

Em um cenário de failover frio, em que é preciso uma única instância do servidor, somente uma instância precisa gravar no disco. Em um ambiente local, geralmente é usado um cluster ativo / passivo. Ao executar um ambiente de produção no Google Cloud, é possível criar uma VM em um grupo de instâncias gerenciadas que executa apenas uma instância.

Elementos básicos de DR:

  • Compute Engine
  • Grupos de instâncias gerenciadas

Esse cenário de failover frio é mostrado no exemplo de arquitetura de imagem a seguir:

Configuração do padrão frio para recuperação quando a produção é no Google Cloud

Para ter uma visão geral completa de como implantar esse cenário de exemplo e testar a recuperação de falha, consulte Implantar um servidor de Web frio recuperável com snapshots de disco permanente.

As etapas a seguir descrevem como configurar esse cenário de failover frio:

  1. Crie uma rede VPC.
  2. Crie uma imagem de VM personalizada que seja configurada com o serviço da Web do aplicativo.
    1. Configure a VM para que os dados processados pelo serviço do aplicativo sejam gravados em um disco permanente anexado.
  3. Crie um snapshot do disco permanente anexado.
  4. Crie um modelo de instância que faça referência à imagem de VM personalizada do servidor da Web.
    1. Configure um script de inicialização para criar um disco permanente a partir do snapshot mais recente e ativá-lo. Esse script precisa ser o snapshot mais recente do disco.
  5. Crie um grupo de instâncias gerenciadas e verificações de integridade com o tamanho de destino de um que faça referência ao modelo de instância.
  6. Configure uma tarefa programada para criar instantâneos regulares do disco permanente..
  7. Configure um balanceador de carga de aplicativo externo.
  8. Configure alertas usando o Cloud Monitoring para enviar um alerta quando o serviço falhar.

Esse cenário de failover frio aproveita alguns dos recursos de alta disponibilidade disponíveis no Google Cloud. Se uma VM falhar, o grupo de instâncias gerenciadas tentará recriá-la automaticamente. Não é necessário iniciar essa etapa de failover. O balanceador de carga de aplicativo externo garante que, mesmo quando uma VM substituta for necessária, o mesmo endereço IP seja usado na frente do servidor de aplicativos. O modelo de instância e a imagem personalizada asseguram que a VM de substituição seja configurada de forma idêntica à instância que substitui.

Seu RPO é determinado pelo último snapshot criado. Quanto maior a frequência com que você tira snapshots, menor é o valor do RPO.

O grupo de instâncias gerenciadas fornece alta disponibilidade avançada. O grupo de instâncias gerenciadas oferece maneiras de reagir a falhas no nível do aplicativo ou da VM. Você não intervém manualmente se algum desses cenários ocorrer. O tamanho de destino garante que você tenha apenas uma instância ativa que seja executada no grupo de instâncias gerenciadas e veicule tráfego.

Os discos permanentes são zonais, portanto, é necessário tirar snapshots para recriar discos se houver uma falha zonal. Os snapshots também estão disponíveis entre regiões, o que permite restaurar um disco em uma região diferente, de maneira semelhante à restauração na mesma região.

No caso improvável de uma falha na zona, você precisa intervir manualmente para se recuperar, conforme descrito na próxima seção.

Processo de failover

Se uma VM falhar, o grupo de instâncias gerenciadas tentará recriar automaticamente uma VM na mesma zona. O script de inicialização no modelo de instância cria um disco permanente a partir do snapshot mais recente e o anexa à nova VM.

No entanto, um grupo de instâncias gerenciadas com tamanho um não será recuperado se houver uma falha de zona. No caso de uma zona falhar, é preciso reagir ao alerta do Cloud Monitoring ou a outra plataforma de monitoramento quando o serviço falhar e criar manualmente um grupo de instâncias em outra zona.

Uma variação dessa configuração é usar discos permanentes regionais em vez de discos permanentes sazonais. Com essa abordagem, você não precisa usar snapshots para restaurar o disco permanente como parte da etapa de recuperação. No entanto, essa variação consome o dobro de armazenamento, e você precisará adaptar o orçamento a isso. Para implantar esse cenário alternativo e testar a recuperação após uma falha, consulte Implantar um servidor de Web recuperável com discos permanentes regionais.

Escolha uma dessas abordagens de acordo com seu orçamento e os valores de RTO e RPO.

Morno: failover de site estático

Se as instâncias do Compute Engine falharem, reduza a interrupção do serviço com um site estático baseado no Cloud Storage em espera. Usar um site estático (em inglês) é uma opção quando o aplicativo da Web é quase todo estático. Neste cenário, o aplicativo principal é executado nas instâncias do Compute Engine. Elas são incluídas em grupos de instâncias gerenciadas, que são disponibilizados como serviços de back-end em um balanceador de carga HTTPS. O balanceador de carga HTTP direciona o tráfego de entrada para as instâncias de acordo com a configuração do balanceador de carga, a configuração de cada grupo de instâncias e a integridade de cada instância.

Elementos básicos de DR:

  • Compute Engine
  • Cloud Storage
  • Cloud Load Balancing
  • Cloud DNS

Essa arquitetura de exemplo é ilustrada no diagrama a seguir:

Arquitetura de um failover morno para um site estático quando a produção é no Google Cloud

Para uma visão geral completa de como implantar esse cenário de exemplo e testar a recuperação após a falha, consulte Implantar um servidor da Web recuperável com o uso do Cloud DNS com o Compute Engine e o Cloud Storage.

As etapas a seguir descrevem como configurar esse cenário:

  1. Crie uma rede VPC.
  2. Crie uma imagem personalizada que seja configurada com o serviço da Web do aplicativo.
  3. Crie um modelo de instância que use a imagem nos servidores da Web.
  4. Configure um grupo de instâncias gerenciadas para os servidores da Web.
  5. Configure verificações de integridade usando o Monitoring.
  6. Configure o balanceamento de carga usando os grupos de instâncias gerenciadas configurados anteriormente.
  7. Crie um site estático baseado no Cloud Storage.

Na configuração de produção, o Cloud DNS está ajustado para apontar para este aplicativo principal, e o site estático em espera fica adormecido. Se o aplicativo do Compute Engine ficar inativo, configure o Cloud DNS de modo a apontar para esse site estático.

Processo de failover

Se o servidor ou os servidores de aplicativos ficarem inativos, sua sequência de recuperação será configurar o Cloud DNS de modo a apontar para o site estático. A arquitetura no modo de recuperação é mostrada no diagrama a seguir:

Configuração após o failover para um site estático quando a produção é no Google Cloud.

Quando as instâncias do Compute Engine do aplicativo são novamente executadas e aceitam cargas de trabalho de produção, você inverte a etapa de recuperação: configure o Cloud DNS de modo a apontar para o balanceador de carga que faz frente às instâncias.

Para uma abordagem alternativa que usa o balanceador de carga de aplicativo externo em vez do Cloud DNS para controlar o failover, consulte Implantar um servidor da Web recuperável com o Compute Engine e o Cloud Storage. Esse padrão é útil se você não tem ou não quer usar o Cloud DNS.

Quente: aplicativo da Web de alta disponibilidade

Um padrão quente quando o ambiente de produção está sendo executado no Google Cloud é estabelecer uma implantação de alta disponibilidade bem arquitetada.

Elementos básicos de DR:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

Essa arquitetura de exemplo é ilustrada no diagrama a seguir:

Arquitetura de padrão quente quando a produção é no Google Cloud

Esse cenário aproveita os recursos de alta disponibilidade do Google Cloud. Você não precisa iniciar nenhuma etapa de failover porque elas ocorrerão automaticamente no caso de um desastre.

Conforme mostrado no diagrama, a arquitetura usa um grupo regional de instâncias gerenciadas com o balanceamento de carga global e o Cloud SQL. Esse exemplo usa um grupo regional de instâncias gerenciadas para que as instâncias sejam distribuídas em três zonas.

Com essa abordagem, você consegue alta disponibilidade avançada. Os grupos regionais de instâncias gerenciadas fornecem mecanismos para reagir a falhas no nível do aplicativo, da instância ou da zona, e você não precisa intervir manualmente caso ocorra algum desses cenários.

Para abordar a recuperação no nível do aplicativo, como parte da configuração do grupo de instâncias gerenciadas, defina verificações de integridade de HTTP que conferem se os serviços estão sendo executados corretamente nas instâncias desse grupo. Se uma verificação de integridade determina que um serviço tem uma falha em uma instância, o grupo recria essa instância automaticamente.

Para ver as etapas detalhadas sobre um método de configuração de um aplicativo da Web de alta disponibilidade no Google Cloud, consulte Aplicativo da Web escalonável e resiliente no Google Cloud (em inglês).

A seguir