Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Connect-Cluster erstellen

Ein Connect-Cluster bietet eine Umgebung für Connectors, mit denen Daten aus vorhandenen Kafka-Bereitstellungen in einen Google Cloud Managed Service for Apache Kafka-Cluster oder Daten aus einem Managed Service for Apache Kafka-Cluster in einen anderen Google Cloud -Dienst oder einen anderen Kafka-Cluster verschoben werden können. Der sekundäre Kafka-Cluster kann ein anderer Google Cloud Managed Service for Apache Kafka-Cluster, ein selbstverwalteter oder ein lokaler Cluster sein.

Hinweis

Sie müssen bereits einen Managed Service for Apache Kafka-Cluster erstellt haben. Sie benötigen den Namen des Managed Service for Apache Kafka-Clusters, an den der Connect-Cluster angehängt werden soll.

Jeder Connect-Cluster ist mit einem Managed Service for Apache Kafka-Cluster verknüpft. In diesem Cluster wird der Status der Connectors gespeichert, die im Connect-Cluster ausgeführt werden.

Erforderliche Rollen und Berechtigungen zum Erstellen eines Connect-Clusters

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Managed Kafka Connect Cluster Editor (roles/managedkafka.connectClusterEditor) für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen eines Connect-Clusters benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierte Rolle enthält die Berechtigungen, die zum Erstellen eines Connect-Clusters erforderlich sind. Maximieren Sie den Abschnitt Erforderliche Berechtigungen, um die notwendigen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind zum Erstellen eines Connect-Clusters erforderlich:

Erteilen Sie die Berechtigung zum Erstellen eines Connect-Clusters am angegebenen Standort: managedkafka.connectClusters.create

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Erforderliche ACL-Hauptkonten

Standardmäßig gewähren Managed Service for Apache Kafka-Cluster Connect-Clustern Zugriff auf Ressourcen, wenn keine ACLs konfiguriert sind. Dazu wird allow.everyone.if.no.acl.found auf true gesetzt, was der Standardeinstellung entspricht.

Wenn für den Managed Service for Apache Kafka-Cluster jedoch ACLs konfiguriert sind, hat der Connect-Cluster nicht automatisch Lese- und Schreibberechtigungen für die Ressourcen. Sie müssen sie manuell gewähren.

Das Connect-Cluster-Dienstkonto, das als Hauptkonto in ACLs verwendet wird, hat das folgende Format: User:service-{consumer project number}@gcp-sa-managedkafka.iam.gserviceaccount.com.

Wenn Sie ACLs für Ihren Kafka-Cluster konfiguriert haben, gewähren Sie dem Connect-Cluster mit den folgenden Befehlen Lese- und Schreibberechtigungen für Themen und Leseberechtigungen für Nutzergruppen:

/bin/kafka-acls.sh \
    --bootstrap-server BOOTSTRAP_ADDR \
    --command-config PATH_TO_CLIENT_PROPERTIES \
    --add \
    --allow-principal User:service-{consumer project number}@gcp-sa-managedkafka.iam.gserviceaccount.com \
    --operation READ --operation WRITE --topic *

/bin/kafka-acls.sh \
    --bootstrap-server BOOTSTRAP_ADDR \
    --command-config PATH_TO_CLIENT_PROPERTIES \
    --add \
    --allow-principal User:service-{consumer project number}@gcp-sa-managedkafka.iam.gserviceaccount.com \
    --operation READ --group *

Weitere Informationen zu diesen Befehlen finden Sie unter Apache Kafka-ACLs für eine detaillierte Zugriffssteuerung konfigurieren.

Connect-Cluster in einem anderen Projekt erstellen

Managed Service for Apache Kafka verwendet einen Dienst-Agent, um aufGoogle Cloud -Ressourcen zuzugreifen. Der Dienst-Agent ist mit dem Projekt verknüpft, in dem Sie den Cluster erstellen.

Wenn Sie einen Connect-Cluster in einem anderen Projekt als dem Managed Service for Apache Kafka-Cluster erstellen, verwenden der Connect-Cluster und der Kafka-Cluster die Dienst-Agents, die mit ihren jeweiligen Projekten verknüpft sind. In diesem Fall benötigt der Dienst-Agent für den Connect-Cluster die Berechtigung, auf Google Cloud -Ressourcen im Projekt des Kafka-Clusters zuzugreifen.

Weisen Sie dem Dienst-Agent des Connect-Clusters im Projekt des Kafka-Clusters die Rolle Managed Kafka Service Agent zu, um die erforderlichen Berechtigungen zu erteilen. Wenn Sie beispielsweise einen Kafka-Cluster im Projekt kafka-project und einen Connect-Cluster im Projekt connect-project erstellen, weisen Sie dem Dienst-Agent, der mit connect-project verknüpft ist, die Rolle „Managed Kafka Service Agent“ für kafka-project zu.

Die E-Mail-Adresse des Dienst-Agents hat das folgende Format: service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com, wobei PROJECT_NUMBER die Projektnummer ist. Weitere Informationen zum Zuweisen der Rolle finden Sie unter Rollen erstellen und Dienst-Agents zuweisen.

Eigenschaften eines Connect-Clusters

In diesem Abschnitt werden die Attribute eines Connect-Clusters beschrieben.

Name des Connect-Clusters

Der Name des Connect-Clusters, den Sie erstellen. Tipps zum Benennen von Connect-Clustern finden Sie in den Richtlinien zum Benennen einer Ressource von Managed Service for Apache Kafka. Der Name eines Clusters ist unveränderlich.

Primärer Kafka-Cluster

Der Managed Service for Apache Kafka-Cluster, der mit Ihrem Connect-Cluster verknüpft ist. In diesem verknüpften Cluster (primärer Cluster) wird der Status der Connectors gespeichert, die im Connect-Cluster ausgeführt werden. In der Regel dient der primäre Managed Service for Apache Kafka-Cluster auch als Ziel für alle Quell-Connectors und als Eingabe für alle Senken-Connectors, die im Connect-Cluster ausgeführt werden.

Ein einzelner Managed Service for Apache Kafka-Cluster kann mehrere Connect-Cluster haben. Wenn Sie einen Managed Service for Apache Kafka-Cluster in einem anderen Projekt auswählen, müssen die entsprechenden Berechtigungen konfiguriert sein.

Nachdem Sie den Connect-Cluster erstellt haben, können Sie nicht mehr zu einem anderen Kafka-Cluster wechseln.

Vorteile der Colocation in einer Region für Latenz und Netzwerkkosten

Wenn Sie Ihre Managed Service for Apache Kafka- und Connect-Cluster in derselben Region platzieren, werden Latenz und Netzwerkkosten reduziert. Angenommen, Ihr Managed Service for Apache Kafka-Cluster befindet sich in region-a und Sie verwenden einen Senken-Connector, um Daten aus diesem Managed Service for Apache Kafka-Cluster (Quelle) in eine BigQuery-Tabelle (Senke) zu schreiben, die sich ebenfalls in region-a befindet. Wenn Sie Ihren Connect-Cluster in region-a bereitstellen, wird die Latenz für den BigQuery-Schreibvorgang minimiert und die Kosten für die Netzwerkübertragung zwischen Regionen zwischen dem Managed Service for Apache Kafka-Cluster und dem Connect-Cluster werden eliminiert.

Latenz- und Kostenaspekte bei mehreren Systemen

Kafka Connect verwendet Connectors, um Daten zwischen Systemen zu verschieben. Eine Seite des Connectors interagiert immer mit einem Managed Service for Apache Kafka-Cluster. In einem einzelnen Kafka Connect-Cluster können mehrere Connectors ausgeführt werden, die entweder als Quelle (Daten aus einem System abrufen) oder als Senke (Daten an ein System übertragen) fungieren.

Ein Connect-Cluster in derselben Region wie der Managed Service for Apache Kafka-Cluster profitiert von einer geringeren Kommunikationslatenz zwischen den beiden Clustern. Jeder Connector interagiert jedoch auch mit einem anderen System, z. B. einer BigQuery-Tabelle oder einem anderen Kafka-Cluster. Auch wenn sich der Connect-Cluster und der Managed Service for Apache Kafka-Cluster am selben Standort befinden, kann sich das andere System in einer anderen Region befinden. Dies führt zu höherer Latenz und höheren Kosten. Die Gesamtlatenz der Pipeline hängt von den Standorten aller drei Systeme ab: dem Managed Service for Apache Kafka-Cluster, dem Connect-Cluster und dem Quell- oder Zielsystem.

Wenn sich Ihr Managed Service for Apache Kafka-Cluster beispielsweise in region-a, Ihr Connect-Cluster in region-b und Sie einen Cloud Storage-Connector für einen Bucket in region-c verwenden, werden Ihnen zwei Netzwerksprünge in Rechnung gestellt (region-a zu region-b und dann region-b zu region-c oder umgekehrt, je nach Connector-Richtung).

Berücksichtigen Sie bei der Planung der Connect-Clusterplatzierung alle beteiligten Regionen, um sowohl die Latenz als auch die Kosten zu optimieren.

Kapazitätskonfiguration

Im Rahmen der Kapazitätskonfiguration müssen Sie die Anzahl der vCPUs und die Größe des Arbeitsspeichers pro vCPU für den Connect-Cluster festlegen. Sie können die Kapazität eines Connect-Clusters nach dem Erstellen aktualisieren. Im Folgenden sind die Attribute für die Kapazitätskonfiguration aufgeführt:

vCPUs: Die Anzahl der vCPUs, die einem Connect-Cluster zugewiesen sind. Der Mindestwert beträgt 3 vCPUs.
Arbeitsspeicher: Die Menge an Arbeitsspeicher, die jeder vCPU zugewiesen wird. Sie müssen zwischen 1 GiB und 8 GiB pro vCPU bereitstellen. Die Arbeitsspeichermenge kann nach dem Erstellen des Clusters innerhalb dieser Grenzen erhöht oder verringert werden.

Wenn Sie beispielsweise einen Cluster mit 6 vCPUs erstellen, beträgt der Mindestspeicher, den Sie dem Cluster zuweisen können, 6 GiB (1 GiB pro vCPU) und der maximale Speicher 48 GiB (8 GiB pro vCPU).

Die vCPU und der Arbeitsspeicher, die jedem Worker in einem Connect-Cluster zugewiesen sind, haben erhebliche Auswirkungen auf die Leistung, Kapazität und Kosten des Clusters. Hier finden Sie eine Übersicht darüber, wie sich vCPU und Arbeitsspeicher auf einen Connect-Cluster auswirken.

vCPU Anzahl

Kafka Connect unterteilt die Arbeit eines Connectors in Aufgaben. Jede Aufgabe kann Daten parallel verarbeiten. Mehr vCPUs bedeuten, dass mehr Aufgaben gleichzeitig ausgeführt werden können, was zu einem höheren Durchsatz führt.
Mehr vCPUs erhöhen die Kosten für Ihren Connect-Cluster.

Arbeitsspeicher

Kafka Connect verwendet Arbeitsspeicher, um Daten zu puffern, während sie zwischen Connectors und Managed Service for Apache Kafka übertragen werden. Ein größerer Arbeitsspeicher ermöglicht größere Puffer. Ein großer Arbeitsspeicher kann den Durchsatz verbessern, insbesondere bei Datenstreams mit hohem Volumen. Connectors, die sehr große Nachrichten oder Datensätze verarbeiten, benötigen ausreichend Arbeitsspeicher, um sie ohne OutOfMemoryError-Ausnahmen zu verarbeiten.
Mehr Arbeitsspeicher erhöht die Kosten für Ihren Connect-Cluster.
Wenn Sie eine komplexe Transformationslogik verwenden, benötigen Sie mehr Arbeitsspeicher.

Ihr Ziel ist es, die richtige Kapazitätskonfiguration für Ihren Connect-Cluster auszuwählen. Dazu müssen Sie den Durchsatz kennen, den Ihr Connect-Cluster verarbeiten kann.

Worker-Subnetz (primär)

Das Worker-Subnetz, auch als primäres Subnetz bezeichnet, verbindet Ihr VPC-Netzwerk mit dem Connect-Cluster. Über dieses Subnetz können die Cluster-Worker die Endpunkte von Quellen und Senken im Nutzernetzwerk erreichen, z. B. Managed Service for Apache Kafka-Cluster oder selbst gehostete Kafka-Cluster.

Hier sind einige Anforderungen für die Konfiguration des Worker-Subnetzes:

Das Worker-Subnetz ist erforderlich.
Das Subnetz muss sich in derselben Region wie der Connect-Cluster befinden.
Das Subnetz muss sich in derselben übergeordneten VPC wie eines der verbundenen Subnetze des primären Kafka-Clusters befinden.
Der CIDR-Bereich des Subnetzes muss mindestens /22 (1.024 Adressen) groß sein.

Den Cluster-Workern werden IP-Adressen im Worker-Subnetz über eine Private Service Connect-Schnittstelle zugewiesen. Worker können jedes Netzwerkziel erreichen, das über das VPC-Netzwerk des Subnetzes zugänglich ist. Dabei gelten die folgenden Anforderungen:

Der Endpunkt darf sich nicht im CIDR-Bereich 172.16.0.0/14 befinden. Dieser Bereich ist für die interne Verwendung von Managed Service for Apache Kafka Connect reserviert.
Firewallregeln müssen den Traffic zulassen. Weitere Informationen finden Sie unter Sicherheit für Netzwerkanhänge konfigurieren.
Für Internettraffic müssen Sie eine Cloud NAT konfigurieren. Eine Cloud NAT ist beispielsweise für einen MirrorMaker-Connector erforderlich, um Daten aus einem Kafka-Cluster zu replizieren, auf den über das Internet zugegriffen werden kann.
Wenn Sie auf Private Service Connect-Endpunkte zugreifen möchten, die sich in einer anderen VPC als der VPC des Worker-Subnetzes befinden, müssen Sie eine unterstützte Nutzerkonfiguration verwenden (z. B. NCC). Weitere Informationen finden Sie unter Zugriff auf veröffentlichte Dienste über Endpunkte.

Auflösbare DNS-Domains

Mit auflösbaren DNS-Domains, auch als DNS-Domainnamen bezeichnet, können DNS-Adressen im Nutzer-VPC-Netzwerk für die Mandanten-VPC verfügbar gemacht werden. Dadurch kann der Connect-Cluster DNS-Namen in IP-Adressen auflösen, was die Kommunikation mit anderen Diensten erleichtert, einschließlich anderer Kafka-Cluster für MirrorMaker-Connectors.

Für auflösbare DNS-Domains können Sie einen Managed Service for Apache Kafka-Cluster auswählen. Sie müssen den DNS-Domainnamen für den primären Managed Service for Apache Kafka-Cluster nicht konfigurieren, da die Bootstrap-Adresse automatisch in die Liste der auflösbaren DNS-Domains aufgenommen wird.

Sie können eine DNS-Domain aber auch manuell angeben. Das ist erforderlich, wenn Sie einen externen Kafka-Cluster auswählen. Die DNS-Domain des primären Managed Service for Apache Kafka-Clusters wird automatisch hinzugefügt. Für andere Kafka-Cluster müssen weiterhin DNS-Domains konfiguriert werden.

Secret Manager-Ressourcen

Für einige Connectors sind vertrauliche Daten wie Passwörter als Teil ihrer Konfiguration erforderlich. Wenn Sie diese Art von Daten sicher verwalten möchten, können Sie sie in Secret Manager speichern und dem Connect-Cluster Zugriff auf das Secret gewähren.

So verwenden Sie Secret Manager-Secrets mit Kafka Connect:

Weisen Sie dem Managed Kafka-Dienstkonto die folgenden IAM-Rollen zu. Mit diesen Rollen kann Ihr Connect-Cluster Secrets aufrufen und auf deren Nutzlasten zugreifen.
- Secret Manager-Betrachter (roles/secretmanager.viewer)
- Zugriffsperson für Secret Manager-Secret (roles/secretmanager.secretAccessor)
Erstellen Sie ein Secret, das die sensiblen Daten enthält. Weitere Informationen finden Sie unter Secret erstellen.
Wenn Sie Ihren Connect-Cluster erstellen oder aktualisieren, geben Sie die Secrets an, auf die der Cluster Zugriff hat. Sie können bis zu 32 Secrets pro Connect-Cluster angeben.

Secrets werden als Dateien in den Cluster-Workern bereitgestellt. Connectors haben nur Lesezugriff auf diese Dateien. Wenn Sie einen Connector erstellen, können die Konfigurationsattribute des Connectors auf die Secrets verweisen.

Verwenden Sie das folgende Format, um auf den Pfad zu einer Secret-Datei zu verweisen:
```
/var/secrets/PROJECT_NAME-SECRET_NAME-SECRET_VERSION
```
Beispiel: ssl.truststore.location=/var/secrets/project1-truststore-1
Wenn Sie den Wert eines Secrets als Konfigurationswert (z. B. ein Passwort) verwenden möchten, verwenden Sie das folgende Format:
```
${directory:/var/secrets:PROJECT_NAME-SECRET_NAME-SECRET_VERSION}
```
Beispiel: password=${directory:/var/secrets:project1-database_password-3}

Ersetzen Sie Folgendes:

PROJECT_NAME: Der Name des Google Cloud -Projekts.
SECRET_NAME: Der Name des Secrets.
SECRET_VERSION: Die Secret-Version.

Labels

Labels sind Schlüssel/Wert-Paare, die Ihnen bei der Organisation und Identifizierung helfen. Sie helfen Ihnen beim Organisieren von Connect-Clustern. Sie können jedem Connect-Cluster ein Label zuweisen und dann die Ressourcen nach Labels filtern. Beispiele für Labels sind environment:prod, application:web-app.