Architektur der Cloud Composer-Umgebung

Cloud Composer 1 Cloud Composer 2

Auf dieser Seite wird die Architektur von Cloud Composer 2-Umgebungen beschrieben.

Konfigurationen der Umgebungsarchitektur

Cloud Composer 2-Umgebungen können die folgenden Architekturkonfigurationen haben:

• Öffentliche IP-Architektur

• Private IP-Architektur

• Äußerst stabile private IP-Architektur

Die Architektur von Umgebungsressourcen ändert sich durch jede Konfiguration geringfügig.

Kunden- und Mandantenprojekte

Beim Erstellen einer Umgebung werden die Umgebungsressourcen von Cloud Composer auf ein Mandanten- und ein Kundenprojekt verteilt.

Das Kundenprojekt ist ein Google Cloud-Projekt, in dem Sie Ihre Umgebungen erstellen. Sie können in einem Kundenprojekt mehrere Umgebungen erstellen.

Das Mandantenprojekt ist ein von Google verwaltetes Mandantenprojekt. Das Mandantenprojekt bietet eine einheitliche Zugriffssteuerung und eine zusätzliche Datensicherheitsebene für Ihre Umgebung. Jede Cloud Composer-Umgebung hat ein eigenes Mandantenprojekt.

Umgebungskomponenten

Eine Cloud Composer-Umgebung besteht aus Umgebungskomponenten.

Eine Umgebungskomponente ist ein Element einer verwalteten Airflow-Infrastruktur, die in Google Cloud als Teil Ihrer Umgebung ausgeführt wird.

Umgebungskomponenten werden entweder im Mandanten- oder im Kundenprojekt Ihrer Umgebung ausgeführt.

Einige Komponenten Ihrer Umgebung basieren auf eigenständigen Google Cloud-Produkten. Kontingente und Beschränkungen für diese Produkte gelten auch für Ihre Umgebungen. Beispielsweise verwenden Cloud Composer-Umgebungen VPC-Peerings. Für Ihr Kundenprojekt gelten Kontingente für die maximale Anzahl von VPC-Peerings. Sobald Ihr Projekt diese maximale Anzahl von Peerings erreicht hat, können Sie keine weiteren Umgebungen erstellen.

Cluster der Umgebung

Cluster der Umgebung ist ein VPC-nativer Google Kubernetes Engine-Cluster Ihrer Umgebung im Autopilot-Modus:

• Umgebungsknoten sind VMs im Cluster der Umgebung.

• Pods im Cluster der Umgebung führen Container mit anderen Umgebungskomponenten wie Airflow-Workern und Planern aus. Pods werden auf Umgebungsknoten ausgeführt.

• Arbeitslastressourcen des Clusters Ihrer Umgebung verwalten Pod-Gruppen im Cluster Ihrer Umgebung Viele Komponenten Ihrer Umgebung werden als verschiedene Arten von Arbeitslastressourcen implementiert. Airflow-Worker werden beispielsweise als Deployments ausgeführt. Zusätzlich zu Deployments enthält Ihre Umgebung auch die Arbeitslasttypen StatefulSets, DaemonSets und Jobs.

Achtung: Nehmen Sie keine Änderungen im Cluster der Umgebung vor. Cluster für Cloud Composer und die darin bereitgestellten Arbeitslasten werden von Google verwaltet. Es ist möglich, die Konfiguration des Umgebungsclusters zu ändern, dies kann jedoch Ihre Umgebung beeinträchtigen. Wenn Sie den Cluster einer Umgebung löschen, kann er nicht wiederhergestellt werden. Sie müssen die Umgebung löschen und eine neue erstellen.

Standardmäßig aktiviert Cloud Composer automatische Knotenupgrades und automatische Knotenreparaturen, um den Cluster Ihrer Umgebung vor Sicherheitslücken zu schützen. Diese Vorgänge erfolgen während Wartungsfenstern, die Sie für Ihre Umgebung angeben.

Airflow-Planer, Trigger, Worker und Redis-Warteschlange

Airflow-Planer steuern die Planung von DAG-Ausführungen und einzelnen Aufgaben von DAGs. Planer verteilen Aufgaben an Airflow-Worker mithilfe einer Redis-Warteschlange, die als Anwendung im Cluster Ihrer Umgebung ausgeführt wird. Airflow-Scheduler werden als Deployments im Cluster Ihrer Umgebung ausgeführt.

Airflow-Worker führen einzelne Aufgaben aus DAGs aus, die sie aus der Redis-Warteschlange nehmen. Airflow-Worker werden als benutzerdefinierte Ressourcen im Cluster Ihrer Umgebung ausgeführt.

Der Airflow-Trigger überwacht alle zurückgestellten Aufgaben in Ihrer Umgebung asynchron. Sie können die Anzahl der Triggerinstanzen konfigurieren, wenn Sie Cloud Composer-Umgebungen erstellen oder aktualisieren. Cloud Composer unterstützt die folgenden Triggerkonfigurationen:

• Anzahl der Trigger:

  • Standardausfallsicherheit: Sie können bis zu 10 Trigger ausführen
  • Hohe Ausfallsicherheit: mindestens 2 Trigger, bis maximal 10

  Sie können die Anzahl der Trigger auf null setzen, aber Sie benötigen mindestens eine Triggerinstanz in Ihrer Umgebung (oder mindestens zwei in hoch stabilen Umgebungen), um zurückstellbare Operatoren in Ihren DAGs zu verwenden. Wenn die Anzahl der Trigger auf null gesetzt ist, führt der Cluster Ihrer Umgebung weiterhin eine Arbeitslast für sie aus, jedoch mit null Pods. Es entstehen keine Kosten.

• Ressourcenzuweisung des Triggers:

  • Maximal 1 vCPU pro Trigger
  • Maximaler Arbeitsspeicher entspricht der Anzahl der Triggerer-CPUs multipliziert mit 6.5

Die Redis-Warteschlange enthält eine Warteschlange einzelner Aufgaben von Ihren DAGs. Airflow-Planer füllen die Warteschlange. Airflow-Worker nehmen ihre Aufgaben daraus. Die Redis-Warteschlange wird als StatefulSet-Anwendung im Cluster Ihrer Umgebung ausgeführt, sodass Nachrichten über Container-Neustarts hinweg beibehalten werden.

Airflow-Webserver

Airflow-Webserver führt die Airflow-UI Ihrer Umgebung aus.

In Cloud Composer 2 wird der Airflow-Webserver als Deployment im Cluster Ihrer Umgebung ausgeführt.

Cloud Composer 2 bietet Zugriff auf die Schnittstelle basierend auf Nutzeridentitäten und IAM-Richtlinienbindungen, die für Nutzer definiert sind. Im Vergleich zu Cloud Composer 1 verwendet Cloud Composer 2 einen anderen Mechanismus, der nicht auf Identity-Aware Proxy basiert.

Airflow-Datenbank

Eine Airflow-Datenbank ist eine Cloud SQL-Instanz, die im Mandantenprojekt Ihrer Umgebung ausgeführt wird. Sie hostet die Airflow-Metadatendatenbank.

Zum Schutz vertraulicher Verbindungs- und Workflowinformationen lässt Cloud Composer den Datenbankzugriff nur auf das Dienstkonto Ihrer Umgebung zu.

Achtung: Wenn Sie das Airflow-Datenbankschema ändern oder die Airflow-Befehle resetdb, initdb oder upgradedb ausführen, kann die Cloud Composer-Umgebung beeinträchtigt werden

Bucket der Umgebung

Der Bucket der Umgebung ist ein Cloud Storage-Bucket, in dem DAGs, Plug-ins, Datenabhängigkeiten und Airflow-Logs gespeichert werden. Der Bucket der Umgebung befindet sich im Kundenprojekt.

Wenn Sie Ihre DAG-Dateien in den Ordner /dags Ihres Buckets hochladen, synchronisiert Cloud Composer die DAGs mit Workern, Planern und dem Webserver Ihrer Umgebung. Sie können Ihre Workflow-Artefakte in den Ordnern data/ und logs/ speichern, ohne Größenbeschränkungen berücksichtigen zu müssen. Sie haben damit die Möglichkeit, den Zugriff auf Ihre Daten uneingeschränkt zu steuern.

Andere Umgebungskomponenten

Eine Cloud Composer-Umgebung enthält mehrere zusätzliche Umgebungskomponenten:

• Cloud SQL-Speicher. Speichert die Airflow-Datenbanksicherungen. Die Airflow-Metadaten werden von Cloud Composer täglich gesichert, um potenzielle Datenverluste zu minimieren.

  Cloud SQL Storage wird im Mandantenprojekt Ihrer Umgebung ausgeführt. Sie können nicht auf die Inhalte im Cloud SQL-Speicher zugreifen.

• Cloud SQL-Proxy. Verbindet andere Komponenten Ihrer Umgebung mit der Airflow-Datenbank.

  Ihre öffentliche IP-Umgebung kann je nach Umfang des Traffics an die Airflow-Datenbank eine oder mehrere Cloud SQL-Proxyinstanzen haben.

  In einer Umgebung mit öffentlichen IP-Adressen wird ein Cloud SQL-Proxy als Deployment im Cluster Ihrer Umgebung ausgeführt.

  Bei der Bereitstellung im Cluster Ihrer Umgebung autorisiert ein Cloud SQL-Proxy auch den Zugriff auf Ihre Cloud SQL-Instanz über eine Anwendung, einen Client oder einen anderen Google Cloud-Dienst.

• Airflow-Monitoring. Meldet Umgebungsmesswerte an Cloud Monitoring und löst den DAG airflow_monitoring aus. Der DAG airflow_monitoring meldet die Daten zum Umgebungsstatus, die später beispielsweise im Monitoring-Dashboard Ihrer Umgebung verwendet werden. Airflow-Monitoring wird als Deployment im Cluster Ihrer Umgebung ausgeführt.

• Der Composer-Agent führt Umgebungsvorgänge wie das Erstellen, Aktualisieren, Upgraden und Löschen von Umgebungen aus. Im Allgemeinen ist diese Komponente dafür verantwortlich, Änderungen an Ihrer Umgebung vorzunehmen. Wird als Job im Cluster Ihrer Umgebung ausgeführt.

• Airflow InitDB erstellt eine Cloud SQL-Instanz und ein anfängliches Datenbankschema. Airflow InitDB wird als Job im Cluster Ihrer Umgebung ausgeführt.

• FluentD. Erfasst Logs aus allen Umgebungskomponenten und lädt die Logs in Cloud Logging hoch. Wird als DaemonSet im Cluster Ihrer Umgebung ausgeführt.

• Pub/Sub-Abos. Ihre Umgebung kommuniziert über Pub/Sub-Abos mit dem GKE-Dienst-Agent. Das Verwalten von Nachrichten beruht auf dem Standardverhalten von Pub/Sub. Löschen Sie keine .*-composer-.* Pub/Sub-Themen. Pub/Sub unterstützt maximal 10.000 Themen pro Projekt.

• Der PSC-Endpunkt verbindet Airflow-Planer und -Worker in der Architektur Private IP-Adresse mit PSC mit der Airflow-Datenbank.

• Der Stackdriver-Adapter für Kundenmesswerte meldet Messwerte Ihrer Umgebung für das Autoscaling. Diese Komponente wird als Deployment im Cluster Ihrer Umgebung ausgeführt.

• Der Airflow Worker Set Controller skaliert Ihre Umgebung automatisch anhand der Messwerte aus dem Stackdriver-Adapter für Kundenmesswerte. Diese Komponente wird als Deployment im Cluster Ihrer Umgebung ausgeführt.

• Cloud Storage FUSE. Stellen Sie den Bucket Ihrer Umgebung als Dateisystem auf Airflow-Workern, Planern und Webservern bereit, damit diese Komponenten auf die Daten aus dem Bucket zugreifen können. Wird als DaemonSet im Cluster Ihrer Umgebung ausgeführt.

Architektur der öffentlichen IP-Umgebung

Abbildung 1. Architektur einer öffentlichen IP-Umgebung (zum Vergrößern klicken)

In einer öffentlichen IP-Umgebungsarchitektur für Cloud Composer 2:

• Im Mandantenprojekt werden eine Cloud SQL-Instanz und ein Cloud SQL-Speicher gehostet.
• Das Kundenprojekt hostet alle anderen Komponenten der Umgebung.
• Airflow-Planer und -Worker im Kundenprojekt kommunizieren über eine Cloud SQL-Proxy-Instanz im Kundenprojekt mit der Airflow-Datenbank.

Architektur der privaten IP-Umgebung

Abbildung 2. Ressourcen der privaten IP-Umgebung in Cloud Composer im Mandantenprojekt und im Kundenprojekt (zum Vergrößern klicken)

Standardmäßig verwendet Cloud Composer 2 Private Service Connect, sodass Ihre privaten IP-Umgebungen intern ohne VPC-Peering kommunizieren. Sie können in Ihrer Umgebung auch VPC-Peerings anstelle von Private Service Connect verwenden. Dies ist eine nicht standardmäßige Option.

In der Architektur der privaten IP-Umgebung:

• Im Mandantenprojekt werden eine Cloud SQL-Instanz und ein Cloud SQL-Speicher gehostet.
• Das Kundenprojekt hostet alle anderen Komponenten der Umgebung.
• Airflow-Planer und -Worker stellen über den konfigurierten PSC-Endpunkt eine Verbindung zur Airflow-Datenbank her.

Hinweis: Wenn die Organisationsrichtlinie für domaineingeschränkte Freigabe (DRS) in Ihrem Projekt aktiviert ist, verwendet Cloud Composer 2 weiterhin die Architektur der privaten IP-Adresse. Nur Cloud Composer 1 verwendet einen anderen Architekturtyp, wenn DRS aktiviert ist.

Äußerst stabile private IP-Architektur

Abbildung 3. Äußerst robuste private IP-Umgebungsressourcen von Cloud Composer im Mandantenprojekt und im Kundenprojekt (zum Vergrößern klicken)

Äußerst robuste Cloud Composer-Umgebungen sind Cloud Composer 2-Umgebungen, die integrierte Redundanz- und Failover-Mechanismen verwenden. Diese verringern die Anfälligkeit der Umgebung für zonale Ausfälle und Single-Point-of-Failure-Ausfälle.

Bei diesem Typ einer privaten IP-Umgebung gilt Folgendes:

• Eine Cloud SQL-Instanz Ihrer Umgebung ist für Hochverfügbarkeit konfiguriert (eine regionale Instanz). Innerhalb einer regionalen Instanz besteht die Konfiguration aus einer primären Instanz und einer Standby-Instanz.
• In Ihrer Umgebung werden zwei Airflow-Planer und zwei Webserver ausgeführt. Wenn Trigger verwendet werden, sind mindestens zwei (insgesamt bis zu zehn) Trigger erforderlich. Diese Komponentenpaare werden in zwei separaten Zonen ausgeführt.
• Die Mindestanzahl von Workern ist auf zwei festgelegt und der Cluster Ihrer Umgebung verteilt die Worker-Instanzen auf die Zonen. Bei einem Zonenausfall werden betroffene Worker-Instanzen in eine andere Zone verschoben.

Einbindung in Cloud Logging und Cloud Monitoring

Cloud Composer kann in Cloud Logging und Cloud Monitoring Ihres Google Cloud-Projekts integriert werden, sodass Sie eine zentrale Stelle für die Anzeige der Airflow-Dienst- und Workflow-Logs haben.

Cloud Monitoring sammelt und erfasst Messwerte, Ereignisse und Metadaten aus Cloud Composer, mit denen sich mithilfe von Dashboards und Diagrammen aussagekräftige Informationen generieren lassen.

Aufgrund des Streaming-Charakters von Cloud Logging können Sie alle Logs, die vom Airflow-Planer und von den Airflow-Workern gesendet werden, sofort aufrufen. Sie müssen also nicht warten, bis Airflow-Logs im Cloud Storage-Bucket Ihrer Umgebung angezeigt werden. Da die Logs von Cloud Logging für Cloud Composer auf google-fluentd beruhen, haben Sie Zugriff auf alle von Airflow-Planern und -Workern erstellten Logs.

Wenn Sie die Anzahl der Logs in Ihrem Google Cloud-Projekt begrenzen möchten, beenden Sie die gesamte Aufnahme von Logs. Deaktivieren Sie das Logging aber nicht.

Nächste Schritte

• Umgebung erstellen
• Versionsübersicht