SolrCloud Lessons Learned – ZooKeeper

Was haben wir aus unserem bisherigen Einsatz von Apache Solr als SolrCloud Installationen bisher an Erfahrungen gemacht?
Um diese Frage soll es in den Beiträgen unter dem Namen “SolrCloud Lessons Learned” gehen.

Im ersten Beitrag in dieser Reihe behandeln wir Apache ZooKeeper.
Welche Konfigurationsparameter sollten in einem produktiven Einsatz unbedingt gesetzt werden?

Wofür wird ZooKeeper in der SolrCloud verwendet

um die Konfigurationen der Collections zu verteilen
um den Status über den Cluster (die Solr Knoten) zu verwalten
um Statusänderungen zu verteilen
um Leaderelections durchzuführen

Für einen produktiven Einsatz der SolrCloud wird vorgesehen, ZooKeeper in einem eigenen sogenannten Ensemble, und nicht embedded mit Solr, zu betreiben. Damit soll sichergestellt werden, dass eine ZooKeeper-Instanz erreichbar bleibt, falls die Solr JVM nicht mehr antwortet oder terminiert wurde.

Da ZooKeeper mehrheitsbasiert arbeitet, sollte immer eine ungerade Anzahl an ZooKeeper-Instanzen gestartet werden, damit das ZooKeeper-Ensemble beschlussfähig bleibt, auch wenn Knoten ausfallen. Die Mindestanzahl der zu startenden ZooKeeper-Instanzen beträgt also drei, somit kann eine ZooKeeper-Instanz ausfallen.

Die Basiskonfiguration ist schnell erledigt, man muss nur das Datenverzeichnis dataDir und die Ports hinzufügen, unter denen die ZooKeeper-Instanzen erreichbar sind.

Hier ein Beispiel für die notwendigen Einstellungen:

dataDir=/data/zookeeper

server.1=zookeeper1.solr-cloud:2888:3888
server.2=zookeeper2.solr-cloud:2889:3889
server.3=zookeeper3.solr-cloud:2890:3890

Das Datenverzeichnis von ZooKeeper kann schnell größer werden wenn eines der folgende Ereignisse auftritt:

Kommunikationsprobleme zwischen ZooKeeper und SolrCloud-Instanzen – führen zu Clusterstate Änderungen
regelmäßige Neustarts von Solr Knoten – führen zu Clusterstate Änderungen
Änderungen an den Konfigurationen der Collections – diese werden in ZooKeeper abgelegt

Diese Änderungen werden in ein sogenanntes Transactionlog geschrieben, sobald ein Transactionlog “stark in seiner Größe wächst” wird davon ein Snapshot angefertigt.

[call-to-action-consulting /]

Lesson Learned – Die erste Lektion

ZooKeeper-Ensemble Konfiguration im Einsatz mit einer SolrCloud

Die ausgelieferte Konfiguration von ZooKeeper macht zwar einen Verweis auf die Online-Dokumentation, allerdings nur wenn man die Konfiguration autopurge einschalten möchte. Der springende Punkt ist allerdings, dass ZooKeeper ohne eingeschaltetes autopurge keine alten Snapshots oder Transactionlogs löscht. Es ist nachvollziehbar, dass die Vorhaltedauer höchst systemspezifisch ist und daher kein sinnvoller Standardwert angenommen werden kann, allerdings wird in der Dokumentation der SolrCloud kein Hinweis dazu gegeben, dass diese konfiguriert werden sollte.

Folgende Einstellung sollten unbedingt konfiguriert werden, wenn man das ZooKeeper.Ensemble produktiv in Betrieb nehmen möchte:

```
autopurge.snapRetainCount
```
Die konfigurierte Anzahl an Snapshots und Transactionlogs wird vorgehalten, die überzähligen werden gelöscht.
```
autopurge.purgeInterval
```
In diesem Intervall, anzugeben in Stunden, werden die Verzeichnisse überprüft und falls notwendig gesäubert.

Wir sind im konkreten Fall darauf gestoßen, da die Server auf denen die Solr Knoten laufen, während des Betriebes regelmäßig neugestartet wurden. Allerdings wurde der Tomcat-Prozess hart terminiert, wenn dieser sich nicht innerhalb einer sehr kurzen Zeitspanne beendet hat. Da Solr durch diese Terminierung Probleme mit der Synchronisation und dem Clusterstate bekommen hat, sind die Transactionlogs von ZooKeeper ständig befüllt worden und deswegen wurden massiv Snapshots erzeugt (mehrere GiB).

Man kann die Snapshots und Transactionlogs auch mittels Kommandozeilenaufruf säubern.
So sieht das Verzeichnis vor der Säuberung aus:

Nach einem Aufruf von

java -cp \
  zookeeper-3.4.5.jar: \
  ./lib/slf4j-api-1.6.1.jar: \
  ./lib/slf4j-log4j12-1.6.1.jar: \
  ./lib/log4j-1.2.15.jar: \
  ./conf/ \
  org.apache.zookeeper.server.PurgeTxnLog /data -n 3

enthält das Verzeichnis nur noch die aktuellsten 3 Snapshots/Transactionlogs: