Zookeeper : Installation et bonnes pratiques

Zookeeper logoLors de l’installation d’un Cluster Solrcloud, il est nécessaire de disposer d’un ensemble Zookeeper opérationnel. On appelle ensemble Zookeeper, un groupe de serveurs Zookeeper qui fonctionnent de concert (« ensemble » donc).

Dans cet article qui décrit l’installation d’un ensemble Zookeeper, sont également abordées les bonnes pratiques qui doivent être impérativement suivies.

Nombre de serveurs dans l’ensemble

La réponse rapide est au minimum trois et idéalement cinq.

Le but est de fournir un service hautement disponible ou l’arrêt pour panne ou maintenance d’un des serveurs de l’ensemble ne perturbe pas le service. Le principe de base pour qu’un ensemble fonctionne est que la moitié plus un des serveurs qui le composent soient disponibles, c’est ce l’on appelle disposer du quorum. Un ensemble de trois serveurs permet donc l’indisponibilité d’un de ces serveurs, alors qu’un ensemble de cinq serveurs permet l’indisponibilité de deux serveurs soit la possibilité de stopper un serveur pour une maintenance ou une mise à jour tout en pouvant accepter la perte d’un second serveur pour cause de panne.

Pré-requis

Logiciel

Zookeeper est une application Java. Le seul vrai pré-requis est de disposer d’un environnement Java. Nous préconisons les versions Oracle ou OpenJDK 1.8 ou 1.9.

Hardware

Zookeeper ne requière pas des serveurs très puissants, les caractéristiques de base conseillées afin de supporter une grande majorité de cas d’usages sont généralement ceux indiqués ci-dessous. Il va de soit que selon l’usage réel de SolrCloud, le monitoring des serveurs Zookeeper (CPU, espace disque, JVM, …) doit amener à adapter ces caractéristiques.

  • Processeurs quad-core
  • 2 Go de RAM
  • 100 Go d’espace disque
  • des I/O disques très performantes en écriture
  • un réseau gigabits très performant avec une très faible latence entre les membres de l’ensemble Zookeeper et les noeuds Solr

Bonnes pratiques

L’ensemble Zookeeper est un point critique de la stabilité et des performances de SolrCloud. Pour atteindre cette objectif, les bonnes pratiques impératives sont :

  • Utilisé des serveurs dédiés
  • Désactiver le swap des serveurs (vm.swappiness=1)
  • Augmenter la limite « nofile » à 8192 (1024 par défaut) dans « /etc/security/limits.conf »
  • Rendre Zookeeper indépendant des DNS en utilisant le fichier « /etc/hosts »
  • Allouer au maximum à la mémoire heap de Zookeeper la quantité de mémoire disponible moins 1 Go (Xmx=1g pour 2 Go de RAM disponible)
  • Utiliser des volumes disques distincts pour les données et les logs de transaction (paramètres dataDir et dataLogDir dans zoo.cfg
  • Activer les logs de GC de la JVM et les analyser régulièrement avec le site gceasy.io
  • Installer des outils de monitoring du système (CPU, I/O disques, …) afin des contrôler le bon fonctionnement et les performances du système. Nous préconisons « sar » qui fait parti du package sysstat

I/O disque

Il est nécessaire d’expliquer pourquoi il est demandé de disposer d’I/O disque très performants en écriture et d’utiliser des volumes distincts pour le stockage des données et des logs de transaction de Zookeeper. Zookeeper réponds à des requêtes de ses clients (les noeuds Solr). Systématiquement, avant de retourner une réponse, Zookeeper synchronise les transactions sur disque. On comprend alors que si ces écritures sont peu rapides, elles deviennent le goulet d’étranglement qui va provoquer des temps de réponses insuffisants et conduire à une instabilité de SolrCloud.

Utiliser des disques SSD est-il conseillé pour le stockage des logs de transaction ?

Tout d’abord, il faut savoir de quoi on parle. S’agit-il d’un datastore d’un système virtualisé construit sur des disques SSD ou de disques SSD directement et physiquement rattachés au serveur. Dans le premier cas, le gain n’est malheureusement pas forcément significatif. Dans le second cas, le gain doit être très significatif et utiliser des disques SSD pourrait sembler être un bon choix. Malheureusement, les disques SSD très performants en lecture peuvent être pénalisés par ponctuellement des latences importantes en écriture, hors ce sont les performances en écriture qui sont critiques pour Zookeeper ! Pour cette raison et uniquement si on a la certitude de ne pas être victime (même très ponctuellement) de problèmes de latence en écriture, l’usage de disque SSD est possible, sinon l’usage de disques SSD est déconseillé !

Installation de Zookeeper

Il s’agit d’une procédure d’installation sur la base de 5 membres.

Cette opération est a répéter sur chaque serveur de l’ensemble.

  • créer un utilisateur zookeeper
  • mettre en place le fichier /etc/hosts avec le contenu suivant. Le but est d’être totalement indépendant des DNS (pannes ou configuration)
  • extraire l’archive dans /opt/zookeeper-3.x.x et créer un lien symbolique générique “/opt/zookeeper” indépendant de la version. Les mises à jours seront plus faciles
  • créer des répertoires pour les données, les logs de transactions et le logs de Zookeeper sur des volumes si possible distincts
  • créer le fichier de configuration “/opt/zookeeper/conf/zoo.cfg” avec le contenu suivant. Il s’agit des paramètres par défaut conseillés avec notamment la distinction des volumes pour les données et les logs de transaction et également l’activation de la purge automatique des données.
  • Créer un fichiers myid dans le répertoire data. Ce fichier ne contient uniquement une ligne qui est le numéro de l’instance Zookeeper qui utilise ce répertoire de données (un chiffre de 1 à 255).
L’id 1 est à remplacer par 2, 3, … n sur chacun des serveurs

  • mettre en place le fichier d’initialisation “/opt/zookeeper/conf/zookeeper-env.sh” avec le contenu suivant. Contrairement à zoo.cfg, ce fichier est relatif à la configuration de la JVM et des logs. Il permet également de pallier à un problème de conservation des logs de la JVM lors des redémarrages. Les logs des JVM sont en rotation avec une taille de 20 Mo par fichier et un historique de 10 fichiers. Ces valeurs peuvent être adaptées.
  • Mettre en place le fichier de configuration des logs “/opt/zookeeper/conf/log4j.properties” avec le contenu suivant. Les logs sont en rotation avec une taille de 20 Mo par fichier et un historique de 10 fichiers. Ces valeurs peuvent être adaptées.
  • repositionner le bon propriétaire des fichiers de configuration

Script de démarrage

  • Mettre en place le script de démarrage “/etc/init.d/zookeeper” avec le contenu suivant
  • Démarrer chaque serveur de l’ensemble
  • Mettre en démarrage automatique

Sous Centos :

Sous Debian :