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.
Migrieren Sie von Apache Kafka-Clustern, die nicht von MSK stammen, zu Amazon MSK Provisioned
Sie können MSK Replicator verwenden, um Apache Kafka-Workloads von selbstverwalteten Umgebungen zu Amazon MSK Provisioned Clustern zu migrieren. MSK Replicator unterstützt die Datenmigration aus Kafka-Bereitstellungen (Kafka Version 2.8.1 oder höher), für die die gegenseitige TLS- (mTLS) - oder (OAuth) -Authentifizierung SASL/SCRAM aktiviert ist. SASL/OAUTHBEARER
Anmerkung
SASL/SCRAM, mTLS oder SASL/OAUTHBEARER Authentifizierung ist nur erforderlich, damit MSK Replicator eine Verbindung zu Ihrem selbstverwalteten Kafka-Cluster herstellen kann. Ihre Client-Anwendungen können weiterhin ihre vorhandenen Authentifizierungsmechanismen verwenden.
Voraussetzungen
Bevor Sie beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:
Quell-Cluster Apache Kafka, auf dem Version 2.8.1 oder höher ausgeführt wird
SASL/SCRAM, mTLS oder SASL/OAUTHBEARER Authentifizierung auf dem Quellcluster aktiviert
Die SSL-Verschlüsselung ist auf dem Quellcluster konfiguriert
Netzwerkkonnektivität über AWS Site-to-Site VPN oder AWS Direct Connect
VPC-Subnetze, die für den Zugriff auf Secrets Manager konfiguriert sind
Detaillierte Anweisungen finden Sie unter Richten Sie die Voraussetzungen für MSK Replicator mit selbstverwalteten Apache Kafka-Clustern ein.
Schritt 1: Erstellen Sie einen von Amazon MSK bereitgestellten Cluster
Erstellen Sie einen von MSK bereitgestellten Cluster mit aktivierter IAM-Authentifizierung. Mindestens drei Broker in drei AZs. Siehe Bereiten Sie den Zielcluster vor.
Schritt 2: Erstellen Sie eine IAM-Ausführungsrolle
Hängen Sie die AWSMSKReplicatorExecutionRole verwaltete Richtlinie an und konfigurieren Sie die Vertrauensrichtlinie fürkafka.amazonaws.com. Fügen Sie Inline-Berechtigungen für AWS Secrets Manager (und AWS KMS falls es Ihre Geheimnisse sind CMK-encrypted) per hinzuZusätzliche SER-Berechtigungen für SASL/SCRAM, mTLs und vom SASL/OAUTHBEARER Kunden verwaltete Schlüssel. Siehe Richten Sie die Voraussetzungen für MSK Replicator mit selbstverwalteten Apache Kafka-Clustern ein.
Schritt 3: Konfiguration SASL/SCRAM, mTLS oder SASL/OAUTHBEARER, und SSL auf einem selbstverwalteten Cluster
Konfigurieren Sie die Authentifizierung auf Ihrem selbstverwalteten Cluster. Erstellen Sie SASL/SCRAM beispielsweise einen dedizierten SCRAM-Benutzer mit den erforderlichen ACL-Berechtigungen. Konfigurieren Sie für mTLs einen SSL-Listener mit Client-Zertifikatsauthentifizierung. Konfigurieren Sie SASL/OAUTHBEARER beispielsweise Ihre Broker für OAUTHBEARER und registrieren Sie den Identitätsanbieter (IDP), der Zugriffstoken verkauft. Konfigurieren Sie SSL-Zertifikate. Siehe Richten Sie die Voraussetzungen für MSK Replicator mit selbstverwalteten Apache Kafka-Clustern ein.
Schritt 4: Speichern Sie Anmeldeinformationen in AWS Secrets Manager
Erstellen Sie ein Geheimnis mit den entsprechenden Schlüssel-Wert-Paaren für Ihren Authentifizierungstyp. Felder „Für“ SASL/SCRAM, „Einschließenusername“ und certificate „“. password Für mTLs schließen Sie privateKey Felder ein certificate und ein (und optional privateKeyPassword für verschlüsselte private Schlüssel). Um den Mechanismus für Client-Anmeldeinformationen zu SASL/OAUTHBEARER verwenden, schließen Sie client_secret Felder ein client_id und ein. Siehe Richten Sie die Voraussetzungen für MSK Replicator mit selbstverwalteten Apache Kafka-Clustern ein.
Schritt 5: Erstellen Sie den Replikator
Verwenden Sie die CreateReplicator API mit der EARLIEST Startposition, der Replikation des identischen Themennamens und der synchroniseConsumerGroupOffsets Einstellung auftrue. Der IAM-Prinzipal, der aufruft, CreateReplicator muss über die unter beschriebenen API-Aufruferberechtigungen verfügen. Zum Erstellen eines MSK-Replikators sind IAM-Berechtigungen erforderlich Wenn Sie beabsichtigen, die bidirektionale Replikation für die Rollback-Funktion einzurichten (Schritt 6), stellen consumerGroupOffsetSyncMode Sie diese Option auch für den Vorwärts- und ENHANCED Rückwärts-Replikator ein. Warten Sie etwa 30 Minuten, bis der Replicator den Status RUNNING erreicht hat. Siehe CreateReplicator API-Beispiele für selbstverwaltete Kafka-Cluster.
Schritt 6: (Optional) Richten Sie die bidirektionale Replikation ein
Erstellen Sie für Rollback-Funktionen einen Reverse-Replicator aus dem von MSK bereitgestellten Cluster zurück zum selbstverwalteten Cluster. Identifizieren Sie beide Cluster im Reverse Replicator genau so, wie Sie sie im Forward Replicator identifiziert haben. Siehe Beispiel für bidirektionale Replikation.
Schritt 7: Überwachen Sie den Fortschritt der Replikation
Überwachen Sie die folgenden Metriken:
MessageLag(sollte 0 erreichen)ReplicationLatencyConsumerGroupOffsetSyncFailure(sollte 0 sein)ConsumerGroupCountOffsetLag (MSK Cluster)undOffsetLag (Non-MSK Cluster)
Weitere Informationen finden Sie unter Überwachung einer Replikation.
Schritt 8: Anwendungen migrieren
Folgen Sie diesen Schritten, um Ihre Anwendungen zu migrieren:
Halten Sie Produzenten davon ab, in selbstverwaltete Cluster zu schreiben
Konfigurieren Sie die Produzenten für den von MSK bereitgestellten Cluster mit IAM-Authentifizierung neu
Überwachen Sie
MessageLag, bis 0 erreicht istStoppen Sie die Nutzung von Verbrauchern im selbstverwalteten Cluster
Konfigurieren Sie die Verbraucher für den von MSK bereitgestellten Cluster neu
Schritt 9: (Optional) Führen Sie ein Rollback zum selbstverwalteten Cluster durch
Wenn die bidirektionale Replikation konfiguriert wurde, können Sie die Migrationsschritte rückgängig machen, um ein Rollback zum selbstverwalteten Cluster durchzuführen. Der Reverse-Replicator (MSK Provisioned → External) hat den selbstverwalteten Cluster synchron gehalten, sodass die Verbraucher ohne Datenverlust zurückgeleitet werden können.
