Comment migrer des données entre différentes versions d'Elasticsearch & entre clusters

Vous débutez avec Elasticsearch ? Participez à notre webinaire Premiers pas avec Elasticsearch. Vous pouvez aussi démarrer un essai gratuit sur le cloud ou tester Elastic dès maintenant sur votre machine.

Lorsque vous souhaitez mettre à niveau un cluster Elasticsearch, il est parfois plus facile de créer un nouveau cluster séparé et de transférer les données de l'ancien cluster vers le nouveau. Les utilisateurs ont ainsi l'avantage de pouvoir tester toutes leurs données et configurations sur le nouveau cluster avec toutes leurs applications sans risque d'interruption ou de perte de données.

Les inconvénients de cette approche sont qu'elle nécessite une certaine duplication du matériel et qu'elle peut créer des difficultés lors du transfert et de la synchronisation de toutes les données.

Il peut également être nécessaire d'effectuer une procédure similaire si vous devez migrer des applications d'un centre de données à un autre.

Dans cet article, nous allons discuter et détailler trois façons de transférer des données entre les clusters Elasticsearch.

Comment migrer des données entre clusters Elasticsearch ?

Il existe trois façons de transférer des données entre les clusters Elasticsearch :

1. Réindexation à partir d'un cluster distant
2. Transfert de données à l'aide d'instantanés
3. Transférer des données avec Logstash

L'utilisation d'instantanés est généralement le moyen le plus rapide et le plus fiable de transférer des données. Toutefois, n'oubliez pas que vous ne pouvez restaurer un instantané que sur un cluster de version égale ou supérieure et jamais avec une différence de plus d'une version majeure. Cela signifie que vous pouvez restaurer un snapshot 6.x sur un cluster 7.x, mais pas sur un cluster 8.x.

Si vous avez besoin d'augmenter de plus d'une version majeure, vous devrez réindexer ou utiliser Logstash.

Examinons maintenant en détail chacune des trois options de transfert de données entre clusters Elasticsearch.

1. Réindexation des données d'un cluster distant

Avant de commencer à réindexer, n'oubliez pas que vous devrez configurer les mappages appropriés pour tous les index sur le nouveau cluster. Pour ce faire, vous devez soit créer les index directement avec les mappings appropriés, soit utiliser des modèles d'index.

Réindexation à distance - configuration requise

Pour réindexer à distance, vous devez ajouter la configuration ci-dessous au fichier elasticseearch.yml pour le cluster qui reçoit les données, qui, dans les systèmes Linux, est généralement situé ici : /etc/elasticsearch/elasticsearch.yml. La configuration à ajouter est la suivante :

Si vous utilisez SSL, vous devez ajouter le certificat CA à chaque nœud et inclure ce qui suit dans la commande pour chaque nœud dans elasticsearch.yml :

Vous pouvez également ajouter la ligne ci-dessous à tous les nœuds Elasticsearch afin de désactiver la vérification SSL. Toutefois, cette approche est moins recommandée car elle n'est pas aussi sûre que l'option précédente :

Vous devrez effectuer ces modifications sur chaque nœud et procéder à un redémarrage progressif. Pour plus d'informations sur la manière de procéder, veuillez consulter notre guide.

Commande de réindexation

Après avoir défini l'hôte distant dans le fichier elasticsearch.yml et ajouté les certificats SSL si nécessaire, vous pouvez commencer à réindexer les données avec la commande ci-dessous :

Il peut donc être utile de fixer des valeurs généreuses pour les délais d'attente plutôt que de se fier aux valeurs par défaut.

Examinons maintenant d'autres erreurs courantes que vous pouvez rencontrer lors d'une réindexation à distance.

Erreurs courantes lors de la réindexation à distance

1. La réindexation ne figure pas sur la liste blanche

Si vous rencontrez cette erreur, cela signifie que vous n'avez pas défini l'adresse IP de l'hôte distant ou le nom du nœud DNS dans Elasticsearch comme décrit ci-dessus ou que vous avez oublié de redémarrer les services Elasticsearch.

Pour résoudre ce problème dans le cluster Elasticsearch, vous devez ajouter l'hôte distant à tous les nœuds Elasticsearch et redémarrer les services Elasticsearch.

2. Exception relative au handshake SSL

Cette erreur signifie que vous avez oublié d'ajouter le certificat reindex.ssl.certificate_authorities à elasticsearch.yml comme décrit ci-dessus. Pour l'ajouter :

2. Transfert de données à l'aide d'instantanés

N'oubliez pas, comme indiqué ci-dessus, que vous ne pouvez restaurer un instantané que sur un cluster de version égale ou supérieure et jamais avec une différence de plus d'une version majeure.

Si vous avez besoin d'augmenter de plus d'une version majeure, vous devrez réindexer ou utiliser Logstash.

Les étapes suivantes sont nécessaires pour transférer des données par le biais d'instantanés :

Étape 1. Ajouter le plugin de référentiel au premier cluster Elasticsearch - Afin de transférer des données entre clusters via des snapshots, vous devez vous assurer que le référentiel est accessible à la fois depuis le nouveau et l'ancien cluster. Les référentiels de stockage en nuage tels que AWS, Google et Azure sont généralement idéaux pour cela. Pour prendre des instantanés, veuillez consulter notre guide et suivre les étapes qu'il décrit.

Étape 2. Redémarrer le service Elasticsearch (rolling restart).

Étape 3. Créez un référentiel pour le premier cluster Elasticsearch.

Étape 4 - Ajouter le plugin de référentiel au deuxième cluster Elasticsearch.

Étape 5- Ajouter un référentiel en lecture seule au deuxième cluster Elasticsearch - Vous devrez ajouter un référentiel en répétant les mêmes étapes que celles que vous avez suivies pour créer le premier cluster Elasticsearch.

Remarque importante : lorsque vous connectez le deuxième cluster Elasticsearch au même référentiel AWS S3, vous devez définir le référentiel comme un référentiel en lecture seule :

C'est important parce que vous voulez éviter le risque de mélanger les versions d'Elasticsearch dans le même dépôt d'instantanés.

Étape 6 - Restauration des données vers le deuxième cluster Elasticsearch - Après avoir suivi les étapes ci-dessus, vous pouvez restaurer les données et les transférer vers le nouveau cluster. Veuillez suivre les étapes décrites dans cet article pour restaurer les données dans le nouveau cluster. 

3. Transfert de données à l'aide de Logstash

Avant de commencer à transférer les données avec logstash, n'oubliez pas que vous devrez configurer les mappings appropriés pour tous les index sur le nouveau cluster. Pour ce faire, vous devrez soit créer les index directement, soit utiliser des modèles d'index.

Pour transférer des données entre deux clusters Elasticsearch, vous pouvez configurer un serveur Logstash temporaire et l'utiliser pour transférer vos données entre les deux clusters. Pour les petits clusters, une instance de 2 Go de mémoire vive devrait suffire. Pour les clusters plus importants, vous pouvez utiliser des CPU à quatre cœurs avec 8 Go de RAM.

Pour des conseils sur l'installation de Logstash, voir ici.

Configuration de Logstash pour le transfert de données d'un cluster à l'autre

La configuration de base pour copier un index unique du cluster A vers le cluster B est la suivante :

Pour sécuriser elasticsearch, vous pouvez utiliser la configuration ci-dessous :

Métadonnées de l'index

Les commandes ci-dessus écrivent dans un seul index nommé. Si vous souhaitez transférer plusieurs index et préserver les noms d'index, vous devez ajouter la ligne suivante à la sortie de Logstash :

De même, si vous souhaitez conserver l'identifiant original du document, vous devrez ajouter :

Gardez à l'esprit que la définition de l'ID du document ralentira considérablement le transfert de données, aussi ne conservez-vous l'ID d'origine que si vous en avez besoin.

Synchronisation des mises à jour

Toutes les méthodes décrites ci-dessus prennent un temps relativement long, et il se peut que des données aient été mises à jour dans le cluster d'origine en attendant la fin du processus.

Il existe plusieurs stratégies pour permettre la synchronisation des mises à jour qui ont pu avoir lieu pendant le processus de transfert des données, et vous devriez réfléchir à ces questions avant d'entamer ce processus. Vous devez notamment réfléchir aux points suivants :

• Quelle méthode utilisez-vous pour identifier les données qui ont été mises à jour/ajoutées depuis le début du processus de transfert de données (par exemple, un champ "last_update_time" dans les données) ?
• Quelle méthode pouvez-vous utiliser pour transférer le dernier élément de données ?
• Existe-t-il un risque de duplication des documents ? En général, c'est le cas, à moins que la méthode que vous utilisez ne fixe l'ID du document à une valeur connue lors de la réindexation).

Les différentes méthodes permettant la synchronisation des mises à jour sont décrites ci-dessous.

1. Utilisation des systèmes de file d'attente

Certains systèmes d'ingestion/mise à jour utilisent des files d'attente qui vous permettent de "rejouer" les modifications de données reçues au cours des x derniers jours. Cela peut permettre de synchroniser les modifications effectuées.

2. Réindexation à distance

Répétez le processus de réindexation pour tous les éléments pour lesquels "last_update_time" > a été effectué il y a x jours. Vous pouvez le faire en ajoutant un paramètre "query" à la requête de réindexation.

3. Logstash

Dans l'entrée Logstash, vous pouvez ajouter une requête pour filtrer tous les éléments où "last_update_time" > il y a x jours. Toutefois, ce processus entraînera des doublons dans les données non chronologiques, à moins que vous n'ayez défini l'identifiant du document.

4. Instantanés

Il n'est pas possible de restaurer une partie seulement d'un index. Vous devez donc utiliser l'une des autres méthodes de transfert de données décrites ci-dessus (ou un script) pour mettre à jour toutes les modifications qui ont eu lieu depuis le processus de transfert de données.

Cependant, la restauration des instantanés est un processus beaucoup plus rapide que la réindexation/Logstash, il est donc possible de suspendre les mises à jour pendant une brève période de temps pendant que les instantanés sont transférés afin d'éviter le problème.