apache zookeeper

 

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: