Mirror Maker pour Kafka Migration

Pour l’un de nos clients de la plate-forme mondiale de gestion de la publicité, nous avons réalisé un projet de migration sans temps d’arrêt pour des composants tels que Platform DB, Ceph, Aerospike, Kafka (Zookeeper + nœuds de données), MapR (hive, oozie, hue), Druid (Zookeeper + données nodes), Flink (Zookeeper + data nodes), Monitoring (Icinga, collectd, cloudwatch), Logging (logstash & Opensearch) & Other Components ( Nexus, SFTP, Jenkins ).

Pour commencer ce blog de migration, les composants kafka et sa migration à l’aide de Mirror Maker sont expliqués en détail ci-dessous.

MirrorMaker est un processus dans Apache Kafka pour répliquer ou mettre en miroir des données entre des clusters Kafka. Ne le confondez pas avec la réplication des données entre les nœuds Kafka du même cluster. Un cas d’utilisation consiste à fournir une réplique d’un cluster Kafka complet dans un autre centre de données pour répondre à différents cas d’utilisation sans affecter le cluster d’origine.

Dans MirrorMaker, il existe un connecteur consommateur et un connecteur producteur. Le consommateur lira les données des rubriques du cluster Kafka source, et le connecteur producteur écrira ces événements ou ces données dans le cluster Kafka cible. Le cluster source et le cluster cible sont indépendants l’un de l’autre.

La fonctionnalité de mise en miroir de Kafka permet de conserver une réplique d’un cluster Kafka existant. Le diagramme suivant montre comment utiliser l’outil MirrorMaker pour mettre en miroir un cluster Kafka source dans un cluster Kafka cible (miroir). L’outil utilise un consommateur Kafka pour consommer les messages du cluster source et republie ces messages sur le cluster local (cible) à l’aide d’un producteur Kafka intégré.

Pour l’un de nos clients, lors de la migration de l’ensemble de son système d’un environnement sur site vers le cloud (AWS), nous avons utilisé un fabricant de miroirs car il avait besoin d’une migration sans interruption vers son pipeline existant. Comme indiqué dans le diagramme ci-dessous, nous avons créé un pipeline AWS distinct similaire à celui de Datacenter et utilisé un fabricant de miroirs pour copier les données de DC kafka vers AWS kafka.

Étapes pour mettre en place un miroir entre les clusters kafka source et cible :

1. Créer une liste des sujets présents dans le cluster source qui doivent être copiés dans le cluster cible
   
2. Créez ces rubriques sur le cluster cible avec la même réplication, les mêmes partitions et d’autres configurations
   
3. Créer un cluster de fabricant de miroirs en fonction de la charge de données via des sujets
   • Utilisez le type d’instance approprié pour le cluster de fabricant de miroirs en fonction des sujets (cela joue un rôle essentiel dans la réduction du décalage entre les données kafka source et cible)
   • Dans notre cas, nous avons utilisé plusieurs clusters configurant différents sujets car la charge de données dans chaque sujet variait. Nous avons utilisé un cluster de type instance c5.18x de 15 nœuds pour les sujets avec une charge de données importante. Alors que pour les sujets avec moins de charge de données, nous avons utilisé des types d’instances c5.18x cluster de 2 nœuds.
   • La configuration d’un miroir est facile – il suffit de démarrer les processus de création de miroirs après avoir appelé le cluster cible. Au minimum, le fabricant de miroirs prend une ou plusieurs configurations de consommateur, une configuration de producteur et une liste blanche ou une liste noire. Vous devez pointer le consommateur vers le ZooKeeper du cluster source et le producteur vers le ZooKeeper du cluster miroir (ou utiliser le paramètre broker.list)
     
4. Jouer avec différents paramètres de configuration pour optimiser le processus de mise en miroir.

1. biens.des.consommateurs

récupérer.message.max.bytes=40240000

client.id=prod-mirrormaker-group-300322_001

group.id=prod-mirrormaker-group-310322_01

exclude.internal.topics=vrai

nombre.consumer.fetchers=300

récupérer.max.attente.ms=500

récupérer.min.octets=186384

2. propriétés.du.producteur

producteur.type=asynchrone

queue.buffering.max.messages=2000

queue.buffering.max.ms=500

lot.num.messages=3000

envoyer.buffer.bytes=1000000

client.id=prod-mirrormaker-group-240322_001

compression.codec=gzip

request.required.acks=1

lot.taille = 1000

buffer.memory = 2000000000

Comment vérifier si un miroir tient la route :

L’outil de vérification de décalage consommateur est utile pour évaluer dans quelle mesure votre miroir suit le cluster source. Notez que l’argument –zkconnect doit pointer vers le ZooKeeper du cluster source (DC dans ce scénario). De plus, si la rubrique n’est pas spécifiée, l’outil imprime des informations pour toutes les rubriques du groupe de consommateurs donné. Par exemple:

TROUVÉ CELA UTILE ? PARTAGEZ-LE