Elasticsearch:Instance architecture upgrade

• Version : La mise à niveau prend en charge la migration entre architectures avec conservation de la version. Par exemple, une instance v2 exécutant la version 5.5 reste sur la version 5.5 après sa mise à niveau vers l'architecture v3.

• Méthode de mise à niveau : Les instances basées sur une architecture v1/v2 peuvent être mises à niveau vers l'architecture v3 manuellement ou automatiquement.

• Limitations liées au type d'instance : La mise à niveau n'est pas prise en charge pour les instances basées sur une architecture v1/v2 disposant des spécifications suivantes : 1-core 2 GB, 2-core 2 GB, 4-core 4 GB, 8-core 8 GB, 12-core 12 GB ou 16-core 16 GB.

• Limitations régionales : Les mises à niveau sont prises en charge uniquement au sein d'une même région. L'instance source (v1/v2) et l'instance cible (v3) doivent se trouver dans la même région.

• Limitations liées aux fonctionnalités : La mise à niveau n'est pas prise en charge si l'instance basée sur l'architecture v1/v2 a activé l'une des fonctionnalités suivantes :

  • Fonctionnalités principales : réplication inter-clusters (CCR), , connectivité réseau entre instances, haute disponibilité (HA), gestion des performances des applications (APM) ou Logstash.

  • Fonctionnalités étendues : mise à l'échelle élastique (telle que l'Auto Scaling) ou proxy inverse Nginx.

  • Fonctionnalités de stockage : OpenStore (édition Log Enhanced) est activé ou des disques locaux sont utilisés.

  • Prérequis de base : X-Pack n'est pas activé.

  • Zone : la zone principale ne figure pas dans la liste des zones prises en charge par l'architecture v3.

• Limitations opérationnelles : Toutes les opérations de modification d'instance sont interdites pendant la mise à niveau. Effectuez les préparatifs opérationnels nécessaires à l'avance.

• Processus et durée de la mise à niveau :

  • La mise à niveau est effectuée sous forme de déploiement bleu-vert pendant une fenêtre de maintenance planifiée. La topologie du cluster affiche temporairement le double du nombre de nœuds. Aucun frais supplémentaire n'est facturé.

  • La durée de la mise à niveau est proportionnelle au volume de données et dure généralement plusieurs heures. Les anciens nœuds sont mis hors ligne pendant la fenêtre de maintenance que vous avez spécifiée. Ce processus entraîne une brève interruption de service de 1 à 2 secondes.

Étape 1 : Créer une tâche de mise à niveau

1. Accédez à la page de mise à niveau en ligne.

   1. Connectez-vous à la console Alibaba Cloud Elasticsearch.

   2. Dans le volet de navigation de gauche, choisissez Elastic Stack Cloud Native PaaS > Online Migration Tool.

2. Cliquez sur Create pour créer une tâche de mise à niveau et configurer ses paramètres.

   Parameter	Description
   Type	Sélectionnez Architecture Upgrade for Alibaba Cloud Elasticsearch Cluster pour mettre à niveau une instance basée sur l'architecture v1/v2 vers l'architecture v3 et terminer la migration des données.
   Cluster	Sélectionnez l'instance basée sur l'architecture v1/v2 que vous souhaitez mettre à niveau dans la région cible.

3. Cliquez sur OK pour créer la tâche.

Étape 2 : Configurer et exécuter la tâche de mise à niveau

À cette étape, suivez les instructions affichées à l'écran pour configurer la tâche de mise à niveau et terminer la migration des données.

1. Vérification de la mise à niveau et configuration de la fusion.

   Dans l'onglet Configure Source and Destination Clusters, suivez ces étapes pour effectuer une vérification de faisabilité de la tâche de mise à niveau et configurer la fusion.

   1. Vérification de faisabilité : Avant d'effectuer la mise à niveau, le système vérifie automatiquement l'état de santé et la sécurité du cluster source afin de garantir que la mise à niveau est sûre et réalisable.

      Remarque

      • Si le cluster source n'est pas sain ou si le watermark du cluster est trop élevé, nous vous recommandons de ne pas effectuer la mise à niveau.

      • Si X-Pack n'est pas activé pour le cluster source, la mise à niveau n'est pas prise en charge.

      Si la vérification de faisabilité échoue, modifiez les configurations comme indiqué.

   2. Configurer la fusion : Le système détecte automatiquement les paramètres de configuration du cluster source, tels que le nombre de shards de réplica, les politiques de sharding et les autorisations utilisateur. Il crée ensuite un cluster cible basé sur cette configuration, garantissant la synchronisation des paramètres, des ressources et des politiques pour une mise à niveau fluide.

      Remarque

      Cette étape prend environ 20 minutes.

2. Migration des données.

   Dans l'onglet Migrate Data, suivez les étapes illustrées dans la figure suivante pour terminer successivement la fusion des clusters, la migration des réplicas, la migration du nœud maître et la migration des shards primaires.

   Actions	Description	Description
   Cluster merge	Les clusters source et cible sont fusionnés en un seul cluster plus volumineux. Après la fusion, le nombre total de nœuds dans le cluster = nombre de nœuds dans le cluster source + nombre de nœuds dans le cluster cible.	Après la fusion des clusters, Kibana pour le cluster cible est temporairement désactivé. Pendant la migration des données, vous pouvez continuer à utiliser le Kibana du cluster source jusqu'à ce que le basculement du service soit terminé.
   Replica migration	Le système migre les shards de réplica d'index des nœuds du cluster source vers les nœuds du cluster cible.	En cas d'échec ou si les services sont affectés pendant la migration des réplicas, vous pouvez annuler l'opération. Après une annulation, la tâche de mise à niveau échoue et vous devez en créer une nouvelle.
   Master node migration	Le système migre le nœud maître du cluster fusionné depuis le cluster source vers le cluster cible.	Ce changement prend effet immédiatement dès le début de la migration et ne peut pas être annulé. Procédez avec prudence. Remarque Pour les instances de version 7.x et ultérieures, le nœud maître est automatiquement basculé vers un nœud du cluster cible. Pour les instances des versions 5.x et 6.x, qui ne prennent pas en charge le basculement automatique, le nouveau nœud est promu au rang de nœud maître uniquement après la fin de l'isolation réseau et la mise hors ligne de l'ancien nœud.
   Primary shard migration	Le système migre les shards primaires qui stockent les données originales des nœuds du cluster source vers les nœuds du cluster cible.	Une fois la migration des shards primaires commencée, l'opération ne peut pas être annulée. Procédez avec prudence.

3. Isolation réseau.

   Dans l'onglet Switch Business, suivez les instructions affichées à l'écran pour initier une demande d'isolation réseau. Cela empêche les nœuds du cluster source de rejoindre le cluster cible. Le cluster source cesse de fournir des services et le cluster cible prend le relais.

4. Fin de la mise à niveau.

   Une fois l'isolation réseau réussie, la tâche de mise à niveau est terminée. Cliquez sur Go to Cluster List pour consulter les détails de l'instance.

Étape 3 : Valider les données

Une fois la mise à niveau de l'architecture et la migration des données terminées, accédez à l'instance cible v3 depuis la console Kibana. Exécutez des requêtes et des opérations d'écriture pour vérifier que le cluster fonctionne comme prévu. Si vous rencontrez des problèmes, contactez le support technique d'Alibaba Cloud Elasticsearch.