Kontingente und Limits

In diesem Dokument sind die Kontingente und Systemlimits für Cloud DNS 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.

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:

• Es überwacht Ihren Verbrauch von Produkten und Diensten von Google Cloud .
• Es schränkt Ihren Verbrauch dieser Ressourcen ein.
• Es bietet eine Möglichkeit, Änderungen am Kontingentwert zu beantragen und Kontingentanpassungen zu automatisieren.

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 Cloud DNS-Ressourcen gelten außerdem Systemlimits. Systemlimits können nicht geändert werden.

Kontingente

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

In dieser Tabelle sind wichtige globale Kontingente für Cloud DNS-Ressourcen pro Projekt aufgeführt. Informationen zu anderen Kontingenten 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 von 1 Minute an die Cloud DNS API senden kann. Dieses Kontingent gilt nur für API-Aufrufe. Für die Verarbeitung von DNS-Anfragen gibt es 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 verwalteter Zonen im Projekt.
Verwaltete Zonen pro VPC-Netzwerk	Die maximal zulässige Anzahl verwalteter Zonen, die an ein VPC-Netzwerk angehängt werden können.
Richtlinienressourcen pro Projekt	Die maximale Anzahl von DNS-Serverrichtlinien pro Projekt.
Richtlinie für Netzwerke pro Antwort	Die maximal zulässige Anzahl von VPC-Netzwerken pro Antwortrichtlinie.
Routingrichtlinien mit Systemdiagnose pro Projekt	Die maximal zulässige Anzahl von DNS-Routingrichtlinien mit Internet-Systemdiagnose pro Projekt.
Elemente pro Routingrichtlinie	Die maximal zulässige Anzahl von Elementen pro Routingrichtlinie.
GKE-Cluster pro verwalteter Zone	Die maximal zulässige Anzahl von Google Kubernetes Engine-Clustern (GKE), an die eine Zone mit privatem Bereich 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ügungen von Ressourceneinträgen pro Änderung	Die maximal zulässige Anzahl von ResourceRecordSets, die Sie pro ChangesCreateRequest hinzufügen können.
Löschungen von Ressourceneinträgen pro Änderung	Die maximal zulässige Anzahl von ResourceRecordSets, die Sie pro ChangesCreateRequest löschen können.
Ressourceneintragssätze 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 jedoch bis zu acht Nameserver umfassen.
Antwortrichtlinien pro Projekt	Die maximal zulässige Anzahl von Antwortrichtlinien pro Projekt.
Schreiblimit für Antwortrichtlinienregeln pro Minute und Region	Die maximale Anzahl von Antwortrichtlinienregeln, die pro Minute für eine Region geschrieben werden können.
Regeln für Antwortrichtlinien pro Batchvorgang	Die maximale Anzahl von Aktionen zur Verwaltung von Antwortrichtlinien 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 verwalteter 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 die Gesamtzahl von rrdata in einem ChangesCreateRequest in Byte.
VPC-Netzwerke pro verwalteter Zone	Die maximal zulässige Anzahl von VPC-Netzwerken, an die eine Zone mit privatem Bereich 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 alle Schreibvorgänge verwendet, mit denen 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 -Konsole gesendet werden.

Ressourcenlimits

Posten	Limit
Wenn Sie eine Aktualisierung dieser Limits anfordern 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 an ein VPC-Netzwerk gebundenen verwalteten Zonen	10.000
Maximale Größe einer DNS-Antwort (UDP)	1.440 Byte
Maximale Größe einer DNS-Antwort (TCP)	65.533 Byte
Diese Limits können nicht erhöht werden.
Maximale Abfragerate pro VPC-Netzwerk und Zone	100.000 Abfragen in einem Zeitraum von 10 Sekunden (10s) in einer Google Cloud -Zone, z. B. us-central1-a
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.

Diese Einschränkungen gelten für alle Projekte und Nutzer in Google Cloud. Nicht delegierte Subdomains und Delegierungen, die auf anderen DNS-Diensten gehostet werden, werden nicht auf dieses Limit angerechnet. Bevor Cloud DNS eine Zone erstellt, die den letzten verfügbaren Nameserver-Shard belegt, müssen Sie den Domaininhaber der Zone 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änkungen 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 diese Einschränkungen 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 totalRrdataSizePerChange-Kontingent wird in Byte berechnet und ist die Summe der Hinzufügungen und Löschungen bei einer Änderung.

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 consoleoben auf der Startseite.

Manage quotas

Cloud DNS enforces quotas on resource usage for various reasons. For example, quotas protect the community of Google Cloud users by preventing unforeseen spikes in usage. Quotas also help users who are exploring Google Cloud with the free tier to stay within their trial.

All projects start with the same quotas, which you can change by requesting additional quota. Some quotas might increase automatically based on your use of a product.

Permissions

To view quotas or request quota increases, Identity and Access Management (IAM) principals need one of the following roles.

Task	Required role
Check quotas for a project	One of the following: Project Owner (roles/owner) Project Editor (roles/editor) Quota Viewer (roles/servicemanagement.quotaViewer)
Modify quotas, request additional quota	One of the following: Project Owner (roles/owner) Project Editor (roles/editor) Quota Administrator (roles/servicemanagement.quotaAdmin) A custom role with the serviceusage.quotas.update permission

Check your quota

Console

1. In the Google Cloud console, go to the Quotas page.

   Go to Quotas

2. To search for the quota that you want to update, use the Filter table. If you don't know the name of the quota, use the links on this page instead.

gcloud

Using the Google Cloud CLI, run the following command to check your quotas.

Replace PROJECT_ID with your own project ID.

    gcloud dns project-info describe PROJECT_ID
    

Errors when exceeding your quota

If you exceed a quota with a gcloud command, gcloud outputs a quota exceeded error message and returns with the exit code 1.

If you exceed a quota with an API request, Google Cloud returns the following HTTP status code: 413 Request Entity Too Large.

Request additional quota

To adjust most quotas, use the Google Cloud console. For more information, see Request a quota adjustment.

Console

1. In the Google Cloud console, go to the Quotas page.

   Go to Quotas

2. On the Quotas page, select the quotas that you want to change.
3. At the top of the page, click Edit quotas.
4. For Name, enter your name.
5. Optional: For Phone, enter a valid phone number.
6. Submit your request. Quota requests take 24 to 48 hours to process.

Resource availability

Each quota represents a maximum number for a particular type of resource that you can create, if that resource is available. It's important to note that quotas do not guarantee resource availability. Even if you have available quota, you can't create a new resource if it is not available.

For example, you might have sufficient quota to create a new regional, external IP address in the us-central1 region. However, that is not possible if there are no available external IP addresses in that region. Zonal resource availability can also affect your ability to create a new resource.

Situations where resources are unavailable in an entire region are rare. However, resources within a zone can be depleted from time to time, typically without impact to the service level agreement (SLA) for the type of resource. For more information, review the relevant SLA for the resource.