Points importants à prendre en compte lors de la mise à niveau d'Elasticsearch 1.x à 2.x

Présentation

Dans tout cycle de vie d'un déploiement logiciel, on doit souvent faire face au besoin d'installer la dernière version d'un produit, à la fois pour bénéficier de nouvelles fonctionnalités et des correctifs mais aussi pour continuer à bénéficier du support. Elasticsearch n'échappe pas à la règle et la version 2.0 comprend des changements majeurs, qui pourraient altérer une installation 1.x existante au cours de la mise à niveau. Vous en retrouverez la liste complète dans la section changements majeurs de la documentation. Notez qu'un redémarrage COMPLET du cluster est nécessaire.

Regardez notre vidéo on sur la mise à niveau d'Elasticsearch 1.x à 2.x.

Comment passer à Elasticsearch 2.x sans problème ?

En effectuant des tests dans un environnement hors production, vous devriez éviter tout échec de mise à niveau ainsi que l'apparition d'incohérences dans vos données. Toutefois cette étape nécessite de la préparation qui pourrait être résumée comme suit :

• Prenez connaissance de la liste des changements majeurs intégrés à la nouvelle version. Vous devriez ainsi éviter les mauvaises surprises si l'une des fonctionnalités que vous utilisiez a été modifiée ou supprimée.
• Paramétrez network.host sur une adresse _non_loopback dans elasticsearch.yml. Notez qu'il peut aussi s'agir d'une interface configurée comme suit : "_[networkInterface]_"; p.ex., "_en0_", "_ens160_" or "_eth0".
• Téléchargez et installez le plugin de migration sur votre cluster avant de lancer la mise à niveau. Vous n'avez pas besoin de redémarrer le nœud. Notez que ce plugin ne fait que vérifier (il ne corrige pas) les mappings, les paramètres des index et les segments, et surligne ensuite ce qui doit être corrigé avant de démarrer le processus de migration. Comme il ne vérifie pas les modèles d'index, vous devez tout de même consulter la documentation des changements majeurs avant de faire une modification manuelle.
• Utilisez la fonction snapshot et restore (un MUST) pour faire une copie de vos données de production dans un environnement de test, et pouvoir les utiliser pour tester la mise à niveau. Mieux vaut altérer cet environnement, le cas échéant, que votre cluster de production.
• Pour passer d'une version majeure à une autre (de 1.x à 2.x) vous devez redémarrer entièrement le cluster.
• Pour les installations non-systemd, nous vous conseillons fortement d'utiliser le tout dernier script init d'Elasticsearch de 1.x à 2.x (il existe de nombreuses différences) :

        2.1 DEB init
        2.1 RPM init

• Apportez toutes les modifications recommandées sur la configuration de votre cluster, ainsi qu'au code back/front-end utilisé par votre application en lien avec cette mise à niveau, d'après les résultats du plugin de migration et du document sur les changements majeurs .
• Suivez toute la documentation sur la mise à niveau des plugins sur Elasticsearch, pour vous assurer qu'ils fonctionnent une fois la dernière version installée.
• Vérifiez que vous avez mis à jour Logstash et Kibana dans une version prise en charge, pour qu'ils soient entièrement compatibles avec Elasticsearch 2.x.
• Notez qu'une mise à niveau de Kibana nécessite aussi la mise à niveau du plugin et de l'agent Marvel car l'interface utilisateur se trouve maintenant dans Kibana.
• Sense est désormais open source et aussi un plugin de Kibana plutôt que Marvel, vous devez donc l'installer manuellement après la mise à niveau.
• Logstash 2.x utilise maintenant le protocole HTTP par défaut. Vous devrez peut-être faire des changements manuels dans la configuration de Logstash. Le plugin de sortie elasticsearch_java peut être installé si besoin.
• Assurez-vous de suivre la bonne procédure de mise à niveau.
• Le processus de mise à niveau des index peut être surveillé. Voir la commande API « vérifier le statut de mise à niveau ».

À l'aide, ma mise à niveau est défaillante !

Si les démons de la mise à niveau tentaient de mettre le chaos dans votre vie, alors que vous aviez scrupuleusement suivi les étapes ci-dessus, tout n'est pas perdu ! Vous pouvez :

• Poser une question à la communauté sur le forum. Notre communauté d'utilisateurs vous surprendra par sa réactivité.
• Soumettre un rapport de bug sur GitHub  si vous pensez avoir rencontré un bug au cours du processus de mise à niveau.
• Si vous êtes un client abonné au support, envoyez un ticket à partir du portail d'assistance. Un membre de l'équipe d'Elastic vous aidera tout au long du processus.

Vous cherchez à réduire au maximum la durée d'indisponibilité ou le créneau de maintenance nécessaire au redémarrage du cluster ?

Si les risques vous paraissent trop importants ou la mise à niveau une montagne trop haute à gravir, envisagez plutôt les mesures suivantes :

• Créez un nouveau cluster sur la nouvelle version d'Elasticsearch, avec les futures versions compatibles de Logstash, Kibana et d'autres plugins (si nécessaire).
• Envoyez les données sources de vos événements à la fois sur l'ancien et le nouveau cluster, et désactivez l'ancien cluster une fois que la période de conservation requise est passée. Cette technique est évidemment plus aisée lorsque les périodes de conservation sont courtes, comme 7 jours ou 1 mois.
• Réindexez votre ensemble complet de données de la source vers le nouveau cluster, puis désactivez l'ancien.

Bien que cette approche requière davantage de ressources physiques (ou virtuelles) au départ (bien qu'un environnement de test puisse être utilisé dans ce but temporairement sans trop de coûts supplémentaires), elle sera limitée dans le temps. Dès que le nouveau cluster contiendra les mêmes données que l'ancien, ainsi que toutes les fonctionnalités requises de votre application front-end, le passage d'un cluster à l'autre sera peut-être la solution la plus simple.

Attention : tout code écrit pour envoyer ou recevoir des données d'Elasticsearch basé sur des mappings ou des fonctions ayant été modifiés (voir les changements majeurs), devra quand même être modifié manuellement quel que soit le type de mise à niveau choisi.

Problèmes connus

Vous trouverez ci-dessous la liste des problèmes connus, ce qui peut être utile lorsque vous choisissez votre type de mise à niveau. Les solutions de dépannage pour les mises à niveau partielles ou ayant échoué, sont aussi fournies.

• Aucun paramétrage de network.host (ou mauvais paramétrage). Avant de lancer Elasticsearch 2.x, assurez-vous de définir network.host: _non_loopback_ dans elasticsearch.yml
• Le plugin de migration est uniquement compatible avec Elasticsearch version 1.x et doit donc être supprimé (ainsi que tous les plugins 1.x) une fois qu'il a confirmé qu'aucun changement n'est requis avant la mise à niveau, avant que vous ne lanciez la mise à niveau.
• Gardez une sauvegarde de tous les fichiers de configuration et laissez la mise à niveau les remplacer (DEB, RPM etc). Modifiez ensuite les nouveaux fichiers de configuration pour qu'ils correspondent aux paramètres requis de votre cluster.
• Assurez-vous que tous les nœuds de votre cluster ont suffisamment d'espace disque avant de lancer la mise à niveau. Ce principe de base de la mise à niveau est trop souvent négligé.
• Vous faites peut-être la mise à niveau à partir d'une très ancienne version (avant 0.90). La version de Lucene doit être compatible avec Elasticsearch 2.x, aussi veuillez consulter la documentation sur l'API de mise à niveau pour savoir si vous devez auparavant faire une requête manuelle de l'API de mise à niveau. 
• Les plugins doivent être à jour pour être compatibles avec la dernière version d'Elasticsearch. Si une nouvelle version d'un plugin est compatible avec la version Elasticsearch 2.x que vous souhaitez installer, vous devez supprimer l'ancien plugin, effectuer la mise à niveau puis installer le nouveau plugin. De même, Elasticsearch ne démarrera pas s'il existe un dossier de plugin contenant un plugin non valide.
• L'agent Marvel doit être installé sur tous les nœuds du cluster. Le plugin de l'agent Marvel a besoin du plugin de licence, aussi vous devez installer celui-ci sur tous les nœuds d'abord. Si cet ordre n'est pas respecté, des problèmes peuvent survenir particulièrement si vous utilisez le nœud client Java et si la librairie "licence" n'est pas déclarée dans votre projet.
• Les nœuds client qui exécutent l'agent Marvel doivent être mis à niveau vers la version Elasticsearch 2.1 ou ultérieure, car des problèmes sont connus avec la version 2.0 pour ce type de nœud avec Marvel.
• Vous ne pourrez pas mettre à niveau les index qui comportent des conflits dans les mappings de champs vers Elasticsearch 2.x (les index ne démarreront peut-être même pas). Le plugin de migration mentionné plus haut devrait déceler ce problème.
• Si vous n'arrivez pas à exécuter le plugin de migration correctement lorsque des index sont fermés et que vous utilisez un filtre dans le plugin, essayez cette solution.
• index_analyzer n'existe plus et les modèles ne sont pas vérifiés par le plugin de migration. Vous pourriez obtenir des exceptions. Pour corriger cela, vous devez mettre à niveau les anciens modèles manuellement.
• Assurez-vous que la version de votre noyau est à jour, car les anciennes versions ont rencontré des problèmes avec la nouvelle fonction fsync utilisée par Elasticsearch 2.x.
• La mise à niveau vers une version majeure comme Elasticsearch 2.x ne fonctionnera pas si des nœuds se trouvent toujours sur d'anciennes versions. Tous les nœuds doivent être mis à niveau vers la nouvelle version au cours du processus de mise à jour du cluster.
• Exécuter des versions incompatibles de Logstash et Kibana après la mise à niveau d'Elasticsearch 2.x.