Migration vers un cluster Amazon MSK

Le réplicateur Amazon MSK peut être utilisé pour la migration de clusters MSK. veuillez consulter Qu'est-ce qu'Amazon MSK Replicator ?. Vous pouvez également utiliser Apache MirrorMaker 2.0 pour migrer d'un cluster non MSK vers un cluster Amazon MSK. Pour un exemple de la procédure à suivre, consultez Migrer un cluster Apache Kafka sur site vers Amazon MSK à l'aide de. MirrorMaker Pour plus d'informations sur son utilisation MirrorMaker, consultez la section Mise en miroir des données entre clusters dans la documentation d'Apache Kafka. Nous vous recommandons de l'installer MirrorMaker dans une configuration à haute disponibilité.

Aperçu des étapes à suivre lors de l'utilisation MirrorMaker pour migrer vers un cluster MSK

1. Créez le cluster MSK de destination

2. Commencez MirrorMaker à partir d'une instance Amazon EC2 au sein du même Amazon VPC que le cluster de destination.

3. Inspectez le MirrorMaker décalage.

4. Après le MirrorMaker rattrapage, redirigez les producteurs et les consommateurs vers le nouveau cluster à l'aide des courtiers bootstrap du cluster MSK.

5. Arrêtez MirrorMaker.

Migration de votre cluster Apache Kafka vers Amazon MSK

Supposons que vous ayez un cluster Apache Kafka nommé CLUSTER_ONPREM. Ce cluster est rempli de rubriques et de données. Si vous souhaitez migrer ce cluster vers un cluster Amazon MSK nouvellement créé nommé CLUSTER_AWSMSK, cette procédure fournit une vision globale des étapes à suivre.

Pour migrer votre cluster Apache Kafka existant vers Amazon MSK

1. Dans CLUSTER_AWSMSK, créez toutes les rubriques que vous souhaitez migrer.

   Vous ne pouvez pas utiliser MirrorMaker cette étape car elle ne recrée pas automatiquement les sujets que vous souhaitez migrer avec le niveau de réplication approprié. Vous pouvez créer les rubriques dans Amazon MSK avec les mêmes facteurs de réplication et le même nombre de partitions qu'elles avaient dans CLUSTER_ONPREM. Vous pouvez également créer les rubriques avec différents facteurs de réplication et nombres de partitions.

2. Commencez MirrorMaker par une instance disposant d'un accès en lecture CLUSTER_ONPREM et en écritureCLUSTER_AWSMSK.

3. Exécutez la commande suivante pour mettre en miroir toutes les rubriques :

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

   Dans cette commande, config/mirrormaker-consumer.properties pointe vers un broker d'amorçage dans CLUSTER_ONPREM ; par exemple, bootstrap.servers=localhost:9092. Et config/mirrormaker-producer.properties pointe vers un broker bootstrap dans CLUSTER_ AWSMSK ; par exemple,. bootstrap.servers=10.0.0.237:9092,10.0.2.196:9092,10.0.1.233:9092

4. Continuez à MirrorMaker exécuter en arrière-plan et continuez à utiliserCLUSTER_ONPREM. MirrorMaker reflète toutes les nouvelles données.

5. Vérifiez la progression de la mise en miroir en inspectant le décalage entre le dernier décalage de chaque sujet et le décalage actuel par rapport auquel il MirrorMaker est consommé.

   N'oubliez pas qu' MirrorMaker il s'agit simplement de faire appel à un consommateur et à un producteur. Ainsi, vous pouvez vérifier le lag en utilisant l'outil kafka-consumer-groups.sh. Pour trouver le nom du groupe de consommateurs, recherchez la group.id dans le fichier mirrormaker-consumer.properties et utilisez sa valeur. S'il n'y a pas de clé de ce type dans le fichier, vous pouvez la créer. Par exemple, définissez group.id=mirrormaker-consumer-group.

6. Une fois que vous aurez MirrorMaker fini de refléter tous les sujets, arrêtez tous les producteurs et consommateurs, puis arrêtez MirrorMaker. Ensuite, redirigez les producteurs et les consommateurs vers le cluster CLUSTER_AWSMSK en changeant leurs valeurs de brokers d'amorçage pour les producteurs et les consommateurs. Redémarrez tous les producteurs et consommateurs sur CLUSTER_AWSMSK.

Migration d'un cluster Amazon MSK vers un autre

Vous pouvez utiliser Apache MirrorMaker 2.0 pour migrer d'un cluster non MSK vers un cluster MSK. Par exemple, vous pouvez migrer d'une version d'Apache Kafka vers une autre. Pour un exemple de la procédure à suivre, consultez Migrer un cluster Apache Kafka sur site vers Amazon MSK à l'aide de. MirrorMaker Le réplicateur Amazon MSK peut être également utilisé pour la migration de clusters MSK. Pour de plus amples informations sur le réplicateur Amazon MSK, consultez MSKRéplicateur.

MirrorMaker 1.0 meilleures pratiques

Cette liste de bonnes pratiques s'applique à la MirrorMaker version 1.0.

• Exécutez MirrorMaker sur le cluster de destination. De cette façon, si un problème de réseau se produit, les messages sont toujours disponibles dans le cluster source. Si vous exécutez MirrorMaker sur le cluster source et que les événements sont mis en mémoire tampon dans le producteur et qu'il y a un problème réseau, les événements risquent d'être perdus.

• Si le chiffrement est requis en transit, exécutez-le dans le cluster source.

• Pour les consommateurs, définissez auto.commit.enabled=false

• Pour les producteurs, définissez

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

  • nouvelles tentatives=int.max_value

  • acks=all

  • max.block.ms = Long.Max_Value

• Pour un rendement élevé du producteur :

  • Les messages de tampon et les lots de messages de remplissage - ajustent buffer.memory, batch.size, linger.ms

  • Ajustez les tampons de socket - receive.buffer.bytes, send.buffer.bytes

• Pour éviter toute perte de données, désactivez la validation automatique à la source, afin de contrôler les validations, ce qu'elle fait généralement après avoir reçu le pack du cluster de destination. MirrorMaker Si le producteur a acks=all et que le cluster de destination a min.insync.replicas défini sur plus de 1, les messages sont conservés sur plusieurs courtiers à la destination avant que le consommateur ne valide le décalage à la source. MirrorMaker

• Si l'ordre est important, vous pouvez définir les nouvelles tentatives sur 0. Sinon, pour un environnement de production, définissez la valeur 1 maximum de connexions en transit pour vous assurer que les lots envoyés ne sont pas validés hors service si un lot échoue au milieu. De cette façon, chaque lot envoyé est réessayé jusqu'à ce que le lot suivant soit envoyé. Si max.block.ms n'est pas défini sur la valeur maximale et si le tampon du producteur est plein, il peut y avoir une perte de données (selon certains des autres paramètres). Cela peut bloquer le consommateur et lui envoyer une contre-pression.

• Pour un débit élevé

  • Augmentez buffer.memory.

  • Augmentez la taille du lot.

  • Ajustez linger.ms de façon à permettre aux lots de se remplir. Cela permet également une meilleure compression, moins d'utilisation de la bande passante réseau et moins de stockage sur le cluster. Cela se traduit par une rétention accrue.

  • Surveillez l'utilisation du processeur et de la mémoire.

• Pour un débit élevé pour les consommateurs

  • Augmentez le nombre de threads/consommateurs par MirrorMaker processus — num.streams.

  • Augmentez d'abord le nombre de MirrorMaker processus sur les machines avant d'augmenter le nombre de threads pour garantir une haute disponibilité.

  • Augmentez le nombre de MirrorMaker processus d'abord sur la même machine, puis sur différentes machines (avec le même identifiant de groupe).

  • Isolez les sujets à très haut débit et utilisez des MirrorMaker instances distinctes.

• Pour la gestion et la configuration

  • Outils de gestion de l'utilisation AWS CloudFormation et de la configuration tels que Chef et Ansible.

  • Utilisez des montages Amazon EFS pour garder tous les fichiers de configuration accessibles à partir de toutes les instances Amazon EC2.

  • Utilisez des conteneurs pour faciliter le dimensionnement et la gestion des MirrorMaker instances.

• En général, il faut plus d'un consommateur pour saturer un producteur. MirrorMaker Par conséquent, veillez à mettre en place plusieurs consommateurs. Tout d'abord, configurez-les sur différents ordinateurs pour fournir une haute disponibilité. Ensuite, mettez à l'échelle des ordinateurs individuels jusqu'à avoir un consommateur pour chaque partition, les consommateurs étant répartis également entre les ordinateurs.

• Pour l'ingestion et la livraison à haut débit, ajustez les tampons de réception et d'envoi car leurs valeurs par défaut peuvent être trop faibles. Pour des performances optimales, assurez-vous que le nombre total de flux (num.streams) correspond à toutes les partitions de rubrique qui MirrorMaker tentent de copier vers le cluster de destination.

MirrorMaker 2.* avantages

• Utilise le framework et l’écosystème d’Apache Kafka Connect.

• Détecte les nouvelles rubriques et partitions.

• Synchronise automatiquement la configuration des rubriques entre les clusters.

• Prend en charge les paires de clusters « actifs/actifs », ainsi que n'importe quel nombre de clusters actifs.

• Fournit de nouvelles mesures, notamment end-to-end la latence de réplication entre plusieurs centres de données et clusters.

• Émet les décalages nécessaires pour migrer les consommateurs entre les clusters et fournit des outils pour la translation de décalage.

• Prend en charge un fichier de configuration de haut niveau pour spécifier plusieurs clusters et flux de réplication en un seul endroit, par rapport aux propriétés producteur/consommateur de bas niveau pour chaque MirrorMaker processus 1.*.