Google Cloud Os serviços de infraestrutura são executados em localizações em todo o mundo. As localizações estão divididas em domínios de falhas denominados regiões e zonas, que são os blocos de construção fundamentais para conceber uma infraestrutura fiável para as suas cargas de trabalho na nuvem.
Um domínio de falha é um recurso ou um grupo de recursos que pode falhar independentemente de outros recursos. Uma VM do Compute Engine autónoma é um exemplo de um recurso que é um domínio de falhas. Uma Google Cloud região ou uma zona é um exemplo de um domínio de falhas que consiste num grupo de recursos. Quando uma aplicação é distribuída de forma redundante em domínios de falhas, pode atingir um nível de disponibilidade agregado superior ao fornecido por cada domínio de falhas.
Esta parte do Google Cloud guia de fiabilidade da infraestrutura descreve os elementos básicos da fiabilidade no Google Cloud e como afetam a disponibilidade dos seus recursos na nuvem.
Regiões e zonas
As regiões são áreas geográficas independentes compostas por zonas. As zonas e as regiões são abstrações lógicas dos recursos físicos subjacentes. Para mais informações sobre considerações específicas da região, consulte o artigo Geografia e regiões.
Disponibilidade da plataforma
AGoogle Cloud infraestrutura foi concebida para tolerar e recuperar de falhas. A Google investe continuamente em abordagens inovadoras para manter e melhorar a fiabilidade do Google Cloud. As seguintes capacidades da Google Cloud infraestrutura ajudam a fornecer uma plataforma fiável para as suas cargas de trabalho na nuvem:
- Regiões geograficamente separadas para mitigar os efeitos de desastres naturais e interrupções de regiões nos serviços globais.
- Redundância e replicação de hardware para evitar pontos únicos de falha.
- Migração em direto de recursos durante eventos de manutenção. Por exemplo, durante a manutenção planeada da infraestrutura, as VMs do Compute Engine podem ser movidas para outro anfitrião na mesma zona através da migração em direto.
- Uma base de infraestrutura segura desde a conceção para a infraestrutura física e o software no qual o Google Cloud é executado, e controlos de segurança operacional para proteger os seus dados e cargas de trabalho. Google Cloud Para mais informações, consulte a vista geral do design de segurança da infraestrutura da Google.
- Uma rede de backbone de alto desempenho que usa uma abordagem de rede definida por software (SDN) avançada para a gestão de rede, com serviços de colocação em cache na extremidade para oferecer um desempenho consistente que se adapta bem.
- Monitorização e relatórios contínuos. Pode ver o estado dos Google Cloud serviços em todas as localizações através do Google Cloud painel de controlo de estado do serviço.
- Eventos anuais de testes de recuperação de desastres (DiRT) em toda a empresa para garantir que os Google Cloud serviços e as operações comerciais internas continuam a ser executados durante um desastre.
- Uma abordagem de gestão de alterações que enfatiza a fiabilidade em todas as fases do ciclo de vida de desenvolvimento de software para quaisquer alterações à plataforma e aos serviços. Google Cloud
Google Cloud A infraestrutura foi concebida para suportar os seguintes níveis de disponibilidade para a maioria das cargas de trabalho dos clientes:
| Localização da implementação | Disponibilidade (tempo de atividade) % | Tempo de inatividade máximo estimado |
|---|---|---|
| Zona única | 3 noves: 99,9% | 43,2 minutos num mês de 30 dias |
| Várias zonas numa região | Quatro noves: 99,99% | 4,3 minutos num mês de 30 dias |
| Várias regiões | Cinco noves: 99,999% | 26 segundos num mês de 30 dias |
As percentagens de disponibilidade na tabela anterior são objetivos. Os Contratos de nível de serviço (SLAs) específicos de determinados serviços podem ser diferentes destes objetivos de disponibilidade. Google Cloud Por exemplo, o contrato de nível de serviço de tempo de atividade para uma instância do Bigtable depende do número de clusters, da respetiva distribuição pelas localizações e da política de encaminhamento que configurar.
O SLA de tempo de atividade mínimo para uma instância do Bigtable com clusters em três ou mais regiões é de 99,999% se a política de encaminhamento multicluster estiver configurada. No entanto, se a política de encaminhamento de cluster único estiver configurada, o SLA de tempo de atividade mínimo é de 99,9%, independentemente do número de clusters e da respetiva distribuição.
Os diagramas nesta secção mostram instâncias do Bigtable com tamanhos de clusters variáveis e as consequentes diferenças nos respetivos SLAs de tempo de atividade.
Cluster único
O diagrama seguinte mostra uma instância do Bigtable de cluster único com um SLA de tempo de atividade mínimo de 99, 9%:
Vários clusters
O diagrama seguinte mostra uma instância do Bigtable com vários clusters em várias zonas numa única região, com encaminhamento de vários clusters (SLA de tempo de atividade mínimo: 99,99%):
Vários clusters
O diagrama seguinte mostra uma instância do Bigtable com vários clusters em três regiões, com encaminhamento de vários clusters (SLA de tempo de atividade mínimo: 99,999%):
Disponibilidade agregada da infraestrutura
Esta secção descreve como calcular a disponibilidade agregada de uma pilha de infraestrutura no Google Cloud. Descreve os fatores que influenciam a disponibilidade agregada e fornece exemplos de cálculos.
Para executar as suas aplicações no Google Cloud, usa recursos de infraestrutura, como VMs e bases de dados. Estes recursos de infraestrutura, em conjunto, constituem a pilha de infraestrutura da sua aplicação. O diagrama seguinte mostra um exemplo de uma pilha de infraestrutura no Google Cloud e o SLA de disponibilidade para cada recurso na pilha:
Esta pilha de infraestrutura de exemplo inclui os seguintes Google Cloud recursos:
- Um Application Load Balancer externo regional recebe e responde a pedidos dos utilizadores.
- Um grupo de instâncias geridas (GIG) regional é o back-end do balanceador de carga de aplicações externo regional. 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 aplicações.
- Um segundo MIG regional é o back-end do balanceador de carga interno. Este MIG tem duas VMs do Compute Engine em zonas diferentes. Cada MV aloja uma instância de um servidor de aplicações.
- Uma instância do Cloud SQL 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 de reserva.
A disponibilidade agregada que pode esperar de uma pilha de infraestrutura, como no exemplo anterior, depende dos seguintes fatores:
Google Cloud SLAs
Os SLAs de tempo de atividade dos Google Cloud serviços que usa na sua pilha de infraestrutura influenciam a disponibilidade agregada mínima que pode esperar da pilha.
As tabelas seguintes apresentam uma comparação dos SLAs de tempo de atividade para alguns serviços:
| Serviços de computação | SLA de tempo de atividade mensal | Tempo de inatividade máximo estimado num mês de 30 dias |
|---|---|---|
| VM do Compute Engine | 99,9% | 43,2 minutos |
| Pods do GKE Autopilot em várias zonas | 99,9% | 43,2 minutos |
| Serviço do Cloud Run | 99,95% | 21,6 minutos |
| Serviços de base de dados | SLA de tempo de atividade mensal | Tempo de inatividade máximo estimado num mês de 30 dias |
|---|---|---|
| Instância do Cloud SQL para PostgreSQL (edição Enterprise) | 99,95% | 21,6 minutos |
| Instância do AlloyDB for PostgreSQL | 99,99% | 4,3 minutos |
| Instância multirregião do Spanner | 99,999% | 26 segundos |
Para os SLAs de outros Google Cloud serviços, consulte os Google Cloud contratos de nível de serviço.
Conforme mostram as tabelas anteriores, os Google Cloud serviços que escolher para cada nível da sua pilha de infraestrutura afetam diretamente o tempo de atividade geral que pode esperar da pilha de infraestrutura. Para aumentar a disponibilidade esperada de uma carga de trabalho implementada num recurso Google Cloud , pode aprovisionar instâncias redundantes do recurso, conforme descrito na secção seguinte.
Redundância de recursos
A redundância de recursos significa o aprovisionamento de duas ou mais instâncias idênticas de um recurso e a implementação da mesma carga de trabalho em todos os recursos do grupo. Por exemplo, para alojar a camada Web de uma aplicação, pode aprovisionar um MIG que contenha várias VMs do Compute Engine idênticas.
Se distribuir um grupo de recursos de forma redundante em vários domínios de falhas, por exemplo, duas zonas, a disponibilidade de recursos que pode esperar desse grupo é superior ao SLA de tempo de atividade de cada recurso no grupo. Google Cloud Esta maior disponibilidade deve-se ao facto de a probabilidade de todos os recursos no grupo falharem em simultâneo ser inferior à probabilidade de os recursos num único domínio de falha terem uma falha coordenada.
Por exemplo, se o SLA de disponibilidade de um recurso for de 99,9%, a probabilidade de o recurso falhar é de 0,001 (1 menos o SLA). Se distribuir uma carga de trabalho por duas instâncias deste recurso aprovisionadas em domínios de falhas separados, a probabilidade de falha dos dois recursos em simultâneo é de 0,000001 (ou seja, 0,001 x 0,001). Esta probabilidade de falha traduz-se numa disponibilidade teórica de 99,9999% para o grupo de dois recursos. No entanto, a disponibilidade real que pode esperar está limitada à disponibilidade de destino da localização de implementação: 99,9% se os recursos estiverem numa únicaGoogle Cloud zona, 99,99% para uma implementação em várias zonas e 99,999% se os recursos redundantes estiverem distribuídos por várias regiões.
Profundidade da pilha
A profundidade de uma pilha de infraestrutura é o número de camadas distintas na pilha. Cada nível numa pilha de infraestrutura contém recursos que fornecem uma função distinta para a aplicação. Por exemplo, a camada intermédia numa pilha de três camadas pode usar VMs do Compute Engine ou um cluster do GKE para alojar servidores de aplicações. Normalmente, cada camada numa pilha de infraestrutura tem uma interdependência estreita com as camadas adjacentes. Isto significa que, se qualquer nível da hierarquia estiver indisponível, toda a hierarquia fica indisponível.
Pode calcular a disponibilidade agregada esperada de uma pilha de infraestrutura de N camadas através da seguinte fórmula:
Por exemplo, se cada camada numa pilha de três camadas for concebida para oferecer uma disponibilidade de 99,9%, a disponibilidade agregada da pilha é de aproximadamente 99,7% (0,999 x 0,999 x 0,999). Isto significa que a disponibilidade agregada de uma hierarquia de vários níveis é inferior à disponibilidade do nível que oferece a menor disponibilidade.
À medida que o número de níveis interdependente numa hierarquia aumenta, a disponibilidade agregada da hierarquia diminui, conforme mostrado na tabela seguinte. Cada exemplo de conjunto na tabela tem um número diferente de níveis e cada nível assume-se que oferece uma disponibilidade de 99,9%.
| Nível | Conjunto A | Stack B | Stack C |
|---|---|---|---|
| Front-End | 99,9% | 99,9% | 99,9% |
| Nível de aplicação | 99,9% | 99,9% | 99,9% |
| Nível médio | – | 99,9% | 99,9% |
| Nível de dados | – | – | 99,9% |
| Disponibilidade agregada do conjunto de Fotos semelhantes | 99,8% | 99,7% | 99,6% |
| Tempo de inatividade máximo estimado da pilha num mês de 30 dias | 86 minutos | 130 minutos | 173 minutos |
Resumo das considerações de design
Quando cria as suas aplicações, considere a disponibilidade agregada da Google Cloud pilha de infraestrutura.
- A disponibilidade de cada Google Cloud recurso na sua pilha de infraestrutura influencia a disponibilidade agregada da pilha. Quando escolhe Google Cloud serviços para criar a sua pilha de infraestrutura, considere o SLA de disponibilidade dos serviços.
- Para melhorar a disponibilidade da função (por exemplo, computação ou base de dados) fornecida por um recurso, pode aprovisionar instâncias redundantes do recurso. Quando cria uma arquitetura com recursos redundantes, além das vantagens de disponibilidade, também tem de considerar os potenciais efeitos na complexidade operacional, na latência e no custo.
- O número de camadas numa pilha de infraestrutura (ou seja, a profundidade da pilha) tem uma relação inversa com a disponibilidade agregada da pilha. Considere esta relação quando conceber ou modificar a sua hierarquia.
Para mais exemplos de cálculos da disponibilidade agregada, consulte as seguintes secções:
- Exemplo de cálculo: implementação de zona única
- Exemplo de cálculo: implementação em várias zonas
- Exemplo de cálculo: implementação multirregional com balanceamento de carga regional
- Exemplo de cálculo: implementação multirregional com balanceamento de carga global
Âmbitos de localizações
O âmbito da localização de um Google Cloud recurso determina a extensão em que uma falha de infraestrutura pode afetar o recurso. A maioria dos recursos que aprovisiona no Google Cloud tem um dos seguintes âmbitos de localização: zonal, regional, multirregional ou global.
O âmbito da localização de alguns tipos de recursos é fixo, ou seja, não pode escolher nem alterar o âmbito da localização. Por exemplo, as redes da nuvem virtual privada (VPC) são recursos globais e as máquinas virtuais (VMs) do Compute Engine são recursos zonais. Para determinados recursos, pode escolher o âmbito da localização durante o aprovisionamento do recurso. Por exemplo, quando cria um cluster do Google Kubernetes Engine (GKE), pode optar por criar um cluster do GKE zonal ou regional.
As secções seguintes descrevem os âmbitos geográficos mais detalhadamente.
Recursos zonais
Os recursos zonais são implementados numa única zona numa Google Cloud região. Seguem-se exemplos de recursos zonais. Esta lista não é exaustiva.
- VMs do Compute Engine
- Grupos de instâncias geridas (GIGs) zonais
- Discos persistentes zonais
- Clusters do GKE de zona única
- Instâncias básicas e zonais do Filestore
- Tarefas do Dataflow
- Instâncias do Cloud SQL
- Clusters do Dataproc no Compute Engine
Uma falha numa zona pode afetar os recursos zonais aprovisionados nessa zona. As zonas foram concebidas para minimizar o risco de falhas correlacionadas com outras zonas na região. Normalmente, uma falha numa zona não afeta os recursos nas outras zonas da região. Além disso, uma falha numa zona não faz com que toda a infraestrutura nessa zona fique indisponível. A zona define apenas o limite esperado para o efeito de uma falha.
Para proteger as aplicações que usam recursos zonais contra incidentes zonais, pode distribuir ou replicar os recursos em várias zonas ou regiões. Para mais informações, consulte o artigo Crie uma infraestrutura fiável para as suas cargas de trabalho no Google Cloud.
Recursos regionais
Os recursos regionais são implementados de forma redundante em várias zonas numa região. Seguem-se exemplos de recursos regionais. Esta lista não é exaustiva.
- MIGs regionais
- Contentores do Cloud Storage regionais
- Discos persistentes regionais
- Clusters do GKE regionais com a configuração predefinida (multizona)
- Sub-redes de VPC
- Balanceadores de carga de aplicações externos regionais
- Instâncias regionais do Spanner
- Instâncias do Filestore Enterprise
- Serviços do Cloud Run
Os recursos regionais são resilientes a incidentes numa zona específica. Uma indisponibilidade de uma região pode afetar alguns ou todos os recursos regionais aprovisionados nessa região. Estas indisponibilidades podem ser causadas por desastres naturais ou falhas de infraestrutura em grande escala.
Recursos multirregionais
Os recursos multirregionais são distribuídos por regiões específicas. Seguem-se exemplos de recursos multirregionais. Esta lista não é exaustiva.
- Contentores do Cloud Storage em duas regiões e multirregionais
- Instâncias do Spanner multirregionais
- Instâncias do Bigtable em vários clusters (várias regiões)
- Conjuntos de chaves multirregionais no Cloud Key Management Service
Para ver uma lista completa dos serviços Google disponíveis em configurações multirregionais, consulte o artigo Produtos disponíveis por localização.
Os recursos multirregionais são resilientes a incidentes em regiões e zonas específicas. Uma interrupção da infraestrutura que ocorra em várias regiões pode afetar a disponibilidade de alguns ou todos os recursos multirregionais aprovisionados nas regiões afetadas.
Recursos globais
Os recursos globais estão disponíveis em todas as Google Cloud localizações. Seguem-se exemplos de recursos globais. Esta lista não é exaustiva.
Projetos. Para orientações e práticas recomendadas sobre como organizar os seus Google Cloud recursos em pastas e projetos, consulte Decida uma hierarquia de recursos para a sua Google Cloud zona de destino.
Redes VPC, incluindo trajetos associados e regras de firewall
Zonas do Cloud DNS
Balanceadores de carga de aplicações externos globais
Conjuntos de chaves globais no Cloud Key Management Service
Tópicos do Pub/Sub
Secrets no Secret Manager
Para ver uma lista completa dos serviços Google disponíveis a nível global, consulte o artigo Produtos globais.
Os recursos globais são resilientes a incidentes zonais e regionais. Estes recursos não dependem de infraestruturas em nenhuma região específica. Google Cloud Tem sistemas e processos que ajudam a minimizar o risco de interrupções da infraestrutura global. A Google também monitoriza continuamente a infraestrutura e resolve rapidamente quaisquer interrupções globais.
A tabela seguinte resume a resiliência relativa dos recursos zonais, regionais, multirregionais e globais a problemas de aplicações e infraestrutura. Também descreve o esforço necessário para configurar estes recursos e recomendações para mitigar os efeitos das indisponibilidades.
| Âmbito do recurso | Resiliência | Recomendações para mitigar os efeitos das indisponibilidades da infraestrutura |
|---|---|---|
| Zonal | Baixo | Implemente os recursos de forma redundante em várias zonas ou regiões. |
| Regional | Médio | Implemente os recursos de forma redundante em várias regiões. |
| Multirregião ou global | Alto | Faça a gestão das alterações cuidadosamente e use alternativas de defesa em profundidade sempre que possível. Para mais informações, consulte as recomendações para gerir o risco de indisponibilidades de recursos globais. |
Recomendações para gerir o risco de indisponibilidades de recursos globais
Para tirar partido da resiliência dos recursos globais perante interrupções de zonas e regiões, pode considerar usar determinados recursos globais na sua arquitetura. A Google recomenda as seguintes abordagens para gerir o risco de indisponibilidades de recursos globais:
Gestão cuidadosa das alterações aos recursos globais
Os recursos globais são resilientes a falhas físicas. A configuração de tais recursos tem âmbito global. Assim, configurar um único recurso global é mais fácil do que operar vários recursos regionais. No entanto, um erro crítico na configuração de um recurso global pode torná-lo um único ponto de falha (SPOF). Por exemplo, pode usar um balanceador de carga global como o frontend de uma aplicação distribuída geograficamente. Um equilibrador de carga global é, muitas vezes, uma boa escolha para uma aplicação deste tipo. No entanto, um erro na configuração do balanceador de carga pode fazer com que fique indisponível em todas as geografias. Para evitar este risco, tem de gerir cuidadosamente as alterações de configuração aos recursos globais. Para mais informações, consulte o artigo Controle as alterações aos recursos globais.
Utilização de recursos regionais como alternativas de defesa em profundidade
Para aplicações com requisitos de disponibilidade excecionalmente elevados, as alternativas de defesa em profundidade regionais podem ajudar a minimizar o efeito das indisponibilidades de recursos globais. Considere o exemplo de uma aplicação distribuída geograficamente que tem um equilibrador de carga global como o front-end. Para garantir que a aplicação permanece acessível mesmo que o balanceador de carga global seja afetado por uma indisponibilidade global, pode implementar balanceadores de carga regionais. Pode configurar os clientes para preferirem o equilibrador de carga global, mas falharem para o equilibrador de carga regional mais próximo se o equilibrador de carga global não estiver disponível.
Exemplo de arquitetura com recursos zonais, regionais e globais
A sua topologia de nuvem pode incluir uma combinação de recursos zonais, regionais e globais, conforme mostrado no diagrama seguinte. O diagrama seguinte mostra uma arquitetura de exemplo para uma aplicação de vários níveis implementada noGoogle Cloud.
Conforme mostrado no diagrama anterior, um balanceador de carga HTTP/S externo global recebe pedidos de clientes. O balanceador de carga distribui os pedidos para o back-end, que é um GIG regional com duas VMs do Compute Engine. A aplicação executada nas VMs escreve dados e lê dados de uma base de dados do Cloud SQL. A base de dados está configurada para AD. As instâncias principal e em espera da base de dados são aprovisionadas em zonas separadas, e a base de dados principal é replicada de forma síncrona para a base de dados em espera. Além disso, é feita automaticamente uma cópia de segurança da base de dados para um contentor multirregional no Cloud Storage.
A tabela seguinte resume os Google Cloud recursos na arquitetura anterior e a resiliência de cada recurso a interrupções de zonas e regiões:
| Recurso | Resiliência a interrupções |
|---|---|
| Rede da VPC | As redes VPC, incluindo os respetivos trajetos associados e as regras de firewall, são recursos globais. São resilientes a interrupções de zonas e regiões. |
| Sub-redes | As sub-redes de VPC são recursos regionais. São resilientes a interrupções de zonas. |
| Balanceador de carga HTTP/S externo global | Os balanceadores de carga HTTP/S externos globais são resilientes a interrupções de zonas e regiões. |
| Regional MIG | Os GIGs regionais são resilientes a interrupções de zonas. |
| VMs do Compute Engine | As VMs do Compute Engine são recursos zonais. Se ocorrer uma indisponibilidade de zona, as VMs do Compute Engine individuais podem ser afetadas. No entanto, a aplicação pode continuar a publicar pedidos porque o back-end do balanceador de carga é um MIG regional e não VMs autónomas. |
| Instâncias do Cloud SQL | A implementação do Cloud SQL nesta arquitetura está configurada
para HA; ou seja, a implementação inclui um par principal/em espera de
instâncias de base de dados. A base de dados principal é replicada de forma síncrona
para a base de dados de reserva através de discos persistentes regionais.
|
| Contentor do Cloud Storage multirregional | Os dados armazenados em contentores do Cloud Storage multirregionais são resilientes a interrupções de uma única região. |
| Discos persistentes | Os discos persistentes podem ser zonais ou regionais. Os discos persistentes regionais são resilientes a indisponibilidades zonais. Para se preparar para a recuperação de interrupções regionais, pode agendar instantâneos de discos persistentes e armazená-los num contentor do Cloud Storage multirregional. |