Remarques :

Migration de Kafka et du cluster Zookeeper sans temps d'arrêt

Introduction

De nombreux services (natifs du cloud ou sur site) utilisent des clusters Kafka pour leurs besoins de messagerie asynchrone, car il s'agit d'une technologie de messagerie qui évolue bien. Il peut arriver que vous deviez remplacer un ensemble de noeuds ou l'ensemble du cluster en raison des besoins de l'entreprise. Ce tutoriel traite de la migration de Kafka et du cluster Zookeeper vers un nouvel ensemble de noeuds sans temps d'inactivité.

L'énoncé du problème

Pourquoi le remplacement d'un noeud dans un cluster par un autre peut être un défi ? L'ajout ou la suppression d'un noeud d'un ensemble de noeuds derrière un équilibreur de charge est omniprésent : ajoutez un nouveau noeud, purgez le noeud existant à enlever, une fois que toutes les connexions en cours sont terminées, arrêtez-le, enlevez-le de la configuration de l'équilibreur de charge, etc.

Le véritable défi réside dans la gestion de l'État avec une application. En général, les applications sont sans conservation de statut et déléguent la persistance d'état à un système de gestion de données, par exemple un système de gestion de base de données relationnelle (SGBDR). Contrairement à de telles applications, Kafka et Zookeeper gèrent l'état localement, c'est-à-dire que la persistance de l'état se fait à l'aide de disques locaux. Cela signifie que nous ne pouvons pas simplement remplacer un noeud par un autre sans prendre en charge l'état local du noeud existant.

En outre, dans le cas de Kafka, le simple ajout d'un noeud ne déclenche pas automatiquement un rééquilibrage de la charge de travail, c'est-à-dire une redistribution des partitions de sujet entre les brokers. Le nouveau noeud participe uniquement au partage de la charge globale pour les nouvelles rubriques créées à partir de ce point.

Un problème opérationnel avec les systèmes basés sur le quorum (Zookeeper dans ce cas) est qu'ils doivent connaître la taille du cluster à l'avance, ce qui signifie que chaque noeud doit connaître tous les autres noeuds du cluster. Et, pour compliquer encore les choses, si vous ajoutez plus d'un noeud (le nombre exact dépend de la taille du cluster existant) en une seule fois, vous devez vous assurer que l'un des nouveaux noeuds ajoutés ne devienne pas le leader sinon nous perdons les données.

Objectifs

Prérequis

Migrer le cluster Kafka

Le remplacement des noeuds dans un cluster Kafka est relativement facile. Ajoutez de nouveaux brokers et appelez la migration des partitions de sujet. Une fois la migration terminée, nous pouvons mettre hors service l'ancien broker. Kafka fournit une API admin pour effectuer la migration de partition. alterPartitionReassignments fonctionne en ajoutant des répliques de partition supplémentaires à une rubrique, attend qu'elles deviennent membres de l'ISR, puis échange le leader de partition.

Vous devez désactiver les nouvelles affectations de partition de sujet aux anciens courtiers (si la logique de l'application crée des sujets lors de l'exécution), sinon cela deviendrait une boucle de migration sans fin. Pour ce faire, vous pouvez utiliser une variante de l'API de création de sujet dans laquelle vous pouvez spécifier vous-même l'affectation de partition. Un exemple d'algorithme pouvant être suivi est répertorié ci-dessous.

Etapes de haut niveau pour la migration qui peuvent être suivies avec la comptabilité (pour le redémarrage en cas d'arrêt ou d'échec du processus de migration au milieu).

  1. Le mappage entre l'ancien et le nouvel ID de courtier est indiqué et terminé.

  2. Utilisez AdminClient pour vérifier si de nouveaux brokers sont disponibles. Si elles ne sont pas toutes disponibles, générez une erreur et mettez fin.

  3. Utilisez AdminClient pour vérifier si le sujet <kafka_topic_migration> existe dans le cluster.

    • Si le sujet <kafka_topic_migration> n'existe pas, créez-le en affectant manuellement des répliques aux nouveaux brokers. Cette rubrique est utilisée pour la comptabilité des rubriques déjà réaffectées, c'est-à-dire migrées.

  4. Lisez le sujet <kafka_topic_migration> dès le début en utilisant un consommateur. Chaque message est un nom de sujet qui a été réaffecté à de nouveaux courtiers.

  5. Utilisez AdminClient pour répertorier toutes les rubriques disponibles dans le cluster. Dans cette liste, enlevez le sujet <kafka_topic_migration>.

  6. A partir des deux étapes ci-dessus, recherchez les sujets à réaffecter à de nouveaux courtiers.

  7. Pour chaque sujet :

    1. Créez une carte Map<TopicPartition,Optional<NewPartitionReassignment>> reassignment = new HashMap<>();.

    2. A l'aide de AdminClient, décrivez la rubrique pour rechercher ses partitions.

    3. Pour chaque partition :

      1. Préparez un objet NewPartitionReassignment en remplaçant chaque ancien ID de réplique (ancien ID de courtier) par le nouvel ID de courtier correspondant. Si le mappage d'ID de courtier ne contient pas la clé correspondant à l'ID de réplique, consignez un avertissement et utilisez l'ID actuel (la raison la plus probable est que cette rubrique a déjà été migrée et que nous avons manqué la comptabilité).

      2. Ajoutez cette entrée à la correspondance.

    4. Utilisez AdminClient pour lancer la réaffectation en appelant la méthode alterPartitionReassignments.

    5. Exécutez une boucle pour vérifier si cette réaffectation est terminée en répertoriant les réaffectations en cours (listPartitionReassignments) et en vérifiant que sa taille est égale à zéro. Mettre en veille N secondes entre chaque boucle.

    6. Vérifiez que les nouvelles répliques de chaque partition correspondent aux répliques souhaitées.

    7. Transmettez ce nom de rubrique en tant que message à la rubrique <kafka_topic_migration>.

  8. Répétez les étapes 4 à 6 s'il ne reste plus de sujets à réaffecter et à mettre fin.

Une fois la migration terminée, nous pouvons mettre hors service les anciens courtiers et désactiver la logique personnalisée de création de sujet.

Remarque : avant de mettre hors service les anciens brokers, assurez-vous que tous les clients de ce cluster ont mis à jour la configuration bootstrap.servers avec les nouveaux brokers.

Migrer le cluster Zookeeper

Étant un système basé sur le quorum (pour valider une opération, nous avons besoin d'au moins le quorum de votes) et étant donné que la réélection du leader entraîne l'arrêt des opérations d'écriture, la migration de Zookeeper est la partie la plus difficile. Il existe deux approches pour remplacer les noeuds. Une approche simple consiste à effectuer plusieurs cycles de redémarrage non simultané de l'ensemble du cluster et à ajouter un nouveau noeud à chaque cycle. Cette approche peut ne pas être acceptable en raison de plusieurs cycles de redémarrage du noeud de leader et de retard dans l'exécution de la migration globale.

Remarque : nous ne pouvons pas ajouter tous les nouveaux noeuds (en tant que participants) en une seule fois en raison du risque qu'un nouveau noeud devienne un leader sans synchroniser toutes les données (ce qui entraîne une perte de données).

Ne spécifiez jamais plus d'un serveur participant dans la même configuration initiale que les participants. Actuellement, les serveurs de jointure ne savent pas qu'ils rejoignent un ensemble existant, si plusieurs serveurs de jointure sont répertoriés en tant que participants, ils peuvent former un quorum indépendant créant une situation de split-brain telle que des opérations de traitement indépendamment de votre ensemble principal. Il est possible de répertorier plusieurs jointures en tant qu'observateurs dans une configuration initiale.

Dans la version Zookeeper au-dessus de 3.5.0, nous prenons en charge la reconfiguration dynamique de l'ensemble Zookeeper. L'indicateur reconfigEnabled doit être défini sur true pour que la reconfiguration dynamique fonctionne. Pour plus d'informations, reportez-vous à la section Dynamic Reconfiguration of the ZooKeeper Ensemble.

Vous pouvez ajouter de nouveaux noeuds à l'ensemble avec le rôle Observer avec la configuration initiale de serveurs composés de serveurs dans la dernière configuration validée. Par exemple, si les serveurs 4 et 5 sont ajoutés en même temps à (1, 2, 3), la configuration initiale de 4 sera (1, 2, 3, 4, 5), où 4 et 5 sont répertoriés en tant qu'observateurs. De même, la configuration de 5 sera (1, 2, 3, 4, 5), où 4 et 5 sont répertoriés en tant qu'observateurs.

Remarque : l'inscription des membres en tant qu'observateurs ne les rendra pas réellement observateurs. Cela les empêchera seulement de former accidentellement un quorum avec d'autres membres. Au lieu de cela, ils contacteront les serveurs dans la configuration actuelle et adopteront la dernière configuration validée (1, 2, 3), où les jointures sont absentes. Après s'être connectés au leader actuel, les membres deviennent des adeptes sans droit de vote jusqu'à ce que le système soit reconfiguré et qu'ils soient ajoutés à l'ensemble (en tant que participant ou observateur, comme souhaité).

Une fois que tous les noeuds sont opérationnels, l'API reconfig est appelée pour ajouter dynamiquement de nouveaux noeuds en tant que participants et supprimer les anciens noeuds de l'ensemble. Par exemple, à l'aide de la CLI.

reconfig -remove 1,2,3 -add
server.5=hostA:2111:2112;2113,6=hostB:2111:2112:participant;2113,7=
hostC:2111:2112:participant;2113*

Après cette étape, les anciens noeuds peuvent être mis hors service.

Remarque :

Remerciements

Ressources de formation supplémentaires

Parcourez d'autres ateliers sur docs.oracle.com/learn ou accédez à davantage de contenus de formation gratuits sur le canal Oracle Learning YouTube. De plus, rendez-vous sur education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir de la documentation sur le produit, visitez Oracle Help Center.