Kontingente und Limits für Load-Balancing-Ressourcen

In den folgenden Abschnitten werden Kontingente und Limits für Load-Balancer beschrieben. Sie können über die Google Cloud Console zusätzliche Kontingente anfordern, um ein Kontingent zu ändern. Limits können normalerweise nicht erhöht werden, sofern nicht ausdrücklich anders angegeben.

Kontingente und Limits

Weiterleitungsregeln

Posten Kontingente und Limits Hinweise
Weiterleitungsregeln pro Google Cloud-Projekt Kontingent Dieses Kontingent stellt die maximale Anzahl von Weiterleitungsregeln in Ihrem Projekt dar. Es gilt kollektiv für alle Weiterleitungsregeln, ungeachtet deren Verwendung. Darin enthalten sind Weiterleitungsregeln für die Protokollweiterleitung, Classic VPN-Gateways sowie Load-Balancing-Schemas (INTERNAL, INTERNAL_MANAGED, INTERNAL_SELF_MANAGED und EXTERNAL).
Maximale Anzahl Weiterleitungsregeln für:
– Internes TCP-/UDP-Load-Balancing
– Internes HTTP(S)-Load-Balancing
75 pro VPC-Netzwerk Weitere Informationen zur Anwendung dieser Limits finden Sie unter Limits für VPC-Netzwerk-Peering.
Maximale Anzahl von internen Weiterleitungsregeln, die eine interne IP-Adresse gemeinsam nutzen können 10 Dieses Limit kann nicht erhöht werden.
Ports pro interner Weiterleitungsregel 5, als Liste oder Bereich
Mit der Portoption ALL unbegrenzt
Dieses Limit kann nicht erhöht werden.
Interne Weiterleitungsregeln pro internem Back-End-Dienst Kein separates Limit Vorbehaltlich anderer Kontingente und Limits können mehrere interne Weiterleitungsregeln auf denselben internen Back-End-Dienst verweisen.

Zielpools und Ziel-Proxys

Posten Kontingente und Limits Hinweise
Zielpools Kontingent Dieses Kontingent gilt pro Projekt.
Ziel-HTTP-Proxys Kontingent Dieses Kontingent gilt pro Projekt.
Ziel-HTTPS-Proxys Kontingent Dieses Kontingent gilt pro Projekt.
Ziel-SSL-Proxys Kontingent Dieses Kontingent gilt pro Projekt.
Ziel-TCP-Proxys Kontingent Dieses Kontingent gilt pro Projekt.
SSL-Richtlinien pro HTTPS- oder SSL-Ziel-Proxy 1 Dieses Limit kann nicht erhöht werden.
SSL-Zertifikate pro HTTPS- oder SSL-Ziel-Proxy 15 Dieses Limit kann nicht erhöht werden.

SSL-Zertifikate

Posten Kontingente und Limits Hinweise
SSL-Zertifikate Kontingent Dieses Kontingent gilt pro Projekt.
Unterstützte Schlüssellängen für private Schlüssel 2.048 Bit RSA (RSA-2048)
256 Bit ECDSA (ECDSA P-256)
Diese Limits können nicht erhöht werden.
Mehrere Domains pro von Google verwaltetem SSL-Zertifikat 100 Dieses Limit kann nicht erhöht werden.
Länge der Domainnamen für von Google verwaltete Zertifikate 64 Byte Dieses Limit kann nicht erhöht werden.

Diese Längenbeschränkung gilt nur für von Google verwaltete SSL-Zertifikate. Das Limit von 64 Byte in diesen Zertifikaten gilt nur für die erste Domain im Zertifikat. Die Längenbeschränkung für die anderen Domains im Zertifikat beträgt 253 Byte. Diese gilt für alle Domainnamen im Internet, nicht nur für von Google verwaltete Zertifikate.

URL-Zuordnungen

Posten Kontingente und Limits Hinweise
URL-Zuordnungen Kontingent Dieses Kontingent gilt pro Projekt.
Hostregeln pro URL-Zuordnung 50 Dieses Limit kann nicht erhöht werden.
Pfad-Matcher pro URL-Zuordnung 50 Dieses Limit kann nicht erhöht werden.
Pfadregeln pro Pfad-Matcher 50 Dieses Limit kann nicht erhöht werden.
Routingregeln pro Pfad-Matcher 50 Dieses Limit kann nicht erhöht werden.
Abgleichsregeln pro Routingregel 50 Dieses Limit kann nicht erhöht werden.
Header-Übereinstimmungen pro Abgleichsregel 50 Dieses Limit kann nicht erhöht werden.
Übereinstimmende Abfrageparameter pro Abgleichsregel 50 Dieses Limit kann nicht erhöht werden.
Header-Aktionen pro Pfad-Matcher 50 Dieses Limit kann nicht erhöht werden.
Back-End-Dienste oder Back-End-Buckets pro Pfadregel Ein Back-End-Dienst oder ein Back-End-Bucket, nicht beides Dieses Limit kann nicht erhöht werden.

Back-End-Buckets

Posten Kontingente und Limits Hinweise
Back-End-Buckets Kontingent Dieses Kontingent gilt pro Projekt.

Back-End-Dienste

Posten Kontingente und Limits Hinweise
Back-End-Dienste Kontingent Dieses Kontingent umfasst alle Back-End-Dienste in Ihrem Projekt (INTERNAL, INTERNAL_MANAGED, INTERNAL_SELF_MANAGED und EXTERNAL).
Back-End-Dienste pro TCP-Proxy-Load-Balancer, SSL-Proxy-Load-Balancer oder internem TCP-/UDP-Load-Balancer 1 Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von VM-Instanzen pro internem Back-End-Dienst

Maximale Anzahl von VM-Instanzen im aktiven Pool, wenn Sie einen Failover für einen internen Back-End-Dienst konfiguriert haben
250, unabhängig davon, wie die VMs auf Instanzgruppen verteilt sind Dieses Limit kann nicht erhöht werden.
Interne Back-End-Dienste gemäß interner Weiterleitungsregel 1 Dieses Limit kann nicht erhöht werden.
Benannte Ports pro externem Back-End-Dienst 1 Dieses Limit kann nicht erhöht werden.
Benannte Ports pro internem Back-End-Dienst 0 Dieses Limit kann nicht erhöht werden.

Back-Ends

Posten Kontingente und Limits Hinweise
Instanzgruppen Kontingent Dieses Kontingent gilt pro Projekt.
Instanzgruppen-Back-Ends pro internem Back-End-Dienst 50 Dieses Limit kann nicht erhöht werden.
Back-End-VMs für einen internen TCP-/UDP-Load-Balancer können auf bis zu 50 Instanzgruppen verteilt werden, wenn die Gesamtzahl der Back-End-VMs 250 oder weniger beträgt.
Instanzgruppen-Back-Ends pro externem Back-End-Dienst 50 Dieses Limit kann nicht erhöht werden.
NEGs pro Projekt Kontingent Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.
NEG-Back-Ends pro externem Back-End-Dienst 50 Dieses Limit kann nicht erhöht werden.

Endpunkte pro NEG

Posten Kontingente und Limits Hinweise
Endpunkte pro NEG 10.000 Dieses Limit kann nicht erhöht werden.

VMs pro Instanzgruppe

Posten Kontingente und Limits Hinweise
VMs pro regionalem Instanzgruppen-Back-End für einen externen Back-End-Dienst Hängt von der Anzahl der Ports ab, die im benannten Port für die Instanzgruppe angegeben sind. Der kleinere der beiden Werte:
A: 2.000
B: VMs * (Anzahl der Ports im benannten Port, der die meisten Portnummern enthält) <= 10.000
Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.
VMs pro zonalem Instanzgruppen-Back-End für einen externen Back-End-Dienst Hängt von der Anzahl der Ports ab, die im benannten Port für die Instanzgruppe angegeben sind. Der kleinere der beiden Werte:
A: 1.000
B: VMs * (Anzahl der Ports im benannten Port, der die meisten Portnummern enthält) <= 10.000
Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.
VMs pro Instanzgruppe, wenn die Instanzgruppe ein Back-End für einen internen Back-End-Dienst ist Kein separates Limit Back-End-VMs für einen internen TCP-/UDP-Load-Balancer können auf bis zu 50 Instanzgruppen verteilt werden, wenn die Gesamtzahl der Back-End-VMs 250 oder weniger beträgt.

Abfragen pro Sekunde für HTTP(S)-Load-Balancing

Posten Kontingente und Limits Hinweise
Abfragen pro Sekunde pro Back-End-Instanzgruppe oder NEG für externes HTTP(S)-Load-Balancing Konfigurierbar bei Verwendung von RATE als Load-Balancing-Modus. Durch Ihre Back-Ends begrenzt.
Abfragen pro Sekunde pro Region und Netzwerk für internes HTTP(S)-Load-Balancing Beim internen HTTP(S)-Load-Balancing hängt die maximale Anzahl von Abfragen pro Sekunde von der Größe der Abfragen und der Komplexität der Konfiguration ab. Wenn die Last die Kapazität überschreitet, nimmt die Latenz zu und Anfragen werden unter Umständen abgebrochen. Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.

Header-Größe für HTTP(S)-Load-Balancing

Posten Kontingente und Limits Hinweise
Maximale Größe des Client-Anfrageheaders für externes HTTP(S)-Load-Balancing ca. 15 KB (Kilobyte) Dieses Limit kann nicht erhöht werden.
Anfrage-URL und Anfrageheader dürfen zusammen maximal 16 KB groß sein.
Maximale Größe des Back-End-Antwortheaders für externes HTTP(S)-Load-Balancing ca. 128 KB (Kilobyte) Dieses Limit kann nicht erhöht werden.
Maximale Größe des Back-End-Anfrageheaders für internes HTTP(S)-Load-Balancing 60 KB (Kilobyte) Dieses Limit kann nicht erhöht werden.
Umwandlung der Header in Kleinbuchstaben Immer, für internes HTTP(S)-Load-Balancing Für das interne HTTP(S)-Load-Balancing gelten hinsichtlich der Groß-/Kleinschreibung von Anfrage- und Antwort-Headern die HTTP/2-Konventionen. Alle Header werden ungeachtet des verwendeten Protokolls in Kleinbuchstaben umgewandelt. Beispiel: Host wird zu host und Keep-ALIVE zu keep-alive. Beim externen HTTP(S)-Load-Balancing bleibt die ursprüngliche Groß-/Kleinschreibung von Anfrage- und Antwort-Headern erhalten.
Maximale Anzahl konfigurierter benutzerdefinierter Anfrageheader für jeden Back-End-Dienst 16 Dieses Limit kann nicht erhöht werden.
Maximale Anzahl konfigurierter benutzerdefinierter Antwortheader für jeden Back-End-Dienst 16 Dieses Limit kann nicht erhöht werden.
Gesamtgröße aller benutzerdefinierten Anfrageheader pro Back-End-Dienst (Headername und -wert, vor der Variablenerweiterung) 8 KB Dieses Limit kann nicht erhöht werden.
Gesamtgröße aller benutzerdefinierten Antwortheader pro Back-End-Dienst (Headername und -wert, vor der Variablenerweiterung) 8 KB Dieses Limit kann nicht erhöht werden.

Proxy-Instanzen für internes HTTP(S)-Load-Balancing

Posten Kontingente und Limits Hinweise
Proxy-Instanzen pro Netzwerk 30 Dieses Kontingent stellt die maximale Anzahl von Envoy-Proxy-Instanzen dar, die Ihrem Netzwerk automatisch zugewiesen werden.
Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.

Überblick

Auf Cloud Load Balancing werden aus verschiedenen Gründen Kontingente für die Ressourcennutzung festgelegt. Diese schützen unter anderem die gesamte Google Cloud-Community vor unerwarteten Auslastungsspitzen. Außerdem helfen Kontingente Nutzern, die Google Cloud mit der kostenlosen Stufe testen, die Testnutzung nicht zu überschreiten.

Alle Projekte beginnen mit den gleichen Kontingenten, die Sie ändern können. Fordern Sie dazu zusätzliche Kontingente an. Einige Kontingente können entsprechend Ihrer Nutzung eines Produkts automatisch erhöht werden.

Berechtigungen

Um Kontingente anzuzeigen oder Kontingenterhöhungen anzufordern, benötigen IAM-Mitglieder eine der folgenden Rollen.

Aufgabe Erforderliche Rolle
Kontingente für ein Projekt überprüfen Projektinhaber oder -bearbeiter oder Kontingentbetrachter
Kontingente ändern, zusätzliche Kontingente anfordern Projektinhaber oder -bearbeiter, Kontingentadministrator oder benutzerdefinierte Rolle mit der Berechtigung serviceusage.quotas.update

Kontingent prüfen

Wechseln Sie in der Cloud Console zur Seite Kontingente.

Führen Sie mit dem gcloud-Befehlszeilentool den folgenden Befehl aus, um Ihre Kontingente zu prüfen. Ersetzen Sie [PROJECT_ID] durch Ihre Projekt-ID:

        gcloud compute project-info describe --project [PROJECT_ID]

Mit dem folgenden Befehl prüfen Sie das genutzte Kontingent in einer Region:

        gcloud compute regions describe example-region

Fehler beim Überschreiten Ihres Kontingents

Wenn Sie mit einem gcloud-Befehl ein Kontingent überschreiten, gibt gcloud eine quota exceeded-Fehlermeldung aus und liefert den Exit-Code 1.

Wenn Sie mit einer API-Anfrage ein Kontingent überschreiten, liefert Google Cloud diesen HTTP-Statuscode: HTTP 413 Request Entity Too Large.

Weitere Kontingente anfordern

Auf der Seite Kontingente in der Cloud Console können Sie weitere Kontingente anfordern. Die Bearbeitung von Kontingentanforderungen dauert 24 bis 48 Stunden.

  1. Rufen Sie die Seite Kontingente auf.

    Zur Seite "Kontingente"

  2. Wählen Sie auf der Seite Kontingente die Kontingente aus, die Sie ändern möchten.
  3. Klicken Sie oben auf der Seite auf die Schaltfläche Kontingente bearbeiten.
  4. Geben Sie Ihren Namen, Ihre E-Mail-Adresse und Ihre Telefonnummer ein und klicken Sie auf Weiter.
  5. Geben Sie Ihre Kontingentanforderung ein und klicken Sie auf Weiter.
  6. Senden Sie die Anfrage.

Ressourcenverfügbarkeit

Jedes Kontingent stellt die maximale Anzahl an Ressourcen eines bestimmten Typs dar, die Sie erstellen können, wenn der Ressourcentyp verfügbar ist. Beachten Sie, dass Kontingente die Verfügbarkeit von Ressourcen nicht garantieren. Auch wenn Sie ein verfügbares Kontingent haben, können Sie keine neue Ressource erstellen, wenn diese nicht verfügbar ist. Beispiel: Sie haben noch ein Kontingent zum Erstellen neuer externer IP-Adressen in us-central1, es sind jedoch keine IP-Adressen mehr verfügbar. Die Verfügbarkeit von zonalen Ressourcen kann sich auch auf Ihre Fähigkeit auswirken, eine neue Ressource zu erstellen.

Es kommt nur selten vor, dass Ressourcen in einer gesamten Region nicht verfügbar sind. Ressourcen in einer Zone können jedoch vorübergehend erschöpft sein, was sich normalerweise nicht auf das SLA für den Ressourcentyp auswirkt. Weitere Informationen finden Sie im entsprechenden Service Level Agreement (SLA) für die jeweilige Ressource.