L'attaque des répliques de Solr

7 août 2019

Bruce Clayton

3 min de lecture

Un administrateur Solr peut commettre une erreur de configuration d'un seul caractère, sans avertissement, mais provoquant des échecs différés à mesure que le projet progresse. Ces problèmes ne sont pas facilement diagnostiqués à partir de leurs symptômes. L'un de ces points sensibles concerne les « répliques » Solr mal configurées. Cet article examine les causes les plus courantes des problèmes de réplication et leur résolution.

Une « réplique » Solr est une copie complète d'un index. C'est très simple : chaque collection Solr possède au moins une réplique.

La plupart des clients SearchStax développent et testent leurs projets sur des déploiements mono-serveur pour des raisons d'économie. Chaque serveur possède une copie de l'index (une réplique). Les systèmes de production, quant à eux, disposent généralement de deux ou trois serveurs et peuvent évoluer vers plusieurs serveurs. Chaque serveur possède sa propre réplique de l'index.

En fonctionnement normal, les répliques prennent en charge les comportements suivants :

Zookeeper surveille les répliques, en gardant les fichiers d'index synchronisés sur l'ensemble du cluster.
Un équilibreur de charge répartit les requêtes entrantes. Les serveurs peuvent tous répondre aux requêtes car ils disposent tous d'une copie de l'index. Le parallélisme réduit la latence des requêtes.
Lorsqu'un serveur est hors ligne (en raison d'une panne ou d'un « redémarrage progressif »), les serveurs restants gèrent la charge de requêtes sans interruption.

Malheureusement, il est facile de créer une collection Solr où il y a moins de répliques que de serveursPar exemple, il arrive que le paramètre replicationFactor soit incorrect lors de la création d'une collection. Nous avons souvent vu des systèmes à trois nœuds ne possédant qu'une seule réplique.

Cette situation crée les problèmes suivants :

Pendant une période de charge de requêtes élevée, la latence des requêtes peut en souffrir car un seul nœud effectue tout le travail.
Lors d'un redémarrage progressif, le système peut basculer vers un serveur ne disposant pas de copie de l'index, ce qui entraîne une interruption de service.
Manuel et programmé sauvegardes Chaque nœud doit posséder une réplique. Si certains nœuds ne possèdent pas de réplique, les sauvegardes peuvent échouer.
Si certains nœuds ne disposent pas d’une réplique, Pulse peut avoir des difficultés à surveiller cette collection.

Les réplicas peuvent également passer en « mode de récupération ». Les administrateurs Solr surchargent parfois leurs systèmes en demandant à Solr d'indexer trop d'enregistrements en un seul lot. La charge CPU atteint alors un maximum de 100% pendant de longues périodes. Cela provoque des interruptions de service, les réplicas passant les uns après les autres en mode de récupération sans raison apparente.

Zookeeper vérifie l'état de chaque réplique toutes les quelques minutes. Lorsque ce processus expire en raison d'une surcharge du processeur, Zookeeper suppose que le serveur de la réplique est en panne. Il place la réplique en mode de récupération pendant qu'il récupère toutes les modifications récentes pour la réparer. La réplique est indisponible pour le système jusqu'à la fin de ce processus.

La récupération des réplicas impose bien sûr une charge supplémentaire au processeur du nœud, ce qui interfère avec les tentatives de Zookeeper de surveiller les autres réplicas sur le même nœud. Dans un système multi-collection (comme un index Sitecore), les réplicas passent en récupération les uns après les autres. Des pannes en cascade peuvent entraîner l'arrêt de l'ensemble du cluster.

La solution immédiate consiste à arrêter Solr, puis à le redémarrer. Cela interrompt l'ingestion et permet à Zookeeper de rattraper son retard. Les réplicas reviennent rapidement en ligne. Pour éviter ce problème, ajustez la taille du lot d'ingestion afin de donner à Zookeeper un accès suffisant au processeur.

Meilleures pratiques:Pour chaque collection Solr, une réplique doit être présente sur chaque nœud du cluster.

L'attaque des répliques de Solr

Par Bruce Clayton

Recevez notre newsletter

Vous aimerez peut-être aussi :

Produits

Tarification

Ressources

Services

Ressources

Tarification

Entreprise