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 |
|
Roteamento fora de uma rede VPC |
|
Entrada
Expectativas de largura de banda | |
---|---|
Roteamento em uma rede VPC |
|
Roteamento 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 |
N4 | 10 Gbps | 50 Gbps |
H3 | N/A | 200 Gbps |
Z3 | 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:
- Família de máquinas de uso geral
- Família de máquinas com otimização de armazenamento
- Família de máquinas com otimização de computação
- Família de máquinas com otimização de memória
- Família de máquinas com otimização de acelerador
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:
- Ative o desempenho de rede por VM de Tier_1 com tipos de máquinas maiores de uso geral e otimizados para computação.
- Use a maior unidade máxima de transmissão (MTU, na sigla em inglês) da rede VPC compatível com sua topologia de rede. MTUs maiores podem reduzir a sobrecarga de cabeçalho de pacote e aumentar a capacidade de dados de payload.
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:
- Taxa máxima de pacotes e largura de banda por túnel do Cloud VPN
- Taxa máxima de pacotes e largura de banda por anexo da VLAN
- Para utilizar plenamente a largura de banda de vários túneis do Cloud VPN de próximo salto ou anexos da VLAN do Cloud Interconnect usando o roteamento ECMP, use várias conexões TCP (cinco tuplas únicas).
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.
- Um endereço IPv6 do intervalo de endereços IPv6
- 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.
- Um endereço IPv6 do intervalo de endereços IPv6
- Outros destinos acessíveis usando as seguintes rotas de rede
VPC:
- Rotas dinâmicas
- Rotas estáticas, exceto aquelas que usam um próximo salto de gateway de Internet padrão
- Rotas personalizadas de peering
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:
- Entre VMs na mesma zona
- Entre VMs em zonas diferentes na mesma região
- Entre VMs em diferentes regiões
- De uma VM para APIs e serviços do Google Cloud usando o Acesso privado do Google ou o acesso às APIs do Google pelo endereço IP externo de uma VM. Isso inclui endpoints do Private Service Connect para APIs do Google.
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âncian2-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 intervalo de endereços IPv6 interno.
- Um intervalo de endereços IPv6 externo quando o pacote de entrada é roteado internamente para a VM de recebimento usando uma das rotas de rede VPC listadas anteriormente nesta seção.
- 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
ounext-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
- 30 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:
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).
- VirtIO: divida o número de vCPUs pelo número de NICs e descarte um restante —
Se o número calculado for menor que 1, atribua uma vNIC a cada fila.
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 que32
: 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 que16
, ignore o número calculado e atribua 16 filas a cada vNIC.
- Usando virtIO ou um
driver personalizado, o número máximo de filas por 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 atribui16
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:
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 anic1
e três filas anic2
. Neste exemplo, não é possível atribuir quatro filas posteriormente anic2
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:
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 paranic3
,nic4
enic5
. Neste exemplo, a soma das filas personalizadas atribuídas é5+6+4 = 15
.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 filas20-15 = 5
restantes para atribuir às outras NICs (nic3
,nic4
enic5
).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 atribui32
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.
- Usando virtIO ou um driver personalizado se o número calculado de filas para cada vNIC restante for
maior que
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
- Se você ainda não tiver uma rede VPC com uma sub-rede para cada interface vNIC que planeja configurar, crie-a.
- 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çãoqueue-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á criadaMACHINE_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
- Se você ainda não tiver uma rede VPC com uma sub-rede para cada interface vNIC que planeja configurar, crie-a.
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âmetroqueue-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 GiBDISK_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á criadaQUEUE_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
- Se você ainda não tiver uma rede VPC com uma sub-rede para cada interface vNIC que planeja configurar, crie-a.
Crie uma VM com contagens de fila específicas para NICs usando o método
instances.insert
. Repita a propriedadenetworkInterfaces
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á criadaZONE
: zona em que a VM será criadaVM_NAME
: nome da nova VM;MACHINE_TYPE
: tipo de máquina, predefinida ou personalizada, para a nova VMSUBNET_*
: o nome da sub-rede a que a interface de rede se conectaQUEUE_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
- Tipos de máquina
- Instâncias de máquina virtual
- Como criar e iniciar uma instância de VM
- Como configurar o desempenho de rede Tier_1 por VM
- Guia de início rápido sobre como usar uma VM do Linux
- Guia de início rápido sobre como usar uma VM do Windows