menu icon

Solr et Kubernetes - Essai de scalabilité horizontale automatisée

Tests de mise en place d'une scalabilité horizontale automatisée sur un cluster Solr 9 dans une environnement Kubernetes

Solr et Kubernetes - Essai de scalabilité horizontale automatisée

Introduction

Un cluster Solr est composé de plusieurs noeuds (ou nodes).

Grâce à la scalabilité horizontale proposée par Kubernetes, il est possible d’ajuster la taille du cluster Solr en fonction des ressources consommées.

Voici une mise en application de cette possibilité, basée sur cet article

Prérequis

Afin de faciliter les différentes installations, nous avons décidé d’utiliser Helm.

Installer Helm

La mise en place d’une scalabilité automatique se base sur des métriques.

Pour cela, l’installation de Metrics Server est donc très utile au cas où il n’y ai pas déjà de moyen d’accéder au métriques du cluster Kube.

Installer Metrics Server

La version de l’opérateur Solr utilisée est la 0.8.1

La version de SolrCloud utilisée pour ce test est la 9.6.1

Installation de Zookeeper

Grâce à Helm, l’installation de Zookeeper se fait en une commande simple qui va comporter tous les éléments importants.

helm install bitnami-zookeeper oci://registry-1.docker.io/bitnamicharts/zookeeper \
--set image.tag=3.8 \
--set fourlwCommandsWhitelist="mntr\,conf\,ruok" \
--set autopurge.purgeInterval=1 \
--set heapSize=512 \
--set replicaCount=3

A retenir :

image.tag nous indique quelle version de Zookeeper va être installée.

replicaCount donne le nombre de nodes Zookeeper qui seront mis en place. 3 étant le nombre idéal pour débuter avec de la Haute Disponibilité.

Installation de Solr

Installation des CRDs (Custom Resources Definitions)

La première chose à faire est d’installer les CRDs spécifiques à SolrCloud

kubectl create -f https://dlcdn.apache.org/solr/solr-operator/v0.8.1/crds/solrclouds.yaml

Installation de l’opérateur

Ensuite, l’opérateur Solr peut être installé sur notre cluster Kube

helm install solr-operator apache-solr/solr-operator --version 0.8.1 \
--set zookeeper-operator.install=false

Déploiement du cluster

helm install example-solr apache-solr/solr --version 0.8.1 \
--set image.tag=9.6.1 \
--set solrOptions.javaMemory="-Xms500m -Xmx500m" \
--set zk.address="bitnami-zookeeper-headless:2181" \
--set podOptions.resources.requests.cpu=200m \
--set addressability.external.method=Ingress \
--set addressability.external.domainName="ing.local.domain" \
--set addressability.external.useExternalAddress="true" \
--set ingressOptions.ingressClassName="nginx"

Deux choses importantes sont à noter :

  • Les lignes commençant par addressability et ingress ne sont à utiliser que dans le cas où un service Ingress est utilisé dans le cluster Kube. Dans ce cas, il faudra créer la configuration pour le nouveau service Solr.

  • Dans certains cas, le cluster peut agir de manière non logique. Cela peut provenir d’un manque de mémoire allouée. Par défaut, chaque pod se voit affecté 500 Mo de mémoire. Cela peut être modifié en ajoutant une ligne :

helm install example-solr apache-solr/solr --version 0.8.1 \
 --set image.tag=9.6.1 \
 --set solrOptions.javaMemory="-Xms500m -Xmx500m" \
 --set zk.address="bitnami-zookeeper-headless:2181" \
 --set podOptions.resources.requests.cpu=200m \
 --set podOptions.resources.requests.memory=1Gi \
 --set addressability.external.method=Ingress \
 --set addressability.external.domainName="ing.local.domain" \
 --set addressability.external.useExternalAddress="true" \
 --set ingressOptions.ingressClassName="nginx"

Situation initiale

Dans notre exemple, une collection addresses a été créée en spécifiant de manière explicite qu’elle devait avoir 5 shards et un replica.

Puis 10 000 documents ont été indexés.

La visualisation dans la UI Solr donne le résultat suivant :

Aperçu du cluster avec 3 nodes. Le node 0 contient un replica, les deux autres en contiennent deux chacun
Aperçu du cluster avec 3 nodes. Le node 0 contient un replica, les deux autres en contiennent deux chacun

Visualisation en arbre des shards. Les shards 1 et 3 sont sur le node 1. Le shard 2 est sur le node 0 et les shards 4 et 5 sont sur le node 2
Visualisation en arbre des shards. Les shards 1 et 3 sont sur le node 1. Le shard 2 est sur le node 0 et les shards 4 et 5 sont sur le node 2

Mise en place de l’autoscale

La mise en place de l’autoscale est simple à mettre en place : il faut lui spécifier la limite qui va déclencher un upscaling ainsi que le nombre minimum et maximum de pod que l’on peut avoir. Par exemple :

kubectl autoscale solrcloud example --cpu-percent=2 --min=3 --max=6

Ici, on spécifie donc que la limite est au dessus de 2% de consommation de CPU (la valeur est volontairement basse de manière à forcer un autoscaling sans avoir besoin de surcharger le cluster Solr).

Une fois la commande passée, on se retrouve très vite avec 6 pods, ce qu’il est facile de vérifier avec quelques commandes très simples.

benjamin@kube01:~$ kubectl get pods
NAME                             READY   STATUS    RESTARTS       AGE
bitnami-zookeeper-0              1/1     Running   3 (11m ago)    46h
bitnami-zookeeper-1              1/1     Running   3 (11m ago)    46h
bitnami-zookeeper-2              1/1     Running   3 (11m ago)    46h
example-solrcloud-0              1/1     Running   0              47s
example-solrcloud-1              1/1     Running   0              70s
example-solrcloud-2              1/1     Running   0              98s
example-solrcloud-3              1/1     Running   0              32s
example-solrcloud-4              1/1     Running   0              32s
example-solrcloud-5              1/1     Running   0              32s
solr-operator-575d5866f4-8wrrv   1/1     Running   11 (11m ago)   46h

Ainsi que la commande de vérification du scaling horizontal (HPA)

kubectl get hpa

Qui donne alors

NAME      REFERENCE           TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
example   SolrCloud/example   3%/2%     3         6         6          163m

Etat du cluster suite à l’autoscale

Suite à cette mise à jour, nous nous retrouvons avec un cluster composé de 6 nodes. Comment est-ce que la répartition des différents shards a-t-elle été gérée ?

Détail du cluster
Aperçu du cluster avec 6 nodes. Les node 0 à 4 contiennent un replica, le node 5 n'en contient pas

Détail du cluster
Visualisation en arbre des shards. Les shards 1 à 5 sont respectivement sur les node 3, 4, 0, 1 et 2.

Conclusion

Ce petit test permet de voir que dans le cas où un cluster Solr est géré dans Kubernetes via l’opérateur dédié et que le nombre de nodes augmente, la répartition des données se fait de manière automatique de manière à avoir les shards répartis sur un maximum de nodes.