Tests de mise en place d'une scalabilité horizontale automatisée sur un cluster Solr 9 dans une environnement Kubernetes
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
Afin de faciliter les différentes installations, nous avons décidé d’utiliser 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.
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
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é.
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
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
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"
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 :
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
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 ?
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.