Migration zu einem Amazon-MSK-Cluster - Amazon Managed Streaming für Apache Kafka
Migrieren Ihres Apache-Kafka-Clusters zu Amazon MSKMigration zwischen zwei Amazon-MSK-ClusternMirrorMaker 1.0 bewährte MethodenMirrorMaker 2.* Vorteile

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Migration zu einem Amazon-MSK-Cluster

Amazon MSK Replicator kann für die MSK-Cluster-Migration verwendet werden. Siehe Was ist Amazon MSK Replicator?. Alternativ können Sie Apache MirrorMaker 2.0 verwenden, um von einem Nicht-MSK-Cluster zu einem Amazon MSK-Cluster zu migrieren. Ein Beispiel dafür finden Sie unter Migrieren eines lokalen Apache Kafka-Clusters zu Amazon MSK mithilfe von. MirrorMaker Informationen zur Verwendung MirrorMaker finden Sie unter Spiegeln von Daten zwischen Clustern in der Apache Kafka-Dokumentation. Wir empfehlen die Einrichtung MirrorMaker in einer Konfiguration mit hoher Verfügbarkeit.

Eine Übersicht der Schritte, die bei der Migration MirrorMaker zu einem MSK-Cluster zu befolgen sind

  1. Erstellen Sie den MSK-Ziel-Cluster

  2. Starten Sie mit MirrorMaker einer Amazon EC2 EC2-Instance innerhalb derselben Amazon VPC wie der Ziel-Cluster.

  3. Untersuchen Sie die Verzögerung MirrorMaker .

  4. Leiten MirrorMaker Sie nach dem Aufholen die Produzenten und Verbraucher mithilfe der MSK-Cluster-Bootstrap-Broker zum neuen Cluster um.

  5. Herunterfahren. MirrorMaker

Migrieren Ihres Apache-Kafka-Clusters zu Amazon MSK

Angenommen, Sie haben einen Apache-Kafka-Cluster namens CLUSTER_ONPREM. Dieser Cluster wird mit Themen und Daten gefüllt. Wenn Sie diesen Cluster zu einem neu erstellten Amazon-MSK-Cluster mit dem Namen CLUSTER_AWSMSK migrieren möchten, bietet dieses Verfahren eine allgemeine Ansicht der auszuführenden Schritte.

So migrieren Sie Ihren vorhandenen Apache-Kafka-Cluster zu Amazon MSK

  1. Erstellen Sie in CLUSTER_AWSMSK alle Themen, die Sie migrieren möchten.

    Sie können diesen Schritt nicht verwenden MirrorMaker , da er die Themen, die Sie migrieren möchten, nicht automatisch mit der richtigen Replikationsebene neu erstellt. Sie können die Themen in Amazon MSK mit denselben Replikationsfaktoren und der Anzahl von Partitionen wie in CLUSTER_ONPREM erstellen. Sie können die Themen auch mit unterschiedlichen Replikationsfaktoren und Partitionszahlen erstellen.

  2. Beginnen Sie mit MirrorMaker einer Instanz, die Lese CLUSTER_ONPREM - und Schreibzugriff CLUSTER_AWSMSK hat.

  3. Führen Sie den folgenden Befehl aus, um alle Themen zu spiegeln:

    <path-to-your-kafka-installation>/bin/kafka-mirror-maker.sh --consumer.config config/mirrormaker-consumer.properties --producer.config config/mirrormaker-producer.properties --whitelist '.*'

    In diesem Befehl weist config/mirrormaker-consumer.properties auf einen Bootstrap-Broker in CLUSTER_ONPREM (z. B. bootstrap.servers=localhost:9092). Und config/mirrormaker-producer.properties zeigt auf einen Bootstrap-Broker in CLUSTER_AWSMSK; zum Beispiel. bootstrap.servers=10.0.0.237:9092,10.0.2.196:9092,10.0.1.233:9092

  4. Lassen Sie es im Hintergrund MirrorMaker laufen und verwenden Sie es weiter. CLUSTER_ONPREM MirrorMaker spiegelt alle neuen Daten wider.

  5. Überprüfen Sie den Fortschritt der Spiegelung, indem Sie die Verzögerung zwischen dem letzten Offset für jedes Thema und dem aktuellen Offset überprüfen, ab dem die Spiegelung verbraucht MirrorMaker wird.

    Denken Sie daran, MirrorMaker dass Sie lediglich einen Verbraucher und einen Hersteller verwenden. So können Sie die Verzögerung mit dem kafka-consumer-groups.sh-Werkzeug überprüfen. Um den Namen der Verbrauchergruppe zu finden, suchen Sie in der mirrormaker-consumer.properties-Datei nach der group.id und verwenden Sie den Wert. Wenn es keinen solchen Schlüssel in der Datei gibt, können Sie ihn erstellen. Legen Sie beispielsweise group.id=mirrormaker-consumer-group fest.

  6. Wenn Sie mit dem Spiegeln aller Themen MirrorMaker fertig sind, beenden Sie alle Produzenten und Verbraucher und hören Sie dann auf MirrorMaker. Leiten Sie dann die Produzenten und Konsumenten in den CLUSTER_AWSMSK-Cluster um, indem Sie die Werte der Produzenten und Konsumenten des Bootstrap-Brokers ändern. Starten Sie alle Produzenten und Konsumenten auf CLUSTER_AWSMSK neu.

Migration zwischen zwei Amazon-MSK-Clustern

Sie können Apache MirrorMaker 2.0 verwenden, um von einem Nicht-MSK-Cluster zu einem MSK-Cluster zu migrieren. Sie können beispielsweise von einer Version von Apache Kafka zu einer anderen migrieren. Ein Beispiel dafür finden Sie unter Migrieren eines lokalen Apache Kafka-Clusters zu Amazon MSK mithilfe von. MirrorMaker Als Alternative kann Amazon MSK Replicator für die MSK-Cluster-Migration verwendet werden. Weitere Informationen über Amazon MSK Replicator finden Sie unter MSKReplikator.

MirrorMaker 1.0 bewährte Methoden

Diese Liste mit bewährten Methoden gilt für MirrorMaker 1.0.

  • MirrorMaker Auf dem Zielcluster ausführen. Wenn ein Netzwerkproblem auftritt, sind die Nachrichten auf diese Weise weiterhin im Quell-Cluster verfügbar. Wenn Sie MirrorMaker auf dem Quellcluster ausführen und Ereignisse im Producer zwischengespeichert werden und es ein Netzwerkproblem gibt, gehen Ereignisse möglicherweise verloren.

  • Wenn während der Übertragung eine Verschlüsselung erforderlich ist, führen Sie diese im Quell-Cluster aus.

  • Legen Sie für Konsumenten „auto.commit.enabled=false“ fest.

  • Für Produzenten legen Sie Folgendes fest:

    • max.in.flight.requests.per.connection=1

    • retries=Int.Max_Value

    • acks=all

    • max.block.ms = Long.Max_Value

  • Für einen hohen Produzentendurchsatz:

    • Nachrichten puffern und Nachrichten-Batches füllen – buffer.memory, batch.size, linger.ms optimieren

    • Socket-Puffer optimieren – receive.buffer.bytes, send.buffer.bytes

  • Um Datenverlust zu vermeiden, schalten Sie das auto Commit an der Quelle aus, sodass die Commits gesteuert werden MirrorMaker können. Dies geschieht normalerweise, nachdem es das ACK vom Zielcluster erhalten hat. Wenn der Producer acks=all und der Zielcluster min.insync.replicas auf mehr als 1 gesetzt hat, werden die Nachrichten auf mehr als einem Broker am Ziel gespeichert, bevor der Verbraucher den Offset an der Quelle festschreibt. MirrorMaker

  • Wenn die Reihenfolge wichtig ist, können Sie die Wiederholungsversuche auf „0“ festlegen. Setzen Sie die maximalen Inflight-Verbindungen für eine Produktionsumgebung alternativ auf „1“, um sicherzustellen, dass die Commits für die versendeten Stapel in der richtigen Reihenfolge durchgeführt werden, falls ein Stapel in der Mitte ausfällt. Auf diese Weise wird jeder gesendete Stapel wiederholt, bis der nächste Stapel gesendet wird. Wenn „max.block.ms“ nicht auf den Maximalwert festgelegt ist und der Puffer des Produzenten voll ist, kann es zu Datenverlust kommen (abhängig von einigen der anderen Einstellungen). Dies kann den Konsumenten blockieren und Druck erzeugen.

  • Für hohen Durchsatz

    • Erhöhen Sie den Pufferspeicher.

    • Erhöhen Sie die Stapelgröße.

    • Passen Sie linger.ms an, damit die Stapel gefüllt werden können. Dies ermöglicht zudem eine bessere Komprimierung, weniger Auslastung der Netzwerkbandbreite und weniger Speicher auf dem Cluster. Dies führt zu einer erhöhten Retention.

    • Überwachen Sie die CPU- und Speichernutzung.

  • Für hohen Konsumentendurchsatz

    • Erhöhen Sie MirrorMaker die Anzahl der Threads/Verbraucher pro Prozess — num.streams.

    • Erhöhen Sie zunächst die Anzahl der MirrorMaker Prozesse auf allen Computern, bevor Sie die Anzahl der Threads erhöhen, um eine hohe Verfügbarkeit zu gewährleisten.

    • Erhöhen Sie die Anzahl der MirrorMaker Prozesse zuerst auf demselben Computer und dann auf verschiedenen Computern (mit derselben Gruppen-ID).

    • Isolieren Sie Themen mit sehr hohem Durchsatz und verwenden Sie separate MirrorMaker Instanzen.

  • Für Verwaltung und Konfiguration

    • AWS CloudFormation Verwendungs- und Konfigurationsmanagement-Tools wie Chef und Ansible.

    • Verwenden Sie Amazon-EFS-Mounts, um alle Konfigurationsdateien von allen Amazon-EC2-Instances aus zugänglich zu machen.

    • Verwenden Sie Container für die einfache Skalierung und Verwaltung von MirrorMaker Instanzen.

  • In der Regel braucht es mehr als einen Verbraucher, um einen Hersteller zu überzeugen. MirrorMaker Richten Sie also mehrere Konsumenten ein. Richten Sie sie zunächst auf verschiedenen Computern ein, um eine hohe Verfügbarkeit zu gewährleisten. Skalieren Sie dann einzelne Computer bis zu einem Konsumenten pro Partition, wobei die Konsumenten gleichmäßig auf die Computer verteilt sind.

  • Da die Standardwerte möglicherweise zu niedrig sind, optimieren Sie die Puffer für Empfangen und Senden, um einen hohen Durchsatz zu erreichen. Um eine maximale Leistung zu erzielen, stellen Sie sicher, dass die Gesamtzahl der Streams (num.streams) mit allen Themenpartitionen übereinstimmt, MirrorMaker die versucht werden, in den Zielcluster zu kopieren.

MirrorMaker 2.* Vorteile

  • Nutzt das Apache Kafka Connect-Framework und -Partnersystem.

  • Erkennt neue Themen und Partitionen.

  • Synchronisiert die Themenkonfiguration automatisch zwischen Clustern.

  • Unterstützt „aktiv/aktiv“-Clusterpaare sowie eine beliebige Anzahl aktiver Cluster.

  • Bietet neue Metriken, einschließlich der end-to-end Replikationslatenz über mehrere Rechenzentren und Cluster hinweg.

  • Gibt Offsets aus, die für die Migration von Konsumenten zwischen Clustern erforderlich sind, und stellt Werkzeuge für die Offset-Übertragung bereit.

  • Unterstützt eine Konfigurationsdatei auf hoher Ebene, mit der mehrere Cluster und Replikationsabläufe an einem zentralen Ort spezifiziert werden können, im Vergleich zu den Eigenschaften auf niedriger Ebene für jeden MirrorMaker 1.*-Prozess.