Lorsque certains nœuds gèrent un volume de données chaudes nettement supérieur aux autres, ils subissent une charge élevée tandis que le reste du cluster demeure inactif. Cette rubrique explique comment diagnostiquer ce déséquilibre et le corriger en migrant manuellement les shards.
Symptômes
Vous rencontrez probablement ce problème si vous constatez l’un des symptômes suivants :
Un nœud fortement sollicité détient un nombre disproportionné de shards partageant le même attribut (par exemple, uniquement des shards primaires).
Un nœud saturé héberge plus de shards pour les index métier que les autres nœuds.
Avant de commencer
La migration manuelle des shards est une solution temporaire. Si des nœuds quittent brièvement le cluster et que la réallocation des shards s’exécute, le déséquilibre risque de réapparaître. Avant de migrer des shards, traitez la cause racine en suivant les recommandations décrites dans Charges déséquilibrées sur un cluster.
Si les shards sont déjà répartis équitablement mais que le cluster reste soumis à une charge élevée, mettez à niveau la configuration du cluster à la place.
Migration manuelle des shards
Étape 1 : Désactivez l’allocation des shards
Exécutez la commande suivante pour désactiver temporairement l’allocation des shards. Cela empêche Elasticsearch de déplacer automatiquement les shards pendant la migration manuelle.
PUT /_cluster/settings
{
"transient" : {
"cluster.routing.allocation.enable" : "none"
}
}Réactivez l’allocation des shards une fois la migration terminée (étape 4). Le maintien de cette fonctionnalité désactivée peut nuire à la récupération et à la résilience du cluster.
Étape 2 : Migrez le shard
Utilisez l’API cluster reroute pour déplacer un shard spécifique d’un nœud vers un autre. L’exemple suivant déplace le shard 3 de l’index index_parkingorder_v1 depuis 192.168.130.77 vers 192.168.130.78.
POST /_cluster/reroute
{
"commands" : [
{
"move" : {
"index" : "index_parkingorder_v1",
"shard" : 3,
"from_node" : "192.168.130.77",
"to_node" : "192.168.130.78"
}
}
]
}Contrainte : le nœud cible ne doit pas déjà détenir un shard du même index avec le même numéro de séquence. Par exemple, si le shard réplica 3 d’un index se trouve sur le nœud A, le shard primaire 3 de cet index ne peut pas être migré vers le nœud A.
Pour consulter la référence complète de l’API reroute, voir cluster-reroute.
Étape 3 : Vérifiez la migration
Exécutez la commande suivante pour vérifier l’allocation actuelle des shards :
GET _cat/shards?vLe résultat liste chaque shard avec son état et le nœud auquel il est assigné. Recherchez le shard migré dans la sortie et confirmez les points suivants :
Il apparaît sur le nœud cible.
Son état est
STARTED.
Voici un exemple de sortie :
index shard prirep state docs store ip node
qosgeoname 4 r STARTED 2279054 623.8mb 10.6.xxx y3m8a_2
qosgeoname 4 p STARTED 2279054 628.8mb 10.6.xxx Xwhpjaf
qosgeoname 3 r RELOCATING 2279002 627.3mb 10.6.xxx 4Mh39az -> 10.6.xxx y3m8a_2tTdi_16TAy7B91w y3m8a_2
qosgeoname 3 p STARTED 2279002 626.4mb 10.6.xxx Xwhpjaf
qosgeoname 1 r STARTED 2278983 623.3mb 10.6.xxx I8SRFdj
qosgeoname 1 p STARTED 2278983 621.6mb 10.6.xxx Qn3qSgY
qosgeoname 2 p STARTED 2280694 623mb 10.6.xxx Qn3qSgY
qosgeoname 2 r STARTED 2280694 622.7mb 10.6.xxx 4Mh39az
qosgeoname 0 p STARTED 2278770 10.6.xxx I8SRFdj
qosgeoname 0 r STARTED 2278770 624.3mb 10.6.xxx y3m8a_2Étape 4 : Réactivez l’allocation des shards
Une fois la migration confirmée, réactivez l’allocation des shards :
PUT /_cluster/settings
{
"transient" : {
"cluster.routing.allocation.enable" : "all"
}
}Étapes suivantes
Charges déséquilibrées sur un cluster — optimisez l’allocation des shards pour éviter que le déséquilibre ne se reproduise.
Mettre à niveau la configuration du cluster — augmentez la capacité si la charge reste élevée après le rééquilibrage.