downgrade cluster, scale in cluster, downgrade cluster configuration, change cluster configuration, reduce cluster configuration, scale in data nodes, scale in nodes - Elasticsearch

Lorsque le trafic métier fluctue entre les heures de pointe et les heures creuses, l'utilisation des ressources d'un cluster Alibaba Cloud Elasticsearch peut rester faible pendant une longue période. Rétrogradez le cluster pour réduire les spécifications des nœuds, diminuer le nombre de nœuds ou modifier le type de stockage afin d'aligner les ressources sur la demande métier et d'optimiser les coûts.

Précautions

Une rétrogradation peut entraîner des retards de service, des conflits de configuration et des modifications de facturation. Lisez les précautions suivantes avant de poursuivre.

Stabilité du service

Le tableau suivant décrit les règles de stabilité du service applicables lors d'une modification de la configuration du cluster.

Condition

Impact

Mesures d'atténuation

Le cluster est fortement sollicité et ne dispose d'aucun réplica d'index. Une charge élevée signifie des écritures ou des requêtes avec une forte concurrence pendant la rétrogradation, avec une utilisation du CPU supérieure à 60 % ou une utilisation de la mémoire heap JVM supérieure à 50 %.

Délais d'accès occasionnels

Activez un mécanisme de nouvelle tentative sur le client. Augmentez le nombre de réplicas d'index à au moins 1 avant la rétrogradation.

Le nombre de nœuds de données est inférieur ou égal à 2 après la rétrogradation.

Perte de données potentielle

Assurez-vous que chaque index possède au moins 1 réplica avant la rétrogradation. Si la rétrogradation supprime des nœuds de données, migrez d'abord les données hors de ces nœuds.

Les valeurs de charge élevée indiquées dans le tableau précédent décrivent les situations où des délais d'accès peuvent survenir lors d'une modification de configuration. Il ne s'agit pas des seuils de validation vérifiés par le système lors de la soumission d'une commande de rétrogradation. Pour connaître les seuils de validation, consultez la section Charge sécurisée dans Vérifications avant rétrogradation.

Fenêtre de maintenance — Effectuez la rétrogradation pendant les heures creuses de l'activité métier.
Adresses IP des nœuds — Une fois la modification terminée, les adresses IP des nœuds du cluster changent.

Avertissement

Si vous activez la validation faible pour la rétrogradation, le système assouplit la validation des ressources effectuée avant l'opération. Une rétrogradation peut alors entraîner un manque de ressources et affecter la stabilité du cluster et des services. L'indisponibilité du service causée par une rétrogradation effectuée avec cette option activée n'est pas couverte par l'accord de niveau de service (SLA). La validation faible est désactivée par défaut et n'est pas recommandée. Évaluez pleinement les risques avant de l'activer.

Contraintes de configuration

Espace de stockage des nœuds de données — Seuls les clusters utilisant l'architecture de contrôle cloud-native (v3) prennent en charge la rétrogradation de l'espace de stockage des nœuds de données. Un cluster utilisant l'architecture de contrôle v2 ne prend pas en charge la réduction de la capacité du disque d'un seul nœud, et vous ne pouvez pas rétrograder l'espace de stockage d'un cluster v2 via la console ou une API. Pour rétrograder l'espace de stockage d'un cluster v2, contactez le support technique. Pour réduire la capacité totale du disque sans assistance technique, réduisez le nombre de nœuds de données (scale-in). Cette opération modifie le nombre de nœuds dans le cluster.
Version du cluster — Vous ne pouvez pas mettre à niveau la version du cluster simultanément à sa rétrogradation.
Types de nœuds par opération — Une seule opération de rétrogradation ne peut modifier qu'un seul type de nœud.
Nœuds de données élastiques — Les nœuds de données élastiques ne peuvent pas être rétrogradés.
Intervalle entre les modifications — Deux opérations de rétrogradation consécutives sur le même cluster doivent être espacées d'au moins 30 minutes.
Nombre de nœuds après une rétrogradation — L'impact d'une rétrogradation sur le nombre de nœuds dépend de la méthode de mise à jour :
Mise à jour sur place — Le nombre de nœuds reste identique. Seules les spécifications des nœuds ou l'espace de stockage changent.
Mise à jour blue-green — Le système ajoute d'abord un nombre de nouveaux nœuds égal au nombre actuel de nœuds et y migre les données. Une fois la migration terminée, les anciens nœuds sont supprimés. Le nombre final de nœuds correspond au nombre requis par les spécifications cibles de la rétrogradation. Une augmentation temporaire du nombre de nœuds durant ce processus est normale.

Contraintes de spécifications CPU et mémoire

Règle de base — Le CPU et la mémoire cibles doivent représenter au moins la moitié du CPU et de la mémoire actuels.
Spécifications interdites — Les spécifications suivantes ne peuvent pas être utilisées comme cibles de rétrogradation : 1-core 2 GiB, 2-core 2 GiB, 2-core 4 GiB et 4-core 4 GiB.
Nœuds Kibana — 2-core 2 GiB est une cible de rétrogradation valide pour un nœud Kibana, même si cette spécification figure dans la liste des spécifications interdites pour les autres types de nœuds.
Cas particulier — Si vous devez absolument rétrograder vers une spécification interdite, créez un nouveau cluster puis migrez vos données.

Impact sur les coûts

Après avoir soumis une commande de rétrogradation, le système vous facture en fonction de la configuration mise à jour. Pour les règles de facturation, consultez paiement à l'utilisation et abonnement.

Vérifications avant rétrogradation

Une rétrogradation effectuée sans les vérifications suivantes peut faire planter le cluster, entraîner une perte de données ou rendre le service indisponible. Vérifiez chaque élément avant de soumettre la commande de rétrogradation.

Santé du cluster

Exécutez GET _cluster/health pour vous assurer que l'état du cluster est GREEN.

Charge sécurisée

Un cluster prend en charge une rétrogradation s'il remplit les conditions indiquées dans le tableau suivant.

Type de nœud

Utilisation du CPU

Utilisation de la heap JVM

Nœud maître dédié

L'utilisation de pointe d'un seul nœud au cours des dernières 24 heures est inférieure à 30 %.

L'utilisation de pointe d'un seul nœud au cours des dernières 24 heures est inférieure à 25 %.

Autres types de nœuds

Les deux conditions doivent être remplies : l'utilisation de pointe d'un seul nœud au cours des dernières 24 heures est inférieure à 50 %, et l'utilisation moyenne de tous les nœuds au cours des dernières 24 heures est inférieure à 30 %.

Les seuils du tableau précédent sont ceux que le système vérifie lors de la soumission d'une commande de rétrogradation. Ils sont évalués sur une période statistique des dernières 24 heures (le dernier jour), et non par rapport aux valeurs en temps réel affichées sur la page de surveillance. L'utilisation de pointe correspond à l'utilisation la plus élevée atteinte par un seul nœud au cours du dernier jour. L'utilisation moyenne correspond à l'utilisation moyenne de tous les nœuds au cours du dernier jour. Par conséquent, même si la valeur actuelle en temps réel est faible, la validation bloque toujours la commande si l'utilisation de pointe d'un seul nœud ou l'utilisation moyenne de tous les nœuds a dépassé le seuil à un moment donné au cours des dernières 24 heures lorsque vous cliquez sur Downgrade Configuration sur la page Instances et soumettez la commande. Ces seuils de validation diffèrent des valeurs de charge élevée qui décrivent le risque de délais d'accès lors d'une modification de configuration. Pour les valeurs de charge élevée, consultez la section Stabilité du service dans Précautions.

Si un message indique que l'utilisation du CPU est supérieure au seuil de validation lors de la soumission de la commande, vérifiez l'utilisation de pointe d'un seul nœud et l'utilisation moyenne de tous les nœuds au cours du dernier jour par rapport aux seuils listés pour chaque type de nœud dans le tableau précédent. Soumettez à nouveau la commande de rétrogradation une fois que les deux métriques sont inférieures aux seuils.

Préparation des index

Exécutez GET _cat/indices?v pour vérifier si un index a le statut CLOSE. Si tel est le cas, exécutez POST /<index_name>/_open pour ouvrir temporairement ces index. Comme les index ne sont ouverts que temporairement, refermez-les une fois la modification terminée si votre activité métier ne nécessite pas qu'ils restent ouverts. Un index fermé peut entraîner l'échec de la modification de configuration des manières suivantes :
- L'état du cluster ne peut pas atteindre GREEN et atteint au mieux YELLOW. Elasticsearch requiert un état de cluster GREEN avant d'effectuer certaines modifications de configuration sensibles, telles que l'ajustement des règles d'allocation des shards.
- Le cluster réalloue les shards pendant la modification de configuration. Les shards d'un index fermé ne peuvent pas participer à la réallocation, ce qui entraîne l'échec des opérations dépendant d'un état GREEN.
Exécutez GET _cat/indices?v pour vérifier que le nombre de réplicas de chaque index est d'au moins 1.

Pour une instance 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 modification. (Recommandé) Définissez le nombre de réplicas à 1 et augmentez-le manuellement une fois la modification terminée.

Si les index contiennent un grand nombre de fragments de documents supprimés, ces fragments consomment un espace disque substantiel. Une rétrogradation du disque peut échouer à la validation ou signaler une erreur lorsque l'espace disque restant est insuffisant. Pendant les heures creuses de l'activité métier, effectuez un force merge pour supprimer les fragments de documents supprimés et libérer de l'espace disque avant de rétrograder le disque.

Rétrogradation dans la console

Vous pouvez rétrograder un cluster Alibaba Cloud Elasticsearch dans la console ou en appelant une opération API. Pour la méthode API, consultez UpdateInstance. La procédure suivante décrit la méthode via la console.

Choisissez un onglet en fonction de la modification souhaitée. Utilisez l'onglet Downgrade specifications, disk type, and space pour rétrograder les spécifications des nœuds, le type de disque ou l'espace disque. La réduction du nombre de nœuds de données (scale-in) prend en charge deux points d'entrée : la page Remove Data Nodes et Number of data nodes sur la page Downgrade Configuration. Un cluster utilisant l'architecture de contrôle cloud-native (v3) peut être réduit en diminuant directement Number of data nodes sur la page Downgrade Configuration ; utilisez donc l'onglet Downgrade specifications, disk type, and space pour cette opération. Utilisez l'onglet Scale in data nodes si la page de rétrogradation affiche The current page does not support decreasing the number of nodes of this type. For data nodes, go to the cluster data node scale-in page.

Downgrade specifications, disk type, and space

Dans la liste Instances, cliquez sur l'icône « plus » à droite de l'instance cible et sélectionnez Downgrade Configuration dans le menu déroulant.

Autre point d'entrée : Sur la page Basic Information, cliquez sur Configuration Update puis sur Downgrade.
Sur la page Downgrade Configuration, ajustez les paramètres de configuration en fonction de vos besoins métier.

Les paramètres ajustables varient selon le type et la version du cluster. La page Downgrade Configuration fait foi.
- Type de stockage des nœuds — Les rétrogradations suivent cet ordre, de la performance la plus élevée à la plus faible. Pour les contraintes sur les spécifications CPU et mémoire, consultez la section Contraintes de spécifications CPU et mémoire dans Précautions.
  - Disques locaux : du SSD local (disque local NVMe SSD) au SATA local (disque local SATA HDD).
    
    Disques locaux sont des dispositifs de disque dur locaux sur la machine physique hébergeant l'instance ECS. Ils fournissent un accès au stockage local pour l'instance ECS et conviennent aux scénarios métier ayant des exigences très élevées en matière de performances d'E/S de stockage et de stockage de masse rentable.
  - ESSD : Un ESSD (Enterprise SSD) combine le réseau 25 GE et la technologie RDMA pour offrir jusqu'à un million d'opérations de lecture/écriture aléatoires par disque et une faible latence sur chemin unique. Un disque ESSD PL0 ne peut pas être rétrogradé vers un SSD standard.
  - Disques de génération précédente : du SSD standard au ultra disk, puis au basic disk. Ces disques sont progressivement retirés dans certaines régions et zones. (Recommandé) Sélectionnez un ESSD lorsque vous choisissez un disque.
- Rétrogradation de l'espace de stockage des nœuds de données (uniquement pour les clusters utilisant l'architecture de contrôle cloud-native (v3)) — Pour maintenir la stabilité du cluster, l'utilisation de l'espace disque après la rétrogradation doit être inférieure à 60 %. Avant la rétrogradation, assurez-vous que : utilisation actuelle du disque < espace disque après la rétrogradation × 0,6.
  
  Sur la page Basic Information de l'instance, vérifiez Control Architecture et confirmez que sa valeur est cloud-native control architecture (v3). Pour les options disponibles pour un cluster utilisant l'architecture de contrôle v2, consultez la section Contraintes de configuration dans Précautions.
- Rétrogradation du nombre de nœuds de données (réduction du nombre de nœuds de données) — Dans la section Select Change Items, cliquez sur data node et diminuez Number of data nodes pour réduire le nombre de nœuds de données.
  
  Remarque
  La page de rétrogradation de certains clusters ne prend pas en charge la diminution du nombre de nœuds. Si, après avoir diminué Number of data nodes, la page affiche The current page does not support decreasing the number of nodes of this type. For data nodes, go to the cluster data node scale-in page., basculez vers l'onglet Scale in data nodes et effectuez la réduction via le point d'entrée Remove Data Nodes.
- Validation faible pour la rétrogradation (désactivée par défaut, non recommandée) — Après activation de cette option, le système assouplit la validation des ressources effectuée avant la rétrogradation. Pour les risques de stabilité et de SLA liés à cette option, consultez la section Stabilité du service dans Précautions.
  
  Vous n'avez pas besoin de spécifier la méthode de mise à jour. Le système sélectionne automatiquement la méthode de mise à jour optimale (mise à jour sur place ou mise à jour blue-green) en fonction des éléments de configuration que vous modifiez.
Lisez et confirmez les Terms of Service et l'Service Level Agreement. Si vous n'avez aucune objection, cliquez sur Buy Now. Le système facture les frais en fonction de votre méthode de facturation.

Scale in data nodes

Si la page Downgrade Configuration affiche The current page does not support decreasing the number of nodes of this type. For data nodes, go to the cluster data node scale-in page., réduisez le nombre de nœuds de données sur la page Remove Data Nodes.

Sur la page Basic Information de l'instance, cliquez sur Configuration Update puis sur Remove Data Nodes.
Sélectionnez le type de nœud et le nombre de nœuds à supprimer en fonction de vos besoins métier.

Les paramètres ajustables varient selon le type et la version du cluster. La page de la console fait foi. Dans cet exemple, le cluster exécute Enhanced Edition 8.17.0.

Pour Select Node Type, vous pouvez choisir data node ou cold data node. Les options disponibles dépendent de la configuration réelle du cluster. Current Number of Nodes correspond au nombre existant de nœuds de ce type. Dans Number of Nodes to Remove, saisissez le nombre de nœuds que vous souhaitez supprimer cette fois-ci.
Cliquez sur OK. Le système effectue l'opération de réduction et calcule les frais en fonction de la configuration du cluster et de votre méthode de facturation.

Alibaba Cloud Elasticsearch effectue automatiquement une vérification de sécurité des nœuds avant la réduction. Si la vérification échoue, résolvez l'erreur en vous basant sur le message d'erreur et réessayez la réduction.

Si les nœuds de données que vous souhaitez supprimer contiennent des données, le système vous invite à migrer les données. Pour plus d'informations, consultez Migration des données et restauration.

Pendant la modification, l'état du cluster passe à Initializing. Les performances du cluster peuvent fluctuer brièvement et des échecs de requêtes transitoires peuvent survenir. Une fois la modification terminée, l'état du cluster passe à Normal. Pour confirmer que la nouvelle configuration a pris effet, consultez Surveiller la progression et vérifier la rétrogradation.

Migration des données et restauration

Cette section s'applique uniquement lorsque vous réduisez le nombre de nœuds de données. Pour garantir la sécurité de vos données, les nœuds de données que vous réduisez ne doivent pas contenir de données. Si les nœuds de données sélectionnés contiennent des données, le système vous invite à migrer les données. Après la migration, aucune donnée d'index ne reste sur les nœuds sélectionnés et aucune nouvelle donnée d'index n'y est écrite.

Migration des données

Dans la section Remove Data Nodes, cliquez sur Data Migration Tool dans la barre d'invite.

L'outil de migration des données utilise le filtre d'allocation des shards Elasticsearch pour réaliser une migration fluide des données. Votre activité métier ne perçoit pas le processus de migration.
Dans la boîte de dialogue Migrate Data, sélectionnez une méthode de migration des nœuds.

Définissez Migration Node Type sur data node et saisissez le Number of Nodes to Migrate. Le système recommande intelligemment les adresses IP des nœuds à migrer en fonction de la distribution des données et de la santé du cluster. Confirmez une seconde fois la sécurité des données. Cochez la case pour accepter l'Alibaba Cloud Elasticsearch Data Migration Service Agreement, puis cliquez sur OK.
Sélectionnez l'accord de migration des données et cliquez sur OK.

Le tableau suivant décrit les méthodes de migration des nœuds.

Paramètre

Description

Smart Migration

Le système sélectionne automatiquement les nœuds de données à migrer en fonction de ses suggestions.

Custom

Sélectionnez manuellement les nœuds de données à migrer.

Restauration des données

La migration des données est un processus long. Pendant cette période, des modifications de l'état du cluster ou des données peuvent entraîner l'échec de la migration. Vous pouvez afficher les détails dans la Task List. Après l'échec ou la fin de la migration des données, restaurez les nœuds migrés en suivant les étapes ci-dessous :

Connectez-vous à la console Kibana de votre cluster Elasticsearch.

Pour obtenir des instructions, consultez Se connecter à la console Kibana.

Remarque
Les exemples ici utilisent Elasticsearch V6.7.0. Les opérations peuvent varier légèrement pour d'autres versions.
Dans le volet de navigation de gauche, choisissez Management > Dev Tools.

Dans la Console, exécutez la commande suivante pour obtenir les adresses IP des nœuds migrés.

GET _cluster/settings

Après l'exécution réussie de la commande, le résultat suivant est renvoyé.

{
  "transient": {
    "cluster": {
      "routing": {
        "allocation": {
          "exclude": {
            "_ip": "192.168.xx.xx,192.168.xx.xx,192.168.xx.xx"
          }
        }
      }
    }
  }
}

Exécutez la commande suivante pour restaurer les données sur les nœuds migrés.

Restaurez les données sur certains des nœuds. Supprimez les nœuds à restaurer de la configuration, mais conservez les nœuds qui ne sont pas restaurés.

PUT _cluster/settings
{
  "transient": {
    "cluster": {
      "routing": {
        "allocation": {
          "exclude": {
            "_ip": "192.168.xx.xx,192.168.xx.xx"
          }
        }
      }
    }
  }
}

Restaurez les données sur tous les nœuds.

PUT _cluster/settings
{
  "transient": {
    "cluster": {
      "routing": {
        "allocation": {
          "exclude": {
            "_ip": null
          }
        }
      }
    }
  }
}

Exécutez la commande suivante pour vérifier si la restauration des données est terminée.
```
GET _cluster/settings
```
Après l'exécution réussie de la commande, si le résultat renvoyé ne contient pas les adresses IP des nœuds migrés, la tâche de restauration de la migration pour ces nœuds est terminée. Vous pouvez également le déterminer en observant si les shards sont réalloués aux nœuds correspondants.

Remarque

Pendant la migration ou la restauration des données, vous pouvez exécuter la commande GET _cat/shards?v pour afficher l'état de la tâche.

Surveiller la progression et vérifier la rétrogradation

Surveiller la progression de la modification

Dans le coin supérieur droit de la page Basic Information de l'instance, cliquez sur l'icône More (trois lignes horizontales) pour ouvrir le panneau Task List. Dans l'onglet Change Progress, vous pouvez afficher des informations telles que l'heure de début de la modification, le type de modification, l'état de la modification et le pourcentage d'achèvement.

Cliquez sur Show Details pour afficher les détails de la modification.

Vérifier le résultat de la rétrogradation

Une fois la rétrogradation terminée, confirmez sur la page Basic Information du cluster si la configuration a pris effet :

L'état du cluster est revenu à Normal.
Nombre de nœuds et spécifications de stockage — Confirmez que le nombre de nœuds, les spécifications de stockage et l'espace de stockage correspondent à vos attentes.
Équilibrage des shards — Exécutez GET _cat/allocation?v pour vérifier la distribution des shards. Si les shards ne sont pas équilibrés, résolvez le problème en suivant Solutions pour une charge de cluster inégale.

Si la modification de configuration échoue

Affichez l'état de la modification et les détails de la modification dans l'onglet Change Progress du panneau Task List, puis suivez les étapes de dépannage dans Que faire si une modification de configuration du cluster échoue ? dans la section FAQ de cette rubrique.

FAQ

Que faire si une modification de configuration du cluster échoue ?
Puis-je modifier le type de disque cloud pour une instance Elasticsearch ?
La modification de la configuration du cluster affectera-t-elle le service Elasticsearch ?
Le cluster rééquilibre-t-il automatiquement les shards après un changement du nombre de nœuds ?
Que faire si j'ai choisi la mauvaise configuration lors de l'achat d'une instance Elasticsearch ?
Puis-je rétrograder une spécification d'instance après l'avoir mise à niveau ? Si oui, comment ?
Pourquoi ne puis-je pas rétrograder les nœuds de données froides ?
Pourquoi le nombre de nœuds augmente-t-il après une rétrogradation du disque ?

Elasticsearch ajuste le nombre de nœuds pour atteindre la capacité disque cible. Par conséquent, le nombre de nœuds peut augmenter après une rétrogradation du disque.
Les instances Logstash prennent-elles en charge les rétrogradations ?

Les instances Logstash ne prennent pas en charge les opérations de rétrogradation. Pour ajuster la configuration d'une instance Logstash, créez une nouvelle instance et migrez vos données. Les opérations de rétrogradation décrites dans cette rubrique s'appliquent uniquement aux instances Elasticsearch.
Pourquoi n'ai-je pas reçu de remboursement après une rétrogradation ? Comment le remboursement de rétrogradation est-il calculé ?

Montant du remboursement de rétrogradation = frais restants de la spécification d'origine − frais d'achat de la nouvelle spécification. Si le résultat calculé par cette règle est inférieur à 0, les frais restants de la spécification d'origine ne suffisent pas à couvrir les frais d'achat de la nouvelle spécification, et aucun remboursement n'est émis. Ne pas recevoir de remboursement après une rétrogradation est un résultat normal dans ce cas. Vous pouvez vérifier les frais de cette rétrogradation en vous basant sur la règle précédente. Des détails tels que le délai d'arrivée du remboursement et les canaux de remboursement disponibles sont soumis à la description des règles de remboursement de rétrogradation.
Que faire si le message « The order configuration parameters do not meet the validation conditions » apparaît lors du passage de l'abonnement au paiement à l'utilisation ?

Lorsque cette erreur apparaît après avoir cliqué sur Switch to Pay-as-you-go, elle est généralement causée par la compatibilité de la version de l'architecture de l'instance. (Recommandé) Mettez d'abord à niveau l'architecture de l'instance vers V3, puis soumettez à nouveau le passage au paiement à l'utilisation. Si le message concernant les paramètres de configuration de la commande apparaît toujours après la mise à niveau, ou si la version de l'architecture de l'instance ne peut pas être mise à niveau, enregistrez le RequestID renvoyé avec l'erreur et soumettez un ticket afin que le support technique puisse enquêter et traiter le problème.
Que faire si une rétrogradation n'est pas disponible ou si un avertissement concernant des ressources insuffisantes apparaît ?

Dans la console Alibaba Cloud, accédez au bas de la page Downgrade Configuration et activez Weak validation for downgrade pour ignorer certaines vérifications de ressources, y compris les avertissements concernant des ressources insuffisantes lors d'une réduction. Une fois la réduction terminée, effectuez à nouveau l'équilibrage des shards. L'activation de la validation faible ou l'exécution d'une rétrogradation forcée présente des risques pour la stabilité du cluster et peut entraîner une indisponibilité du service ou une perte de données. Procédez uniquement après avoir compris et accepté ces risques.