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: