Elasticsearch:Déséquilibres de charge sur un cluster

Scénario

Un cluster dispose de 3 nœuds master dédiés et de 9 nœuds de données. Les nœuds master possèdent 16 vCPU et 32 Go de mémoire. Les nœuds de données possèdent 32 vCPU et 64 Go de mémoire. Pendant les heures de pointe (16 h 21 – 18 h 00), le cluster traite environ 2 000 QPS en lecture et 1 000 QPS en écriture. L'utilisation du processeur atteint 100 % sur deux nœuds, dégradant les performances des requêtes.

Analyse

1. Vérifiez les instances Elastic Compute Service (ECS) et la surveillance réseau. Pendant les heures de pointe, le nombre de QPS pour les requêtes augmente fortement et l'utilisation du processeur grimpe en flèche sur les nœuds concernés. Cela confirme que les nœuds soumis à une forte charge traitent la majeure partie du trafic des requêtes.

2. Exécutez GET _cat/shards?v pour vérifier la distribution des shards. La sortie indique que les shards de l'index test sont concentrés sur les nœuds à forte charge. L'utilisation du disque y est également plus élevée. Une allocation inégale des shards entraîne un stockage déséquilibré : les nœuds contenant davantage de données gèrent un trafic en lecture et en écriture plus important.

3. Exécutez GET _cat/indices?v pour vérifier la configuration de l'index. L'index test comporte 5 shards primaires et 1 réplica par shard primaire. Les shards ne sont pas répartis uniformément et certains documents sont marqués .del. Lors d'une recherche, Elasticsearch analyse les documents marqués .del puis les filtre, ce qui réduit l'efficacité de la recherche. Exécutez une fusion forcée pendant les heures creuses pour supprimer ces documents.

   pri rep docs.count docs.deleted store.size pri.store.size
   1   1        8640            0      6.7mb          3.3mb
   1   1        8639            0      6.7mb          3.3mb
   1   1        8639            0      6.7mb          3.3mb
   1   1      297847          488    688.7mb        344.8mb
   1   1       93230          364    222.1mb          111mb
   1   1      297803          588    693.5mb        346.1mb
   1   1      297756          540    697.5mb        348.5mb
   1   1      297852          536    687.9mb        343.4mb
   1   1      297750          588    693.1mb        344.2mb
   1   1        8639            0      6.7mb          3.3mb
   1   1        8639            0      6.7mb          3.3mb
   1   1           2            0     19.3kb          8.3kb
   3   1           0            0      1.1kb           576b
   3   1    71888299     15614684      124gb         64.6gb
   3   1           0            0      1.1kb           576b
   1   1        2661            0      2.2mb          1.1mb
   1   1        8639            0      6.7mb          3.3mb
   1   1        8639            0      6.6mb          3.3mb
   1   1      297732          540    700.5mb        349.9mb
   1   1      297795          540    691.6mb        344.7mb

4. Consultez les journaux du cluster et les journaux des requêtes lentes. Toutes les requêtes sont des requêtes de terme normales et aucune erreur n'apparaît dans les journaux du cluster. La cause racine réside dans la distribution des shards, et non dans des problèmes au niveau des requêtes.

Cause racine

Une allocation inégale des shards concentre le stockage et le trafic sur un sous-ensemble de nœuds, provoquant un déséquilibre de l'utilisation du processeur.

Après rééquilibrage des shards, l'utilisation du processeur s'homogénéise sur l'ensemble des nœuds :

Solution

Planifiez le nombre de shards avant de créer les index. Consultez les directives de planification des shards ci-dessous.

Scénario

Un nœud du cluster subit une augmentation soudaine de l'utilisation du processeur, ce qui affecte les performances des requêtes. L'index test comprend 3 shards primaires et 1 réplica par shard primaire, répartis uniformément sur les nœuds. L'index contient de nombreux documents marqués delete.doc. Les instances ECS fonctionnent normalement.

Analyse

1. Ajoutez "profile": true au corps de la requête. La sortie du profilage montre que le Shard 1 de l'index test met plus de temps à répondre aux requêtes que les autres shards.

2. Exécutez des requêtes avec preference=_primary et preference=_replica, toutes deux avec "profile": true. Le shard primaire du Shard 1 est plus lent que son réplica. Cela permet d'isoler le Shard 1 comme étant la cause du problème.

3. Exécutez les commandes suivantes pour inspecter les segments du Shard 1 :

   Les différences de nombre de documents entre un shard primaire et son réplica peuvent s'expliquer par deux raisons : Latence de synchronisation : si des documents sont écrits en continu, le réplica peut temporairement prendre du retard. Une fois les écritures arrêtées, les comptes convergent. ID de document générés automatiquement avec suppressions concurrentes : si vous écrivez des documents avec des ID générés automatiquement et envoyez une requête Delete by Query pour un document qui vient d'être écrit, la suppression s'exécute sur le shard primaire avant que l'écriture ne soit propagée au réplica. Le réplica reçoit alors l'écriture sans la suppression, ce qui entraîne un plus grand nombre de documents sur le réplica. De plus, le shard primaire accumule des documents marqués doc.delete.

   GET _cat/segments/index?v&h=shard,segment,size,size.memory,ip
   GET _cat/shards?v

   La sortie indique que le Shard 1 possède des segments plus volumineux et plus de documents que son shard réplica. Cette différence de taille des segments provoque le déséquilibre de charge.

Solution (choisissez une option)

• Pendant les heures creuses, exécutez une fusion forcée pour compacter les petits segments et supprimer les documents delete.doc.

• Redémarrez le nœud hébergeant le shard primaire. Cette opération promeut le réplica en tant que shard primaire et génère un nouveau réplica à partir de celui-ci, offrant ainsi aux deux shards des structures de segments identiques.

Après optimisation, la charge se répartit uniformément sur les nœuds :

Scénario

Un cluster est déployé sur deux zones : la zone B et la zone C. Les nœuds de la zone C supportent systématiquement une charge plus élevée que ceux de la zone B. Ce déséquilibre n'est pas causé par des différences matérielles ni par une distribution inégale des données.

Analyse

1. Consultez l'utilisation du processeur sur les 4 derniers jours. Les données de surveillance montrent que l'utilisation du processeur a considérablement changé à un moment précis.

   

2. Vérifiez les connexions TCP sur chaque nœud. Le nombre de connexions TCP diffère considérablement entre la zone B et la zone C, ce qui indique un problème de distribution des connexions réseau.

   

3. Vérifiez le comportement de connexion du client. Le client utilise des connexions persistantes et crée peu de nouvelles connexions. Dans les architectures multi-zones, chaque unité de planification sélectionne indépendamment le nœud optimal lors de l'établissement d'une connexion. Lorsque le volume de nouvelles connexions est faible, plusieurs unités de planification peuvent choisir le même nœud. De plus, les nœuds clients Elasticsearch privilégient le transfert des requêtes vers les nœuds situés dans la même zone, ce qui concentre le trafic sur une seule zone.

Solution (choisissez une option)

• Définissez une durée de vie (TTL) pour les connexions sur le client. Utilisez httpClientBuilder.setConnectionTimeToLive() pour forcer le renouvellement périodique des connexions. Par exemple, pour définir une TTL de 5 minutes :

  Utilisez setConnectionTimeToLive() à cet effet. setKeepAliveStrategy() est moins efficace pour redistribuer les connexions.

  httpClientBuilder.setConnectionTimeToLive(5, TimeUnit.MINUTES)

  Pour plus de détails, consultez HttpAsyncClientBuilder.

• Redémarrez les clients simultanément pour forcer l'établissement de nouvelles connexions vers tous les nœuds en même temps.

• Utilisez des nœuds clients dédiés pour router le trafic. Les nœuds clients transfèrent les requêtes vers les nœuds de données, isolant ainsi la couche de routage de la couche de stockage. Même si les nœuds clients deviennent fortement sollicités, les nœuds de données ne sont pas affectés.

Après optimisation, la charge se répartit uniformément entre les zones :

Scénario

Les shards semblent répartis uniformément sur les nœuds, mais un index spécifique possède plus de shards — ou des shards plus volumineux — sur les nœuds à forte charge.

Solution

Définissez index.routing.allocation.total_shards_per_node pour limiter le nombre de shards d'un seul index pouvant atterrir sur un même nœud.

Calculez la valeur comme suit : (shards primaires + shards réplicas) / nombre de nœuds de données. Arrondissez à l'entier supérieur si le résultat n'est pas un nombre entier.

PUT index_name/_settings
{
  "index.routing.allocation.total_shards_per_node": "3"
}