Kontingente und Limits

In diesem Dokument sind die Kontingente und Systemlimits für Service Directory aufgeführt.

  • Kontingente haben Standardwerte, aber Sie können in der Regel Anpassungen anfordern.
  • Systemlimits sind feste Werte, die nicht geändert werden können.

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

Google Cloud nutzt Kontingente, um für Fairness zu sorgen und Spitzen bei der Ressourcennutzung und ‑verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einer Ressource vonGoogle Cloud Ihr Projekt von Google Cloud nutzen kann. 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. Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community der Nutzer vonGoogle Cloud schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Ressourcen von Google Cloud .

Das Cloud-Kontingentsystem tut 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 auszuführen versuchen, schlägt dann fehl.

Kontingente gelten in der Regel auf der Ebene des Projekts von Google Cloud . Die Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf das verfügbare Kontingent in einem anderen Projekt. Innerhalb eines Projekts von Google Cloud werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.

Weitere Informationen finden Sie in der Cloud-Kontingente-Übersicht.

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

Kontingente

Für Service Directory gelten folgende Kontingente:

  • Namespaces pro Projekt und Region
  • Services pro Namespace
  • Endpunkte pro Service
  • Registrierungsanfragen pro Minute und Region
  • Suchanfragen pro Minute und Region

Auf der Seite „Kontingente“ können Sie Ihre vorhandenen Kontingente und die Nutzung sehen.

Limits

Allgemeine Beschränkungen bei Service Directory:

  • Es gibt zwar keinen Systemstatus bzw. keine Systemdiagnosen für Endpunkte. Dafür gibt allerdings es zwei Alternativen:
    • Sie können interne Load-Balancer für integrierte Systemdiagnosen nutzen und den Load-Balancer bei Service Directory registrieren.
    • Sie können den Systemstatus eines individuellen Endpunkts als Endpunktanmerkungen in Service Directory speichern.

Limits für die Cloud DNS-Integration:

  • Die Cloud DNS-Integration funktioniert nur für Endpunkte in Form gültiger IPv4- oder IPv6-Adressen. Endpunkte, die registriert sind, aber keine gültige IP-Adresse haben, werden von DNS-Anfragen ignoriert.
  • SRV-Einträge können nicht angepasst werden. Symbolischer Dienst, Protokoll, TTL, Gewichtung und Priorität werden von Service Directory verwaltet.
  • Dienst- und Endpunktanmerkungen werden bei DNS-Anfragen nicht bereitgestellt. Wenn Sie für Ihren Dienst benutzerdefinierte Anmerkungen benötigen, sollten Sie dafür die HTTP-Unterstützung in Service Directory verwenden.
  • Sie können keine Ressourceneinträge in die Service Directory-Zone aufnehmen. Nur intern von vorhandenen Service Directory-Endpunkten erzeugte Ressourceneinträge sind zulässig.

Kontingente verwalten

MitService Directory 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:
  • Project Owner (roles/owner)
  • Project Editor (roles/editor)
  • Quota Administrator (roles/servicemanagement.quotaAdmin)
  • Eine benutzerdefinierte Rolle mit der Berechtigung serviceusage.quotas.update

Kontingent prüfen

Console

  1. Rufen Sie in der Google Cloud Console die Seite Kontingente auf.

    Kontingente aufrufen

  2. 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 mit einer API-Anfrage ein Kontingent überschreiten,gibt Google Cloud den folgenden HTTP-Statuscode zurück: 413 Request Entity Too Large. Google Cloud

Weitere Kontingente anfordern

Verwenden Sie die Google Cloud Console, um die meisten Kontingente anzupassen. Weitere Informationen finden Sie unter Kontingentanpassung beantragen.

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 einer bestimmten Region. 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.