Installation et déploiement
Il y a deux approches pour l'installation de Solr, une installation ou par déploiement. Voici les informations requises pour l'installation d'une version 9 de Solr.
Configuration requise
Vous pouvez installer Solr sur n'importe quel système où un environnement d'exécution Java (JRE) approprié est disponible.
Systèmes d'exploitation pris en charge
Solr est testé sur plusieurs versions de Linux, macOS et Windows.
Configuration requise pour Java
Vous aurez besoin de la version 11 ou supérieure de Java Runtime Environment (JRE). Sur une ligne de commande, vérifiez votre version de Java comme suit :
| java -version |
on obtiendra un résultat ressemblant à ceci :
|
openjdk version "11.0.14.1" 2022-02-08 OpenJDK Runtime Environment Temurin-11.0.14.1+1 (build 11.0.14.1+1) OpenJDK 64-Bit Server VM Temurin-11.0.14.1+1 (build 11.0.14.1+1, mixed mode) |
Le résultat exact peut varier, mais vous devez vous assurer que vous respectez la version minimale requise. Il est recommandé également de choisir une version n'étant pas en fin de vie auprès de son fournisseur. Il est également préférable d'utiliser la dernière version officielle disponible.
Certaines versions de Java VM présentent des bogues pouvant avoir un impact sur votre implémentation.
Sources pour Java
Le Java est disponible auprès de plusieurs fournisseurs. L'image officielle de Docker pour Solr utilise la distribution Temurin d'OpenJDK 17 du projet Adoptium. Solr effectue régulièrement des tests avec les versions Temurin, OpenJDK et Oracle de Java. Certaines distributions sont gratuites, d'autres sont payantes, certaines fournissent des correctifs de sécurité et une assistance, d'autres non. Il est recommandé de lire l'article Java is still free de Java Champions pour vous aider à décider.
Le projet Solr ne soutient aucun fournisseur particulier de Java. Bien qu'on références l'ensemble de développement Java (JDK) sur cette page, tout environnement d'exécution Java (JRE) associé aux JDK référencés est acceptable.
Combinaisons Java et Solr
La version Java minimale pour Solr 9.x est Java 11. Cela s'applique à la fois au serveur Solr et aux bibliothèques clientes SolrJ. La version Java recommandée est JRE 17.
Voici quelques conseils lors de l'exécution de Solr avec une version Java plus récente que la version minimale spécifiée :
- Les distributions Java OpenJDK et Oracle sont testées de manière approfondie et continueront d'être testées à l'avenir.
- Les distributions Java provenant d'autres sources ne sont pas régulièrement testées par notre infrastructure de test, vous devez donc tester Java à partir de ces sources dans votre environnement.
- Pour les besoins de Solr, Java et OpenJDK d'Oracle sont identiques.
- La mise à niveau de Java n'est pas requise, sachant qu'aucun bogue Java ne sera résolu à moins que vous n'utilisiez une version de Java fournissant LTS.
- Java 11 a été largement testé par des tests automatisés et des utilisateurs via Solr 9. Le support à long terme (LTS) pour Java est fourni à partir de plusieurs sources.
- L'infrastructure de test du projet teste en permanence les versions minimales et supérieures de Java pour chaque branche de développement.
- Java 12, 13, 14, 15 et 16 n'ont pas de LTS. Pour cette raison, Java 17 est préférable lors de la mise à niveau de Java.
Tests de projet des combinaisons Java-Solr
Solr et Lucene exécutent un modèle d'intégration continue, exécutant des tests unitaires et d'intégration automatisés à l'aide de plusieurs versions de Java. De plus, certaines organisations maintiennent également leur propre infrastructure de test et transmettent leurs résultats à la communauté.
Les tests continus portent sur les deux lignes de code en cours de développement actif, Solr 9x et le futur Solr 10.0 :
- Solr 9.x est la ligne de version stable actuelle et comportera des «versions ponctuelles», c'est-à-dire 9.1, 9.2,..., jusqu'à la sortie de Solr 10.0.
- Solr 9.x est testé en continu par rapport à Java 11, 17, 21 et également à des versions plus récentes.
Il existe également des développements et des tests avec la future ligne de version Solr 10.x.
Solr 8.x et les versions antérieures ne sont plus testées en continu.
Installation de Solr
L'installation de Solr sur des serveurs compatibles Unix ou Windows nécessite généralement une simple extraction (ou décompression) du paquet de téléchargement.
Paquets Solr disponibles
Solr est disponible sur le site Web de Solr. Téléchargez la dernière version https://solr.apache.org/downloads.html.
Pour la version 9, il existe trois paquets distincts :
| Paquet | Description |
|---|---|
| solr-9.6.1.tgz | Le paquet binaire complet, pour tous les systèmes d'exploitation. Ce paquet comprend tous les modules et accessoires Solr propriétaires (par exemple, prometheus-exporter). |
| solr-9.6.1-slim.tgz | Le paquet binaire slim, pour tous les systèmes d'exploitation. Ce paquet comprend uniquement ce qui est nécessaire pour exécuter Solr. Les modules et accessoires (par exemple, prometheus-exporter) ne sont pas inclus. |
| solr-9.6.1-src.tgz | Le code source du paquet Solr. Ceci est utile si vous souhaitez développer sur Solr sans utiliser le dépôt Git officiel. |
Deux images Docker sont fournies utilisant les binaires complet et slim.
Préparation de l'installation
Lorsque vous commencez à utiliser Solr, il vous suffit d'extraire l'archive de distribution Solr dans un répertoire de votre choix. Cela suffira comme environnement de développement initial, mais veillez à ne pas surcharger cette installation «jouet» avant de configurer vos véritables environnements de développement et de production.
Une fois que vous aurez dépassé l'évaluation initiale de Solr, vous devrez prendre soin de planifier votre implémentation. Vous devrez peut-être réinstaller Solr sur un autre serveur ou créer un environnement SolrCloud en unité d'allocation.
Lorsque vous êtes prêt à configurer Solr pour un environnement de production, veuillez vous référer aux instructions fournies sur la page Passer de Solr à la production.
Il est important de noter que Lucene impose une limite stricte au nombre de documents contenus dans un seul index : environ 2,14 milliards de documents (2 147 483 647 pour être exact). En pratique, il est très peu probable qu'un nombre aussi important de documents puisse tenir dans un seul index et fonctionner correctement. Vous devrez probablement distribuer votre index sur un unité d'allocation avant d'atteindre ce nombre. Si vous savez que vous dépasserez ce nombre total de documents avant même de commencer l'indexation, il est préférable de planifier votre installation avec SolrCloud dans le cadre de votre conception dès le début.
Installation du paquet
Pour simplifier les choses pour l'instant, extrayez l'archive de distribution Solr dans votre répertoire personnel local :
|
cd ~/ tar zxf solr-9.6.1.tgz |
Note : Windows inclut l'outil tar depuis Windows 10. Ouvrez une fenêtre de ligne de commande et exécutez la commande ci-dessus. Il existe également plusieurs outils de désarchivage tiers prenant en charge les archives .tar.
Disposition des répertoires
Après avoir installé Solr, vous verrez les répertoires et fichiers suivants :
| Répertoire | Description | |
|---|---|---|
| bin/ | Ce répertoire comprend plusieurs scripts importants qui faciliteront l'utilisation de Solr : | |
| Script | Description | |
| solr et solr.cmd | Il s'agit du script de contrôle de Solr, également connu sous le nom de bin/solr (*nix) / bin/solr.cmd (Windows). Ce script est l'outil privilégié pour démarrer et arrêter Solr. Vous pouvez également créer des collections ou des coeurs, configurer l'authentification et travailler avec des fichiers de configuration lors de l'exécution en mode SolrCloud. | |
| post | L'outil de publication, fournissant une interface de ligne de commande simple pour publier du contenu sur Solr. | |
| solr.in.sh et solr.in.cmd | Il s'agit des fichiers de propriétés pour les systèmes *nix et Windows, respectivement. Les propriétés au niveau du système pour Java, Jetty et Solr sont configurées ici. La plupart de ces paramètres peuvent être remplacés lors de l'utilisation de bin/solr / bin/solr.cmd, mais cela vous permet de définir toutes les propriétés en un seul endroit. | |
| install_solr_services.sh | Ce script est utilisé sur les systèmes *nix pour installer Solr en tant que service. Il est décrit plus en détail dans la section Mise en production de Solr. | |
| modules/ | Le répertoire des modules de Solr comprend des modules complémentaires propriétaires pour des fonctionnalités spécialisées améliorant Solr. Ce module n'est pas inclus dans la distribution Slim. | |
| prometheus-exporter/ | Une application autonome, incluse sous bin/, surveillant les instances Solr et produit des métriques Prometheus. Ceci n'est pas inclus dans la distribution slim. | |
| docker/ | Ce répertoire contient un fichier Docker pour créer une image Docker à partir de la distribution binaire, compatible avec l'image officielle. Ce répertoire contient également les scripts nécessaires à l'utilisation de Solr dans l'image Docker, sous le répertoire scripts/. Le fichier README.md de ce répertoire décrit comment créer des images Docker pour Solr personnalisées à l'aide de cette distribution binaire. | |
| lib/ | Dossier dans lequel Solr recherchera des fichiers jar de plugiciels supplémentaires. | |
| dist/ | Le répertoire dist contient les principaux fichiers .jar de Solr. | |
| docs/ | Le répertoire docs inclut un lien vers les Javadocs en ligne pour Solr. | |
| example/ | Le répertoire d'exemples comprend plusieurs types d'exemples illustrant diverses fonctionnalités de Solr. | |
| licenses/ | Le répertoire des licences inclut toutes les licences des bibliothèques tierces utilisées par cette distribution de Solr. | |
| server/ | Ce répertoire est l'endroit où réside le coeur de l'application Solr. Un fichier README dans ce répertoire fournit un aperçu détaillé,
mais voici quelques points saillants :
|
|
Démarrage de Solr
Solr inclut un outil d'interface de ligne de commande appelé bin/solr (Linux/MacOS) ou bin\solr.cmd (Windows). Cet outil vous permet de démarrer et d'arrêter Solr, de créer des cours et des collections, de configurer l'authentification et de vérifier l'état de votre système.
Pour l'utiliser pour démarrer Solr, vous pouvez simplement saisir :
| bin/solr start |
Si vous utilisez Windows, vous pouvez démarrer Solr en exécutant bin\solr.cmd à la place.
| bin\solr.cmd start |
Cela démarrera Solr en arrière-plan, en écoutant sur le port 8983.
Lorsque vous démarrez Solr en arrière-plan, le script attendra de s'assurer que Solr démarre correctement avant de revenir au prompt de ligne de commande.
Démarrer Solr avec un exemple groupé spécifique
Solr fournit également un certain nombre d'exemples utiles pour vous aider à découvrir les fonctionnalités clefs. Vous pouvez lancer les exemples à l'aide de l'indicateur -e. Par exemple, pour lancer l'exemple «techproducts», vous devez exécuter :
| bin/solr start -e techproducts |
Actuellement, les exemples disponibles que vous pouvez exécuter sont : techproducts, schemaless et cloud.
Vérifiez si Solr est en cours d'exécution
Si vous n'êtes pas sûr que Solr est en cours d'exécution localement, vous pouvez utiliser la commande status :
| bin/solr status |
Cette fonction recherchera les instances Solr en cours d'exécution sur votre ordinateur, puis rassemblera des informations de base à leur sujet, telles que la version et l'utilisation de la mémoire.
Solr est en cours d'exécution. Si vous avez besoin d'être convaincu, utilisez un navigateur Web pour voir la console d'administration avec un URL comme ceci :
| http://localhost:8983/solr/ |
Si Solr n'est pas en cours d'exécution, votre navigateur se plaindra de ne pas pouvoir se connecter au serveur. Vérifiez votre numéro de port et réessayez.
Créer un noyau
Si vous n'avez pas démarré Solr avec un exemple de configuration, vous devez créer un noyau pour pouvoir indexer et rechercher. Vous pouvez le faire en exécutant :
| bin/solr create -c name |
Cela créera un noyau qui utilise un schéma piloté par les données qui essaie de deviner le type de champ correct lorsque vous ajoutez des documents à l'index.
Pour voir toutes les options disponibles pour créer un nouveau noyau, exécutez :
| bin/solr create -help |
Mise en production de Solr
Cette section fournit des conseils sur la façon de configurer Solr pour qu'il s'exécute en production sur des plateformes *nix, telles qu'Ubuntu. Plus précisément, nous allons parcourir le processus de configuration pour exécuter une seule instance Solr sur un hôte Linux, puis fournir des conseils sur la façon de prendre en charge plusieurs noeuds Solr exécutés sur le même hôte.
Script d'installation de service
Solr inclut un script d'installation de service (bin/install_solr_service.sh) pour vous aider à installer Solr en tant que service sur Linux. Actuellement, le script ne prend en charge que les distributions Linux : CentOS, Debian, Red Hat, SUSE et Ubuntu. Avant d'exécuter le script, vous devez déterminer quelques paramètres concernant votre configuration. Plus précisément, vous devez décider où installer Solr et quel utilisateur système doit être le propriétaire des fichiers et du processus Solr.
Planification de la structure de votre répertoire
Nous vous recommandons de séparer vos fichiers Solr actifs, tels que les fichiers journaux et les fichiers d'index, des fichiers inclus dans le bundle de distribution Solr, car cela facilite la mise à niveau de Solr et est considéré comme une bonne pratique à suivre en tant qu'administrateur système.
Répertoire d'installation de Solr
Par défaut, le script d'installation du service extrait l'archive de distribution dans /opt. Vous pouvez modifier cet emplacement à l'aide de l'option -i lors de l'exécution du script d'installation. Le script crée également un lien symbolique vers le répertoire versionné de Solr. Par exemple, si vous exécutez le script d'installation pour Solr 9.6.1, la structure de répertoire suivante sera utilisée :
|
/opt/solr-9.6.1 /opt/solr -> /opt/solr-9.6.1 |
L'utilisation d'un lien symbolique permet d'isoler les scripts de la dépendance à la version spécifique de Solr. Si, plus tard, vous devez effectuer une mise à niveau vers une version ultérieure de Solr, vous pouvez simplement mettre à jour le lien symbolique pour pointer vers la version mise à niveau de Solr. On utilise /opt/solr pour faire référence au répertoire d'installation de Solr dans les sections restantes de cette page.
Répertoire séparé pour les fichiers inscriptibles
Vous devez également séparer les fichiers Solr inscriptibles dans un répertoire différent ; par défaut, le script d'installation utilise /var/solr, mais vous pouvez remplacer cet emplacement à l'aide de l'option -d. Avec cette approche, les fichiers dans /opt/solr resteront intacts et tous les fichiers qui changent pendant l'exécution de Solr résideront sous /var/solr.
Créer l'utilisateur Solr
L'exécution de Solr en tant que root n'est pas recommandée pour des raisons de sécurité, et la commande bin/solr start refusera de le faire. Par conséquent, vous devez déterminer le nom d'utilisateur d'un utilisateur système qui possédera tous les fichiers Solr et le processus Solr en cours d'exécution. Par défaut, le script d'installation crée l'utilisateur Solr, mais vous pouvez remplacer ce paramètre à l'aide de l'option -u. Si votre organisation a des exigences spécifiques pour la création de nouveaux comptes d'utilisateur, vous devez créer l'utilisateur avant d'exécuter le script. Le script d'installation fera de l'utilisateur Solr le propriétaire des répertoires /opt/solr et /var/solr.
Vous êtes maintenant prêt à exécuter le script d'installation.
Exécutez le script d'installation Solr
Pour exécuter le script, vous devez télécharger la dernière archive de distribution Solr, puis procéder comme suit :
| tar xzf solr-9.6.1.tgz solr-9.6.1/bin/install_solr_service.sh --strip-components=2 |
La commande précédente extrait le script install_solr_service.sh de l'archive dans le répertoire actuel. Si vous effectuez l'installation sur Red Hat, assurez-vous que lsof est installé avant d'exécuter le script d'installation de Solr (sudo yum install lsof). Le script d'installation doit être exécuté en tant que root :
| sudo bash ./install_solr_service.sh solr-9.6.1.tgz |
Par défaut, le script extrait l'archive de distribution dans /opt, configure Solr pour écrire les fichiers dans /var/solr et exécute Solr en tant qu'utilisateur solr. Par conséquent, la commande suivante produit le même résultat que la commande précédente :
| sudo bash ./install_solr_service.sh solr-9.6.1.tgz -i /opt -d /var/solr -u solr -s solr -p 8983 |
Vous pouvez personnaliser le nom du service, les répertoires d'installation, le port et le propriétaire à l'aide des options transmises au script d'installation. Pour voir les options disponibles, procédez simplement comme suit :
| sudo bash ./install_solr_service.sh -help |
Une fois le script terminé, Solr sera installé en tant que service et s'exécutera en arrière-plan sur votre serveur (sur le port 8983). Pour vérifier, vous pouvez faire :
| sudo service solr status |
Si vous ne souhaitez pas démarrer le service immédiatement, passez l'option -n. Vous pouvez ensuite démarrer le service manuellement plus tard, par exemple après avoir terminé la configuration.
Nous aborderons dans un instant certains paramètres de configuration supplémentaires que vous pouvez effectuer pour affiner votre configuration Solr. Avant de continuer, examinons de plus près les étapes effectuées par le script d'installation. Cela vous donne une meilleure vue d'ensemble et vous aidera à comprendre les détails importants de votre installation Solr lorsque vous lirez d'autres pages de ce guide ; par exemple, lorsqu'une page fait référence à la page d'accueil de Solr, vous saurez exactement où elle se trouve sur votre système.
Répertoire de base de Solr
Le répertoire de base de Solr (à ne pas confondre avec le répertoire d'installation de Solr) est l'endroit où Solr gère les répertoires principaux avec les fichiers d'index. Par défaut, le script d'installation utilise /var/solr/data. Si l'option -d est utilisée dans le script d'installation, le sous-répertoire de données se trouve à l'emplacement indiqué dans l'option -d. Prenez un moment pour inspecter le contenu du répertoire de base de Solr sur votre système. Si vous n'entreposez pas solr.xml dans ZooKeeper, le répertoire de base doit contenir un fichier solr.xml. Lorsque Solr démarre, le script de contrôle Solr transmet l'emplacement du répertoire de base à l'aide de la propriété système -Dsolr.solr.home=....
L'environnement remplace le fichier d'inclusion
Le script d'installation du service crée un fichier d'inclusion spécifique à l'environnement remplaçant les valeurs par défaut utilisées par le script bin/solr. Le principal avantage de l'utilisation d'un fichier d'inclusion est qu'il fournit un emplacement unique où toutes vos substitutions spécifiques à l'environnement sont définies. Prenez un moment pour inspecter le contenu du fichier /etc/default/solr.in.sh, étant le chemin par défaut configuré par le script d'installation. Si vous avez utilisé l'option -s dans le script d'installation pour modifier le nom du service, la première partie du nom de fichier sera différente. Pour un service nommé solr-demo, le fichier sera nommé /etc/default/solr-demo.in.sh. Il existe de nombreux paramètres que vous pouvez remplacer à l'aide de ce fichier. Cependant, au minimum, ce script doit définir les variables SOLR_PID_DIR et SOLR_HOME, telles que :
|
SOLR_PID_DIR=/var/solr SOLR_HOME=/var/solr/data |
La variable SOLR_PID_DIR définit le répertoire dans lequel le script de contrôle écrira un fichier contenant l'identificateur de processus du serveur Solr.
Paramètres de journalisation
Solr utilise Apache Log4j pour la journalisation. Le script d'installation copie /opt/solr/server/resources/log4j2.xml dans /var/solr/log4j2.xml. Prenez un moment pour vérifier que le fichier d'inclusion Solr est configuré pour envoyer les journaux au bon emplacement en vérifiant les paramètres suivants dans /etc/default/solr.in.sh :
|
LOG4J_PROPS=/var/solr/log4j2.xml SOLR_LOGS_DIR=/var/solr/logs |
Script init.d
Lors de l'exécution d'un service comme Solr sous Linux, il est courant de configurer un script init.d afin que les administrateurs système puissent contrôler Solr à l'aide de l'outil de service, par exemple : service solr start. Le script d'installation crée un script init.d très basique pour vous aider à démarrer. Prenez un moment pour inspecter le fichier /etc/init.d/solr, étant le nom de script par défaut configuré par le script d'installation. Si vous avez utilisé l'option -s sur le script d'installation pour modifier le nom du service, le nom de fichier sera différent. Notez que les variables suivantes sont configurées pour votre environnement en fonction des paramètres transmis au script d'installation :
|
SOLR_INSTALL_DIR=/opt/solr SOLR_ENV=/etc/default/solr.in.sh RUNAS=solr |
Les variables SOLR_INSTALL_DIR et SOLR_ENV devraient être explicites. La variable RUNAS définit le propriétaire du processus Solr, tel que solr ; si vous ne définissez pas cette valeur, le script exécutera Solr en tant que root, ce qui n'est pas recommandé pour la production. Vous pouvez utiliser le script /etc/init.d/solr pour démarrer Solr en procédant comme suit en tant que root :
| service solr start |
Le script /etc/init.d/solr prend également en charge les commandes stop, restart et status. Gardez à l'esprit que le script init fourni avec Solr est très simple et est destiné à vous montrer comment configurer Solr en tant que service. Cependant, il est également courant d'utiliser des outils plus avancés comme supervisord ou upstart pour contrôler Solr en tant que service sous Linux. De plus, le script d'installation configure le service Solr pour qu'il démarre automatiquement lorsque la machine hôte s'initialise.
Vérification de la progression
Dans la section suivante, nous aborderons certains paramètres d'environnement supplémentaires pour vous aider à affiner votre configuration de production. Cependant, avant de continuer, passons en revue ce que nous avons accompli jusqu'à présent. Plus précisément, vous devriez pouvoir contrôler Solr à l'aide de /etc/init.d/solr. Veuillez vérifier que les commandes suivantes fonctionnent avec votre configuration :
|
sudo service solr restart sudo service solr status |
La commande status doit fournir des informations de base sur le noeud Solr en cours d'exécution ressemblant à :
|
Solr process PID running on port 8983 { "version":"5.0.0 - ubuntu - 2014-12-17 19:36:58", "startTime":"2014-12-19T19:25:46.853Z", "uptime":"0 days, 0 hours, 0 minutes, 8 seconds", "memory":"85.4 MB (%17.4) of 490.7 MB"} |
Si la commande status échoue, recherchez les messages d'erreur dans /var/solr/logs/solr.log.
Affinez votre configuration de production
Valeurs par défaut dynamiques pour ConcurrentMergeScheduler
Le planificateur de fusion est configuré dans solrconfig.xml et sa valeur par défaut est ConcurrentMergeScheduler. Ce planificateur utilise plusieurs processus léger pour fusionner les segments Lucene en arrière-plan.
Par défaut, ConcurrentMergeScheduler détecte automatiquement les valeurs par défaut de maxThreadCount et maxMergeCount en conséquence. maxThreadCount est défini sur 4 ou la moitié du nombre de processeurs disponibles pour la JVM, selon la valeur la plus élevée, et maxMergeCount est défini sur maxThreadCount+5.
Si vous disposez d'un disque rotatif, il est préférable de définir explicitement les valeurs de maxThreadCount et maxMergeCount dans la section IndexConfig de SolrConfig.xml afin que les valeurs appropriées à votre matériel soient utilisées.
Paramètres de mémoire et de GC
Par défaut, le script bin/solr définit la taille maximale de la mémoire de tas Java à 512 Mo (-Xmx512m), ce qui est parfait pour démarrer avec Solr. Pour la production, vous souhaiterez augmenter la taille maximale du tas en fonction des besoins en mémoire de votre application de recherche ; les valeurs comprises entre 8 et 16 Go ne sont pas rares pour les serveurs de production. Lorsque vous devez modifier les paramètres de mémoire de votre serveur Solr, utilisez la variable SOLR_HEAP dans le fichier d'inclusion, par exemple :
| SOLR_HEAP="8g" |
N'allouez pas la mémoire de tas Java très volumineux à moins que vous ne sachiez en avoir besoin.
En outre, le script de contrôle Solr est fourni avec un ensemble de paramètres de récupération de place Garbage First préconfigurés s'étant avérés efficaces avec Solr pour un certain nombre de charges de travail différentes. Cependant, ces paramètres peuvent ne pas fonctionner correctement pour votre utilisation spécifique de Solr. Par conséquent, vous devrez peut-être modifier les paramètres de récupération de place, ce qui doit également être fait avec la variable GC_TUNE dans le fichier d'inclusion /etc/default/solr.in.sh.
Vous pouvez également vous référer aux paramètres JVM pour ajuster vos paramètres de mémoire et de récupération de place.
Gestion de la mémoire insuffisante
Le script bin/solr utilise l'option -XX:+CrashOnOutOfMemoryError du JVM pour faire planter Solr en cas d'exceptions OutOfMemoryError. Ce comportement est recommandé. En mode SolrCloud, ZooKeeper sera immédiatement averti qu'un noeud a rencontré une erreur irrécupérable.
Passer en production avec SolrCloud
Pour exécuter Solr en mode SolrCloud, vous devez définir la variable ZK_HOST dans le fichier d'inclusion pour qu'elle pointe vers votre ensemble ZooKeeper. L'exécution de ZooKeeper intégré n'est pas prise en charge dans les environnements de production. Par exemple, si vous avez un ensemble ZooKeeper hébergé sur les trois hôtes suivants sur le port client par défaut 2181 (zk1, zk2 et zk3), vous devez définir :
| ZK_HOST=zk1,zk2,zk3 |
Lorsque la variable ZK_HOST est définie, Solr se lance en mode «cloud».
Chroot ZooKeeper
Si vous utilisez une instance ZooKeeper partagée par d'autres systèmes, il est recommandé d'isoler l'arborescence znode SolrCloud à l'aide de la prise en charge chroot de ZooKeeper. Par exemple, pour garantir que tous les znodes créés par SolrCloud sont entreposés sous /solr, vous pouvez placer /solr à la fin de votre chaîne de connexion ZK_HOST, comme suit :
| ZK_HOST=zk1,zk2,zk3/solr |
Avant d'utiliser un chroot pour la première fois, vous devez créer le chemin racine (znode) dans ZooKeeper en utilisant le script de contrôle Solr. Nous pouvons utiliser la commande mkroot pour cela :
| bin/solr zk mkroot /solr -z <ZK_node>:<ZK_PORT> |
Note : Si vous souhaitez également démarrer ZooKeeper avec le solr_home existant, vous pouvez utiliser à la place la commande bootstrap zkcli.sh / zkcli.bat, créant également le chemin chroot s'il n'existe pas.
Suppression d'un noyau inconnu
Lorsque Solr charge un noyau à partir d'un système de fichiers, il vérifie l'état de l'unité d'allocation correspondant dans ZooKeeper. Si aucune entrée correspondante n'existe, le noyau sera ignoré et un avertissement sera enregistré. Cela protège contre les erreurs de configuration (par exemple, la connexion à la mauvaise instance ZooKeeper ou au mauvais chroot) où l'index serait toujours valide une fois la configuration corrigée. Cependant, vous devrez peut-être supprimer manuellement les noyaux indésirables n'ayant pas été supprimés avec succès dans le cadre de la suppression intentionnelle d'une collection.
Si vous préférez supprimer automatiquement les fichiers orphelins, vous pouvez modifier votre fichier d'inclusion pour définir SOLR_DELETE_UNKNOWN_CORES sur true :
| SOLR_DELETE_UNKNOWN_CORES=true |
Nom d'hôte Solr
Utilisez la variable SOLR_HOST dans le fichier d'inclusion pour définir le nom d'hôte du serveur Solr :
| SOLR_HOST=solr1.example.com |
Il est recommandé de définir le nom d'hôte du serveur Solr, en particulier lors de l'exécution en mode SolrCloud, car cela détermine l'adresse du noeud lorsqu'il s'enregistre auprès de ZooKeeper.
Bannière d'environnement dans l'interface d'administration (Admin UI)
Pour éviter d'effectuer des modifications accidentelles sur la mauvaise unité d'allocation, vous pouvez configurer une indication visuelle dans l'interface d'administration indiquant si vous travaillez actuellement avec un environnement de production ou non. Pour ce faire, modifiez votre fichier solr.in.sh ou solr.in.cmd avec un paramètre -Dsolr.environment=prod ou définissez la propriété de l'unité d'allocation nommée environment. Les valeurs autorisées sont dev, test, stage ou prod. Chacune de ces valeurs possède des étiquettes et des couleurs par défaut prédéfinies. Pour spécifier l'étiquette en utilisant le mot label et/ou la couleur, utilisez un format délimité par des virgules comme ci-dessous. L'étiquette doit être définie avant la couleur. Le caractère + peut être utilisé à la place de l'espace pour éviter les guillemets. Les couleurs, en utilisant le mot color, peuvent être des couleurs CSS valides ou des chiffres, par exemple, #ff0000 pour le rouge vif. Exemples de configurations d'environnement valides :
| Exemple | Description |
|---|---|
| prod | L'étiquette par défaut est « Production », la couleur par défaut est un ton de rouge. |
| test,label=Functional+test | La couleur par défaut restera le jaune, mais remplacera l'étiquette. |
| dev,label=MyDev,color=blue | Remplace à la fois l'étiquette et la couleur par le nom. |
| stage,color=#ff8888 | Personnaliser la couleur avec le code |
Remplacer les paramètres dans solrconfig.xml
Solr permet de remplacer les propriétés de configuration à l'aide des propriétés système Java transmises au démarrage à l'aide de la syntaxe -Dproperty=value. Par exemple, dans solrconfig.xml, les paramètres de validation automatique par défaut sont définis sur :
<autoSoftCommit>
<maxTime>${solr.autoSoftCommit.maxTime:3000}</maxTime>
</autoSoftCommit>
En général, chaque fois que vous voyez une propriété dans un fichier de configuration Solr utilisant la syntaxe ${solr.PROPERTY:DEFAULT_VALUE}, vous savez qu'elle peut être remplacée à l'aide d'une propriété système Java. Par exemple, pour définir le temps maximal pour les validations logicielles à 10 secondes, vous pouvez démarrer Solr avec -Dsolr.autoSoftCommit.maxTime=10000, comme suit :
| bin/solr start -Dsolr.autoSoftCommit.maxTime=10000 |
Le script bin/solr transmet simplement les options commençant par -D à la JVM lors du démarrage. Pour une exécution en production, il est recommandé de définir ces propriétés dans la variable SOLR_OPTS définie dans le fichier d'inclusion. En gardant notre exemple de validation logicielle, dans /etc/default/solr.in.sh, vous feriez :
| SOLR_OPTS="$SOLR_OPTS -Dsolr.autoSoftCommit.maxTime=10000" |
Paramètres Ulimit (systèmes d'exploitation *nix)
Il existe plusieurs paramètres devant être surveillés et définis aussi haut que possible, «illimité» de préférence. Sur la plupart des systèmes d'exploitation *nix, vous pouvez voir les valeurs actuelles en saisissant ce qui suit au prompt de commande :
| ulimit -a |
Ces quatre paramètres en particulier sont importants pour avoir une valeur très élevée, illimitée si possible.
- Processus maximal (ulimit -u) : 65 000 est le minimum recommandé.
- Descripteurs de fichier (ulimit -n) : 65 000 est le minimum recommandé. Tous les fichiers utilisés par toutes les répliques ont leurs descripteurs de fichiers ouverts en même temps, ce qui peut devenir assez volumineux.
- Mémoire virtuelle (ulimit -v) : définissez sur unlimited. Ceci est utilisé pour MMap les index.
- Taille maximal de la mémoire (ulimit -m) : également utilisé par MMap, défini sur unlimited.
- Si votre système le prend en charge, sysctl vm.max_map_count doit également être défini sur unlimited.
Nous vous recommandons vivement de relever ces paramètres de manière permanente. Le processus exact pour les relever de manière permanente varie selon le système d'exploitation. Certains systèmes nécessitent de modifier les fichiers de configuration et de redémarrer votre serveur. Consultez vos administrateurs système pour obtenir des conseils sur votre environnement particulier.
Vérifiez ces limites à chaque mise à niveau de votre noyau ou de votre système d'exploitation. Ces opérations peuvent les réinitialiser à leurs valeurs par défaut.
Si ces limites sont dépassées, les problèmes signalés par Solr varient en fonction de l'opération spécifique responsable du dépassement de la limite. Des erreurs telles que «trop de fichiers ouverts», «erreur de connexion» et «nombre maximal de processus dépassé» ont été signalées, ainsi que des échecs de récupération de SolrCloud.
Éviter l'échange disque (systèmes d'exploitation *nix)
Lors de l'exécution d'une application Java comme Solr, le fait que le système d'exploitation échange la mémoire sur le disque est une très mauvaise situation. On préféra généralement un crash dur afin que d'autres noeuds Solr sains puissent prendre le relais, plutôt que de laisser un noeud Solr face des échanges disques, ce qui entraîne des performances terribles, des dépassements de délai et un système instable. Il est donc recommandé de désactiver complètement l'échange disque sur l'hôte ou de réduire le «swapiness». Ces instructions sont valables pour les environnements Linux. Notez également que lors de l'exécution de Solr dans un conteneur Docker, ces modifications doivent être appliquées à l'hôte.
Désactivation de l'échange disque
Pour désactiver temporairement l'échange disque sur un système Linux, vous pouvez exécuter la commande swapoff :
| sudo swapoff -a |
Si vous souhaitez rendre ce paramètre permanent, assurez-vous d'abord que vous disposez de suffisamment de RAM physique sur votre hôte, puis consultez la documentation de votre système Linux pour connaître la procédure correcte à suivre pour désactiver l'échange disque (swap).
Réduire l'échange disque
Une autre option consiste à réduire l'échange disque («swap») de votre système. Un système Linux sera par défaut assez agressif dans l'échange de mémoire vers le disque, en ayant une valeur de «swap» par défaut élevée. En réduisant cette valeur à une valeur très basse, cela aura presque le même effet que l'utilisation de swapoff, mais Linux sera toujours autorisé à échanger en cas d'urgence. Pour vérifier le paramètre d'échange actuelle (swap) actuel, exécutez :
| cat /proc/sys/vm/swappiness |
Ensuite, pour modifier le paramètre de manière permanente, ouvrez /etc/sysctl.conf en tant qu'utilisateur root. Ensuite, modifiez ou ajoutez cette ligne au fichier :
| vm.swappiness = 1 |
Vous pouvez également modifier temporairement le paramètre en exécutant cette commande :
| echo 1 > /proc/sys/vm/swappiness |
Considérations relatives à la sécurité
Les administrateurs doivent considérer attentivement leur configuration de sécurité comme une étape importante du passage à la production. Solr fournit un certain nombre de fonctionnalités prêtes à l'emploi pour répondre aux besoins de sécurité des utilisateurs : l'authentification et l'autorisation peuvent être configurées à l'aide d'une gamme de plugiciels de sécurité, la confidentialité peut être renforcée en activant SSL/TLS et (dans SolrCloud) les données ZooKeeper peuvent être protégées par des règles ACL pour empêcher les lectures et écritures non autorisées.
Même si ces mesures ou d'autres sont prises, il est fortement recommandé que Solr soit toujours protégé par un pare-feu. Solr n'est pas conçu pour être exposé sur l'Internet ouvert.
Il est également fortement recommandé que Solr n'écoute que les interfaces réseau strictement requises. Pour empêcher les administrateurs d'exposer involontairement Solr plus largement, Solr écoute uniquement sur l'interface de bouclage («127.0.0.1») par défaut. La plupart des déploiements devront modifier cette valeur pour une valeur moins restrictive afin qu'elle puisse être atteinte à partir d'autres boîtiers. Cela peut être fait en définissant une valeur SOLR_JETTY_HOST dans le «script d'inclusion» de votre environnement (solr.in.sh ou solr.in.cmd) :
| SOLR_JETTY_HOST="0.0.0.0" |
Le même paramètre est également disponible en tant que propriété système -Dsolr.jetty.host.
Il en va de même pour Zookeeper intégré, s'il est exécuté avec Solr. Par défaut, Zookeeper intégré écoute uniquement sur l'interface de bouclage («127.0.0.1»). L'hôte de liaison est contrôlé via la valeur SOLR_ZK_EMBEDDED_HOST dans le «script d'inclusion» de votre environnement (solr.in.sh ou solr.in.cmd) :
| SOLR_ZK_EMBEDDED_HOST="0.0.0.0" |
Le même paramètre est également disponible en tant que propriété système -Dsolr.zk.embedded.host.
Exécution de plusieurs noeuds Solr par hôte
Le script bin/solr est capable d'exécuter plusieurs instances sur une machine, mais pour une installation classique, ce n'est pas une configuration recommandée. Des ressources processeur et mémoire supplémentaires sont nécessaires pour chaque instance supplémentaire. Une seule instance est facilement capable de gérer plusieurs index.
Quand ignorer la recommandation
Pour chaque recommandation, il existe des exceptions. Pour la recommandation ci-dessus, cette exception s'applique principalement lorsque l'on parle d'évolutivité extrême. La meilleure raison d'exécuter plusieurs noeuds Solr sur un hôte est de réduire le besoin de mémoire de tas extrêmement volumineux.
Lorsque la mémoire de tas Java devient très volumineux, cela peut entraîner des pauses de récupération de place extrêmement longues, même avec le réglage GC que le script de démarrage fournit par défaut. Le point exact auquel de la mémoire de tas est considéré comme «très volumineux» varie en fonction de la façon dont Solr est utilisé. Cela signifie qu'il n'y a pas de nombre précis puissant être donné comme seuil, mais si votre mémoire de tas atteint le voisinage de 16 à 32 gigaoctets, il est peut-être temps d'envisager de diviser les noeuds. Idéalement, cela signifierait plus de machines, mais les contraintes budgétaires pourraient rendre cela impossible.
Il y a un autre problème une fois que la mémoire de tas atteint 32 Go. En dessous de 32 Go, Java peut utiliser des pointeurs compressés, mais au-dessus de ce point, des pointeurs plus grands sont nécessaires, ce qui utilise plus de mémoire et ralentit la JVM.
Si votre cas d'utilisation nécessite plus de 31 Go de tas, envisagez plusieurs noeuds, car ils seront généralement plus performants qu'un noeud avec > 32 Go de mémoire de tas.
Si votre cas d'utilisation nécessite plusieurs instances, vous aurez au minimum besoin de répertoires personnels Solr uniques pour chaque noeud que vous souhaitez exécuter ; idéalement, chaque répertoire personnel doit se trouver sur un disque physique différent afin que plusieurs noeuds Solr n'aient pas à se faire concurrence lors de l'accès aux fichiers sur le disque. Le fait d'avoir des répertoires personnels Solr différents implique que vous aurez besoin d'un fichier d'inclusion différent pour chaque noeud. De plus, si vous utilisez le script /etc/init.d/solr pour contrôler Solr en tant que service, vous aurez besoin d'un script distinct pour chaque noud. L'approche la plus simple consiste à utiliser le script d'installation de service pour ajouter plusieurs services sur le même hôte, par exemple :
| sudo bash ./install_solr_service.sh solr-9.6.1.tgz -s solr2 -p 8984 |
La commande ci-dessus ajoutera un service nommé solr2 exécuté sur le port 8984 en utilisant /var/solr2 pour les fichiers inscriptibles (c'est-à-dire «live») ; le deuxième serveur sera toujours détenu et exécuté par l'utilisateur solr et utilisera les fichiers de distribution Solr dans /opt. Après avoir installé le service solr2, vérifiez qu'il fonctionne correctement en procédant comme suit :
|
sudo service solr2 restart sudo service solr2 status |