Elasticsearch:Mettre à niveau la configuration du cluster

Avant de procéder à la mise à niveau

Une mise à niveau peut entraîner une latence du service, des conflits de configuration et des modifications de facturation. Consultez les informations suivantes avant de poursuivre.

• Stabilité du service — Le tableau suivant décrit l'impact d'une mise à niveau sur le service selon différents profils de charge du cluster, ainsi que les mesures à prendre pour chaque profil.

• Fenêtre de maintenance — Effectuez la mise à niveau pendant les heures creuses de votre activité.

• Planification de la capacité

  Évaluer la capacité requise du cluster avant de procéder à la mise à niveau.

• Contraintes de configuration

  • La mise à niveau de la configuration du cluster ne prend pas en charge les mises à niveau de version Elasticsearch.

  • Chaque opération de mise à niveau permet de modifier un seul type de nœud à la fois.

• Impact sur les coûts

  Après soumission de la commande de mise à niveau, le système vous facture selon la configuration mise à jour. Pour les règles de facturation, consultez les rubriques Paiement à l'utilisation et Abonnement.

Spécifications recommandées pour les scénarios courants

Sélectionnez une famille de spécifications de nœud en fonction du goulot d'étranglement actuel des performances de votre cluster :

• L'augmentation de la mémoire peut indirectement améliorer la vitesse d'écriture, car une heap JVM plus grande réduit les pauses GC et une mémoire hors heap plus importante diminue les E/S disque. L'effet réel varie selon la charge de travail et le volume de données. Validez-le dans un environnement de test avant de prendre une décision. Pour une évaluation complète des besoins en capacité du cluster, consultez la rubrique Évaluer la capacité requise du cluster.

• N'utilisez pas de nœuds de 2 vCPU 4 GiB ou moins dans un environnement de production. Pour les environnements de production, utilisez des nœuds d'au moins 4 vCPU 8 GiB. Pour connaître les causes des pics de CPU et des déconnexions de nœuds sur les nœuds de petites spécifications, ainsi que les solutions, reportez-vous à la question relative aux nœuds de petites spécifications dans la section FAQ de cette rubrique.

Vérifications préalables à la mise à niveau

Une mise à niveau qui ignore ces vérifications peut provoquer des pannes du cluster, une perte de données ou une indisponibilité du service. Vérifiez chaque élément avant de poursuivre.

• État de santé du cluster — Exécutez GET _cluster/health et confirmez que l'état du cluster est GREEN. Si le cluster n'est pas sain, résolvez le problème comme indiqué dans la rubrique Erreur de modification du cluster - État du cluster non sain.

• Sécurité de la charge — Exécutez GET _cat/nodes?v et confirmez que l'utilisation du CPU est ≤ 60 %. Si l'utilisation du CPU dépasse 60 %, appliquez les mesures de réponse pour charge élevée indiquées dans le tableau de stabilité du service avant la mise à niveau.

• Préparation des index

  • Exécutez GET /_cat/indices?v pour vérifier si un index se trouve dans l'état CLOSE. Si un index est dans l'état CLOSE, exécutez POST /<index_name>/_open pour l'ouvrir temporairement. Sinon, la mise à niveau risque d'échouer pour les raisons suivantes :

    • Le cluster ne peut pas atteindre l'état GREEN lorsqu'un index est dans l'état CLOSE. ES exige que le cluster soit GREEN avant d'effectuer certaines modifications sensibles, telles que l'ajustement des règles d'allocation des shards.

    • Le cluster réalloue les shards pendant une mise à niveau :

      • Les shards des index fermés ne peuvent pas participer à la réallocation.

      • Les opérations dépendant de l'état GREEN échouent.

      • Le cluster ne peut pas atteindre l'état GREEN et atteint au mieux l'état YELLOW.

  • Si un index CLOSE ne peut pas être ouvert ou supprimé pour des raisons métier, la validation de la mise à niveau peut toujours afficher le message « L'état du cluster n'est pas sain. L'opération actuelle ne peut pas être effectuée. ». Les index CLOSE peuvent déclencher ce message même si GET _cluster/health indique que le cluster est sain. Il s'agit d'un comportement de validation attendu. Dans ce cas, désactivez Intelligent Update sur la page de mise à niveau, définissez la méthode de mise à jour sur In-place Update, puis poursuivez la mise à niveau. Comme In-place Update effectue un roulement des nœuds sans copier les données, conserve les adresses IP des nœuds inchangées et prend relativement moins de temps, elle convient à un cluster contenant de nombreux index CLOSE impossibles à gérer.

    Cette méthode s'applique uniquement aux instances d'architecture V2, sur lesquelles vous pouvez désactiver Intelligent Update. Les instances d'architecture V3 (le nouveau plan de contrôle cloud-native) ne prennent pas en charge la désactivation de Intelligent Update, de sorte que les mises à niveau des spécifications des nœuds et des types de disque sur ces instances utilisent toujours une mise à jour blue-green. Évaluez soigneusement l'impact avant de choisir In-place Update lorsque l'utilisation du cluster est élevée, par exemple CPU > 60 %.

  • Exécutez GET _cat/indices?v pour vérifier si chaque index possède au moins 1 réplica.

    Pour les instances multi-zones, assurez-vous que le nombre de réplicas de tout index dans le cluster est inférieur au nombre de zones pendant la mise à niveau. (Recommandé) Définissez le nombre de réplicas sur 1 et augmentez-le manuellement une fois la mise à niveau terminée.

• Équilibre des shards — Exécutez GET _cat/shards?v pour vérifier si les shards sont déséquilibrés. Confirmer que la distribution des shards est équilibrée avant une mise à niveau est essentiel pour éviter une dégradation des performances ou des pannes du cluster pendant ou après la mise à niveau.

  • prirep : Identifie si un shard est un shard primaire (p) ou un shard réplica (r).

  • state : Vérifiez si un shard réplica est UNASSIGNED et si une migration reste bloquée dans l'état RELOCATING pendant une période prolongée. Ces problèmes empêchent les nouveaux nœuds de recevoir des shards et maintiennent le cluster dans l'état YELLOW ou RED après la mise à niveau. Si ces problèmes surviennent, résolvez-les comme indiqué dans la rubrique Solutions pour une charge de cluster inégale.

Méthode 1 : Mise à niveau via la console

Mettez à niveau la configuration du cluster dans la console Elasticsearch. Les règles et options applicables à chaque élément de configuration sont décrites après la procédure.

1. Connectez-vous à la console Elasticsearch et accédez à la page Instance List.

2. Cliquez sur Upgrade Configuration.

   Point d'entrée alternatif : Sur la page Basic Information, cliquez sur Configuration UpdateUpgrade.

3. Sur la page Change Specifications, ajustez les valeurs des éléments de configuration en fonction de vos besoins métier.

   Les éléments configurables varient selon le type de cluster et la version. Reportez-vous aux options affichées sur la page de mise à niveau.

4. Consultez les Conditions d'utilisation et l'Accord de niveau de service (SLA) en cliquant sur Terms of Service et Service Level Agreement. Si vous acceptez, cliquez sur Buy Now. Le payeur est facturé selon le mode de paiement. Après avoir cliqué sur Buy Now, la mise à niveau démarre. Pour suivre sa progression et vérifier le résultat, consultez la section Suivre la progression et vérifier la mise à niveau de cette rubrique.

• Modifications du nombre de zones — Si la spécification requise est en rupture de stock dans une zone, migrez les nœuds de cette zone avant la mise à niveau.

  • Extension : Vous pouvez passer de 1 zone à 2 ou 3 zones.

  • Réduction : La réduction d'une instance multi-zone à une instance mono-zone n'est pas prise en charge. Si vous devez effectuer cette opération, achetez une nouvelle instance avec la configuration de zone requise, migrez les données vers celle-ci, puis libérez l'instance d'origine une fois la migration terminée.

• Mises à niveau prises en charge pour les spécifications des nœuds et les types de stockage des nœuds, classées de la performance la plus faible à la plus élevée :

  • Disques cloud de génération précédente : disque cloud (disque cloud standard), puis ultra disque cloud, puis SSD standard.

    Ces types de disque ne sont plus disponibles à l'achat dans certaines régions et zones. (Recommandé) Choisissez plutôt des disques cloud ESSD.

  • Disques cloud ESSD : Les disques cloud ESSD (Enterprise SSD) utilisent les technologies de réseau 25 GE et RDMA pour fournir jusqu'à 1 million d'opérations de lecture/écriture aléatoires par disque et des performances à faible latence sur une seule connexion.

  • Disques locaux.

    Un disque local est un dispositif de stockage local sur l'hôte physique d'une instance ECS. Il fournit un accès au stockage local pour les instances ECS et convient aux charges de travail ayant des exigences extrêmement élevées en matière de performances d'E/S de stockage et de stockage de masse rentable.

Mettre à niveau les SSD standard vers des disques cloud ESSD

Si votre cluster présente une utilisation IOUtil du disque élevée atteignant fréquemment sa limite, mettez à niveau le type de disque des SSD standard vers des disques cloud ESSD pour améliorer les performances d'E/S.

Contraintes de mise à niveau du stockage

• Limitations ESSD PL0 : Lorsque vous mettez à niveau une instance SSD standard existante vers un disque cloud ESSD, PL0 n'est pas disponible. Vous ne pouvez sélectionner que PL1 ou un niveau de performance (PL) supérieur. PL0 reste disponible lors de la création d'une nouvelle instance ESSD.

• Forced Update : Si un disque plein provoque un état anormal du cluster, supprimez d'abord les index inutiles ou réduisez le nombre de réplicas pour rétablir l'état GREEN. Sinon, sélectionnez cette option sur la page de mise à niveau pour forcer l'extension de la capacité. Pour connaître l'impact du contournement de la vérification de l'état de santé du cluster, consultez l'option Force Change décrite avec les méthodes de mise à jour ci-dessous.

• Disques locaux : La capacité des disques locaux est physiquement liée aux spécifications des nœuds de l'instance et ne peut pas être ajustée indépendamment. Pour augmenter la capacité des disques locaux, mettez à niveau les spécifications globales des nœuds. Les nouvelles instances ne prennent actuellement en charge que la famille de spécifications « disque cloud de nouvelle génération ». Les disques locaux s'appliquent uniquement aux instances existantes.

• Mise à l'échelle automatique du stockage : ES ne prend pas en charge une fonctionnalité de mise à l'échelle automatique du stockage comme celle du service de base de données ApsaraDB RDS. Mettez à niveau manuellement la configuration du cluster lorsque l'espace disque est insuffisant. Remarques sur les modifications combinées : Si vous devez mettre à niveau les spécifications, changer le type de disque et étendre la capacité simultanément, notez qu'un changement de type de disque prend uniquement en charge une mise à jour blue-green et ne prend pas en charge une mise à jour in-place. Pour éviter plusieurs migrations de données, effectuez les étapes suivantes séparément :

1. Modifiez d'abord les spécifications de l'instance et étendez la capacité. Vous pouvez utiliser Intelligent Update ou une mise à jour in-place. Une fois le service rétabli, effectuez l'étape suivante.

2. Modifiez le type de disque séparément en utilisant une mise à jour blue-green. Une mise à jour blue-green ne peut provoquer de brèves interruptions que lors du basculement des nœuds après la synchronisation des données, et a peu d'impact sur l'activité.

• Intelligent Update (activé par défaut) : Le système sélectionne automatiquement la méthode de mise à jour optimale en fonction des modifications de configuration. Vous pouvez la désactiver et spécifier manuellement une méthode de mise à jour :

• Forced Update : Cette option ignore la vérification de l'état de santé du cluster et force un redémarrage du cluster. Elle peut rendre le service instable pendant le redémarrage et provoquer une interruption de service prolongée ; le temps de récupération dépend du volume de données. Utilisez-la uniquement pour une extension de capacité d'urgence lorsque le cluster est indisponible.

Méthode 2 : Mise à niveau via l'API

Vous pouvez également mettre à niveau la configuration du cluster en appelant une opération API. Pour l'API de mise à niveau du cluster, consultez la documentation de référence API : UpdateInstance.

Suivre la progression et vérifier la mise à niveau

• Pour afficher la progression après le démarrage de la mise à niveau, connectez-vous à la console Elasticsearch, choisissez Elasticsearch Clusters, ouvrez la page Basic Information de l'instance et cliquez sur Show Details.

• Une fois la mise à niveau terminée, vérifiez que la configuration a pris effet sur la page Basic Information du cluster :InitializingNormal

  • La mise à niveau est réussie lorsque l'état de l'instance revient à Normal.

  • Vérifiez que le nombre de zones correspond à vos attentes.

  • Nombre de nœuds et spécifications de stockage : Vérifiez que les nouveaux nœuds ont rejoint le cluster et que les spécifications de stockage sont correctes.

  • Équilibre des shards : Exécutez GET _cat/allocation?v pour vérifier la distribution des shards. Si les shards sont déséquilibrés, résolvez le problème comme indiqué dans la rubrique Solutions pour une charge de cluster inégale.

  Pendant la mise à niveau, l'état du cluster devient Initializing. Les performances du cluster peuvent fluctuer brièvement et des interruptions de requête transitoires peuvent survenir. Une fois la mise à niveau terminée, l'état du cluster devient Normal.

PUT /_cluster/settings
{
  "transient" : {
    "cluster.routing.allocation.enable" : "all"
  }
}

FAQ