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 de possibilitar a criação de 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 mapeia as zonas independentemente para os clusters de cada organização. Por exemplo, a zona us-central1-a da sua organização pode não mapear 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 suas 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 particulares 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

A tabela a seguir mostra 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-south1 a, b, c Mumbai, Índia
asia-southeast1 a, b, c Jurong West, Singapura
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

Como escolher uma região e uma 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 ver mais informações sobre como distribuir os 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 uma 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, caso você tenha clientes apenas nos EUA ou tenha necessidades específicas que exijam a presença dos seus dados nos EUA, faz sentido armazenar os seus recursos em zonas na região us-central1 ou em zonas na região us-east1.

  • Zona

    Uma zona é uma localização isolada dentro de uma região. O nome totalmente qualificado de uma zona é constituído de <region>-<zone>. Por exemplo, o nome de domínio 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 das regiões com o local, as zonas e os recursos disponíveis em cada uma delas.

Cada zona aceita uma combinação de plataformas Ivy Bridge, Sandy Bridge, Haswell, Broadwell e Skylake. A instância criada em uma determinada zona usará o processador padrão aceito na zona. Por exemplo, se você criar uma instância na zona us-central1-a, ela usará um processador Sandy Bridge.

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-south1 Mumbai Mumbai, Índia
  • asia-south1-a
  • asia-south1-c
asia-south1-b
asia-southeast1 Singapura Jurong West, Singapura
  • asia-southeast1-a
  • asia-southeast1-b
  • asia-southeast1-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-b
  • europe-north1-c
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-c
europe-west2-b
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

Regiões anunciadas

Em 2019 e 2020, o Google continuará expandindo para as seguintes regiões novas:

  • Zurique (Suíça) Lançada!
  • Osaka (Japão) Lançada!
  • Seul (Coreia do Sul)
  • Salt Lake City, Utah (EUA)
  • Las Vegas, Nevada (EUA)
  • Jacarta (Indonésia)

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 ativa

    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 limpo e reinicia depois do evento de manutenção.

Para mais informações sobre como definir as opções para as suas instâncias, consulte Definição de opções de programação da 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, você não poderá adicionar mais recursos do mesmo tipo nesse projeto ou nessa região.

Para consultar uma lista abrangente de cotas aplicáveis ao seu projeto, visite a página Cotas no Console do Google Cloud Platform.

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 incorrerá em 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, você deve duplicar 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 estiver 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. Se quiser mais dicas sobre como projetar sistemas para disponibilidade, consulte Como projetar sistemas robustos.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine