Virtualização de zona

Neste documento, explicamos a virtualização de zona, que é o método que o Google usa para mapear zonas públicas em clusters de hardware físico interno nos nossos data centers. A virtualização de zona nos permite expandir perfeitamente nossas zonas, fazer o upgrade do hardware e desativar a infraestrutura física sem causar impacto para o cliente. Leia sobre esse tópico se seus aplicativos estiverem distribuídos em vários projetos e se você quiser saber como o Google espalha as zonas por meio da infraestrutura física.

Os recursos do Google Cloud são hospedados em várias regiões em todo o mundo. Regiões são áreas geográficas independentes que consistem em zonas. Zonas e regiões são abstrações lógicas de recursos físicos subjacentes. Uma região consiste em três ou mais zonas instaladas em três ou mais data centers físicos. As regiões México, Osaka e Montreal têm três zonas instaladas em um ou dois data centers físicos. Essas regiões estão em processo de expansão para pelo menos três data centers físicos. Ao projetar suas soluções no Google Cloud, considere as orientações em Locais do Cloud, SLAs do Google Cloud Platform e a documentação do produto do Google Cloud apropriada.

Colocar os recursos em várias zonas dentro de uma região reduz o risco de falhas na infraestrutura física e de software que afetam seus apps. Já a distribuição entre diferentes regiões garante um nível ainda mais elevado de independência em relação a falhas.

Para uma lista de locais geográficos do Google Cloud, consulte Regiões e zonas. Para mais informações sobre como criar apps resilientes, consulte a série de soluções do Google Cloud sobre o planejamento de recuperação de desastres.

Clusters

Todo o hardware do Google Cloud é organizado em clusters. Um cluster representa um conjunto de recursos de computação, rede e armazenamento com suporte da infraestrutura de criação, energia e resfriamento. Os componentes de infraestrutura normalmente são compatíveis com um único cluster, garantindo que eles compartilhem poucas dependências.

A asia-east1 tem 3 zonas e 3 clusters.

Figura 1: há três zonas na região asia-east1. Cada zona tem o próprio cluster com recursos individuais.

No entanto, componentes com confiabilidade altamente demonstrada e redundância downstream podem ser compartilhados entre clusters. Por exemplo, vários clusters normalmente compartilham uma subestação de grade de utilitários porque elas são extremamente confiáveis e os clusters usam sistemas redundantes de energia. O Google Cloud projeta a infraestrutura física para dar suporte aos contratos de nível de serviço (SLAs, na sigla em inglês) e aos objetivos de nível de serviço (SLOs, na sigla em inglês) dos serviços do Google Cloud.

Mapeamento de zona para cluster

Quando um projeto usa uma região pela primeira vez, o Google Cloud seleciona um único cluster para cada zona na região, que é o cluster padrão para os recursos zonais desse projeto. No entanto, as restrições de hardware podem resultar no uso de clusters adicionais nessa zona. Essa seleção é chamada de mapeamento de zona para cluster. Os mapeamentos de zona para cluster padrão são selecionados por projeto para que cada cliente tenha as mesmas capacidades e o mesmo desempenho. Em um projeto, o mapeamento entre uma zona lógica e um cluster físico é consistente. No entanto, outro projeto pode ter um mapeamento de zona para cluster completamente diferente com base nos recursos zonais do projeto. Um projeto nunca tem duas zonas mapeadas no mesmo cluster físico.

É possível alinhar os mapeamentos de zona para cluster entre projetos usando redes de nuvem privada virtual (VPC). O Google Cloud tenta atribuir o mesmo mapa de zona para cluster a todos os projetos que compartilham uma rede VPC. Mapas consistentes de zona para cluster nos projetos podem ser falhas de componentes atômicos previsíveis no aplicativo.

Zonas virtualizadas

Como as regiões se expandem, cada zona é compatível com vários clusters. Nosso objetivo é agrupar clusters com infraestrutura compartilhada, como uma construção ou uma infraestrutura de resfriamento, em zonas lógicas para que as falhas de infraestrutura compartilhada afetem apenas uma zona dentro de uma região.

As zonas A asia-east1 A e B estão expandidas para dois clusters.

Figura 2 Duas das três zonas em asia-east1 foram expandidas e agora têm dois clusters.

As cargas de trabalho do cliente são mantidas no menor número possível de clusters. Normalmente, a carga de trabalho zonal está em um único cluster. No entanto, os mapeamentos de zona para cluster podem incluir clusters adicionais em que a capacidade extra ou hardware especializado não esteja disponível no cluster principal do mapa.

As zonas A asia-east1 A e B estão expandidas para dois clusters.

Figura 3 Exibe um diagrama do mapeamento de zona para cluster de dois projetos:

  • O Project Fizz tem dois clusters mapeados para asia-east1-a porque apenas o Cluster z é compatível com cargas de trabalho da GPU, e apenas o Cluster y é compatível com cargas de trabalho da TPU.
  • O Project Fizz e o Project Buzz têm clusters diferentes mapeados para asia-east1-b.

Embora a mudança do mapeamento de zona para cluster raramente seja modificada, as alterações ocorrem de acordo com as necessidades e as ofertas de hardware subjacentes em evolução. Por exemplo, os clusters são adicionados a uma zona para aumentar a capacidade e são removidos de uma zona quando são desativados. Durante qualquer evento de manutenção, o Google tenta limitar a inatividade usando a migração em tempo real quando possível.

No caso de uma interrupção do cluster, a zona lógica associada a esse cluster é informada como tendo uma interrupção no Painel de status do Google Cloud, no entanto, nem todos os recursos do cliente foram afetadas, já que a zona pode ser composta de vários clusters. Portanto, alguns clientes podem não ser afetados por uma única interrupção do cluster. Recomendamos a adoção de arquiteturas de várias zonas para minimizar o impacto de interrupções.

Redes compartilhadas e zonas virtualizadas

As redes de nuvem privada virtual (VPC) são redes virtualizadas que fornecem conectividade entre recursos em um projeto. Vários projetos podemcompartilhar uma rede VPC para ativar a conectividade entre projetos, e uma organização pode fazer o peering de uma rede VPC compartilhada para ativar a conectividade entre organizações. Nosso algoritmo de mapeamento de virtualização de zona tenta atribuir o mesmo mapa de zona para cluster a todos os projetos que compartilham uma rede VPC ou estendem sua rede VPC via peering de VPC. Isso é válido mesmo quando os projetos estão em diferentes organizações do Google Cloud. A medida que a complexidade da rede cresce com o número de projetos e VPC, manter um mapeamento de zona consistente se torna mais desafiador e, portanto, não pode ser garantido.

A seguir