Architektur der Cloud Composer-Umgebung

Cloud Composer 1 Cloud Composer 2

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

Konfigurationen der Umgebungsarchitektur

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

• Öffentliche IP-Architektur

• Private IP-Architektur mit VPC-Peerings

• Private IP-Adresse mit Domaineingeschränkte Freigabe-Architektur (DRS)

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 oder routenbasierter Google Kubernetes Engine-Cluster im Standard-Modus Ihrer Umgebung:

• 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, 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 Deployments im Cluster Ihrer Umgebung ausgeführt.

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 1 ist der Airflow-Webserver eine App Engine Flex-Instanz, die im Mandantenprojekt Ihrer Umgebung ausgeführt wird.

Der Airflow-Webserver ist in Identity-Aware Proxy eingebunden. Cloud Composer blendet die Details der IAP-Integration aus und bietet Zugriff auf den Webserver basierend auf Nutzeridentitäten und IAM-Richtlinienbindungen, die für Nutzer definiert sind.

Der Airflow-Webserver wird auf einem anderen Dienstkonto ausgeführt als die Airflow-Worker und Airflow-Planer. Das Dienstkonto für den Webserver wird beim Erstellen der Umgebung automatisch generiert und von der Webserverdomain abgeleitet. Wenn die Domain beispielsweise example.appspot.com lautet, ist das Dienstkonto [e-mail].

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.

Hinweis: Aufgrund einer Diensteinschränkung in App Engine sind die Ordner data/ undlogs/ für den Airflow-Webserver nicht verfügbar.

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.

– HAProxy. Load-Balancing des Traffics zur Cloud SQL-Instanz zwischen zwei Cloud SQL-Proxy-Instanzen, die im Mandantenprojekt ausgeführt werden. Bei Cloud Composer 1 wird diese Komponente in privaten IP-Umgebungen verwendet und als Container in der Bereitstellung des Cloud SQL-Proxys ausgeführt.

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

• Bucket-Synchronisierung: Bei diesem Prozess werden Umgebungs-Buckets in den Kunden- und Mandantenprojekten synchronisiert. Diese Komponente wird in der Architektur der privaten IP-Adresse mit DRS-Umgebung verwendet. Diese Komponente wird als Container in den Pods anderer Komponenten ausgeführt, die Umgebungs-Buckets verwenden.

  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 1:

  • Das Mandantenprojekt hostet eine Cloud SQL-Instanz, Cloud SQL Storage und eine App Engine Flex-Instanz, auf der der Airflow-Webserver ausgeführt wird.
  • 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.
  • Der Airflow-Webserver im Mandantenprojekt kommuniziert mit der Airflow-Datenbank über eine Cloud SQL-Proxyinstanz im Mandantenprojekt.

  Architektur der privaten IP-Umgebung

  

  Abbildung 2. Architektur einer privaten IP-Umgebung (zum Vergrößern klicken)

  In einer Architektur für eine private IP-Umgebung:

  • Das Mandantenprojekt hostet eine Cloud SQL-Instanz, Cloud SQL Storage und zwei App Engine-Instanzen, auf denen der Airflow-Webserver ausgeführt wird.
  • Das Kundenprojekt hostet alle anderen Komponenten der Umgebung.
  • Airflow-Planer und -Worker stellen über den HAProxy-Prozess im Cluster der Umgebung eine Verbindung zur Airflow-Datenbank her.
  • Der HAProxy-Prozess verteilt den Traffic durch Load-Balancing auf die Cloud SQL-Instanz zwischen zwei Cloud SQL-Proxy-Instanzen, die sich im Mandantenprojekt befinden. Private IP-Umgebungen verwenden zwei Cloud SQL-Proxy-Instanzen, da das Kundenprojekt aufgrund von Netzwerkeinschränkungen nicht direkt auf die Datenbank zugreift. Es sind zwei Instanzen erforderlich, damit die Komponenten Ihrer Umgebung jederzeit auf die Datenbank zugreifen können.

  Private IP mit DRS

  

  Abbildung 3. Architektur einer privaten IP-Umgebung (zum Vergrößern klicken)

  Wenn die Organisationsrichtlinie für die Domaineingeschränkte Freigabe (DRS) in Ihrem Projekt aktiviert ist, verwendet Cloud Composer die private IP-Adresse mit der DRS-Umgebungsarchitektur.

  In der Architektur der privaten IP-Adresse mit DRS-Umgebung:

  • Das Mandantenprojekt hostet eine Cloud SQL-Instanz, Cloud SQL Storage und zwei App Engine-Instanzen, auf denen der Airflow-Webserver ausgeführt wird.

  • Im Mandantenprojekt wird ein Bucket für eine zusätzliche Umgebung gehostet. Der Airflow-Webserver greift direkt auf diesen Bucket zu.

  • Das Kundenprojekt hostet alle anderen Komponenten der Umgebung.

  • Das Kundenprojekt hostet den Bucket-Synchronisierungsprozess im Cluster der Umgebung. Bei diesem Vorgang werden zwei Umgebungs-Buckets synchronisiert.

  • Airflow-Planer und -Worker stellen über den HAProxy-Prozess im Cluster der Umgebung eine Verbindung zur Airflow-Datenbank her.

  • Der HAProxy-Prozess verteilt den Traffic durch Load-Balancing auf die Cloud SQL-Instanz zwischen zwei Cloud SQL-Proxy-Instanzen, die sich im Mandantenprojekt befinden. Private IP-Umgebungen verwenden zwei Cloud SQL-Proxy-Instanzen, da das Kundenprojekt aufgrund von Netzwerkeinschränkungen nicht direkt auf die Datenbank zugreift. Es sind zwei Instanzen erforderlich, damit die Komponenten Ihrer Umgebung jederzeit auf die Datenbank zugreifen können.

  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