Archives par étiquette : cluster

Redis Cluster

Voici le résultat de quelques tests réalisé sur le cluster redis (3.0)

Je suis parti cette image docker https://github.com/Grokzen/docker-redis-cluster

Après un inévitable

l’image est prête à être utilisé. Par défaut, cette image va lancer 3 nœuds masters et 3 nœuds slaves (1 par nœud master).

Lançons la commande

On peut voir que les ports 7000 à 7005 sont remontés sur le système hôte. Ce sera plus facile pour interroger redis directement.

En interrogeant redis, il y a bien 6 nœuds qui constituent le cluster (cluster_known_nodes).

La répartition des clés sautent aux yeux quand on essaye d’insérer une valeur

En lisant ce blog, on voit que la clé de répartition, se calcule comme suit:

Dans notre cas, key=toto ce qui donne hash_slots=9548

Si on inspecte le cluster, on obtient

On peut donc voir que notre valeur est contenu entre 5461 et 10922 et donc est géré par le master 63e73580b843d499b665a7385967268528e836e9 soit le l’instance redis sur le port 7001. Ce qui est bien conforme avec l’information fourni par redis.

Que se passe t’il si on arrête un slave:

En relançant la commande

On voit bien l’erreur de connexion à l’instance sur le port 7005 mais cela n’a pas d’incidence sur la santé du cluster.

Que se passe t’il si on arrête un master.

Le cluster voit bien le problème de connexion à l’instance défaillante.
il voit aussi qu’il y a un slave qui n’a pas de master. A la dernière ligne, on voit qu’il y a un problème de cohérence sur le cluster car tous les slots de répartition ne sont pas couverts par le cluster

Mais cela est corrigé quand le slave devient master:

J’ai modifié le programme Java initié dans le précédent article et je mesure à 6s, le temps pour que le cluster soit de nouveaux opérationnels;

Il est peut être possible de jouer sur le paramétrage pour descendre ce temps, mais je n’ai pas encore trouvé comment.

On voit bien ici le problème lorsque que les données ne soit pas répliquées entre les différents masters. Lorsqu’un master est absent, il y a un « petit » laps de temps ou les données ne sont pas connues.

Redis Cluster en java

En commençant à regarder le mode cluster de redis à travers une image docker déjà construire https://github.com/Grokzen/docker-redis-cluster, je me suis aperçu que ce n’est pas si transparent. En effaçant, si on essaye d’ajouter une valeur mais que la clé ne correspond au bon noeud, redis ne renvoi pas OK mais plutôt l’indication de ou insérer la donnée:

Je me suis demandé comment gérer cela dans un programme Java. Est-ce le driver qui va faire le travail ou il faut le gérer à la main.

Si on utilise le driver standard de Jedis, voici ce qu’on obtiens:

Heureusement, Jedis propose une classe pour résoudre ce problème (Je n’ai rien trouvé coté JRedis).

 

Le driver est même capable de récupérer les autres noeuds. Dans l’exemple j’ai indiqué un seul noeud, mais avec le code suivant :

on voit bien que le driver a pu récupérer les autres noeuds:

les sources sont ici

Quelques liens utiles:
commandes redis cluster

– À la découverte de Redis Cluster 3.0

 

docker – liens entre container suite

Maintenant que nous avons la bonne version de docker, nous pouvons modifier le fichier context.xml de l’application pour pointer sur le hostname de redis :

On va aussi modifier le démarrage du serveur d’applications pour créer un lien vers redis:

tomcat et redis sont maintenant connectée sans avoir besoin de connaître l’ip de chacun.

Et voici le script de démarrage complet :

Nous avons donc réussi à déployer des applications qui sont connectées entre elles, sans connaître les ips de chacune à l’avance. En termes de scalabilité, il devient aisé de rajouter un serveur d’application. Il faut juste démarrer un nouveau conteneur et le linker au haproxy.

Dans un prochain article, nous essayerons de voir comment faire fonctionner un cluster de redis avec docker.

Les sources sont à jour ici: https://github.com/BenoitCharret/session-webapp/tree/article_3