Kontingente und Limits
In diesem Dokument sind die Kontingente und Limits für VPC-Netzwerke (Virtual Private Cloud) aufgeführt.
Google Cloud nutzt Kontingente, um Fairness zu gewährleisten und Spitzen bei Ressourcennutzung und -verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einer Google Cloud-Ressource Ihr Google 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 der Google Cloud-Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud-Ressourcen.
Das Cloud-Kontingentsystem ermöglicht Folgendes:
- Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen
- Ihren Verbrauch dieser Ressourcen einschränken
- Eine Möglichkeit bieten, Änderungen am Kontingentwert anzufordern
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 Google Cloud-Projektebene. Ihre Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf Ihr verfügbares Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud-Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.
Für VPC-Ressourcen gelten außerdem Systemlimits. Systemlimits können nicht geändert werden.
Kontingente
Informationen zum Ändern eines Kontingents finden Sie unter Weitere Kontingente anfordern.
Pro Projekt
In dieser Tabelle sind wichtige globale Kontingente für VPC-Ressourcen pro Projekt aufgeführt. Informationen zu anderen Kontingenten finden Sie in der Google Cloud Console auf der Seite Kontingente.
Richten Sie das Monitoring für den Messwert serviceruntime.googleapis.com/quota/allocation/usage
für den Ressourcentyp Consumer Quota
ein, um Kontingente pro Projekt mit Cloud Monitoring zu überwachen. Legen Sie weitere Labelfilter (service
, quota_metric
) fest, um den Kontingenttyp abzurufen. Informationen zum Monitoring von Kontingentmesswerten, einschließlich des Findens von Namen von Limits und Messwertnamen, finden Sie unter Kontingentmesswerte verwenden. Für jedes Kontingent gibt es ein Limit und einen Nutzungswert.
Kontingent | Beschreibung |
---|---|
Netzwerkbandbreite | |
Bandbreite für ausgehender Traffic von GCE-VM zum Internet in Mbit/s | Gesamtbandbreite für ausgehenden Traffic von Google Cloud-VMs in einer Region zu Zielen außerhalb eines VPC-Netzwerks (über das Standard-Internetgateway). Die Nutzung dieses Kontingents wird dem Projekt in Rechnung gestellt, das die Compute Engine-VMs enthält, die die Pakete senden. Schließt Traffic aus, der über den privaten Google-Zugriff an Google APIs und Google-Dienste gesendet wird. Schließt Traffic aus, der von VMs mit externen IP-Adressen an Google APIs und -Dienste gesendet wird. |
Netzwerkbandbreite für ausgehenden Traffic zwischen Regionen (Mbit/s) von Compute-Instanzen | Gesamtbandbreite für ausgehenden Traffic von Google Cloud-VMs in einer Region zu Zielen, die innerhalb eines VPC-Netzwerks routingfähig sind (mithilfe von nächsten Hops, die nicht das Standard-Internetgateway sind). Die Nutzung dieses Kontingents wird dem Projekt in Rechnung gestellt, das die Compute Engine-VMs enthält, die die Pakete senden. |
Shared VPC | |
Projekte mit projektübergreifendem Netzwerkdienst | Anzahl der Dienstprojekte mit freigegebener VPC, die an ein Hostprojekt mit freigegebener VPC angehängt werden können. Zusätzlich zu diesem Kontingent finden Sie weitere Informationen unter Limits für freigegebene VPC-Projekte. |
Allgemein | |
Netzwerke | Umfasst das Netzwerk default , das Sie entfernen können. |
Richtlinienbasierte Routen | Die Anzahl der richtlinienbasierten Routen, die Sie in Ihrem Projekt erstellen können. |
Router | Die Anzahl der Cloud Router, die Sie in Ihrem Projekt in jedem beliebigen Netzwerk und in jeder beliebigen Region erstellen können. Netzwerke haben auch ein Limit bezüglich der Anzahl von Cloud Routern in einer bestimmten Region. Weitere Informationen finden Sie unter Kontingente und Limits für Cloud Router. |
Paketspiegelungen | Die Anzahl der Paketspiegelungsrichtlinien, die Sie in Ihrem Projekt in jedem beliebigen Netzwerk und in jeder beliebigen Region erstellen können. |
Load-Balancer und Protokollweiterleitungsregeln Weitere Informationen finden Sie unter Weiterleitungsregeln in der Dokumentation zu Load-Balancing-Kontingenten. | |
Interne IP-Adressen | |
Interne IP-Adressen | Die Anzahl der regionalen statischen internen IPv4-Adressen, die Sie in den einzelnen Regionen für Ihr Projekt reservieren können. |
Regionale statische interne IPv6-Adressbereiche | Die Anzahl der regionalen statischen internen IPv6-Adressbereiche, die Sie in den einzelnen Regionen für Ihr Projekt reservieren können. |
Statische globale interne IPv4-Adressen | Die Anzahl der statischen globalen internen IPv4-Adressbereiche, die Sie in Ihrem Projekt reservieren können, z. B. zugewiesene IPv4-Adressbereiche für den Zugriff auf private Dienste und IPv4-Adressen, die für Private Service Connect-Endpunkte reserviert sind, die für den Zugriff auf globale Google APIs verwendet werden. Bei IP-Adressbereichen ist jeder Bereich ein zusammenhängender interner IP-Adressbereich. |
Interne Bereiche | Die Anzahl der internen Bereichsressourcen, die Sie in Ihrem Projekt reservieren können. |
Externe IP-Adressen | |
Statische IP-Adressen | Die Anzahl der regionalen statischen externen IPv4-Adressen, die Sie in den einzelnen Regionen für Ihr Projekt reservieren können. |
Regionale statische externe IPv6-Adressbereiche | Die Anzahl der regionalen statischen externen IPv6-Adressbereiche, die Sie in den einzelnen Regionen für Ihr Projekt reservieren können. |
Statische IP-Adressen (global) | Die Anzahl der globalen statischen externen IP-Adressen, die Sie in Ihrem Projekt reservieren können. |
Verwendete IP-Adressen | Die Anzahl der statischen und sitzungsspezifischen regionalen externen IP-Adressen, die Sie in Ihrem Projekt gleichzeitig verwenden können. |
Verwendete IP-Adressen (global) | Die Anzahl der statischen und sitzungsspezifischen globalen externen IP-Adressen, die Sie in Ihrem Projekt gleichzeitig verwenden können. |
Anfragen zur Adressverschiebung pro Minute | Die globale Anzahl von Adressverschiebungsanfragen, die Sie pro Minute stellen können. |
Anfragen zur Adressverschiebung pro Minute und Region | Die Anzahl der Adressverschiebungsanfragen, die Sie pro Minute und Region stellen können. |
Eigene IP verwenden (Bring your own IP, BYOL) | |
Statische BYOIP-IP-Adressen | Die Anzahl der regionalen externen IP-Adressen vom Typ Bring your own IP , die Sie in den einzelnen Regionen für Ihr Projekt reservieren können.
|
Statische BYOIP-IP-Adressen (global) | Die Anzahl der globalen externen IP-Adressen unter Bring your own IP , die Sie in Ihrem Projekt erstellen können.
|
Öffentliche Beworbene Präfixe | Die Anzahl der öffentlich beworbenen Präfixe (PAPs), die Sie in Ihrem Projekt erstellen können.
|
Erstellanfragen für öffentliche beworbene V2-Präfixe pro Minute | Die Anzahl der Erstellungsanfragen für regional öffentlich beworbene Präfixe, die Sie pro Minute stellen können. Dieses Kontingent gilt sowohl für öffentlich beworbene Präfixe der Version 1 als auch der Version 2.
|
Löschanfragen für öffentliche beworbene V2-Präfixe pro Minute | Die Anzahl der Löschanfragen für regional öffentlich beworbene Präfixe, die Sie pro Minute stellen können. Dieses Kontingent gilt sowohl für öffentlich beworbene Präfixe der Version 1 als auch der Version 2.
|
Ankündigungsanfragen für öffentliche beworbene V2-Präfixe pro Minute | Die Anzahl der Ankündigungsanfragen, die Sie pro Minute für regionale öffentlich beworbene Präfixe stellen können.
|
Regionale öffentliche delegierte Präfixe | Die Anzahl der regionalen öffentlich delegierten Präfixe (PDPs), die Sie pro Region erstellen können.
|
Globale öffentliche delegierte Präfixe | Die Anzahl der globalen öffentlich delegierten Präfixe, die Sie erstellen können.
|
Erstellanfragen für regionale öffentlich delegierte Präfixe pro Minute pro Region | Die Anzahl der Erstellanfragen für regionale öffentlich delegierte Präfixe, die Sie pro Minute und Region stellen können.
|
Regionale öffentliche delegierte Präfixe - Löschanfragen pro Minute und Region | Die Anzahl der Löschanfragen für regionale öffentlich delegierte Präfixe, die Sie pro Minute und Region stellen können.
|
Ankündigungsanfragen für regionale öffentlich delegierte Präfixe pro Minute pro Region | Die Anzahl der Ankündigungsanfragen, die Sie pro Minute und Region für regionale öffentlich delegierte Präfixe stellen können. Dieses Kontingent gilt nicht für Widerrufungs-Anfragen.
|
Öffentlich delegiertes Präfix mit variabler Präfixlänge | Die Anzahl der regionalen öffentlich delegierten IPv6-Präfixe, die Sie pro Projekt und Region erstellen können.
|
Private Service Connect | |
Interne PSC-LB-Weiterleitungsregeln | Die maximale Anzahl von Private Service Connect-Endpunkten (Weiterleitungsregeln), die ein Dienstnutzer erstellen kann, um eine Verbindung zu Erstellerdiensten herzustellen. Dieses Kontingent gilt pro Region und Projekt. Kontingentname: |
Anzahl der regionalen Endpunkte pro Projekt und Region |
Die maximale Anzahl von Private Service Connect-Endpunkten, die ein Dienstnutzer erstellen kann, um eine Verbindung zu regionalen Endpunkten herzustellen. Dieses Kontingent gilt pro Region und Projekt. Kontingentname: |
Dienstanhänge | Die maximale Anzahl von Private Service Connect-Dienstanhängen, die ein Dienstersteller erstellen kann. Dieses Kontingent gilt pro Region und Projekt. Kontingentname: |
Netzwerkanhänge | Die maximale Anzahl von Netzwerkanhängen, die ein Private Service Connect-Nutzer erstellen kann. Dieses Kontingent gilt pro Region und Projekt. Kontingentname: |
Richtlinien für Dienstverbindungen pro Projekt und Region | Die maximale Anzahl von Richtlinien für Dienstverbindungen, die ein Dienstnutzer erstellen kann. Dieses Kontingent gilt pro Region und Projekt. Kontingentname: |
Dienstverbindungskarten pro Projekt und Region | Die maximale Anzahl von Richtlinien für Dienstverbindungen, die ein Dienstersteller erstellen kann. Dieses Kontingent gilt pro Region und Projekt. Kontingentname: |
Pro Netzwerk
In dieser Tabelle sind wichtige Netzwerkkontingente aufgeführt. Informationen zu anderen Kontingenten finden Sie in der Google Cloud Console auf der Seite Kontingente.
Informationen zum Monitoring der verfügbaren Messwerte mit Cloud Monitoring finden Sie unter Kontingentmesswerte verwenden. Für jedes Kontingent gibt es ein Limit und einen Nutzungswert.
Ein Kontingent pro Netzwerk hat in der Regel ein entsprechendes Kontingent pro Peering-Gruppe, das bei Verwendung von VPC-Netzwerk-Peering gilt. Für Peering-Gruppenkontingente gilt das Konzept des effektiven Limits.
Kontingent | Beschreibung |
---|---|
Instanzen und Alias-IP-Bereiche | |
Instanzen pro VPC-Netzwerk | Die Gesamtzahl der VM-Instanzen mit einer Netzwerkschnittstelle (NIC) im VPC-Netzwerk. Kontingentname: Verfügbare Messwerte:
|
Instanzen pro Peering-Gruppe | Aus Sicht eines VPC-Netzwerks die Gesamtzahl der VM-Instanzen mit einer Netzwerkschnittstelle (NIC, Network Interface) entweder im VPC-Netzwerk selbst oder in einem der direkt verbundenen Peers. Kontingentname: Verfügbare Messwerte:
|
IP-Aliasse pro VPC-Netzwerk | Die Gesamtzahl der Alias-IP-Bereiche, die von Netzwerkschnittstellen (NICs) von VM-Instanzen im VPC-Netzwerk verwendet werden. Dieses Kontingent zählt die Anzahl der Alias-IP-Bereiche ohne Berücksichtigung der Größe der einzelnen Bereiche (Subnetzmaske). Zusätzlich zu diesem Kontingent gibt es für die Anzahl der Alias-IP-Bereiche je Netzwerkschnittstelle ein Limit pro VM. Kontingentname: Verfügbare Messwerte:
|
IP-Aliasse pro Peering-Gruppe | Aus Sicht eines VPC-Netzwerks die Gesamtzahl der Alias-IP-Bereiche, die von NICs von VM-Instanzen verwendet werden, die sich lokal im VPC-Netzwerk und in direkt verbundenen Peers befinden. Dieses Kontingent zählt die Anzahl der Alias-IP-Bereiche ohne Berücksichtigung der Größe der einzelnen Bereiche (Subnetzmaske). Zusätzlich zu diesem Kontingent gibt es für die Anzahl der Alias-IP-Bereiche je Netzwerkschnittstelle ein Limit pro VM. Kontingentname: Verfügbare Messwerte:
|
Subnetz-IP-Adressbereiche | |
Subnetzwerkbereiche pro VPC-Netzwerk | Die Gesamtzahl der Subnetz-IP-Adressbereiche, die von Subnetzen im VPC-Netzwerk verwendet werden. Umfasst primäre IPv4-Adressbereiche, sekundäre IPv4-Adressbereiche und IPv6-Adressbereiche. Kontingentname: Verfügbare Messwerte:
|
Subnetzwerkbereiche pro Peering-Gruppe | Aus Sicht eines VPC-Netzwerks die Gesamtzahl der IP-Adressbereiche von Subnetzen, die von Subnetzen verwendet werden, die sich lokal im VPC-Netzwerk und in direkt verbundenen Peers befinden. Umfasst primäre IPv4-Adressbereiche, sekundäre IPv4-Adressbereiche und IPv6-Adressbereiche. Kontingentname: Verfügbare Messwerte:
|
VPC-Netzwerk-Peering | |
Peerings pro VPC-Netzwerk | Die Gesamtzahl der VPC-Netzwerke, zu denen über VPC-Netzwerk-Peering eine Verbindung hergestellt werden kann. Kontingentname: Verfügbare Messwerte:
|
Statische und dynamische Routen | |
Statische Routen pro Netzwerk | Die Gesamtzahl der statischen Routen, die für das VPC-Netzwerk lokal sind, aus Sicht aller Regionen des VPC-Netzwerks. Dieses Kontingent gilt für die Gesamtzahl der statischen IPv4- und IPv6-Routen. Kontingentname: Verfügbare Messwerte:
|
Statische Routen pro Peering-Gruppe | Die Gesamtzahl der statischen Routen, die für das VPC-Netzwerk und in dessen direkt verbundenen Peers lokal sind, aus Sicht aller Regionen des VPC-Netzwerks. Dieses Kontingent gilt für die Gesamtzahl der statischen IPv4- und IPv6-Routen. Kontingentname: Verfügbare Messwerte:
|
Dynamische Routen pro Region und Peering-Gruppe | Aus Sicht der einzelnen Regionen in einem VPC-Netzwerk, die Gesamtzahl der dynamischen Routen, die für das VPC-Netzwerk und in dessen direkt verbundenen Peers lokal sind. Dieses Kontingent gilt für die Gesamtzahl der dynamischen IPv4- und IPv6-Routen. Kontingentname: Verfügbare Messwerte:
Wenn die Anzahl der dynamischen Routen dieses Limit überschreitet, passt Google Cloud den Import dynamischer Routen nach den folgenden Regeln an:
|
Load-Balancer und Protokollweiterleitungsregeln Weitere Informationen finden Sie unter Weiterleitungsregeln in der Dokumentation zu Load-Balancing-Kontingenten. | |
Private Service Connect | |
PSC-Google APIs-Weiterleitungsregeln pro VPC-Netzwerk | Die maximale Anzahl von Private Service Connect-Endpunkten (Weiterleitungsregeln), die für den Zugriff auf Google APIs verwendet werden können. Dieses Kontingent gilt für die Gesamtzahl der Weiterleitungsregeln, die in allen Regionen für den Zugriff auf Google APIs verwendet werden. Dieses Kontingent kann nicht erhöht werden. Hier erhalten Sie weitere Informationen darüber, wie viele globale Internetadressen Sie erstellen können. Kontingentname: Verfügbare Messwerte:
|
Von PSC propagierte Verbindungen pro VPC-Netzwerk |
Die maximale Anzahl von weitergeleiteten Private Service Connect-Verbindungen, die im VPC-Netzwerk eines Nutzers vorhanden sein können. Dieses Kontingent kann nicht erhöht werden.
Kontingentname: Verfügbare Messwerte:
|
PSC-ILB-Nutzerweiterleitungsregeln pro Ersteller-VPC-Netzwerk |
Die maximale Anzahl von Private Service Connect-Endpunkten und weitergeleiteten Verbindungen , die auf ein VPC-Netzwerk eines Diensterstellers zugreifen können. Dieses Kontingent gilt für die Gesamtzahl der Endpunkte und weitergegebenen Verbindungen , die auf Dienste in allen Regionen des VPC-Netzwerks des Diensterstellers zugreifen. Endpunkte tragen bis zu ihrem Löschen zu diesem Kontingent bei, auch wenn der zugehörige Dienstanhang gelöscht oder so konfiguriert ist, dass die Verbindung abgelehnt wird. Fortgeleitete Verbindungen tragen zu diesem Kontingent bei, bis der zugehörige Endpunkt gelöscht wird, auch wenn die Verbindungsweiterleitung am Hub deaktiviert ist oder die Speiche der fortgeleiteten Verbindung gelöscht wird. Kontingentname: Verfügbare Messwerte:
|
Eingestellte Kontingente
Google Cloud erzwingt folgende Kontingente nicht mehr:
Subnetzwerke: Als Ersatz dient das Kontingent für Subnetzwerkbereiche pro VPC-Netzwerk.
Routen: Als Ersatz dient das Kontingent für statische Routen pro Netzwerk.
Limits
Sofern nicht ausdrücklich angegeben können Limits normalerweise nicht erhöht werden.
Limits für freigegebene VPCs
Die Anzahl der Dienstprojekte, die an ein Hostprojekt angehängt werden können, ist ein konfigurierbares Projektkontingent. Zusätzlich gelten die folgenden Limits für freigegebene VPCs.
Posten | Limit | Hinweise |
---|---|---|
Anzahl der freigegebenen VPC-Hostprojekte in einer Organisation | 100 | Um eine Aktualisierung dieses Limits anzufordern, reichen Sie eine Supportanfrage ein. |
Anzahl der Hostprojekte, an die ein Dienstprojekt angehängt werden kann | 1 | Dieses Limit kann nicht erhöht werden. |
Pro Netzwerk
Die folgenden Limits gelten für VPC-Netzwerke. Diese Limits werden intern mithilfe von Kontingenten durchgesetzt. Wenn Limits pro Netzwerk überschritten werden, werden Fehler vom Typ QUOTA_EXCEEDED
mit internen Kontingentnamen angezeigt.
Posten | Limit | Hinweise |
---|---|---|
Subnetz-IP-Bereiche | ||
Primäre IP-Bereiche pro Subnetz | 1 | Subnetze müssen genau einen primären IPv4-Bereich (CIDR-Block) haben. Dieses Limit kann nicht erhöht werden. Weitere Informationen finden Sie unter IPv4-Subnetzbereiche. |
Maximale Anzahl von sekundären IP-Bereichen pro Subnetz | 170 | Subnetze können optional sekundäre IPv4-Adressbereiche haben. Dieses Limit kann nicht erhöht werden. Weitere Informationen finden Sie unter IPv4-Subnetzbereiche. |
Routen | ||
Maximale Anzahl von Netzwerk-Tags pro Route | 256 | Die maximale Anzahl von Netzwerk-Tags, die Sie einer statischen Route zuordnen können. Dieses Limit kann nicht erhöht werden. |
Limits für IP-Adressen
Posten | Limit | Hinweise |
---|---|---|
Öffentlich delegierte Präfixe pro öffentlich beworbenem Präfix | 10 | Die Anzahl der öffentlich delegierten Präfixe (PDPs), die Sie mit einem öffentlich beworbenen Präfix (PAP) erstellen können. |
Pro Instanz
Die folgenden Limits gelten für VM-Instanzen. Wenn nichts anderes angegeben ist, können diese Limits nicht erhöht werden. Informationen zu Kontingenten für VMs finden Sie unter Ressourcenkontingente.
Posten | Limit | Hinweise |
---|---|---|
Maximale Übertragungseinheit (MTU) | Zwischen 1.300 Byte und 8.896 Byte (einschließlich). Gängige Werte sind 1.460 Byte (Standard), 1.500 Byte (Ethernet-Standard) und 8.896 Byte (Jumbo-Frames). |
Weitere Informationen finden Sie unter Maximale Übertragungseinheit. |
Maximale Anzahl von Netzwerkschnittstellen | 8 | Netzwerkschnittstellen werden bei der Instanzerstellung definiert und können später nicht durch Bearbeitung der Instanz geändert werden. |
Maximale Anzahl von Alias-IP-Bereichen pro Netzwerkschnittstelle | 150 | Die Anzahl der Alias-IP-Bereiche, die Sie einer Netzwerkschnittstelle zuweisen können, solange das Kontingent für die Gesamtzahl von zugewiesenen Alias-IP-Bereichen im VPC-Netzwerk nicht überschritten wird. Google Cloud berücksichtigt die Größe der Netzmaske des Alias-IP-Bereichs nicht. Beispiel: Ein individueller |
Netzwerkschnittstellen pro VPC-Netzwerk | 1 | Jede Netzwerkschnittstelle muss mit einem eindeutigen VPC-Netzwerk verbunden sein. Eine Instanz kann nur eine Netzwerkschnittstelle in einem bestimmten VPC-Netzwerk haben. |
Maximale Dauer inaktiver TCP-Verbindungen | 10 Minuten | Inaktive TCP-Verbindungen in VPC-Netzwerken werden nach zehn Minuten automatisch beendet. Dieses Limit kann nicht geändert werden. Mithilfe von TCP-Keepalives können Sie jedoch verhindern, dass Verbindungen zu Instanzen inaktiv werden. Weitere Informationen finden Sie unter Tipps und Fehlerbehebung für Compute Engine. |
Maximale Rate für ausgehenden Traffic zu einem internen IP-Adressziel | Dieser Wert ist vom Maschinentyp der VM abhängig. | Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Ausgehender Traffic zu internen IP-Adresszielen sowie unter Maschinentypen. |
Maximale Rate für ausgehenden Traffic zu einem externen IP-Adressziel | Alle Datenflüsse: ca. 7 Gbit/s (Gigabit pro Sekunde) oder 25 Gbit/s mit VM-1-Netzwerkleistung Einzelner Datenfluss: 3 Gbit/s (kontinuierlich) |
Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Ausgehender Traffic zu externen IP-Adresszielen. |
Maximale Rate für eingehenden Traffic zu einem internen IP-Adressziel | Kein künstliches Limit | Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Eingehender Traffic zu internen IP-Adresszielen. |
Maximale Rate für eingehenden Traffic zu einem externen IP-Adressziel | Maximal 30 Gbit/s Maximal 1.800.000 Pakete pro Sekunde |
Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Eingehender Traffic zu externen IP-Adresszielen. |
Beschränkungen beim Logging von Verbindungen
Die maximale Anzahl von Verbindungen, die pro VM-Instanz protokolliert werden können, hängt vom Maschinentyp ab. Die Beschränkungen beim Logging von Verbindungen werden als die maximale Anzahl von Verbindungen angegeben, die in einem Intervall von fünf Sekunden erfasst werden kann.
Maschinentyp der Instanz | Maximale Anzahl der in einem 5-Sekunden-Intervall protokollierten Verbindungen |
---|---|
f1-micro | 100 Verbindungen |
g1-small | 250 Verbindungen |
Maschinentypen mit 1–8 vCPUs | 500 Verbindungen pro vCPU |
Maschinentypen mit mehr als 8 vCPUs | 4.000 (500×8) Verbindungen |
Hybridkonnektivität
Über die folgenden Links finden Sie Kontingente und Limits für Cloud VPN, Cloud Interconnect und Cloud Router.
- Kontingente und Limits für Cloud VPN
- Kontingente und Limits für Cloud Interconnect
- Kontingente und Limits für Cloud Router
Effektive Limits für Peering-Gruppenkontingente
Für jedes Kontingent pro Peering-Gruppe gilt das Konzept eines effektiven Limits. In diesem Abschnitt wird beschrieben, wie das effektive Limit des Kontingents berechnet wird. Das effektive Limit ist immer größer oder gleich dem Wert des Limits für das Kontingent pro Peering-Gruppe.
Die meisten Kontingente pro Peering-Gruppe haben ein entsprechendes Netzwerkkontingent, z. B. SUBNET_RANGES_PER_PEERING_GROUP
und SUBNET_RANGES_PER_NETWORK
. Die in diesem Abschnitt beschriebene Berechnung des effektiven Limits gilt für alle Kontingente pro Peering-Gruppe, auch für solche, die kein entsprechendes Kontingent pro Netzwerk haben.
Das effektive Limit eines Kontingents pro Peering-Gruppe wird so berechnet:
Schritt 1: Wählen Sie ein VPC-Netzwerk aus. Wenn VPC-Netzwerk-Peering verwendet wird, hat jedes Netzwerk eine eigene Peering-Gruppe. Die Peering-Gruppe eines Netzwerks besteht aus dem VPC-Netzwerk selbst und allen anderen VPC-Netzwerken, die über VPC-Netzwerk-Peering direkt mit ihm verbunden sind. Die Berechnungen des effektiven Limits werden für jedes Kontingent pro Peering-Gruppe auf Netzwerkbasis wiederholt.
Schritt 2: Für das ausgewählte VPC-Netzwerk wird das höhere der folgenden Limits ermittelt:
- Das Limit für das Kontingent pro Peering-Gruppe
- Das Limit für das entsprechende Kontingent pro Netzwerk
Wenn kein entsprechendes Kontingent pro Netzwerk existiert, verwenden Sie das Kontingent pro Peering-Gruppe.
Schritt 3: Erstellen Sie eine Liste mit dem höheren der folgenden beiden Limits pro Peer-Netzwerk:
- Das Limit für das Kontingent pro Peering-Gruppe
- Das Limit für das entsprechende Kontingent pro Netzwerk
Wenn kein entsprechendes Kontingent pro Netzwerk existiert, verwenden Sie das Kontingent pro Peering-Gruppe.
Schritt 4: Aus der in Schritt 3 erstellten Liste wird der niedrigste Wert ermittelt.
Schritt 5. Von den in Schritt 2 und Schritt 4 ermittelten Werten wird der größere genommen. Diese Zahl ist das effektive Limit für das Kontingent pro Peering-Gruppe aus Sicht des ausgewählten VPC-Netzwerk.
Beispiel für effektive Limits
Angenommen, Sie haben die vier VPC-Netzwerke network-a
, network-b
, network-c
und network-d
. Da es vier VPC-Netzwerke gibt, gibt es auch vier Peering-Gruppen, je eine aus der Sicht jedes Netzwerks.
Angenommen, die folgenden Netzwerk-Peering-Verbindungen bestehen:
network-a
ist mitnetwork-b
verbunden undnetwork-b
mitnetwork-a
.network-a
ist mitnetwork-c
verbunden undnetwork-c
mitnetwork-a
.network-c
ist mitnetwork-d
verbunden undnetwork-d
mitnetwork-c
.
Angenommen, die Limits für zwei entsprechende Kontingente sind so festgelegt:
Netzwerk | Limit für INTERNAL_FORWARDING_RULES_PER_PEERING_GROUP |
Limit für INTERNAL_FORWARDING_RULES_PER_NETWORK |
---|---|---|
network-a |
500 | 600 |
network-b |
350 | 300 |
network-c |
300 | 300 |
network-d |
400 | 300 |
Die effektiven Limits für jedes INTERNAL_FORWARDING_RULES_PER_PEERING_GROUP
-Kontingent sind:
Peering-Gruppe für
network-a
– direkte Peers sindnetwork-b
undnetwork-c
.- In
network-a
:max(500,600) = 600
- Liste der Maxima für direkte Peers:
network-b
:max(350,300) = 350
network-c
:max(300,300) = 300
- Minimum der Liste der direkten Peers:
min(350,300) = 300
- Effektives Limit für
INTERNAL_FORWARDING_RULES_PER_PEERING_GROUP
innetwork-a
:max(600,300) = 600
- In
Peering-Gruppe für
network-b
– ein direkter Peer,network-a
.- In
network-b
:max(350,300) = 350
- Liste der Maxima für direkte Peers:
network-a
:max(500,600) = 600
- Minimum der Liste der direkten Peers:
min(600) = 600
- Effektives Limit für
INTERNAL_FORWARDING_RULES_PER_PEERING_GROUP
innetwork-b
:max(350,600) = 600
- In
Peering-Gruppe für
network-c
– direkte Peers sindnetwork-a
undnetwork-d
.- In
network-c
:max(300,300) = 300
- Liste der Maxima für direkte Peers:
network-a
:max(500,600) = 600
network-d
:max(400,300) = 400
- Minimum der Liste der direkten Peers:
min(600,400) = 400
- Effektives Limit für
INTERNAL_FORWARDING_RULES_PER_PEERING_GROUP
innetwork-c
:max(300,400) = 400
- In
Peering-Gruppe für
network-d
– ein direkter Peer,network-c
.- In
network-d
:max(400,300) = 400
- Liste der Maxima für direkte Peers:
network-c
:max(300,300) = 300
- Minimum der Liste der direkten Peers:
min(300) = 300
- Effektives Limit für
INTERNAL_FORWARDING_RULES_PER_PEERING_GROUP
innetwork-d
:max(400,300) = 400
- In
Kontingente verwalten
MitVirtual Private Cloud werden Kontingente für die Ressourcennutzung aus verschiedenen Gründen festgelegt. Kontingente schützen unter anderem die gesamte Google Cloud -Community vor unerwarteten Nutzungsspitzen. Außerdem unterstützen Kontingente Nutzer, die Google Cloud mit der kostenlosen Stufe prüfen, dabei, im Rahmen der Testversion zu verbleiben.
Alle Projekte beginnen mit den gleichen Kontingenten, die Sie ändern können, indem Sie zusätzliche Kontingente anfordern. Einige Kontingente könnten entsprechend Ihrer Nutzung eines Produkts automatisch erhöht werden.
Berechtigungen
Zur Anzeige von Kontingenten oder zur Anforderung von Kontingenterhöhungen benötigen IAM-Hauptkonten (Identity and Access Management) eine der folgenden Rollen:
Aufgabe | Erforderliche Rolle |
---|---|
Kontingente für ein Projekt prüfen | Beispiele:
|
Kontingente ändern, zusätzliche Kontingente anfordern | Beispiele:
|
Kontingent prüfen
Console
- Öffnen Sie in der Google Cloud Console die Seite Kontingente.
- Mit dem Feld Tabelle filtern können Sie nach den zu aktualisierenden Kontingenten suchen. Wenn Sie den Namen des Kontingents nicht kennen, verwenden Sie stattdessen die Links auf dieser Seite.
gcloud
Führen Sie mit der Google Cloud CLI 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 ein Kontingent mit einem gcloud
-Befehl überschreiten, gibt gcloud
eine quota exceeded
-Fehlermeldung aus und liefert den Exit-Code 1
.
Wenn Sie ein Kontingent mit einer API-Anfrage überschreiten, liefert Google Cloud folgenden HTTP-Statuscode: 413 Request Entity Too Large
.
Weitere Kontingente anfordern
Verwenden Sie die Google Cloud Console, um die meisten Kontingente anzupassen. Weitere Informationen finden Sie unter Kontingentanpassung beantragen.
Console
- Öffnen Sie in der Google Cloud Console die Seite Kontingente.
- Wählen Sie auf der Seite Kontingente die Kontingente aus, die Sie ändern möchten.
- Klicken Sie oben auf der Seite auf Kontingente bearbeiten.
- Geben Sie unter Name Ihren Namen ein.
- Optional: Geben Sie unter Telefon eine Telefonnummer ein.
- Senden Sie die Anfrage. Die Bearbeitung von Kontingentanforderungen dauert 24 bis 48 Stunden.
Ressourcenverfügbarkeit
Jedes Kontingent stellt die maximale Anzahl an Ressourcen eines bestimmten Typs dar, die Sie erstellen können, sofern der Ressourcentyp verfügbar ist. Beachten Sie, dass Kontingente die Verfügbarkeit von Ressourcen nicht garantieren. Selbst wenn Sie ein verfügbares Kontingent haben, können Sie keine neue Ressource erstellen, wenn keine verfügbar ist.
Beispiel: Sie haben noch ein ausreichendes Kontingent zum Erstellen einer neuen regionalen, externen IP-Adresse in der Region us-central1
. Dies ist jedoch nicht möglich, wenn in dieser Region keine externen IP-Adressen verfügbar sind. 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 kompletten Region nicht verfügbar sind. Ressourcen innerhalb einer Zone können aber manchmal vorübergehend ausgeschöpft sein, ohne dass sich das auf das Service Level Agreement (SLA) für den Ressourcentyp auswirkt. Weitere Informationen finden Sie im entsprechenden SLA für die Ressource.