Apache ZooKeeper est un système de coordination distribué open-source qui fournit une plateforme pour la gestion de configuration, la synchronisation de processus et la gestion de verrous. À l’origine développé par Yahoo, il est aujourd’hui maintenu par Apache.
ZooKeeper offre également une haute disponibilité et résilience aux pannes, ce qui en fait une solution fiable pour les environnements distribués à grande échelle. En effet, il peut gérer des charges de travail très élevées et est conçu pour s’adapter à des environnements de plus en plus complexes.
Dans cet article, nous allons essayer de lever le voile sur son fonctionnement, et comprendre les fondamentaux.
Comment fonctionne Zookeeper ?
Décrivons dans un premier temps l’architecture de Apache ZooKeeper.
ZooKeeper suit une architecture « client-serveur« , où les serveurs sont des noeuds qui fournissent un service et les clients sont les noeuds qui utilisent ce service. Décrivons chaque élément du diagramme ci-dessus.
- Un client fait référence à une application cliente qui émet des requêtes aux serveurs ZooKeeper pour gérer les configurations et synchroniser les services distribués. Ils peuvent se connecter à n’importe quel serveur qui se chargera de rediriger la requête au serveur approprié.
- Un serveur est un nœud dans le cluster ZooKeeper. Ils sont responsables de la gestion des requêtes entrantes, de stocker les données et de les maintenir à jour. Les serveurs peuvent se répliquer les uns aux autres dans le but de maintenir une haute disponibilité.
- Un serveur est élu leader et est responsable de la coordination des réplicas de l’ensemble. Ce leader gère ainsi la réplication des données et attribue aux différents serveurs leurs transactions. Si le leader tombe en panne, un autre serveur est immédiatement élu pour prendre sa place et assumer ses fonctions.
- Un follower (ou suiveur), est un nœud qui suit les instructions du leader.
- L’ensemble est un groupe de serveurs ZooKeeper.
Les modèle de données : Qu'est ce que c'est ?
ZooKeeper utilise un modèle de données basé sur une hiérarchie de nœuds, similaire à la structure d’un système de fichier. Ainsi, chaque nœud est identifié par un chemin unique dans l’arborescence. Ils peuvent avoir des enfants qui sont en réalité des nœuds placés sous le nœud parent dans la hiérarchie. Cette structure en arborescence permet de créer des structures de données complexes pour la représentation des informations nécessaires à la coordination et la synchronisation des applications distribuées.
Dans ZooKeeper, chaque nœud est appelé Znode, et chaque znode est identifié par un nom.
Chacun de ces znode dans le modèle de données ZooKeeper maintient une structure stat. Elle fournit simplement les métadonnées d’un znode, qui est composée des éléments suivants :
- Le numéro de version augmente chaque fois que des données associées au znode changent. Cette notion est importante lorsque plusieurs clients tentent d’effectuer des opérations sur le même znode
- Les ACL (contrôles d’accès) agissent en tant que mécanisme d’authentification pour accéder au znode.
- L’horodatage représente le temps écoulé depuis la création ou la dernière modification du znode, représenté en millisecondes. Ce changement est identifié à partir de l’identifiant de transaction (le zxid). Ce zxid est unique et permet de facilement identifier le temps écoulé entre plusieurs demandes.
- La longueur de données représente la quantité totale de données stockée dans un znode. Il est possible de stocker au maximum 1 mégaoctet de données.
Quels sont les différents types de nœuds ?
Les znodes peuvent être de différents types :
- Znode persistants : ces nœuds existent toujours, même si le client ayant créé ce znode s’est déconnecté. Par défaut, tous les znodes sont persistants, sauf indication contraire.
- Znode éphémère : ils demeurent actifs tant que le client est connecté. Dès lors qu’un client se déconnecte, les znodes éphémères sont automatiquement supprimés. Pour cette raison, ils ne peuvent pas avoir d’enfants supplémentaires. Lorsqu’un znode éphémère est supprimé, le nœud approprié suivant remplira sa position. Ils jouent un rôle essentiel dans l’élection du Leader.
- Znode séquentiel : ce dernier type de znode peut être soit persistant, soit éphémère. Lorsque ce type de znode est créé, ZooKeeper définit le chemin du znode en y attachant une séquence à 10 chiffres au nom original. Par exemple, si un znode avec le chemin /myapp est créé en tant que znode séquentiel, ZooKeeper changera le chemin en /myapp0000000001 et définira le numéro de séquence suivant sur 0000000002. Dans le cas où 2 znodes séquentiels sont créés simultanément, ZooKeeper n’utilisera jamais le même numéro pour chaque znode. Ce type de znode joue un rôle important dans le verrouillage et la synchronisation.
Les sessions
Il s’agit d’un concept très important pour les opérations de ZooKeeper. A intervalle régulier, des heartbeats sont envoyés par le client afin de maintenir sa session active. Si aucun heartbeat ne parvient à l’ensemble ZooKeeper, le client est considéré comme « mort », entraînant également la suppression des znodes éphémères.
Les Watches
Ce mécanisme permet aux clients de recevoir des notifications sur les changements relatifs à l’ensemble ZooKeeper. Ils peuvent définir des watches lors de la lecture d’un nœud particulier, et ces watches envoient au client une notification enregistrée pour tout changement du nœud.
Conclusion
Apache ZooKeeper est un système de coordination distribué, qui se présente comme une entité unique, mais dissimule tout un système complexe. Il permet ainsi de résoudre toutes les difficultés rencontrées par les applications distribuées grâce à son framework, qui fournit par ailleurs plusieurs services, notamment des services de gestion de configuration et de nommage.
Maintenant que vous savez tout sur la coordination et la synchronisation avec Apache ZooKeeper, n’hésitez pas à vous inscrire à une formation DataScientest pour apprendre davantage. Découvrez nos cursus data !
