Une présentation en français de Apache Zookeeper, un système de coordination de processus.

1. Apache Zookeeper
"From a certain point onward, there is no longer any turning back.
That is the point that must be reached." - Kafka
Michael Morello
@barkbay
1

2. Pourquoi ?
● Pourquoi s'intéresser au problème de consensus ?
– Parce que c'est le même que celui des transactions
distribuées
– Parce qu'aujourd'hui les traitements sont répartis sur plusieurs
machines
– Parce qu'il faut accepter que ces machines et le réseau qui
les relie ne soient pas fiables
2

3. Qu'est ce qu'un consensus ?
● Soit un système composé de N processus et un domaine
de valeurs D
● Chaque processus possède une valeur initiale v0 dans D
→ Il y a consensus si l'ensemble des processus évaluent
une même valeur finale vf
3

4. Fallacies of Distributed Computing
● Pourquoi est-ce difficile ?
1. Le réseau n'est pas fiable
2. La latence n'est pas nulle
3. La bande passante n'est pas infinie
4. Le réseau n'est pas sécurisé
5. La topologie change
6. Il y a plusieurs administrateurs
7. Transporter une donnée a un coût
8. Le réseau n'est pas homogène
Fallacies of Distributed Computing - Peter Deutsch @Sun Microsystems 4

5. Est-ce possible ?
● Théorème de M. Fisher, N. Lynch et M. Paterson
(1985)
Dans un modèle de communication asynchrone et si l'on
considère que les processus peuvent connaître des
défaillances alors il n'existe pas de solution
5

6. Dans la pratique...
● 2 Phase Commit :
– Bloquant, haute vulnérabilité aux pannes, ne gère pas un "fail-stop" du
coordinateur, utilisable seulement pour coordonner un faible nombre de
processus
● 3 Phase Commit :
– Non bloquant, plus résistant que 2PC, mais gère de manière incomplète un
"fail-recover" du coordinateur
● Algorithme de Paxos :
– Algorithme de consensus basé sur un quorum de participants
– Pas de coordinateur, pas de "Single Point of Failure"
– Robuste, fonctionne tant qu'il y a une majorité de participants 6

7. Zookeeper Atomic Broadcast
● Zookeeper implémente un algorithme inspiré de
Paxos appelé ZAB : Zookeeper Atomic Broadcast
● Paxos est efficace mais ZAB apporte quelques
améliorations :
– Par exemple il garantit dans quel ordre les
transactions sont appliquées alors que Paxos
ne le permet pas.
7

8. Et ça sert à quoi ?
●
Leader Election : attribuer un rôle spécifique à 1 JVM1 en
particulier parmi N
● Group Membership : regrouper de manière logique des
JVM
● (Double) Barriers : synchronisation de N JVM
● Sections critiques : partage de verrous ou de
sémaphores entre plusieurs JVM
8
1 : Il existe aussi des API pour d'autres langages comme le C, Perl et Python

9. Et ça sert à quoi (encore)
● Architecture orientée service : annuaire de services
hautement disponible et cohérent
● Centre de configuration de processus dynamique et
hautement disponible
● Système de message (à la JMS) hautement disponible,
haute performance, et avec conservation de l'ordre des
messages (Kafka, Hedwig)
9

10. Qui l'utilise ?
Et bien d'autres....... 10

11. Le modèle de programmation
● Modèle simple : Zookeeper expose une arborescence et les données
sont stockées dans les nœuds de l'arbre :
/parent : data1
|­ fils1 : data2
`­ fils2 : data3
● Ces nœuds sont appelés ZNodes
● La mise à jour des nœuds se fait de manière atomique grâce à ZAB
● Les clients peuvent être immédiatement notifiés d'une mise à jour des
données.
11

12. Programmation de + haut niveau
Netflix Curator1 est une bibliothèque
développée par Netflix qui offre une API de
haut niveau afin de faciliter l'utilisation de
Zookeeper :
– Gestion plus aisée de la connexion au cluster
Zookeeper et des problèmes
– Offre des recettes de bases (leader, lock, cache...)
– Extension : annuaire de service
12
1 : https://github.com/Netflix/curator

13. Points d'attention
● Zookeeper conserve les données en mémoire et la taille des données associées à
un Znode ne peut (par défaut) dépasser 1Mo
● Les "watches" qui notifient immédiatement les clients d'une mise à jour des
données ne sont exécutés qu'une seule fois et dans un même "thread"
● Corollaire du point précédent : certains événements peuvent être manqués et il
faut faire attention aux problèmes de synchronisation.
● Attention à l'effet de troupeau (Herd Effect) si trop de clients surveillent le même
Znode lorsque celui-ci est modifié.
● En Java : attention aux longues pauses du garbage collector qui peuvent faire
croire au cluster que le client s'est déconnecté.
13

14. Question ?
Michael Morello
michael.morello@gmail.com
@barkbay
14