Conforme descrito na secção Disponibilidade da plataforma, a infraestrutura do Google Cloud foi concebida para suportar uma disponibilidade alvo de 99,9% para uma carga de trabalho implementada numa única zona.Google Cloud A disponibilidade alvo é de 99,99% para uma implementação em várias zonas1 e de 99,999% para uma implementação em várias regiões. Esta parte do Google Cloud guia de fiabilidade da infraestrutura fornece orientações de implementação, exemplos de arquiteturas e técnicas de design que podem ajudar a proteger as suas cargas de trabalho contra falhas ao nível do recurso, da zona e da região.
Evite pontos únicos de falha
Normalmente, as aplicações são compostas por vários componentes interdependentes, cada um concebido para executar uma função específica. Normalmente, estes componentes são agrupados em níveis com base na função que desempenham e na respetiva relação com os outros componentes. Por exemplo, uma aplicação de fornecimento de conteúdo pode ter três níveis: um nível Web que contém um equilibrador de carga e servidores Web; um nível de app com um cluster de servidores de aplicações; e um nível de dados para persistência. Se qualquer componente desta pilha de aplicações depender de um único recurso de infraestrutura, uma falha desse recurso pode afetar a disponibilidade de toda a pilha. Por exemplo, se a camada de apps for executada numa única VM e se a VM falhar, toda a pilha fica efetivamente indisponível. Este componente é um ponto único de falha (SPOF).
Uma pilha de aplicações pode ter mais do que um SPOF. Considere a pilha de aplicações de vários níveis apresentada no diagrama seguinte:
Conforme mostrado no diagrama anterior, esta arquitetura de exemplo contém um único equilibrador de carga, dois servidores Web, um único servidor de apps e uma única base de dados. O balanceador de carga, o servidor de apps e a base de dados neste exemplo são SPOFs. Uma falha de qualquer um destes componentes pode fazer com que os pedidos dos utilizadores à aplicação falhem.
Para remover os SPOFs na sua pilha de apps, distribua os recursos por várias localizações e implemente recursos redundantes.
Distribua recursos e crie redundância
Consoante os requisitos de fiabilidade da sua aplicação, pode escolher entre as seguintes arquiteturas de implementação:
| Arquitetura | Recomendação da carga de trabalho |
|---|---|
| Multirregião | Cargas de trabalho essenciais para a empresa e onde a elevada disponibilidade é essencial, como aplicações de redes sociais e de retalho. |
| Várias zonas | Cargas de trabalho que precisam de resiliência contra falhas de zonas, mas podem tolerar algum tempo de inatividade causado por falhas de regiões. |
| Zona única | Cargas de trabalho que podem tolerar o tempo de inatividade ou que podem ser implementadas noutra localização quando necessário com o mínimo de esforço. |
Considerações sobre o custo, a latência e as operações
Quando cria uma arquitetura distribuída com recursos redundantes, além dos requisitos de disponibilidade da aplicação, também tem de considerar os efeitos na complexidade operacional, na latência e no custo.
Numa arquitetura distribuída, aprovisiona e gere um número superior de recursos. O volume de tráfego de rede entre localizações é mais elevado. Também armazenam e replicam mais dados. Consequentemente, o custo dos seus recursos na nuvem numa arquitetura distribuída é mais elevado e a operação dessas implementações envolve mais complexidade. Para aplicações essenciais para o negócio, a vantagem da disponibilidade de uma arquitetura distribuída pode compensar o aumento do custo e da complexidade operacional.
Para aplicações que não são essenciais para a empresa, a alta disponibilidade que uma arquitetura distribuída oferece pode não ser essencial. Determinadas aplicações têm outros requisitos mais importantes do que a disponibilidade. Por exemplo, as aplicações de computação em lote requerem ligações de rede de baixa latência e elevada largura de banda entre as VMs. Uma arquitetura de zona única pode ser adequada para essas aplicações e também pode ajudar a reduzir os custos de transferência de dados.
Arquiteturas de implementação
Esta secção apresenta as seguintes opções de arquitetura para criar infraestrutura para as suas cargas de trabalho no Google Cloud:
- Implementação de zona única
- Implementação em várias zonas
- Implementação multirregião com balanceamento de carga regional
- Implementação multirregião com balanceamento de carga global
Implementação de zona única
O diagrama seguinte mostra uma arquitetura de aplicação de zona única com redundância em todos os níveis, para alcançar uma maior disponibilidade das funções executadas por cada componente:
Conforme mostrado no diagrama anterior, esta arquitetura de exemplo inclui os seguintes componentes:
- Um balanceador de carga HTTP/S externo regional para receber e responder a pedidos dos utilizadores.
- Um grupo de instâncias geridas (GIG) zonal como back-end para o balanceador de carga HTTP/S. O GIG tem duas VMs do Compute Engine. Cada MV aloja uma instância de um servidor Web.
- Um balanceador de carga interno para processar a comunicação entre o servidor Web e as instâncias do servidor de apps.
- Um segundo MIG zonal como back-end para o balanceador de carga interno. Este GIG contém duas VMs do Compute Engine. Cada VM aloja uma instância de um servidor de aplicações.
- Uma instância de base de dados do Cloud SQL (edição Enterprise) para a qual a aplicação escreve dados e a partir da qual lê dados. A base de dados é replicada manualmente para uma segunda instância da base de dados do Cloud SQL na mesma zona.
Disponibilidade agregada: implementação de zona única
A tabela seguinte mostra a disponibilidade de cada nível no diagrama de arquitetura de zona única anterior:
| Recurso | SLA |
|---|---|
| Balanceador de carga externo | 99,99% |
| Nível Web: VMs do Compute Engine numa única zona | 99,9% |
| Balanceador de carga interno | 99,99% |
| Nível da aplicação: VMs do Compute Engine numa única zona | 99,9% |
| Instância do Cloud SQL (edição Enterprise) | 99,95% |
Pode esperar que os Google Cloud recursos de infraestrutura indicados na tabela anterior ofereçam a seguinte disponibilidade agregada e tempo de inatividade mensal máximo estimado:
- Disponibilidade agregada: 0,9999 x 0,999 x 0,9999 x 0,999 x 0,9995 = 99,73%
- Tempo de inatividade mensal máximo estimado: aproximadamente 1 hora e 57 minutos
Este cálculo considera apenas os recursos de infraestrutura apresentados no diagrama de arquitetura anterior. Para avaliar a disponibilidade de uma aplicação em Google Cloud, também tem de considerar outros fatores, como os seguintes:
- O design interno da aplicação
- Os processos e as ferramentas de DevOps usados para criar, implementar e manter a aplicação, as respetivas dependências e a Google Cloud infraestrutura
Para mais informações, consulte o artigo Fatores que afetam a fiabilidade da aplicação.
Efeitos das indisponibilidades e orientações para a recuperação
Numa arquitetura de implementação de zona única, se algum componente falhar, a aplicação pode processar pedidos se cada camada contiver, pelo menos, um componente funcional com capacidade adequada. Por exemplo, se uma instância do servidor Web falhar, o balanceador de carga encaminha os pedidos dos utilizadores para as outras instâncias do servidor Web. Se uma VM que aloja uma instância de servidor Web ou servidor de apps falhar, o MIG garante que é criada automaticamente uma nova VM. Se a base de dados falhar, tem de ativar manualmente a segunda base de dados e atualizar as instâncias do servidor de apps para estabelecer ligação à base de dados.
Uma interrupção de zona ou de região afeta as VMs do Compute Engine e as instâncias de base de dados do Cloud SQL numa implementação de zona única. Uma indisponibilidade de zona não afeta o balanceador de carga nesta arquitetura porque é um recurso regional. No entanto, o balanceador de carga não pode distribuir o tráfego porque não existem back-ends disponíveis. Se ocorrer uma indisponibilidade de zona, tem de aguardar que a Google resolva a indisponibilidade e, em seguida, verificar se a aplicação funciona conforme esperado.
A secção seguinte descreve uma abordagem arquitetónica que pode usar para distribuir recursos em várias zonas, o que ajuda a melhorar a resiliência da aplicação a falhas de zonas.
Implementação em várias zonas
Numa implementação de zona única, se ocorrer uma indisponibilidade de zona, a aplicação pode não conseguir publicar pedidos até o problema ser resolvido. Para ajudar a melhorar a resiliência da sua aplicação contra falhas de zonas, pode aprovisionar várias instâncias de recursos zonais (como VMs do Compute Engine) em duas ou mais zonas. Para serviços que suportam recursos com âmbito regional (como contentores do Cloud Storage), pode implementar recursos regionais.
O diagrama seguinte mostra uma arquitetura entre zonas de elevada disponibilidade, com os componentes em cada camada da pilha de aplicações distribuídos por duas zonas:
Conforme mostrado no diagrama anterior, esta arquitetura de exemplo inclui os seguintes componentes:
- Um balanceador de carga HTTP/S externo regional recebe e responde a pedidos dos utilizadores.
- Um MIG regional é o back-end do balanceador de carga HTTP/S. O MIG contém duas VMs do Compute Engine em zonas diferentes. Cada MV aloja uma instância de um servidor Web.
- Um balanceador de carga interno processa a comunicação entre o servidor Web e as instâncias do servidor de apps.
- Um segundo MIG regional é o back-end do balanceador de carga TCP. Este MIG tem duas VMs do Compute Engine em zonas diferentes. Cada VM aloja uma instância de um servidor de apps.
- Uma instância do Cloud SQL (edição Enterprise) configurada para HA é a base de dados da aplicação. A instância de base de dados principal é replicada de forma síncrona para uma instância de base de dados em espera.
Disponibilidade agregada: implementação em várias zonas
A tabela seguinte mostra a disponibilidade de cada camada no diagrama de arquitetura de zona dupla anterior:
| Recurso | SLA |
|---|---|
| Balanceador de carga externo | 99,99% |
| Nível Web: VMs do Compute Engine em zonas separadas | 99,99% |
| Balanceador de carga interno | 99,99% |
| Nível da aplicação: VMs do Compute Engine em zonas separadas | 99,99% |
| Instância do Cloud SQL (edição Enterprise) | 99,95% |
Pode esperar que os Google Cloud recursos de infraestrutura indicados na tabela anterior ofereçam a seguinte disponibilidade agregada e tempo de inatividade mensal máximo estimado:
- Disponibilidade agregada: 0,9999 x 0,9999 x 0,9999 x 0,9999 x 0,9995 = 99,91%
- Tempo de inatividade mensal máximo estimado: aproximadamente 39 minutos
Este cálculo considera apenas os recursos de infraestrutura apresentados no diagrama de arquitetura anterior. Para avaliar a disponibilidade de uma aplicação em Google Cloud, também tem de considerar outros fatores, como os seguintes:
- O design interno da aplicação
- Os processos e as ferramentas de DevOps usados para criar, implementar e manter a aplicação, as respetivas dependências e a Google Cloud infraestrutura
Para mais informações, consulte o artigo Fatores que afetam a fiabilidade da aplicação.
Efeitos das indisponibilidades e orientações para a recuperação
Numa implementação de zona dupla, se algum componente falhar, a aplicação pode processar pedidos se existir, pelo menos, um componente funcional com capacidade adequada em cada nível. Por exemplo, se uma instância do servidor Web falhar, o balanceador de carga encaminha os pedidos dos utilizadores para a instância do servidor Web na outra zona. Se uma VM que aloja uma instância de servidor Web ou servidor de apps falhar, o MIG garante que é criada automaticamente uma nova VM. Se a base de dados principal do Cloud SQL falhar, o Cloud SQL faz automaticamente a comutação por falha para a instância de base de dados em espera.
O diagrama seguinte mostra a mesma arquitetura que o diagrama anterior e os efeitos de uma indisponibilidade de zona na disponibilidade da aplicação:
Conforme mostrado no diagrama anterior, se ocorrer uma indisponibilidade numa das zonas, o balanceador de carga nesta arquitetura não é afetado, porque é um recurso regional. Uma indisponibilidade de zona pode afetar VMs do Compute Engine individuais e uma das instâncias de base de dados do Cloud SQL. No entanto, a aplicação permanece disponível e responsiva, porque as VMs estão em MIGs regionais e a base de dados do Cloud SQL está configurada para HA. Os MIGs garantem que são criadas automaticamente novas VMs para manter o número mínimo configurado de VMs. Se a instância de base de dados do Cloud SQL principal for afetada por uma indisponibilidade de zona, o Cloud SQL faz a comutação por falha automaticamente para a instância de reserva na outra zona. Depois de a Google resolver a indisponibilidade, tem de verificar se a aplicação é executada conforme esperado em todas as zonas onde está implementada.
Se ambas as zonas nesta arquitetura tiverem uma interrupção, a aplicação fica indisponível. O balanceador de carga continua disponível, a menos que ocorra uma interrupção ao nível da região. No entanto, o equilibrador de carga não pode distribuir o tráfego porque não existem back-ends disponíveis. Se ocorrer uma indisponibilidade em várias zonas ou numa região, tem de aguardar que a Google resolva a indisponibilidade e, em seguida, verificar se a aplicação funciona conforme esperado.
As secções seguintes apresentam opções de arquitetura para proteger a sua aplicação contra interrupções em várias zonas e interrupções na região.
Implementação multirregional com balanceamento de carga regional
Numa implementação de zona única ou várias zonas, se ocorrer uma indisponibilidade da região, a aplicação não pode publicar pedidos até o problema ser resolvido. Para proteger a sua aplicação contra falhas de regiões, pode distribuir os recursos por duas ou mais regiões. Google Cloud
O diagrama seguinte mostra uma arquitetura entre regiões altamente disponível, com os componentes em cada camada da pilha de aplicações distribuídos por várias regiões:
Conforme mostrado no diagrama anterior, esta arquitetura de exemplo inclui os seguintes componentes:
- Uma zona do Cloud DNS pública com uma política de encaminhamento que direciona o tráfego para duas Google Cloud regiões.
- Um balanceador de carga HTTP/S externo regional em cada região para receber e responder a pedidos dos utilizadores.
- O back-end de cada balanceador de carga HTTP/S regional é um MIG regional. Cada MIG contém duas VMs do Compute Engine em zonas diferentes. Cada uma destas VMs aloja uma instância de um servidor Web.
- Um equilibrador de carga interno em cada região processa a comunicação entre as instâncias do servidor Web e as instâncias do servidor de apps.
- Um segundo par de MIGs regionais é o back-end dos balanceadores de carga internos. Cada um destes MIGs contém duas VMs do Compute Engine em zonas diferentes. Cada VM aloja uma instância de um servidor de apps.
- A aplicação escreve dados e lê dados de uma instância do Spanner de várias regiões. A configuração multirregião usada nesta arquitetura (
eur5) inclui quatro réplicas de leitura/escrita. As réplicas de leitura/escrita são aprovisionadas igualmente em duas regiões e em zonas separadas. A configuração do Spanner multirregional também inclui uma réplica de testemunho numa terceira região.
Disponibilidade agregada: implementação em várias regiões com balanceamento de carga regional
Na implementação multirregional apresentada no diagrama anterior, os balanceadores de carga e as VMs são aprovisionados de forma redundante em duas regiões. A zona DNS é um recurso global e a instância do Spanner é um recurso de várias regiões.
Para calcular a disponibilidade agregada da infraestrutura apresentada nesta arquitetura, temos de calcular primeiro a disponibilidade agregada dos recursos em cada região e, em seguida, considerar os recursos que abrangem várias regiões. Google CloudUse o seguinte processo:
- Calcular a disponibilidade agregada dos recursos de infraestrutura
por região, ou seja, excluindo os recursos de DNS e de base de dados:
Recurso e SLA SLA Balanceador de carga externo 99,99% Nível Web: VMs do Compute Engine em zonas separadas 99,99% Balanceador de carga interno 99,99% Nível da aplicação: VMs do Compute Engine em zonas separadas 99,99% Disponibilidade agregada por região: 0,9999 x 0,9999 x 0,9999 x 0,9999 = 99,96%
Calcular a disponibilidade agregada dos recursos de infraestrutura tendo em conta a redundância de dupla região dos equilibradores de carga e das VMs do Compute Engine.
A disponibilidade teórica é 1-(1-0,9996)(1-0,9996) = 99,999984%. No entanto, a disponibilidade real que pode esperar está limitada à disponibilidade de destino para implementações multirregionais, que é de 99,999%.
Calcule a disponibilidade agregada de todos os recursos de infraestrutura, incluindo os recursos do Cloud DNS e do Spanner:
- Disponibilidade agregada: 0,99999 x 1 x 0,99999 = 99,998%
- Tempo de inatividade mensal máximo estimado: aproximadamente 52 segundos
Este cálculo considera apenas os recursos de infraestrutura apresentados no diagrama de arquitetura anterior. Para avaliar a disponibilidade de uma aplicação em Google Cloud, também tem de considerar outros fatores, como os seguintes:
- O design interno da aplicação
- Os processos e as ferramentas de DevOps usados para criar, implementar e manter a aplicação, as respetivas dependências e a Google Cloud infraestrutura
Para mais informações, consulte o artigo Fatores que afetam a fiabilidade da aplicação.
Efeitos das indisponibilidades e orientações para a recuperação
Se qualquer componente nesta implementação em várias regiões falhar, mas existir, pelo menos, um componente a funcionar com capacidade adequada em cada nível, a aplicação continua a funcionar. Por exemplo, se uma instância do servidor Web falhar, o balanceador de carga HTTP/S externo regional encaminha os pedidos dos utilizadores para as outras instâncias do servidor Web na região. Da mesma forma, se uma das instâncias do servidor de apps falhar, os balanceadores de carga internos enviam pedidos para as outras instâncias do servidor de apps. Se alguma das VMs falhar, os MIGs garantem que são criadas automaticamente novas VMs para manter o número mínimo configurado de VMs.
Uma indisponibilidade numa única zona não afeta os balanceadores de carga, porque são recursos regionais e são resilientes a indisponibilidades de zonas. Uma indisponibilidade de zona pode afetar VMs individuais do Compute Engine. No entanto, as instâncias do servidor Web e do servidor de apps permanecem disponíveis, porque as VMs fazem parte de MIGs regionais. Os MIGs garantem que as novas VMs são criadas automaticamente para manter o número mínimo configurado de VMs. A instância do Spanner nesta arquitetura usa uma configuração multirregional, que é resiliente a interrupções de zonas.
Para obter informações sobre como funciona a replicação em várias regiões no Spanner, consulte os artigos Configurações regionais e de várias regiões e Desmistificar as configurações de várias regiões do Spanner.
O diagrama seguinte mostra a mesma arquitetura de várias regiões que o diagrama anterior e os efeitos de uma indisponibilidade de uma única região na disponibilidade da aplicação:
Conforme mostrado no diagrama anterior, mesmo que ocorra uma indisponibilidade em ambas as zonas de qualquer região, a aplicação permanece disponível, porque é implementada uma pilha de aplicações independente em cada região. A zona DNS encaminha os pedidos dos utilizadores para a região que não é afetada pela indisponibilidade. A instância do Spanner de várias regiões é resiliente a interrupções regionais. Depois de a Google resolver a indisponibilidade, tem de verificar se a aplicação é executada conforme esperado na região que teve a indisponibilidade.
Se duas das regiões nesta arquitetura tiverem interrupções, a aplicação fica indisponível. Aguarde até que a Google resolva as indisponibilidades. Em seguida, verifique se a aplicação é executada conforme esperado em todas as regiões onde está implementada.
Para implementações multirregionais, em vez de usar balanceadores de carga regionais, pode considerar usar um balanceador de carga global. A secção seguinte apresenta uma arquitetura de implementação em várias regiões que usa um equilibrador de carga global e descreve as vantagens e os riscos dessa abordagem.
Implementação em várias regiões com balanceamento de carga global
O diagrama seguinte mostra uma implementação multirregional alternativa que usa um balanceador de carga global em vez de balanceadores de carga regionais:
Conforme mostrado no diagrama anterior, esta arquitetura usa um balanceador de carga de HTTP/S externo global (com a RFC ativada) para receber e responder a pedidos de utilizadores. Cada regra de encaminhamento do equilibrador de carga usa um único endereço IP externo. Não precisa de configurar um registo DNS separado para cada região. Os back-ends do balanceador de carga HTTP/S externo global são dois MIGs regionais. O balanceador de carga encaminha os pedidos para a região mais próxima dos utilizadores.
Todos os outros componentes nesta arquitetura são idênticos à arquitetura apresentada na Implementação em várias regiões com equilíbrio de carga regional.
Vantagens e riscos do balanceamento de carga global para implementações em várias regiões
Para equilibrar a carga do tráfego externo para uma aplicação distribuída por várias regiões, pode usar um balanceador de carga global ou vários balanceadores de carga regionais.
Seguem-se as vantagens de uma arquitetura que usa um equilibrador de carga global:
- Só precisa de gerir um único equilibrador de carga.
- Os balanceadores de carga globais usam um único endereço IP anycast para fornecer balanceamento de carga em várias regiões. Google Cloud
- Os balanceadores de carga globais são resilientes a falhas de regiões e oferecem uma comutação por falha automática entre regiões.
- Os balanceadores de carga globais suportam as seguintes funcionalidades, que podem ajudar a melhorar a fiabilidade das suas implementações:
- Cache edge com o Cloud CDN
- Capacidade de usar contentores do Cloud Storage altamente duradouros como back-ends
- Políticas de segurança do Google Cloud Armor
Seguem-se os riscos de uma arquitetura que usa um balanceador de carga global:
- Uma alteração de configuração incorreta ao equilibrador de carga global pode tornar a aplicação indisponível para os utilizadores. Por exemplo, ao atualizar o front-end do balanceador de carga global, se eliminar acidentalmente uma regra de encaminhamento, o balanceador de carga deixa de receber pedidos dos utilizadores. O efeito deste risco é menor no caso de uma arquitetura multirregional que usa balanceadores de carga regionais, porque, mesmo que o balanceador de carga regional numa das regiões seja afetado por um erro de configuração, os balanceadores de carga nas outras regiões continuam a funcionar.
- Uma indisponibilidade da infraestrutura que afete os recursos globais pode tornar o balanceador de carga global indisponível.
Para mitigar estes riscos, tem de gerir cuidadosamente as alterações ao equilibrador de carga global e considerar a utilização de alternativas de defesa em profundidade sempre que possível. Para mais informações, consulte as recomendações para gerir o risco de indisponibilidade de recursos globais.
Disponibilidade agregada: implementação em várias regiões com balanceamento de carga global
Na implementação multirregional apresentada no diagrama anterior, as VMs e os balanceadores de carga internos são distribuídos de forma redundante em duas regiões. O balanceador de carga externo é um recurso global, e a instância do Spanner é um recurso de várias regiões.
Para calcular a disponibilidade agregada desta implementação, primeiro calculamos a disponibilidade agregada dos recursos em cada região e, em seguida, consideramos os recursos que abrangem várias regiões.
- Calcular a disponibilidade agregada dos recursos de infraestrutura
por região, excluindo o equilibrador de carga externo e a base de dados:
Recurso SLA Nível Web: VMs do Compute Engine em zonas separadas 99,99% Balanceador de carga interno 99,99% Nível da aplicação: VMs do Compute Engine em zonas separadas 99,99% Disponibilidade agregada por região: 0,9999 x 0,9999 x 0,9999 = 99,97%
Calcular a disponibilidade agregada dos recursos de infraestrutura considerando a redundância de duas regiões do balanceador de carga interno e das VMs do Compute Engine.
A disponibilidade teórica é 1-(1-0,9997)(1-0,9997) = 99,999991%. No entanto, a disponibilidade real que pode esperar está limitada à disponibilidade de destino para implementações em várias regiões, que é de 99,999%.
Calcule a disponibilidade agregada de todos os recursos de infraestrutura, incluindo o balanceador de carga global e os recursos do Spanner:
- Disponibilidade agregada: 0,99999 x 0,9999 x 0,99999 = 99,988%
- Tempo de inatividade mensal máximo estimado: aproximadamente 5 minutos e 11 segundos
Este cálculo considera apenas os recursos de infraestrutura apresentados no diagrama de arquitetura anterior. Para avaliar a disponibilidade de uma aplicação em Google Cloud, também tem de considerar outros fatores, como os seguintes:
- O design interno da aplicação
- Os processos e as ferramentas de DevOps usados para criar, implementar e manter a aplicação, as respetivas dependências e a Google Cloud infraestrutura
Para mais informações, consulte o artigo Fatores que afetam a fiabilidade da aplicação.
Efeitos das indisponibilidades e orientações para a recuperação
Se qualquer componente nesta arquitetura falhar, a aplicação continua a funcionar se existir, pelo menos, um componente funcional com capacidade adequada em cada nível. Por exemplo, se uma instância do servidor Web falhar, o balanceador de carga HTTP/S externo global encaminha os pedidos dos utilizadores para as outras instâncias do servidor Web. Se uma instância do servidor de apps falhar, os balanceadores de carga internos enviam os pedidos para as outras instâncias do servidor de apps. Se alguma das VMs falhar, os GIGs garantem que são criadas automaticamente novas VMs para manter o número mínimo configurado de VMs.
Se ocorrer uma indisponibilidade numa das zonas de qualquer região, o balanceador de carga não é afetado. O balanceador de carga HTTP/S externo global é resiliente a interrupções de zonas e regiões. Os balanceadores de carga internos são recursos regionais e são resilientes a falhas de zonas. Uma indisponibilidade de zona pode afetar VMs do Compute Engine individuais. No entanto, as instâncias do servidor Web e do servidor de apps permanecem disponíveis, porque as VMs fazem parte dos MIGs regionais. Os MIGs garantem que as VMs são criadas automaticamente para manter o número mínimo configurado de VMs. A instância do Spanner nesta arquitetura usa uma configuração de várias regiões, que é resiliente a interrupções de zonas.
O diagrama seguinte mostra a mesma arquitetura de várias regiões que o diagrama anterior e os efeitos de uma indisponibilidade de uma única região na disponibilidade da aplicação:
Conforme mostrado no diagrama anterior, mesmo que ocorra uma indisponibilidade em ambas as zonas de qualquer região, a aplicação permanece disponível, porque é implementada uma pilha de aplicações independente em cada região. O balanceador de carga HTTP/S externo global encaminha os pedidos dos utilizadores para a aplicação na região que não é afetada pela indisponibilidade. A instância do Spanner multirregional é resiliente a interrupções regionais. Depois de a Google resolver a indisponibilidade, tem de verificar se a aplicação é executada conforme esperado na região que teve a indisponibilidade.
Para obter informações sobre como funciona a replicação em várias regiões no Spanner, consulte os artigos Configurações regionais e de várias regiões e Desmistificar as configurações de várias regiões do Spanner.
Se duas das regiões nesta arquitetura tiverem interrupções, a aplicação fica indisponível. O balanceador de carga HTTP/S externo global está disponível, mas não consegue distribuir o tráfego porque não existem back-ends disponíveis. Aguarde até que a Google resolva as indisponibilidades. Em seguida, verifique se a aplicação é executada conforme esperado em todas as regiões onde está implementada.
As implementações em várias regiões podem ajudar a garantir a elevada disponibilidade das suas aplicações empresariais mais críticas. Para garantir a continuidade do negócio durante eventos de falha, além de implementar a aplicação em várias regiões, tem de tomar determinados passos adicionais. Por exemplo, tem de fazer o planeamento da capacidade para garantir que é reservada capacidade suficiente em todas as regiões ou que os riscos associados ao dimensionamento automático de emergência são aceitáveis. Também tem de implementar práticas operacionais para testes de recuperação de desastres, gerir incidentes, validar o estado da aplicação após incidentes e realizar retrospetivas.
-
Para mais informações sobre considerações específicas da região, consulte o artigo Geografia e regiões. ↩