Ressourcenkontingente

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

Es gelten nicht für alle Projekte dieselben Kontingente. Wenn Sie die Google Cloud Platform stärker nutzen, kann Ihr Kontingent auch erweitert werden. Wenn Sie eine deutlich stärkere Auslastung erwarten, können Sie proaktiv auf der Seite Kontingente der GCP Console eine Anpassung Ihres Kontingents anfordern.

Kontingent prüfen

Das verfügbare Kontingent für Ressourcen in Ihrem Projekt können Sie auf der Seite Kontingente in der Google Cloud Platform Console überprüfen.

Wenn Sie das gcloud-Befehlszeilentool verwenden, führen Sie den folgenden Befehl aus, um projektweite Kontingente abzurufen: Ersetzen Sie dabei myproject durch Ihre Projekt-ID:

gcloud compute project-info describe --project myproject

Bitte beachten Sie, dass hierdurch nicht die Kontingente pro Region aufgelistet werden. Die Kontingente pro Region erhalten Sie mit dem folgendem Befehl:

gcloud compute regions describe [REGION]

Ersetzen Sie [REGION] durch die Region, über die Sie Kontingentinformationen abrufen möchten.

Ein höheres Kontingent anfordern

Auf der Seite Kontingente in der GCP Console können Sie höhere oder niedrigere Kontingente anfordern. Es fallen keine Gebühren für die Anforderung eines höheren Kontingents an. Ihre Kosten erhöhen sich nur dann, wenn Sie mehr Ressourcen verwenden.

Berechtigungen zum Bearbeiten von Kontingenten

Zum Bearbeiten Ihrer Kontingente benötigen Sie die Berechtigung serviceusage.quotas.update. Diese ist standardmäßig in den vordefinierten Rollen Inhaber, Bearbeiter und Kontingentadministrator enthalten.

Änderung des Kontingents anfordern

  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 Kontingente bearbeiten.
  4. Klicken Sie das Kästchen des Dienstes an, den Sie bearbeiten möchten.
  5. Geben Sie Ihren Namen, Ihre E-Mail-Adresse und Ihre Telefonnummer ein und klicken Sie auf Weiter.
  6. Geben Sie Ihre Anfrage zum Erhöhen des Kontingents ein und klicken Sie auf Weiter.
  7. Senden Sie die Anfrage.
  8. 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 auf Ihre Anfrage antworten.

Sie erhalten innerhalb von 24 bis 48 Stunden vom Compute Engine-Team eine Antwort auf Ihre Anfrage.

Sie sollten zusätzliche Ressourcen mindestens einige Tage im Voraus planen und anfordern, damit genügend Zeit vorhanden ist, um der Anfrage nachzukommen.

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. Kontingente sind allerdings keine Garantie dafür, dass jederzeit Ressourcen zur Verfügung stehen. Wenn eine Ressource nicht verfügbar ist, können Sie keine neuen Ressourcen dieses Typs erstellen, selbst wenn Ihr Kontingent in der Region oder dem Projekt noch nicht erschöpft ist. Beispiel: Ihr Kontingent zum Erstellen neuer externer IP-Adressen in us-central1 ist noch nicht erschöpft, aber in dieser Region sind keine IP-Adressen mehr verfügbar.

Es kann auch vorkommen, dass Sie zwar ein regionales Kontingent haben, aber in einer bestimmten Zone keine Ressource 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 die Zone keine Kapazität mehr hat. Versuchen Sie in solchen Fällen, dieselbe Ressource in einer anderen Zone zu erstellen, zum Beispiel in us-central1-f.

Es kommt nur selten vor, dass eine Ressource auf regionaler Ebene keine Kapazität mehr hat. Weitere Informationen zu den Möglichkeiten, die sich Ihnen in solchen Situationen bieten, finden Sie im Compute Engine SLA.

Grundlegendes zu Kontingenten für VM-Instanzen, CPUs und IP-Adressen

Bei der Planung der Anforderungen von VM-Instanzen gibt es eine Reihe von Kontingenten, die sich darauf auswirken, wie viele VM-Instanzen Sie erstellen können, 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. Um eine n1-standard-16-Instanz in einer beliebigen Zone der Region us-central1 zu starten, benötigen Sie ein Kontingent für mindestens 16 CPUs in us-central1.

Netzwerk- und Lastenausgleichskontingente werden benötigt, um Firewalls, Lastenausgleichsmodule, 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 Lastenausgleichsmodulen und HTTP(S)-Proxys zugewiesen sind, globale Kontingente.

CPUs

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 normale 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 Ihnen beispielsweise 48 vCPUs in einer Region wie us-central1 verbleiben, jedoch nur 32 vCPUs für das CPUs (All Regions)-Kontingent, können Sie nur 32 vCPUs in der Region us-central1 starten, auch wenn es ein verbleibendes Kontingent in der Region gibt. Das liegt daran, dass das CPU (All Regions)-Kontingent ausgeschöpft wurde. Sie müssen vorhandene Instanzen löschen, um neue Instanzen starten zu können.

GPUs

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.

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 VMs ausgeführt werden oder nicht. Dieses Kontingent wird nicht in der Google Cloud Platform Console 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 weitere CPUs anfordern, durch die dieses Kontingent erhöht wird. Das Kontingent wird auf ausgeführte und nicht ausgeführte sowie auf normale Instanzen und Instanzen auf Abruf angerechnet.

Kontingente für Ressourcen auf Abruf

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

Sie können spezielle Kontingente auf Abruf für folgende Auf-Abruf-Ressourcen anfordern: Preemptible CPUs, Preemptible GPUs oder Preemptible Local SSDs (GB). 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.

Festplattenkontingente

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, sitzungsspezifisches Laufwerk, das für Scratch-Jobs, den lokalen Cache oder Verarbeitungsjobs mit einer hohen Fehlertoleranz verwendet werden kann, da dieses Laufwerk nicht für eine Verwendung nach dem Neustart von VM-Instanzen ausgelegt ist. Lokale SSD-Partitionen werden in Schritten von jeweils 375 GB verkauft. Es können bis zu acht lokale SSD-Partitionen an eine VM angehängt werden. Im gcloud-Tool und in der API sind diese 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 sind jedoch kostengünstig als große langlebige Laufwerke für Speicher, als Bootlaufwerke und für serielle Schreibvorgänge wie Logs einzusetzen. 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 dies 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 nichtflüchtiger SSD-Speicher, die in einer Region erstellt werden können. Nichtflüchtige SSD-Speicher umfassen mehrere Replikate und bieten mehr IOPS und einen höheren Durchsatz als nichtflüchtige Standardspeicher, wie unter Leistung von nichtflüchtigen Speichern und lokalen SSDs optimieren beschrieben. Nichtflüchtige SSD-Speicher bieten kostengünstigen langlebigen Speicher für hohe E/A-Anforderungen. Sie stehen in unbegrenzter Zahl zum Anhängen an eine VM innerhalb derselben Zone zur Verfügung. Im gcloud-Tool und in der API wird dies als SSD_TOTAL_GB angegeben. Dieses Kontingent ist unabhängig von lokalen SSDs. Es gilt jedoch auch für regionale nichtflüchtige SSD-Speicher. Regionale Laufwerke verbrauchen allerdings pro GB doppelt so viel vom Kontingent, weil sie innerhalb einer Region in zwei Zonen repliziert werden.

IP-Adressen

Sie benötigen eine ausreichende Anzahl von 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 an VMs in der Region und das globale IP-Kontingent für die Zuweisung von IPv4-Adressen an globale Netzwerkressourcen wie HTTP-Proxys und Load-Balancer. Abhängig von den Anforderungen kommen unterschiedliche Typen von IP-Adressen in Betracht.

  • Verwendete IP-Adressen: Umfassen sitzungsspezifische und statische IP-Adressen, die aktuell von einer Ressource verwendet werden. Verwendete IP-Adressen werden nicht berechnet. Für nicht genutzte statische IP-Adressen werden dagegen Gebühren erhoben.
  • 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 privaten IP-Bereich RFC 1918 zu reservieren. Diesen reservierten internen Adressen können Sie nach Bedarf Ressourcen zuordnen.
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine-Dokumentation