Regiões e zonas

Alguns recursos do Compute Engine estão em regiões ou zonas. Região é uma localização geográfica específica onde os recursos podem ser executados. Cada região tem uma ou mais zonas, sendo que a maioria tem três ou mais zonas. Por exemplo, a região us-central1 é uma região central dos Estados Unidos com as zonas us-central1-a, us-central1-b, us-central1-c e us-central1-f.

Os recursos existentes em uma zona, como instâncias ou discos persistentes, são conhecidos como 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, discos e instâncias são ambos recursos zonais. Para anexar um disco a uma instância, ambos os recursos precisam estar na mesma zona. De maneira semelhante, se você quiser atribuir um endereço IP estático a uma instância, esta precisará estar na mesma região do IP estático.

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.

A tabela a seguir descreve as regiões e as zonas. 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-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
northamerica-northeast1 a, b, c Montreal, Quebec, Canadá
southamerica-east1 a, b, c 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 aumentar 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

A tabela a seguir lista as 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-south1 Mumbai Mumbai, Índia
  • asia-south1-a
  • asia-south1-b
  • asia-south1-c
asia-southeast1 Singapura Jurong West, Singapura
  • asia-southeast1-a
  • 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-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
northamerica-northeast1 Montreal Montreal, Quebec, Canadá
  • northamerica-northeast1-a
  • northamerica-northeast1-b
  • northamerica-northeast1-c
southamerica-east1 São Paulo 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

Ao longo de 2018, o Google continuará se expandindo nas seguintes regiões novas:

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

  • Zurique (Suíça)
  • Osaka (Japão)
  • 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 certa forma, 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á.

  • 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

O Compute Engine fez melhorias recentes na tecnologia de virtualização que eliminam a necessidade de descomissionar uma zona existente para uma atualização completa da infraestrutura (alimentação, refrigeração, rede, malha, servidores etc.). As atualizações da 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. Leve também em consideração a hospedagem dos seus recursos em todas as regiões. Por exemplo, considere hospedar instâncias de backup em uma zona em europe-west3 diante do improvável cenário da região europe-west1 enfrentar uma falha. Para mais dicas sobre como projetar sistemas para disponibilidade, consulte Como projetar sistemas robustos.

Próximas etapas

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

Enviar comentários sobre…

Documentação do Compute Engine