Migrieren von Apache Kafka-Workloads zu Azure HDInsight 4.0

Azure HDInsight 4.0 bietet die neuesten Open-Source-Komponenten mit erheblichen Verbesserungen bei Leistung, Konnektivität und Sicherheit. In diesem Dokument wird erläutert, wie Apache Kafka-Workloads auf HDInsight 3.6 zu HDInsight 4.0 migriert werden. Nachdem Sie Ihre Workloads zu HDInsight 4.0 migriert haben, können Sie viele der neuen Features verwenden, die in HDInsight 3.6 nicht verfügbar sind.

HDInsight 3.6 Kafka-Migrationspfade

HDInsight 3.6 unterstützt zwei Versionen von Kafka: 1.0.0 und 1.1.0. HDInsight 4.0 unterstützt Die Versionen 1.1.0 und 2.1.0. Je nachdem, welche Version von Kafka und welche Version von HDInsight Sie ausführen möchten, gibt es mehrere unterstützte Migrationspfade. Diese Pfade werden unten erläutert und im folgenden Diagramm veranschaulicht.

• Führen Sie sowohl Kafka als auch HDInsight auf den neuesten Versionen aus (empfohlen):Migrieren Sie eine HDInsight 3.6- und Kafka 1.0.0- oder 1.1.0-Anwendung auf HDInsight 4.0 mit Kafka 2.1.0 (Pfade D und E unten).
• Führen Sie HDInsight auf der neuesten Version aus, aber Kafka nur auf einer neueren Version: Migrieren Sie eine HDInsight 3.6- und Kafka 1.0.0-Anwendung zu HDInsight 4.0 mit Kafka 1.1.0 (Pfad B unten).
• Führen Sie HDInsight auf der neuesten Version aus, behalten Sie Kafka-Version bei: Migrieren Sie eine HDInsight 3.6- und Kafka 1.1.0-Anwendung zu HDInsight 4.0 mit Kafka 1.1.0 (Pfad C unten).
• Führen Sie Kafka auf einer neueren Version aus, behalten Sie HDInsight-Version bei: Migrieren Sie eine Kafka 1.0.0-Anwendung zu 1.1.0, und bleiben Sie auf HDInsight 3.6 (Pfad A unten). Beachten Sie, dass für diese Option weiterhin eine Bereitstellung eines neuen Clusters erforderlich ist. Das Upgrade der Kafka-Version auf einem vorhandenen Cluster wird nicht unterstützt. Nachdem Sie einen Cluster mit der gewünschten Version erstellt haben, migrieren Sie Ihre Kafka-Clients, um den neuen Cluster zu verwenden.

Apache Kafka-Versionen

Kafka 1.1.0

Wenn Sie von Kafka 1.0.0 auf 1.1.0 migrieren, können Sie die folgenden neuen Features nutzen:

• Verbesserungen am Kafka-Controller beschleunigen das kontrollierte Herunterfahren, sodass Sie Broker neu starten und sich von Problemen schneller erholen können.
• Verbesserungen in der FetchRequests-Logik , mit der Sie mehr Partitionen (und damit mehr Themen) auf dem Cluster haben können.
• Kafka Connect unterstützt Datensatzheader und reguläre Ausdrücke für Themen.

Eine vollständige Liste der Updates finden Sie in den Versionshinweisen zu Apache Kafka 1.1.

Apache Kafka 2.1.0

Wenn Sie zu Kafka 2.1 migrieren, können Sie die folgenden Features nutzen:

• Bessere Brokerresilienz aufgrund eines verbesserten Replikationsprotokolls.
• Neue Funktionalität in der KafkaAdminClient-API.
• Konfigurierbare Kontingentverwaltung.
• Unterstützung für Zstandard-Komprimierung.

Eine vollständige Liste der Updates finden Sie in den Versionshinweisen zu Apache Kafka 2.0 und Apache Kafka 2.1 Versionshinweisen.

Kafka-Clientkompatibilität

Neue Kafka-Broker unterstützen ältere Kunden. KIP-35 – Das Abrufen der Protokollversion hat einen Mechanismus eingeführt, mit dem die Funktionalität eines Kafka-Brokers und eines KIP-97-Clients dynamisch bestimmt wird: Verbesserte Kafka-Client-RPC-Kompatibilitätsrichtlinie führte eine neue Kompatibilitätsrichtlinie und Garantien für den Java-Client ein. Zuvor musste ein Kafka-Client mit einem Broker derselben Version oder einer neueren Version interagieren. 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.

Beachten Sie, dass es nicht bedeutet, dass der Client ältere Broker unterstützt. Weitere Informationen finden Sie unter Compatibility Matrix.

Allgemeiner Migrationsprozess

Der folgende Migrationsleitfaden setzt voraus, dass ein Apache Kafka 1.0.0- oder 1.1.0-Cluster auf HDInsight 3.6 in einem einzigen virtuellen Netzwerk bereitgestellt wird. Der bestehende Broker hat einige Themen und wird aktiv von Produzenten und Verbrauchern genutzt.

Führen Sie die folgenden Schritte aus, um die Migration abzuschließen:

1. Stellen Sie einen neuen HDInsight 4.0-Cluster und -Clients zum Testen bereit. Stellen Sie einen neuen HDInsight 4.0 Kafka-Cluster bereit. Wenn mehrere Kafka-Clusterversionen ausgewählt werden können, empfiehlt es sich, die neueste Version auszuwählen. Legen Sie nach der Bereitstellung einige Parameter nach Bedarf fest, und erstellen Sie ein Thema mit demselben Namen wie Ihre vorhandene Umgebung. Legen Sie auch TLS fest, und bringen Sie die BYOK-Verschlüsselung (Bring-your-own-key) nach Bedarf ein. Überprüfen Sie dann, ob sie mit dem neuen Cluster ordnungsgemäß funktioniert.

   

2. Wechseln Sie den Cluster für die Produzentenanwendung, und warten Sie, bis alle Warteschlangendaten von den aktuellen Verbrauchern verarbeitet werden. Wenn der neue Kafka-Cluster in HDInsight 4.0 verwendet werden kann, ändern Sie das vorhandene Producerziel in den neuen Cluster. Lassen Sie es unverändert, bis die vorhandene Consumer-App alle Daten aus dem vorhandenen Cluster verbraucht hat.

   

3. Schalten Sie den Cluster in der Verbraucheranwendung um. Nachdem sie bestätigt haben, dass die vorhandene Consumeranwendung die Nutzung aller Daten aus dem vorhandenen Cluster abgeschlossen hat, wechseln Sie die Verbindung zum neuen Cluster.

   

4. Entfernen Sie nach Bedarf den alten Cluster und testen Sie Anwendungen. Sobald der Schalter abgeschlossen ist und ordnungsgemäß funktioniert, entfernen Sie den alten HDInsight 3.6 Kafka Cluster und die Hersteller und Verbraucher, die bei Bedarf im Test verwendet werden.

Nächste Schritte

• Leistungsoptimierung für Apache Kafka HDInsight-Cluster
• Schnellstart: Erstellen eines Apache Kafka-Clusters in Azure HDInsight mithilfe des Azure-Portals