Kontingente und Limits

In diesem Dokument sind die Kontingente und Systemlimits für Cloud Router aufgeführt.

  • Kontingente geben an, wie viel einer zählbaren, freigegebenen Ressource Sie verwenden können. Kontingente werden von Diensten wie Trusted Cloud by S3NS Cloud Router definiert.
  • Systemlimits sind feste Werte, die nicht geändert werden können.

Trusted Cloud by S3NS nutzt Kontingente, um Fairness zu gewährleisten und Spitzen bei Ressourcennutzung und -verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einerTrusted Cloud Ressource Ihr Trusted Cloud Projekt nutzen darf. Kontingente gelten für eine Reihe von Ressourcentypen, einschließlich Hardware, Software und Netzwerkkomponenten. Mit Kontingenten können Sie beispielsweise die Anzahl der API-Aufrufe an einen Dienst, die Anzahl der von Ihrem Projekt gleichzeitig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Die Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community derTrusted Cloud -Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Trusted Cloud Ressourcen.

Das Cloud-Kontingentsystem ermöglicht Folgendes:

Wenn Sie versuchen, mehr von einer Ressource zu verbrauchen, als das Kontingent zulässt, blockiert das System in den meisten Fällen den Zugriff auf die Ressource. Die Aufgabe, die Sie ausführen möchten, schlägt fehl.

Kontingente gelten in der Regel auf Trusted Cloud Projektebene. Ihre Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf Ihr verfügbares Kontingent in einem anderen Projekt. Innerhalb eines Trusted Cloud -Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.

Für Cloud Router-Ressourcen gelten außerdem Systemlimits. Systemlimits können nicht geändert werden.

Kontingente

Informationen zum Ändern eines Kontingents finden Sie unter Weitere Kontingente anfordern.

In dieser Tabelle sind wichtige Kontingente pro Projekt aufgeführt. Weitere Kontingente finden Sie auf der Seite Kontingente und Systemlimits der Trusted Cloud Console.

Element Kontingent Hinweise
Cloud Router pro Projekt Kontingent Unabhängig vom Kontingent ist jedes Netzwerk auf fünf Cloud Router pro Region beschränkt. Siehe Limits

Einzigartige Präfixe für dynamische Cloud Router-Routen aus der eigenen Region pro Region und VPC-Netzwerk

Die maximale Anzahl eindeutiger Zielpräfixe für erkannte Routen, die von allen Cloud Routern in derselben Region auf Subnetze in einer Region angewendet werden können. Dies wird als from-own-region-Kontingent einer Region bezeichnet.

 Kontingent

Auf dieses Kontingent werden sowohl IPv4- als auch IPv6-Präfixe angerechnet.

Alle erkannten Routen werden auf dieses Kontingent angerechnet, einschließlich benutzerdefinierter erkannter Routen und von BGP empfangener Routen.

Routen werden nach eindeutigen Zielen gruppiert. Routen mit identischen Zielen, aber unterschiedlichen nächsten Hops zählen als ein Ziel. Routen mit identischen Zielen und identischen nächsten Hops gelten ebenfalls als ein Ziel.

Für Netzwerke im globalen Modus für dynamisches Routing ist es möglich, eines der Kontingente für eindeutige Präfixe für dynamische Routen zu erreichen, ohne das andere zu erreichen. Wenn eines der Kontingente überschritten wurde, können vorübergehende Verbindungsprobleme auftreten, wenn Routen verloren gehen./ Weitere Informationen finden Sie im Beispiel zu erkannten Routen.

Weitere Informationen zu diesen Kontingenten sowie zu Messwerten, mit denen Sie Ihre aktuelle Nutzung ermitteln können, finden Sie unter Fehlerbehebung bei BGP-Routen und Routenauswahl.

Nur anwendbar auf VPC-Netzwerke im globalen Modus für dynamisches Routing:

Einzigartige dynamische Cloud Router-Routenpräfixe aus anderen Regionen pro Region und VPC-Netzwerk

Die maximale Anzahl eindeutiger Ziele für erkannte Routen, die von Cloud Routern aus verschiedenen Regionen auf Subnetze in einer Region angewendet werden können Dies wird als from-other-regions-Kontingent einer Region bezeichnet.

 Kontingent

Auf dieses Kontingent werden sowohl IPv4- als auch IPv6-Präfixe angerechnet.

Alle erkannten Routen werden auf dieses Kontingent angerechnet, einschließlich benutzerdefinierter erkannter Routen und von BGP empfangener Routen.

Routen werden nach eindeutigen Zielen gruppiert. Routen mit identischen Zielen, aber unterschiedlichen nächsten Hops zählen als ein Ziel. Routen mit identischen Zielen und identischen nächsten Hops gelten ebenfalls als ein Ziel.

Für Netzwerke im globalen Modus für dynamisches Routing ist es möglich, eines der Kontingente für eindeutige Präfixe für dynamische Routen zu erreichen, ohne das andere zu erreichen. Wenn eines der Kontingente erreicht wurde, können vorübergehende Verbindungsprobleme auftreten, wenn Routen verloren gehen. Weitere Informationen finden Sie im Beispiel zu erkannten Routen.

Weitere Informationen zu diesen Kontingenten sowie zu Messwerten, mit denen Sie Ihre aktuelle Nutzung ermitteln können, finden Sie unter Fehlerbehebung bei BGP-Routen und Routenauswahl.

Limits

Für Virtual Private Cloud-Netzwerke (VPC) gelten die folgenden Limits für Cloud Router. Wenn nichts anderes angegeben ist, können diese Limits nicht erhöht werden.

Element Limit Hinweise
Maximale Anzahl der Cloud Router je Kombination von VPC-Netzwerk und Region 5 Wenn Sie für Ihr Projekt ein ausreichend hohes Kontingent haben, können Sie in einem VPC-Netzwerk und einer Region bis zu fünf Cloud Router erstellen.
Maximale Anzahl der BGP-Peers für jeden Cloud Router in einem gegebenen VPC-Netzwerk und einer Region 128 Ein BGP-Peer kann folgendes sein:
Maximale Anzahl von Präfixen, die Cloud Router von einer einzelner BGP-Peer akzeptiert 5.000 Wenn ein BGP-Peer mehr als 5.000 Präfixe anbietet, setzt Cloud Router die BGP-Sitzung zurück.
Maximale Anzahl von Begriffen aller angewendeten BGP-Routenrichtlinien innerhalb eines einzelnen BGP-Peers oder einer einzelnen Richtung 1.000 Dieses Limit wird nicht auf Ressourcen aufgeteilt, sondern zusammengefasst. Es gibt keine Begrenzung für die Größe eines einzelnen Übereinstimmungs- oder Aktionsausdrucks, die Anzahl der Aktionen in einem Begriff, die Anzahl der Begriffe in einer einzelnen Richtlinie oder die Anzahl der Richtlinien.
Maximale Anzahl von Route Advertisements im Subnetz pro BGP-Sitzung für einen Cloud Router Keine Beschränkung Bei Cloud Routern besteht kein Limit für die Anzahl der Route Advertisements im Subnetz. Die Anzahl der Subnetzrouten hängt von der Anzahl der Subnetze ab, die durch die VPC-Netzwerkkontingente und -limits bestimmt wird.
Maximale Anzahl von benutzerdefinierten beworbenen Routen pro BGP-Sitzung für einen Cloud Router 200 Wenn die benutzerdefinierten Routen für alle BGP-Sitzungen auf einem Cloud Router identisch sind, stellt dieses Limit die Gesamtzahl für eindeutige IPv4- und IPv6-Routen für den Cloud Router dar. In diesem Fall erhält jede Sitzung den gleichen Satz an benutzerdefinierten beworbenen Routen.
Die maximale Gesamtgröße aller Übereinstimmungs- und Aktionsausdrucksliterale, die in BGP-Routenrichtlinien für einen Cloud Router verwendet werden und als UTF-8 codiert sind. 250 KiB Für einen bestimmten Cloud Router wird dieses Limit nicht auf mehrere Ressourcen aufgeteilt, sondern zusammengefasst. Es gibt keine Begrenzung für die Größe eines einzelnen Übereinstimmungs- oder Aktionsausdrucks, die Anzahl der Aktionen in einem Begriff, die Anzahl der Begriffe in einer einzelnen BGP-Routenrichtlinie oder die Anzahl der BGP-Routenrichtlinien.
Maximale Anzahl von Abfragen pro Minute für list-bgp-routes Anrufe auf einem einzelnen Cloud Router 1500 Dieses Kontingent stammt von compute.googleapis.com/list_requests_per_region. Weitere Informationen finden Sie unter Ratenkontingente.
Maximale Anzahl von BGP-Routenrichtlinien pro Cloud Router. 500
Maximale Anzahl benutzerdefinierter erkannter Routen für eine BGP-Sitzung 10

Weitere Informationen zu diesem Feature finden Sie unter Benutzerdefinierte erkannte Routen.

Die maximale Anzahl eindeutiger IP-Präfixe, die für eine bestimmte Region in einem VPC-Netzwerk als benutzerdefinierte erkannte Routen konfiguriert werden können. Mit diesem Limit können dieselben Bereiche auf mehreren Peers verwendet werden.

10

Weitere Informationen zu diesem Feature finden Sie unter Benutzerdefinierte erkannte Routen.

Beispiel zu erkannten Routen

Die folgenden Beispiele veranschaulichen das Verhalten beim Routenverlust, das Sie erreichen können, wenn das Kontingent für „from-own-region“ oder „from-other-regions“ überschritten wird.

Angenommen, Sie haben Cloud Router in der Region us-east1 und Cloud Router in der Region us-west1 im selben VPC-Netzwerk und globales dynamisches Routing ist aktiviert. Jeder Cloud Router in jeder Region lernt 250 eindeutige Ziele. Zur Veranschaulichung dieses Beispiels lernt jeder Cloud Router in jeder Region keine der gleichen Ziele.

Unabhängig davon, welche Cloud Router die Routen in den einzelnen Regionen lernen, ist das Kontingent für „from-own-region“ jeder Region ausgeschöpft, da 250 von 250 eindeutigen Zielen von den Cloud Routern in jeder Region erlernt werden. Die from-other-regions-Kontingente für beide Regionen sind ebenfalls aufgebraucht, da jeder Cloud Router 250 eindeutige Ziele aus der anderen Region importiert. Wenn im Beispiel-VPC-Netzwerk regionales dynamisches Routing verwendet wird, gelten die Kontingente für „Aus anderen Regionen“ nicht in jeder Region, da der regionale Modus für dynamisches Routing die VPC anweist, nur dynamische Routen in der Region zu erstellen, die dem nächsten Hop der Route entspricht.

Kontingent für „from-own-region“ einer Region überschreiten

Angenommen, Ihr lokaler Router, der mit einem Cloud Router in us-west1 verbunden ist, bewirbt ein 251. Ziel. Cloud Router in der Region us-west1 wählen 250 der 251 eindeutigen Ziele nach einer deterministischen Routenreihenfolge aus. Diese Router senden diese 250 eindeutigen Ziele an das VPC-Netzwerk und erstellen 250 dynamische Routen in der Region us-west1.

Da das VPC-Netzwerk den Modus für globales dynamisches Routing verwendet, werden auch maximal 250 dynamische Routen in jeder anderen Region erstellt, wobei das Kontingent für eindeutige Ziele von anderen Regionen gilt. Im nächsten Abschnitt wird dies in anderen Regionen ausführlicher beschrieben.

Kontingent für „from-other-regions“ einer Region überschreiten

Wenn Cloud Router in der Region us-west1 251 eindeutige Ziele erkannt haben, werden 250 der 251 eindeutigen Ziele aus us-west1 Ressourcen in der Region us-east1 zur Verfügung gestellt, da das Kontingent für from-other-regions der Region us-east1 nur 250 eindeutige Ziele akzeptieren kann.

Angenommen, Sie erstellen einen Cloud Router in einer dritten Region (us-central1) im selben VPC-Netzwerk. Angenommen, der neue Cloud Router lernt von seinem BGP-Peer zehn eindeutige Ziele. Obwohl das Kontingent für „from-own-region“ der Region us-central1 nicht überschritten wurde, wurde das Kontingent für „from-other-regions“ der Region us-central1 überschritten, da insgesamt 500 eindeutige Ziele von den beiden anderen Regionen (250 von us-east1 und andere 250 von us-west1) bereitgestellt werden.

Regionsweise legt die deterministische Routenreihenfolge Routen für maximal 250 eindeutige Ziele in anderen Regionen fest, wie in der folgenden Tabelle angegeben.

Region Eindeutige Ziele lokal in der Region
(Nutzung des Kontingents „from-own-region“) 		Eindeutige Ziele aus anderen Regionen
(Nutzung des Kontingents für „from-other-regions“ der Region)
us-west1

251 empfangen. 250 der 251 sind ausgewählt und einer der 251 wird aufgrund der deterministischen Routenreihenfolge verworfen. 250 dynamische Routen mit den nächsten Hops in us-west1 werden in us-west1 erstellt.

Die 250 ausgewählten Präfixe werden für andere Regionen freigegeben.

260 erhalten (250 von us-east1, 10 ab us-central1). 250 der 260 werden ausgewählt und 10 von den 260 werden nach der deterministischen Routenreihenfolge verworfen.

250 dynamische Routen mit den nächsten Hops außerhalb von us-west1 werden in us-west1 erstellt.
us-east1

250 empfangen. Alle 250 werden nach der deterministischen Routenreihenfolge ausgewählt. 250 dynamische Routen mit den nächsten Hops in us-east1 werden in us-east1 erstellt.

Alle 250 ausgewählten Präfixe werden für andere Regionen freigegeben.

260 erhalten (250 von us-west1, 10 ab us-central1). 250 der 260 werden ausgewählt und 10 von den 260 werden nach der deterministischen Routenreihenfolge verworfen.

250 dynamische Routen mit den nächsten Hops außerhalb von us-east1 werden in us-east1 erstellt.
us-central1

10 erhalten. Alle zehn werden nach der deterministischen Routenreihenfolge ausgewählt. Zehn dynamische Routen mit den nächsten Hops in us-central1 werden in us-central1 erstellt.

Alle zehn ausgewählten Präfixe werden für andere Regionen freigegeben.

500 erhalten (250 von us-west1, 250 von us-east1). 250 der 500 werden ausgewählt und 250 der 500 werden durch die deterministische Routenreihenfolge verworfen.

250 dynamische Routen mit den nächsten Hops außerhalb von us-central1 werden in us-central1 erstellt.

Obwohl das Kontingent für „from-other-regions“ der Region us-central1 überschritten wird, kann das Kontingent für „from-own-region“ Ziele akzeptieren, deren nächste Hops in der Region us-central1 liegen.

Verhalten bei deterministischem Routenverlust

Cloud Router implementiert ein deterministisches Routenverlustverhalten basierend auf der Länge der Subnetzmaske und den lexikografischen Eigenschaften jedes empfangenen Präfixes. Innerhalb jeder Region gilt der folgende Prozess unabhängig für die Liste der from-own-region-Ziele und der Liste der eindeutigen from-other-regions-Ziele:

  • Die Liste wird zuerst von der kürzesten zur längsten Länge der Subnetzmaske sortiert, dann lexikografisch. Beispiel: 10.0.0.0/8 steht vor 10.2.1.0/24, also vor 10.99.1.0/24.

  • Die ersten 250 Einträge in der Liste werden beibehalten. Alle anderen werden verworfen.

Wie unter from-other-regions-Kontingent einer Region überschreiten gezeigt, wird das deterministische Auslieferungsverhalten unabhängig auf das from-own-region-Kontingent und das from-other-regions-Kontingent der einzelnen Regionen angewendet.

Das deterministische Routenverlust hat folgende Konsequenzen:

  • Wenn beide IPv4- und IPv6-Präfixe empfangen werden, verwirft Cloud Router in der Regel zuerst IPv6-Präfixe, wenn ein eindeutiges Zielkontingent überschritten wird. Dies liegt daran, dass die kürzeste Subnetzmaskenlänge für IPv6 (/48) länger als die längste mögliche Subnetzmaskenlänge für IPv4 (/32) ist.

  • Wenn die in jeder Region erlernten Präfixe konstant bleiben, programmiertTrusted Cloud gemäß dem dynamischen Routingmodus des VPC-Netzwerk eine konsistente Gruppe lokaler dynamischer Routen in jeder Region. Diese Konsistenz wird beibehalten, einschließlich der Routen, die von Cloud Router gelöscht werden, wenn Cloud Router-Aufgaben neu gestartet werden.

Routenverlust wird vermieden

Während dem Routenverlust geht die Verbindung für die Präfixe, die verworfen werden, verloren. Um den Routenverlust zu vermeiden, überwachen Sie die from-own-region- und from-other-regions-Präfixnutzung mit Cloud Monitoring oder Cloud Logging und stellen Sie sicher, dass nicht mehr eindeutige Ziele als das jeweilige Kontingent beworben werden.

Sie können Routen zusammenfassen, um die Anzahl der eindeutigen Ziele zu reduzieren. Wenn Sie beispielsweise die vier Subnetze 10.10.10.0/24, 10.10.10.1/24, 10.10.10.2/24 und 10.10.10.3/24 haben, können Sie sie in einem Präfix zusammenfassen, z. B. 10.10.0.0/22.

Wenn eine Zusammenfassung nicht möglich ist, wenden Sie sich an Ihr Trusted Cloud Vertriebsteam, um alternative Optionen zu besprechen.

Manage quotas

Cloud Router enforces quotas on resource usage for various reasons. For example, quotas protect the community of Trusted Cloud by S3NS users by preventing unforeseen spikes in usage. Quotas also help users who are exploring Trusted Cloud with the free tier to stay within their trial.

All projects start with the same quotas, which you can change by requesting additional quota. Some quotas might increase automatically based on your use of a product.

Permissions

To view quotas or request quota increases, Identity and Access Management (IAM) principals need one of the following roles.

Task Required role
Check quotas for a project One of the following:
Modify quotas, request additional quota One of the following:
  • Project Owner (roles/owner)
  • Project Editor (roles/editor)
  • Quota Administrator (roles/servicemanagement.quotaAdmin)
  • A custom role with the serviceusage.quotas.update permission

Check your quota

Console

  1. In the Trusted Cloud console, go to the Quotas page.

    Go to Quotas

  2. To search for the quota that you want to update, use the Filter table. If you don't know the name of the quota, use the links on this page instead.

gcloud

Using the Google Cloud CLI, run the following command to check your quotas. Replace PROJECT_ID with your own project ID.

    gcloud compute project-info describe --project PROJECT_ID

To check your used quota in a region, run the following command:

    gcloud compute regions describe example-region

Errors when exceeding your quota

If you exceed a quota with a gcloud command, gcloud outputs a quota exceeded error message and returns with the exit code 1.

If you exceed a quota with an API request, Trusted Cloud returns the following HTTP status code: 413 Request Entity Too Large.

Request additional quota

To adjust most quotas, use the Trusted Cloud console. For more information, see Request a quota adjustment.

Resource availability

Each quota represents a maximum number for a particular type of resource that you can create, if that resource is available. It's important to note that quotas don't guarantee resource availability. Even if you have available quota, you can't create a new resource if it is not available.

For example, you might have sufficient quota to create a new regional, external IP address in a given region. However, that is not possible if there are no available external IP addresses in that region. Zonal resource availability can also affect your ability to create a new resource.

Situations where resources are unavailable in an entire region are rare. However, resources within a zone can be depleted from time to time.