Unassigned shards, impossibilité de relocate

Bonjour,

Une problématique que je n'arrive pas à résoudre est actuellement en cours.
L'opération est à la base de faire deux montées de version, une première de la 5.4.2 vers la 5.6.16 avant de faire une montée de version majeure vers la 6.8.0.

Après avoir fait deux nodes, il a fallu tout stopper.

J'ai donc cherché la cause:

GET /_cluster/allocation/explain

{
  "index": "siginf-cnfs-syslog-2019.01.25",
  "shard": 3,
  "primary": false,
  "current_state": "unassigned",
  "unassigned_info": {
    "reason": "NODE_LEFT",
    "at": "2019-06-18T11:29:07.442Z",
    "details": "node_left[lkwG5GSVRe2cm-5UQu73hQ]",
    "last_allocation_status": "no_attempt"
  },
  "can_allocate": "throttled",
  "allocate_explanation": "allocation temporarily throttled",
  "node_allocation_decisions": [
    {
      "node_id": "9sh-p97VQ7WK9JMMHphL-A",
      "node_name": "mutsxpidx005-docker-es-2",
      "transport_address": "172.31.249.245:9300",
      "node_attributes": {
        "zone": "SDC3",
        "ml.max_open_jobs": "10",
        "ml.enabled": "true"
      },
      "node_decision": "throttled",
      "deciders": [
        {
          "decider": "throttling",
          "decision": "THROTTLE",
          "explanation": "reached the limit of outgoing shard recoveries [10] on the node [9sh-p97VQ7WK9JMMHphL-A] which holds the primary, cluster setting [cluster.routing.allocation.node_concurrent_outgoing_recoveries=10] (can also be set via [cluster.routing.allocation.node_concurrent_recoveries])"
        }
      ]
    },
    {
      "node_id": "I6s-YOD3SEmRDO9ogU7qHg",
      "node_name": "mutsxpidx005-docker-es-1",
      "transport_address": "172.31.249.245:9301",
      "node_attributes": {
        "zone": "SDC3",
        "ml.max_open_jobs": "10",
        "ml.enabled": "true"
      },
      "node_decision": "throttled",
      "deciders": [
        {
          "decider": "throttling",
          "decision": "THROTTLE",
          "explanation": "reached the limit of outgoing shard recoveries [10] on the node [I6s-YOD3SEmRDO9ogU7qHg] which holds the primary, cluster setting [cluster.routing.allocation.node_concurrent_outgoing_recoveries=10] (can also be set via [cluster.routing.allocation.node_concurrent_recoveries])"
        }
      ]
    },
    {
      "node_id": "bQylteMjSd6RvJ0ioODj6w",
      "node_name": "mutsxpidx008-docker-es-1",
      "transport_address": "172.31.249.250:9300",
      "node_attributes": {
        "zone": "SDC3"
      },
        {
          "decider": "awareness",
          "decision": "NO",
          "explanation": "there are too many copies of the shard allocated to nodes with attribute [zone], there are [2] total configured shard copies for this shard id and [3] total attribute values, expected the allocated shard count per attribute [2] to be less than or equal to the upper bound of the required number of shards per attribute [1]"
        }
      ]
    },
    {
      "node_id": "wz6Mg3p2Tzy2DDKYNkdhEw",
      "node_name": "mutsxpidx004-docker-es-2",
      "transport_address": "172.31.249.244:9300",
      "node_attributes": {
        "zone": "SDC1",
        "ml.max_open_jobs": "10",
        "ml.enabled": "true"
      },
      "node_decision": "no",
      "deciders": [
        {
          "decider": "throttling",
          "decision": "THROTTLE",
          "explanation": "reached the limit of outgoing shard recoveries [10] on the node [wz6Mg3p2Tzy2DDKYNkdhEw] which holds the primary, cluster setting [cluster.routing.allocation.node_concurrent_outgoing_recoveries=10] (can also be set via [cluster.routing.allocation.node_concurrent_recoveries])"
        },
        {
          "decider": "awareness",
          "decision": "NO",
          "explanation": "there are too many copies of the shard allocated to nodes with attribute [zone], there are [2] total configured shard copies for this shard id and [3] total attribute values, expected the allocated shard count per attribute [2] to be less than or equal to the upper bound of the required number of shards per attribute [1]"
        }
      ]
    }
  ]
}

À l'origine, les shards par défaut étaient à 5, que j'ai modifié sur le template principal à 2.
Cependant les anciens étant toujours à 5, je ne peux pas y retoucher.

J'ai recherché sur plusieurs discussions différentes sans réellement trouver de solution, l'état est du coups instable et j'aimerais principalement retrouver un état green avant de continuer la montée de version en sachant que le node master est monté en version et que je suis conscient qu'il ne pourra pas réallouer sur des versions antérieures.

Voici la conf du cluster:

{
  "persistent": {
    "cluster": {
      "routing": {
        "allocation": {
          "node_concurrent_incoming_recoveries": "10",
          "disk": {
            "watermark": {
              "low": "90%"
            }
          },
          "node_initial_primaries_recoveries": "20",
          "enable": "all",
          "node_concurrent_outgoing_recoveries": "10"
        }
      }
    },
    "indices": {
      "recovery": {
        "max_bytes_per_sec": "500mb"
      }
    }
  },
  "transient": {
    "cluster": {
      "routing": {
        "rebalance": {
          "enable": "all"
        },
        "allocation": {
          "cluster_concurrent_rebalance": "2",
          "node_concurrent_recoveries": "5",
          "disk": {
            "watermark": {
              "low": "90%"
            }
          },
          "enable": "all"
        }
      }
    },
    "discovery": {
      "zen": {
        "minimum_master_nodes": "3"
      }
    }
  }
}

En vous remerciant par avance pour votre aide.

Jonathan

Peux-tu mettre à jour ton post et formater ton code/logs etc avec le bouton </> ?

J'ai déplacé ta question sur #in-your-native-tongue:discussions-en-francais. Si tu veux toucher plus de monde, en anglais, tu peux en effet écrire sur #elasticsearch.

Remise en forme effectuée.
Si jamais je n'avais pas de retour efficace en Français, je tenterais en Anglais.
Une journée que je tourne en rond à tenter de trouver une solution, dur dur.

J'ai par contre complètement oublié de mettre l'état du cluster, qui est actuellement en yellow, je posterais son état dès demain matin. Mais j'ai 7000+ Shards d'unassigned.
Bonne soirée.

Salut,

tu peux confirmer que tes disques ne sont pas déjà plein?

Tu peux aussi donner plus de détails sur combien de serveurs? est-ce que ton master fait aussi data? Combien d'index, de replicas etc...

Salut Gabriel,

Merci pour ton retour.
Le watermark a été augmenté par mes soins qui était à 85%.
J'ai effectivement déjà des disques saturés (notamment le master node), alors que d'autres serveurs sont à 35-40%, mais visiblement il n'y a pas de ré-allocation dynamique sur les nœuds avec des espaces disques importants ce qui est un premier problème.

Pour les détails, dans un premier temps, mon master node fait effectivement data.
Voici la liste indexes - shards :

 {
  "cluster_name": "es_cluster_sante",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 10,
  "number_of_data_nodes": 9,
  "active_primary_shards": 12700,
  "active_shards": 17699,
  "relocating_shards": 4,
  "initializing_shards": 36,
  "unassigned_shards": 7665,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 284,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 72772962,
  "active_shards_percent_as_number": 69.68110236220473
}

Je suis actuellement à 2817 indexes.

Hello,

Regarde si les shards sont en train d'être réalloué :slight_smile:
GET _cat/recovery?v&h=i,s,t,ty,st,shost,thost,f,fp,b,bp

Par ailleurs tu as voulu faire un full cluster restart/upgrade ou bien un rolling upgrade ?

Tu as bien pensé à faire la commande ? :

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "none"
  }
} 

=> https://www.elastic.co/guide/en/elasticsearch/reference/5.6/rolling-upgrades.html

Hello Elastock,

Voilà le retour que j'ai avec au total 17000+ lignes:

iginf-snfs-aptisec-2019.05.18               0 9.2s  peer           done  172.31.249.244 172.31.249.241 0   0.0%   0           0.0%
siginf-snfs-aptisec-2019.05.18               0 775ms existing_store done  n/a            172.31.249.244 0   100.0% 0           100.0%
siginf-snfs-aptisec-2019.05.18               1 1.2s  peer           done  172.31.249.248 172.31.249.250 21  100.0% 927027      100.0%
siginf-snfs-aptisec-2019.05.18               2 3.3s  existing_store done  n/a            172.31.249.241 0   100.0% 0           100.0%
siginf-snfs-aptisec-2019.05.18               3 1s    peer           done  172.31.249.245 172.31.249.242 21  100.0% 650603      100.0%
siginf-snfs-aptisec-2019.05.18               4 2.3s  peer           done  172.31.249.241 172.31.249.249 18  100.0% 920972      100.0%
siginf-snfs-aptisec-2019.05.18               4 4.2s  peer           done  172.31.249.244 172.31.249.248 1   100.0% 130         100.0%
siginf-snfs-aptisec-2019.05.19               0 901ms peer           done  172.31.249.244 172.31.249.249 39  100.0% 1004479     100.0%
siginf-snfs-aptisec-2019.05.19               1 663ms peer           done  172.31.249.244 172.31.249.242 1   100.0% 130         100.0%
siginf-snfs-aptisec-2019.05.19               1 2.3s  peer           done  172.31.249.242 172.31.249.250 24  100.0% 965058      100.0%
siginf-snfs-aptisec-2019.05.19               2 677ms peer           done  172.31.249.244 172.31.249.241 1   100.0% 258         100.0%
siginf-snfs-aptisec-2019.05.19               2 356ms existing_store done  n/a            172.31.249.244 0   100.0% 0           100.0%
siginf-snfs-aptisec-2019.05.19               3 953ms peer           done  172.31.249.244 172.31.249.248 18  100.0% 945013      100.0%
siginf-snfs-aptisec-2019.05.19               4 682ms peer           done  172.31.249.244 172.31.249.242 1   100.0% 130         100.0%
siginf-snfs-aptisec-2019.05.16               0 835ms peer           done  172.31.249.244 172.31.249.249 21  100.0% 411584      100.0%
siginf-snfs-aptisec-2019.05.16               0 767ms peer           done  172.31.249.242 172.31.249.250 21  100.0% 411584      100.0%
siginf-snfs-aptisec-2019.05.16               1 1.4s  peer           done  172.31.249.244 172.31.249.241 0   0.0%   0           0.0%
siginf-snfs-aptisec-2019.05.16               1 781ms existing_store done  n/a            172.31.249.244 0   100.0% 0           100.0%
siginf-snfs-aptisec-2019.05.16               2 1.1s  peer           done  172.31.249.241 172.31.249.248 30  100.0% 452068      100.0%
siginf-snfs-aptisec-2019.05.16               3 1.3s  peer           done  172.31.249.244 172.31.249.249 27  100.0% 428035      100.0%
siginf-snfs-aptisec-2019.05.16               3 2s    peer           done  172.31.249.244 172.31.249.242 27  100.0% 428035      100.0%
siginf-snfs-aptisec-2019.05.16               4 1.4s  peer           done  172.31.249.244 172.31.249.241 0   0.0%   0           0.0%
siginf-snfs-aptisec-2019.05.16               4 734ms peer           done  172.31.249.241 172.31.249.244 1   100.0% 635         100.0%
siginf-snfs-aptisec-2019.05.17               0 854ms peer           done  172.31.249.248 172.31.249.249 36  100.0% 1025051     100.0%
siginf-snfs-aptisec-2019.05.17               1 1.5s  peer           done  172.31.249.242 172.31.249.248 30  100.0% 986310      100.0%
siginf-snfs-aptisec-2019.05.17               2 1.8s  peer           done  172.31.249.244 172.31.249.248 33  100.0% 958700      100.0%
siginf-snfs-aptisec-2019.05.17               3 839ms peer           done  172.31.249.241 172.31.249.242 39  100.0% 987625      100.0%
siginf-snfs-aptisec-2019.05.17               4 2.5s  peer           done  172.31.249.244 172.31.249.242 27  100.0% 641350      100.0%
siginf-snfs-aptisec-2019.05.17               4 1.7s  peer           done  172.31.249.242 172.31.249.250 36  100.0% 1006463     100.0%
pgan-logstash-2018.12.01                     0 325ms peer           done  172.31.249.244 172.31.249.241 1   100.0% 573         100.0%
pgan-logstash-2018.12.01                     0 609ms existing_store done  n/a            172.31.249.244 0   100.0% 0           100.0%
pgan-logstash-2018.12.01                     1 869ms existing_store done  n/a            172.31.249.244 0   100.0% 0           100.0%
pgan-logstash-2018.12.01                     1 827ms peer           done  172.31.249.244 172.31.249.245 1   100.0% 510         100.0%
pgan-logstash-2018.12.01                     2 622ms peer           done  172.31.249.250 172.31.249.242 33  100.0% 228203      100.0%
pgan-logstash-2018.12.01                     3 994ms peer           done  172.31.249.248 172.31.249.249 39  100.0% 292436      100.0%
pgan-logstash-2018.12.01                     3 1.4s  peer           done  172.31.249.244 172.31.249.248 39  100.0% 292436      100.0%
pgan-logstash-2018.12.01                     4 1.1s  peer           done  172.31.249.248 172.31.249.250 39  100.0% 262873      100.0%
pgan-logstash-2018.12.02                     0 883ms peer           done  172.31.249.244 172.31.249.242 21  100.0% 172976      100.0%
pgan-logstash-2018.12.02                     1 540ms peer           done  172.31.249.244 172.31.249.249 36  100.0% 274389      100.0%
pgan-logstash-2018.12.02                     1 1s    peer           done  172.31.249.244 172.31.249.250 36  100.0% 274389      100.0%
pgan-logstash-2018.12.02                     2 1s    existing_store done  n/a            172.31.249.241 0   100.0% 0           100.0%
pgan-logstash-2018.12.02                     3 731ms peer           done  172.31.249.242 172.31.249.248 21  100.0% 167026      100.0%
pgan-logstash-2018.12.02                     4 742ms peer           done  172.31.249.249 172.31.249.248 18  100.0% 197545      100.0%

Je suis effectivement sur une stratégie de rolling update pour ne pas couper le service. Mais j'ai dû le stopper me rendant compte que j'avais autant de shards unassigned.

Tu doit stopper la réallocation des shards et l'indexation si tu fait ça , sinon a chaque fois que tu stop un noeuds , les autres noeuds vont commencer à se réallouer les shards , et ça risque de poser encore plus de problèmes si sur certains noeuds tu es deja limite sur l'occupation disque .
Si tu as coupé le service , je te conseille de upgrader en full restart tant qu'a faire .
J'ignore comment sont dimmensionné tes noeuds et quels sont tes uses cases mais tu as 17 000 shards sur 10 nodes(+7665 unnassigned) , donc 1700 shards par node+700 , ça me parait beaucoup.
Je pense que deja tu devrais repenser ta distribution des indexs+ shards une fois l'upgrade terminé .

1780 shards par node !
Il te faudrait au moins 80go de HEAP pour ça.

Quel est la taille de tes shards (au maximum/minimum)?

Quelques ressources
https://www.elastic.co/elasticon/conf/2016/sf/quantitative-cluster-sizing

And https://www.elastic.co/webinars/using-rally-to-get-your-elasticsearch-cluster-size-right

1 Like

Quand je suis arrivé sur le projet, ils faisaient de l'over-sharding, de 5, je suis passé à 2, mais ayant des périodes longues de rétention, je ne peux malheureusement pas modifier les anciens indexes, et donc le nombre de shards ne diminue actuellement pas, mais je conçois que c'est beaucoup trop, une nouvelle architecture cible doit être conçue, il faut que j'arrive à maintenir avec ce que j'ai actuellement.

1 Like

Pour les anciens index, tu peux les réindexer (créer un nouvel index, envoyer les données dedans et supprimer l'ancien index). Au besoin, si le nom de l'index est critique, tu peux utiliser des alias.

Je n'avais pas fait attention à la question, en termes de Shards, on est à 60Go Max pour un shard, 500Mo au plus petit.

Regarde l'API shrink.
Aussi vu que tu n'as pas un volume constant, l'API rollover te permettra sans doute de conserver une taille optimale pour tes index plutôt que des index journaliers.

Bref, les vidéos en parlent. Une version FR d'ailleurs ici:

Super je regarde ça à tête reposée, la journée est fort compliquée avec tous les problèmes successifs ^^ merci à tous pour vos réponses

Bonsoir à tous.

J'ai pu avancer dans mes affaires et repasser le cluster en green en version 5.6.16.
J'ai donc continué mon étape afin de basculer de la version 5.6.16 à la version 6.8.0.
Avant de déployer ma nouvelle version sur mon premier noeud, j'ai stoppé la réallocation des shards comme habituellement.
J'ai procédé à ma montée de version, réglé quelques soucis pour faire tourner mon container, jusque là tout va bien.
Mon noeud a l'air intégré au cluster, je peux passer des commandes curl depuis mon noeud nouvellement installé, cependant j'ai un gros soucis, quand je souhaite remettre la réallocation des shards à "all", j'ai l'erreur suivante :

curl -XPUT 'http://mutsxpidx001.srv.sigma.host:9200/_cluster/settings' -H "Content-Type: application/json"  -d '
"transient": {
"cluster.routing.allocation.enable": "all"
}
}'
{"error":{"root_cause":[{"type":"action_request_validation_exception","reason":"Validation Failed: 1: no settings to update;"}],"type":"action_request_validation_exception","reason":"Validation Failed: 1: no settings to update;"},"status":400}

Je me retrouve donc coincé à ne pas pouvoir remettre en état de marche la réallocation.
Est-ce qu'il y aurait une subtilité, ou plusieurs, lors d'un changement de version majeure?

En vous remerciant.
Bonne soirée

J'ai l'impression que cela te dit que cluster.routing.allocation.enable est déjà sur all.

Je me posais la question effectivement, mais c'est qu'il y a un bug quelque part, il va falloir trouver où, qui m'empêchait de passer cette commande curl par le nom de la machine, sur l'IP nickel, j'ai donc pu faire la montée de version en 6.8.0 sur tout le cluster.
Il me reste d'autres détails à régler mais le plus dur (à priori) est derrière moi.

1 Like

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.