Sonnig mit Aussicht auf Wolken

Solr-Suchserver in die Cloud skalieren
Kommentare

Apache Solr ist für die meisten Entwickler die schon mal eine leistungsfähig Suchfunktion implementierten mussten ein alter Bekannter. Vor wenigen Monaten wurde nun die langerwartete neue Major Version 4.0, der auf Apache Lucene basierenden Suchplattform veröffentlicht. Auch wenn manche Neuerungen, wie das komplett Überarbeitete Admin UI und die Aktualisierung der zugrundeliegenden Apache-Lucene-Version, offensichtlich sind, steckt die spannendste Neuerung im Detail: Die SolrCloud ermöglicht den relativ einfachen Aufbau eines Clusters aus Solr-Applikationsservern, um die Suchplattform einfach und effizient zu skalieren und hochverfügbar zu machen.

Bevor wir uns in das Abenteuer SolrCloud stürzen können, gilt es noch ein paar Vorbereitungen zu treffen, die im weiteren Verlauf des Artikels die Arbeit und gegebenenfalls die Fehlerdiagnose erheblich vereinfachen können. Für das Arbeiten mit mehreren identischen Systemen ist ClusterSSH bzw. csshX (für Mac OSX) eine gute Wahl um SSH-Kommandos auf mehreren Systemen parallel ausführen zu können. Für den schnellen Start gibt es auch auf dem GitHub-Profil des Autors [1] eine vorgefertigte Vagrant Box auf der bereits alle wichtigen Dienste installiert sind und die als Grundlage für alle nachfolgenden Beispiele dient. Als Betriebssystem wurde Ubuntu LTE 12.04 gewählt.

Das Einrichten der Maschine geht schnell von der Hand, es wird lediglich ein installiertes vagrant [2] vorausgesetzt. Die entsprechende Base Box wird, wenn nicht bereits vorhanden, zum System hinzugefügt:

   vagrant add box precise64 http://files.vagrantup.com/precise64.box

Anschließend soll ein kleines Cluster an virtuellen Maschinen aufgebaut werden, um somit eine eigene kleine SolrCloud auf dem eigenen Rechner aufsetzten zu können. Für die nachfolgenden Beispiele hat der Autor vier virtuelle Maschinen aufgesetzt. Als Hostname wurde jeweils solr und die Nummer der Maschine verwendet (solr1, solr2 usw.). Dazu wurde das Git Repository in entsprechende Ordner geklont:

git clone https://github.com/sthartmann/vagrant-solr4.git solr1

Die Hostnamen und IP-Adressen der virtuellen Maschinen müssen vor dem ersten Initialisieren in der entsprechenden Vagrantfile angepasst werden:

config.vm.network :hostonly, "192.168.3.200"
config.vm.host_name = "solr1"

Nun kann in das jeweilige Verzeichnis gewechselt und die Maschine kann hochgefahren werden. Es ist zu bedenken, dass der erste Start etwas dauern kann, da hier die Solr- und ZooKeeper-Installationspakete aus dem Internet nachgeladen werden:

cd solr1
vagrant up

Der Log-in auf den Maschinen kann entweder über das entsprechende vagrant ssh-Kommando im jeweiligen Ordner erfolgen oder via ssh direkt mit dem Benutzer vagrant und dem gleichlautenden Passwort.

Als letzter Schritt sollten noch auf den Maschinen alle weiteren Hosts in der entsprechenden Host-Datei unter /etc/host eingetragen werden, um die Kommunikation über die entsprechenden Namen sicherzustellen und nervige Tipparbeit bei IP-Adressen zu vermeiden.

Es ist auch möglich, die ganze Cloud auf einer Maschine aufzuziehen, jedoch müssen hier die Ports der Dienste angepasst werden, um Konflikte durch doppelte Belegung zu vermeiden. Aus eigenen Erfahrungen verursacht dieses Vorgehen meistens mehr Verwirrung als Nutzen. Daher konzentrieren wir uns auch in diesem Artikel auf das Vorgehen die Dienste von Anfang an auf mehrere (virtuelle) Maschinen zu verteilen.

Installation von Solr4

Als Grundlage für Solr bzw. die SolrCloud wird in jedem Fall ein Java Servlet Container benötigt, für den schnellen Start wird Jetty als Java-Server im Solr-Package gleich mitgeliefert. In diesem Artikel wird der Aufbau jedoch mit Tomcat 6 als Servlet Engine realisiert, da sich diese Konstellation im Produktiveinsatz als zuverlässiger und flexibler erwiesen hat. Natürlich kann auch Version 7 von Tomcat ohne Probleme eingesetzt werden.

Eine aktuelle Java-Version (mindestens 1.6) wird sowohl vom Tomcat-Server als auch von Solr vorausgesetzt und sie ist auf den meisten Systemen bereits installiert.

Auf der vorbereiteten virtuellen Maschine ist das Tomcat-6-Paket bereits vorinstalliert, für alle anderen Systeme kann der Server über die integrierte Paketverwaltung nachinstalliert werden:

apt-get install tomcat6 # Ubuntu bzw. Debian Systeme
zypper install tomcat6 # Suse

Anschließend wird noch das Solr4-Installationspaket benötigt, dieses kann auf der Website des Projekts, in der jeweils aktuellen Version, heruntergeladen werden [3].

Um gleich von Beginn an eine saubere Ordnerstruktur zu haben, legen wir diese vor der eigentlichen Installation an und kopieren die entsprechenden Dateien auf allen Servern in die folgende Struktur:

/etc/solr
  /data/
  /zoo_data/

Für die kompletten Verzeichnisse muss der Tomcat Lese- und Schreibrechte besitzen, um die Daten dort entsprechend ablegen zu können:

chmod -R tomcat /etc/solr/

Nun aber genug der Vorbereitung, die Installation kann beginnen. Nach dem Entpacken des Archivs werden nun einerseits die Beispieldaten in unsere Verzeichnisstruktur integriert und die eigentliche Solr-Anwendung im Tomcat-Server deployt:

tar xzf solr-4.x.x.tgz
cp -R solr-4.x.x/example/solr/* /etc/solr/ # Copy sample data
cp solr-4.x.x/dist/solr-4.x.x.war /var/lib/tomcat6/webapps/

Ob die Anwendung erfolgreich im Tomcat deployt wurde, kann durch einen Aufruf der Admin-Oberfläche unter http://localhost:8080/solr-4.x.x/ geprüft werden. Bei Problemen in diesem Schritt ist ein Neustart des Tomcat-Diensts meistens schon ausreichend. Es wird jedoch beim Aufruf der Admin-Oberfläche noch eine Fehlermeldung erscheinen, da noch keine Cores definiert wurden. Diese Fehlermeldung wird jedoch nach dem weiteren Durcharbeiten des Artikels verschwinden.

Sollte es zu anderen Fehlern kommen, lohnt sich meistens ein Blick in das Logfile des Tomcat-Servers, das unter /var/log/tomcat/catalina.out zu finden ist. Dort werden auftretende Exceptions oder Fehler in Konfigurationsdateien ausgegeben. Um späteren Verwirrungen entgegenzuwirken, empfiehlt sich dieser Schritt gleich auf allen virtuellen Testsystemen auszuführen. Der Aufbau der Konfiguration für die Systeme ist in folgenden Dateien abgelegt:

/etc/tomcat6/Catalina/localhost/solr-4.2.0.xml
/etc/solr/collection1/conf/solrconfig.xml
/etc/solr/solr.xml

Die erste Datei der Liste wird nicht automatisch erzeugt, sondern muss nun angelegt werden. In dieser Datei wird die Konfiguration des Solr Containers innerhalb von Tomcat festgelegt:

<?xml version="1.0" encoding="utf-8"?> <Context path="/solr-4.2.0" debug="0" crossContext="true" allowLinking="true">   <Environment name="solr/home" type="java.lang.String" value="/etc/solr" override="true"/> </Context>

Es müssen auf den jeweiligen Systemen der Wert des path-Parameters und der value-Parameter der solr/home-Umgebung auf die lokale Installation angepasst werden.

In der solrconfig.xml wird der allgemeine Aufbau des Index bzw. der Collection definiert, dazu gehören unter anderem auch Request und Search Handler und weitere spezifische Einstellungen für die jeweilige Collection. Für unseren Testaufbau muss lediglich der Pfad zum Datenverzeichnis angepasst werden:

 ${solr.data.dir:/etc/solr/data}

Im letzten Schritt der Konfiguration werden wir die globale Solr-Konfiguration an unseren Java-Server anpassen. Hierzu müssen in der Datei /etc/solr/solr.xml die Parameter host und hostPort editiert werden. Für host setzen wir den vorherigen Hostnamen für unser System (z. B. solr1, solr2 usw.) oder die jeweilige IP-Adresse des Systems. Der hostPort sollte bei der Verwendung von Tomcat auf 8080 gesetzt werden, was dem Default Port von Tomcat entspricht. Sollte nicht der Default Port verwendet werden, muss der Parameter gleichgezogen werden.

Nach dem Abschluss der Konfiguration kann das Admin-Interface erneut aufgerufen werden, es sollte jetzt kein Fehler mehr erscheinen, sondern es sollte Abbildung 1 ähneln.

Abb. 1: Überarbeitete Administrationsoberfläche von Solr 4.x

Abb. 1: Überarbeitete Administrationsoberfläche von Solr 4.x

Ab in die Wolke

Nach den nicht ganz unerheblichen Vorarbeiten können wir nun mit dem eigentlichen Aufbau unserer SolrCloud beginnen. Hierzu am Anfang noch ein paar kleine Definitionen der Terminologie.

Die größte Einheit innerhalb von Solr ist die so genannte Collection. Hierbei handelt es sich um den eigentlichen Suchindex. Die Collection wiederum kann in Shards aufgeteilt werden. Sie können zur logischen Untergliederung von Collections verwendet werden. Die Collections können dann wiederum auf diverse Solr Nodes aufgeteilt werden, wobei ein Node jeweils einer Solr-Instanz entspricht.

Nun aber genug der theoretischen Vorbereitung und wir beginnen mit der Praxis, denn die nächsten Schritte zu unserer ersten Cloud werden schneller erledigt sein, als erwartet.

Abb. 2: Erster Testaufbau mit einer Collection, zwei Shards und einem internen ZooKeeper-Server

Abb. 2: Erster Testaufbau mit einer Collection, zwei Shards und einem internen ZooKeeper-Server

Im ersten Schritt werden wir eine SolrCloud mit einer Collection und zwei Shards (Abb. 2) aufsetzten, in der die Konfiguration von einem ZooKeeper-Server auf dem Host solr1 verwaltet wird. In der skizzierten Serverkonfiguration bilden zwei Server den entsprechenden Shard ab, und auf die anderen beiden wird der Shard repliziert.

Jetzt muss den derzeit autark arbeitenden Solr-Servern auf unseren virtuellen Maschinen nur noch mitgeteilt werden, welche Funktion im Cluster sie übernehmen sollen. Die Zusammenarbeit der Server und der Abgleich der gemeinsamen Konfiguration erfolgen über Apache ZooKeeper, dieses Modul ist in Solr4 mittlerweile integriert und im ersten Beispiel werden wir auch auf den internen ZooKeeper-Server zurückgreifen.

Um die entsprechenden Parameter für das „Aufspannen“ unserer Cloud an Solr zu übergeben, passen wir die globale Variable JAVA_OPTS an. Damit dies beim Start des Tomcat-Servers automatisch angewendet wird, editieren wir das Startskript von Tomcat6 unter /etc/init.d/tomcat6.

Für den ersten Server, auf dem auch der interne Zookeeper gestartet wird, wird die folgende Zeile eingefügt:

export JAVA_OPTS="$JAVA_OPTS -DhostContext=/solr-4.2.0 -Dbootstrap_confdir=/etc/solr/collection1/conf -Dcollection.configName=myconf -DzkRun -DnumShards=2"

Der erste Parameter DhostContext legt den Pfad zur Solr-Applikation innerhalb des Tomcat-Servers fest, Dbootstrap_confdir zeigt auf die Konfiguration unseres Index bzw. der Collection. Mit Dcollection.configName wird ein eindeutiger Name für die Konfiguration gesetzt, um anschließend mit DzkRun den Start des ZooKeeper-Server zu triggern. Der letzte Parameter legt fest, dass wir in diesem Beispiel unsere Collection auf zwei logische Shards aufteilen wollen. Wird der DnumShards-Parameter nicht übergeben, wird als Default der Wert 1 gesetzt, was keiner Aufteilung der Collection in mehrere Shards entspricht.

Für die restlichen Server fällt die Konfiguration etwas einfacher aus. Dort müssen lediglich der Pfad zur Solr-Applikation und der Host, auf dem der ZooKeeper-Server läuft, übergeben werden:

export JAVA_OPTS="$JAVA_OPTS -DhostContext=/solr-4.2.0
  -DzkHost=solr1:9080"

Als Port wird für den ZooKeeper immer der Tomcat Port plus 1000 verwendet. Nachdem wir nun alle Startskripte entsprechend angepasst haben, können wir Tomcat beenden und neu starten. Beim Blick in die jeweiligen Admin-Interfaces sollte nun ein neuer Menüpunkt Cloud ins Auge fallen. Nach einer Auswahl des zugehörigen Untermenüs Graph sollte nun eine grafische Darstellung Ihrer SolrCloud erscheinen (Abb. 3).

Sollten dort aus vorherigen Konfigurationsversuchen noch „alte“ Systeme in grau angezeigt werden, muss lediglich das Verzeichnis /etc/solr/zoo_data/ geleert werden und ein Neustart des Tomcat erfolgen.

Abb. 3: Grafische Darstellung der SolrCloud innerhalb des Admin-Interfaces

Abb. 3: Grafische Darstellung der SolrCloud innerhalb des Admin-Interfaces

Herzlichen Glückwunsch, Sie haben soeben Ihre erste SolrCloud installiert und in Betrieb genommen. Für die weiteren Gehversuche müssen nun lediglich noch Testdaten in unsere Collection eingefügt werden. Hier können wir auch auf Beispieldaten aus dem Solr-Paket zurückgreifen. Die Daten sind innerhalb des Solr-Installationsordners in /examples/exampledocs/ hinterlegt. Der Import kann über die Konsole erfolgen:

java -Durl=http://solr1:8080/solr-4.2.0/collection1/update -jar post.jar mem.xml

Die importierten Daten können nun mit curl abgefragt werden:

curl http://solr1:8080/solr-4.2.0/collection1/select?q=*%3A*&wt=xml&indent=true

Diese Abfrage kann nun auf jedem beliebigen Solr Host ausgeführt werden und sollte, wenn alle Schritte erfolgreich absolviert wurden, nun auf allen Systemen dieselbe Antwort bzw. dieselbe Dokumentenanzahl als Ergebnis liefern.

Parktisch ist auch das überarbeitete Query-Tool innerhalb der Admin-Oberfläche, durch dessen Hilfe Abfragen schnell ausgeführt und getestet werden können. Die Rückgabe der Daten aus dem Solr-Index kann nicht ausschließlich in XML erfolgen, sondern wahlweise auch in JSON, Python, Ruby, PHP oder CSV (Abb. 4). Das Setzen des entsprechenden Rückgabeformats kann später einiges an Programmierarbeit ersparen.

Abb. 4: Überarbeitetes Query-Tool inkl. Auswahl des Rückgabeformats

Unsere Cloud hat nur leider immer noch einige Schwachpunkte: Bei einem Ausfall des ZooKeeper-Servers bzw. einem kompletten Ausfall des Hosts können keine Daten mehr repliziert werden. Somit ist das Ziel der Hochverfügbarkeit nicht erreicht. Diese Unwägbarkeit lässt sich jedoch mit einigen marginalen Anpassungen der Startparameter aus dem Weg räumen.

Parameterübersicht/Solr4

Allgemeine Parameter (solr.xml):
host: Hostname der Instanz, default FQDN
hostPort: Port für die laufende Solr-Instanz, default = jetty.port (8983)
hostContext: Kontext/Pfad der Solr-Instanz innerhalb des Java Containers
ZooKeeper-Paramter (JAVA_OPTS / SOLR_OPTS):
zkRun: Führt den in Solr integrierten ZooKeeper-Server auf dieser Instanz aus
zkHost: Host bzw. Liste der Hosts der ZooKeeper-Server innerhalb des Clusters
zkClientTimeout: default = 15000/ZooKeeper-Session-Time-out
Cluster-Parameter:
numShards: default = 1, Anzahl der Shards innerhalb des Clusters
shard: Benutzerdefinierte Shard-ID, Instanz wird dem jeweiligen Shard zugeordnet

Hochverfügbarkeit mit ZooKeeper Ensemble

Abb. 5: SolrCloud – je eine ZooKeeper-Instanz je Solr-Instanz

Abb. 5: SolrCloud – je eine ZooKeeper-Instanz je Solr-Instanz

Der einfachste Weg zur Hochverfügbarkeit ist die Anpassung der Parameter, die beim Start an Solr übergeben werden. Hierzu wird auf jedem System ein ZooKeeper-Server gestartet. Zudem verbindet sich jeder Host nicht auf einen, sondern auf mehrere ZooKeeper-Server innerhalb der Cloud. Wobei lediglich Host 1 die Konfiguration in das Ensemble lädt (Abb. 5):

export JAVA_OPTS="$JAVA_OPTS -DhostContext=/solr-4.2.0 -Dbootstrap_confdir=/etc/solr/collection1/conf -Dcollection.configName=myconf -DzkRun -DzkHost=solr2:9080,solr3:9080,solr4:9080 -DnumShards=2"

Für alle weiteren Hosts werden lediglich die zusätzlichen ZooKeeper-Server übergeben:

export JAVA_OPTS="$JAVA_OPTS -DhostContext=/solr-4.2.0
  -DzkRun -DzkHost=solr1:9080,solr3:9080,solr4:9080"

Nun läuft auf jedem Host ein interner ZooKeeper-Server, womit auch im Falle des Ausfalls eines der Systeme die Verteilung der Konfiguration und Daten sichergestellt ist.

Wer einen Blick hinter die Kulissen seines ZooKeeper Ensembles wagen will, dem sei das Eclipse-ZooKeeper-Plug-in ans Herz gelegt [4] (Abb. 6).

Abb. 6: Darstellung des ZooKeeper Ensemble in Eclipse

Abb. 6: Darstellung des ZooKeeper Ensemble in Eclipse

Hier lässt sich klar erkennen, dass immer einer der Hosts als Leader und die restlichen Host als Follower agieren. Bricht der Leader weg, wird in einem Quorum über einen neuen Leader abgestimmt, der dann die Verteilung der Konfiguration sicherstellt.

Die eigentliche Replikation des Suchindex erfolgt nicht durch ZooKeeper, sondern über die interne Replikation des Solr-Servers, deren Verhalten in der Konfiguration festgelegt wird.

Nun aber zu der Installation des externen ZooKeepers. Hierzu laden wir die entsprechende Version von der Seite des Projekts oder verwenden das Paket, das auf der Beispielmaschine bereits im Home-Verzeichnis hinterlegt ist:

tar xzf zookeeper-3.4.x.tar.gz
mkdir /etc/zookeeper
mkdir /etc/zookeeper/data/
mkdir /etc/zookeeper/log/
cp -r zookeeper-3.4.x/* /etc/zookeeper

Nach den folgenden Schritten ist die Installation des ZooKeeper bereits abgeschlossen, und es müssen lediglich noch einige Konfigurationsanpassungen vorgenommen werden. Innerhalb des /etc/zookeeper/data/-Verzeichnisses der jeweiligen Maschinen wird eine Datei myid angelegt, die lediglich die Nummer des jeweiligen Servers enthält: für Host 1 eine 1 usw. Die eigentliche Konfigurationsdatei heißt zoo.cfg und ist in /etc/zookeeper/conf/ abgelegt. Diese passen wir wie in Listing 1 an.

Listing 1

# The number of milliseconds of each tick tickTime=2000 # The number of ticks that the initial synchronization phase can take initLimit=10 # The number of ticks that can pass between sending a request and getting an acknowledgement syncLimit=5 # The directory where the snapshot is stored # Choose appropriately for your environment dataDir=/etc/zookeeper/data # The port at which the clients will connect clientPort=2181 # The directory where transaction log is stored # This parameter provides dedicated log device for ZooKeeper dataLogDir=/etc/zookeeper/log # ZooKeeper server and its port no. # ZooKeeper ensemble should know about every other machine in the ensemble # Specify server id by creating 'myid' file in the dataDir # Use hostname instead of IP address for convenient maintenance server.1=solr1:2888:3888 server.2=solr2:2888:3888 server.3=solr3:2888:3888 server.4=solr4:2888:3888

Der Start des Servers erfolgt durch eigene Skripte, welche in /etc/zookeeper/bin/ zu finden sind:

./zkServer.sh start

Um eventuell auftretende Fehler zu beheben oder für weitere Diagnosezwecke, kann die Datei zookeeper.out im bin/-Verzeichnis von ZooKeeper verwendet werden:

tail -f /etc/zookeeper/zookeeper.out

Eine einfache Statusabfrage kann auch direkt über die Konsole erfolgen:

./zkServer.sh status
JMX enabled by default
Using config: /etc/zookeeper/bin/../conf/zoo.cfg
Mode: follower

Auch kann ein Blick mit dem erwähnten Eclipse-Plug-in aufschlussreich sein. Ein ebenfalls sehr hilfreiches Tool bei der Arbeit mit vielen ZooKeeper-Servern ist zkTop, ein Klon des top-Befehls, unter Linux abgestimmt auf ZooKeeper [5]. Was einem dann sofort auffällt, ist, dass in unserem neuen „externen“ ZooKeeper Ensemble keinerlei Informationen enthalten sind. Um nun die Solr-Konfiguration zu verteilen, müssen wir diese in das Ensemble laden. Hierzu machen wir uns eine Kopie der Solr-CLI-Klassen aus dem im Tomcat deployten solr-x.x.x.war:

cp /var/lib/tomcat6/webapps/solr-4.2.0/WEB-INF/lib/* solr-cli/

Mithilfe der Tools ist das Hochladen der Konfiguration schnell erledigt:

java -classpath .:/home/vagrant/solr-cli/* org.apache.solr.cloud.ZkCLI -cmd upconfig -zkhost solr1:2181,solr2:2181,solr3:2181,solr4:2181 -confdir /etc/solr/collection1/conf/ -confname myconf

An dieser Stelle fällt auf, dass sich der ZooKeeper-Port geändert hat. Der externe ZooKeeper läuft per Default auf Port 2181. Diese Einstellung kann in der zoo.cfg angepasst werden. Die hochgeladene Konfiguration muss nun noch verlinkt werden:

java -classpath .:/home/vagrant/solr-cli/* org.apache.solr.cloud.ZkCLI -cmd linkconfig -collection=collection1 -confname=myconf -zkhost solr1:2181,solr2:2181,solr3:2181,solr4:2181

Im Ordner example/cloud-scripts innerhalb des Solr-Pakets befindet sich auch ein Linux/Windows Shell Script, das das Setzen des Classpath und Klassennamens übernimmt. Die Aufrufe werden dadurch entsprechend vereinfacht:

./zkcli.sh -cmd upconfig -zkhost solr1:2181,solr2:2181,solr3:2181,solr4:2181 -confdir /etc/solr/collection1/conf/ -confname myconf

bzw.

./zkcli.sh -cmd linkconfig -collection=collection1 -confname=myconf -zkhost solr1:2181,solr2:2181,solr3:2181,solr4:2181

Den Erfolg der letzten Schritte können wir nun auch einfach über die ZooKeeper-Konsole verifizieren. Das entsprechende Skript für die Verbindung via CLI (zkCli.sh) findet sich auch im bin/-Verzeichnis der Solr-Installation (Listing 2).

Listing 2

./zkCli.sh -server localhost:2181 [zk: localhost:2181(CONNECTED) 1] ls / [configs, collections, zookeeper] [zk: localhost:2181(CONNECTED) 2] ls /configs [myconf] [zk: localhost:2181(CONNECTED) 4] ls /collections [collection1]

Damit Solr nun nicht mehr den internen ZooKeeper verwendet, müssen nun wiedermal die Tomcat-Startskripte angepasst werden. Im ersten Schritt entfernen wir jeweils den Parameter –DzkRun, der den Start des internen ZooKeeper-Servers auslöst. Zudem müssen wir beim –DzkHost-Parameter die Portnummern auf den neuen ZooKeeper-Port 2181 anpassen.

Da das Hochladen der Konfiguration nun einmalig manuell vorgenommen wurde, muss auch diese auf Host 1 nicht mehr übergeben werden. Somit ergeben sich für die vier Hosts nun die folgenden Startparameter:

export JAVA_OPTS="$JAVA_OPTS -DhostContext=/solr-4.2.0
  DzkHost=solr1:2181,solr2:2181,,solr3:2181,solr4:2181"

Nach diesen Schritten ist nun die SolrCloud mit externen ZooKeeper Ensemble aufgesetzt und einsatzbereit. Die Vorteile eines externen ZooKeeper Ensembles sind zum einen die Möglichkeit, den ZooKeeper- und Solr-Server voneinander zu lösen, um ggf. auch andere Konfigurationen über ZooKeeper zu verteilen. Auch besteht die Möglichkeit, für die Solr-Konfiguration auf ein bestehendes ZooKeeper Ensemble zurückzugreifen.

Ob nun alles in dem erwarteten Umfang funktioniert, kann nun leicht getestet werden, indem man den einen oder anderen Host gezielt abschaltet.

Solr4 und PHP

Zum Abschluss des Artikels soll nun noch der Brückenschlag zum Einsatz von Solr4 bzw. SolrCloud in Verbindung mit PHP erfolgen. Zwar gab es keine wesentlichen Änderungen in der Struktur der Abfragen, doch müssen die meisten PHP Solr Libraries minimal angepasst werden, um mit der neuen Version einwandfrei zusammenzuarbeiten.

Seit Version 3.1.0 unterstützt Solarium alle relevanten Solr4-Funktionen und ist somit die umfangreichste und beste Library für die Zusammenarbeit von Solr4 und PHP [6].

Ausschlaggebend für die Anpassungen ist der Parameter waitFlush(), der in älteren Solr-Versionen bei commit()– und optimize()-Funktionen übergeben wurde. Da dieser Parameter bereits seit Version 1.4 als deprecated gilt [7], wurde er nun in Solr4 endgültig entfernt. Bereits in den letzten Versionen hatte er keine Funktion mehr und wurde nur aus Kompatibilitätsgründen mitgezogen.

Zusätzlich wurde bei der commit-Funktion auch noch der neue boolsche Parameter softCommit eingeführt. Dieser ermöglicht einen performanten Neuaufbau von „Views“ auf den Index, ohne jedoch sicherzustellen, dass alle Daten bereits „on-disk“ geschrieben wurden.

Da in bestehenden Projekten der Umstieg auf eine neue Solr Client Library meistens viel Refactoring mit sich bringt und sich gerade wegen dieser kleinen Änderungen auch nicht wirklich lohnt, gibt es für die gängigen Librarys, wie die PECL Extension und auch die offizielle Solr PHP Library des Apache-Projekts gute und funktionale Patches aus der Community, in denen die entsprechende Funktionalität integriert und angepasst wurde [8],[9].

Fazit

Was nach dem ersten Eintauchen in die Welt von Solr4 sicherlich am meisten ins Auge sticht, ist das neue und aufgeräumte Admin UI, das nun auch alle Funktionalitäten erfüllt, die man sich schon immer für die einfache Verwaltung seiner Solr-Instanzen gewünscht hat. Doch wie bereits eingangs erwähnt, kommt der wirkliche Spaß erst mit dem Set-up der eigenen SolrCloud. Denn hier zeigt sich die wahre Power der neuen Solr-Version: einfache und effektive Hochverfügbarkeit und Skalierbarkeit. Sicherlich ist für die einfachen Anwendungszwecke eine „normale“ Replikation zweier Solr-Server weiterhin ausreichend. Aber der Schritt in die Cloud ist so nah, dass es fast schon sexy ist, auch kleine Solr-Installationen als solche vorzubereiten, um im späteren produktiven Einsatz auf alle Eventualitäten vorbereitet zu sein.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -