Regiões e zonas

Os recursos do Compute Engine são hospedados em vários locais no mundo todo. Esses locais são compostos de regiões e zonas. As regiões são localizações geográficas específicas onde seus recursos podem ser hospedados. As regiões têm três zonas ou mais. Por exemplo, a região us-west1 indica uma região da costa oeste dos Estados Unidos que tem três zonas: us-west1-a, us-west1-b e us-west1-c.

Os recursos que residem em uma zona, como instâncias de máquina virtual ou discos permanentes zonais, são chamados de recursos zonais. Outros recursos, como endereços IP externos estáticos, são regionais. Os recursos regionais podem ser usados por quaisquer recursos nessa região, independentemente da zona, enquanto os recursos de zona só podem ser usados por recursos na mesma zona.

Por exemplo, para anexar um disco permanente zonal a uma instância, os dois recursos precisam estar na mesma zona. Da mesma maneira, para atribuir um endereço IP estático a uma instância, a instância precisa estar na mesma região que o endereço IP estático.

A distribuição de recursos entre diferentes zonas em uma região promove o isolamento da maioria dos tipos de falhas de infraestrutura física e de serviço de software da infraestrutura. Já a distribuição entre diferentes regiões garante um nível ainda mais elevado de independência em relação a falhas. Isso permite projetar sistemas robustos com recursos espalhados por diferentes domínios de falhas.

Apenas determinados recursos são específicos da região ou da zona. Outros recursos, como imagens, são recursos globais que podem ser usados por qualquer outro recurso em qualquer local. Para mais informações sobre recursos globais, regionais e zonais do Compute Engine, consulte Recursos globais, regionais e zonais.

Zonas e clusters

O Compute Engine implementa uma camada de abstração entre as zonas e os clusters físicos em que as zonas estão hospedadas. Um cluster representa uma infraestrutura física distinta hospedada em um data center. Cada cluster tem infraestrutura de software, energia, refrigeração, rede e infraestrutura de segurança independentes e inclui um grande conjunto de recursos de computação e armazenamento.

Cada zona é hospedada em um ou mais clusters, e o Compute Engine as mapeia de maneira independente para os clusters de cada organização. Por exemplo, a zona us-central1-a da sua organização pode não ser mapeada para o mesmo cluster que a zona us-central1-a de outra organização.

A dissociação das zonas dos clusters oferece uma série de benefícios para você e para o Compute Engine:

  • Permite que o Compute Engine garanta que os recursos estejam equilibrados nos clusters de uma região.
  • A lista de zonas disponíveis permanece gerenciável à medida que o Compute Engine continua a expandir as regiões ao longo do tempo, adicionando mais clusters.

Para a maioria das organizações, o Compute Engine garante que todos os projetos em uma organização tenham um mapeamento consistente de zona para cluster. Para organizações com projetos que usam peering de rede VPC ou acesso a serviços privados para compartilhar redes ou serviços com outras organizações, o Compute Engine tenta garantir que todas as organizações com peering tenham um mapeamento consistente de zona para cluster. No caso de provedores de SaaS de grande escala, por exemplo, o Compute Engine pode não fornecer um mapeamento consistente para todas as organizações com peering. Nesses casos, o Compute Engine garante que os projetos com peering tenham um mapeamento consistente de zona para cluster.

Como escolher uma região e zona

Você escolhe qual região ou zona hospeda os seus recursos, o que controla onde os seus dados são armazenados e usados. A escolha de uma região e zona é importante por vários motivos:

Como corrigir falhas
Distribua os seus recursos entre várias zonas e regiões para tolerar interrupções. O Google projeta zonas para serem independentes entre si: uma zona normalmente conta com planos de alimentação, refrigeração, rede e controle isolados de outras zonas, e a maioria dos eventos de falha única afetará apenas uma zona. Por isso, se uma zona permanecer indisponível, você poderá transferir o tráfego para outra na mesma região a fim de manter os serviços em execução. Da mesma maneira, se uma região enfrentar algum distúrbio, você precisará ter serviços de backup em execução em uma região diferente. Para mais informações sobre como distribuir seus recursos e projetar um sistema robusto, consulte Como projetar sistemas robustos.
Menos latência de rede
Para diminuir a latência de rede, convém escolher uma região ou zona que esteja próxima do seu ponto de serviço. Por exemplo, caso você tenha mais clientes na Costa Leste dos EUA, convém escolher uma região e uma zona primárias que estejam próximas dessa área e uma região e zona de backup que também estejam próximas.

Como identificar uma região ou uma zona

Cada região no Compute Engine contém várias zonas. Cada nome de zona contém duas partes que descrevem detalhadamente cada zona. A primeira parte do nome da zona é a região e a segunda parte do nome descreve a zona na região:

  • Região

    Regiões são coleções de zonas. As zonas têm conexões de rede de muita largura de banda e baixa latência com outras zonas na mesma região. Para implantar aplicativos tolerantes a falhas que tenham alta disponibilidade, o Google recomenda a implantação de aplicativos em várias zonas e regiões. Isso ajuda na proteção contra falhas inesperadas de componentes, incluindo até uma única zona ou região.

    Escolha regiões que façam sentido para seu cenário. Por exemplo, se você só tiver clientes nos EUA ou se tiver necessidades específicas que exijam que seus dados estejam nos EUA, faz sentido armazenar os recursos em zonas das regiões us-central1 ou us-east1.

  • Zona

    Uma zona é um local isolado dentro de uma região. O nome totalmente qualificado de uma zona é composto de <region>-<zone>. Por exemplo, o nome totalmente qualificado da zona a na região us-central1 é us-central1-a.

    Dependendo da amplitude de distribuição dos seus recursos, crie instâncias em várias zonas, em diversas regiões, para redundância.

Regiões e zonas disponíveis

A tabela classificável a seguir permite selecionar diferentes opções para ver onde os recursos estão disponíveis. Por exemplo, é possível selecionar Europe no menu suspenso Selecionar um local e M2 em Selecionar um tipo de máquina para ver uma lista de zonas em que as máquinas M2 estão disponíveis na Europa.

Cada zona aceita uma combinação das plataformas Ivy Bridge, Sandy Bridge, Haswell, Broadwell, Skylake ou Cascade Lake, bem como a plataforma AMD EPYC Rome. Quando você cria uma instância em uma zona, a instância usa o processador padrão compatível com essa zona. Por exemplo, se você cria uma instância na zona us-central1-a, a instância por padrão usará um processador Haswell, a menos que você especifique outra opção.

Também é possível escolher a plataforma de CPU que você quer. Para mais informações, leia Como especificar uma plataforma de CPU mínima para instâncias de VM.

Zonas Local Tipos de máquinas CPUs Recursos
asia-east1-a Condado de Changhua, Taiwan, APAC (Ásia-Pacífico) E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-east1-b Condado de Changhua, Taiwan, APAC (Ásia-Pacífico) E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-east1-c Condado de Changhua, Taiwan, APAC (Ásia-Pacífico) E2, N2, N2D, N1, M1, C2 Ivy Bridge, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-east2-a
asia-east2-b
asia-east2-c
Hong Kong, APAC (Ásia-Pacífico) E2, N2, N1 Broadwell, Skylake, Cascade Lake
asia-northeast1-a Tóquio, Japão, APAC (Ásia-Pacífico) E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
asia-northeast1-b Tóquio, Japão, APAC (Ásia-Pacífico) E2, N2, N1 Broadwell, Skylake, Cascade Lake
asia-northeast1-c Tóquio, Japão, APAC (Ásia-Pacífico) E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
asia-northeast2-a
asia-northeast2-b
asia-northeast2-c
Osaka, Japão, APAC (Ásia-Pacífico) E2, N1 Skylake
asia-northeast3-a
asia-northeast3-b
asia-northeast3-c
Seul, Coreia do Sul, APAC (Ásia-Pacífico) E2, N1, C2 Skylake
asia-south1-a Mumbai, Índia, APAC (Ásia-Pacífico) E2, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
asia-south1-b Mumbai, Índia, APAC (Ásia-Pacífico) E2, N1, M2, M1 Broadwell, Skylake GPUs
asia-south1-c Mumbai, Índia, APAC (Ásia-Pacífico) E2, N1, M1 Broadwell, Skylake
asia-southeast1-a Jurong West, Singapura, APAC (Ásia-Pacífico) E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
asia-southeast1-b Jurong West, Singapura, APAC (Ásia-Pacífico) E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-southeast1-c Jurong West, Singapura, APAC (Ásia-Pacífico) E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
asia-southeast2-a
asia-southeast2-b
asia-southeast2-c
Jacarta, Indonésia, APAC (Ásia-Pacífico) E2, N1 Skylake
australia-southeast1-a Sydney, Austrália, APAC (Ásia-Pacífico) E2, N2, N1, C2 Broadwell, Skylake, Cascade Lake
australia-southeast1-b Sydney, Austrália, APAC (Ásia-Pacífico) E2, N2, N1, C2, M1 Broadwell, Skylake, Cascade Lake GPUs
australia-southeast1-c Sydney, Austrália, APAC (Ásia-Pacífico) E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPUs
europe-north1-a Hamina, Finlândia, Europa E2, N2, N1, C2, M1 Broadwell, Skylake, Cascade Lake
europe-north1-b Hamina, Finlândia, Europa E2, N1, C2 Broadwell, Skylake
europe-north1-c Hamina, Finlândia, Europa E2, N1, C2 M1 Broadwell, Skylake
europe-west1-b St. Ghislain, Bélgica, Europa E2, N2, N2D, N1, M1, C2 Sandy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west1-c St. Ghislain, Bélgica, Europa E2, N2, N2D, N1, C2 Ivy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
europe-west1-d St. Ghislain, Bélgica, Europa E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west2-a Londres, Inglaterra, Europa E2, N2, N1, C2 Broadwell, Skylake, Cascade Lake GPUs
europe-west2-b Londres, Inglaterra, Europa E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
europe-west2-c Londres, Inglaterra, Europa E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
europe-west3-a Frankfurt, Alemanha, Europa E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
europe-west3-b Frankfurt, Alemanha, Europa E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
europe-west3-c Frankfurt, Alemanha, Europa E2, N1 Broadwell, Skylake
europe-west4-a Eemshaven, Holanda, Europa E2, N2, N1, C2 Broadwell, Skylake, Cascade Lake GPUs
europe-west4-b Eemshaven, Holanda, Europa E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west4-c Eemshaven, Holanda, Europa E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
europe-west6-a
europe-west6-b
europe-west6-c
Zurique, Suíça, Europa E2, N1 Skylake
northamerica-northeast1-a Montreal, Quebec, América do Norte E2, N2, N1 Broadwell, Skylake, Cascade Lake GPUs
northamerica-northeast1-b Montreal, Quebec, América do Norte E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPUs
northamerica-northeast1-c Montreal, Quebec, América do Norte E2, N2, N1, M1 Broadwell, Skylake, Cascade Lake GPUs
southamerica-east1-a Osasco, São Paulo, Brasil, América do Sul E2, N2, N1 Broadwell, Skylake, Cascade Lake
southamerica-east1-b Osasco, São Paulo, Brasil, América do Sul E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake
southamerica-east1-c Osasco, São Paulo, Brasil, América do Sul E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
us-central1-a Council Bluffs, Iowa, América do Norte E2, N2, N2D, N1, M1, C2 Sandy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-central1-b Council Bluffs, Iowa, América do Norte E2, N2, N1, M2, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake GPUs
us-central1-c Council Bluffs, Iowa, América do Norte E2, N2, N2D, N1, M2, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-central1-f Council Bluffs, Iowa, América do Norte E2, N2, N2D, N1, C2 Ivy Bridge, Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east1-b Moncks Corner, Carolina do Sul, América do Norte E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east1-c Moncks Corner, Carolina do Sul, América do Norte E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east1-d Moncks Corner, Carolina do Sul, América do Norte E2, N2, N2D, N1, M1, C2 Haswell, Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east4-a Ashburn, Virgínia, América do Norte E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east4-b Ashburn, Virgínia, América do Norte E2, N2, N2D, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-east4-c Ashburn, Virgínia, América do Norte E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
us-west1-a The Dalles, Oregon, América do Norte E2, N2, N1, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
us-west1-b The Dalles, Oregon, América do Norte E2, N2, N2D, N1, M1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome GPUs
us-west1-c The Dalles, Oregon, América do Norte E2, N2, N2D, N1, C2 Broadwell, Skylake, Cascade Lake, AMD EPYC Rome
us-west2-a Los Angeles, Califórnia, América do Norte E2, N1, M2, C2 Broadwell, Skylake, Cascade Lake
us-west2-b Los Angeles, Califórnia, América do Norte E2, N1, M1 Broadwell, Skylake GPUs
us-west2-c Los Angeles, Califórnia, América do Norte E2, N1, M2, M1, C2 Broadwell, Skylake, Cascade Lake GPUs
us-west3-a
us-west3-b
us-west3-c
Salt Lake City, Utah, América do Norte E2, N1 Skylake
us-west4-a
us-west4-b
us-west4-c
Las Vegas, Nevada, América do Norte E2, N2, N1 Skylake, Cascade Lake

Regiões anunciadas

Em 2021, o Google continuará se expandindo nas seguintes novas regiões:

  • Varsóvia (Polônia)

Manutenção transparente

O Google realiza regularmente manutenção na infraestrutura corrigindo sistemas com o software mais recente, realizando testes de rotina e manutenção preventiva, além de garantir de maneira geral que a infraestrutura do Google seja tão rápida e eficiente quanto o Google sabe fazer.

Por padrão, todas as instâncias são configuradas de maneira que esses eventos de manutenção sejam transparentes para os seus aplicativos e as suas cargas de trabalho. O Google usa uma combinação de inovações em data center, práticas recomendadas operacionais e tecnologia de migração ativa para tirar instâncias de máquina virtual em execução do caminho da manutenção que está sendo realizada. Sua instância continua em execução dentro da mesma zona sem ação da sua parte.

Por padrão, todas as máquinas virtuais são definidas para migração ativa, mas você também pode definir suas máquinas virtuais para serem interrompidas e reinicializadas. As duas opções diferem das seguintes maneiras:

  • Migração em tempo real

    O Compute Engine migra automaticamente sua instância em execução. O processo de migração afetará o desempenho do convidado de certo modo, mas sua instância permanece on-line durante todo o processo de migração. O impacto exato sobre o desempenho do convidado e a duração dependem de muitos fatores, mas a maioria dos aplicativos e das cargas de trabalho não notará. Para mais informações, consulte Migração em tempo real.

  • Interromper e reinicializar

    O Compute Engine sinaliza automaticamente para que sua instância desligue, aguarda o desligamento limpo e reinicia depois do evento de manutenção.

Para mais informações sobre como definir as opções para suas instâncias, consulte Como definir opções de programação de instância.

Suspensão de uso da zona

Nunca é necessário desativar uma zona atual para realizar uma atualização de infraestrutura do zero (energia, resfriamento, malha de rede, servidores etc.). As atualizações de infraestrutura são raras e as zonas normalmente funcionam de três a cinco anos entre as atualizações. Essas atualizações devem ser transparentes para os clientes.

Se for necessário suspender o uso de alguma zona, o Compute Engine notificará os usuários com bastante antecedência sobre quando ficará off-line. Dessa forma, você tem bastante tempo para migrar as suas instâncias de máquina virtual e as cargas de trabalho.

Cotas

Determinados recursos, como IPs estáticos, imagens, regras de firewall e redes da VPC, têm limites de cota definidos para todo o projeto e limites de cota por região. Quando você cria esses recursos, eles são contabilizados na cota total de todo o projeto ou na cota por região, se aplicável. Se algum dos limites da cota afetada for excedido, não será mais possível adicionar recursos do mesmo tipo a esse projeto ou essa região.

Para uma lista abrangente de cotas que se aplicam ao seu projeto, visite a página Cotas no Console do Google Cloud.

Por exemplo, se a cota global de pools de destino for 50 e você criar 25 pools de destino em example-region-1 e 25 pools de destino em example-region-2, você atingirá a cota de todo o projeto e não poderá criar mais pools de destino em nenhuma região do projeto, até que seja liberado espaço. Da mesma forma, se tiver uma cota por região de 7 endereços IP reservados, você só poderá reservar até 7 endereços IP em uma única região. Depois de alcançar esse limite, você precisará reservar endereços IP em uma nova região ou liberar alguns endereços IP.

Dicas

Durante a seleção de zonas, lembre-se do seguinte:

  • A comunicação dentro e entre as regiões gera custos diferentes.

    Normalmente, a comunicação dentro das regiões sempre será mais barata e mais rápida do que a comunicação entre regiões diferentes.

  • Projete sistemas importantes com redundância em várias zonas.

    Em algum momento, as instâncias podem sofrer uma falha inesperada. Para atenuar os efeitos desses eventos possíveis, duplique os sistemas importantes em várias zonas e regiões.

    Por exemplo, hospedando instâncias nas zonas europe-west1-b e europe-west1-c, se a europe-west1-b falhar inesperadamente, as suas instâncias na zona europe-west1-c ainda continuarão disponíveis. Porém, se hospedar todas as suas instâncias em europe-west1-b, você não conseguirá acessar nenhuma instância se europe-west1-b ficar off-line. Além disso, verifique se é possível hospedar seus recursos nas regiões. Por exemplo, no improvável cenário de uma falha na região europe-west1, verifique se é possível hospedar instâncias de backup em uma zona na região europe-west3. Para mais dicas sobre como projetar sistemas para disponibilidade, consulte Como projetar sistemas robustos.

A seguir