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. Cada região tem uma ou mais zonas, sendo que a maioria tem três ou mais zonas. Por exemplo, a região us-west1 indica uma região na 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, e os recursos zonais 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. Além disso, ela possibilita a criação de sistemas robustos com recursos espalhados por diferentes domínios de falha.

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 SaaS de grande escala, por exemplo, pode não ser possível para o Compute Engine 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.

Locais

Na tabela a seguir, mostramos os locais de todas as regiões do Compute Engine e as zonas associadas. Consulte a seção Regiões e zonas disponíveis para ver a descrição completa dos tipos de máquina e recursos disponíveis em cada zona.

Região Zonas Local
asia-east1 a, b, c Condado de Changhua, Taiwan
asia-east2 a, b, c Hong Kong
asia-northeast1 a, b, c Tóquio, Japão
asia-northeast2 a, b, c Osaka, Japão
asia-northeast3 a, b, c Seul (Coreia do Sul)
asia-south1 a, b, c Mumbai, Índia
asia-southeast1 a, b, c Jurong West, Singapura
asia-southeast2 a, b, c Jacarta, Indonésia
australia-southeast1 a, b, c Sydney, Austrália
europe-north1 a, b, c Hamina, Finlândia
europe-west1 b, c, d St. Ghislain, Bélgica
europe-west2 a, b, c Londres, Inglaterra, Reino Unido
europe-west3 a, b, c Frankfurt, Alemanha
europe-west4 a, b, c Eemshaven, Holanda
europe-west6 a, b, c Zurique, Suíça
northamerica-northeast1 a, b, c Montreal, Quebec, Canadá
southamerica-east1 a, b, c Osasco (São Paulo), Brasil
us-central1 a, b, c, f Council Bluffs, Iowa, EUA
us-east1 b, c, d Moncks Corner, Carolina do Sul, EUA
us-east4 a, b, c Ashburn, Virgínia do Norte, EUA
us-west1 a, b, c The Dalles, Oregon, EUA
us-west2 a, b, c Los Angeles, Califórnia, EUA
us-west3 a, b, c Salt Lake City, Utah, EUA
us-west4 a, b, c Las Vegas, Nevada, EUA

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

Na tabela a seguir, há uma lista de regiões, locais, zonas disponíveis na região e recursos disponíveis nas zonas dessa região.

Cada zona aceita uma combinação das plataformas Ivy Bridge, Sandy Bridge, Haswell, Broadwell, Skylake ou Cascade Lake. 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.

Você também poderá escolher a plataforma de CPU da sua preferência. Para mais informações, leia Como especificar uma plataforma de CPU mínima para instâncias de VM.

Nome da região Descrição da região Local Zonas Recursos
asia-east1 Taiwan Condado de Changhua, Taiwan asia-east1-a
asia-east1-b
asia-east1-c
asia-east2 Hong Kong Hong Kong asia-east2-a
asia-east2-b
asia-east2-c
asia-northeast1 Tóquio Tóquio, Japão asia-northeast1-a
asia-northeast1-b
asia-northeast1-c
asia-northeast2 Osaka Osaka, Japão asia-northeast2-a
asia-northeast2-b
asia-northeast2-c
asia-northeast3 Seul Seul (Coreia do Sul) asia-northeast3-a
asia-northeast3-b
asia-northeast3-c
asia-south1 Mumbai Mumbai, Índia asia-south1-a
asia-south1-b
asia-south1-c
asia-southeast1 Singapura Jurong West, Singapura asia-southeast1-a
asia-southeast1-b
asia-southeast1-c
asia-southeast2 Jacarta Jacarta, Indonésia asia-southeast2-a
asia-southeast2-b
asia-southeast2-c
australia-southeast1 Sydney Sydney, Austrália australia-southeast1-a
australia-southeast1-b
australia-southeast1-c
europe-north1 Finlândia Hamina, Finlândia europe-north1-a
europe-north1-c
europe-north1-b
europe-west1 Bélgica St. Ghislain, Bélgica europe-west1-b
europe-west1-c
europe-west1-d
europe-west2 Londres Londres, Inglaterra, Reino Unido europe-west2-a
europe-west2-b
europe-west2-c
europe-west3 Frankfurt Frankfurt, Alemanha europe-west3-a
europe-west3-b
europe-west3-c
europe-west4 Holanda Eemshaven, Holanda europe-west4-a
europe-west4-b
europe-west4-c
europe-west6 Zurique Zurique, Suíça europe-west6-a
europe-west6-b
europe-west6-c
northamerica-northeast1 Montreal Montreal, Quebec, Canadá northamerica-northeast1-a
northamerica-northeast1-b
northamerica-northeast1-c
southamerica-east1 Osasco Osasco, São Paulo, Brasil southamerica-east1-a
southamerica-east1-b
southamerica-east1-c
us-central1 Iowa Council Bluffs, Iowa, EUA us-central1-a
us-central1-b
us-central1-c
us-central1-f
us-east1 Carolina do Sul Moncks Corner, Carolina do Sul, EUA us-east1-b
    us-east1-c
    us-east1-d
us-east4 Virgínia do Norte Ashburn, Virgínia, EUA us-east4-a
us-east4-b
us-east4-c
us-west1 Oregon The Dalles, Oregon, EUA us-west1-a
us-west1-b
us-west1-c
us-west2 Los Angeles Los Angeles, Califórnia, EUA us-west2-a
us-west2-b
us-west2-c
us-west3 Salt Lake City Salt Lake City, Utah, EUA us-west3-a
us-west3-b
us-west3-c
us-west4 Las Vegas Las Vegas, Nevada, EUA us-west4-a
us-west4-b
us-west4-c

Regiões anunciadas

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

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 as suas máquinas virtuais para serem encerradas 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.

  • Encerramento e reinicialização

    O Compute Engine sinaliza automaticamente para que sua instância desligue, aguarda o desligamento correto e a reinicia fora 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 atingir 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, é possível que as suas instâncias enfrentem 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