Largura de banda da rede

O Google Cloud é responsável pela largura de banda por instância de máquina virtual (VM), e não por interface de rede (vNIC) ou endereço IP. O tipo de máquina de uma VM define a maior taxa de saída possível. No entanto, só é possível atingir essa taxa de saída máxima em circunstâncias específicas.

Nesta página, descrevemos as expectativas, que são úteis para o planejamento das implantações. Ele categoriza a largura de banda a partir de duas dimensões:

  • Saída ou entrada: conforme usados nesta página, a saída e a entrada são sempre da perspectiva de uma VM do Google Cloud:
    • Os pacotes enviados de uma VM do Google Cloud compõem o tráfego de saída (envio).
    • Os pacotes enviados a uma VM do Google Cloud compõem o tráfego de entrada (recebimento).
  • Como o pacote é roteado: um pacote pode ser roteado de uma VM de envio ou de uma VM de recebimento usando rotas cujos próximos saltos estão dentro de uma rede VPC ou rotas fora de uma rede VPC.

Nem outras interfaces de rede virtual (vNICs, na sigla em inglês) nem endereços IP extras por vNIC aumentam a largura de banda de entrada ou saída de uma VM. Por exemplo, uma VM C3 com 22 vCPUs está limitada a 23 Gbps de largura de banda de saída total. Se você configurar a VM C3 com duas vNICs, a VM ainda será limitada a 23 Gbps de largura de banda de saída total, e não de 23 Gbps por vNIC.

Todas as informações nesta página são aplicáveis às VMs do Compute Engine, bem como a produtos que dependam delas. Por exemplo, um nó do Google Kubernetes Engine é uma VM do Compute Engine.

Resumo da largura de banda

A tabela a seguir ilustra as expectativas de largura de banda com base no fato de um pacote ser enviado (saída) ou recebido por uma VM e o método de roteamento de pacotes.

Saída

Expectativas de largura de banda
Roteamento em uma rede VPC

  • Principalmente definida por uma largura de banda de saída máxima por VM com base no tipo de máquina da VM de envio e se a rede Tier_1 está ativada.

    • VMs N2, N2D, C2 e C2D com suporte de rede Tier_1 a limites de largura de banda de saída de até 100 Gbps.
    • As VMs H3 são compatíveis com limites de largura de banda de saída de VM para VM de até 200 Gbps.
    • As VMs A2 e G2 são compatíveis com limites de largura de banda de saída de até 100 Gbps.
    • As VMs A3 são compatíveis com limites de largura de banda de saída de até 1.000 Gbps.
    • As VMs C3, C3D e Z3 (pré-lançamento) aceitam limites de largura de banda de saída de até 200 Gbps com a rede Tier_1.
  • Para outros fatores, definições e cenários, consulte Saída para destinos roteáveis em uma rede VPC.
Roteamento fora de uma rede VPC

  • Principalmente definida por uma largura de banda de saída máxima por VM com base no tipo de máquina da VM de envio e se a rede Tier_1 está ativada. Com exceção das VMs H3, a saída máxima possível de uma VM de envio para um destino fora da rede VPC não pode exceder o seguinte:

    • 7 Gbps no total quando a rede Tier_1 não está ativada
    • 25 Gbps no total quando a rede Tier_1 está ativada
    • 3 Gbps por fluxo
  • Para outros fatores, definições e advertências, consulte Saída para destinos fora de uma rede VPC.

Entrada

Expectativas de largura de banda
Roteamento em uma rede VPC
  • Geralmente, as taxas de entrada são semelhantes às taxas de saída de um tipo de máquina.
  • O tamanho da sua VM, a capacidade da placa de rede (NIC) do servidor, o tráfego que entra em outras VMs convidadas em execução no mesmo hardware de host, a configuração de rede do SO convidado e o número de leituras de disco realizadas pelo na VM podem afetar a taxa de entrada.
  • O Google Cloud não impõe outras limitações às taxas de entrada em uma rede VPC.
  • Para outros fatores, definições e cenários, consulte Entrada para destinos roteáveis em uma rede VPC.
Roteamento fora de uma rede VPC

  • O Google Cloud protege cada VM limitando o tráfego de entrada roteado fora de uma rede VPC. O limite é a primeira das seguintes taxas encontradas:

    • 1.800.000 pps (pacotes por segundo)
    • 10 Gbps
  • Para séries de máquinas compatíveis com várias NICs físicas, como a A3, o limite é a primeira das seguintes taxas encontradas:
    • 1.800.000 pps (pacotes por segundo) por NIC física
    • 30 Gbps por NIC física
  • Para outros fatores, definições e cenários, consulte Entrada para destinos fora de uma rede VPC.

Largura de banda de saída

O Google Cloud limita a largura de banda de saída usando as taxas máximas de saída por VM com base no tipo de máquina da VM que envia o pacote e se o destino do pacote pode ser acessado usando rotas dentro de uma rede VPC ou rotas fora de uma rede VPC. A largura de banda de saída inclui pacotes emitidos por todas as NICs da VM e dados transferidos para todos os discos permanentes conectados à VM.

Largura de banda máxima de saída por VM

A largura de banda de saída máxima por VM geralmente é de 2 Gbps por vCPU, mas há algumas diferenças e exceções, dependendo da série de máquinas. A tabela a seguir mostra o intervalo de limites máximos para largura de banda de saída do tráfego roteado dentro de uma rede VPC apenas para o nível de rede padrão, não por desempenho de rede da VM de Tier_1. de dois minutos.

Série de máquina Menor limite máximo de saída por VM sem a rede Tier_1 Maior limite máximo de saída por VM sem a rede Tier_1
E2 1 Gbps 16 Gbps
C3 23 Gbps 100 Gbps
C3D 20 Gbps 100 Gbps
T2D 10 Gbps 32 Gbps
N2,C2, N2D e C2D 10 Gbps 32 Gbps
H3 N/A 200 Gbps
Z3 (pré-lançamento) 23 Gbps 100 Gbps
N1 (excluindo VMs com 1 vCPU) 10 Gbps 32 Gbps na plataforma de CPU Intel Skylake
16 Gbps em plataformas de CPU mais antigas que a Intel Skylake
Tipos de máquina N1 com 1 vCPU, f1-micro e g1-small 2 Gbps 2 Gbps
A3, A2 e G2 N/A Com base no tipo de GPU

Você pode encontrar a largura de banda máxima de saída por VM para cada tipo de máquina listado na página da família de máquinas específica:

A largura de banda máxima de saída por VM não é uma garantia. A largura de banda de saída real pode ser reduzida de acordo com fatores como os seguintes:

  • Driver Ethernet convidado: o gVNIC oferece um desempenho melhor do que a interface de rede VirtIO
  • Tamanho do pacote
  • Sobrecarga de protocolo
  • O número de fluxos
  • configurações do driver Ethernet do SO convidado da VM, como descarregamento de soma de verificação e descarga de segmentação TCP (TSO, na sigla em inglês)
  • Congestionamento da rede
  • Em uma situação em que os discos permanentes concorrem com outro tráfego de saída de rede, 60% da largura de banda máxima da rede é destinada às gravações do Persistent Disk, deixando 40% para o outro tráfego de saída. Consulte Fatores que afetam o desempenho do disco na documentação do Persistent Disk para mais detalhes.

Para conseguir a maior largura de banda de saída máxima por VM:

Saída para destinos roteáveis em uma rede VPC

Da perspectiva de uma VM de envio e para endereços IP de destino acessíveis por rotas dentro de uma rede VPC, o Google Cloud limita o tráfego de saída usando estas regras:

  • Largura de banda de saída máxima por VM: a largura de banda máxima de saída por VM descrita na seção Largura de banda de saída máxima por VM.
  • Largura de banda de saída inter-regional por projeto: se uma VM de envio e um destino interno ou o próximo salto estiverem em regiões diferentes, o Google Cloud vai aplicar um limite máximo de largura de banda de saída inter-regional. de dois minutos. É improvável que a maioria dos clientes atinja esse limite. Para dúvidas sobre esse limite, registre um caso de suporte.
  • Limites do Cloud VPN e do Cloud Interconnect: ao enviar tráfego de uma VM para um destino de endereço IP interno roteável por um túnel do Cloud VPN de próximo salto ou um anexo da VLAN do Cloud Interconnect, a largura de banda de saída é limitada por:

Os destinos roteáveis em uma rede VPC incluem todos os destinos a seguir. Cada um deles pode ser acessado da perspectiva da VM de envio por uma rota em que o próximo salto não é o gateway de Internet padrão:

  • Endereços IPv4 internos regionais em intervalos de endereços IPv4 principais e secundários da sub-rede, incluindo intervalos de endereços IPv4 particulares e públicos de uso particular, usados por estes recursos de destino:
    • O endereço IPv4 interno principal da interface de rede (vNIC) de uma VM de recebimento. Quando uma VM de envio se conecta à placa de rede (vNIC) de outra VMExterno endereço IPv4, os pacotes são roteados usando um gateway de Internet padrão do próximo salto. Saída para destinos fora de uma rede VPC se aplica.
    • Um endereço IPv4 interno em um intervalo de IP do alias da placa de rede (vNIC) da VM de recebimento.
    • Um endereço IPv4 interno de uma regra de encaminhamento interno para encaminhamento de protocolo ou para um balanceador de carga de rede de passagem interna.
  • Endereços IPv4 internos globais para estes recursos de destino:
  • Intervalos de endereços de sub-rede IPv6 internos usados por estes recursos de destino:
    • Um endereço IPv6 do intervalo de endereços IPv6 /96 atribuído a uma pilha dupla que recebe a vNIC da VM.
    • Um endereço IPv6 do intervalo de endereços IPv6 /96 de uma regra de encaminhamento interna para encaminhamento de protocolo ou para um balanceador de carga de rede de passagem interna.
  • Intervalos de endereços de sub-rede IPv6 externos usados por esses recursos de destino quando os pacotes são roteados usando rotas de sub-rede ou rotas de sub-rede de peering na rede VPC ou por rotas personalizadas no Rede VPC que não usa o próximo salto padrão do gateway da Internet:
    • Um endereço IPv6 do intervalo de endereços IPv6 /96 atribuído a uma pilha dupla que recebe a vNIC da VM.
    • Um endereço IPv6 do intervalo de endereços IPv6 /96 de uma regra de encaminhamento externa para encaminhamento de protocolo ou para um balanceador de carga de rede de passagem externa.
  • Outros destinos acessíveis usando as seguintes rotas de rede VPC:

A lista a seguir classifica o tráfego do envio de VMs para destinos internos, da maior largura de banda possível para a menor:

Saída para destinos fora de uma rede VPC

Da perspectiva de uma VM de envio e para endereços IP de destino fora de uma rede VPC, o Google Cloud limita o tráfego de saída às taxas a seguir que forem alcançadas primeiro:

  • Largura de banda de saída por VM: a largura de banda máxima para todas as conexões de uma VM com destinos fora de uma rede VPC é o menor Largura de banda máxima de saída por VM e um destes preços:

    • 25 Gbps, se a rede Tier_1 estiver ativada
    • 7 Gbps, se a rede Tier_1 não estiver ativada
    • 1 Gbps para VMs H3
    • 7 Gbps por NIC física para séries de máquinas compatíveis com várias NICs físicas, como A3.

    Por exemplo, mesmo que uma instância n2-standard-16 tenha uma largura de banda de saída máxima por VM de 32 Gbps, a largura de banda de saída por VM de uma instância n2-standard-16 para destinos externos é de 25 Gbps ou 7 Gbps, dependendo da ativação da rede Tier_1.

  • Taxa de saída máxima por fluxo: a largura de banda máxima para cada conexão de 5 tuplas única, de uma VM para um destino fora de uma rede VPC, é 3 Gbps, exceto no H3, onde é de 1 Gbps.

  • Largura de banda de saída de Internet por projeto: a largura de banda máxima para todas as conexões das VMs em cada região de um projeto para destinos fora de uma rede VPC é definida pelas cotas de largura de banda de saída da Internet do projeto.

Os destinos fora de uma rede VPC incluem todos os destinos a seguir. Cada um deles pode ser acessado por uma rota na rede VPC da VM de envio, em que o próximo salto é o gateway de Internet padrão:

  • Endereços IPv4 e IPv6 externos globais para balanceadores de carga de rede de proxy externo e balanceadores de carga de aplicativo externos
  • Endereços IPv4 externos regionais para recursos do Google Cloud, incluindo endereços IPv4 externos de vNIC da VM, endereços IPv4 externos para encaminhamento de protocolo externo, balanceadores de carga de rede de passagem externa e pacotes de resposta para gateways NAT do Cloud.
  • Endereços IPv6 externos regionais em sub-redes de pilha dupla comde intervalos de endereços IPv6 externos usado por endereços IPv6 externos de VMs de pilha dupla, encaminhamento de protocolo externo e balanceadores de carga de rede de passagem externa, desde que a sub-rede esteja localizada em uma rede VPC separada sem peering e o endereço IPv6 de destino. ou o intervalo é acessível por meio de uma rota na rede VPC da VM de envio, cujo próximo saltoé o gateway padrão da Internet. Se uma sub-rede de pilha dupla com um intervalo de endereços IPv6 externo estiver localizada na mesma rede VPC ou em uma rede VPC com peering, consulte Saída para destinos roteáveis em uma rede VPC.
  • Outros destinos externos acessíveis por meio de uma rota estática na rede VPC da VM de envio, desde que o próximo salto da rota seja o gateway de Internet padrão.

Para detalhes sobre quais recursos do Google Cloud usam quais tipos de endereços IP externos, consulte Endereços IP externos.

Largura de banda de entrada

O Google Cloud processa a largura de banda de entrada (entrada) dependendo de como o pacote de entrada é roteado para uma VM de recebimento.

Entrada para destinos roteáveis em uma rede VPC

Uma VM de recebimento pode processar tantos pacotes de entrada quanto o tipo de máquina, o sistema operacional e outras condições de rede permitirem. O Google Cloud não implementará nenhuma restrição de largura de banda intencional nos pacotes de entrada entregues a uma VM se o pacote de entrada for entregue usando rotas dentro de uma rede VPC:

  • Rotas de sub-rede na rede VPC da VM de recebimento
  • Rotas de sub-rede com peering em uma rede VPC com peering
  • Rotas em outra rede que tenham como próximos saltos os túneis do Cloud VPN, anexos do Cloud Interconnect (VLAN) ou VMs de dispositivo roteador localizadas na rede VPC da VM de destino

Estes são os destinos de pacotes roteados dentro de uma rede VPC:

  • O endereço IPv4 interno principal da interface de rede (vNIC) de uma VM de recebimento. Os endereços IPv4 internos primários são endereços IPv4 internos regionais provenientes do intervalo de endereços IPv4 principal de uma sub-rede.
  • Um endereço IPv4 interno de um intervalo de IP do alias da placa de rede (vNIC) da VM de destino. Os intervalos de IP do alias podem vir de um intervalo de endereços IPv4 principal da sub-rede ou de um dos intervalos de endereços IPv4 secundários.
  • Um endereço IPv6 do intervalo de endereços IPv6 /96 atribuído a uma pilha dupla que recebe a vNIC da VM. Os intervalos IPv6 da VM podem vir destes intervalos IPv6 de sub-redes:
  • Um endereço IPv4 interno de uma regra de encaminhamento usado pelo encaminhamento de protocolo interno para a VM de recebimento ou o balanceador de carga de rede de passagem interna em que a VM de recebimento é um back-end do balanceador de carga. Os endereços IPv4 da regra de encaminhamento interno vêm do intervalo de endereços IPv4 principal de uma sub-rede.
  • Um endereço IPv6 interno do intervalo IPv6 /96 de uma regra de encaminhamento usado pelo encaminhamento de protocolo interno para a VM de recebimento ou o balanceador de carga de rede de passagem interna em que a VM de recebimento é um back-end do balanceador de carga. Os endereços IPv6 da regra de encaminhamento interno vêm do intervalo de endereços IPv6 interno de uma sub-rede.
  • Um endereço IPv6 externo do intervalo IPv6 /96 de uma regra de encaminhamento usado pelo encaminhamento de protocolo externo para a VM de recebimento ou o balanceador de carga de rede de passagem externa em que a VM de recebimento é um back-end do balanceador de carga quando o pacote de entrada é roteado dentro da rede VPC usando uma das rotas listadas anteriormente nesta seção. Os endereços IPv6 da regra de encaminhamento externo vêm do intervalo de endereços IPv6 externo de uma sub-rede.
  • Um endereço IP dentro do intervalo de destino de uma rota estática personalizada usando o recebimento da VM como uma VM de próximo salto (next-hop-instance ou next-hop-address).
  • Um endereço IP no intervalo de destino de uma rota estática personalizada usando um próximo salto de balanceador de carga de rede interno (next-hop-ilb), se a VM recebida for um back-end para esse balanceador de carga.

Entrada para destinos fora de uma rede VPC

O Google Cloud implementa os limites de largura de banda a seguir para pacotes de entrada entregues a uma VM de recebimento usando rotas fora de uma rede VPC. Quando há balanceamento de carga envolvido, os limites de largura de banda são aplicados individualmente a cada VM de recebimento.

Para séries de máquinas que não são compatíveis com várias NICs físicas, a restrição de largura de banda de entrada aplicável se aplica coletivamente a todas as NICs virtuais. O limite é a primeira das seguintes taxas encontradas:

  • 180.000.000 pacotes por segundo
  • 10 Gbps

Para séries de máquinas compatíveis com várias NICs físicas, como a A3, a restrição aplicável de largura de banda de entrada se aplica individualmente a cada NIC física. O limite é a primeira das seguintes taxas encontradas:

  • 1.800.000 pacotes por segundo por NIC física
  • 30 Gbps por NIC física

Os destinos de pacotes roteados usando rotas fora de uma rede VPC incluem:

  • Um endereço IPv4 externo atribuído em uma configuração de acesso NAT um para um em uma das interfaces de rede (NICs) da VM de destino.
  • Um endereço IPv6 externo do intervalo de endereços IPv6 /96 atribuído a uma placa de rede (vNIC) de uma VM de recebimento de pilha dupla quando o pacote de entrada é roteado usando uma rota fora da rede VPC da VM de destino.
  • Um endereço IPv4 externo de uma regra de encaminhamento usado pelo protocolo externo encaminhando para a VM de recebimento ou o balanceador de carga de rede de passagem externa em que a VM de recebimento é um back-end do balanceador de carga.
  • Um endereço IPv6 externo do intervalo IPv6 /96 de uma regra de encaminhamento usado pelo encaminhamento de protocolo externo para a VM de recebimento ou o balanceador de carga de rede de passagem externa em que a VM de recebimento é um back-end do balanceador de carga quando o pacote de entrada é roteado usando uma rota fora de uma rede VPC.
  • Respostas de entrada estabelecidas que foram processadas pelo Cloud NAT.

Quadros enormes

Para receber e enviar frames muito grandes, configure a rede VPC usada pelas VMs. Defina a unidade máxima de transmissão (MTU, na sigla em inglês) para um valor maior, até 8896.

Valores de MTU mais altos aumentam o tamanho do pacote e reduzem a sobrecarga do cabeçalho do pacote, o que aumenta a capacidade de dados do payload.

Para usar frames jumbo com o driver gVNIC, use a versão 1.3 ou mais recente do driver. Nem todas as imagens públicas do Google Cloud incluem essa versão do driver. Para mais informações sobre a compatibilidade do sistema operacional com frames jumbo, consulte a guia Recursos de rede na página Detalhes do sistema operacional. As versões de imagem que indicam suporte total a frames jumbo incluem o driver gVNIC atualizado, mesmo que o SO convidado mostre a versão do driver gve como 1.0.0.

Se você está usando uma imagem do SO que não tem suporte total a frames jumbo, é possível instalar manualmente o driver da gVNIC versão 1.3.0 ou mais recente. O Google recomenda a instalação da versão do driver da gVNIC marcada como Latest para aproveitar os benefícios de outros recursos e correções de bugs. Faça o download dos drivers gVNIC pelo GitHub.

Para atualizar manualmente a versão do driver da gVNIC no sistema operacional convidado, consulte Usar em sistemas operacionais não compatíveis.

Filas de recebimento e transmissão

Cada vNIC de VM recebe um número de filas de recebimento e transmissão para o processamento de pacotes da rede.

  • Fila de recebimento (RX): fila para receber pacotes. Quando a vNIC recebe um pacote da rede, a vNIC seleciona o descritor de um pacote de entrada da fila, processa e entrega o pacote ao SO convidado por uma fila de pacotes anexada a uma vCPU. usando uma interrupção. Se a fila RX estiver cheia e não houver buffer disponível para colocar um pacote, o pacote será descartado. Isso normalmente pode acontecer se um aplicativo estiver superutilizando um núcleo de vCPU que também está anexado à fila de pacotes selecionada.
  • Fila de transmissão (TX): fila para transmitir pacotes. Quando o SO convidado envia um pacote, um descritor é alocado e colocado na fila do TX. Em seguida, a vNIC processa o descritor e transmite o pacote.

Alocação de fila padrão

A menos que você atribua contagens de fila para NICs explicitamente, é possível modelar o algoritmo que o Google Cloud usa para atribuir um número fixo de filas de RX e TX por vNIC desta maneira:

  1. Use um dos seguintes métodos, dependendo do seu tipo de interface de rede:

    • VirtIO: divida o número de vCPUs pelo número de NICs e descarte um restante —[number of vCPUs/number of NICs].
    • gVNIC: divida o número de vCPUs pelo número de NICs, divida o resultado por 2 e descarte qualquer resto — [number of vCPUs/number of NICs/2].

    Esse cálculo sempre resulta em um número inteiro (não uma fração).

  2. Se o número calculado for menor que 1, atribua uma vNIC a cada fila.

  3. Determine se o número calculado é maior que o número máximo de filas por vNIC. O número máximo de filas por vNIC depende do tipo de driver:

    • Usando virtIO ou um driver personalizado, o número máximo de filas por vNIC é 32. Se o número calculado for maior que 32: ignore o número calculado e atribua 32 filas a cada vNIC.
    • Usando gvNIC, o número máximo de filas por vNIC é 16. Se o número calculado for maior que 16, ignore o número calculado e atribua 16 filas a cada vNIC.

Veja nos exemplos a seguir como calcular o número padrão de filas:

  • Se uma VM usar a VirtIO e tiver 16 vCPUs e 4 NICs, o número calculado será [16/4] = 4. O Google Cloud atribui quatro filas a cada vNIC.

  • Se uma VM usar GVNIC e tiver 128 vCPUs e duas NICs, o número calculado será [128/2/2] = 32. O Google Cloud atribui a cada vNIC o número máximo de filas por vNIC possível. O Google Cloud atribui 16 filas por vNIC.

Em sistemas Linux, use ethtool para configurar uma vNIC com menos filas do que o número de filas que o Google Cloud atribui por vNIC.

Alocação de fila personalizada

Em vez da alocação padrão de filas, é possível atribuir uma contagem de filas personalizada (total de RX e TX) a cada vNIC ao criar uma nova VM usando a API Compute Engine.

O número de filas personalizadas que são especificadas precisa aderir às seguintes regras:

  • A contagem mínima de filas que pode ser atribuída por vNIC é uma;

  • A contagem máxima de filas que pode ser atribuída a cada vNIC é o menor entre a contagem de vCPUs ou a contagem máxima de filas da vNIC, com base no tipo de driver:

    • usando virtIO ou um driver personalizado, a contagem máxima de filas será 32;
    • usando gvNIC, a contagem máxima de filas será 16.

  • Se você atribuir contagens de filas personalizadas a todas as NICs da VM, a soma das atribuições de filas precisará ser menor ou igual ao número de vCPUs atribuídas à instância de VM.

É possível que haja excesso de inscrições na contagem de filas personalizadas das placas de rede (NIC, na sigla em inglês). Em outras palavras, é possível ter uma soma das contagens de filas atribuídas a todas as NICs da VM que seja maior do que o número de vCPUs da VM. Para fazer mais inscrições na contagem de filas personalizada, é preciso atender às seguintes condições:

  • Use a gVNIC como o tipo de vNIC para todas as NICs configuradas para a VM.
  • A VM usa um tipo de máquina das séries N2, N2D, C2 e C2D.
  • Você ativou a rede Tier_1 para a VM.
  • Você especificou uma contagem de fila personalizada para todas as NICs configuradas para a VM.

Com a assinatura em excesso de fila, a contagem máxima de filas da VM é 16 vezes o número de placas de rede. Portanto, se você tiver 6 NICs configuradas para uma VM com 30 vCPUs, será possível configurar no máximo 16 * 6 ou 96 filas personalizadas para sua VM.

Exemplos

  • Se uma VM tiver 8 vCPUs e 3 NICs, a contagem máxima de filas da VM será o número de vCPUs, ou seja, 8. É possível atribuir uma fila a nic0, quatro filas a nic1 e três filas a nic2. Neste exemplo, não é possível atribuir quatro filas posteriormente a nic2 enquanto mantém as outras duas atribuições de filas de vNIC porque a soma das filas atribuídas não pode exceder o número de vCPUs (oito).

  • Se uma VM tiver 96 vCPUs e duas NICs, você poderá atribuir até 32 filas às duas NICs usando o driver virtIO ou até 16 filas usando o driver gvNIC. Neste exemplo, a soma das filas atribuídas é sempre menor que o número de vCPUs.

Também é possível atribuir uma contagem de filas personalizadas para apenas algumas NICs, permitindo que o Google Cloud atribua filas para as NICs restantes. O número de filas que podem ser atribuídas por vNIC ainda está sujeito às regras mencionadas anteriormente. Simule a possibilidade da configuração e, se for possível, o número de filas que o Google Cloud atribui às NICs restantes com este processo:

  1. Calcule a soma das filas das NICs usando a atribuição de filas personalizada. Para uma VM de exemplo com 20 vCPUs e 6 NICs, suponha que você atribua nic0 5 filas, nic1 6 filas, nic2 4 filas e deixe o Google Cloud atribuir filas para nic3, nic4 e nic5. Neste exemplo, a soma das filas personalizadas atribuídas é 5+6+4 = 15.

  2. Subtraia a soma das filas personalizadas atribuídas do número de vCPUs. Se a diferença não for pelo menos igual ao número de NICs restantes a que o Google Cloud precisa atribuir filas, o Google Cloud retornará um erro. Continuando com o exemplo de VM de 20 vCPUs e uma soma de filas personalizadas atribuídas 15, o Google Cloud tem filas 20-15 = 5 restantes para atribuir às outras NICs (nic3, nic4 e nic5).

  3. Divida a diferença da etapa anterior pelo número de NICs restantes e descarte qualquer sobra: ⌊(number of vCPUs - sum of assigned queues)/(number of remaining NICs)⌋. Este cálculo sempre resulta em um número inteiro (não uma fração) que é pelo menos igual a um por causa da restrição explicada na etapa anterior. O Google Cloud atribui a cada NIC restante uma contagem de filas correspondente ao número calculado, desde que o número calculado não seja maior que o número máximo de filas por vNIC. O número máximo de filas por vNIC depende do tipo de driver:

    • Usando virtIO ou um driver personalizado se o número calculado de filas para cada vNIC restante for maior que 32, o Google Cloud atribui 32 filas a cada vNIC restante.
    • Usando gVNIC, se o número calculado de filas para cada NIC restante for maior que 16, o Google Cloud atribuirá 16 filas a cada vNIC.

Configurar contagens de filas personalizadas

Para criar uma VM que usa uma contagem de fila personalizada para uma ou mais vNICs, conclua as etapas a seguir.

gcloud

  1. Se você ainda não tiver uma rede VPC com uma sub-rede para cada interface vNIC que planeja configurar, crie-a.
  2. Use o comando gcloud compute instances create para criar a VM. Repita a sinalização --network-interface para cada vNIC que você quiser configurar para a VM e inclua a opção queue-count.
    gcloud compute instances create VM_NAME \
        --zone=ZONE \
        --machine-type=MACHINE_TYPE \
        --network-performance-configs=total-egress-bandwidth-tier=TIER_1  \
        --network-interface=network=NETWORK_NAME_1,subnet=SUBNET_1,nic-type=GVNIC,queue-count=QUEUE_SIZE_1 \
        --network-interface=network=NETWORK_NAME_2,subnet=SUBNET_2,nic-type=GVNIC,queue-count=QUEUE_SIZE_2

Substitua:

  • VM_NAME: um nome para a nova VM.
  • ZONE: a zona em que a VM será criada
  • MACHINE_TYPE: o tipo de máquina da VM O tipo de máquina especificado precisa ser compatível com as redes gVNIC e Nível_1.
  • NETWORK_NAME: o nome da rede criada anteriormente.
  • SUBNET_*: o nome de uma das sub-redes criadas anteriormente.
  • QUEUE_SIZE: o número de filas da vNIC, sujeito às regras discutidas em Alocação de fila personalizada.

Terraform

  1. Se você ainda não tiver uma rede VPC com uma sub-rede para cada interface vNIC que planeja configurar, crie-a.

  2. Crie uma VM com contagens de fila específicas para vNICs usando o recurso google_compute_instance. Repita o parâmetro --network-interface para cada vNIC que você quer configurar para a VM e inclua o parâmetro queue-count.

    # Queue oversubscription instance
resource "google_compute_instance" "VM_NAME" {
project      = "PROJECT_ID"
boot_disk {
  auto_delete = true
  device_name = "DEVICE_NAME"
  initialize_params {
     image="IMAGE_NAME"
     size = DISK_SIZE
     type = "DISK_TYPE"
  }
}
machine_type = "MACHINE_TYPE"
name         = "VM_NAME"
zone = "ZONE"

network_performance_config {
    total_egress_bandwidth_tier = "TIER_1"
}

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_1
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_1"
 }

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_2
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_2"
}

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_3
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_3""
}

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_4
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_4""
}

}

Substitua:

  • VM_NAME: um nome para a nova VM.
  • PROJECT_ID: ID do projeto em que a VM será criada. A menos que você esteja usando uma rede VPC compartilhada, o projeto especificado precisa ser o mesmo em que todas as sub-redes e redes foram criadas.
  • DEVICE_NAME: o nome a ser associado ao disco de inicialização no SO convidado.
  • IMAGE_NAME: o nome de uma imagem, por exemplo, "projects/debian-cloud/global/images/debian-11-bullseye-v20231010".
  • DISK_SIZE: o tamanho do disco de inicialização, em GiB
  • DISK_TYPE: o tipo de disco a ser usado para o disco de inicialização, por exemplo, pd-standard.
  • MACHINE_TYPE: o tipo de máquina da VM O tipo de máquina especificado precisa ser compatível com as redes gVNIC e Nível_1.
  • ZONE: a zona em que a VM será criada
  • QUEUE_COUNT: o número de filas da vNIC, sujeito às regras discutidas em Alocação de fila personalizada.
  • SUBNET_*: o nome da sub-rede a que a interface de rede se conecta

REST

  1. Se você ainda não tiver uma rede VPC com uma sub-rede para cada interface vNIC que planeja configurar, crie-a.

  2. Crie uma VM com contagens de fila específicas para NICs usando o método instances.insert. Repita a propriedade networkInterfaces para configurar várias interfaces de rede.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances
{
"name": "VM_NAME",
"machineType": "machineTypes/MACHINE_TYPE",
"networkPerformanceConfig": {
    "totalEgressBandwidthTier": TIER_1
},
"networkInterfaces": [
    {
      "nicType": gVNIC,
      "subnetwork":"regions/region/subnetworks/SUBNET_1",
      "queueCount": "QUEUE_COUNT_1"
    } ],
"networkInterfaces": [
    {
      "nicType": gVNIC,
      "subnetwork":"regions/region/subnetworks/SUBNET_2",
      "queueCount": "QUEUE_COUNT_2"
    } ],
}

    Substitua:

    • PROJECT_ID: ID do projeto em que a VM será criada
    • ZONE: zona em que a VM será criada
    • VM_NAME: nome da nova VM;
    • MACHINE_TYPE: tipo de máquina, predefinida ou personalizada, para a nova VM
    • SUBNET_*: o nome da sub-rede a que a interface de rede se conecta
    • QUEUE_COUNT: número de filas da vNIC, sujeito às regras discutidas em Alocação de fila personalizada.

Alocações de fila e alteração do tipo de máquina

As VMs são criadas com uma alocação de fila padrão ou é possível atribuir uma contagem de filas personalizada a cada placa de interface de rede virtual (vNIC) ao criar uma nova VM usando a API Compute Engine. As atribuições de fila de vNIC padrão ou personalizadas são definidas apenas ao criar uma VM. Se sua VM tiver vNICs que usam contagens de fila padrão, altere o tipo de máquina. Se o tipo de máquina para o qual você está mudando tiver um número diferente de vCPUs, as contagens de fila padrão da VM serão recalculadas com base no novo tipo de máquina.

Se a VM tiver vNICs que usam contagens de filas personalizadas e não padrão, é possível alterar o tipo de máquina usando a CLI do Google Cloud ou a API Compute Engine para atualizar as propriedades da instância A conversão será bem-sucedida se a VM resultante for compatível com a mesma contagem de filas por vNIC da VM original. Para VMs que usam a interface VirtIO-Net e uma contagem de filas personalizada maior que 16 por vNIC, não é possível alterar o tipo de máquina para um tipo de máquina de terceira geração que usa apenas gVNIC. Em vez disso, é possível migrar sua VM para um tipo de máquina de terceira geração seguindo as instruções em Migrar sua carga de trabalho de uma VM existente para uma nova VM.

A seguir