Ressourcenkontingente

Compute Engine legt aus verschiedenen Gründen Kontingente für die Ressourcennutzung fest. Diese schützen unter anderem die gesamte Google Cloud-Community vor unerwarteten Auslastungsspitzen. Google Cloud bietet außerdem kostenlose Testkontingente, die einen eingeschränkten Zugriff für Projekte bieten, die zum Kennenlernen von Google Cloud im Rahmen einer kostenlosen Testversion dienen.

Es gelten nicht für alle Projekte dieselben Kontingente. Wenn Sie Google Cloud mit der Zeit stärker nutzen, können sich Ihre Kontingente entsprechend erhöhen. Falls Sie eine deutlich stärkere Auslastung erwarten, können Sie auf der Seite Kontingente der Cloud Console eine Anpassung Ihres Kontingents anfordern.

Berechtigungen zum Prüfen und Bearbeiten von Kontingenten

Sie benötigen die Berechtigung serviceusage.quotas.get, um Ihre Kontingente aufzurufen.
Sie benötigen die Berechtigung serviceusage.quotas.update, um Ihre Kontingente zu ändern.
Sie ist standardmäßig in den vordefinierten einfachen Rollen Inhaber, Bearbeiter und Kontingentadministrator enthalten.

Kontingent prüfen

Jedes Projekt hat ein anderes Kontingent. Sie können das Kontingent eines Projekts auf der Seite Kontingente in der Google Cloud Console überprüfen.

Um projektweite Kontingente mit dem gcloud-Befehlszeilentool zu prüfen, führen Sie folgenden Befehl aus:

gcloud compute project-info describe --project PROJECT_ID

Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID:

In den Ergebnissen sind keine Kontingente pro Region aufgeführt. Die Kontingente pro Region erhalten Sie mit dem folgenden Befehl:

gcloud compute regions describe REGION

Ersetzen Sie REGION durch den Namen der Region, für die Sie eine Liste der Kontingentinformationen benötigen.

Höheres Kontingent anfordern

Auf der Seite Kontingente in der Cloud Console können Sie höhere oder niedrigere Kontingente anfordern. Für die Anforderung einer Kontingenterhöhung fallen keine Kosten an. Ihre Kosten erhöhen sich nur dann, wenn Sie mehr Ressourcen verwenden.

  1. Rufen Sie in der Google Cloud Console auf der Seite IAM & Verwaltung die Option Kontingente auf.

    Kontingente aufrufen

Am einfachsten können Sie Ihre Kontingente mithilfe der Filtertabelle aufrufen.

  1. Öffnen Sie die Filtertabelle und wählen Sie Limitname: aus, um nach dem Kontingent zu suchen, das Sie anpassen möchten.
  2. Wählen Sie den Dienst aus, für den Sie Ihr Kontingent anpassen möchten.
  3. Treffen Sie Ihre Auswahl aus den Drop-down-Optionen.
  4. Bearbeiten Sie Ihr Kontingentlimit.
  5. Klicken Sie auf SPEICHERN.

Anfragen zum Verringern des Kontingents werden standardmäßig abgelehnt. Sollten Sie Ihr Kontingent verringern wollen, antworten Sie bitte auf die E-Mail des Supports und erklären Sie Ihre Anforderungen. Ein Supportmitarbeiter wird innerhalb von 48 Stunden auf Ihre Anfrage antworten.

Sie sollten zusätzliche Ressourcen mindestens einige Tage im Voraus planen und anfordern, damit genügend Zeit bleibt, die Anfrage zu bearbeiten.

Kontingente und Ressourcenverfügbarkeit

Ressourcenkontingente legen die maximale Anzahl der Ressourcen eines bestimmten Typs fest, die Sie erstellen können, sofern diese Ressourcen verfügbar sind. Sie garantieren jedoch nicht, dass jederzeit Ressourcen zur Verfügung stehen. Wenn eine Ressource nicht verfügbar ist oder Ihr Kontingent in der Region erschöpft ist, können Sie keine neuen Ressourcen dieses Typs erstellen. Das gilt auch, wenn Ihr Kontingent in der Region oder für das Projekt noch nicht erschöpft ist. Beispiel: Ihr Kontingent zum Erstellen externer IP-Adressen in us-central1 ist noch nicht aufgebraucht, aber in dieser Region sind keine IP-Adressen mehr verfügbar.

Es kann auch sein, dass Sie ein regionales Kontingent haben, eine Ressource aber in einer bestimmten Zone nicht verfügbar ist. Beispiel: Sie haben in der Region us-central1 ein Kontingent zum Erstellen von VM-Instanzen, können jedoch keine VM-Instanzen in der Zone us-central1-a erstellen, wenn das Kontingent der Zone ausgeschöpft ist. Versuchen Sie in solchen Fällen, dieselbe Ressource in einer anderen Zone zu erstellen, zum Beispiel in us-central1-f. Weitere Informationen zu Ihren Optionen bei erschöpften zonalen Ressourcen finden Sie unter Allgemeine Fehlerbehebung.

Informationen zu Kontingenten

Bei der Planung der Anforderungen von VM-Instanzen gibt es eine Reihe von Kontingenten, die sich auf die Anzahl der erstellten VM-Instanzen auswirken und berücksichtigt werden müssen.

Regionale und globale Kontingente

VM-Kontingente werden auf regionaler Ebene verwaltet. Die Kontingente für VM-Instanzen, Instanzgruppen, CPUs und Festplatten können unabhängig von der Zone von jeder beliebigen VM in der Region genutzt werden. Das CPU-Kontingent ist beispielsweise ein regionales Kontingent, deshalb gilt für jede Region ein anderes Limit und eine andere Nutzungsanzahl. Sie benötigen ein Kontingent für mindestens 16 CPUs in us-central1, um eine Instanz vom Typ n2-standard-16 in einer beliebigen Zone der Region us-central1 zu starten.

Netzwerk- und Load-Balancing-Kontingente werden benötigt, um Firewalls, Load-Balancer, Netzwerke und VPNs zu erstellen. Dies sind globale Kontingente, die nicht von einer Region abhängig sind. Ein globales Kontingent kann von jeder Region genutzt werden. Beispielsweise verbrauchen genutzte und statische externe IP-Adressen, die Load-Balancern und HTTP(S)-Proxys zugewiesen sind, globale Kontingente.

CPU-Kontingent

Das CPU-Kontingent bezieht sich auf die Gesamtzahl der virtuellen CPUs in Ihren VM-Instanzen in einer Region. CPU-Kontingente gelten für ausgeführte und reservierte Instanzen. Sowohl vordefinierte Instanzen als auch Instanzen auf Abruf nutzen dieses Kontingent.

Zum Schutz der Compute Engine-Systeme und anderer Nutzer haben einige neue Konten und Projekte auch ein globales CPUs (All Regions)-Kontingent. Dieses gilt regionenübergreifend und betrifft die Gesamtzahl Ihrer vCPUs in allen Regionen.

Wenn Sie beispielsweise in einer Region (z. B. us-central1) noch 48 vCPUs, aber für das Kontingent CPUs (All Regions) nur 32 vCPUs haben, können Sie in der Region us-central1 trotz des verbleibenden Kontingents nur 32 vCPUs starten. Das liegt daran, dass das Kontingent CPU (All Regions) ausgeschöpft wurde. Sie müssen vorhandene Instanzen löschen, um neue Instanzen starten zu können.

E2- und N1-Maschinentypen nutzen gemeinsam einen CPU-Kontingentpool. N2-, N2D-, M1-, M2- und C2-Maschinentypen haben eigene, separate CPU-Kontingentpools. Damit Sie einen Vertrag über einen Rabatt für zugesicherte Nutzung erwerben können, müssen Sie ein Rabattkontingent für zugesicherte Nutzung haben.

Maschinentyp Kontingentpool Name des CPU-Kontingents Name des zugesicherten CPU-Kontingents
E2, N1 Gemeinsam genutzter Pool CPUS Committed_CPUS
N2 Separater Pool N2_CPUS Committed_N2_CPUS
N2D Separater Pool N2D_CPUS Committed_N2D_CPUS
M1 Separater Pool M1_CPUS Committed_MEMORY-OPTIMIZED_CPUS
M2 Separater Pool M2_CPUS Committed_MEMORY-OPTIMIZED_CPUS
C2 Separater Pool C2_CPUS Committed_C2_CPUS
A2 Separater Pool A2_CPUS Committed_A2_CPUS
VMs auf Abruf Gemeinsam genutzter Pool PREEMPTIBLE_CPUS Nicht verfügbar für VMs auf Abruf

GPU-Kontingent

Wie das CPU-Kontingent bezieht sich auch das GPU-Kontingent auf die Gesamtzahl der virtuellen GPUs in allen VM-Instanzen in einer Region. Prüfen Sie auf der Seite Kontingente, ob in Ihrem Projekt ausreichend GPUs zur Verfügung stehen, und fordern Sie ggf. ein höheres Kontingent an. Neue Konten und Projekte haben außerdem ein globales GPU-Kontingent, das für alle Regionen gilt.

Wenn Sie ein GPU-Kontingent anfordern, müssen Sie ein Kontingent für die GPU-Modelle, die Sie in den einzelnen Regionen erstellen möchten, sowie ein zusätzliches globales Kontingent für die Gesamtzahl der GPUs aller Typen in allen Zonen anfordern.

NVIDIA Name des GPU-Kontingents Name des zugesicherten GPU-Kontingents Virtuelle Workstation GPUs auf Abruf GPU auf Abruf für Workstations
K80 NVIDIA_K80_GPUS COMMITTED_NVIDIA_K80_GPUS PREEMPTIBLE_NVIDIA_K80_GPUS
P100 NVIDIA_P100_GPUS COMMITTED_NVIDIA_P100_GPUS NVIDIA_P100_VWS_GPUS PREEMPTIBLE_NVIDIA_P100_GPUS PREEMPTIBLE_NVIDIA_P100_VWS_GPUS
A100 NVIDIA_A100_GPUS COMMITTED_NVIDIA_A100_GPUS N/A PREEMPTIBLE_NVIDIA_A100_GPUS N/A
P4 NVIDIA_P4_GPUS COMMITTED_NVIDIA_P4_GPUS NVIDIA_P4_VWS_GPUS PREEMPTIBLE_NVIDIA_P4_GPUS PREEMPTIBLE_NVIDIA_P4_VWS_GPUS
T4 NVIDIA_T4_GPUS COMMITTED_NVIDIA_T4_GPUS NVIDIA_T4_VWS_GPUS PREEMPTIBLE_NVIDIA_T4_GPUS PREEMPTIBLE_NVIDIA_T4_VWS_GPUS
V100 NVIDIA_V100_GPUS COMMITTED_NVIDIA_V100_GPUS PREEMPTIBLE_NVIDIA_V100_GPUS

VM-Instanzen

Das Kontingent für VM-Instanzen ist ein regionales Kontingent, mit dem die Anzahl der vorhandenen VM-Instanzen in einer bestimmten Region unabhängig davon eingeschränkt wird, ob die VM ausgeführt wird oder nicht. Dieses Kontingent wird in der Google Cloud Console auf der Seite „Kontingente“ angezeigt. Es wird von Compute Engine automatisch auf das Zehnfache Ihres regulären CPU-Kontingents festgelegt. Sie brauchen dieses Kontingent nicht anzufordern. Wenn Sie ein Kontingent für weitere VM-Instanzen benötigen, sollten Sie zusätzliche CPUs anfordern. Mehr CPUs erhöhen auch das Kontingent der VM-Instanz. Das Kontingent wird auf ausgeführte und nicht ausgeführte sowie auf normale Instanzen und Instanzen auf Abruf angerechnet.

  1. Rufen Sie in der Google Cloud Console auf der Seite IAM & Verwaltung die Option Kontingente auf.

    Kontingente aufrufen

  2. Öffnen Sie die Filtertabelle und wählen Sie Dienst aus.

  3. Wählen Sie Compute Engine API aus.

  4. Wählen Sie Limitname: VM-Instanzen aus.

  5. Klicken Sie auf Alle Kontingente, um eine Liste Ihrer Kontingente für die VM-Instanz nach Region aufzurufen. Ihre Kontingente für die einzelnen Regionen sind absteigend aufgeführt.

  6. Klicken Sie auf das Kästchen der Region, deren Kontingent Sie ändern möchten.

  7. Klicken Sie auf Kontingente bearbeiten.

  8. Füllen Sie das Formular aus.

  9. Klicken Sie auf Anfrage senden.

Kontingente für Ressourcen auf Abruf

Sie müssen in Ihrem Projekt für die jeweilige Ressource ein Kontingent haben, um CPUs auf Abruf oder an VM-Instanzen auf Abruf angehängte GPUs bzw. lokale SSDs zu verwenden.

Sie können für Preemptible CPUs, Preemptible GPUs oder Preemptible Local SSDs (GB) spezielle Kontingente auf Abruf anfordern. Wenn für Ihr Projekt kein Kontingent auf Abruf vorhanden ist, können Sie Ressourcen auf Abruf aber weiterhin im Rahmen des regulären Kontingents starten.

Nachdem Ihnen von Compute Engine ein Kontingent auf Abruf in einer Region zugeteilt wurde, werden alle Instanzen auf Abruf automatisch auf das Auf-Abruf-Kontingent angerechnet.

Laufwerkskontingente

Die folgenden Kontingente für nichtflüchtigen Speicher und lokale SSDs gelten je Region:

  • Local SSD (GB): Kombinierte Gesamtgröße der lokalen SSD-Partitionen, die in einer Region an VMs angehängt werden können. Eine lokale SSD ist ein schnelles, flüchtiges Laufwerk, das für Scratch-Jobs, den lokalen Cache oder Verarbeitungsjobs mit einer hohen Fehlertoleranz genutzt werden kann, da der Inhalt dieses Laufwerks nach dem Neustart einer VM-Instanz nicht mehr verfügbar ist. Lokale SSD-Partitionen werden in Schritten von 375 GB verkauft. Es können bis zu 24 lokale SSD-Partitionen an eine VM angehängt werden. Im gcloud-Tool und in der API wird die Gesamtgröße als LOCAL_SSD_TOTAL_GB angegeben.

  • Persistent disk standard (GB): Gesamtgröße der nichtflüchtigen Standardspeicher, die in einer Region erstellt werden können. Wie unter Leistung von nichtflüchtigen Speichern und lokalen SSDs optimieren beschrieben, bieten nichtflüchtige Standardspeicher weniger IOPS und Durchsatz als nichtflüchtige SSD-Speicher oder lokale SSDs. Sie können jedoch kostengünstig als große langlebige Laufwerke für Speicher, als Bootlaufwerke und für serielle Schreibvorgänge wie Logs eingesetzt werden. Nichtflüchtige Standardspeicher sind langlebig und können in unbegrenzter Zahl an eine VM in derselben Zone angehängt werden. Im gcloud-Tool und in der API wird die Gesamtgröße als DISKS_TOTAL_GB angegeben. Dieses Kontingent gilt auch für regionale nichtflüchtige Standardspeicher. Regionale Laufwerke verbrauchen jedoch pro GB doppelt so viel vom Kontingent, weil sie innerhalb einer Region in zwei Zonen repliziert werden.

  • Persistent disk SSD (GB): Kombinierte Gesamtgröße der Partitionen SSD-gestützter nichtflüchtiger Speicher, die in einer Region erstellt werden können. SSD-gestützte nichtflüchtige Speicher umfassen mehrere Replikate und bieten mehr IOPS und einen höheren Durchsatz als nichtflüchtige Standardspeicher, wie unter Blockspeicherleistung beschrieben. SSD-gestützte nichtflüchtige Speicher stehen in unbegrenzter Zahl zum Anhängen an eine VM innerhalb derselben Zone zur Verfügung. Im gcloud-Tool und in der API wird die Gesamtgröße als SSD_TOTAL_GB angegeben. Dieses Kontingent ist vom lokalen SSD-Kontingent getrennt. Dieses Kontingent gilt für die unten aufgeführten Speichertypen. Regionale nichtflüchtige Speicher verbrauchen pro GB doppelt so viel vom Kontingent, weil sie innerhalb einer Region in zwei Zonen repliziert werden.

    • Zonaler und regionaler nichtflüchtiger SSD-Speicher
    • Abgestimmter zonaler und regionaler nichtflüchtiger Speicher

Externe IP-Adressen

Sie benötigen eine ausreichende Anzahl an externen IP-Adressen für jede VM, die über das öffentliche Internet erreichbar sein muss. Das regionale IP-Kontingent gilt für die Zuweisung von IPv4-Adressen zu VMs in dieser Region. Das globale IP-Kontingent gilt für die Zuweisung von IPv4-Adressen an globale Netzwerkressourcen wie Load-Balancer. Google Cloud bietet passend zu Ihren Anforderungen verschiedene Arten von IP-Adressen an. Weitere Informationen zu Preisen finden Sie unter Preise für externe IP-Adressen. Ausführliche Informationen zu Kontingenten finden Sie unter Kontingente und Limits.

  • Verwendete externe IP-Adressen: Diese umfassen sitzungsspezifische und statische IP-Adressen, die aktuell von einer Ressource genutzt werden.
  • Statische externe IP-Adressen: Externe IP-Adressen, die für Ihre Ressourcen reserviert wurden und auch nach dem Neustart einer Maschine beibehalten werden. Sie können diese Adressen bei DNS- und Domainanbietern registrieren, um eine nutzerfreundliche Adresse zu erhalten, beispielsweise www.example-site.com.
  • Statische interne IP-Adressen: Statische interne IP-Adressen bieten die Möglichkeit, interne IP-Adressen aus dem im Subnetz konfigurierten internen IP-Bereich zu reservieren. Diesen reservierten internen Adressen können Sie nach Bedarf Ressourcen zuordnen.

Instanzgruppen

Zum Verwenden von Instanzgruppen benötigen Sie verfügbares Kontingent für alle Ressourcen, die die Gruppe nutzen wird (beispielsweise CPU-Kontingent), sowie verfügbares Kontingent für die Gruppenressource selbst. Je nach Gruppentyp gelten folgende Kontingente für die Gruppenressourcen:

Diensttyp Dienstkontingent
Regional (mehrere Zonen) verwaltete Instanzgruppe Regional instance group managers
Zonal (einzelne Zone) verwaltete Instanzgruppe Beide:
  • Instance group managers
  • Instance groups
Nicht verwaltete (einzelne Zone) Instanzgruppe Instance groups
Regionales (mehrere Zonen) Autoscaling Regional autoscalers
Zonales (einzelne Zone) Autoscaling Autoscalers