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 você pode executar os seus recursos. Cada região tem uma ou mais zonas. Por exemplo, a região us-central1 denota uma região na 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.

Somente 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 quaisquer outros recursos em qualquer local. Para mais informações sobre recursos globais, regionais e zonais do Compute Engine, consulte os Recursos globais, regionais e de zonas.

O diagrama a seguir apresenta alguns exemplos de como regiões e zonas estão relacionados entre si. Cada região independe de outras regiões, e cada zona está isolada de outras zonas na mesma região.

Diagrama das zonas descrevendo as disponíveis em cada região

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 de uma zona é importante por diversos 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 única zona. Por isso, se uma zona permanecer indisponível, você poderá transferir o tráfego para outra zona 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ê deverá ter serviços de backup em execução em uma região diferente. Para 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 esteja próxima.

Identificação de 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, até a inclusão de uma única zona ou região.

    Escolha regiões que façam sentido para o 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 seguinte tabela lista a região, o local, o local, as zonas disponíveis nessa região e os recursos disponíveis nessa região.

Cada zona dá suporte a processadores Ivy Bridge, Sandy Bridge, Haswell, Broadwell e à plataforma Skylake. Quando você criar uma instância na zona, a instância usará o processador padrão compatível nessa zona. Por exemplo, se você criar uma instância na zona us-central1-a, a instância usará um processador Sandy Bridge.

Você também poderá escolher a plataforma de CPU desejada, se quiser. 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
us-central1 Iowa Council Bluffs, Iowa, EUA us-central1-a
  • Plataforma de 2,6 GHz Intel Xeon E5 (Sandy Bridge) (padrão)
  • Plataforma de 2,2 GHz Intel Xeon E5 v4 (Broadwell)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • Tipos de máquina de 64 núcleos
  • SSDs locais
us-central1-b
  • Plataforma de 2,3 GHz Intel Xeon E5 v3 (Haswell) (padrão)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • Tipos de máquina de 64 núcleos
  • SSDs locais
us-central1-c
  • Plataforma de 2,3 GHz Intel Xeon E5 v3 (Haswell) (padrão)
  • Plataforma de 2,2 GHz Intel Xeon E5 v4 (Broadwell)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • Tipos de máquina de 64 núcleos
  • SSDs locais
us-central1-f
  • Plataforma de 2,5 GHz Intel Xeon E5 v2 (Ivy Bridge)(padrão)
  • Plataforma de 2,2 GHz Intel Xeon E5 v4 (Broadwell)
  • tipos de máquina com 32 núcleos
  • SSDs locais
us-west1 Oregon The Dalles, Oregon, EUA us-west1-a
us-west1-b
  • Plataforma de 2,2 GHz Intel Xeon E5 v4 (Broadwell)(padrão)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • Tipos de máquina de 64 núcleos
  • SSDs locais
us-west1-c
us-east4 Virgínia do Norte Ashburn, Virgínia, EUA us-east4-a
us-east4-b
us-east4-c
us-east1 Carolina do Sul Moncks Corner, Carolina do Sul, EUA us-east1-b
us-east1-c
us-east1-d
  • Plataforma de 2,3 GHz Intel Xeon E5 v3 (Haswell) (padrão)
  • Plataforma de 2,2 GHz Intel Xeon E5 v4 (Broadwell)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • Tipos de máquina de 64 núcleos
  • SSDs locais
southamerica-east1 * São Paulo São Paulo, Brasil southamerica-east1-a southamerica-east1-b southamerica-east1-c
europe-west1 Bélgica St. Ghislain, Bélgica europe-west1-b
  • Plataforma de 2,6 GHz Intel Xeon E5 (Sandy Bridge) (padrão)
  • Plataforma de 2,2 GHz Intel Xeon E5 v4 (Broadwell)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • Tipos de máquina de 64 núcleos
  • SSDs locais
europe-west1-c
  • Plataforma de 2,5 GHz Intel Xeon E5 v2 (Ivy Bridge)(padrão)
  • Plataforma de 2,2 GHz Intel Xeon E5 v4 (Broadwell)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • Tipos de máquina de 64 núcleos
  • SSDs locais
europe-west1-d
  • Plataforma de 2,3 GHz Intel Xeon E5 v3 (Haswell) (padrão)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • Tipos de máquina de 64 núcleos
  • SSDs locais
europe-west2 Londres Londres, 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
asia-southeast1 Cingapura Jurong West, Cingapura asia-southeast1-a
asia-southeast1-b
  • Plataforma de 2,2 GHz Intel Xeon E5 v4 (Broadwell)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • Tipos de máquina de 64 núcleos
  • SSDs locais
asia-east1 Taiwan Changhua County, Taiwan asia-east1-a
  • Plataforma de 2,5 GHz Intel Xeon E5 v2 (Ivy Bridge)(padrão)
  • Plataforma de 2,2 GHz Intel Xeon E5 v4 (Broadwell)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • Tipos de máquina de 64 núcleos
  • SSDs locais
asia-east1-b
  • Plataforma de 2,5 GHz Intel Xeon E5 v2 (Ivy Bridge)(padrão)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • tipos de máquina com 32 núcleos
  • SSDs locais
asia-east1-c
  • Plataforma de 2,5 GHz Intel Xeon E5 v2 (Ivy Bridge)(padrão)
  • Plataforma de 2,0 GHz Intel Xeon (Skylake)
  • tipos de máquina com 32 núcleos
  • SSDs locais
asia-northeast1 Tóquio Tóquio, Japão asia-northeast1-a
asia-northeast1-b
asia-northeast1-c
australia-southeast1 Sydney Sydney, Austrália australia-southeast1-a australia-southeast1-b australia-southeast1-c

* Para os clientes que utilizam a região de São Paulo, todos os contratos de nível de serviço (SLA, na sigla em inglês) de produtos regionais permanecerão em vigor. No entanto, a funcionalidade multirregional e entre regiões que abrange a América do Norte e a América do Sul pode ter disponibilidade ou desempenho reduzido.

Regiões anunciadas

Ao longo de 2017 e 2018, o Google continuará se expandindo nas 11 regiões novas a seguir:

  • Los Angeles (Estados Unidos)
  • Finlândia
  • Frankfurt (Alemanha) Lançado!
  • Londres (Reino Unido) Lançado!
  • Montreal (Canadá)
  • Mumbai (Índia)
  • Países Baixos
  • Virgínia do Norte (Estados Unidos) Lançado!
  • São Paulo (Brasil) Lançado!
  • Cingapura Lançado!
  • Sydney (Austrália) Lançado!

Também anunciaremos regiões adicionais até o final de 2017. Se você quiser acesso antecipado às novas regiões, inscreva-se aqui.

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 datacenter, 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. A 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 a sua instância em execução. O processo de migração afetará o desempenho do convidado em determinado grau, mas a 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 a sua instância desligar, 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 acontecem 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 quando ficará off-line. Dessa forma, você tem muito 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 Google Cloud Platform Console.

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 sua cota de todo o projeto e não poderá criar mais pools de destino em nenhuma região dentro do seu projeto até liberar espaço. Da mesma maneira, 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, eis algumas coisas para se ter em mente:

  • 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 em zonas europe-west1-b e europe-west1-c, se europe-west1-b falhar inesperadamente, as suas instâncias na zona europe-west1-c ainda continuará disponível. 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. Você também deve levar 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-east1 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