Solr Cloud: Répartition des Shards entre les noeuds

Question

J'utilise actuellement Solr Cloud 6.1, le comportement suivant peut également être observé jusqu'à la version 7.0.

J'essaie de créer une collection Solr avec 5 fragments et un facteur de réplication de 2. J'ai 5 serveurs physiques. Normalement, cela répartirait uniformément les 10 réplicas parmi les serveurs disponibles. Mais, au démarrage de Solr Cloud avec un paramètre -h (nomhôte) pour donner à chaque instance Solr un nom d'hôte individuel, mais constant, cela ne fonctionne plus. La distribution ressemble alors à ceci:

solr-0: 
wikipedia_shard1_replica1 wikipedia_shard2_replica1 wikipedia_shard3_replica2 wikipedia_shard4_replica1 wikipedia_shard4_replica2 

solr-1: 

solr-2: 
wikipedia_shard3_replica1 wikipedia_shard5_replica1 wikipedia_shard5_replica2 

solr-3: 
wikipedia_shard1_replica2 

solr-4: 
wikipedia_shard2_replica2 

J'ai essayé d'utiliser Rule-based Replica Placement, mais les règles semblent être ignorées.

Je dois utiliser des noms d'hôtes, car Solr s'exécute dans un cluster Kubernetes, où les adresses IP changent fréquemment et Solr ne trouve pas ses cœurs après le redémarrage d'un conteneur. J'ai d'abord soupçonné une nouvelle version de Solr d'en être la cause, mais je l'ai réduit au problème du nom d'hôte.

Y at-il une solution pour cela?

Answer 1

La solution est en fait assez simple (mais pas vraiment documenté):

Lors de la création d'un Service dans OpenShift/Kubernetes, tous les pods correspondant sont sauvegardés par un équilibreur de charge. Lorsque toutes les instances Solr reçoivent un nom d'hôte unique, ces noms d'hôte se résoudront tous en une seule adresse IP (celle de l'équilibreur de charge).

Solr ne peut en aucun cas gérer cela et ne parvient pas à distribuer ses fragments uniformément.

La solution consiste à utiliser headless services de Kubernetes. Les services sans tête ne sont pas pris en charge par un équilibreur de charge et, par conséquent, chaque nom d'hôte est résolu en une adresse IP unique.