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

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 - 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 - 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.
SHI - Beratung  Entwicklung  Consulting
SHI - Beratung Entwicklung Consulting
Wir beraten und unterstützen Sie mit Schulungen, Trainings und Consulting. Von der Strategieberatung bis zur Anwendungsentwicklung helfen wir Ihnen bei der Optimierung Ihrer
Geschäftsprozesse.

Universal AJAX Live Search

Veröffentlicht am 26.10.2017 von Patricia Kaufmann

Die SolrCloud bietet eine Reihe von Mechanismen, um die Ausfallsicherheit des Clusters zu erhöhen. Dazu gehört zum einen die Verteilung der indexierten Daten auf mehrere Solr-Knoten und zum anderen das Management des Clusters durch ZooKeeper. Vor Allem aber die Möglichkeit, Indexe auf andere Knoten zu replizieren, schützt vor Fehlern und Nicht-Erreichbarkeiten der Daten bei einem Ausfall. Sollte einer der Solr-Knoten ausfallen, ist durch die Replikation sichergestellt, dass die bereits indexierten Daten weiterhin durchsuchbar sind und neue Indexierungsanfragen wie gewohnt angenommen werden können. Auf diese Weise können n-1 Ausfälle (wobei n die Anzahl an Repliken einer Shard sei) von der SolrCloud verschmerzt und aufgefangen werden. Das neueste Solr-Release 7.1.0 bietet darüber hinaus nun die Möglichkeit, Ausfälle nicht nur zu tolerieren, sondern weggebrochene Repliken automatisch zu ersetzen.

Das Setup

Stellen wir uns folgendes Szenario vor:

In unserer SolrCloud befinden sich drei Solr-Knoten (host1:8983_solr, host2:8983_solr, host3:8983_solr) auf drei verschiedenen physischen Servern.

Es existiert eine Collection mit einer Shard, die auf zwei Solr-Knoten (host1:8983_solr und host2:8983_solr) repliziert ist. Das Anlegen einer solchen Collection könnte über den folgenden API-Aufruf geschehen sein:

http://host1:8983/solr/admin/collections?action=CREATE&name=testcollection&numShards=1 &replicationFactor=2

Der Ausfall

Durch einen Stromausfall in dem Gebäude, in dem Server host2 beheimatet ist, fällt der Server – und damit der Solr-Knoten host2:8983_solr – aus. Der Ausfall hat vorerst keine fehlerproduzierenden Auswirkungen, da sowohl alle Indexierungsprozesse als auch alle Suchanfragen weiterhin korrekt abgearbeitet werden. Dennoch beeinflusst der Ausfall die Antwortzeiten auf Suchanfragen negativ, da nunmehr lediglich einer statt zwei Solr-Knoten die hohe Anzahl an Suchanfragen an die eine Shard der Collection bearbeiten kann. Da wir eine Solr-Version vor 7.1.0 für die SolrCloud verwenden, müssen wir entweder die verschlechterte Performanz akzeptieren oder eigene Mechanismen einbauen, welche die nicht mehr erreichbaren Indexe auf intakte Solr-Knoten replizieren.

Wäre es nicht angenehmer, wenn sich das System selbst um diese Replikation kümmern würde, sodass ein Ausfall beinahe unbemerkt an uns vorüberzieht? Diese Frage haben sich die Entwickler der Suchmaschine offenbar auch gestellt und in die Version 7.1.0 einen Mechanismus integriert, der genau solche Szenarien automatisch abfängt und so für noch mehr Ausfallsicherheit sorgt.

Der Einfall

Ab Solr 7.1.0 steht nun allen Solr-Anwendern der zusätzliche Parameter autoAddReplicas zur Verfügung, welcher vorher exklusiv HDFS-Nutzern vorbehalten war. Dieses Feature und der damit verbundene Trigger-Mechanismus sorgen nun für automatisches Replizieren, sobald ein Solr-Knoten aus dem Cluster fällt. Lediglich zwei Schritte sind notwendig, um diese mächtige Funktionalität zu nutzen:

1) Beim Anlegen einer Collection muss der Parameter replicationFactor gesetzt werden. Dieser gibt die minimale Anzahl an Repliken an, die für eine Shard der Collection aktiv sein sollen. Sinkt die Anzahl unter den Wert von replicationFactor, so sorgt der neue autoAddReplicas-Mechanismus für die Erzeugung neuer Repliken.

2) Der Parameter autoAddReplicas muss für die Collection aktiviert werden. Die Aktivierung kann über die Collections-API durchgeführt werden:

http://host1:8983/solr/admin/collections?action=MODIFYCOLLECTION &collection=testcollection&autoAddReplicas=true

Was nun bei einem Ausfall von host2:8983_solr passiert, kann über den SolrCloud-Graphen auf der Administrationsseite verfolgt werden:

solr7 autoAddReplicas

① Verteilung der Repliken vor dem Ausfall auf host1 und host2

② Ausfall von host2

③ Automatisches Hinzufügen einer Replica auf host3

④ Inbetriebnahme von Replica auf host3 und Löschen der Replica auf host2

Das Fazit

Mit der neuen Möglichkeit autoAddReplicas kann die SolrCloud noch stärker und automatisierter vor dem Ausfall eines Solr-Servers geschützt werden. Das Feature bietet damit zusätzlichen Schutz vor Nicht-Erreichbarkeit der Daten und Performanz-Verlusten.

Falls diese Funktionalität für Sie interessant ist oder Sie aus anderen Gründen über eine Migration auf Version 7.1.0 nachdenken, kontaktieren Sie uns gerne, um das Thema detaillierter zu besprechen.

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