Visão geral de redes VPC

Uma rede de nuvem privada virtual (VPC) é a versão virtual de uma rede física, como uma rede de data center. Ela fornece conectividade para as instâncias de máquina virtual (VM) do Compute Engine, clusters do Google Kubernetes Engine (GKE), instâncias de ambiente flexível do App Engine, além de outros recursos no projeto.

Os projetos podem conter várias redes VPC. A menos que você crie uma política organizacional que a proíba, novos projetos começarão com uma rede padrão que tenha uma sub-rede em cada região (uma rede VPC de modo automático).

Especificações

As redes VPC têm as seguintes propriedades:

  • Redes VPC, inclusive as rotas associadas e regras de firewall, são recursos globais. Elas não estão associadas a nenhuma região ou zona específica.

  • Sub-redes são recursos regionais. Cada sub-rede define um intervalo de endereços IP.

  • O tráfego para instâncias e a partir delas pode ser controlado com regras de firewall da rede.

  • Os recursos em uma rede VPC podem se comunicar uns com os outros por meio de endereços IPv4 internos (privados), sujeitos às regras de firewall da rede aplicáveis. Para mais informações, consulte Comunicação dentro da rede.

  • Instâncias com endereços IP internos podem se comunicar com APIs e serviços do Google. Para mais informações, consulte Opções de acesso privado para serviços.

  • A administração da rede pode ser protegida usando papéis do Cloud Identity and Access Management (Cloud IAM).

  • Uma organização pode usar a VPC compartilhada para manter uma rede VPC em um projeto host comum. Os membros autorizados do Cloud IAM de outros projetos na mesma organização podem criar recursos que usem sub-redes da rede VPC compartilhada.

  • As redes VPC podem ser conectadas a outras redes VPC em diferentes projetos ou organizações usando o Peering de rede VPC.

  • As redes VPC podem ser conectadas com segurança em ambientes híbridos usando Cloud VPN ou Cloud Interconnect.

  • As redes VPC são compatíveis somente com tráfego unicast IPv4. Elas não são compatíveis com tráfego broadcast, multicast ou IPv6 dentro da rede: as VMs na rede VPC só podem enviar tráfego para destinos IPv4 e receber tráfego apenas de origens IPv4. No entanto, é possível criar um endereço IPv6 para um balanceador de carga global.

Terminologia de rede e sub-rede

O termo subnet ("sub-rede", em português) é uma abreviação da palavra subnetwork. Eles são usados indistintamente no Console do Google Cloud, nos comandos gcloud e na documentação da API.

Uma sub-rede não é a mesma coisa que uma rede VPC. As redes e sub-redes são diferentes tipos de objetos no Google Cloud.

Redes e sub-redes

Cada rede VPC consiste em uma ou mais partições de intervalo IP úteis chamadas de sub-redes. Cada sub-rede é associada a uma região. As redes VPC não têm intervalos de endereços IP associados a elas. Os intervalos de IP são definidos para as sub-redes.

Uma rede precisa ter pelo menos uma sub-rede para que você possa usá-la. As redes VPC de modo automático criam sub-redes em cada região automaticamente. As redes VPC do modo personalizado começam sem sub-redes, o que proporciona controle total sobre a criação de sub-redes. É possível criar mais de uma sub-rede por região. Para informações sobre as diferenças entre as redes VPC de modo automático e modo personalizado, consulte Tipos de redes VPC.

Ao criar um recurso no Google Cloud, você escolhe uma rede e uma sub-rede. Para recursos que não sejam modelos de instância, você também precisa selecionar uma zona ou região. Selecionar uma zona escolhe implicitamente a região pai. Como as sub-redes são objetos regionais, a região selecionada para um recurso determina as sub-redes que ele pode usar:

  • O processo de criação de uma instância envolve a seleção de uma zona, uma rede e uma sub-rede. As sub-redes disponíveis para seleção são restritas àquelas na região selecionada. O Google Cloud atribui à instância um endereço IP do intervalo de endereços disponíveis na sub-rede.

  • O processo de criação de um grupo de instâncias gerenciadas envolve a seleção de uma zona ou região, dependendo do tipo de grupo e de um modelo de instância. Os modelos de instância disponíveis para seleção são restritos àquelas sub-redes definidas que estão na mesma região selecionada para o grupo de instâncias gerenciadas.

    • Modelos de instância são recursos globais. O processo de criação de um modelo de instância envolve a seleção de uma rede e uma sub-rede. Se você selecionar uma rede VPC de modo automático, poderá usar sub-redes automáticas para adotar a seleção de sub-redes disponível na região selecionada de qualquer grupo de instâncias gerenciadas que usaria o modelo. As redes VPC de modo automático têm uma sub-rede em cada região por definição.
  • O processo de criação de um cluster de contêineres do Kubernetes envolve a seleção de uma zona ou região (dependendo do tipo de cluster), uma rede e uma sub-rede. As sub-redes disponíveis para seleção são restritas àquelas na região selecionada.

Modo de criação da sub-rede

O Google Cloud oferece dois tipos de redes VPC, determinadas pelo modo de criação de sub-rede:

  • Quando uma rede VPC de modo automático é criada, dentro dela cria-se automaticamente uma sub-rede de cada região. Essas sub-redes criadas automaticamente usam um conjunto de intervalos de IP predefinidos que se encaixam no bloco CIDR 10.128.0.0/9. À medida que novas regiões do Google Cloud forem disponibilizadas, novas sub-redes nessas regiões serão adicionadas automaticamente às redes VPC de modo automático usando um intervalo de IP desse bloco. Além das sub-redes criadas de maneira automática, é possível adicionar mais sub-redes manualmente às redes VPC de modo automático nas regiões escolhidas usando intervalos de IP fora de 10.128.0.0/9.

  • Quando uma rede VPC de modo personalizado é criada, nenhuma sub-rede é criada automaticamente. Esse tipo de rede oferece controle total das sub-redes e dos intervalos de IP. Você decide quais sub-redes criar nas regiões escolhidas usando os intervalos de IP especificados.

É possível mudar uma rede VPC do modo automático para o modo personalizado. Essa é uma conversão de mão única; redes VPC de modo personalizado não podem ser alteradas para redes VPC de modo automático. Para ajudar você a decidir que tipo de rede atende a suas necessidades, consulte as considerações para redes VPC de modo automático.

Rede padrão

A menos que você desative essa opção, cada novo projeto começa com uma rede padrão. A rede padrão é uma rede VPC de modo automático com regras de firewall já preenchidas.

É possível desativar a criação de redes padrão criando uma política da organização com a restrição compute.skipDefaultNetworkCreation. Projetos que herdam essa política não terão uma rede padrão.

Considerações sobre redes VPC de modo automático

As redes VPC de modo automático são fáceis de configurar e usar, além de serem adequadas para casos de uso com estes atributos:

  • É útil ter sub-redes criadas automaticamente em cada região.

  • Os intervalos de IP predefinidos das sub-redes não se sobrepõem àqueles que você usaria para propósitos diferentes (por exemplo, conexões do Cloud VPN a recursos locais).

No entanto, as redes VPC de modo personalizado são mais flexíveis e mais adequadas para a produção. Os seguintes atributos destacam casos de uso em que redes VPC de modo personalizado são recomendadas ou obrigatórias:

  • Não é necessário ter uma sub-rede criada automaticamente em cada região.

  • Ter novas sub-redes criadas automaticamente à medida que as novas regiões se tornam disponíveis pode sobrepor os endereços IP usados por sub-redes criadas manualmente ou rotas estáticas, ou podem interferir no planejamento geral da rede.

  • Você precisa de controle total sobre as sub-redes criadas na rede VPC, incluindo regiões e intervalos de endereços IP usados.

  • Você planeja conectar redes VPC usando o peering de rede VPC ou o Cloud VPN. Como as sub-redes de cada rede VPC de modo automático usam o mesmo intervalo predefinido de endereços IP, não é possível conectar essas redes entre si.

Intervalos de sub-rede

Ao criar uma sub-rede, é preciso definir o intervalo de endereços IP principal. Os endereços internos primários dos seguintes recursos vêm do intervalo principal da sub-rede: instâncias de VM, balanceadores de carga internos e encaminhamento de protocolo interno. Se quiser, é possível adicionar intervalos de endereços IP secundários a uma sub-rede, que são usados apenas por intervalos de IP de alias. No entanto, você pode configurar intervalos de IP de alias para instâncias do intervalo primário ou secundário de uma sub-rede.

Cada intervalo de IP primário ou secundário de todas as sub-redes de uma rede VPC precisa ser um bloco CIDR válido exclusivo. Consulte os limites por rede para o número de intervalos de IP secundários que podem ser definidos.

Suas sub-redes não precisam formar um bloco CIDR contíguo predefinido, mas você pode fazer isso se quiser. Por exemplo, as redes VPC de modo automático criam sub-redes que se encaixam em um intervalo de IP de modo automático predefinido.

Para mais informações, consulte Como trabalhar com sub-redes.

Intervalos válidos

Os intervalos de endereços IP primários e secundários de uma sub-rede são endereços IP internos regionais. A tabela a seguir descreve intervalos válidos.

Range Descrição
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Endereços IP privados RFC 1918
100.64.0.0/10 Espaço de endereços compartilhado RFC 6598
192.0.0.0/24 Atribuições do protocolo IETF RFC 6890
192.0.2.0/24 (TEST-NET-1)
198.51.100.0/24 (TEST-NET-2)
203.0.113.0/24 (TEST-NET-3)
Documentação RFC 5737
192.88.99.0/24 Retransmissão IPv6 para IPv4 (obsoleta) RFC 7526
198.18.0.0/15 Teste de comparativo de mercado RFC 2544
240.0.0.0/4 Reservado RFC 1112
Endereços IP públicos reutilizados de modo privado Inclui endereços IP que não fazem parte dos intervalos de RFC listados nesta tabela e nem do conjunto restrito. Quando você usa esses endereços como intervalos de sub-rede, o Google Cloud não encaminha o tráfego publicamente para eles.

Para peering de rede VPC, as rotas de sub-rede para endereços IP públicos não são trocadas automaticamente. As rotas de sub-rede são exportadas automaticamente, mas as redes com peering precisam ser explicitamente configuradas para importar e usá-las.

Os intervalos de sub-rede têm as seguintes restrições:

  • Os intervalos de sub-rede não podem corresponder, ser mais estreitos ou mais amplos que um intervalo restrito. Por exemplo, 169.0.0.0/8 não é um intervalo de sub-rede válido porque se sobrepõe ao intervalo de link local 169.254.0.0/16 (RFC 3927), que é um intervalo restrito.

  • Os intervalos de sub-rede não podem abranger um intervalo RFC (descrito na tabela anterior) e um intervalo de endereços IP públicos usado de maneira privada. Por exemplo, 172.16.0.0/10 não é um intervalo de sub-rede válido porque se sobrepõe ao RFC 1918 e aos endereços IP públicos.

  • Os intervalos de sub-rede não podem abranger vários intervalos de RFC. Por exemplo, 192.0.0.0/8 não é um intervalo de sub-rede válido porque inclui 192.168.0.0/16 (de RFC 1918) e 192.0.0.0/24 (de RFC 6890). No entanto, é possível criar duas sub-redes com intervalos primários diferentes, uma com 192.0.0.0/16 e outra com 192.0.0.0/24. Ou você pode usar esses dois intervalos na mesma sub-rede se transformar um deles em um intervalo secundário.

Intervalos fora das limitações da RFC 1918

Se você selecionar um intervalo de sub-rede fora do intervalo da RFC 1918, considere a seguinte limitação:

  • O Cloud DNS tem limitações com sub-redes que usam intervalos de IP não RFC 1918. Consulte a documentação do Cloud DNS para mais informações.

Intervalos restritos

Os intervalos restritos incluem endereços IP públicos do Google e intervalos RFC comumente reservados, conforme descrito na tabela a seguir. Esses intervalos não podem ser usados para intervalos de sub-rede.

Range Descrição
Endereços IP públicos para APIs e serviços do Google, inclusive netblocks do Google Cloud. Encontre esses endereços IP em http://gstatic.com/ipranges/goog.txt.
199.36.153.4/30 e 199.36.153.8/30 Endereços IP virtuais específicos do Acesso privado do Google
0.0.0.0/8 Rede (local) atual RFC 1122
127.0.0.0/8 Host local RFC 1122
169.254.0.0/16 Link local RFC 3927
224.0.0.0/4 Multicast RFC 5771
255.255.255.255/32 Endereço de destino da transmissão limitada RFC 8190 e RFC 919

Endereços IP reservados em uma sub-rede

Cada sub-rede tem quatro endereços IP reservados no intervalo de IP principal. Não há endereços IP reservados nos intervalos de IP secundários.

Endereço IP reservado Descrição Exemplo
Rede Primeiro endereço no intervalo de IP primário da sub-rede 10.1.2.0 em 10.1.2.0/24
Gateway padrão Segundo endereço no intervalo de IP primário da sub-rede 10.1.2.1 em 10.1.2.0/24
Penúltimo endereço Penúltimo endereço no intervalo de IP primário da sub-rede que é reservado pelo Google Cloud para um possível uso futuro 10.1.2.254 em 10.1.2.0/24
Transmissão Último endereço no intervalo de IP primário da sub-rede 10.1.2.255 em 10.1.2.0/24

Intervalos de IP do modo automático

Esta tabela lista os intervalos de IP para as sub-redes criadas automaticamente em uma rede VPC de modo automático. Os intervalos de IP dessas sub-redes cabem no bloco CIDR 10.128.0.0/9. As redes VPC de modo automático são criadas com uma sub-rede por região e recebem automaticamente novas sub-redes em novas regiões. Partes não utilizadas de 10.128.0.0/9 são reservadas para uso futuro no Google Cloud.

Region Intervalo de IP (CIDR) Gateway padrão Endereços utilizáveis (inclusivos)
asia-east1 10.140.0.0/20 10.140.0.1 10.140.0.2 a 10.140.15.253
asia-east2 10.170.0.0/20 10.170.0.1 10.170.0.2 a 10.170.15.253
asia-northeast1 10.146.0.0/20 10.146.0.1 10.146.0.2 a 10.146.15.253
asia-northeast2 10.174.0.0/20 10.174.0.1 10.174.0.2 a 10.174.15.253
asia-northeast3 10.178.0.0/20 10.178.0.1 10.178.0.2 para 10.178.15.253
asia-south1 10.160.0.0/20 10.160.0.1 10.160.0.2 a 10.160.15.253
asia-southeast1 10.148.0.0/20 10.148.0.1 10.148.0.2 a 10.148.15.253
australia-southeast1 10.152.0.0/20 10.152.0.1 10.152.0.2 a 10.152.15.253
europe-north1 10.166.0.0/20 10.166.0.1 10.166.0.2 a 10.166.15.253
europe-west1 10.132.0.0/20 10.132.0.1 10.132.0.2 a 10.132.15.253
europe-west2 10.154.0.0/20 10.154.0.1 10.154.0.2 a 10.154.15.253
europe-west3 10.156.0.0/20 10.156.0.1 10.156.0.2 a 10.156.15.253
europe-west4 10.164.0.0/20 10.164.0.1 10.164.0.2 a 10.164.15.253
europe-west6 10.172.0.0/20 10.172.0.1 10.172.0.2 a 10.172.15.253
northamerica-northeast1 10.162.0.0/20 10.162.0.1 10.162.0.2 a 10.162.15.253
southamerica-east1 10.158.0.0/20 10.158.0.1 10.158.0.2 a 10.158.15.253
us-central1 10.128.0.0/20 10.128.0.1 10.128.0.2 a 10.128.15.253
us-east1 10.142.0.0/20 10.142.0.1 10.142.0.2 ao 10.142.15.253
us-east4 10.150.0.0/20 10.150.0.1 10.150.0.2 a 10.150.15.253
us-west1 10.138.0.0/20 10.138.0.1 10.138.0.2 a 10.138.15.253
us-west2 10.168.0.0/20 10.168.0.1 10.168.0.2 a 10.168.15.253
us-west3 10.180.0.0/20 10.180.0.1 10.180.0.2 para 10.180.15.253
us-west4 10.182.0.0/20 10.182.0.1 10.182.0.2 a 10.182.15.253

Rotas e regras de firewall

Rotas

Rotas definem caminhos para os pacotes que saem das instâncias (tráfego de saída). As rotas no Google Cloud são divididas em duas categorias: geradas pelo sistema e personalizadas.

Cada nova rede começa com dois tipos de rotas geradas pelo sistema:

  • A rota padrão define um caminho para o tráfego deixar a rede VPC. Ela fornece acesso geral à Internet para as VMs que atendem aos requisitos de acesso à Internet. Ela também fornece o caminho típico para o Acesso privado do Google.

  • Uma rota de sub-rede é criada para cada um dos intervalos de IP associados a uma sub-rede. Cada sub-rede tem pelo menos uma rota de sub-rede para o intervalo de IP primário dela. Rotas de sub-redes adicionais são criadas para uma sub-rede se você adicionar intervalos de IP secundários a ela. As rotas de sub-rede definem os caminhos para que o tráfego alcance as VMs que usam as sub-redes. Não é possível remover manualmente as rotas das sub-redes.

Rotas personalizadas são rotas estáticas que você cria manualmente ou rotas dinâmicas mantidas de modo automático por um ou mais de seus Cloud Routers. Para mais informações, consulte rotas personalizadas.

Para ver detalhes completos sobre o roteamento no Google Cloud, consulte a visão geral das rotas.

Modo de roteamento dinâmico

Cada rede VPC tem um modo de roteamento dinâmico associado que controla o comportamento de todos os Cloud Routers. Os Cloud Routers compartilham rotas com sua rede VPC e aprendem rotas dinâmicas personalizadas de redes conectadas quando você conecta sua rede VPC a outra rede usando um túnel do Cloud VPN que usa roteamento dinâmico ou usando Interconexão dedicada ou Interconexão por parceiro.

  • O roteamento dinâmico regional é o padrão. Neste modo, as rotas para os recursos no local aprendidas por um determinado Cloud Router na rede VPC aplicam-se apenas às sub-redes na mesma região do Cloud Router. A menos que tenha sido modificado por divulgações personalizadas, cada Cloud Router só compartilha as rotas para sub-redes na região dela com a contraparte local.

  • O roteamento dinâmico global altera o comportamento de todos os Cloud Routers na rede de modo que as rotas para recursos locais que eles aprendem estejam disponíveis em todas as sub-redes na rede VPC, independentemente da região. A menos que tenha sido modificado por divulgações personalizadas, cada Cloud Router compartilha rotas para todas as sub-redes da rede VPC com a contraparte local.

Para ver informações sobre como o conjunto de rotas compartilhadas por um Cloud Router pode ser personalizado, consulte Anúncios personalizados.

O modo de roteamento dinâmico pode ser definido quando você cria ou modifica uma rede VPC. É possível alterar o modo de roteamento dinâmico de regional para global e vice-versa sem restrições. Para ver instruções, consulte Alteração do modo de roteamento dinâmico.

Regras de firewall

As regras de firewall aplicam-se ao tráfego de saída e de entrada na rede. As regras de firewall controlam o tráfego mesmo que esteja totalmente dentro da rede, incluindo a comunicação entre instâncias de VM.

Toda rede VPC tem duas regras de firewall implícitas. Uma regra implícita permite todo o tráfego de saída e a outra nega todo o tráfego de entrada. Não é possível excluir as regras implícitas, mas é possível modificá-las com suas próprias regras. O Google Cloud sempre bloqueia o tráfego, independentemente das regras de firewall. Para mais informações, consulte Tráfego bloqueado.

Para monitorar qual regra de firewall permitiu ou negou uma conexão específica, consulte Geração de registros de regras de firewall.

Comunicações e acesso

Comunicação dentro da rede

As rotas de sub-rede geradas pelo sistema definem os caminhos para enviar tráfego entre instâncias dentro da rede usando endereços IP internos (privados). Para que uma instância possa se comunicar com outra, as regras de firewall apropriadas também precisam ser configuradas, porque cada rede tem uma regra de firewall de negação implícita para o tráfego de entrada.

Exceto para a rede padrão, é necessário criar explicitamente regras de firewall de entrada com prioridade mais alta para permitir que as instâncias se comuniquem umas com as outras. A rede padrão inclui várias regras de firewall, além das regras implícitas, incluindo a regra default-allow-internal, que permite a comunicação de instância a instância na rede. A rede padrão também vem com regras de entrada que permitem protocolos como RDP e SSH.

As regras que vêm com a rede padrão também são apresentadas como opções para você aplicar a novas redes VPC de modo automático criadas com o Console do Cloud.

Requisitos de acesso à Internet

Os seguintes critérios precisam ser atendidos para que uma instância tenha acesso de saída à Internet:

  • A rede precisa ter uma rota de gateway de Internet padrão válida ou uma rota personalizada com o intervalo de IP de destino mais comum (0.0.0.0/0). Essa rota define o caminho para a Internet. Para saber mais, consulte Rotas.

  • As regras de firewall precisam permitir o tráfego de saída da instância. A menos que seja modificada por uma regra de prioridade mais alta, a regra de permissão implícita para o tráfego de saída permite o tráfego de saída de todas as instâncias.

  • Um dos seguintes itens precisa ser verdadeiro:

    • A instância precisa ter um endereço IP externo. É possível atribuir um endereço IP externo a uma instância durante ou depois da criação dela.

    • A instância precisa poder usar o Cloud NAT ou um proxy baseado em instância que seja o destino de uma rota 0.0.0.0/0 estática.

Comunicações e acesso para o App Engine

As regras de firewall da VPC aplicam-se a recursos executados na rede VPC, como VMs do Compute Engine. Para instâncias do App Engine, as regras de firewall funcionam da seguinte maneira:

  • Ambiente padrão do App Engine: somente regras de firewall do Google App Engine se aplicam ao tráfego de entrada. Como as instâncias do ambiente padrão do App Engine não são executadas na rede VPC, as regras de firewall da VPC não se aplicam a elas.

  • Ambiente flexível do App Engine: as regras de firewall do Google App Engine e da VPC se aplicam ao tráfego de entrada. O tráfego de entrada precisa da permissão dos dois tipos de regras de firewall. Para o tráfego de saída, aplicam-se as regras de firewall da VPC.

Para mais informações sobre como controlar o acesso a instâncias do App Engine, consulte Segurança do aplicativo.

Traceroute para endereços IP externos

Por motivos internos, o Google Cloud aumenta o contador do TTL de pacotes transferidos para os próximos saltos na rede do Google. Ferramentas como traceroute e mtr podem fornecer resultados incompletos, porque o TTL não expira em alguns saltos. Os saltos dentro e fora da rede do Google podem estar ocultos nestas circunstâncias:

  • Quando você envia pacotes de instâncias do Compute Engine para endereços IP externos, incluindo endereços IP externos de outros recursos ou destinos do Google Cloud na Internet.

  • Quando você envia pacotes para o endereço IP externo associado a uma instância do Compute Engine ou a outro recurso do Google Cloud.

O número de saltos ocultos varia de acordo com os níveis de serviço da rede, a região e outros fatores da instância. Se houver apenas alguns saltos, é possível que todos eles fiquem ocultos. Os saltos ausentes de um resultado de traceroute ou mtr não significam que o tráfego de saída seja descartado.

Não há solução alternativa para esse comportamento. É preciso levar isso em consideração ao configurar o monitoramento terceirizado que se conecta a um endereço IP externo associado a uma VM.

Limites de capacidade de saída

As informações de capacidade da rede estão disponíveis na seção Largura de banda da rede.

Exemplo de rede VPC

O exemplo a seguir ilustra uma rede VPC de modo personalizado com três sub-redes em duas regiões:

Exemplo de rede VPC (clique para ampliar)
Exemplo de rede VPC (clique para ampliar)
  • Subnet1 é definida como 10.240.0.0/24 na região us-west1.
    • Há duas instâncias de VM na zona us-west1-a nesta sub-rede. Os endereços IP vêm do intervalo disponível de endereços na subnet1.
  • Subnet2 é definida como 192.168.1.0/24 na região us-east1.
    • Há duas instâncias de VM na zona us-east1-a nesta sub-rede. Os endereços IP vêm do intervalo disponível de endereços na subnet2.
  • Subnet3 é definida como 10.2.0.0/16, também na região us-east1.
    • Uma instância de VM na zona us-east1-a e uma segunda instância na zona us-east1-b estão em subnet3, cada uma recebendo um endereço IP do intervalo disponível. Como as sub-redes são recursos regionais, as instâncias podem ter interfaces de rede associadas a qualquer sub-rede na mesma região que contém as zonas.

Desempenho da rede

Latência

A latência medida entre regiões para redes do Google Cloud pode ser encontrada no nosso painel ao vivo. O painel mostra as métricas e a metodologia medianas de desempenho de capacidade e latência entre regiões do Google Cloud para reproduzir esses resultados usando o PerfKit Benchmarker.

O Google Cloud normalmente mede latências de ida e volta com menos de 55 μs no 50º percentil e latências de cauda com menos de 80 μs no 99º percentil entre instâncias de VM c2-standard-4 na mesma zona.

O Google Cloud normalmente mede latências de ida e volta com menos de 45 μs no 50º percentil e latências com menos de 60 μs no 99º percentil entre instâncias de VM c2-standard-4 na mesma rede de baixa latência (política de veiculação "compacta"). A política de posicionamento compacto diminui a latência da rede, garantindo que as VMs estejam localizadas fisicamente na mesma rede de baixa latência.

Metodologia: a latência dentro da zona é monitorada por meio de uma sondagem de caixa preta que executa constantemente o comparativo TCP_RR netperf entre um par de VMs do tipo c2 em cada zona em que as instâncias c2 estão disponíveis. Ele coleta resultados P50 e P99 para configuração com e sem a política de posicionamento compacto. O comparativo TCP_RR avalia o desempenho da solicitação/resposta medindo a taxa de transação. Se os aplicativos exigirem a melhor latência possível, as instâncias c2 serão recomendadas.

Perda de pacotes

O Google Cloud rastreia a perda de pacotes entre regiões medindo regularmente a perda de ida e volta em todas as regiões. Nossa meta é que a média global dessas medições seja inferior a 0,01%.

Metodologia: uma sondagem de caixa preta de VM para VM monitora a perda de pacotes para cada par de zonas usando pings e agrega os resultados em uma métrica de perda global. Essa métrica é acompanhada com uma janela de um dia.

A seguir