Cenários de recuperação de desastres para aplicações

Last reviewed 2024-08-05 UTC

Este documento faz parte de uma série que aborda a recuperação de desastres (RD) no Google Cloud. Esta parte explora cenários comuns de recuperação de desastres para aplicações.

A série é composta por estas partes:

Introdução

Este documento enquadra os cenários de DR para aplicações em termos de padrões de DR que indicam a facilidade com que a aplicação pode recuperar de um evento de desastre. Usa os conceitos abordados no documento Bases de DR para descrever como pode implementar um plano de DR completo adequado aos seus objetivos de recuperação.

Para começar, considere algumas cargas de trabalho típicas para ilustrar como pensar nos seus objetivos de recuperação e arquitetura tem uma influência direta no seu plano de DR.

Cargas de trabalho de processamento em lote

As cargas de trabalho de processamento em lote tendem a não ser críticas para a missão, pelo que normalmente não precisa de incorrer no custo de conceber uma arquitetura de alta disponibilidade (HA) para maximizar o tempo de atividade. Em geral, as cargas de trabalho de processamento em lote podem lidar com interrupções. Este tipo de carga de trabalho pode tirar partido de produtos económicos, como VMs do Spot e instâncias de VM preemptivas, que são instâncias que pode criar e executar a um preço muito inferior ao das instâncias normais. (No entanto, o Compute Engine pode parar ou eliminar preventivamente estas instâncias se precisar de aceder a esses recursos para outras tarefas.

Ao implementar pontos de verificação regulares como parte da tarefa de processamento, a tarefa de processamento pode ser retomada a partir do ponto de falha quando são iniciadas novas VMs. Se estiver a usar o Dataproc, o processo de lançamento de nós de trabalho preemptíveis é gerido por um grupo de instâncias gerido. Isto pode ser considerado um padrão quente, em que existe uma breve pausa à espera que as VMs de substituição continuem o processamento.

Sites de comércio eletrónico

Em sites de comércio eletrónico, algumas partes da aplicação podem ter valores de RTO maiores. Por exemplo, o pipeline de compra real tem de ter uma elevada disponibilidade, mas o processo de email que envia notificações de encomendas aos clientes pode tolerar um atraso de algumas horas. Os clientes sabem que fizeram uma compra e, por isso, embora esperem receber um email de confirmação, a notificação não é uma parte crucial do processo. Esta é uma combinação de padrões quentes (de compra), mornos e frios (de notificação).

A parte transacional da aplicação precisa de um tempo de atividade elevado com um valor de RTO mínimo. Por conseguinte, usa a HA, que maximiza a disponibilidade desta parte da aplicação. Esta abordagem pode ser considerada um padrão frequente.

O cenário de comércio eletrónico ilustra como pode ter valores de RTO variáveis na mesma aplicação.

Streaming de vídeo

Uma solução de streaming de vídeo tem muitos componentes que têm de estar altamente disponíveis, desde a experiência de pesquisa ao processo real de streaming de conteúdo para o utilizador. Além disso, o sistema requer uma latência baixa para criar uma experiência do utilizador satisfatória. Se algum aspeto da solução não proporcionar uma excelente experiência, é mau tanto para o fornecedor como para o cliente. Além disso, os clientes hoje em dia podem recorrer a um produto concorrente.

Neste cenário, uma arquitetura de HA é essencial e são necessários pequenos valores de RTO. Este cenário requer um padrão ativo em toda a arquitetura da aplicação para ajudar a garantir um impacto mínimo em caso de desastre.

Arquiteturas de RD e AD para produção no local

Esta secção examina como implementar três padrões (frio, morno e quente) quando a sua aplicação é executada no local e a sua solução de recuperação de desastres está naGoogle Cloud.

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

Num padrão frio, tem recursos mínimos no projeto de recuperação de desastres Google Cloud, apenas o suficiente para ativar um cenário de recuperação. Quando existe um problema que impede o ambiente de produção de executar cargas de trabalho de produção, a estratégia de failover requer que seja iniciado um espelho do ambiente de produção em Google Cloud. Em seguida, os clientes começam a usar os serviços do ambiente de recuperação de desastres.

Nesta secção, examinamos um exemplo deste padrão. No exemplo, o Cloud Interconnect está configurado com uma solução de VPN autogerida (nãoGoogle Cloud) para fornecer conetividade a Google Cloud. Os dados são copiados para o Cloud Storage como parte do ambiente de produção.

Este padrão usa as seguintes bases de dados de registos detalhados:

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

O diagrama seguinte ilustra esta arquitetura de exemplo:

Arquitetura para o padrão de arranque a frio quando a produção está no local

Os passos seguintes descrevem como pode configurar o ambiente:

  1. Crie uma rede de VPC.
  2. Configure a conetividade entre a sua rede no local e a rede Google Cloud .
  3. Crie um contentor do Cloud Storage como destino da cópia de segurança dos seus dados.
  4. Crie uma conta de serviço.
  5. Crie uma política de IAM para restringir quem pode aceder ao contentor e aos respetivos objetos. Inclui a conta de serviço criada especificamente para este fim. Também adiciona a conta de utilizador ou o grupo à política para o seu operador ou administrador do sistema, concedendo a todas estas identidades as autorizações relevantes. Para ver detalhes sobre as autorizações de acesso ao Cloud Storage, consulte o artigo Autorizações de IAM para o Cloud Storage.
  6. Use a representação da conta de serviço para conceder ao seu utilizador local Google Cloud(ou conta de serviço) acesso para representar a conta de serviço que criou anteriormente. Em alternativa, pode criar um novo utilizador especificamente para este fim.
  7. Teste se consegue carregar e transferir ficheiros no contentor de destino.
  8. Crie um script de transferência de dados.
  9. Crie uma tarefa agendada para executar o script. Pode usar ferramentas como o Linux crontab e o Agendador de tarefas do Windows.

  10. Criar imagens personalizadas configuradas para cada servidor no ambiente de produção. Cada imagem deve ter a mesma configuração que o seu equivalente no local.

    Como parte da configuração da imagem personalizada para o servidor de base de dados, crie um script de arranque que copie automaticamente a cópia de segurança mais recente de um contentor do Cloud Storage para a instância e, em seguida, invoque o processo de restauro.

  11. Configure o Cloud DNS para apontar para os seus serviços Web virados para a Internet.

  12. Crie um modelo do Deployment Manager que vai criar servidores de aplicações na sua Google Cloud rede usando as imagens personalizadas configuradas anteriormente. Este modelo também deve configurar as regras de firewall adequadas necessárias.

Tem de implementar processos para garantir que as imagens personalizadas têm a mesma versão da aplicação que no local. Certifique-se de que incorpora atualizações às imagens personalizadas como parte do seu ciclo de atualização padrão e certifique-se de que o modelo do Deployment Manager está a usar a imagem personalizada mais recente.

Processo de comutação por falha e tarefas após o reinício

Se ocorrer um desastre, pode fazer a recuperação para o sistema que está a ser executado no Google Cloud. Para o fazer, inicie o processo de recuperação para criar o ambiente de recuperação através do modelo do Gestor de implementações que criar. Quando as instâncias no ambiente de recuperação estiverem prontas para aceitar tráfego de produção, ajuste o DNS para apontar para o servidor Web emGoogle Cloud.

Uma sequência de recuperação típica é a seguinte:

  1. Use o modelo do Deployment Manager para criar uma implementação emGoogle Cloud.
  2. Aplique a cópia de segurança da base de dados mais recente no Cloud Storage ao servidor de base de dados em execução no Google Cloud seguindo as instruções do seu sistema de base de dados para recuperar ficheiros de cópia de segurança.
  3. Aplique os registos de transações mais recentes no Cloud Storage.
  4. Teste se a aplicação funciona conforme esperado simulando cenários de utilizadores no ambiente recuperado.
  5. Quando os testes forem bem-sucedidos, configure o Cloud DNS para apontar para o servidor Web em Google Cloud. (Por exemplo, pode usar um endereço IP anycast atrás de um balanceador de carga, com vários servidores Web atrás do balanceador de carga.) Google Cloud

O diagrama seguinte mostra o ambiente recuperado:

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

Quando o ambiente de produção estiver novamente em execução no local e o ambiente puder suportar cargas de trabalho de produção, inverta os passos que seguiu para fazer a comutação por falha para o ambiente de recuperação. Google Cloud Uma sequência típica para regressar ao ambiente de produção é a seguinte:

  1. Faça uma cópia de segurança da base de dados em execução no Google Cloud.
  2. Copie o ficheiro de cópia de segurança para o ambiente de produção.
  3. Aplique o ficheiro de cópia de segurança ao seu sistema de base de dados de produção.
  4. Impedir ligações à aplicação em Google Cloud. Por exemplo, impeça ligações ao balanceador de carga global. A partir deste ponto, a sua aplicação fica indisponível até terminar de restaurar o ambiente de produção.
  5. Copie todos os ficheiros de registo de transações para o ambiente de produção e aplique-os ao servidor de base de dados.
  6. Configure o Cloud DNS para apontar para o seu serviço Web no local.
  7. Certifique-se de que o processo que tinha implementado para copiar dados para o Cloud Storage está a funcionar conforme esperado.
  8. Elimine a sua implementação.

Standby quente: recuperação para Google Cloud

Normalmente, é implementado um padrão de aquecimento para manter os valores de RTO e RPO o mais pequenos possível sem o esforço e a despesa de uma configuração totalmente HA. Quanto menor for o valor de OTR e OPR, mais elevados são os custos à medida que se aproxima de ter um ambiente totalmente redundante que possa publicar tráfego a partir de dois ambientes. Por conseguinte, a implementação de um padrão morno para o seu cenário de RD é uma boa compensação entre o orçamento e a disponibilidade.

Um exemplo desta abordagem é usar o Cloud Interconnect configurado com uma solução VPN autogerida para fornecer conetividade ao Google Cloud. Uma aplicação de várias camadas está a ser executada no local enquanto usa um conjunto de recuperação mínimo no Google Cloud. O conjunto de recuperação consiste numa instância de servidor de base de dados operacional no Google Cloud. Esta instância tem de ser executada em todos os momentos para poder receber transações replicadas através de técnicas de replicação assíncronas ou semissíncronas. Para reduzir os custos, pode executar a base de dados no tipo de máquina mais pequeno capaz de executar o serviço de base de dados. Porque pode usar uma instância de execução prolongada, aplicam-se descontos por utilização sustentada.

Este padrão usa as seguintes bases de dados de registos detalhados:

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

Os instantâneos do Compute Engine oferecem uma forma de fazer cópias de segurança que pode reverter para um estado anterior. Neste exemplo, são usadas imagens instantâneas porque as páginas Web atualizadas e os ficheiros binários das aplicações são escritos com frequência na Web de produção e nos servidores de aplicações. Estas atualizações são replicadas regularmente para as instâncias do servidor Web e do servidor de aplicações de referência em Google Cloud. (Os servidores de referência não aceitam tráfego de produção. São usados para criar os instantâneos.)

O diagrama seguinte ilustra uma arquitetura que implementa esta abordagem. Os destinos de replicação não são apresentados no diagrama.

Arquitetura para um padrão quente quando a produção está no local

Os passos seguintes descrevem como pode configurar o ambiente:

  1. Crie uma rede de VPC.
  2. Configure a conetividade entre a sua rede no local e a rede Google Cloud .
  3. Replique os seus servidores no local para Google Cloud instâncias de VM. Uma das opções é usar uma solução de parceiro. O método que usar depende das suas circunstâncias.
  4. Crie uma imagem personalizada do servidor de base de dados no Google Cloud que tenha a mesma configuração que o servidor de base de dados no local.
  5. Crie instantâneos das instâncias do servidor Web e do servidor de aplicações.
  6. Inicie uma instância de base de dados em Google Cloud usando a imagem personalizada que criou anteriormente. Use o tipo de máquina mais pequeno capaz de aceitar dados replicados da base de dados de produção no local.
  7. Anexe discos persistentes à instância da base de dados para as bases de dados e registos de transações. Google Cloud
  8. Configure a replicação entre o servidor de base de dados no local e o servidor de base de dados no Google Cloud seguindo as instruções do software de base de dados.
  9. Defina a flag de eliminação automática nos discos persistentes anexados à instância da base de dados para no-auto-delete.
  10. Configure uma tarefa agendada para criar capturas de ecrã regulares dos discos persistentes da instância da base de dados no Google Cloud.
  11. Crie reservas para garantir a capacidade do seu servidor Web e servidores de aplicações, conforme necessário.
  12. Teste o processo de criação de instâncias a partir de imagens instantâneas e de criação de imagens instantâneas dos discos persistentes.
  13. Crie instâncias do servidor Web e do servidor de aplicações com as imagens instantâneas criadas anteriormente.
  14. Crie um script que copie as atualizações para a aplicação Web e o servidor de aplicações sempre que os servidores no local correspondentes forem atualizados. Escreva o script para criar um instantâneo dos servidores atualizados.
  15. Configure o Cloud DNS para apontar para o seu serviço Web virado para a Internet nas instalações.

Processo de comutação por falha e tarefas após o reinício

Normalmente, para gerir uma comutação por falha, usa o seu sistema de monitorização e alerta para invocar um processo de comutação por falha automático. Quando a aplicação no local precisa de comutação por falha, configura o sistema de base de dados no Google Cloud para que possa aceitar o tráfego de produção. Também inicia instâncias do servidor Web e de aplicações.

O diagrama seguinte mostra a configuração após a comutação por falha para Google Cloud permitir que as cargas de trabalho de produção sejam servidas a partir de Google Cloud:

Configuração do padrão de aquecimento para recuperação quando a produção está no local

Uma sequência de recuperação típica é a seguinte:

  1. Redimensione a instância do servidor de base de dados para que possa processar cargas de produção.
  2. Use as imagens instantâneas do servidor Web e da aplicação em Google Cloud para criar novas instâncias do servidor Web e da aplicação.
  3. Teste se a aplicação funciona conforme esperado simulando cenários de utilizadores no ambiente recuperado.
  4. Quando os testes forem bem-sucedidos, configure o Cloud DNS para apontar para o seu serviço Web em Google Cloud.

Quando o ambiente de produção estiver novamente em execução no local e puder suportar cargas de trabalho de produção, inverta os passos que seguiu para fazer failover para o ambiente de recuperação. Google Cloud Uma sequência típica para regressar ao ambiente de produção é a seguinte:

  1. Faça uma cópia de segurança da base de dados em execução no Google Cloud.
  2. Copie o ficheiro de cópia de segurança para o ambiente de produção.
  3. Aplique o ficheiro de cópia de segurança ao seu sistema de base de dados de produção.
  4. Impedir ligações à aplicação em Google Cloud. Uma forma de o fazer é impedir as ligações ao servidor Web modificando as regras da firewall. A partir deste ponto, a sua aplicação vai ficar indisponível até terminar de restaurar o ambiente de produção.
  5. Copie todos os ficheiros de registo de transações para o ambiente de produção e aplique-os ao servidor de base de dados.
  6. Teste se a aplicação funciona conforme esperado simulando cenários de utilizadores no ambiente de produção.
  7. Configure o Cloud DNS para apontar para o seu serviço Web no local.
  8. Elimine as instâncias do servidor Web e do servidor de aplicações que estão a ser executadas em Google Cloud. Deixe os servidores de referência em execução.
  9. Redimensione o servidor de base de dados no Google Cloud tamanho mínimo da instância que pode aceitar dados replicados da base de dados de produção no local.
  10. Configure a replicação entre o servidor de base de dados no local e o servidor de base de dados no Google Cloud seguindo as instruções do software de base de dados.

HA ativo/ativo em implementações no local e na Google Cloud

Se tiver valores de RTO e RPO pequenos, só pode alcançá-los executando HA no seu ambiente de produção e Google Cloud em simultâneo. Esta abordagem dá-lhe um padrão ativo, porque tanto a implementação no local como a Google Cloud estão a publicar tráfego de produção.

A principal diferença em relação ao padrão de aquecimento é que os recursos em ambos os ambientes estão a ser executados no modo de produção e a servir tráfego de produção.

Este padrão usa as seguintes bases de dados de registos detalhados:

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

O diagrama seguinte ilustra esta arquitetura de exemplo. Ao implementar esta arquitetura, tem um plano de recuperação de desastres que requer uma intervenção mínima em caso de desastre.

Arquitetura para um padrão frequente quando a produção está no local

Os passos seguintes descrevem como pode configurar o ambiente:

  1. Crie uma rede de VPC.
  2. Configure a conetividade entre a sua rede no local e a sua rede Google Cloud .
  3. Crie imagens personalizadas que estejam configuradas para cada servidor no ambiente de produção no local. Google Cloud Cada Google Cloud imagem deve ter a mesma configuração que o seu equivalente no local.

  4. Configure a replicação entre o servidor de base de dados no local e o servidor de base de dados no Google Cloud seguindo as instruções do software de base de dados.

    Muitos sistemas de base de dados permitem apenas uma instância de base de dados gravável quando configura a replicação. Por conseguinte, pode ter de garantir que uma das réplicas da base de dados funciona como um servidor só de leitura.

  5. Crie modelos de instâncias individuais que usam as imagens para os servidores de aplicações e os servidores Web.

  6. Configure grupos de instâncias geridas regionais para os servidores de aplicações e Web.

  7. Configure verificações de funcionamento com o Cloud Monitoring.

  8. Configure o equilíbrio de carga usando os grupos de instâncias geridas regionais que foram configurados anteriormente.

  9. Configure uma tarefa agendada para criar capturas de ecrã regulares dos discos persistentes.

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

Com esta abordagem híbrida, tem de usar um serviço DNS que suporte o encaminhamento ponderado para os dois ambientes de produção, para poder publicar a mesma aplicação a partir de ambos.

Tem de criar o sistema para falhas que possam ocorrer apenas numa parte de um ambiente (falhas parciais). Nesse caso, o tráfego deve ser reencaminhado para o serviço equivalente no outro ambiente de segurança. Por exemplo, se os servidores Web no local ficarem indisponíveis, pode desativar o encaminhamento de DNS para esse ambiente. Se o seu serviço DNS suportar verificações de estado, estas ocorrem automaticamente quando a verificação de estado determina que não é possível alcançar os servidores Web num dos ambientes.

Se estiver a usar um sistema de base de dados que permita apenas uma única instância gravável, em muitos casos, o sistema de base de dados promove automaticamente a réplica só de leitura para ser a principal gravável quando o sinal de pulsação entre a base de dados gravável original e a réplica de leitura perde o contacto. Certifique-se de que compreende este aspeto da replicação da base de dados caso precise de intervir após um desastre.

Tem de implementar processos para garantir que as imagens de VMs personalizadas no Google Cloud têm a mesma versão da aplicação que as versões no local. Incorpore atualizações às imagens personalizadas como parte do seu ciclo de atualização padrão e certifique-se de que o modelo do Deployment Manager está a usar a imagem personalizada mais recente.

Processo de comutação por falha e tarefas após o reinício

Na configuração descrita aqui para um cenário de emergência, um desastre significa que um dos dois ambientes não está disponível. Não existe um processo de alternativa da mesma forma que existe nos cenários de aquecimento ou arrefecimento, em que tem de mover dados ou processamento para o segundo ambiente. No entanto, pode ter de tratar as seguintes alterações de configuração:

  • Se o seu serviço DNS não redirecionar automaticamente o tráfego com base numa falha na verificação do estado, tem de configurar manualmente o encaminhamento DNS para enviar tráfego para o sistema que ainda está em funcionamento.
  • Se o seu sistema de base de dados não promover automaticamente uma réplica só de leitura para ser a principal gravável em caso de falha, tem de intervir para garantir que a réplica é promovida.

Quando o segundo ambiente estiver novamente em execução e puder processar o tráfego de produção, tem de ressincronizar as bases de dados. Uma vez que ambos os ambientes suportam cargas de trabalho de produção, não tem de tomar mais nenhuma medida para alterar a base de dados principal. Depois de as bases de dados serem sincronizadas, pode permitir que o tráfego de produção seja novamente distribuído por ambos os ambientes ajustando as definições de DNS.

Arquiteturas de RD e AD para produção no Google Cloud

Quando cria a arquitetura da sua aplicação para a carga de trabalho de produção no Google Cloud, as funcionalidades de AD da plataforma têm uma influência direta na sua arquitetura de RD.

O serviço de cópia de segurança e RD é uma solução centralizada nativa da nuvem para fazer cópias de segurança e recuperar cargas de trabalho na nuvem e híbridas. Oferece uma recuperação de dados rápida e facilita a retoma rápida das operações empresariais essenciais.

Para mais informações sobre a utilização do serviço de cópia de segurança e RD para cenários de aplicações no Google Cloud, consulte o seguinte:

Frio: servidor de aplicações recuperável

Num cenário de comutação por falha a frio em que precisa de uma única instância de servidor ativa, apenas uma instância deve escrever no disco. Num ambiente no local, usa frequentemente um cluster ativo / passivo. Quando executa um ambiente de produção no Google Cloud, pode criar uma VM num grupo de instâncias geridas que só executa uma instância.

Este padrão usa as seguintes bases de dados de registos detalhados:

  • Compute Engine
  • Grupos de instâncias geridas

Este cenário de comutação por falha a frio é apresentado na seguinte imagem de arquitetura:

Configuração do padrão de arranque a frio para recuperação quando a produção está em Google Cloud

Os passos seguintes descrevem como configurar este cenário de comutação por falha a frio:

  1. Crie uma rede de VPC.
  2. Crie uma imagem de VM personalizada configurada com o serviço Web da sua aplicação.
    1. Configure a VM para que os dados processados pelo serviço de aplicação sejam escritos num disco persistente anexado.
  3. Crie um instantâneo a partir do disco persistente anexado.
  4. Crie um modelo de instância que faça referência à imagem de VM personalizada para o servidor Web.
    1. Configure um script de arranque para criar um disco persistente a partir do instantâneo mais recente e montar o disco. Este script tem de conseguir obter o instantâneo mais recente do disco.
  5. Crie um grupo de instâncias gerido e verificações de funcionamento com um tamanho de destino de um que faça referência ao modelo de instância.
  6. Crie uma tarefa agendada para criar capturas de ecrã regulares do disco persistente.
  7. Configure um balanceador de carga de aplicações externo.
  8. Configure alertas através do Cloud Monitoring para enviar um alerta quando o serviço falha.

Este cenário de comutação em caso de falha a frio tira partido de algumas das funcionalidades de HA disponíveis no Google Cloud. Se uma VM falhar, o grupo de instâncias geridas tenta recriar a VM automaticamente. Não tem de iniciar este passo de comutação por falha. O Application Load Balancer externo garante que, mesmo quando é necessária uma VM de substituição, o mesmo endereço IP é usado em frente do servidor de aplicações. O modelo de instância e a imagem personalizada garantem que a VM de substituição é configurada de forma idêntica à instância que substitui.

O RPO é determinado pela última captura de ecrã feita. Quanto mais frequentemente fizer instantâneos, menor é o valor de RPO.

O grupo de instâncias geridas oferece HA em profundidade. O grupo de instâncias gerido oferece formas de reagir a falhas ao nível da aplicação ou da VM. Não intervém manualmente se ocorrer algum desses cenários. Um tamanho de destino de um garante que tem sempre uma instância ativa que é executada no grupo de instâncias gerido e publica tráfego.

Os discos persistentes são zonais, pelo que tem de tirar capturas de ecrã para recriar discos se ocorrer uma falha zonal. As capturas de ecrã também estão disponíveis em várias regiões, o que lhe permite restaurar um disco para uma região diferente, de forma semelhante ao restauro para a mesma região.

No caso improvável de uma falha zonal, tem de intervir manualmente para fazer a recuperação, conforme descrito na secção seguinte.

Processo de comutação por falha

Se uma VM falhar, o grupo de instâncias geridas tenta automaticamente recriar uma VM na mesma zona. O script de arranque no modelo de instância cria um disco persistente a partir da captura de ecrã mais recente e anexa-o à nova VM.

No entanto, um grupo de instâncias gerido com um tamanho de um não é recuperado se houver uma falha de zona. No cenário em que uma zona falha, tem de reagir ao alerta do Cloud Monitoring ou de outra plataforma de monitorização quando o serviço falha e criar manualmente um grupo de instâncias noutra zona.

Uma variação desta configuração é usar discos persistentes regionais em vez de discos persistentes zonais. Com esta abordagem, não precisa de usar instantâneos para restaurar o disco persistente como parte do passo de recuperação. No entanto, esta variação consome o dobro do armazenamento e tem de ter isso em conta no orçamento.

A abordagem que escolher é determinada pelo seu orçamento e pelos valores de RTO e RPO.

Quente: alternativa de site estático

Se as instâncias do Compute Engine falharem, pode mitigar a interrupção do serviço tendo um site estático baseado no Cloud Storage em espera. Este padrão é adequado quando a sua aplicação Web é maioritariamente estática.

Neste cenário, a aplicação principal é executada em instâncias do Compute Engine. Estas instâncias estão agrupadas em grupos de instâncias geridos e os grupos de instâncias funcionam como serviços de back-end para um balanceador de carga HTTPS. O balanceador de carga HTTP direciona o tráfego recebido para as instâncias de acordo com a configuração do balanceador de carga, a configuração de cada grupo de instâncias e o estado de funcionamento de cada instância.

Este padrão usa as seguintes bases de dados de registos detalhados:

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

O diagrama seguinte ilustra esta arquitetura de exemplo:

Arquitetura para uma comutação por falha a quente para um site estático quando a produção está em Google Cloud

Os passos seguintes descrevem como configurar este cenário:

  1. Crie uma rede de VPC.
  2. Crie uma imagem personalizada configurada com o serviço Web da aplicação.
  3. Crie um modelo de instância que use a imagem para os servidores Web.
  4. Configure um grupo de instâncias geridas para os servidores Web.
  5. Configure verificações de funcionamento através da Monitorização.
  6. Configure o equilíbrio de carga através dos grupos de instâncias geridas que configurou anteriormente.
  7. Crie um site estático baseado no Cloud Storage.

Na configuração de produção, o Cloud DNS está configurado para apontar para esta aplicação principal, e o site estático de reserva permanece inativo. Se a aplicação do Compute Engine ficar indisponível, configuraria o Cloud DNS para apontar para este site estático.

Processo de comutação por falha

Se o servidor ou os servidores de aplicações ficarem inativos, a sequência de recuperação consiste em configurar o Cloud DNS para apontar para o seu Website estático. O diagrama seguinte mostra a arquitetura no respetivo modo de recuperação:

Configuração após a comutação por falha para um site estático quando a produção está em Google Cloud.

Quando as instâncias do Compute Engine da aplicação estiverem novamente em execução e puderem suportar cargas de trabalho de produção, inverta o passo de recuperação: configure o Cloud DNS para apontar para o balanceador de carga que está à frente das instâncias.

Em alternativa, pode usar a replicação assíncrona do disco persistente. Oferece replicação de armazenamento de blocos com um objetivo de ponto de recuperação (RPO) baixo e um objetivo de tempo de recuperação (RTO) baixo para recuperação de desastres ativa-passiva entre regiões. Esta opção de armazenamento permite-lhe gerir a replicação para cargas de trabalho do Compute Engine ao nível da infraestrutura, em vez de ao nível da carga de trabalho.

Hot: HA web application

Um padrão frequente quando o seu ambiente de produção está em execução no Google Cloud é estabelecer uma implementação de HA bem arquitetada.

Este padrão usa as seguintes bases de dados de registos detalhados:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

O diagrama seguinte ilustra esta arquitetura de exemplo:

Arquitetura de padrões frequentes quando a produção está no Google Cloud

Este cenário tira partido das funcionalidades de HA no Google Cloud. Não tem de iniciar nenhum passo de comutação por falha, porque ocorrem automaticamente em caso de desastre.

Conforme mostrado no diagrama, a arquitetura usa um grupo de instâncias gerido regional juntamente com o balanceamento de carga global e o Cloud SQL. O exemplo aqui usa um grupo de instâncias geridas regional, pelo que as instâncias são distribuídas por três zonas.

Com esta abordagem, obtém HA em profundidade. Os grupos de instâncias geridos regionais oferecem mecanismos para reagir a falhas ao nível da aplicação, da instância ou da zona, e não tem de intervir manualmente se ocorrer algum desses cenários.

Para resolver a recuperação ao nível da aplicação, como parte da configuração do grupo de instâncias gerido, configura verificações de estado HTTP que validam se os serviços estão a ser executados corretamente nas instâncias desse grupo. Se uma verificação de estado determinar que um serviço falhou numa instância, o grupo volta a criar automaticamente essa instância.

Para mais informações sobre a criação de aplicações escaláveis e resilientes no Google Cloud, consulte Padrões para apps escaláveis e resilientes .

O que se segue?