Freigeben über

Migrieren von Apache Kafka-Workloads zu Azure HDInsight 5.1

Azure HDInsight 5.1 enthält die neuesten Open-Source-Komponenten mit erheblichen Verbesserungen in Bezug auf Leistung, Konnektivität und Sicherheit. In diesem Artikel wird erläutert, wie Sie Apache Kafka-Workloads von HDInsight 4.0 (Kafka 2.1) zu HDInsight 5.1 (Kafka 3.2) migrieren.

Apache Kafka-Versionen

Apache Kafka 3.2.0

Wenn Sie zu Kafka 3.2.0 (HDI 5.1) migrieren, können Sie die folgenden neuen Funktionen nutzen:

  • Unterstützung automatisierter Consumer-Offsets mit clusterübergreifender Synchronisierung in MM 2.0, wodurch Migration und Failover von Consumern über Cluster hinweg vereinfacht werden (KIP-545).
  • Hinweis auf den Partitionsleiter, um die Partition wiederherzustellen: Ein neues Feature, mit dem der Controller mit einem neu gewählten Themenpartitionsleiter kommunizieren kann, um zu erfahren, ob der Zustand wiederhergestellt werden muss (KIP-704)
  • Unterstützt standardmäßig TLS 1.2 für sichere Kommunikation.
  • Entfernung der Zookeeper-Abhängigkeit: Produzenten und Consumer benötigen den Zookeeper-Parameter nicht mehr. Verwenden Sie für CLI-Befehle die Option --bootstrap-server anstelle von --zookeeper (KIP-500).
  • Konfigurierbare Backloggröße zum Erstellen von Acceptor: Eine neue Konfiguration, mit der die Größe des SYN-Backlogs für TCP-Acceptor-Sockets auf den Brokern festgelegt werden kann (KIP-764)
  • Fehlercodefeld auf oberster Ebene für DescribeLogDirsResponse: Ein neuer Fehlercode, der die DescribeLogDirs-API mit anderen APIs konsistent macht und das Zurückgeben anderer Fehler neben CLUSTER_AUTHORIZATION_FAILED ermöglicht (KIP-784)

Eine umfassende Liste der Aktualisierungen finden Sie in den Versionshinweisen zu Apache Kafka 3.2.0.

Kafka-Clientkompatibilität

Neue Kafka-Broker unterstützen ältere Clients. Mit KIP-35: Retrieving protocol version (Abrufen der Protokollversion) wurde ein Mechanismus zur dynamischen Bestimmung der Funktionalität eines Kafka-Brokers eingeführt. Mit KIP-97: Improved Kafka Client RPC Compatibility Policy (Kompatibilitätsrichtlinie für verbesserten Kafka-Client-RPC) wurden eine neue Kompatibilitätsrichtlinie und Garantien für den Java-Client eingeführt. Zuvor musste die Interaktion zwischen einem Kafka-Client und einem Broker derselben oder einer höheren Version erfolgen. Nun können neuere Versionen der Java-Clients und anderer Clients, die KIP-35 unterstützen, z. B. librdkafka, auf ältere Anforderungstypen zurückgreifen oder entsprechende Fehler auslösen, wenn die Funktionalität nicht verfügbar ist.

Screenshot shows Upgrade Kafka client compatibility.

Hinweis

Es wird empfohlen, die gleiche Version von Kafka-Client und -Cluster zu verwenden. Weitere Informationen finden Sie in der Kompatibilitätsmatrix.

Allgemeiner Migrationsvorgang

In der folgenden Migrationsanleitung wird davon ausgegangen, dass ein Apache Kafka 2.1.1-Cluster in HDInsight 4.0 in einem einzelnen virtuellen Netzwerk bereitgestellt wird. Der vorhandene Broker enthält einige Themen und wird von Producern und Consumern aktiv verwendet. Die Aktualisierung der Kafka-Version auf einem vorhandenen Cluster ist nicht möglich. Nachdem Sie einen Cluster mit HDI 5.1 erstellt haben, migrieren Sie die Kafka-Clients zur Verwendung des neuen Clusters.

Führen Sie zur Migration die folgenden Schritte aus:

  1. Stellen Sie einen neuen HDInsight 5.1-Cluster und entsprechende Clients zum Testen bereit. Stellen Sie einen neuen HDInsight 5.1-Kafka-Cluster bereit. Wenn mehrere Kafka-Clusterversionen ausgewählt werden können, empfiehlt sich die Auswahl der neuesten Version. Legen Sie nach der Bereitstellung einige Parameter fest, und erstellen Sie ein Thema mit dem gleichen Namen wie die vorhandene Umgebung. Legen Sie außerdem die TLS- und die Bring-Your-Own-Key-Verschlüsselung (BYOK) nach Bedarf fest. Überprüfen Sie dann, ob alles mit dem neuen Cluster ordnungsgemäß ausgeführt wird.

    Screenshot shows how to Deploy new HDInsight 5.1 clusters.

  2. Ändern Sie den Cluster für die Produceranwendung, und warten Sie, bis alle Warteschlangendaten von den aktuellen Consumern verarbeitet wurden: Wenn der neue Kafka-Cluster in HDInsight 5.1 verwendet werden kann, ändern Sie das vorhandene Producerziel in den neuen Cluster. Ändern Sie das Ziel erst, wenn die vorhandene Consumeranwendung alle Daten vom vorhandenen Cluster verarbeitet hat.

    Screenshot shows how to Switch cluster for producer app.

  3. Ändern Sie den Cluster für die Consumeranwendung: Nachdem Sie überprüft haben, ob die vorhandene Consumeranwendung alle Daten des vorhandenen Clusters genutzt hat, ändern Sie die Verbindung in den neuen Cluster.

    Screenshot shows how to Switch cluster on consumer app.

  4. Entfernen Sie den alten Cluster, und testen Sie die Anwendungen nach Bedarf: Wenn der Wechsel abgeschlossen ist und der Cluster ordnungsgemäß ausgeführt wird, entfernen Sie den alten HDInsight 4.0-Kafka-Cluster und die beim Testen verwendeten Producer und Consumer.

Nächste Schritte