Mise à jour d’un environnement Solrcloud en production

Dans cet article nous expliquons le principe de la mise à jour d’un environnement Solrcloud en production. Nous abordons les mises à jours des 3 éléments qui interviennent dans un environnement Solrcloud :

  • la JVM
  • Zookeeper
  • Solrcloud

Pour chacun de ces éléments, les points abordés sont :

  • les taches préalables
  • la procédure
  • les impacts sur les configurations

La mise à jour de chaque élément peut être faite à chaud si l’ensemble Zookeeper comporte au moins 3 membres, si le cluster Solr contient au moins 2 noeuds et si chaque collection possède au moins 2 replicas.

Mise à jour de la JVM

Tout d’abord, il faut s’assurer que la mise à jour de Java ne se fait pas automatiquement (c’est plutôt rare sur un serveur). En effet, Lucene qui est embarqué dans Solr est très sensible à la version de Java installée et de nombreux cas de bugs ont été signalés par le passé. Je vous conseille de vous reporter à l’article « La bonne version de Java pour Solr ».

Lors d’une mise à jour de la JVM, il est donc important de vérifier auprès de la communauté Zookeeper et Solr que la version envisagée ne présente pas de bugs connus. Pour Solr, il faut se rendre sur cette page du wiki.

Zookeeper et Solr peuvent utiliser des JVM de versions différentes, par contre, il est impératif d’utiliser la même version de JVM pour tous les membres d’un ensemble Zookeeper et tous les noeuds d’un cluster Solrcloud.

Pour la mise à jour de la JVM, je vous laisse seul maitre de la méthode que vous souhaitez utiliser. Par contre, il est important de mettre à jour la JVM sur un seul serveur simultanément. Donc, pour chaque serveur l’un après l’autre, la procédure est la suivante :

  1. arrêter le membre Zookeeper ou le noeud Solr
  2. mettre à jour la JVM
  3. redémarrer le membre Zookeeper ou le noeud Solr et vérification du bon fonctionnement du système

Mise à jour de Zookeeper

Il n’y a pas à prioris de raison de mettre à jour Zookeeper hors du cardre d’une mise à jour de Solr. En effet, pour chaque version de Solr est conseillée une version de Zookeeper. Donc, il n’est pas particulièrement nécessaire de fouiller dans les release notes Zookeeper pour savoir si une mise à jour est doit être faite et pour quelle raison.

La mise à jour de l’ensemble Zookeeper est donc faite lors de la mise à jour de Solr et doit être réalisée en préalable de cette dernière. C’est dans les release notes et la documentation de Solr que l’on trouve les modifications de paramètres à faire dans Zookeeper.

Tout comme pour la JVM, la mise à jour se fait à chaud, membre par membre. Pour chaque membre l’un après l’autre, la procédure est la suivante :

  1. arrêter le membre Zookeeper
  2. renommer le répertoire de l’installation courante avec sauvegarder les données.
  3. installer une nouvelle instance de zookeeper sans donnée, mais en récupérant le fichier de configuration zoo.cfg et le fichier myid (localisé dans le répertoire data)
  4. redémarrer le membre Zookeeper et vérification du bon fonctionnement du système

Après le redémarrage, le membre va rejoindre l’ensemble, mettre à jour ses données et son état interne avec le leader, puis commencer à fonctionner.

Durant cette mise à jour, même si cela reste possible, il ne faut éviter de :

  • charger des fichiers de configuration dans l’ensemble
  • créer, supprimer ou modifier des collections Solr (ne pas utiliser les Cores API et collections API)

Mise à jour de Solrcloud

Autant la mise à jour des JVM ou de l’ensemble Zookeeper est plutôt sans risque si la compatibilité des versions a bien été vérifiée, autant la mise à jour de Solr doit être soigneusement préparée. En effet, une mise à jour de Solr à des impacts multiples :

  • Il faut s’assurer que des fonctionnalités utilisées ne sont pas devenues obsolètes
  • Il faut mettre à jour les fichiers de configuration (solrconfig.xml et schema.xml)
  • Il faut vérifier si une réindexation est nécessaire

Il est donc très important de lire attentivement la documentation Solr au sujet de la mise à jour, à savoir:

Il faut ensuite tester la nouvelle version de Solr avec les configurations mises à jour dans un environnement de tests ou de pre-production.

Une fois toutes ces étapes préalables réalisées et que l’opération est validée, il faut procéder à la mise à jour des noeuds Solr les uns après les autres. Si une ou plusieurs collections n’ont pas de réplica, elle seront indisponibles durant l’intervention sur le noeud qui les héberge.

Pour chaque noeud l’un après l’autre, la procédure est la suivante :

  1. arrêter le noeud solr
  2. renommer le répertoire de l’installation courante
  3. installer une nouvelle instance
  4. copier le répertoire solr home de l’ancienne instance dans la nouvelle
  5. mettre à jour les scripts de démarrage de Solr si ils avaient été modifiés (bin/solr.in.sh)
  6. mettre à jour le répertoire lib du répertoire solr home avec les nouvelles versions des jar fournies dans la distribution de la nouvelle version
  7. redémarrer le noeud Solr

Après le redémarrage, le noeud va synchroniser ses données avec les autres noeuds. Il faut attendre la fin de cette synchronisation avant de mettre à jour le noeud suivant.

Durant cette mise à jour, même si cela reste possible, il ne faut éviter de :

  • Ajouter, supprimer ou modifier une collection
  • Réaliser des écritures massives dans les collections