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

Este artigo é a terceira parte de uma série sobre recuperação de desastres (DR, na sigla em inglês) no Google Cloud Platform (GCP). Nesta parte, exploramos cenários comuns de recuperação de desastres em aplicativos.

A série consiste nestas partes:

Introdução

Neste artigo, serão abordados os cenários de recuperação de desastres nos aplicativos em termos de padrões da DR. Eles indicam quanto tempo leva para o aplicativo se recuperar de um evento de desastre. Você verá os conceitos abordados no artigo Elementos básicos da DR para descrever como é possível implementar um plano de DR completo e adequado para suas metas de recuperação.

Para começar, pense em 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, não há uma necessidade comum de incorrer o custo de projetar uma arquitetura de alta disponibilidade para maximizar o tempo de atividade. Em geral, essas cargas de trabalho podem lidar com interrupções. Esse tipo de carga de trabalho aproveita produtos econômicos, como instâncias de VMs preemptivas, que você pode criar e executar a um preço muito mais baixo 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 você pode 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 facilmente 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

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

Padrão frio: recuperação para o GCP

Em um padrão frio, você tem recursos mínimos no projeto de DR do GCP (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 GCP. 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 o Cloud VPN para fornecer conectividade ao GCP. Os dados são copiados para o Cloud Storage como parte do ambiente de produção.

Elementos básicos da recuperação de desastres:

  • Cloud DNS
  • Cloud Interconnect
  • Cloud VPN
  • Cloud Storage
  • Compute Engine
  • Cloud Load Balancing
  • Cloud Deployment Manager

Essa arquitetura de exemplo é ilustrada no diagrama a seguir:

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

Nas etapas a seguir, descrevemos como é possível configurar o ambiente:

  1. Crie uma rede VPC.
  2. Configure a conectividade entre a rede local e a do GCP.
  3. Crie um intervalo 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. Isso 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 intervalo 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 ver detalhes sobre as permissões de acesso ao Cloud Storage, consulte Permissões do IAM para comandos gsutil.

  7. Teste se é possível fazer o upload e o download dos arquivos no intervalo 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 são configuradas para cada servidor no ambiente de produção. Cada imagem precisa ter a mesma configuração que seu equivalente local.

    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 intervalo do Cloud Storage para a instância. Depois, chame o processo de restauração.

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

  12. Elabore um modelo do Cloud Deployment Manager que criará servidores de aplicativos na rede do GCP 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 atualizações a elas como parte do seu ciclo de atualização padrão, e garanta que o modelo do Cloud 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 GCP. Para isso, inicie o processo de recuperação para criar o ambiente de recuperação usando o modelo do Cloud 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 de modo a apontar para o servidor da Web no GCP.

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

  1. Use o modelo do Cloud Deployment Manager para criar uma implantação no GCP.
  2. Aplique o backup de banco de dados mais recente no Cloud Storage ao servidor de banco de dados em execução no GCP. 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 servidor da Web no GCP. (Por exemplo, é possível usar um endereço IP anycast em um balanceador de carga do GCP com vários servidores da Web no balanceador.)

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 GCP. Veja a seguir uma sequência comum para retornar ao ambiente de produção:

  1. Faça um backup do banco de dados em execução no GCP.
  2. Copie o arquivo de backup para o 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 GCP. 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. Certifique-se de que o processo de cópia de dados no Cloud Storage esteja funcionando conforme o esperado.
  8. Exclua a implantação.

Espera morna: recuperação para o GCP

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 o Cloud VPN para fornecer conectividade ao GCP. Um aplicativo de multicamadas está sendo executado no local enquanto usa um conjunto de recuperação mínimo no GCP. O conjunto de recuperação consiste em uma instância do servidor de banco de dados operacional no GCP. 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 você pode usar uma instância de execução longa, os descontos por uso prolongado serão aplicados.

Elementos básicos da recuperação de desastres:

  • Cloud DNS
  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • Cloud Deployment Manager

Os instantâneos do Compute Engine são uma maneira de fazer backups que podem ser revertidos para um estado anterior. Os instantâneos 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 GCP.Os servidores de referência não aceitam tráfego de produção. Eles são usados ​​para criar os instantâneos.

No diagrama a seguir, ilustramos 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

Nas etapas a seguir, descrevemos como é possível configurar o ambiente:

  1. Crie uma rede VPC.
  2. Configure a conectividade entre a rede local e a do GCP.
  3. Replique os servidores locais para as instâncias de VM do GCP. Uma opção é usar uma solução de parceiro. O método adotado depende das circunstâncias.
  4. Crie uma imagem personalizada do servidor de banco de dados no GCP que tenha a mesma configuração que o servidor de banco de dados local.
  5. Crie instantâneos das instâncias do servidor da Web e de aplicativos.
  6. Inicie uma instância de banco de dados no GCP 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 GCP 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 GCP. 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 de banco de dados como no-auto-delete.
  10. Configure uma tarefa programada para criar instantâneos regulares dos discos permanentes na instância de banco de dados no GCP.
  11. Teste o processo de tirar instantâneos dos discos permanentes e de criar instâncias com base nos instantâneos.
  12. Crie instâncias do servidor da Web e de aplicativos usando os instantâneos criados anteriormente.
  13. 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 instantâneo dos servidores atualizados.
  14. 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 GCP para aceitar o tráfego de produção. Inicie também instâncias do servidor da Web e de aplicativos.

No diagrama a seguir, mostramos a configuração após o failover para o GCP, permitindo que as cargas de trabalho de produção sejam disponibilizadas do GCP:

Configuração do padrão quente 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 instantâneos do aplicativo no GCP 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 GCP.

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 GCP. Veja a seguir uma sequência comum para retornar ao ambiente de produção:

  1. Faça um backup do banco de dados em execução no GCP.
  2. Copie o arquivo de backup para o 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 GCP. 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 estão em execução no GCP. Deixe os servidores de referência em execução.
  9. Redimensione o servidor de banco de dados no GCP 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 GCP. Basta seguir as instruções do software de banco de dados.

Alta disponibilidade quente no local e no GCP

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 GCP simultaneamente. Essa abordagem fornece um padrão quente, já que tanto o local quanto o GCP 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 da recuperação de desastres:

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

Essa arquitetura de exemplo é ilustrada no diagrama a seguir. Ao implementá-la, você tem 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

Nas etapas a seguir, descrevemos como é possível configurar o ambiente:

  1. Crie uma rede VPC.
  2. Configure a conectividade entre a rede local e a do GCP.
  3. Crie imagens personalizadas no GCP que são configuradas para cada servidor no ambiente de produção local. Cada imagem do GCP precisa ter a mesma configuração que seu equivalente local.
  4. Configure a replicação entre o servidor de banco de dados local e o do GCP. 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, talvez seja 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 de aplicativos e da Web.

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

  7. Configure verificações de integridade usando o Stackdriver 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 instantâneos regulares dos discos permanentes.

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

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 GCP tenham a mesma versão do aplicativo que as versões locais. Incorpore atualizações às imagens personalizadas como parte do seu ciclo de atualização padrão, e garanta que o modelo do Cloud 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 simplesmente 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, você poderá 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 GCP

Quando você projeta a arquitetura do aplicativo para carga de trabalho de produção no GCP, 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 frio, em que é preciso uma única instância do servidor, você quer apenas uma instância gravando no disco. No local, isso geralmente é conseguido com um cluster ativo/passivo. Por outro lado, quando você executa um ambiente de produção no GCP, a instância do servidor faz parte de um grupo de instâncias gerenciadas. Esse grupo é usado como um serviço de back-end para o serviço de balanceamento de carga interno.

Elementos básicos da recuperação de desastres:

  • Compute Engine
  • Balanceamento de carga interno do GCP

Essa arquitetura de exemplo é ilustrada no diagrama a seguir. Nenhuma conexão de cliente é ilustrada, porque, em geral, você não tem um cliente externo conectado diretamente a um servidor de aplicativos. Em vez disso, o comum é ter um proxy ou aplicativo da Web na frente do servidor de aplicativos.

Arquitetura de um cenário frio quando a produção é no GCP

Nas etapas a seguir, descrevemos como é possível configurar esse cenário:

  1. Crie uma rede VPC.
  2. Crie uma imagem personalizada configurada com o serviço de aplicativo. Como parte da imagem, faça as configurações a seguir:

    1. Configure o servidor para que os dados processados pelo serviço do aplicativo sejam gravados em um disco permanente anexado.
    2. Crie um instantâneo do disco permanente anexado.
    3. Configure um script de inicialização para criar um disco permanente do instantâneo mais recente e ativá-lo. Esse script precisa ser capaz de receber o último instantâneo do disco.
  3. Crie um modelo de instância que use a imagem.

  4. Configure um grupo regional de instâncias gerenciadas com um tamanho de destino de um. Use o modelo de instância criado anteriormente.

  5. Configure verificações de integridade usando o Monitoring.

  6. Configure o balanceamento de carga interno usando o grupo regional de instâncias gerenciadas configurado anteriormente.

  7. Configure uma tarefa programada para criar instantâneos regulares do disco permanente.

    Neste cenário, aproveitamos alguns dos recursos de alta disponibilidade disponíveis no GCP. Você não precisa iniciar nenhuma etapa de failover porque elas ocorrerão automaticamente no caso de um desastre. O balanceador de carga interno garante que, mesmo quando uma instância de substituição for necessária, o mesmo endereço IP seja usado para fazer frente ao servidor de aplicativos. O modelo de instância e a imagem personalizada garantem que a instância de substituição seja configurada de forma idêntica à instância que está substituindo.

Seu RPO será determinado pelo último instantâneo capturado. Quanto maior a frequência com que os instantâneos são capturados, menor é o valor do RPO.

O grupo regional de instâncias gerenciadas fornece alta disponibilidade avançada. Ele oferece mecanismos para reagir a falhas no nível do aplicativo, da instância ou da zona. Você não precisa intervir manualmente se algum desses cenários ocorrer. Definir um tamanho de destino como um garante que você tenha apenas uma instância em execução.

Os discos permanentes são zonais, portanto, os instantâneos são necessários para recriar discos em caso de falha zonal. Os instantâneos também estão disponíveis nas regiões, o que permite restaurar um disco em uma região diferente tão facilmente quanto na mesma região.

Processo de failover

Neste cenário, no caso de uma falha zonal, o grupo regional de instâncias inicia uma instância de substituição em uma zona diferente na mesma região. Um novo disco permanente é criado do último instantâneo e anexado à nova instância. Esse estado é ilustrado no diagrama a seguir:

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

Algumas variações dessa configuração incluem o seguinte:

  • O uso de discos permanentes regionais em vez de por zona. Com essa abordagem, você não precisa usar instantâneos 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.
  • O uso de um grupo de instâncias gerenciadas em vez de um grupo regional, e anexar o disco permanente à instância de substituição iniciada na mesma zona que a instância com falha. Nesse cenário, você precisa configurar a exclusão automática do disco permanente como no-auto-delete.

A abordagem escolhida será determinada pelo seu orçamento e valores de RTO e de 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 é uma opção quando o aplicativo da Web é quase todo estático. Nesse 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 da recuperação de desastres:

  • 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 GCP

Nas etapas a seguir, descrevemos como é possível configurar esse cenário:

  1. Crie uma rede VPC.
  2. Crie uma imagem personalizada 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 que você configurou 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 os servidores de aplicativos ficarem inativos, a sequência de recuperação será configurar o Cloud DNS para 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 GCP

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 para apontar para o balanceador de carga que faz frente às instâncias.

Quente: aplicativo da Web de alta disponibilidade

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

Elementos básicos da recuperação de desastres:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

Essa arquitetura de exemplo é ilustrada no diagrama a seguir:

Arquitetura de padrões quentes quando a produção é no GCP

Esse cenário aproveita os recursos de alta disponibilidade do GCP. 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 GCP, consulte Aplicativo da Web escalonável e resiliente no GCP.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…