SHI GmbH Augsburg - Ihr Starker Partner für Search & Big Data, Apache Solr, IT Commerce Lösungen

SHI - Beratung  Entwicklung  Consulting
SHI - Beratung Entwicklung Consulting
Wir beraten unterstützen Sie mit Schulungen, Trainings und Consulting. Von der Strategieberatung bis zur Anwendungsentwicklung helfen wir Ihnen bei der Optimierung Ihrer
Geschäftsprozesse.
SHI - Fast Forward to Success
SHI - Fast Forward to Success
Geschwindigkeit zählt. Bei den Kosten und bei den Erfolgsaussichten.
Bei uns sorgen professionelles Projektmanagement und modulare Entwicklung
für Ihren raschen und effizienten Software-Projekterfolg.
SHI - Support und Service
SHI - Support und Service
Wir sind Dienstleister aus Leidenschaft und verstehen unsere Kunden.
Nach dem Projekt ist vor dem Projekt und individuelle, persönliche
Betreuung stehen bei uns ganz weit oben.
SHI - Individuelle Anwendungen aus Software-Bausteinen
SHI - Individuelle Anwendungen aus Software-Bausteinen
Bei uns bekommen Sie weder Software von der Stange, noch unerprobte Eigenentwicklungen. Wir setzen auf bewährte Open-Source-Technologien und setzen Ihre individuelle Anwendung
aus passenden
Bausteinen zusammen.

Universal AJAX Live Search

Veröffentlicht am 09.02.2017 von Markus Klose


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.


Fazit

Die Cross Data Center Replication Funktionalität von Apache Solr löst das grundlegende Problem einer verteilten Architektur nicht wirklich. CDCR ermöglicht es nicht eine einzelne SolrCloud über mehrere Data Center zu konfigurieren und effizient (regional) zu durchsuchen.
Jedoch ist die Cross Data Center Replikation in bestimmten Situationen sehr hilfreich, wie beispielsweise im oben beschriebenen UseCase des Hot-Standby. CDCR kann auch genutzt werden, wenn nicht auf Real-Time der Daten geachtet werden muss. In diesem Fall kann CDCR kombiniert mit einem Load-Balancer eingesetzt werden, um Suchen performanter (regional) umzusetzen.


Weiterführende Links
•    Solr Wiki
•    Solr JIRA
•    Blog Yonik Seeley
•    Blog Sematex

SEARCH & BIG DATA, BERATUNG, SCHULUNG, ENTWICKLUNG, SUPPORT, PUBLISHER SOLUTIONS
MIT APACHE SOLR, LUCENE, ELASTICSEARCH, SMARTLOGIC SEMAPHORE, SHI INFOPILOT