Kontingente und Limits

In diesem Dokument sind die quotas und quotas für Cloud DNS aufgeführt.

Ein Kontingent schränkt ein, wie viel von einer bestimmten gemeinsam genutzten Google Cloud-Ressource Ihr Google Cloud-Projekt nutzen kann, einschließlich Hardware, Software und Netzwerkkomponenten. Daher sind Kontingente Teil eines Systems, das Folgendes tut:

• Ihre Nutzung oder Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen.
• Ihren Verbrauch dieser Ressourcen einschränken, um u. a. für Fairness zu sorgen und Nutzungsspitzen zu reduzieren.
• Konfigurationen verwalten, die automatisch vorgeschriebene Einschränkungen erzwingen.
• Möglichkeit, das Kontingent anzufordern oder zu ändern.

Wenn ein Kontingentlimit überschritten wird, blockiert das System in den meisten Fällen den Zugriff auf die entsprechende Google-Ressource und die Aufgabe, die Sie ausführen möchten, schlägt fehl. In den meisten Fällen gelten Kontingente für jedes Google Cloud-Projekt und werden von allen Anwendungen und IP-Adressen geteilt, die dieses Google Cloud-Projekt verwenden.

Für Cloud DNS-Ressourcen gelten außerdem Limits. Diese Limits stehen nicht im Zusammenhang mit dem Kontingentsystem. Limits können nur geändert werden, wenn etwas anderes angegeben ist.

Kontingente

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

In dieser Tabelle sind wichtige globale Kontingente für Cloud DNS-Ressourcen in den einzelnen Projekten aufgeführt. Weitere Kontingente finden Sie in der Google Cloud Console auf der Seite Kontingente.

Element	Beschreibung
Leselimit für eine Minute für eine Region	Die maximale Anzahl von API-Anfragen, die ein IAM-Nutzer innerhalb eines Zeitraums von einer Minute an die Cloud DNS API senden kann. Dieses Kontingent gilt nur für API-Aufrufe. Für die Verarbeitung von DNS-Abfragen gelten keine Kontingente.
DNSSEC-Schlüssel pro verwalteter Zone	Die maximale Anzahl von DNSSEC-Schlüsseln pro verwalteter Zone.
Verwaltete Zonen pro Projekt	Die maximal zulässige Anzahl von verwalteten Zonen im Projekt.
Verwaltete Zonen pro VPC-Netzwerk	Die maximal zulässige Anzahl von verwalteten Zonen, die an ein VPC-Netzwerk angehängt werden können.
Richtlinienressourcen pro Projekt	Die maximale Anzahl von DNS-Serverrichtlinien pro Projekt.
Richtlinie „Netzwerke pro Antwort“	Die maximal zulässige Anzahl von VPC-Netzwerken pro Antwortrichtlinie.
Elemente pro Routingrichtlinie	Die maximal zulässige Anzahl von Elementen pro Routingrichtlinie.
GKE-Cluster pro verwaltete Zone	Die maximal zulässige Anzahl von Google Kubernetes Engine-Clustern (GKE), an die eine private Zone angehängt werden kann.
GKE-Cluster pro Richtlinie	Die maximal zulässige Anzahl von GKE-Clustern pro Richtlinie.
Verwaltete Zonen pro GKE-Cluster	Die maximal zulässige Anzahl von verwalteten Zonen, die an einen GKE-Cluster angehängt werden können.
Hinzufügen von Ressourceneinträgen pro Änderung	Die maximal zulässige Anzahl von ResourceRecordSets, die Sie pro ChangesCreateRequest hinzufügen können.
Löschen von Ressourceneinträgen pro Änderung	Die maximal zulässige Anzahl von ResourceRecordSets, die Sie pro ChangesCreateRequest löschen können.
Ressourceneinträge pro verwalteter Zone	Die maximal zulässige Anzahl von ResourceRecordSets pro Zone im Projekt.
Ressourceneinträge pro Ressourceneintragssatz	Die maximal zulässige Anzahl von ResourceRecords pro ResourceRecordSet. Jede Delegierung (Ressourceneintragssätze vom Typ NS) kann bis zu acht Nameserver haben.
Antwortrichtlinien pro Projekt	Die maximal zulässige Anzahl von Antwortrichtlinien pro Projekt.
Schreiblimit für Antwortrichtlinienregel für eine Minute für eine Region	Die maximale Anzahl von Antwortrichtlinienregeln, die pro Minute für eine Region geschrieben werden können.
Antwortrichtlinienregeln pro Batchaktion	Die maximale Anzahl von Aktionen zur Antwortrichtlinienverwaltung pro Batch und Minute.
Antwortrichtlinienregeln pro Richtlinie	Die maximale Anzahl von Antwortrichtlinienregeln, die Sie für eine Richtlinie erstellen können.
Ziel-Nameserver pro Weiterleitungsrichtlinie	Die maximal zulässige Anzahl von Ziel-Nameservern pro Weiterleitungsrichtlinie.
Ziel-Nameserver pro verwaltete Zone	Die maximal zulässige Anzahl von Ziel-Nameservern pro verwalteter Weiterleitungszone.
Gesamtgröße der Ressourceneintragsdaten (in Byte) pro Änderung	Die maximal zulässige Größe für insgesamt rrdata in einer ChangesCreateRequest in Byte.
VPC-Netzwerke pro verwalteter Zone	Die maximal zulässige Anzahl von VPC-Netzwerken, an die eine private Zone angehängt werden kann.
VPC-Netzwerke pro Richtlinie	Die maximal zulässige Anzahl von VPC-Netzwerken pro Cloud DNS-Serverrichtlinie.
Schreiblimit für eine Minute für eine Region	Die maximale Anzahl von DNS-Schreibvorgängen pro Region und Minute. Dieses Kontingent wird für jeden Schreibvorgang verwendet, bei dem ein DNS-Eintrag erstellt, geändert oder gelöscht wird.

Limits

Anders als Kontingente, bei denen eine Erhöhung angefordert werden kann, können Limits normalerweise nicht erhöht werden, sofern nicht ausdrücklich angegeben.

API-Nutzung

Die Anzahl der API-Anfragen (Abfragen) pro Tag wird auf Projektebene verwaltet. Für dieses Limit werden alle API-Anfragen berücksichtigt, auch solche, die über die Google Cloud CLI und die Google Cloud Console gesendet werden.

Ressourcenlimits

Element	Limit
Wenn Sie eine Aktualisierung dieser Limits beantragen möchten, wenden Sie sich an Cloud Customer Care.
Anzahl der Peering-Zonen pro Netzwerk	1.000
Nameserver pro Delegierung	8
Hinzufügungen pro Änderung	1.000
Löschungen pro Änderung	1.000
Größe der Ressourceneintragsdaten pro Änderung	100.000 Byte
Anzahl der Labelkombinationen	1.000
Anzahl der Regeln pro Antwortrichtlinie	10.000
Anzahl der Elemente pro Routingrichtlinie	100
Anzahl der verwalteten Zonen, die an ein VPC-Netzwerk gebunden sind	10.000
Maximale Größe einer DNS-Antwort (UDP)	1.440 Byte
Maximale Größe einer DNS-Antwort (TCP)	65.533 Byte
Maximale Abfragerate pro VPC-Netzwerk	100.000 Abfragen in einem Zeitraum von 10 Sekunden (10s)
Diese Limits können nicht erhöht werden.
Anzahl der Antwortrichtlinien pro VPC-Netzwerk	1
Anzahl der Label pro verwaltete Zone	64 Label und 128 Byte pro Schlüssel oder Wert
Anzahl der Weiterleitungsziele in einer Weiterleitungszone	50
Anzahl der Weiterleitungsziele in einem alternativen Nameserver	50

Nameserver-Limits

Cloud DNS weist jede verwaltete Zone einem von fünf Nameserver-Shards zu. Ein Shard ist der Buchstabe vor der Zahl in einem autorisierenden Nameserver-Namen. Der E-Shard besteht also beispielsweise aus ns-cloud-e1 bis ns-cloud-e4.

Eine neue verwaltete Zone einer Domain, z. B. domain.example.tld, kann keinem Shard zugewiesen werden, wenn bereits eine der folgenden Zonen auf demselben Shard vorhanden ist:

• Eine verwaltete Zone mit demselben DNS-Namen, z. B. domain.example.tld
• Eine Subdomain des DNS-Namens, z. B. sub.domain.example.tld
• Eine übergeordnete Domain des DNS-Namens, z. B. example.tld

Aufgrund dieser Einschränkungen gelten die folgenden Limits für öffentliche verwaltete Zonen:

• Sie können maximal fünf Zonen mit genau demselben DNS-Namen erstellen.
• Für jede übergeordnete Domain können Sie maximal fünf Ebenen an Subdomains erstellen.

Dieses Limit gilt für alle Projekte und Nutzer in Google Cloud. Nicht delegierte Subdomains und Delegierungen, die in anderen DNS-Diensten gehostet werden, werden nicht auf dieses Limit angerechnet. Bevor Cloud DNS eine fünfte Zone mit dem gleichen DNS-Namen erstellt und so verhindert, dass ein anderer Nutzer diesen DNS-Namen verwendet, müssen Sie den Domaininhaber mit einem TXT-Eintrag bestätigen.

Mehrere Subdomains derselben übergeordneten Domain, z. B. domain.example.tld und otherdomain.example.tld, können demselben Shard zugewiesen werden. Cloud DNS kann jedoch nach der Berücksichtigung der Einschränkung einen beliebigen verfügbaren Shard auswählen. Wenn Sie solche Subdomains in jedem Shard erstellen, können Sie keine Zone für die übergeordnete Domain example.tld erstellen.

Sie können dieses Problem vermeiden, indem Sie für übergeordnete Domains immer verwaltete Zonen erstellen, bevor Sie Zonen für die Subdomains erstellen.

Wenn die untergeordneten Domains bereits alle Shards blockieren, führen Sie die folgenden Schritte aus, um einen Shard für die übergeordnete Domain freizugeben:

1. Prüfen Sie die Nameserver für jede Subdomain-Zone, um den dazugehörigen Shard zu bestimmen.
2. Finden Sie heraus, welcher Shard (X) mit den wenigsten (oder den unwichtigsten) verwalteten Zonen belegt ist.
3. Exportieren Sie die Zonen von Shard X (und ändern Sie ihre Delegierungen) in einen anderen DNS-Dienst.
4. Nachdem die TTLs für die ursprüngliche Delegierung abgelaufen sind, löschen Sie die verwalteten Zonen der Subdomains auf Shard X.
5. Erstellen Sie die verwaltete Zone für die übergeordnete Domain. Sie wird Shard X zugewiesen.
6. Stellen Sie die gelöschten verwalteten Zonen für die Subdomains wieder her. Stellen Sie zuerst die Subdomains wieder her und erst danach deren Sub-Subdomains. Sie werden alle neuen Shards zugewiesen, daher müssen ihre Delegierungen aktualisiert werden.

Hinweis: Für alle über Google Domains registrierten Domains werden eigene Zonen auf Shards erstellt. Bei diesen Produkten gelten Beschränkungen und Limits für Shards. Eine Google Domains-Registrierung verwendet daher einen der Shards, die in Cloud DNS für Domain- und Subdomain-Zonen verfügbar sind. Umgekehrt gilt: Falls eine Domain auf allen Nameserver-Shards Cloud DNS-Zonen mit identischen Namen oder Subdomain-DNS-Namen hat, können Sie diese Domain erst mit Google Domains registrieren, nachdem Sie wie oben beschrieben einen Shard freigegeben haben.

Limits prüfen

Mit dem folgenden Befehl können Sie die Limits für Ihr Projekt prüfen. Das Beispiel zeigt die Gesamtlimits für die verschiedenen Objekttypen im Projekt my-project. Das Kontingent totalRrdataSizePerChange wird in Byte und der Summe der Hinzufügungen und Löschungen bei einer Änderung berechnet.

gcloud dns project-info describe my-project

Obwohl dies Limits sind, behandelt Google Cloud sie intern als Kontingente, sodass sie in der Ausgabe als Kontingente gekennzeichnet sind.

id: my-project,
kind: "dns#project",
number: "123456789012",
quota:
    kind: dns#quota,
    managedZones: 10000,
    resourceRecordsPerRrset: 10000,
    rrsetAdditionsPerChange: 3000,
    rrsetDeletionsPerChange: 3000,
    rrsetsPerManagedZone: 10000,
    totalRrdataSizePerChange: 100000,
    labelSets: 1000

Die Namen Ihres Standardprojekts und weiterer Projekte finden Sie in der Google Cloud Console oben auf der Startseite.

Kontingente verwalten

Mit Cloud DNS 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önnen sich je nach Ihrer Nutzung eines Produkts automatisch erhöhen.

Berechtigungen

Hauptkonten von Identity and Access Management (IAM) benötigen eine der folgenden Rollen, um Kontingente anzusehen oder Kontingenterhöhungen anzufordern.

Aufgabe	Erforderliche Rolle
Kontingente für ein Projekt prüfen	Einen der folgenden Werte: Project Owner (roles/owner) Project Editor (roles/editor) Quota Viewer (roles/servicemanagement.quotaViewer)
Kontingente ändern, zusätzliche Kontingente anfordern	Einen der folgenden Werte: 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. Öffnen Sie in der Google Cloud Console die Seite Kontingente.

   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 dns project-info describe PROJECT_ID
    

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.

Weitere Kontingente anfordern

Verwenden Sie zur Erhöhung/Verringerung der meisten Kontingenten die Google Cloud Console. Weitere Informationen finden Sie unter Höheres Kontingentlimit anfordern.

Console

1. Öffnen Sie in der Google Cloud Console die Seite Kontingente.

   Kontingente aufrufen

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. Geben Sie unter Name Ihren Namen ein.
5. Optional: Geben Sie unter Telefon eine gültige Telefonnummer ein.
6. 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.