Elasticsearch:Évaluation des spécifications et de la capacité de stockage

Précautions

Les méthodes d'évaluation fournies dans cette rubrique s'appuient sur des résultats de tests réels et l'expérience des utilisateurs. Les exigences en matière de structure des données, de complexité des requêtes, de volume de données, de performances et de modifications des données varient d'un utilisateur à l'autre. Cette rubrique est fournie à titre indicatif uniquement. Nous vous recommandons d'évaluer les spécifications et la capacité de stockage de votre cluster Elasticsearch en fonction de vos données réelles et de vos scénarios métier.

Évaluation de l'espace de stockage

L'espace de stockage d'un cluster Elasticsearch dépend des facteurs suivants :

• Volume des données source.

• Nombre de shards de réplica : chaque shard principal doit avoir au moins un shard de réplica.

• Surcoûts d'indexation : dans la plupart des cas, les surcoûts d'indexation dépassent de 10 % ceux des données source.

  Par exemple, les index de surveillance utilisés par X-Pack pour l'analyse des exceptions génèrent des surcoûts d'indexation. Les index de surveillance incluent les types suivants :

  • .monitoring-es-6-* : ce type d'index consomme une grande quantité d'espace de stockage. Par défaut, Elasticsearch ne conserve que les données d'index créées au cours des sept derniers jours.

  • .monitoring-kibana-6-* : la quantité d'espace de stockage consommée par ce type d'index augmente avec le nombre d'index. Par défaut, Elasticsearch ne conserve que les données d'index créées au cours des sept derniers jours.

  • .watcher-history-3-* : ce type d'index ne consomme qu'une petite quantité d'espace de stockage. Si ces index ne sont plus nécessaires, supprimez-les manuellement.

• Surcoûts internes du cluster Elasticsearch : les opérations internes telles que la fusion des segments et la journalisation génèrent des surcoûts d'indexation. 20 % de l'espace de stockage est réservé à ces surcoûts.

  La quantité d'espace de stockage consommée par les journaux du cluster augmente avec le nombre de requêtes et de transferts de données reçus par le cluster Elasticsearch. Les journaux du cluster incluent les journaux d'exécution, les journaux d'accès et les journaux lents. Par défaut, Elasticsearch ne conserve que les journaux générés au cours des sept derniers jours. Cette durée ne peut pas être modifiée.

• Espace de stockage réservé par le système d'exploitation : par défaut, le système d'exploitation réserve 5 % de l'espace de stockage pour les processus critiques, la récupération du système et les fragments de disque.

• Marge de sécurité du seuil : Elasticsearch réserve au moins 15 % de l'espace de stockage comme seuil de sécurité.

Calculez l'espace de stockage recommandé à l'aide de la formule suivante :

Recommended storage space of the cluster = Volume of source data × (1 + Number of replica shards) × Indexing overheads/(1 - Storage space reserved by the operating system)/(1 - Internal overheads of the cluster)/(1 - Security threshold overheads)
             = Volume of source data × (1 + Number of replica shards) × 1.7
             = Volume of source data × 3.4

Évaluation des spécifications des nœuds et du nombre de nœuds

Nœuds de données

• Nombre maximal de nœuds par cluster = Nombre de vCPU par nœud × 5.

• Le volume maximal de données que chaque nœud d'un cluster Elasticsearch peut stocker varie selon le scénario métier :

  • Scénarios généraux : espace de stockage maximal par nœud = Taille de la mémoire par nœud (GiB) × 30.

  • Scénarios de requête, tels que l'accélération ou l'agrégation sur les requêtes de données : espace de stockage maximal par nœud = Taille de la mémoire par nœud (GiB) × 10.

  • Scénarios de journalisation, tels que l'importation de données de journal ou l'analyse hors ligne : espace de stockage maximal par nœud = Taille de la mémoire par nœud (GiB) × 50.

Le tableau suivant répertorie le nombre maximal de nœuds et l'espace de stockage maximal par nœud pour différentes spécifications de nœud.

Calculez l'espace de stockage total d'un cluster Elasticsearch à l'aide de la formule suivante : Total storage space of an Elasticsearch cluster = Storage space per node × Number of nodes. Déterminez les spécifications de chaque nœud en fonction de l'espace de stockage maximal de chaque nœud et du nombre maximal de nœuds.

Nœuds master dédiés

Si votre cluster Elasticsearch contient un grand nombre de nœuds de données, activez les nœuds master dédiés pour garantir la stabilité du cluster.

Reportez-vous aux instructions suivantes pour déterminer les spécifications des nœuds master dédiés pour votre cluster Elasticsearch :

• Spécifications par défaut : 2 vCPU et 8 GiB de mémoire

• Spécifications si le nombre de nœuds de données dépasse 10 : 4 vCPU et 16 GiB de mémoire

• Spécifications si le nombre de nœuds de données dépasse 30 : 8 vCPU et 32 GiB de mémoire

• Spécifications si le nombre de nœuds de données dépasse 50 : 16 vCPU et 64 GiB de mémoire

Nœuds clients

Si vous utilisez des nœuds clients indépendants, vous pouvez effectuer une opération de réduction sur le résultat de l'évaluation. Dans ce cas, si un ramasse-miettes (GC) intense se produit lors de l'étape de réduction, les nœuds de données ne seront pas affectés.

Si vous activez les nœuds clients, configurez les nœuds clients et les nœuds de données selon un ratio de 1:5 et sélectionnez des spécifications avec un ratio vCPU/mémoire de 1:4 ou 1:8 pour les nœuds clients. Vous devez acheter au moins deux nœuds clients. Par exemple, si vous configurez 10 nœuds de données dont les spécifications sont de 8 vCPU et 32 GiB de mémoire, nous vous recommandons de configurer 2 nœuds clients dont les spécifications sont de 8 vCPU et 32 GiB de mémoire.

Évaluation des shards

Le nombre de shards et la taille de chaque shard affectent la stabilité et les performances d'un cluster Elasticsearch. Planifiez correctement les shards pour tous les index d'un cluster Elasticsearch. Cela permet d'éviter qu'un grand nombre de shards n'affecte les performances du cluster ou ne provoque des charges inégales dans des scénarios métier complexes. Par exemple, si la planification des shards pour un index dans un cluster Elasticsearch est inappropriée, des différences significatives d'utilisation du disque entre les nœuds et des charges CPU inégales peuvent survenir.

Alibaba Cloud fournit les directives suivantes pour vous aider à planifier les shards. Ces directives sont fournies à titre indicatif uniquement.

• Volume de données stockées sur chaque shard

  • Nous vous recommandons de stocker au maximum 30 GiB de données sur chaque shard. Dans des cas particuliers, vous pouvez stocker au maximum 50 GiB de données sur chaque shard.

  • Dans les scénarios d'analyse de journaux ou les scénarios nécessitant des index extrêmement volumineux, assurez-vous que chaque shard ne stocke pas plus de 100 GiB de données.

• Nombre de shards

  • Avant d'allouer des shards pour votre cluster Elasticsearch, évaluez le volume de données que vous souhaitez stocker.

    • Si le volume total de données est important, réduisez la quantité de données à écrire pour diminuer la charge de travail de votre cluster Elasticsearch. Dans ce cas, configurez plusieurs shards principaux pour chaque index et un shard de réplica pour chaque shard principal.

    • Si le volume total de données et le volume de données à écrire sont faibles, configurez un shard principal pour chaque index et un ou plusieurs shards de réplica pour chaque shard principal.

    Remarque

    • Par défaut, un cluster Elasticsearch V7.X ou ultérieur est configuré avec un shard principal pour chaque index et un shard de réplica pour chaque shard principal. Par défaut, un cluster Elasticsearch antérieur à la version V7.X est configuré avec cinq shards principaux pour chaque index et un shard de réplica pour chaque shard principal.

    • Si le volume de données que vous devez stocker est inférieur à 30 GiB, vous pouvez configurer un shard principal pour chaque index et plusieurs shards de réplica pour le shard principal. Cela permet d'équilibrer la charge. Par exemple, si la taille de chaque index est de 20 GiB et que votre cluster Elasticsearch contient cinq nœuds de données, vous pouvez configurer un shard principal pour chaque index et quatre shards de réplica pour chaque shard principal.

  • Maintenez le nombre de shards égal au nombre de nœuds de données ou à un multiple entier du nombre de nœuds de données.

  • Configurez un maximum de cinq shards pour un index sur un nœud.

  • Calculez le nombre total de shards pour tous les index sur un seul nœud à l'aide de l'une des formules suivantes :

    • Pour les clusters avec de petites spécifications : Nombre de shards sur un seul nœud de données = Taille de la mémoire du nœud de données × 30

    • Pour les clusters avec de grandes spécifications : Nombre de shards sur un seul nœud de données = Taille de la mémoire du nœud de données × 50

    Remarque

    • Lors du calcul du nombre de shards, prenez également en compte le volume de données. Si le volume de données est inférieur à 1 TiB, calculez le nombre de shards à l'aide de la formule pour les clusters avec de petites spécifications.

    • Par défaut, le nombre maximal de shards sur un seul nœud dans un cluster Elasticsearch V7.X est de 1 000. Nous vous recommandons de ne pas modifier ce nombre maximal. Si vous souhaitez modifier le nombre de shards sur un seul nœud, augmentez le nombre de nœuds avant d'utiliser le cluster.

    • Configurez les shards en fonction de vos besoins métier. Un plus grand nombre de shards principaux génère plus de surcoûts de performance. Si vous configurez un nombre excessif de shards pour chaque index dans votre cluster Elasticsearch, les descripteurs de fichiers peuvent être épuisés. Il en résultera des pannes sur votre cluster Elasticsearch.

Pour plus d'informations sur l'évaluation des shards, consultez How to size your shards.

Références

• Pour connaître les spécifications de nœud prises en charge dans différentes régions et versions, ou pour acheter un cluster Elasticsearch, consultez la page d'achat.

• Consultez les résultats du test de charge sur les clusters Elasticsearch avec différentes spécifications et versions pour connaître les performances des différentes spécifications de nœud. Pour plus d'informations, consultez les rubriques du répertoire Performance.

• Pour obtenir des informations sur les différences entre les types de cluster Standard Edition et Kernel-enhanced Edition, ainsi que sur les modifications des fonctionnalités dans chaque version de cluster, consultez Version features.

• Ajustez des éléments tels que les spécifications des nœuds, l'espace de stockage des nœuds et le nombre de nœuds pour un cluster Elasticsearch existant en fonction du résultat de l'évaluation. Pour savoir comment effectuer ces opérations et connaître les précautions associées, consultez Upgrade cluster configuration et Downgrade a cluster.

• Vous ne pouvez spécifier le nombre de shards principaux pour un index que lors de sa création. Une fois l'index créé, vous ne pouvez pas modifier ce nombre. Pour savoir comment créer un index, consultez Create an index.

• Si le volume de données stockées sur chaque shard pour un index existant dépasse le volume recommandé, réindexez les données pour cet index. Pour plus d'informations, consultez Use the reindex API to migrate data between Alibaba Cloud Elasticsearch clusters.

  Remarque

  La réindexation des données peut garantir la continuité du service, mais elle prend du temps.

• Pour savoir comment résoudre les charges déséquilibrées sur un cluster Elasticsearch, consultez Unbalanced loads on a cluster.

• Pour savoir comment résoudre la distribution inégale des données chaudes sur les nœuds, consultez Uneven distribution of hot data on nodes.

• Si vous activez la fonctionnalité Auto Indexing, utilisez la fonctionnalité de gestion du cycle de vie des index (ILM) ou un script API Elasticsearch pour supprimer les index obsolètes. Pour plus d'informations sur la fonctionnalité ILM, consultez Manage Heartbeat data with ILM.

• Supprimez rapidement les petits index pour libérer de la mémoire heap.

Raisons des différences de stockage des index

La taille de stockage peut varier considérablement entre les index. Les sections suivantes décrivent les raisons courantes de ces différences et les méthodes de dépannage.

• Paramètres d'analyseur différents : L'analyseur ngram divise le texte en nombreuses petites combinaisons de caractères, ce qui génère beaucoup plus de jetons que l'analyseur standard. Il en résulte un index inversé plus volumineux. Par exemple, pour les mêmes documents, un index utilisant un analyseur ngram avec min_gram=1 et max_gram=4 peut être environ 3,4 fois plus grand que le même index utilisant l'analyseur standard.

• Types de champs et paramètres de mappage différents : Un champ text construit un index inversé, tandis qu'un champ keyword ne le fait pas. Différentes configurations de mappage affectent directement l'utilisation du stockage.

• Nombre de réplicas différent : Une valeur plus élevée pour le paramètre number_of_replicas augmente la consommation totale de stockage.

• Paramètres de compression différents : Le paramètre best_compression utilise l'algorithme DEFLATE. Cet algorithme offre un taux de compression plus élevé que l'algorithme LZ4 default, mais au prix d'une légère réduction des performances en lecture/écriture.

Pour enquêter sur les différences de stockage, effectuez les étapes suivantes :

• Exécutez la commande GET _cat/indices?v&bytes=b pour afficher la taille de stockage de chaque index.

• Exécutez la commande POST <index>/_disk_usage?run_expensive_tasks=true pour analyser la distribution du stockage au niveau des champs et identifier les champs qui consomment le plus d'espace.