Kontingente und Limits

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

• Kontingente geben an, wie viel einer zählbaren, freigegebenen Ressource Sie verwenden können. Kontingente werden von Google Cloud-Diensten wie Cloud DNS definiert.
• Systemlimits sind feste Werte, die nicht geändert werden können.

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

Das Cloud-Kontingentsystem ermöglicht Folgendes:

• Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen
• Ihren Verbrauch dieser Ressourcen einschränken
• Eine Möglichkeit bieten, Änderungen am Kontingentwert anzufordern

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 ausführen möchten, schlägt fehl.

Kontingente gelten in der Regel auf Google Cloud-Projektebene. Ihre Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf Ihr verfügbares Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud-Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.

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.

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

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 auf 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.

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 gemessen 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 Console oben auf der Startseite.

Kontingente verwalten

MitCloud 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ö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:

Kontingent prüfen

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

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 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.