Elasticsearch:Évaluer les spécifications et 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 d'évolution 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 réplicas : chaque shard primaire doit disposer d'au moins un shard 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 comprennent 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-* : l'espace de stockage consommé 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 faible 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.

  L'espace de stockage consommé par les journaux du cluster augmente avec le nombre de requêtes et de poussées de données reçues 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 la fragmentation du disque.

• Surcoûts liés au seuil de sécurité : Elasticsearch réserve au moins 15 % de l'espace de stockage comme seuil de sécurité.

L'espace de stockage recommandé se calcule à 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

Parmi les paramètres des shards, seul le nombre de shards réplicas affecte le résultat de la formule précédente. L'ajout de shards primaires n'augmente pas l'utilisation du disque, car les données existantes sont simplement redistribuées sur un plus grand nombre de shards et le volume total de données reste inchangé. L'ajout de shards réplicas augmente l'utilisation du disque proportionnellement au nombre de réplicas, car chaque shard réplica stocke une copie complète des données. Cela correspond au facteur (1 + Number of replica shards) de la formule. Par conséquent, si un shard unique devient trop volumineux, nous vous recommandons d'augmenter le nombre de shards primaires plutôt que d'ajouter des shards réplicas. Pour augmenter le nombre de shards primaires, utilisez l'API _split pour diviser l'index ou réindexez les données.

É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.

L'espace de stockage total d'un cluster Elasticsearch se calcule à 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.

• Pour un petit volume de données générant une forte charge d'E/S disque, évaluez les spécifications en fonction de la capacité d'E/S plutôt que de la seule capacité de stockage. Un cas typique est celui d'un index contenant environ 10 millions de documents courts, occupant environ 3 Go au total, et faisant principalement l'objet de requêtes par correspondance exacte, par préfixe ou par agrégation. La capacité de stockage n'est pas le goulot d'étranglement dans ce cas, et les exigences en matière de vCPU et de mémoire sont modérées. Toutefois, chaque requête touche un grand nombre de termes et de segments, ce qui génère des lectures aléatoires fréquentes sur le disque. Par conséquent, les E/S disque déterminent la latence des requêtes atteignable. Évaluez conjointement les deux éléments suivants :

  • Spécifications des nœuds : sélectionnez des spécifications avec un ratio vCPU/mémoire de 1:2, et utilisez au moins 4 vCPU et 16 GiB de mémoire pour chaque nœud de données. Un nœud doté de 4 vCPU et 16 GiB de mémoire prend en charge jusqu'à 160 GiB de données dans les scénarios de requête, ce qui laisse une marge suffisante pour un volume de données de cette ampleur. Des spécifications inférieures à cette valeur laissent peu de cache de page pour l'index, et le cluster lit alors davantage de données depuis le disque.

  • Stockage : définissez Storage Type sur Standard SSD lors de l'achat d'un cluster ou de la mise à niveau de sa configuration. Le Standard SSD offre un nombre élevé d'IOPS et un temps de réponse court, et convient à l'analyse en ligne et à la recherche. Les IOPS et le débit qu'un nœud peut atteindre sont déterminés par le type de stockage et les spécifications du nœud, et non par le nombre de shards primaires. L'ajout de shards primaires à un index de cette taille n'augmente pas la capacité d'E/S disponible.

Nœuds maîtres dédiés

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

Reportez-vous aux instructions suivantes pour déterminer les spécifications des nœuds maîtres dédiés de 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 garbage collection (GC) important se produit lors de l'étape de réduction, les nœuds de données ne sont pas affectés.

Si vous activez des 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. Achetez 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 lignes directrices suivantes pour vous aider à planifier les shards. Ces lignes directrices sont fournies à titre indicatif uniquement.

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

  • Nous vous recommandons de ne pas stocker plus de 30 GiB de données sur chaque shard. Dans des cas particuliers, vous pouvez stocker jusqu'à 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 à 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 afin de diminuer la charge de votre cluster Elasticsearch. Dans ce cas, configurez plusieurs shards primaires pour chaque index et un shard réplica pour chaque shard primaire.

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

    Remarque

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

    • Si le volume de données à stocker est inférieur à 30 GiB, vous pouvez configurer un shard primaire pour chaque index et plusieurs shards réplicas pour le shard primaire. Cela permet d'assurer l'équilibrage de charge. Par exemple, la taille de chaque index est de 20 GiB et votre cluster Elasticsearch contient cinq nœuds de données. Dans ce cas, vous pouvez configurer un shard primaire pour chaque index et quatre shards réplicas pour chaque shard primaire.

  • 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 des spécifications modestes : 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 des spécifications élevées : 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 destinée aux clusters avec des spécifications modestes.

    • 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 primaires génère davantage 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.

Les lignes directrices précédentes s'appliquent à un index unique. Si votre cluster stocke plusieurs index métier, les index diffèrent par leur volume de données et leur taux de croissance ; planifiez donc le nombre de shards primaires pour chaque index séparément au lieu d'appliquer une valeur unique à tous les index. Effectuez les étapes suivantes pour chaque index :

1. Recueillez les entrées de planification de l'index. Exécutez la commande GET _cat/indices?v&bytes=b pour obtenir la taille de stockage actuelle de chaque index, puis estimez l'incrément quotidien et la période de rétention de l'index afin d'obtenir le volume de données attendu à la fin de la période de rétention. Enregistrez le nombre de nœuds de données dans le cluster, la taille de la mémoire par nœud de données et le nombre de shards réplicas utilisés par l'index.

2. Calculez le nombre de base de shards primaires en fonction de la taille de stockage par shard. Divisez le volume de données attendu de l'index par 30 GiB et arrondissez le résultat à l'entier supérieur. Dans des cas particuliers, vous pouvez utiliser 50 GiB comme diviseur. Dans les scénarios d'analyse de journaux ou les scénarios nécessitant des index extrêmement volumineux, vous pouvez utiliser 100 GiB. Si le volume de données attendu de l'index reste inférieur à 30 GiB, conservez un shard primaire pour l'index et ajoutez plutôt des shards réplicas, afin que les requêtes sur l'index soient réparties sur les nœuds.

3. Alignez le nombre de shards sur le nombre de nœuds de données. Ajustez la valeur de base de sorte que le nombre total de shards de l'index, calculé à l'aide de la formule Number of primary shards × (1 + Number of replica shards), soit égal au nombre de nœuds de données ou à un multiple entier du nombre de nœuds de données. Il est préférable d'arrondir à l'entier supérieur plutôt qu'à l'entier inférieur, car un shard plus petit laisse de la place pour une croissance future.

4. Vérifiez le résultat par rapport aux limites par nœud. Chaque nœud ne doit pas stocker plus de cinq shards du même index. Le nombre total de shards de tous les index sur un nœud de données ne doit pas dépasser la valeur calculée à l'aide de la formule correspondant aux spécifications de votre cluster : taille de la mémoire du nœud de données × 30 pour les clusters avec des spécifications modestes, ou taille de la mémoire du nœud de données × 50 pour les clusters avec des spécifications élevées. Pour un cluster V7.X, maintenez le nombre de shards sur un seul nœud en dessous de 1 000. Si la somme des shards planifiés de tous les index dépasse ces limites, réduisez le nombre de shards des index ayant le plus petit volume de données, fusionnez les index fractionnés par temps mais rarement interrogés, ou ajoutez des nœuds de données.

Par exemple, un index devrait stocker 300 GiB de données à la fin de sa période de rétention, le cluster contient 6 nœuds de données et l'index utilise 1 shard réplica. Le nombre de base de shards primaires est de 300 GiB / 30 GiB = 10. Pour faire du nombre total de shards un multiple entier de 6, augmentez le nombre de shards primaires à 12. L'index aura alors 24 shards au total, chaque shard stockera environ 25 GiB de données et chaque nœud de données stockera 4 shards de l'index. Les trois lignes directrices sont respectées.

Une fois le calcul terminé pour chaque index, appliquez le plan. Vous ne pouvez spécifier le nombre de shards primaires que lors de la création d'un index. Pour un index déjà existant dont les shards sont trop volumineux, utilisez l'API _split pour diviser l'index ou réindexez les données, et utilisez un modèle d'index pour appliquer la valeur planifiée aux index créés ultérieurement.

Si l'utilisation du disque ou l'utilisation du CPU diffère toujours considérablement entre les nœuds après la mise en œuvre du plan, les shards d'un ou plusieurs index volumineux restent concentrés sur quelques nœuds. Identifiez l'index et le nœud à l'origine du déséquilibre et rééquilibrez les shards en vous basant sur Charges déséquilibrées sur un cluster.

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 Fonctionnalités de version.

• Vous pouvez ajuster 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 obtenir des informations sur la manière d'effectuer ces opérations et sur les précautions associées, consultez Mettre à niveau la configuration du cluster et Rétrograder un cluster.

• Vous ne pouvez spécifier le nombre de shards primaires pour un index que lors de sa création. Une fois l'index créé, vous ne pouvez pas modifier ce nombre pour l'index. Pour obtenir des informations sur la création d'un index, consultez Créer un index.

• Si le volume de données stockées sur chaque shard d'un index existant dépasse le volume recommandé, réindexez les données pour cet index. Pour plus d'informations, consultez Utiliser l'API reindex pour migrer des données entre des clusters Alibaba Cloud Elasticsearch.

  Remarque

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

• Pour obtenir des informations sur la résolution des charges déséquilibrées sur un cluster Elasticsearch, consultez Charges déséquilibrées sur un cluster.

• Pour obtenir des informations sur la résolution de la distribution inégale des données chaudes sur les nœuds, consultez Distribution inégale des données chaudes sur les nœuds.

• 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 Gérer les données Heartbeat avec ILM.

• Supprimez rapidement les petits index afin de 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 volumineux que le même index utilisant l'analyseur standard .

• Types de champs et paramètres de mapping différents : un type de champ text construit un index inversé en tokenisant la valeur du champ en plusieurs jetons. Un type de champ keyword n'effectue pas de tokenisation ; il indexe plutôt la valeur entière du champ comme un seul terme dans l'index inversé, prenant en charge la correspondance exacte (requêtes term ), le tri et les agrégations. Différentes configurations de mapping affectent directement la consommation de 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 de 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.

FAQ

Comment déterminer si mon cluster nécessite une mise à niveau de configuration et si les E/S disque présentent un risque ?

Évaluez le cluster dans l'ordre suivant. Les métriques de ressources vous indiquent si le cluster est proche de sa limite de capacité, et les événements de cluster vous indiquent si les E/S disque sont déjà devenues le goulot d'étranglement.

Étape 1 : Vérifiez si les métriques de ressources restent à un niveau élevé

Sur la page des détails de l'instance, cliquez sur Cluster Monitoring et affichez l'onglet Basic Monitoring. Définissez la plage de temps sur 1 jour, puis sur 7 jours, et vérifiez Node CPU Utilization(%), Node Disk Utilization(%), Node HeapMemory Utilization(%) et Node load_1m. Si une métrique reste supérieure à 80 % pendant les heures ouvrables, ou si load_1m reste proche ou supérieur au nombre de vCPU par nœud, le cluster fonctionne près de sa limite de capacité. Dans ce cas, les performances d'écriture et de requête ainsi que la stabilité du cluster peuvent être affectées, même si aucune alerte critique n'est déclenchée, et vous devez envisager de mettre à niveau la configuration du cluster. L'état du cluster et les métriques QPS d'écriture et de requête sur le même onglet vous aident à confirmer si la charge provient d'une augmentation du trafic ou d'une modification du modèle de requête.

Basic Monitoring fournit sept métriques : état du cluster, QPS d'index de cluster, QPS de requête de cluster, utilisation du CPU des nœuds, utilisation du disque des nœuds, utilisation de la mémoire heap des nœuds et load_1m des nœuds. Il ne fournit pas de graphique IOPS séparé ni de graphique de débit disque ; n'utilisez donc pas les graphiques de surveillance pour déterminer si le disque atteint sa limite d'E/S.

Étape 2 : Identifiez les risques d'E/S disque en fonction des événements de cluster

Cliquez sur Event Center dans le volet de navigation de gauche, et filtrez les événements par plage de temps, ID d'instance et gravité de l'événement. Les événements suivants indiquent que la capacité d'E/S de la configuration de stockage actuelle est devenue un goulot d'étranglement : disk I/O performance bottleneck, high disk I/O utilization et disk throughput throttling. Si un tel événement se produit de manière répétée, ou s'il s'accompagne d'une augmentation de la latence des requêtes ou de requêtes rejetées, le cluster présente un risque de goulot d'étranglement d'E/S, même si l'utilisation du CPU et l'utilisation de la mémoire heap sont normales. Si l'événement indique que le cluster est passé en état lecture seule, traitez-le immédiatement, car les écritures sont déjà bloquées. Les limites supérieures d'IOPS et de débit qui déclenchent ces événements sont déterminées par le type de stockage et les spécifications des nœuds du cluster.

Étape 3 : Soulagez la pression à court terme

• Optimisez les requêtes : réduisez la plage de temps des requêtes, évitez les requêtes avec caractères génériques et les requêtes d'agrégation à haute cardinalité sur les grands index, et supprimez ou fusionnez les index qui sont petits ou ne sont plus interrogés afin de libérer de la mémoire heap.

• Réduisez le nombre de shards réplicas pour les index qui ne nécessitent pas un débit de lecture élevé. Chaque shard réplica stocke une copie complète des données ; la suppression d'un shard réplica réduit donc à la fois l'utilisation du disque et les surcoûts d'écriture.

• Améliorez la distribution des shards en suivant les lignes directrices de la section « Évaluation des shards » de cette rubrique. Vous ne pouvez spécifier le nombre de shards primaires que lors de la création d'un index. Pour un index déjà existant, utilisez l'API _split pour diviser l'index ou réindexez les données, au lieu d'espérer modifier le nombre de shards primaires d'un index en cours d'exécution.

Étape 4 : Mettez le cluster à l'échelle pour une croissance à long terme

Si les métriques restent à un niveau élevé après les optimisations précédentes, ou si le volume de données continue d'augmenter, mettez à niveau la configuration du cluster. Vous pouvez augmenter les spécifications des nœuds, ajouter des nœuds de données ou étendre l'espace de stockage par nœud en vous basant sur Mettre à niveau la configuration du cluster, et réévaluez les spécifications cibles en vous basant sur la section « Évaluation des spécifications des nœuds et du nombre de nœuds » de cette rubrique. Si les E/S disque plutôt que les vCPU ou la mémoire constituent le goulot d'étranglement, évaluez un type de stockage offrant des IOPS plus élevées lors de la planification de la mise à niveau. Si votre cluster utilise des spécifications developer, notez que le service est interrompu pendant la mise à niveau et que le cluster ne peut pas être rétrogradé vers des spécifications developer par la suite.