Cotas e limites

Neste documento, listamos as cotas e limites que se aplicam ao Cloud Load Balancing.

Para alterar uma cota, consulte Como solicitar cota adicional.

Uma cota restringe quanto de um determinado recurso compartilhado do Google Cloud o projeto do Cloud pode usar, incluindo hardware, software e componentes de rede.

As cotas fazem parte de um sistema que:

  • monitora o uso ou o consumo de produtos e serviços do Google Cloud;
  • restringe o consumo desses recursos por motivos que incluem garantir a equidade e a redução dos picos de uso;
  • mantém as configurações que aplicam automaticamente restrições prescritas;
  • fornece maneiras de fazer ou solicitar alterações na cota.

Quando uma cota é excedida, na maioria dos casos, o sistema bloqueia imediatamente o acesso ao respectivo recurso do Google, e a tarefa que você está tentando executar falha. Na maioria dos casos, as cotas se aplicam a todos os projetos do Cloud. Além disso, elas são compartilhadas entre todos os aplicativos e endereços IP que usam esse projeto.

Também há limites nos recursos do Cloud Load Balancing. Esses limites não estão relacionados ao sistema de cotas. Não é possível mudar os limites, a menos que seja indicado de outra forma.

Regras de encaminhamento

Item Cotas e limites Observações
Regras de encaminhamento Cota

Essa cota é válida para regras de encaminhamento de balanceadores de carga HTTP(S) externos (clássico) globais, balanceadores de carga de proxy SSL externos, balanceadores de carga de proxy TCP externos e gateways de VPN clássica.

Para outros casos de uso da regra de encaminhamento além desses, consulte as linhas a seguir.

Regras de encaminhamento do balanceador de carga HTTP(S) externo global Cota

O número máximo de regras de encaminhamento do balanceador de carga HTTP(S) externo global que podem ser criadas no projeto.

Nome da cota: GLOBAL_EXTERNAL_MANAGED_FORWARDING_RULES

Regras de encaminhamento do balanceador de carga HTTP(S) externo regional Cota

O número máximo de regras de encaminhamento do balanceador de carga HTTP(S) externo regional que é possível criar em cada região no seu projeto.

Nome da cota: EXTERNAL_MANAGED_FORWARDING_RULES

Regras de encaminhamento de balanceamento de carga de rede TCP/UDP externo Cota Regras de encaminhamento para uso por balanceadores de carga de rede TCP/UDP externos (ambos arquiteturas de pool de destino e serviço de back-end).
Regras de encaminhamento de protocolo externo Cota Regras de encaminhamento para encaminhamento de protocolo externo para instâncias de destino.
Regras de encaminhamento do Traffic Director Cota Regras de encaminhamento para o Traffic Director.
Regras de encaminhamento de balanceamento de carga TCP/UDP interno por rede VPC Cota

O número máximo de regras de encaminhamento para balanceamento de carga TCP/UDP interno.

Essa cota se aplica ao número total de regras de encaminhamento para balanceamento de carga interno de TCP/UDP. Ele não se aplica a cada região individualmente.

Nome da cota:
INTERNAL_FORWARDING_RULES_PER_NETWORK

Para mais informações, consulte Cotas VPC por rede.

Regras de encaminhamento para encaminhamento de protocolo interno Cota

O número máximo de regras de encaminhamento para o encaminhamento de protocolos interno.

Esse limite se aplica ao número total de regras de encaminhamento para o encaminhamento de protocolos interno. Ele não se aplica a cada região individualmente.

Nome da cota:
INTERNAL_FORWARDING_RULES_WITH_TARGET_INSTANCE_PER_NETWORK

Para mais informações, consulte Cotas VPC por rede.

Regras de encaminhamento por rede VPC para balanceadores de carga HTTP(S) internos e balanceadores de carga de proxy TCP regional internos Cota

O número máximo de regras de encaminhamento para balanceadores de carga HTTP(S) internos e balanceadores de carga de proxy TCP regional internos

Essa cota se aplica ao número total de regras de regras de encaminhamento para balanceadores de carga HTTP(S) internos e balanceadores de carga de proxy TCP regional internos. Ela não se aplica a cada região individualmente.

Nome da cota:
INTERNAL_MANAGED_FORWARDING_RULES_PER_NETWORK

Para mais informações, consulte Cotas VPC por rede.

Número máximo de regras de encaminhamento interno que podem compartilhar um único endereço IP interno 10 Esse limite só é aplicável a balanceadores de carga TCP/UDP internos. Esse limite não pode ser aumentado.
Número de portas discretas por regra de encaminhamento para balanceadores de carga TCP/UDP internos e balanceadores de carga de rede baseados em serviço de back-end 5

Não é possível aumentar esse limite. No entanto, são possíveis opções alternativas de especificação de porta:

  • É possível especificar um único intervalo de portas contíguas nas regras de encaminhamento para balanceadores de carga de rede baseados em serviço de back-end e balanceadores de carga de rede baseados em pool de destino. O intervalo pode incluir mais de cinco portas.
  • É possível especificar todas as portas em regras de encaminhamento para balanceadores de carga de rede baseados em serviço de back-end e balanceadores de carga TCP/UDP internos.
Número de regras de encaminhamento que podem referenciar o mesmo serviço de back-end para um balanceador de carga de passagem Nenhum limite separado. Sujeito a outras cotas e limites, várias regras de encaminhamento podem fazer referência ao mesmo serviço de back-end para um balanceador de carga de passagem.
Número de serviços de back-end de balanceador de carga que podem ser referenciados por uma única regra de encaminhamento 1 As regras de encaminhamento para balanceadores de carga de passagem precisam referenciar exatamente um serviço de back-end.

Pools e proxies de destino

Item Cotas e limites Observações
Pools de destino Cota Essa cota é por projeto.
Proxies HTTP de destino Cota Essa cota é por projeto.
Proxies HTTPS de destino Cota Essa cota é por projeto.
Proxies SSL de destino Cota Essa cota é por projeto.
Proxies TCP de destino Cota Essa cota é por projeto.
Políticas de SSL por HTTPS ou proxy SSL de destino 1 Esse limite não pode ser aumentado.
Certificados SSL por HTTPS ou proxy SSL de destino 15 Esse limite não pode ser aumentado.

Verificações de integridade

Item Cotas e limites Observações
Verificações de integridade Cota É uma cota por projeto que abrange todos os tipos de verificação de integridade (global, regional e legada).

Certificados SSL

Item Cotas e limites Observações
Certificados SSL Cota Essa cota é por projeto.
Comprimentos compatíveis de chaves privadas RSA de 2.048 bits (RSA-2048)
ECDSA de 256 bits (ECDSA P-256)
Não é possível aumentar esses limites.
Vários domínios por certificado SSL gerenciado pelo Google 100 Esse limite não pode ser aumentado.
Comprimento do nome de domínio dos certificados gerenciados pelo Google 64 bytes Esse limite não pode ser aumentado.

Ele se aplica apenas aos certificados SSL gerenciados pelo Google. Neles, o limite de 64 bytes vale somente para o primeiro domínio . O limite de comprimento dos outros domínios do certificado é de 253 bytes. Esse valor é o padrão dos nomes de domínios na Internet e não é específico dos certificados gerenciados pelo Google.

Mapas de URL

Os limites documentados aqui não podem ser aumentados.

Item Balanceamento de carga HTTP(S) externo Balanceamento de carga HTTP(S) interno
Mapas de URL Cota

Essa cota é por projeto.

Cota

Essa cota é por projeto.

Regras de host, correspondências de caminho por mapa de URL Limite: 1000 Limite: 2000
Regras de caminho ou regras de rota por correspondência de caminho Limite: 1000 Limite: 200
Hosts por regra de host Limite: 1000 Limite: 1000
Predicados por correspondência de caminho Limite: 1000 Limite: 1000
Número de serviços ou buckets de back-end distintos referenciados pelo mapa de URL Limite: 2500 Limite: 2500
Tamanho dos mapas de URLs Limite: 64 KB Limite: 128 KB
Número de testes de mapa de URLs Limite: 10000 N/A

O balanceamento de carga de HTTP(S) interno não é compatível com testes de mapa de URL.

Esse é um limite na contagem de condições de correspondência em todas as regras na correspondência de caminho. Para correspondências de caminho com regras de caminho, esse é o número total de caminhos em todas as regras. Para correspondências de caminho com regras de rota, a contagem de prefixos é calculada adicionando:

  • Um para a condição de correspondência de caminho (um de prefixMatch ou fullPathMatch);
  • a soma das correspondências do cabeçalho em todas as regras de rota da correspondência de caminho;
  • a soma das correspondências do parâmetro de consulta em todas as regras de rota da correspondência de caminho.

Por exemplo, para uma correspondência de caminho com as seguintes regras de rota:

  • a regra de rota A tem uma correspondência de prefixo e três correspondências de cabeçalho;
  • a regra de rota B tem uma correspondência de fullPathMatch e duas de parâmetros de consulta.

A contagem total de predicados para essa correspondência de caminho seria 7. Isso é calculado da seguinte forma: 1 (para o prefixMatch) + 3 (para o número de correspondências de cabeçalho) + 1 (para o fullPathMatch) + 2 (para o número de correspondências de parâmetros de consulta).

Buckets de back-end

Item Cotas e limites Observações
buckets de back-end Cota Essa cota é por projeto.

Serviços de back-end

Item Cotas e limites Observações
Serviços de back-end Cota Essa cota inclui todos os serviços de back-end (INTERNAL, INTERNAL_MANAGED, INTERNAL_SELF_MANAGED, EXTERNAL e EXTERNAL_MANAGED) no seu projeto.
Serviços de back-end por balanceador de carga de proxy TCP externo, balanceador de carga de proxy SSL externo, balanceador de carga TCP/UDP interno e balanceador de carga de rede baseado em serviço de back-end. 1 Esse limite não pode ser aumentado.
Número máximo de instâncias de VM para o serviço de back-end de um balanceador de carga TCP/UDP interno

Esse valor máximo se aplica ao número total de instâncias no pool ativo se você tiver failover configurado.

Sem subconfiguração de back-end: 250

Com a subconfiguração de back-end ativada: 2000

Não é possível aumentar esses limites.
Elas são aplicadas independentemente da maneira como as instâncias são agrupadas em grupos de instâncias ou GCE_VM_IP NEGs. Por exemplo, se você adicionar cinco grupos de instâncias, cada um com 60 instâncias de VM, ao mesmo serviço de back-end do balanceador de carga TCP/UDP interno, o balanceador de carga só distribuirá pacotes para 250 das 300 instâncias (5 × 60) quando a subconfiguração do back-end está desativada.

Portas nomeadas por serviço de back-end de um balanceador de carga de proxy 1 Esse limite não pode ser aumentado.
Portas nomeadas por serviço de back-end de um balanceador de carga de passagem 0 Esse limite não pode ser aumentado. O campo portName no serviço de back-end é ignorado para balanceadores de carga de passagem.

Back-ends

Item Cotas e limites Observações
Grupos de instâncias Cota Essa cota é por projeto.
NEGs por projeto Cota Essa cota é por projeto.
Número máximo de back-ends de grupos de instâncias, GCE_VM_IP_PORT back-ends NEG ou GCE_VM_IP back-ends NEG por serviço de back-end 50

Esse limite não é configurável.

O suporte para back-ends de NEG GCE_VM_IP_PORT e GCE_VM_IP varia de acordo com o produto de balanceamento de carga.

Se você tiver configurado o failover para balanceadores de carga de rede baseados em serviço de back-end, ou se tiver configurado o failover para balanceadores de carga TCP/UDP internos, é possível configurar até 50 grupos de instâncias de backup ou principais ou 50 NEGs GCE_VM_IP por serviço de back-end.

Os balanceadores de carga TCP/UDP internos também têm um limite para o número de instâncias de VM individuais ou endpoints em que um serviço de back-end pode distribuir pacotes. Para detalhes, consulte cotas de serviços de back-end.

Endpoints por NEG

Item Cotas e limites Observações
Endpoints por GCE_VM_IP_PORT NEG zonal 10.000 Esse limite não pode ser aumentado.
Endpoints por GCE_VM_IP NEG zonal 10.000 Esse limite não pode ser aumentado.
Endpoints por NEG da Internet 1 Esse limite não pode ser aumentado.
Endpoints por NEG sem servidor 1 Esse limite não pode ser aumentado.
Endpoints por NEG de conectividade híbrida 10.000 Esse limite não pode ser aumentado.

VMs por grupo de instâncias

É possível que o número de VMs de back-end que podem ser atendidas por um único balanceador de carga seja menor do que o número de VMs compatíveis com um grupo de instância. O número máximo de VMs com balanceamento de carga por grupo de instâncias depende do número de portas especificado em cada porta nomeada que o grupo de instâncias exporta.

O limite máximo de VMs com carga balanceada por grupo de instâncias não pode exceder 2.000 para grupos de instâncias gerenciadas por região e não pode exceder 1.000 para grupos de instâncias gerenciadas por zona ou não gerenciadas.

Item Cotas e limites Notas
Número máximo de VMs por grupo gerenciado de instâncias regionais conectado ao serviço de back-end de um balanceador de carga de passagem 2.000 Os balanceadores de carga TCP/UDP internos também têm um limite para o número de instâncias de VM individuais ou endpoints em que um serviço de back-end pode distribuir pacotes. Para detalhes, consulte cotas de serviços de back-end.
Número máximo de VMs por grupo de instâncias gerenciadas por zona ou por grupo de instâncias não gerenciadas por zona conectado a um serviço de back-end de balanceador de carga 1.000 Os balanceadores de carga TCP/UDP internos também têm um limite para o número de instâncias de VM individuais ou endpoints em que um serviço de back-end pode distribuir pacotes. Para detalhes, consulte cotas de serviços de back-end.
Número máximo de VMs por grupo gerenciado de instâncias regionais conectado ao serviço de back-end de um balanceador de carga de proxy Depende do número de portas especificado na porta nomeada do grupo de instâncias. É a opção que for menor:
A: 2.000
B: 10.000/(número de portas na porta nomeada que contém a maioria do número de portas)
Entre em contato com a equipe de vendas do Google Cloud se precisar aumentar esse limite.
Número máximo de VMs por grupo de instâncias gerenciadas por zona ou por grupo de instâncias não gerenciadas por zona conectado ao serviço de back-end de um balanceador de carga de proxy Depende do número de portas especificado na porta nomeada do grupo de instâncias. É a opção que for menor:
A: 1.000
B: 10.000/(número de portas na porta nomeada que contém a maioria do número de portas)
Entre em contato com a equipe de vendas do Google Cloud se precisar aumentar esse limite.

Para calcular o número máximo de VMs com carga balanceada em um back-end de grupo de instâncias:

  1. Determine o número máximo de portas por porta nomeada.

    Por exemplo, se um grupo de instâncias tiver as seguintes portas nomeadas: http:80, api-gateway:8080 e api-gateway:8090, haverá um número de porta para o nome http e dois números de porta para o nome api-gateway. Portanto, neste exemplo, o número máximo de portas por porta nomeada é duas.

  2. Divida 10.000 pelo número máximo de portas por porta nomeada e descarte o restante. Por exemplo, 10,000 / 2 = 5,000

  3. Compare o número calculado na etapa anterior com o limite máximo das VMs com carga balanceada por grupo de instâncias: 2.000 para grupos regionais, 1.000 para grupos zonais.

    Se o número calculado na etapa anterior for menor ou igual ao limite máximo, o número máximo de VMs com balanceamento de carga por grupo de instâncias será o número calculado na etapa anterior. Caso contrário, o número máximo de VMs com carga balanceada por grupo de instâncias será o limite superior (2.000 para grupos regionais ou 1.000 para grupos zonais).

Consultas por segundo para balanceamento de carga HTTP(S)

Item Cotas e limites Observações
Consultas por segundo (QPS) por grupo de instâncias de back-end ou NEG para balanceamento de carga HTTP(S) externo Configurável ao usar RATE para o modo de balanceamento. Seus back-ends definem um limite.
Consultas por segundo (QPS) em cada região e rede para balanceamento de carga HTTP(S) interno Para o balanceamento de carga HTTP(S) interno, a carga máxima de QPS depende do tamanho das solicitações e da complexidade da configuração. Se a carga exceder a capacidade, a latência aumentará e as solicitações poderão ser descartadas. Entre em contato com a equipe de vendas do Google Cloud se precisar aumentar o limite.

Tamanho do cabeçalho para balanceamento de carga HTTP(S)

Item Cotas e limites Observações
Tamanho máximo do cabeçalho da solicitação do cliente para balanceamento de carga HTTP(S) externo 60 KB (kilobytes) Esse limite não pode ser aumentado.
O tamanho combinado do URL e do cabeçalho da solicitação precisa ser menor ou igual a 64 KB.
Tamanho máximo do cabeçalho de resposta do back-end para balanceamento de carga HTTP(S) externo 128 KB (kilobytes) Esse limite não pode ser aumentado.
Tamanho máximo do cabeçalho da solicitação do back-end para balanceamento de carga HTTP(S) interno 60 KB (kilobytes) Esse limite não pode ser aumentado.
Conversão de cabeçalhos de solicitação e resposta HTTP em letras minúsculas Sempre, exceto para o balanceador de carga HTTP(S) externo global (clássico) ao usar HTTP/1.1 Como exemplo, Host é convertido em host e Keep-ALIVE em keep-alive.
Número máximo de cabeçalhos de solicitação personalizados e configurados para cada serviço de back-end 16 Esse limite não pode ser aumentado.
Número máximo de cabeçalhos de resposta personalizados e configurados para cada serviço de back-end 16 Esse limite não pode ser aumentado.
Tamanho total de todos os cabeçalhos de solicitação personalizados por serviço de back-end (nome e valor combinados, antes da expansão da variável) 8 KB Esse limite não pode ser aumentado.
Tamanho total de todos os cabeçalhos de resposta personalizados por serviço de back-end (nome e valor combinados, antes da expansão da variável) 8 KB Esse limite não pode ser aumentado.

Como gerenciar cotas

O Cloud Load Balancing aplica cotas no uso de recursos por vários motivos. Por exemplo, as cotas protegem a comunidade de usuários Google Cloud, impedindo picos de uso inesperados. As cotas também ajudam os usuários que estão explorando o Google Cloud com o nível gratuito a permanecer na avaliação.

Todos os projetos começam com as mesmas cotas, que podem ser alteradas com uma solicitação de cota extra. Algumas cotas podem aumentar automaticamente dependendo do uso de um produto.

Permissões

Para ver cotas ou solicitar aumentos de cota, os participantes do Identity and Access Management (IAM) precisam de um dos papéis a seguir.

Tarefa Papel necessário
Verificar cotas para um projeto Pode ser umas destas opções:
Modificar cotas, solicitar cota extra Pode ser umas destas opções:

Como verificar cotas

Console

  1. No Console, acesse a página Cotas.

    Acessar "Cotas"

  2. Para pesquisar a cota a ser atualizada, use a tabela de filtros. Se você não souber o nome da cota, use os links desta página.

gcloud

Com a Google Cloud CLI, execute o comando a seguir para verificar suas cotas. Substitua PROJECT_ID pelo seu código do projeto:

      gcloud compute project-info describe --project PROJECT_ID
    

Para verificar a cota utilizada em uma região, execute o comando a seguir:

      gcloud compute regions describe example-region
    

Erros ao exceder a cota

Se você exceder uma cota com um comando gcloud, o gcloud emitirá uma mensagem de erro quota exceeded e retornará com o código de saída 1.

Se você exceder uma cota com uma solicitação de API, o Google Cloud retornará o seguinte código de status HTTP: HTTP 413 Request Entity Too Large.

Como solicitar cotas extras

Para aumentar ou diminuir a maioria das cotas, use o console do Google Cloud. Para mais informações, consulte Como solicitar uma cota maior

Console

  1. No Console, acesse a página Cotas.

    Acessar "Cotas"

  2. Na página Cotas, selecione as que você quer alterar.
  3. Na parte superior da página, clique em Editar cotas.
  4. Preencha seu nome, e-mail, número de telefone e clique em Próxima.
  5. Preencha sua solicitação de cota, e clique em Concluído.
  6. Envie a solicitação. As solicitações de cota demoram de 24 a 48 horas para serem processadas.

Disponibilidade de recursos

Cada cota representa um número máximo para um tipo específico de recurso que é possível criar, desde que o recurso esteja disponível. É importante observar que as cotas não garantem a disponibilidade de recursos. Mesmo que você tenha cota disponível, não será possível criar um novo recurso se ele não estiver disponível.

Por exemplo, é possível ter cota suficiente para criar um novo endereço IP externo regional na região us-central1. No entanto, isso não é possível se não houver endereços IP externos disponíveis naquela região. A disponibilidade de recursos zonais também pode afetar sua capacidade de criar um novo recurso.

São raras as situações em que os recursos não estão disponíveis em uma região inteira. No entanto, os recursos dentro de uma zona podem ser usados periodicamente, normalmente sem impacto no contrato de nível de serviço (SLA) para o tipo de recurso. Para mais informações, leia o SLA relevante do recurso.