Cet article est la suite du 1er article:
http://www.consultingit.fr/fr/zookeeper-diagramme-de-sequences-coordination-applications-distribuees
Les followers
Les followers votent pour savoir qui est le leader. C’est un mécanisme d’élection. Le follower est indépendant ; Quand il a besoin d’interroger une ressource, il interroge le contexte pour les requêtes de lectures.
L’observer
C’est celui qui supervise le cluster Zookeeper. On l’utilise quand il y a beaucoup de machines, cinquantes par exemple. On démarre une machine dont le role est d’observer. La différence avec le follower c’est qu’il ne vote pas.
Qui utilise Zookeeper par exemple ? Le Crédit Agricole
Architecture
Zookeeper utilise une base de donnée NoSQL : il n’y a pas de notions de tablespaces, de tables...
Si on prend par exemple Cassandra, les données sont stockées en ligne/colonnes. Dans zookeeper, les données sont stockées dans un graphe, comme un système d’arborescence de fichiers. Il y a des nœuds, « Znode » . Comme quand on met un fichier dans un répertoire.
Le contexte est un tableau de bytes, converti en objets et lu. Le binaire ça prend moins de mémoire que le XML est en plus c’est sécurisé.
Comme le contexte est répliqué partout, si on perd une machine, ce n’est pas grave, puisque le contexte est interrogeable sur les autres machines.
Un client qui se connecte à un serveur du cluster zookeeper doit connaitre tout ce qui se passe dans le cluster. Il a donc besoin d’un watcher (cf Jersey SendEvent) Tout ce qui se passe dans le cluster Zookeeper sera notifié au client par des événements.
Quand est-ce que le client est notifié?
-un serveur tombe
-ce qui se passe dans le contexte dans le serveurs, s’il est modifié et supprimé.
Le fichier est conf/zoo.cfg propose des paramètres, dont ceux-là par défaut:
|
tickTime=2000 dataDir=/var/lib/zookeeper/ clientPort=2181 initLimit=5 syncLimit=2 server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888 |
Datadir est le chemin vers la base de données NOSQL.
Il est identique sur l’ensemble des serveurs du cluster.
Chaque serveur 3 ports : 1 port d’élection, 1 port de connection, 1 port d’échange.
Si je veux un observer, j’ajoute dans le fichier de conf de l’observer: type = observer
https://zookeeper.apache.org/doc/r3.4.6/zookeeperAdmin.html
Zookeeper utilise log4j pour gérer les logs
Zookeeper est un outil opensource : on nous donne le .JAR et on a accès au code source.
Graphe de données Zookeeper
2eme algorithme d’élection du leader, en plus de FastLeaderElection
Démarrage du serveur, élection, génération d’un GuiD (global unique identifier) GUID-003 par exemple.
Le leader sera en fait celui qui a le guid-xxx le plus bas.
L’API Zookeeper
Operations, type
Create, write
getDate, Read
setData,Write…
Je récupère un tableau de byte (contexte) que je dois gérer.
Installation et configuration de Zookeeper
Quand on télécharge zookeeper, il faut modifier le zoo_sample.cfg en zoo.cfg pour que zookeeper puisse démarrer.
Dans le répertoire conf, on pose aussi le log4j.properties.
La réplication multicast : j’ai un service multicast.
Exemple : Jersey SSE
Executer zkServer.sh start
Pour connaitre le statut de ce serveur: "zkServer.sh status"
Pour qu'un client se connecte avec un serveur et initialise une session:
zkCli.sh -server 127.0.0.1:2181
Création d'un noed Znode, qui correspond au graphe NOSQL: "create /consultingit test"
Je mets en place le watcher avec la commande:
get /consultingit true
Une question? Posez-la ici
Qu’est-ce que l’unicast ?
Le client 1 envoie directement une requete à client2 en connaissant sa référence distribuée : IP, PORT, PROTOCOLE.
Qu’est-ce que le multicast ?
Le client 1 veut envoyer un message au client 2 et au client 3. Il peut le faire en envoyant 2 unicasts à la suite.
Mais il peut envoyer un seul message
Exemple, quand on envoie un message sur un chat, un message est envoyé à tout le monde, le message est envoyé au groupe. Voir RMI en UDP.
Mais en REST, avec JerseySSE par exemple, j’ai un cluster de machines, serveur 1 et serveur 2 et serveur 3. On veut qu’ils communiquent en multicast. JerseySSE désigne un serveur master (Jersey send event). Les serveurs 2 et serveurs 3 via un getEvent s’abonnent au serveur 1, comme un listener, comme un watcher. Quand le serveur 1 envoie un message, le serveur 2 et le serveur 3 le recoivent.
Besoin d'aide avec Zookeeper? Remplissez ce petit formulaire: