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
Eine Übersicht der Schritte, die bei der Migration MirrorMaker zu einem MSK-Cluster zu befolgen sind
Erstellen Sie den MSK-Ziel-Cluster
Starten Sie mit MirrorMaker einer Amazon EC2 EC2-Instance innerhalb derselben Amazon VPC wie der Ziel-Cluster.
-
Untersuchen Sie die Verzögerung MirrorMaker .
-
Leiten MirrorMaker Sie nach dem Aufholen die Produzenten und Verbraucher mithilfe der MSK-Cluster-Bootstrap-Broker zum neuen Cluster um.
-
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
-
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. -
Beginnen Sie mit MirrorMaker einer Instanz, die Lese
CLUSTER_ONPREM
- und SchreibzugriffCLUSTER_AWSMSK
hat. -
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 inCLUSTER_ONPREM
(z. B.bootstrap.servers=localhost:9092
). Undconfig/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
-
Lassen Sie es im Hintergrund MirrorMaker laufen und verwenden Sie es weiter.
CLUSTER_ONPREM
MirrorMaker spiegelt alle neuen Daten wider. -
Ü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 dermirrormaker-consumer.properties
-Datei nach dergroup.id
und verwenden Sie den Wert. Wenn es keinen solchen Schlüssel in der Datei gibt, können Sie ihn erstellen. Legen Sie beispielsweisegroup.id=mirrormaker-consumer-group
fest. -
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 aufCLUSTER_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.