In diesem Dokument sind die Kontingente und Systemlimits für Cloud Composer 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 unter Cloud-Kontingente – Übersicht.Die meisten Kontingente können Sie in der Google Cloud Console anpassen. Weitere Informationen finden Sie unter Kontingentanpassung anfordern.
Für Cloud Composer-Ressourcen gelten außerdem Systemlimits. Systemlimits können nicht geändert werden.
Cloud Composer-Kontingente
Die Kontingente in diesem Abschnitt gelten nur für die Cloud Composer API und Tools, die die Cloud Composer API verwenden:
- Cloud Composer-Schnittstelle in der Google Cloud Console
gcloud composer
- undgcloud beta composer
-Befehle- Cloud Composer REST API
- Cloud Composer RPC API
- Terraform für Vorgänge mit Cloud Composer-Umgebungen
Die Kontingente in diesem Abschnitt gelten nicht für Dienste, die Sie in Ihren Airflow-DAGs verwenden. Für solche Dienste gelten eigene Kontingente.
Für Cloud Composer gelten die folgenden API-Kontingente:
Kontingentname | Limit |
---|---|
Leseanfragen pro Projekt | 1.000 Kontingenteinheiten pro Minute |
Schreibanfragen pro Projekt | 25.000 Kontingenteinheiten pro Tag |
Schreibanfragen pro Projekt | 1.500 Kontingenteinheiten pro Minute |
Snapshot-Anfragen pro Projekt speichern | 5.000 Kontingenteinheiten pro Tag |
Snapshot-Anfragen pro Projekt speichern | 250 Kontingenteinheiten pro Minute |
Snapshot-Anfragen pro Projekt und Umgebung speichern | 2.600 Kontingenteinheiten pro Tag |
Snapshot-Anfragen pro Projekt laden | 2.500 Kontingenteinheiten pro Tag |
Snapshot-Anfragen pro Projekt laden | 150 Kontingente pro Minute |
Anfragen zum Laden von Snapshots pro Projekt und Umgebung | 700 Kontingenteinheiten pro Tag |
Für Cloud Composer API-Aufrufe fallen die folgenden Kosten in Kontingenteinheiten an:
Vorgang | Kosten in Kontingenteinheiten | Art der Anfrage |
---|---|---|
Alle Vorgänge | 1 | Lesen |
environments.create | 100 | Schreiben |
environments.patch | 100 | Schreiben |
environments.delete | 100 | Schreiben |
environments.databaseFailover | 100 | Schreiben |
environments.restartWebServer | 100 | Schreiben |
environments.checkUpgrade | 100 | Schreiben |
environments.executeAirflowCommand | 25 | Schreiben |
environments.stopAirflowCommand | 25 | Schreiben |
environments.saveSnapshot | 50 | Snapshot speichern |
environments.loadSnapshot | 50 | Snapshot laden |
Beispiele für die Berechnung von Kontingenten
Für eine
environments.create
-Anfrage werden 100 Kontingenteinheiten des Schreibkontingents verbraucht.Es gibt zwei solche Kontingente für Schreibanfragen:
- Schreibanfragen pro Projekt und Tag
- Schreibanfragen pro Projekt und Minute
Für diesen Vorgang werden 100 Kontingenteinheiten aus jedem Kontingent verbraucht.
Wenn Sie danach eine
environments.restartWebServer
-Anfrage ausführen, werden weitere 100 Kontingenteinheiten aus denselben Kontingenten verbraucht, daenvironments.restartWebServer
Kontingente mit derenvironments.create
-Anfrage teilt.Für eine
environments.saveSnapshot
-Anfrage werden 50 Kontingenteinheiten aus drei Kontingenten verbraucht:- „Snapshot speichern“-Anfragen pro Projekt und Tag
- Anfragen zum Speichern von Snapshots pro Projekt und Minute
- Snapshot-Anfragen pro Projekt, Umgebung und Tag speichern
Diese drei Kontingente begrenzen die maximale Anzahl von
environments.saveSnapshot
-Anfragen. Jedes Tool geht dabei anders vor.Das Kontingentlimit für Save snapshot requests per project per day beträgt 2.500 Kontingenteinheiten. Sie können in Ihrem Projekt jeden Tag bis zu 50
environments.saveSnapshot
-Anfragen ausführen.Das Kontingentlimit für Save snapshot requests per project per minute (Anfragen zum Speichern von Snapshots pro Projekt und Minute) beträgt 150 Kontingenteinheiten. Sie können in Ihrem Projekt nur bis zu drei
environments.saveSnapshot
-Anfragen pro Minute ausführen.Das Kontingentlimit für Save snapshot requests per project per environment per day (Anfragen zum Speichern von Snapshots pro Projekt, Umgebung und Tag) beträgt 750 Kontingenteinheiten. Sie können für eine einzelne Umgebung bis zu 15
environments.saveSnapshot
-Anfragen pro Tag ausführen. Wenn alle Kontingenteinheiten für eine bestimmte Umgebung aufgebraucht sind, können Sie weiterhinenvironments.saveSnapshot
-Anfragen für andere Umgebungen in Ihrem Projekt ausführen.
Kontingente für andere Dienste
Cloud Composer verwendet andere Google Cloud Dienste. Für diese Dienste gelten Kontingente auf Projektebene, die bei der Verwendung von Cloud Composer gelten.
So gelten beispielsweise Kontingente für Cloud Storage für alle Buckets, die mit Umgebungen in Ihrem Projekt verknüpft sind. Ein weiteres Beispiel: Die Cluster der Umgebung verwenden Google Kubernetes Engine. Daher gelten Kontingente für GKE für alle Cluster, die mit Umgebungen in Ihrem Projekt verknüpft sind.
Kontingente für von Cloud Composer verwendete Dienste
Die folgenden Dienste werden von Cloud Composer verwendet. Für diese Dienste gelten eigene Kontingentlimits:
- Cloud Deployment Manager-Kontingente
- Google Kubernetes Engine-Kontingente
- Compute Engine-Kontingente
- Cloud Storage-Kontingente
- Pub/Sub-Kontingente
- Cloud Logging-Kontingente
- Cloud Monitoring-Kontingente
- Cloud Build-Kontingente (gelten für Umgebungen, in denen benutzerdefinierte PyPI-Pakete verwendet werden)
- Artifact Registry-Kontingente
- IAM-Kontingente
- Kontingente für Virtual Private Cloud (gilt nicht für Umgebungen, in denen Private Service Connect verwendet wird)
- Resource Manager-Kontingente
- Service Directory-Kontingente
Kontingente für optionale Dienste
Sie können Airflow-Operatoren mit Google Cloud -Diensten verwenden. Für alle Dienste, die Sie in einem DAG verwenden, gelten die Kontingente des jeweiligen Dienstes.