Dieser Blog ist eine kurze Einführung in die CDCR (Cross Data Center Replication) Funktionalität von Solr. Es wird beschrieben, was CDCR ist, was CDCR nicht ist und wann man diese Funktionalität einsetzen kann.
Die SolrCloud ist nun schon seit einigen Jahren das Mittel der Wahl, wenn es um eine verteilte Architektur im Zusammenhang mit Apache Solr geht. Eine SolrCloud kann aus vielen einzelnen Solr Instanzen bestehen, die auch in unterschiedlichen Data Center installiert worden sind. Eine SolrCloud über mehrere Data Center hinweg zu installieren birgt jedoch einige Schwachstellen. Beispielsweise sind die Instanzen innerhalb eines Data Centers besser untereinander angebunden, als die Data Center untereinander. Dadurch kann es zu Latenzen bei der Suche bzw. Indexierung kommen, welches sich negativ auf die Performance auswirkt.
Um diesen Nachteil zu verhindern gibt es einige Lösungen bzw. Ansätze. Die SolrCloud Funktionalität CDCR (Cross Data Center Replikation) ist eine davon.
Was ist SolrCloud CDCR
Die SolrCloud CDCR Funktionalität ermöglicht die automatische Verteilung von Dokumenten über mehrere SolrCloud Installationen hinweg. Bei dieser Architektur gibt es zwei oder mehr SolrCloud Installationen, die unabhängig voneinander sind, d.h. sie haben jeweils ein eigenes ZooKeeper Ensemble für das SolrCloud Management.
Eine der SolrCloud Installationen ist besonders und übernimmt die Hauptrolle bei der Indexierung. Diese sogenannte „source“ SolrCloud leitet die zu indexierenden Dokumente an die anderen SolrClouds („target“) weiter. Diese Architektur erinnert etwas an klassische Master-Slave Architektur der Replikation, nur diesmal nicht auf Index-Ebene, sondern im größeren Rahmen.
Es gibt jedoch kein Polling Mechanismus der target-SolrClouds. Die Replikation der Dokumente geschieht asynchron und wird von „source“ SolrCloud an gesteuert. Somit sind die Daten der SolrClouds zeitgleich fast identisch (NRT) und können parallel durchsucht werden.
Was ist SolrCloud CDCR nicht
Die SolrCloud CDCR Funktionalität ermöglicht kein sogenanntes Standortbewusstsein (location awareness). Standortbewusstsein im Zusammenhang mit der SolrCloud würde bedeuten, zu wissen wo sich einzelne Shards (Indexe) befinden, d.h. zu wissen in welchem Data Center, in welcher Zone oder in welchem Rack der Index physisch abgelegt worden ist.
Dieses Wissen könnte genutzt werden, um Optimierungen bei der Indexierungs- bzw. Suchstrategie durchzuführen. Würde man beispielsweise wissen in welchem Data Center sich die einzelnen Solr Instanzen befinden könnte beim Erstellen einer Collection darauf geachtet werden, dass Replikas immer in mindestens zwei Data Center erstellt werden. Aktuell muss man dies jedoch noch manuell sicherstellen.
Funktionsweise der SolrCloud CDCR
Im Umgang mit den SolrCloud Instanzen muss man ein paar Kleinigkeiten beachten. Die Indexierung, dies beinhaltet auch das Aktualisieren bzw. das Löschen von bereits existierenden Dokumenten, geschieht in zwei Phasen. Die erste Phase ist das Standardverhalten innerhalb der SolrCloud. Alle Dokumente, die an die „source“ SolrCloud geschickt werden, werden innerhalb der SolrCloud an die entsprechende Collection bzw. Shard geroutet und sowohl im Leader, als auch auf allen Replikas indexiert. Erst wenn dies erfolgreich durchgeführt worden ist, wird das Dokument asynchron an die „target“ SolrCloud(s) verschickt, wo wiederum das Dokument im entsprechenden Leader und allen zugehörigen Replikas indexiert wird.
Grundlegend können alle SolrCloud Instanzen, die über die Cross Data Center Replikation miteinander verbunden sind, durchsucht werden. Es gibt hier jedoch kein automatisches Load-Balancing zwischen den einzelnen SolrCloud Instanzen. Dies kann man aber mit einem externen Load-Balancer nachkonfigurieren. Man muss hierbei aber berücksichtigen, dass die einzelnen SolrCloud Instanzen möglicherweise leicht unterschiedliche Indices haben, denn die sogenannten „target“ Collections hängen etwas hinterher.
UseCase – Hot-Standby / Failover
Viele Anwendungen bzw. Systeme sind unternehmenskritisch und ein Ausfall kann nicht nur zum Verlust von Reputation oder Geld führen sondern kann durchaus auch rechtliche Konsequenzen haben. Solche unternehmenskritische Anwendungen bzw. Systeme werden oft durch ein „Duplikat“ abgesichert. Ein solches Standby System ermöglicht einen reibungslosen Failover im Falle des Falles.
Im Zusammenhang mit der SolrCloud bedeutet dies, dass man zwei SolrClouds benötigt. Eine SolrCloud ist die aktive und wird ständig durchsucht und mit neuen Daten befüllt. Die zweite SolrCloud ist passiv und wird erst aktiv, wenn die erste ausfällt. Bei diesem aktiv-passiv Szenario wird die zweite SolrCloud Instanz permanent mit den gleichen Indexaktualisierungen versehen, ohne jedoch aktiv durchsucht zu werden. Ohne die permanente Aktualisierung würde im Fall des Failover ein veralteter Datenbestand durchsucht werden.
Eine verteilte Indexierung kann man natürlich auch über einen eigenen Indexer realisieren, der die Dokumente gleichzeitig an mehrere SolrCloud Instanzen schickt. Im Falle von Änderungen am Setup der SolrCloud Instanzen muss dann aber auch der Indexer geändert werden. In diesem Fall die Cross Data Center Replikation Funktionalität der SolrCloud perfekt geeignet. Der Indexer muss nur die Daten an die „source“ SolrCloud schicken und automatisch wird die zweite SolrCloud im anderen Data Center aktualisiert.
Dieses Szenario „Hot-Standby“ funktioniert natürlich auch, wenn beide SolrCloud Instanzen im gleichen Data Center installiert worden sind und kein Komplettausfall des Data Centers zu befürchten ist.
