Ist Ihr Search Cluster wirklich (ausfall)sicher??? Jepsen beweist es!!!
Viele Anbieter und Produkte werben damit, dass große, skalierbare und performante Search Cluster leicht zu erstellen und zu warten sind. Weder mit Apache Solr noch mit Elasticsearch ist dies eine große Herausforderung. Beide Such-Server bieten eine ausgereifte API um neue Collections anzulegen, zu löschen, Aliase zu verwalten und so weiter.
ABER !!! Wie verhalten sich diese Systeme im laufenden Betrieb? Sind die Daten immer redundant auf allen Knoten? Was passiert wenn ein Teil meines Clusters ausfällt oder nur durch Netzwerkprobleme kurzfristig abgeschnitten ist?
Oft genug hört man von Horrorgeschichten, dass ganze Search Cluster Installationen durch plötzlich auftretende Probleme korrumpiert bzw. zerstört werden. Um dies zu testen – damit man die richtige Wahl der Applikation bzw. der Technologie treffen kann – wurde ein Jepsen entwickelt. Jepsen werden wir in diesem Artikel kurz vorstellen und Testergebnisse bezüglich SolrCloud und Elasticsearch aufzeigen.
Was ist Jepsen?
Jepsen ist ein Tool welches Netzwerkprobleme bzw. –ausfälle simuliert und die Ergebnisse protokolliert. Dadurch lassen sich bei Search Cluster Installationen Szenarien wie das berüchtigte Split Brain nachstellen. Während einer solchen „Teilung“ des Search Cluster kann man nun weiter indexieren bzw. Suchen und merkt wie sich das System verhält.
Für die Tests von Jepsen mit der SolrCloud bzw. mit einem Elasticsearch Cluster bedeutet dies, dass in unterschiedlichsten Varianten einzelnen Knoten zeitweise mit Jepsen entfernt werden. Gleichzeitig wird weiter indexiert und es wird überprüft, ob das Failover funktioniert und die Daten konsistent bleiben.
Hierzu gibt es bereits einige Untersuchungen, die wir nachfolgen kurz vorstellen. Details zu den Untersuchungen finden Sie in den weiter unten verlinkten Seiten.
Jepsen vs. SolrCloud
Im Rahmen der Jepsen Tests wurde eine SolrCloud mit Instanzen aufgesetzt, wobei auf jeder Instanz ein Apache Solr und ein Apache ZooKeeper installiert wurden. Anschließend wurden in unterschiedlichen Versuchen mal eine Instanz aus dem Verbund gelöst oder es mal wurde der bestehende Cluster in zwei Teile gesplittet.
Bei den Indexierungs- und Suchtests hat sich immer herauskristallisiert, dass keine Daten während der Indexierung verloren gehen und Indexe immer synchron waren.
Jepsen vs. Elasticsearch
Ein ähnliches Setup wurde für Elasticsearch gewählt. Es wurde ebenfalls ein Cluster mit 5 Instanzen aufgesetzt und mittels Jepsen Netzwerkprobleme simuliert.
Bei den Indexierungs- bzw. Suchtests wurde festgestellt, dass es im gewählten Setup von Elasticsearch zu Datenverlusten gekommen ist.
Fazit
Zusammenfassend kann man sagen, dass sich die SolrCloud wir ein CP System verhält (siehe CAP Theorem), d.h. die Daten werden vorrangig konsistent (C) und partitionstolerant (P) gehalten. SolrCloud sorgt also dafür, dass die Daten sicher indexiert werden, vernachlässigt aber die Verfügbarkeit (A). Elasticsearch dagegen ist eher ein CA System, d.h. Elasticsearch setzt eher darauf, dass der Cluster verfügbar ist, als dass in jedem Replika alle Daten enthalten sind.
Wenn Sie in Ihrem System auf mehr Partitionstoleranz Wert legen, als auf Verfügbarkeit, dann ist Apache Solr das richtige Produkt. Ist Ihnen die Verfügbarkeit wichtiger als die Gewissheit, dass alle Daten auf allen Knoten vorhanden sind, dann ist Elasticsearch besser.
Weiterführende Links
- Jepsen vs. SolrCloud – https://lucidworks.com/blog/call-maybe-solrcloud-jepsen-flaky-networks/
- Jepsen vs. Elasticsearch – https://aphyr.com/posts/317-call-me-maybe-elasticsearch
- CAP Theorem – https://de.wikipedia.org/wiki/CAP-Theorem
