View a markdown version of this page

Migrer depuis des clusters Apache Kafka autres que MSK vers Amazon MSK Provisioned - Amazon Managed Streaming for Apache Kafka

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Migrer depuis des clusters Apache Kafka autres que MSK vers Amazon MSK Provisioned

Vous pouvez utiliser MSK Replicator pour migrer les charges de travail Apache Kafka depuis des environnements autogérés vers des clusters Amazon MSK Provisioned. MSK Replicator prend en charge la migration de données à partir de déploiements Kafka (Kafka version 2.8.1 ou ultérieure) sur lesquels l'authentification TLS mutuelle (mTLS) ou (OAuth) est activée. SASL/SCRAM SASL/OAUTHBEARER

Note

SASL/SCRAM, mTLS ou SASL/OAUTHBEARER l'authentification est requise uniquement pour que MSK Replicator puisse se connecter à votre cluster Kafka autogéré. Vos applications clientes peuvent continuer à utiliser leurs mécanismes d'authentification existants.

Conditions préalables

Avant de commencer, assurez-vous de disposer des éléments suivants :

  1. Cluster Apache Kafka source exécutant la version 2.8.1 ou ultérieure

  2. SASL/SCRAM, mTLS ou SASL/OAUTHBEARER authentification activée sur le cluster source

  3. Chiffrement SSL configuré sur le cluster source

  4. Connectivité réseau via AWS Site-to-Site VPN ou AWS Direct Connect

  5. Sous-réseaux VPC configurés pour l'accès à Secrets Manager

Pour obtenir des instructions complètes, consultez Configuration des prérequis pour MSK Replicator avec des clusters Apache Kafka autogérés.

Étape 1 : Création d'un cluster Amazon MSK Provisioned

Créez un cluster MSK Provisioned avec l'authentification IAM activée. Minimum de trois courtiers répartis sur trois zones de couverture. Consultez Préparer le cluster cible.

Étape 2 : Création d'un rôle d'exécution IAM

Joignez la politique AWSMSKReplicatorExecutionRole gérée et configurez la politique de confiance pourkafka.amazonaws.com. Ajoutez des autorisations en ligne pour AWS Secrets Manager (et AWS KMS si vos secrets le sont CMK-encrypted) par. Autorisations SER supplémentaires pour SASL/SCRAM les clés mTL et gérées par le client SASL/OAUTHBEARER Consultez Configuration des prérequis pour MSK Replicator avec des clusters Apache Kafka autogérés.

Étape 3 : configurer SASL/SCRAM mTLS ou SASL/OAUTHBEARER SSL sur un cluster autogéré

Configurez l'authentification sur votre cluster autogéré. Pour SASL/SCRAM, créez un utilisateur SCRAM dédié avec les autorisations ACL requises. Pour mTLS, configurez un écouteur SSL avec authentification par certificat client. Pour SASL/OAUTHBEARER, configurez vos courtiers pour OAUTHBEARER et enregistrez le fournisseur d'identité (IDP) qui vend les jetons d'accès. Configurez les certificats SSL. Consultez Configuration des prérequis pour MSK Replicator avec des clusters Apache Kafka autogérés.

Étape 4 : Stockez les informations d'identification dans AWS Secrets Manager

Créez un secret avec les paires clé-valeur appropriées à votre type d'authentification. Pour SASL/SCRAMusername, incluez password et les certificate champs. Pour les mTL, incluez privateKey les champs certificate et (et éventuellement privateKeyPassword pour les clés privées cryptées). Pour SASL/OAUTHBEARER utiliser le mécanisme des informations d'identification du client, incluez client_secret les champs client_id et. Consultez Configuration des prérequis pour MSK Replicator avec des clusters Apache Kafka autogérés.

Étape 5 : Création du réplicateur

Utilisez CreateReplicator l'API avec la position de EARLIEST départ, la réplication du même nom de rubrique et synchroniseConsumerGroupOffsets définissez surtrue. Le principal IAM qui appelle CreateReplicator doit disposer des autorisations d'appelant de l'API décrites dans. Autorisations IAM requises pour créer un réplicateur MSK Si vous envisagez de configurer la réplication bidirectionnelle pour la fonctionnalité de restauration (étape 6), définissez également cette option ENHANCED sur consumerGroupOffsetSyncMode les réplicateurs avant et arrière. Attendez environ 30 minutes pour que le réplicateur atteigne le statut EN COURS D'EXÉCUTION. Consultez CreateReplicator Exemples d'API pour les clusters Kafka autogérés.

Étape 6 : (Facultatif) Configurer la réplication bidirectionnelle

Créez un réplicateur inversé à partir du cluster provisionné MSK vers le cluster autogéré pour bénéficier de fonctionnalités de restauration. Identifiez les deux clusters dans le réplicateur inversé exactement comme vous les avez identifiés dans le réplicateur direct. Consultez Exemple de réplication bidirectionnelle.

Étape 7 : Surveiller la progression de la réplication

Surveillez les indicateurs suivants :

  • MessageLag(devrait atteindre 0)

  • ReplicationLatency

  • ConsumerGroupOffsetSyncFailure(devrait être 0)

  • ConsumerGroupCount

  • OffsetLag (MSK Cluster) et OffsetLag (Non-MSK Cluster)

Pour de plus amples informations, veuillez consulter Surveiller la réplication.

Étape 8 : Migrer les applications

Pour migrer vos applications, procédez comme suit :

  1. Empêcher les producteurs d'écrire vers un cluster autogéré

  2. Reconfigurer les producteurs vers le cluster MSK Provisioned avec authentification IAM

  3. Surveillez MessageLag jusqu'à ce qu'il atteigne 0

  4. Arrêtez les consommateurs d'utiliser un cluster autogéré

  5. Reconfigurer les consommateurs vers le cluster MSK Provisioned

Étape 9 : (Facultatif) Revenir au cluster autogéré

Si la réplication bidirectionnelle a été configurée, vous pouvez inverser les étapes de migration pour revenir au cluster autogéré. Le réplicateur inversé (MSK Provisioned → External) aura synchronisé le cluster autogéré, afin que les consommateurs puissent être redirigés sans perte de données.