Quotas e limites
Este documento indica as quotas e os limites do sistema que se aplicam ao Cloud Router.
- As quotas têm valores predefinidos, mas normalmente pode pedir ajustes.
- Os limites do sistema são valores fixos que não podem ser alterados.
Google Cloud usa quotas para ajudar a garantir a equidade e reduzir os picos na utilização e disponibilidade de recursos. Uma quota restringe a quantidade de um Google Cloud recurso que o seu Google Cloud projeto pode usar. As quotas aplicam-se a uma variedade de tipos de recursos, incluindo componentes de hardware, software e rede. Por exemplo, as quotas podem restringir o número de chamadas API para um serviço, o número de balanceadores de carga usados em simultâneo pelo seu projeto ou o número de projetos que pode criar. As quotas protegem a comunidade de Google Cloud utilizadores, impedindo a sobrecarga dos serviços. As quotas também ajudam a gerir os seus próprios Google Cloud recursos.
O sistema de quotas da nuvem faz o seguinte:
- Monitoriza o seu consumo de Google Cloud produtos e serviços
- Restringe o seu consumo desses recursos
- Oferece uma forma de pedir alterações ao valor da quota e automatizar os ajustes de quotas
Na maioria dos casos, quando tenta consumir mais de um recurso do que a respetiva quota permite, o sistema bloqueia o acesso ao recurso e a tarefa que está a tentar realizar falha.
Geralmente, as quotas aplicam-se ao nível do Google Cloud projeto A sua utilização de um recurso num projeto não afeta a sua quota disponível noutro projeto. Num Google Cloud projeto, as quotas são partilhadas por todas as aplicações e endereços IP.
Para mais informações, consulte a vista geral das quotas da nuvem.Também existem limites do sistema nos recursos do Cloud Router. Não é possível alterar os limites do sistema.
Quotas
Para alterar uma quota, consulte o artigo Peça quota adicional.
Esta tabela abrange as quotas importantes por projeto. Para outras quotas, consulte a página Google Cloud Quotas e limites do sistema da consola.
| Item | Quota | Notas |
|---|---|---|
| Cloud Routers por projeto | Quota | Independentemente da quota, cada rede está limitada a cinco routers na nuvem por região. Consulte os limites. |
|
Prefixos de rotas dinâmicas do Cloud Router exclusivos da própria região por região por rede de VPC O número máximo de prefixos de destino únicos garantidos para rotas aprendidas a aplicar a sub-redes numa determinada região por todos os routers na nuvem na mesma região. Isto é designado por quota da própria região de uma região. |
Quota |
Os prefixos IPv4 e IPv6 são contabilizados para esta quota. Todos os encaminhamentos aprendidos contam para esta quota, incluindo encaminhamentos aprendidos personalizados e encaminhamentos recebidos do BGP. Os trajetos são agrupados por destinos únicos. Os trajetos com destinos idênticos, mas diferentes saltos seguintes, só contam como um único destino. Os trajetos com destinos idênticos e saltos seguintes idênticos também só contam como um único destino. Para redes no modo de encaminhamento dinâmico global, é possível atingir uma das quotas de prefixos de rotas dinâmicas únicas sem atingir a outra. Se qualquer uma das quotas tiver sido excedida, pode ter problemas de conetividade intermitentes quando as rotas são ignoradas. Para ver detalhes, consulte o exemplo de rota aprendida. Para mais informações acerca destas quotas, incluindo as métricas que pode usar para compreender a sua utilização atual, consulte o artigo Resolva problemas de rotas BGP e seleção de rotas. |
|
Só se aplica a redes VPC no modo de encaminhamento dinâmico global. Prefixos de rotas dinâmicas do Cloud Router exclusivos de outras regiões por região por rede VPC O número máximo de destinos únicos garantidos para rotas aprendidas que podem ser aplicados a sub-redes numa determinada região por routers da nuvem de diferentes regiões. Isto é designado quota de outras regiões de uma região. |
Quota |
Os prefixos IPv4 e IPv6 são contabilizados para esta quota. Todos os encaminhamentos aprendidos contam para esta quota, incluindo encaminhamentos aprendidos personalizados e encaminhamentos recebidos do BGP. Os trajetos são agrupados por destinos únicos. Os trajetos com destinos idênticos, mas diferentes saltos seguintes, só contam como um único destino. Os trajetos com destinos idênticos e saltos seguintes idênticos também só contam como um único destino. Para redes no modo de encaminhamento dinâmico global, é possível atingir uma das quotas de prefixos de rotas dinâmicas únicas sem atingir a outra. Se qualquer uma das quotas tiver sido atingida, pode ter problemas de conetividade intermitentes quando as rotas são ignoradas. Para ver detalhes, consulte o exemplo de rota aprendida. Para mais informações acerca destas quotas, incluindo as métricas que pode usar para compreender a sua utilização atual, consulte o artigo Resolva problemas de rotas BGP e seleção de rotas. |
Limites
Os seguintes limites do Cloud Router aplicam-se às redes da nuvem virtual privada (VPC). Salvo indicação em contrário, não é possível aumentar estes limites.
| Item | Limite | Notas |
|---|---|---|
| Número máximo de Cloud Routers por combinação de rede VPC e região | 5 | Se tiver quota suficiente para o projeto, pode criar até cinco routers na nuvem numa determinada VPC e região. |
| Número máximo de pares BGP para cada Cloud Router numa determinada rede VPC e região | 128 | O par BGP pode ser qualquer uma das seguintes opções:
|
| Número máximo de prefixos que o Cloud Router aceita de um único par BGP | 5000 | Se um par BGP anunciar mais de 5000 prefixos, o Cloud Router repõe a sessão BGP. |
| Número máximo de termos de todas as políticas de rotas BGP aplicadas num único par BGP ou direção | 1000 | Este limite não é dividido entre recursos, mas sim combinado. Não existe um limite para o tamanho de uma única expressão de correspondência ou ação, o número de ações num termo, o número de termos numa única política ou o número de políticas. |
| Para um determinado Cloud Router, o número máximo de anúncios de rota de sub-rede por sessão de BGP | Sem restrições | Os Cloud Routers não têm um limite para o número de rotas de sub-rede que podem anunciar. O número de rotas de sub-rede é determinado pelo número de sub-redes, que são controladas pelas quotas e pelos limites da rede VPC. |
| Para um determinado Cloud Router, o número máximo de rotas anunciadas personalizadas por sessão BGP | 200 | Se as rotas anunciadas personalizadas forem idênticas para todas as sessões BGP num Cloud Router, este limite representa o número total de rotas anunciadas personalizadas IPv4 e IPv6 únicas para o Cloud Router. Neste caso, cada sessão recebe o mesmo conjunto de rotas anunciadas personalizadas. |
| Para um determinado Cloud Router, o tamanho máximo combinado de todos os literais de expressões de correspondência e ação usados nas políticas de rotas BGP quando codificados como UTF-8. | Limite de 250 KiB | Para um determinado Cloud Router, este limite não é dividido por recursos, mas combinado. Não existe um limite para o tamanho de uma única correspondência ou expressão de ação, o número de ações num termo, o número de termos numa única política de encaminhamento BGP ou o número de políticas de encaminhamento BGP. |
Consultas máximas por minuto para chamadas list-bgp-routes num único Cloud Router |
1500 | Esta quota é de compute.googleapis.com/list_requests_per_region.
Para mais informações, consulte o artigo
Quotas de taxa. |
| Número máximo de políticas de rotas BGP por Cloud Router. | 500 | |
| Para uma determinada sessão de BGP, o número máximo de rotas aprendidas personalizadas | 10 |
Para mais informações sobre esta funcionalidade, consulte o artigo Trajetos personalizados. |
Para uma determinada região numa rede VPC, o número máximo de prefixos IP exclusivos que podem ser configurados como rotas aprendidas personalizadas. Este limite permite que os mesmos intervalos sejam usados em vários pares |
10 |
Para mais informações sobre esta funcionalidade, consulte o artigo Trajetos personalizados. |
Exemplo de trajeto memorizado
Os exemplos seguintes ilustram o comportamento de abandono de trajetos que pode encontrar quando a quota from-own-region ou a quota from-other-regions é excedida.
Suponhamos que tem routers na região us-east1 e routers na região us-west1 na mesma rede VPC e que o encaminhamento dinâmico global está ativado. Cada Cloud Router em cada região aprende 250 destinos únicos. Para fins ilustrativos deste exemplo, cada Cloud Router em cada região não aprende nenhum dos mesmos destinos.
Independentemente de quais os Cloud Routers que aprendem as rotas em cada região, a quota from-own-region de cada região é esgotada porque os Cloud Routers em cada região aprendem 250 de 250 destinos únicos. As quotas de outras regiões para ambas as regiões também estão esgotadas porque cada Cloud Router importa 250 destinos únicos da outra região. Se a rede VPC de exemplo usasse o encaminhamento dinâmico regional, as quotas de outras regiões em cada região não se aplicariam porque o modo de encaminhamento dinâmico regional indica à rede VPC que só crie rotas dinâmicas na região que corresponda ao próximo salto da rota.
Exceder a quota de origem da região
Suponhamos que o seu router no local ligado a um Cloud Router em
us-west1 anuncia um 251.º destino. Os routers na nuvem na região us-west1 escolhem 250 dos 251 destinos únicos seguindo uma ordem de rota determinística.
Estes routers enviam esses 250 destinos únicos para a rede VPC, criando 250 rotas dinâmicas na região us-west1.
Uma vez que a rede VPC usa o modo de encaminhamento dinâmico global, também não cria mais de 250 rotas dinâmicas em todas as outras regiões, sujeitas à quota de destino único de outras regiões de cada uma das outras regiões. A secção seguinte descreve o que acontece noutras regiões mais detalhadamente.
Exceder a quota de uma região de outras regiões
Quando os routers na nuvem aprendem 251 destinos únicos na região us-west1, 250 dos 251 destinos únicos de us-west1 ficam disponíveis para os recursos na região us-east1, porque a quota de outras regiões da região us-east1 só pode aceitar 250 destinos únicos.
Suponha que cria um Cloud Router numa terceira região,
us-central1, na mesma rede VPC. Suponhamos que o Cloud Router aprende 10 destinos únicos do respetivo par BGP. Embora a quota da região us-central1 de origem na própria região não tenha sido excedida, a quota da região us-central1 de origem noutras regiões foi excedida porque as outras duas regiões fornecem um total de 500 destinos únicos (250 da região us-east1 e 250 diferentes da região us-west1).
Com base nas regiões, a ordem determinística do trajeto seleciona trajetos para um máximo de 250 destinos únicos noutras regiões, conforme indicado na tabela seguinte.
| Região |
Destinos únicos locais da região (utilização da quota da região de origem) |
Destinos únicos de outras regiões (utilização da quota de regiões de outras regiões) |
|---|---|---|
| us-west1 |
251 recebidos. 250 dos 251 são selecionados e um dos 251 é ignorado pela
ordem de rota determinística. São criadas 250 rotas dinâmicas com saltos seguintes em
Os 250 prefixos selecionados são partilhados com outras regiões. |
260 recebidos (250 de São criadas 250 rotas dinâmicas com saltos seguintes fora de |
| us-east1 |
250 recebidos. Todos os 250 estão selecionados pela ordem do caminho determinístico. 250
rotas dinâmicas com saltos seguintes em Todos os 250 prefixos selecionados são partilhados com outras regiões. |
260 recebidos (250 de São criadas 250 rotas dinâmicas com saltos seguintes fora de |
| us-central1 |
10 recebidos. Todos os 10 estão selecionados pela ordem de rota determinística. 10
As rotas dinâmicas com saltos seguintes em Todos os 10 prefixos selecionados são partilhados com outras regiões. |
500 recebidos (250 de São criadas 250 rotas dinâmicas com saltos seguintes fora de |
Embora a quota de us-central1 de outras regiões seja excedida, a quota da própria região pode aceitar destinos cujos saltos seguintes estejam na região us-central1.
Comportamento determinístico de eliminação de trajetos
O Cloud Router implementa um comportamento de eliminação de rotas determinístico com base no comprimento da máscara de sub-rede e nas caraterísticas lexicográficas de cada prefixo recebido. Em cada região, o seguinte processo aplica-se independentemente à lista de destinos da própria região e à lista de destinos únicos de outras regiões:
A lista é ordenada primeiro do comprimento da máscara de sub-rede mais curto para o mais longo e, em seguida, por ordem lexicográfica. Por exemplo,
10.0.0.0/8vem antes de10.2.1.0/24, que vem antes de10.99.1.0/24.As primeiras 250 entradas da lista são preservadas. Todos os outros são rejeitados.
Conforme mostrado no exemplo de exceder a quota de uma região de outras regiões, o comportamento de rejeição determinístico é aplicado independentemente à quota de cada região da própria região e à quota de cada região de outras regiões.
O comportamento de rejeição de rotas determinístico tem as seguintes consequências:
Quando são recebidos prefixos IPv4 e IPv6, o Cloud Router geralmente descarta primeiro os prefixos IPv6 sempre que é excedida uma quota de destino exclusiva. Isto acontece porque o comprimento da máscara de sub-rede mais curto mais comum para IPv6 (
/48) é mais longo do que o comprimento da máscara de sub-rede possível mais longo para IPv4 (/32).Se o conjunto de prefixos aprendidos em cada região permanecer constante, Google Cloud programa um conjunto consistente de rotas dinâmicas locais em todas as regiões, sujeito ao modo de encaminhamento dinâmico da rede VPC. Esta consistência, incluindo as rotas que são ignoradas pelo Cloud Router, é preservada quando as tarefas do Cloud Router são reiniciadas.
Evitar a eliminação do trajeto
Durante a eliminação de rotas, perde a conetividade para os prefixos que são eliminados. Para evitar a eliminação de rotas, monitorize a utilização de prefixos de origem própria e de outras regiões de cada região através do Cloud Monitoring ou do Cloud Logging e certifique-se de que não anuncia mais destinos únicos do que cada quota.
Considere resumir as rotas para reduzir o número de destinos únicos. Por
exemplo, se tiver as quatro sub-redes 10.10.10.0/24, 10.10.10.1/24, 10.10.10.2/24 e 10.10.10.3/24, pode resumi-las como um prefixo,
10.10.0.0/22.
Se o resumo não for possível, contacte a sua Google Cloud equipa de vendas para discutir opções alternativas.
Gerenciar cotas
OCloud Router 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 cotas, os membros do gerenciamento de identidade e acesso (IAM, na sigla em inglês) precisam ter um dos papéis a seguir:
| Tarefa | Papel necessário |
|---|---|
| Verificar cotas para um projeto | Uma das seguintes opções:
|
| Modificar cotas, solicitar cota extra | Uma das seguintes opções:
|
Verificar sua cota
Console
- No console Google Cloud , acesse a página Cotas.
- 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_IDPara 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, Google Cloud vai retornar o
seguinte código de status HTTP: 413 Request Entity Too Large.
Solicitar cota adicional
Para ajustar a maioria das cotas, use o console Google Cloud . Para mais informações, consulte Solicitar um ajuste de cota.
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, você pode ter cota suficiente para criar um novo endereço IP externo regional em uma determinada região. 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.