Une approche automatisée pour effectuer une mise à niveau du moteur sur place dans Amazon OpenSearch Service

Les mises à niveau logicielles apportent de nouvelles fonctionnalités et de meilleures performances, et vous tiennent au courant des informations fournies par le fournisseur de logiciels. Cependant, les mises à niveau des services logiciels peuvent être difficiles à réaliser avec succès, en particulier lorsque vous ne pouvez pas tolérer les temps d’arrêt et lorsque les API de la nouvelle version introduisent des modifications importantes et des dépréciations auxquelles vous devez remédier. Cet article vous montre comment passer du moteur Elasticsearch au moteur OpenSearch sur Service Amazon OpenSearch sans avoir besoin d’une mise à niveau intermédiaire vers Elasticsearch 7.10.

Le service OpenSearch prend en charge Recherche ouverte en tant que moteur, avec des versions des séries 1.x à 2.x. Le service prend également en charge les anciennes versions d’Elasticsearch, les versions 1.x à 7.10. Bien qu’OpenSearch apporte de nombreuses améliorations par rapport aux moteurs précédents, il peut sembler décourageant d’envisager non seulement de mettre à niveau les versions, mais également de changer de moteur au cours du processus. La bonne nouvelle est qu’OpenSearch 1.0 est compatible avec Elasticsearch 7.10, ce qui facilite les modifications du moteur. Si vous exécutez une version d’Elasticsearch dans la série 6.x ou au début de la série 7.x sur OpenSearch Service, vous pensez peut-être que vous devez effectuer une mise à niveau vers Elasticsearch 7.10, puis vers OpenSearch 1.3. Cependant, vous pouvez facilement mettre à niveau votre moteur Elasticsearch existant exécutant 6.8, 7.1, 7.2, 7.4, 7.9 et 7.10 dans OpenSearch Service vers le moteur OpenSearch 1.3.

OpenSearch Service effectue diverses vérifications avant d’exécuter une mise à niveau réelle :

• Validation avant de démarrer une mise à niveau
• Préparation de la configuration d’installation pour la version souhaitée
• Provisionnement de nouveaux nœuds avec la même configuration matérielle
• Déplacement de fragments d’anciens nœuds vers des nœuds nouvellement provisionnés
• Suppression des anciens nœuds et des anciennes références de nœuds des points de terminaison OpenSearch

Lors d’une mise à niveau, AWS s’occupe du gros travail indifférencié du provisionnement, du déploiement et du déplacement des données vers un nouveau domaine. Vous êtes responsable de vous assurer qu’il n’y a pas de modifications avec rupture qui affectent la migration des données et le déplacement vers la version la plus récente du domaine OpenSearch. Dans cet article, nous discutons des éléments que vous devez modifier et vérifier avant et après l’exécution d’une mise à niveau des versions 6.8, 7.1, 7.2, 7.4, 7.9 et 7.10 d’Elasticsearch vers 1.3 OpenSearch Service.

Modifications avec rupture avant la mise à niveau

Voici les changements majeurs antérieurs à la mise à niveau :

• Vérification des dépendances pour les clients de langage et les bibliothèques – Si vous utilisez les clients de langage open source de haut niveau d’Elastic, par exemple les bibliothèques client Java, go ou Python, AWS recommande de passer aux versions open source OpenSearch de ces clients. (Si vous n’utilisez pas de client de langage de haut niveau, vous pouvez ignorer cette étape.) Voici quelques étapes pour effectuer une vérification des dépendances :
  • Déterminer la bibliothèque cliente – Choisissez une bibliothèque client appropriée compatible avec votre langage de programmation. Faire référence à Clients de langage OpenSearch pour une liste de toutes les bibliothèques clientes prises en charge.
  • Ajouter des dépendances et résoudre les conflits – Mettez à jour le système de gestion des dépendances de votre projet avec les dépendances nécessaires spécifiées par la bibliothèque cliente. Si votre projet comporte déjà des dépendances qui entrent en conflit avec les dépendances de la bibliothèque cliente OpenSearch, vous pouvez rencontrer des conflits de dépendances. Dans de tels cas, vous devez résoudre les conflits manuellement.
  • Tester et vérifier le client – Testez la fonctionnalité du client OpenSearch en établissant une connexion, en effectuant certaines opérations de base (comme l’indexation et la recherche) et en vérifiant les résultats.
• Suppression des types de mappage – Plusieurs types au sein d’un index étaient obsolètes dans Elasticsearch version 6.x et complètement supprimés dans la version 7.0 ou ultérieure. Les index OpenSearch ne peuvent contenir qu’un seul type de mappage. À partir de la version 2.x d’OpenSearch, le _type de mappage doit être _doc. Vous devez vérifier et corriger le mappage avant de passer à OpenSearch 1.3.

Effectuez les étapes suivantes pour identifier et résoudre les problèmes de mappage :

1. Accédez aux outils de développement et utilisez ce qui suit GET <index> mapping API pour récupérer les informations de mappage pour tous les index :

La réponse de mappage contiendra une structure JSON qui représente le mappage de votre index.

2. Recherchez les clés de niveau supérieur dans la réponse JSON ; chaque clé représente un type personnalisé dans l’index.

Le _doc type est utilisé pour le type par défaut dans Elasticsearch 7.x et OpenSearch Service 1.x, mais vous pouvez voir des types supplémentaires que vous avez définis dans les versions antérieures d’Elasticsearch. Voici un exemple de réponse pour un index avec deux types personnalisés : type1 et type2.

Notez que les index créés dans 5.x continueront à fonctionner dans 6.x comme ils le faisaient dans 5.x, mais les index créés dans 6.x n’autorisent qu’un seul type par index.

{
  "myindex": {
    "mappings": {
      "type1": {
        "properties": {
          "field1_type1": {
            "type": "text"
          },
          "field2_type1": {
            "type": "integer"
          }
        }
      },
      "type2": {
        "properties": {
          "field1_type2": {
            "type": "keyword"
          },
          "field2_type2": {
            "type": "date"
          }
        }
      }
    }
  }
}

Pour corriger les multiples types de mappage dans votre domaine existant, vous devez réindexer les données, où vous pouvez créer un index pour chaque mappage. Il s’agit d’une étape cruciale dans le processus de migration car OpenSearch ne prend pas en charge plusieurs types au sein d’un seul index. Dans les étapes suivantes, nous convertissons un index comportant plusieurs types de mappage en deux index distincts, chacun utilisant le _doc taper.

3. Vous pouvez unifier le mappage en utilisant votre nom d’index existant comme racine et en ajoutant le type comme suffixe. Par exemple, le code suivant crée deux index avec myindex comme nom racine et type1 et type2 comme suffixe :

   # Create an index for "type1"
   PUT /myindex_type1
   
   # Create an index for "type2"
   PUT /myindex_type2

4. Utilisez le _reindex API pour reindex les données de l’index d’origine dans les deux nouveaux index. Alternativement, vous pouvez recharger les données à partir de leur source, si vous les conservez dans un autre système.

   POST _reindex
   {
     "source": {
       "index": "myindex",
       "type": "type1"  
     },
     "dest": {
       "index": "myindex_type1",
       "type": "_doc"  
     }
   }
   POST _reindex
   {
     "source": {
       "index": "myindex",
       "type": "type2"  
     },
     "dest": {
       "index": "myindex_type2",
       "type": "_doc"  
     }
   }

5. Si votre application interrogeait auparavant l’index d’origine avec plusieurs types, vous devrez mettre à jour vos requêtes pour spécifier les nouveaux index avec _doc comme type. Par exemple, si votre client effectuait une requête en utilisant myindexqui a été réindexé à myindex_type1 et myindex_type2puis modifiez vos clients pour qu’ils pointent vers myindex*qui interrogera les deux index.
6. Après avoir vérifié que les données ont été réindexées avec succès et que votre application fonctionne comme prévu avec les nouveaux index, vous devez supprimer l’index d’origine avant de lancer la mise à niveau, car il ne sera pas pris en charge dans la nouvelle version. Soyez prudent lorsque vous supprimez des données et assurez-vous de disposer de sauvegardes si nécessaire.
7. Dans le cadre de cette mise à niveau, Kibana sera remplacé par OpenSearch Dashboards. Lorsque vous avez terminé la mise à niveau à l’étape suivante, vous devez recommander à vos utilisateurs d’utiliser le nouveau point de terminaison, qui sera _dashboards. Si vous utilisez un point de terminaison personnalisé, veillez à le mettre à jour pour qu’il pointe vers /_dashboards.
8. Nous vous recommandons de mettre à jour votre Gestion des identités et des accès AWS (JE SUIS) Stratégies pour utiliser les opérations API renommées. Cependant, OpenSearch Service continuera à respecter les politiques existantes en répliquant en interne les anciennes autorisations API. Politiques de contrôle des services (SCP) introduisent une couche de complexité supplémentaire par rapport à l’IAM standard. Pour éviter que vos stratégies SCP ne soient rompues, vous devez ajouter à la fois les anciennes et les nouvelles opérations API à chacune de vos stratégies SCP.

Démarrer la mise à niveau

Le processus de mise à niveau est irréversible et ne peut être ni suspendu ni annulé. Vous devez vous assurer que tout se passera bien en effectuant une vérification de preuve de concept (POC). En créant un POC, vous garantissez la préservation des données, évitez les problèmes de compatibilité, prévenez les bogues indésirables et atténuez les risques. Vous pouvez exécuter un POC avec un petit domaine sur la nouvelle version et avec un petit sous-ensemble de vos données. Déployez et exécutez tout code frontal qui communique avec OpenSearch Service via l’API sur votre domaine de test. Utilisez votre pipeline d’ingestion pour envoyer également des données à votre domaine de test, en vous assurant que rien ne se casse. Importez ou reconstruisez des tableaux de bord, des alertes, des détecteurs d’anomalies, etc. Cette simple précaution peut rendre votre expérience de mise à niveau plus fluide et sans problème tout en minimisant les perturbations potentielles.

Lorsque OpenSearch Service démarre la mise à niveau, cela peut prendre de 15 minutes à plusieurs heures. Les tableaux de bord OpenSearch peuvent être indisponibles pendant une partie ou la totalité de la durée de la mise à niveau.

Dans cette section, nous montrons comment démarrer une mise à niveau à l’aide du Console de gestion AWS. Vous pouvez également exécuter la mise à niveau à l’aide du Interface de ligne de commande AWS (AWS CLI) ou AWS SDK. Pour plus d’informations, reportez-vous à Démarrage d’une mise à niveau (CLI) et Démarrage d’une mise à niveau (SDK).

1. Prendre un instantané manuel de votre domaine.

Cet instantané sert de sauvegarde que vous pouvez restaurer sur un nouveau domaine si vous souhaitez revenir à l’utilisation de la version précédente.

2. Sur la console OpenSearch Service, choisissez le domaine que vous souhaitez mettre à niveau.
3. Sur le Actions menu, choisissez Mise à niveau.
4. Sélectionnez la version cible comme OpenSearch 1.3. Si vous effectuez une mise à niveau vers une version d’OpenSearch, vous pourrez alors activer le mode de compatibilité. Si vous activez ce paramètre, OpenSearch signale sa version comme 7.10 pour permettre aux clients et plugins open source d’Elastic comme Logstash de continuer à travailler avec votre domaine OpenSearch Service.
5. Choisir Vérifier l’éligibilité à la mise à niveauqui vous aide à identifier s’il existe des modifications importantes que vous devez encore corriger avant d’exécuter une mise à niveau.
6. Choisir Mise à niveau.
7. Vérifiez l’état sur le tableau de bord du domaine pour surveiller l’état de la mise à niveau.

Le graphique suivant donne une démonstration rapide de l’exécution et de la surveillance de la mise à niveau via les étapes précédentes.

Modifications et validations post-mise à niveau

Maintenant que vous avez mis à niveau avec succès votre domaine vers OpenSearch Service 1.3, assurez-vous d’apporter les modifications suivantes :

• Point de terminaison personnalisé – UN point de terminaison personnalisé pour votre domaine OpenSearch Service vous permet de vous référer facilement aux URL de vos tableaux de bord OpenSearch et OpenSearch. Vous pouvez inclure la marque de votre entreprise ou simplement utiliser un point de terminaison plus court et plus facile à retenir que le point de terminaison standard. Dans OpenSearch Service, Kibana a été renommé tableaux de bord. Après avoir mis à niveau un domaine du moteur Elasticsearch vers le moteur OpenSearch, le /_plugin/kibana le point de terminaison change en /_dashboards. Si vous utilisez le point de terminaison Kibana pour configurer un domaine personnalisé, vous devez le mettre à jour pour inclure le nouveau /_dashboards point final.
• Authentification SAML pour les tableaux de bord OpenSearch – Après avoir mis à niveau votre domaine vers OpenSearch Service, vous devez modifier toutes les URL Kibana configurées dans votre fournisseur d’identité (IdP) de /_plugin/kibana à /_dashboards. Les URL les plus courantes sont les URL du service d’assertion consommateur (ACS) et les URL des destinataires.

Conclusion

Cet article explique ce qu’il faut prendre en compte lors de la planification de la mise à niveau de votre moteur Elasticsearch existant dans votre domaine OpenSearch Service vers le moteur OpenSearch. OpenSearch Service continue de prendre en charge les anciennes versions du moteur, y compris les versions open source d’Elasticsearch de 1.x à 7.10. En migrant vers OpenSearch Service, vous pourrez profiter de corrections de bogues, d’améliorations de performances, de nouvelles fonctionnalités de service et de types d’instances étendus pour vos nœuds de données, comme les instances AWS Graviton 2.

Si vous avez des commentaires sur cet article, partagez-les dans la section commentaires. Si vous avez des questions sur cet article, démarrez un nouveau fil de discussion sur le Forum Amazon OpenSearch Service ou contacter l’assistance AWS.

à propos des auteurs

Prashant Agrawal est un architecte de solutions spécialiste de la recherche senior chez Amazon OpenSearch Service. Il travaille en étroite collaboration avec les clients pour les aider à migrer leurs charges de travail vers le cloud et aide les clients existants à affiner leurs clusters pour obtenir de meilleures performances et réduire les coûts. Avant de rejoindre AWS, il a aidé divers clients à utiliser OpenSearch et Elasticsearch pour leurs cas d’utilisation de recherche et d’analyse de journaux. Lorsqu’il ne travaille pas, vous pouvez le trouver en train de voyager et d’explorer de nouveaux endroits. Bref, il aime faire Manger → Voyager → Répéter.

Bansal dur est architecte de solutions chez AWS, spécialisé dans l’analyse. Il a créé des solutions pour aider les organisations à prendre des décisions basées sur les données.