Pour découvrir  Zookeeper que l’on retrouve régulièrement dans de nombreux projets open source distribuables sur plusieurs serveurs. L’objectif est de comprendre le fonctionnement de Zookeeper en marco et de pouvoir s’en servir en tant que développeur.

Dans les fonctionnalités offertes par Zookeeper on trouve du NamingService, de la gestion de configuration, de la synchronisation, Leader Election… Zookeeper est en fait comme une boîte à outils que vous pouvez utiliser dès que coordonner des process déployés sur plusieurs serveurs devient un casse-tête.

Ci-dessous les thèmes que je veux traiter dans cet article

• comment fonctionne Zookeeper et un aperçu des termes à connaître,
• installer une instance de Zookeeper en local.
• installer plusieurs instances de Zookeeper en local.

Comment fonctionne Zookeeper et un aperçu des termes à connaître

Zookeeper fonctionne en fournissant un espace mémoire partagé par toutes les instances d’un même ensemble de serveurs Zookeeper. Cet espace mémoire est hiérarchique, à la manière d’un système de fichier composé de répertoires et de fichiers à la différence que, dans le cas de Zookeeper, on ne parle pas de répertoires et de fichiers mais de nœuds. Chaque nœud s’appelle un ZNode.
Lorsque l’on démarre une instance Zookeeper, la hiérarchie de nœuds est vide et nous n’avons alors qu’un nœud racine qui, à l’instar des systèmes fichiers, se nomme « / » :

Zookeeper nous laisse la liberté de créer de nouveaux ZNode et de stocker des données dedans. Par exemple : ajoutons un ZNode que l’on appellera « BMA». Nous obtenons alors l’arborescence suivante :

A l’intérieur de ce ZNode /BMA nous pouvons ajouter des données. Par exemple la valeur « Hello » :

Voilà… C’est la première étape. Maintenant pour que cela prenne tout son sens, l’idée c’est de se dire que cette hiérarchie de nœuds va se répliquer et se synchroniser sur tous les serveurs sur lesquels nous aurons installé Zookeeper.

Un serveur Zookeeper standalone a un intérêt qui se limite au test/développement en local. Zookeeper prend tout son sens lorsqu’on le déploie sur plusieurs serveurs ; on appelle cela un ensemble :

Le fonctionnement d’un ensemble Zookeeper nécessite l’élection d’un leader parmi les instances qui le composent. Lorsqu’un client écrit/modifie des données dans les ZNodes, c’est le leader qui effectue l’opération puis la transmet aux autres membres. Une fois qu’un certain nombre d’instances ont appliqué l’opération, cette dernière est considérée comme valide au sein de l’ensemble Zookeeper. Ledit nombre est appelé le quorum. Comme lors d’une élection au sein d’un groupe de personnes, le quorum représente le nombre minimum d’instances Zookeeper pour qu’une décision (typiquement, décider si la valeur affectée dans un ZNode est validée sur l’ensemble Zookeeper) soit prise par l’ensemble Zookeeper.

Par exemple si l’on a un ensemble de 3 serveurs, cela signifie que si au moins 2 serveurs dans l’ensemble Zookeeper sont d’accord sur une opération d’écriture, celle-ci est considérée valide.

Oui, mais comment connaît-on / détermine t-on la valeur du quorum ?

Le calcul du quorum s’effectue selon la formule suivante : quorum = n/2

• avec n le nombre de serveurs présents dans l’ensemble Zookeeper
• sachant que l’on arrondira toujours le résultat à la valeur supérieure (par exemple 3/2 = 1.5 => quorum = 2)
• on ajoute +1 si la valeur ne représente pas une majorité stricte (par exemple 2/2 = 1 => quorum = 2)

Donc, si on crée un petit tableau rapide avec le nombre de serveurs et le quorum nécessaire voilà ce que nous obtenons:

Lorsque l’ensemble est composé de 2 instances, le quorum est également de 2 car une seule instance ne représente pas une majorité stricte : non utilisable, puisque perdre un serveur revient à perdre notre service Zookeeper.
Avec 3 instances dans l’ensemble, le quorum reste à 2 (2 sur 3 représente bien une majorité stricte). Dans ce cas, si nous perdons un serveur, le service Zookeeper reste opérationnel. Un ensemble de 2 serveurs est donc le minimum pour avoir un service Zookeeper résistant aux pannes.
4 instances n’est pas intéressant dans la mesure où cela fait un quorum de 3, n’offre aucune plus-value par rapport à un ensemble de 3 : nous ne pouvons pas perdre plus d’une instance, donc nous n’avons pas amélioré notre robustesse par rapport à un ensemble de 3.
Finalement, en suivant la même logique nous pouvons constater qu’il est préférable de configurer un nombre impair d’instances dans un ensemble Zookeeper.

Pour conclure cette première partie, résumons un peu ce que nous venons de voir :

• une instance Zookeeper offre un espace mémoire hiérarchique ;
• plusieurs instances Zookeeper répliquées se nomment un ensemble ;
• un leader est élu dans l’ensemble Zookeeper, c’est lui qui enregistre les opérations, les transmet aux autres membres puis considère l’opération valide lorsque le quorum est atteint ;
• au sein d’un ensemble Zookeeper, le quorum représente le nombre minimum d’instances nécessaires pour commiter une donnée dans l’ensemble.

Comment installer Zookeeper

Il y pas mieux qu’une vidéo pour illustrer la démarche