Après avoir détaillé dans l’article « Mise en oeuvre de SolrCloud (Solr 4.0)« , l’installation d’un cloud constitué de 4 noeud Solr, je présente maintenant quelques cas courants d’administration de SolrCloud, à savoir :
- charger des configurations
- créer des collections
- modifier la configuration d’une collection
- redimensionner un cluster (ajouter plus de noeuds dans SolrCloud)
- déplacer un noeud
- redimensionner une collection (ajouter des replicas)
- redimensionner une collection (ajouter des shards)
Pour tous ces exemples et les manipulations décrites, nous travaillons sur le serveur qui héberge notre cluster SolrCloud installé à l’occasion de l’écriture de l’article précédent.
Charger des configurations
Afin de pouvoir créer des collections dans SolrCloud, il faut au préalable y avoir chargé des configurations. Une configuration est en fait un ensemble de fichiers qui correspond au répertoire conf d’un core. A cet ensemble de fichiers, on associe un nom de configuration.
Pour cela, on utilise un outil de SolrCould “ZkCli”. Supposons que l’on veuille charger la configuration de la collection1 fournie en exemple avec Solr et lui associer le nom “config1”. Il faut commencer par choisir un noeud du cloud pour réaliser les opérations. Nous choisissons le noeud 1. Les étapes sont :
Préparer l’environnement de travail
Le noeud 1 fonctionne déjà en mode http avec Tomcat, mais pour la gestion des configurations, nous avons besoin de lancer des opérations en ligne de commande et pour cela nous avons donc besoin de regrouper les librairies Solr dans un répertoire. Nous utiliserons « /opt/node1/solr/lib ».
mkdir /tmp/solr cd /tmp/solr unzip /opt/downloads/solr-4.3.0/dist/solr-4.3.0.war cp /tmp/solr/WEB-INF/lib/* /opt/node1/solr/lib/. cp /opt/downloads/solr-4.3.0/example/lib/ext/* /opt/node1/solr/lib/.
Charger la configuration avec la commande suivante
java -classpath .:/opt/node1/solr/lib/* org.apache.solr.cloud.ZkCLI -cmd upconfig -zkhost localhost:2181 -confdir /opt/downloads/solr-4.3.0/example/solr/collection1/conf -confname config1
Vérifier dans Zookeeper
./bin/zkCli.sh -server localhost:2181
ls /configs/config1 doit retourner des valeurs
Les options de l’outil Zookeeper de Solr (ZkCLI)
-c,--collection for linkconfig: name of the collection-cmd cmd to run: bootstrap, upconfig, downconfig, linkconfig, makepath, clear -d,--confdir for upconfig: a directory of configuration files -h,--help bring up this help page -n,--confname for upconfig, linkconfig: name of the config set -r,--runzk run zk internally by passing the solr run port - only for clusters on one machine (tests, dev) -s,--solrhome for bootstrap, runzk: solrhome location -z,--zkhost ZooKeeper host address
Créer des collections
Une fois des configurations chargées dans Zookeeper, il est possible d’utiliser la Collections API pour créer des collections dans le cloud. Voici comment créer une collection “collectionOne” avec la configuration “config1”. Cette collection est constituée de 2 shards et 2 replicas :
curl 'http://localhost:8180/solr/admin/collections?action=CREATE&name=collectionOne&numShards=2&replicationFactor=2&maxShardsPerNode=2&collection.configName=config1'
Mettre à jour la configuration d’une collection
La mise à jour des fichiers de configuration consiste en la mise à jour de la configuration dans Zookeper avec la même commande que le chargement initial de la configuration.
java -classpath .:/opt/node1/solr/lib/* org.apache.solr.cloud.ZkCLI -cmd upconfig -zkhost localhost:2181 -confdir /opt/downloads/solr-4.3.0/example/solr/collection1/conf -confname config1
Puis, il faut « reloader » la collection.
curl 'http://localhost:8180/solr/admin/collections?action=RELOAD&name=collectionOne
Description de la collection API
| action | The CoreAdmin operation to be performed across all cores of a collection. It can currently support: CREATE RELOAD DELETE |
| name | this is the name of the core. You are free to choose the name of the core (here mycollection_shard1_1), we suggest to include something that refers to the name of the collection and the shard. |
| collection | the name of the collection. Note that we didn’t use the collection name ‘mycollection’ before: a collection owes its existence to the cores that are associated with it. |
| shard | the name of the shard. You can choose this freely, e.g.use shard1, shard2, etc. |
| collection.configName | what configuration (as uploaded above) should be used for the collection. You only need to specify this parameter once, when creating the first core for a collection, when create the other cores you can leave it out. |
| numShards | The number of shards to be created as part of the collection (used when creating a collection). |
| replicationFactor | The number of replicas to be created for each shard. In Solr 4.1, it means the total number of replicas; in Solr 4.0, it referred to the number of additional copies. |
| maxShardsPerNode | When creating collections, the shards and/or replicas are spread across all available (i.e., live) nodes, and two replicas of the same shard will never be on the same node. If a node is not live when the CREATE operation is called, it will not get any parts of the new collection, which could lead to too many replicas being created on a single (live) node. Defining themaxShardsPerNode sets a limit on the number of replicas CREATE will spread to each node. The default is 1. If the entire collection can not be fit into the live nodes, no collection will be created at all. |
| createNodeSet | Allows defining the nodes to spread the new collection across. If not provided, the CREATE operation will create shard-replica spread across all of your live Solr nodes. The format is a comma-separated list of node_names, such as localhost:8983_solr,localhost:8984_solr,localhost:8985_solr |
Redimensionner un cluster (ajouter plus de noeuds dans SolrCloud)
Si la volumétrie des données à indexer ou le nombre de requêtes augmente, il peut être nécéssaire d’augmenter le nombre de shards et/ou le nombre de réplicas de certaines collections. Cela peut nécéssiter d’augmenter le nombre de noeuds dans le cluster SolrCloud.
Cette opération est très simple car il suffit de répliquer le configuration d’un noeud existant et de le démarrer (on ne réplique pas les données et donc le fichier solr.xml ne doit déclarer aucun core). Ce dernier va automatiquement entrer en contact avec l’ensemble zookeeper pour se faire connaitre et se mettre à la disposition du cluster.
Je rappelle que si vous simulez ceci sur un serveur physique hébergeant plusieurs noeuds, et que vous dupliquez les configurations d’un noeud existant, il faut bien vérifier les numéros de port et le chemin vers le répertoire home de Solr dans les fichiers suivants :
Pour Tomcat, il faut vérifier :
- /opt/nodeN/tomcat/conf/server.xml (numéro de port)
- /opt/nodeN/tomcat/bin/setenv.sh (numéro de port)
Pour Solr, il faut vérifier :
- /opt/nodeN/solr/home/solr.xml (numéro de port)
- /opt/nodeN/tomcat/bin/setenv.sh (chemin vers le répertoire home de Solr)
Déplacer un noeud
Les opérations sont :
- Stopper le noeud
- Déplacer le noeud (nouveau host et/ou nouveau port)
- Modifier les fichiers de configurations suivants :
Pour Tomcat, il faut vérifier :
- /opt/nodeN/tomcat/conf/server.xml (numéro de port)
- /opt/nodeN/tomcat/bin/setenv.sh (numéro de port)
Pour Solr, il faut vérifier :
- /opt/nodeN/solr/home/solr.xml (numéro de port)
- /opt/nodeN/tomcat/bin/setenv.sh (chemin vers le répertoire home de Solr)
- Démarrer le noeud
Note : le noeud déplacé est toujours visible dans l’administration SolrCloud avec son ancienne adresse mais il est indiqué avec un statut “gone”.
Que se passe-t-il pour les collections hébergées sur le noeud déplacé durant l’opération ?
- Pour une collection avec 1 shard sans replica : la collection devient totalement indisponible le temps du déplacement
- Pour une collection avec N shards sans replica : la collection est toujours disponible pour l’indexation (dans le shard disponible) et pour la recherche mais sans les données du shard indisponible.
- Pour une collection avec 1 shard et 1 replica : La collection est totalement disponible pour l’indexation et la recherche mais avec une diminution des performances.
- Pour une collection avec 1 shard et N replicas : La collection est totalement disponible pour l’indexation et la recherche
Redimensionner une collection (ajouter des replicas)
Le but est de faire face à un accroissement des requêtes sur la collection.
Apres avoir éventuellement ajouté un ou plusieurs noeuds dans le cluster Solrcloud, il faut maintenant ajouter 1 replica à chaque shard de la collection.
Imaginons une collection “collectionThree” constituée de 2 shards chacun répliqués une fois. Nous avons donc une collection répartie sur 4 noeuds.
- collectionThree_shard1_replica1 (sur localhost:8480 ou noeud 4)
- collectionThree_shard2_replica1 (sur localhost:8380 ou noeud 3)
- collectionThree_shard1_replica2 (sur localhost:8180 ou noeud 1)
- collectionThree_shard2_replica2 (sur localhost:8780 ou noeud 7)
La stratégie de nommage des cores sur les noeuds est « <nom_collection>_shardX_replicaY ». Nous devons donc créer 2 cores :
- collectionThree_shard1_replica3
- collectionThree_shard2_replica3
Lors de la création initiale de la collection, nous avons utilisé la Collections API qui s’est chargée de dispatcher automatiquement les cores au travers des noeuds. Pour l’ajout d’un core dans une collection, nous devons décider nous même du noeud cible et utiliser non plus la Collections API, mais la Cores API.
Nous allons créer le core collectionThree_shard1_replica3 sur le noeud 6 et le core collectionThree_shard2_replica3 sur le noeud 5 :
curl 'http://localhost:8680/solr/admin/cores?action=CREATE&name=collectionThree_shard1_replica3&collection=collectionThree&shard=shard1&collection.configName=config1'
curl 'http://localhost:8580/solr/admin/cores?action=CREATE&name=collectionThree_shard2_replica3&collection=collectionThree&shard=shard2&collection.configName=config1'
Redimensionner une collection (ajouter des shards)
Avant Solr 4.3.0, cela n’était pas possible. Les solutions de contournement étaient :
“oversharding”, c’est à dire créer plus de shards que nécessaire pour anticiper un futur besoin. Au besoin, on héberge plusieurs noeuds du cluster SolrCloud sur le même serveur et on les déplace plus tard lors que de nouveaux serveurs physiques sont ajoutés.
créer une nouvelle collection avec plus de shards et tout réindexer
A partir de Solr 4.3.0, il est possible de découper un shard existant en 2 shards équilibrés
[à compléter]