Elasticsearch:Mise à niveau de la configuration du cluster

Prérequis

• Stabilité du service

  • Stabilité du service lors des changements de configuration :

    État du cluster	Impact sur le service	Action recommandée
    Charge normale avec réplicas Charge normale : CPU ≤ 60 %, mémoire heap ≤ 50 %, charge < nombre de cœurs.	Le service reste disponible. Une légère baisse de performance est possible.	Aucune action requise.
    Charge élevée sans réplicas Charge élevée : écritures ou requêtes simultanées importantes pendant la mise à niveau, avec CPU > 60 % ou mémoire heap > 50 %.	Des délais d'attente d'accès occasionnels peuvent survenir.	Activez un mécanisme de nouvelle tentative sur le client. Augmentez le nombre de réplicas d'index avant la mise à niveau.
    Charge élevée avec état non sain	Des délais d'attente d'accès occasionnels ou des instabilités du service peuvent survenir.	Rétablissez la santé du cluster avant d'appliquer le changement.

  • Fenêtre de maintenance : effectuez l'opération pendant les heures creuses.

• Planification de la capacité

  Évaluez la capacité requise pour le cluster.

• Contraintes de configuration

  • Vous ne pouvez pas mettre à niveau la version d'Elasticsearch simultanément à la configuration du cluster.

  • Vous ne pouvez modifier qu'un seul type de nœud par opération de mise à niveau.

  • Pour les clusters d'architecture V3, vous ne pouvez pas désactiver la Mise à jour intelligente. Si vous appelez l'opération API de mise à jour de la configuration de l'instance et définissez le paramètre intelligent sur false, le système remplace cette valeur par true. La page de mise à niveau des clusters d'architecture V3 ne propose aucune option pour désactiver la Mise à jour intelligente ; les mises à niveau des spécifications de nœud ou des types de disque utilisent toujours une mise à jour bleu-vert.

• Impact sur les coûts

  Une fois la commande de mise à niveau envoyée, la facturation suit la configuration mise à jour. Règles de facturation : paiement à l'utilisation, abonnement.

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

Lors de la mise à niveau de votre cluster Elasticsearch, choisissez la famille de spécifications adaptée à votre charge de travail pour optimiser l'utilisation des ressources. Le tableau suivant vous aide à identifier la famille de spécifications correspondant le mieux à votre scénario :

Pour plus d'informations sur l'évaluation des spécifications et de la capacité de stockage nécessaires à votre cluster, consultez Évaluer les spécifications et la capacité de stockage.

Vérifications préalables à la mise à niveau

• Santé du cluster

  Exécutez GET _cluster/health pour vérifier que l'état du cluster est GREEN. En cas de problème, résolvez-le en suivant la procédure Erreur de changement de cluster - État de cluster non sain.

• Sécurité de la charge

  Exécutez GET _cat/nodes?v. L'utilisation du CPU doit être ≤ 60 %. Si elle est supérieure, activez les nouvelles tentatives côté client et augmentez le nombre de réplicas d'index.

• État des index

  • Exécutez GET /_cat/indices?v pour rechercher les index fermés. Ouvrez-les avec POST /<index_name>/_open avant de poursuivre. Les index fermés provoquent l'échec des changements de configuration pour les raisons suivantes :

    • Les index fermés empêchent le cluster d'atteindre l'état GREEN, nécessaire aux modifications d'allocation des shards.

    • Lors d'un changement de configuration, le cluster réalloue les shards :

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

      • Les opérations nécessitant l'état GREEN échouent.

      • Le cluster ne peut atteindre que l'état YELLOW au mieux.

  • Si des index fermés ne peuvent être ouverts ou supprimés pour des raisons métier, la console bloque tout de même la mise à niveau avec une erreur d'état de cluster non sain, même si GET _cluster/health indique un état normal. Ce comportement de validation est attendu et dû aux index fermés ; il ne s'agit pas d'un signal contradictoire. Comme solution de contournement, désactivez la Mise à jour intelligente sur la page de mise à niveau et sélectionnez manuellement In-place Update pour poursuivre la mise à niveau. Cette méthode effectue un redémarrage progressif des nœuds sans copie de données, conserve les adresses IP des nœuds et prend moins de temps. Elle convient donc aux clusters contenant de nombreux index fermés impossibles à traiter. Cette solution de contournement s'applique uniquement aux clusters d'architecture V2, où la Mise à jour intelligente peut être désactivée. Pour les clusters d'architecture V3, la Mise à jour intelligente ne peut pas être désactivée, la page de mise à niveau ne propose pas cette option, et les mises à niveau des spécifications de nœud ou des types de disque utilisent toujours une Blue-green Update. Pour identifier la version d'architecture de votre cluster, consultez la section Déterminer la version d'architecture de votre cluster de cette rubrique. Comme pour toute mise à jour sur place, soyez prudent si l'utilisation des ressources est élevée (par exemple, CPU > 60 %).

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

    Pour les déploiements multizones, maintenez le nombre de réplicas inférieur au nombre de zones pendant le changement (recommandé : 1). Augmentez le nombre de réplicas une fois le changement terminé.

• Équilibre des shards

  Exécutez GET _cat/shards?v pour détecter d'éventuels shards déséquilibrés.

  Important

  Des shards déséquilibrés peuvent provoquer une dégradation des performances ou des pannes de cluster après la mise à niveau.

  • prirep : vérifiez si un shard réplica (r) est UNASSIGNED.

  • state : vérifiez si une migration de shard est 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, laissant le cluster dans l'état YELLOW ou RED. Résolvez-les en suivant la procédure Solutions pour une charge de cluster inégale.

Déterminer la version d'architecture de votre cluster

Les clusters ES fonctionnent sur l'une des deux architectures de plan de contrôle, v2 ou v3. Les méthodes de mise à niveau disponibles et la durée estimée diffèrent selon l'architecture (consultez les détails de durée des méthodes de mise à jour dans la section Méthode 1 : Mise à niveau via la console de cette rubrique). Déterminez la version d'architecture de votre cluster avant de procéder à la mise à niveau.

Méthode 1 : Vérification dans la console

Connectez-vous à la console ES, accédez à la page Basic Information de votre instance et vérifiez la valeur du champ Control Plane Deployment Mode. Cette valeur indique la version d'architecture de votre cluster.

Méthode 2 : Détermination par le numéro de version Elasticsearch

Méthode 1 : Mise à niveau via la console

1. Sur la page Instances, cliquez sur Upgrade Configuration.

   Point d'accès alternatif : sur la page Basic Information de votre instance, cliquez sur Configuration Update > Upgrade.

2. Sur la page Upgrade/Downgrade, ajustez les paramètres de configuration selon vos besoins métier.

   Important

   Les paramètres disponibles varient selon le type et la version du cluster. La page de mise à niveau affiche les options applicables.

   • Changements de zone de disponibilité : si le stock est insuffisant pour une spécification dans une zone, migrez d'abord les nœuds.

     Vous pouvez passer d'une zone à deux ou trois zones. La réduction d'un cluster multizone à une seule zone n'est pas prise en charge. Si vous devez réduire le nombre de zones, achetez une nouvelle instance avec la configuration de zone requise, migrez-y vos données, puis libérez l'instance d'origine.

   • Spécifications des nœuds et types de stockage (des performances les plus faibles aux plus élevées) :

     1. Disques cloud de génération précédente : disque cloud standard -> disque cloud ultra -> disque cloud SSD.

        Remarque

        Ces types de disques sont progressivement abandonnés dans certaines régions. Utilisez plutôt des ESSD.

     2. ESSD : les ESSD (Enterprise SSD) utilisent un réseau 25 GbE et RDMA pour offrir jusqu'à 1 million d'IOPS par disque avec une faible latence.

     3. Disques locaux.

        Remarque

        Les disques locaux résident sur la machine physique hôte ECS. Ils conviennent aux charges de travail nécessitant des performances E/S élevées ou un stockage de masse économique.

     Remarque

     Quand passer de SSD à ESSD : si la métrique IOUtil de votre cluster reste constamment élevée et atteint fréquemment 100 %, envisagez de passer des disques cloud SSD aux disques cloud ESSD pour améliorer les performances d'E/S.

     Remarque

     Contraintes de mise à niveau du stockage :

     • Limitation ESSD PL0 : si vous mettez à niveau une instance existante avec disque cloud SSD vers un disque cloud ESSD, le niveau PL0 n'est pas disponible. Vous pouvez uniquement sélectionner PL1 ou un niveau de performance supérieur. Le niveau PL0 reste disponible lors de la création d'une nouvelle instance ESSD.

     • Mise à jour forcée : si un disque est plein et que l'état du cluster devient anormal, supprimez les index inutiles ou réduisez le nombre de réplicas pour rétablir l'état green du cluster avant la mise à niveau. Sinon, vous pouvez sélectionner Forced Update sur la page de mise à niveau pour forcer l'extension de capacité, ce qui peut rendre le service instable pendant le redémarrage. La page de mise à niveau propose également une option Intelligent Update (activée par défaut), qui permet au système de sélectionner automatiquement la méthode de mise à jour adaptée au type de changement.

     • Dépendance aux disques locaux : si votre cluster utilise des disques locaux, la mise à niveau de la capacité de stockage nécessite la mise à niveau globale des spécifications du nœud. Actuellement, seul le type de nœud New generation cloud disk est disponible lors de la création d'une nouvelle instance ; les disques locaux ne sont disponibles que pour les instances existantes.

     • Mise à l'échelle automatique du stockage non prise en charge : Elasticsearch ne propose pas de fonctionnalité de mise à l'échelle automatique du stockage similaire à celle d'ApsaraDB RDS.

     Important

     Considérations sur les changements combinés : si vous devez mettre à niveau les spécifications des nœuds, changer le type de disque et étendre la capacité simultanément, notez que le changement de type de disque ne prend pas en charge les mises à jour sur place — seules les mises à jour bleu-vert sont prises en charge. Pour éviter plusieurs migrations de données, effectuez les changements en étapes distinctes :

     1. Mettez d'abord à niveau les spécifications des nœuds et étendez la capacité. Vous pouvez utiliser la Mise à jour intelligente ou la mise à jour sur place pour ces changements.

     2. Une fois le cluster rétabli, changez le type de disque séparément à l'aide d'une mise à jour bleu-vert.

     Les mises à jour bleu-vert peuvent provoquer de brèves interruptions de connexion uniquement pendant la phase de basculement des nœuds, une fois la synchronisation des données terminée, minimisant ainsi l'impact sur votre activité.

   • Mise à jour intelligente (activée par défaut) : le système sélectionne automatiquement la méthode de mise à jour optimale. Vous pouvez la désactiver et choisir manuellement :

     Méthode de mise à jour	Mécanisme	Durée	Impact sur le service et cas d'utilisation
     Blue-green Update	Ajout de nouveaux nœuds → Copie des données → Basculement transparent	Longue	Les adresses IP des nœuds changent. Des fluctuations temporaires de performance sont possibles. Idéal lorsque la disponibilité prime sur la vitesse de mise à jour.
     In-place Update	Redémarrage progressif des nœuds (aucune copie de données requise).	Courte	Les adresses IP des nœuds restent inchangées. Des fluctuations temporaires de performance sont possibles. Idéal pour résoudre rapidement les goulots d'étranglement de performance. Important Soyez prudent si l'utilisation des ressources est élevée (CPU > 60 %).

     Durée estimée pour les instances d'architecture V2 (mise à jour bleu-vert)

     Pour un cluster d'architecture V2, la mise à niveau des spécifications des nœuds de données ou de la version ES utilise une mise à jour bleu-vert. Estimez la durée comme suit :

     Durée totale = Durée du plan de contrôle + Durée de la migration des données

     • Durée du plan de contrôle = Nombre de nœuds × 10 minutes × 2. Une mise à jour bleu-vert ajoute d'abord de nouveaux nœuds puis supprime les anciens, chaque nœud étant donc compté pour deux cycles d'environ 10 minutes chacun.

     • Durée de la migration des données (en heures) = Volume de données maximal sur un seul nœud de données / indices.recovery.max_bytes_per_sec / 3600. La valeur par défaut de indices.recovery.max_bytes_per_sec est de 40 Mo/s. Vous pouvez appeler l'opération GET /_cluster/settings pour vérifier la valeur actuelle et l'ajuster si nécessaire.

     Exemple : pour un cluster V2 avec 3 nœuds de données, la durée du plan de contrôle est d'environ 3 × 10 × 2 = 60 minutes (soit environ 1 heure). Ajoutez la durée de migration des données calculée avec la formule précédente pour obtenir la durée totale estimée.

     Durée estimée pour les instances d'architecture V3 (mise à jour bleu-vert)

     Pour un cluster d'architecture V3, une Blue-green Update comprend une phase de plan de contrôle et une phase de migration des données :

     Durée totale = Durée du plan de contrôle + Durée de la migration des données

     • Durée du plan de contrôle : environ 10 à 20 minutes. Cela couvre le démarrage des nouveaux nœuds et la suppression des anciens.

     • Durée de la migration des données (en heures) = Volume de données maximal sur un seul nœud de données / indices.recovery.max_bytes_per_sec / 3600. La valeur par défaut de indices.recovery.max_bytes_per_sec est de 40 Mo/s. Vous pouvez appeler l'opération GET /_cluster/settings pour vérifier la valeur actuelle et l'ajuster si nécessaire.

     Exemple : pour un cluster de 3 nœuds avec 3 To de données totales et indices.recovery.max_bytes_per_sec défini sur 100 Mo/s, le volume de données maximal sur un seul nœud de données est d'environ 1 To. La durée de migration des données est d'environ 1 To / 100 Mo/s / 3600 ≈ 2,8 heures. La durée totale de la mise à jour bleu-vert est d'environ 10 minutes + 2,8 heures.

     Remarque

     Toutes les opérations de mise à jour sur place ne déclenchent pas un redémarrage progressif. Pour les clusters d'architecture V3, l'impact sur le service varie selon le scénario de mise à niveau :

     • Mise à niveau de la capacité de stockage : effectuée sous forme d'extension en ligne. Aucun redémarrage de nœud n'est nécessaire et les tâches en cours ne sont pas affectées pendant le changement.

     • Mise à l'échelle horizontale (ajout de nœuds de données) : les nœuds de données existants ne redémarrent pas. Une fois le changement terminé, le cluster rééquilibre automatiquement les shards, et la migration des données consomme certaines ressources du cluster.

     • Mise à niveau des spécifications de nœud ou du type de disque : effectuée par défaut sous forme de Blue-green Update. De nouveaux nœuds sont ajoutés, les données y sont migrées, puis les anciens nœuds sont supprimés. Les requêtes métier peuvent subir des exceptions mineures à la fin du changement, lors du basculement des nœuds.

     Pour les clusters d'architecture V2, les changements de spécifications de nœud redémarrent toujours les nœuds un par un pour terminer la mise à jour.

   • Forced Update : ignore les vérifications de santé et force le redémarrage du cluster. Le temps de récupération dépend du volume de données. À utiliser uniquement pour une mise à l'échelle d'urgence lorsque le cluster est déjà indisponible.

3. Lisez les Terms of Service et le Service Level Agreement. Si vous acceptez, cliquez sur Buy Now. La facturation suit la méthode sélectionnée.

   Pendant le changement, l'état du cluster passe à Initializing avec d'éventuelles fluctuations de performance et des échecs de requêtes transitoires. Une fois terminé, l'état revient à Normal.

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

Appelez l'opération API UpdateInstance.

Surveillance et vérification

• Une fois la mise à niveau lancée, suivez la progression sur la page Basic Information dans la console Elasticsearch Clusters :

  Cliquez sur Show Details :

• Après la mise à niveau, vérifiez la nouvelle configuration sur la page Basic Information :

  • L'état du cluster revient à Active.

  • Zone de disponibilité

  • Nombre de nœuds et stockage : confirmez 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. En cas de déséquilibre, utilisez les Solutions pour une charge de cluster inégale.

FAQ

Mises à niveau et métriques de performance

Opérations de mise à niveau

Autres questions

• Alibaba Cloud Elasticsearch prend-il en charge les mises à niveau ou les rétrogradations de version ?

• Puis-je changer le type de disque cloud pour une instance ES ?

• Le cluster rééquilibre-t-il automatiquement les shards après un changement du nombre de nœuds ?

• La modification de la configuration du cluster affecte-t-elle le service ES ?

• Que faire si j'ai sélectionné la mauvaise configuration lors de l'achat d'une instance ES ?

• Puis-je rétrograder la configuration après avoir mis à niveau les spécifications de l'instance ? Comment ?

• Pourquoi est-il recommandé aux utilisateurs de l'ancienne spécification 1 cœur 2 GiB de mettre à niveau dès que possible ?

• Comment modifier la configuration du cluster pour assurer des opérations métier normales lors d'un pic de trafic temporaire ?

• Que faire si je reçois l'erreur « UpgradeVersionMustFromConsole » lors de la mise à niveau d'un cluster ?

• Dans quelles circonstances puis-je utiliser la fonctionnalité de redémarrage forcé pour ES, et quels en sont les effets ?

• Que faire si une mise à niveau de cluster échoue ou expire ?

• Le changement du type de disque cloud d'une instance ES entraîne-t-il une perte de données ?

• Que faire si une mise à niveau de cluster échoue en raison d'un état non sain, alors que l'état du cluster est indiqué comme GREEN ?

• Puis-je mettre à niveau le CPU d'une instance ES directement pour éviter la migration des données ?