Navigation:  Installation & Allgemeine Informationen > Installation & Konfiguration > WebOffice FTS-Index (Applikationsserver) > Installation von Solr Cloud >

Fachbegriffe

Previous pageReturn to chapter overviewNext page

1. SolrCloud Teminologie

 

Einer der verwirrendsten Aspekte der Solr-Terminologie ist der Unterschied zwischen collections, shards, replicas, cores, und config sets. Diese Begriffe haben eine spezifische Bedeutung in Bezug auf SolrCloud.

 

SolrCloud / Solr Cluster - Ein Cluster von Solr-Servern, der Fehlertoleranz und Hochverfügbarkeit vereint. Mehrere Solr-Knoten können als eine Einheit verwaltet werden. Die Orchestrierung des Clusters und die Synchronisation zwischen den einzelnen Knoten wird von Zookeeper übernommen.

 

Node - Eine JVM Instanz mit Solr.

 

Collection - Ein  logischer Index in einem SolrCloud-Cluster. Ist einem config set zugeordnet und besteht aus einem oder mehreren shards. Wenn die Anzahl der shards mehr als eins ist, handelt es sich um einen distributed Index. SolrCloud verweist darauf über den Namen der collection und hat keinen direkten Bezug zum Shards-Parameter, der normalerweise für die Distributed Search benötigt wird.

 

Configset - Ein Menge von zusammengehörigen Konfigurationsdateien, die für die ordnungsgemäße Funktion eines cores erforderlich sind. Jedes configset hat einen Namen. Es besteht mindestens aus einer solrconfig.xml (SolrConfigXml) und einer schema.xml (SchemaXml), kann aber basierend auf diesen beiden Dateien auch andere Dateien enthalten. Diese werden im Zookeeper gespeichert. Configsets können mit dem Befehl upconfig in der Commandline oder mit dem Startparameter bootstrap_confdir Solr hochgeladen oder aktualisiert werden.

 

Core - Dies ist eine laufende Instanz eines Lucene Index zusammen mit der gesamten Solr-Konfiguration. Mit mehreren Cores können Sie eine einzige Solr Instanz mit separaten Konfigurationen und Indizes - mit eigener Konfiguration und eigenem Schema für unterschiedliche Anwendungen einsetzen; haben aber dennoch den Komfort einer einheitlichen Administration. Einzelne Indizes sind ziemlich isoliert, aber Sie können sie als eine einzige Anwendung verwalten, ohne ihren Servlet-Container neu zu starten zu müssen.

Hinweis:  Die Konfiguration eines cores wird im Zookeeper gespeichert. Bei traditionellem (Single-Core) Solr bleibt die Konfiguration des cores im conf-Verzeichnis auf der Festplatte.

 

Leader - Die shard replica, welche über die leader election ausgewählt wurde. Elections können jederzeit stattfinden, aber normalerweise werden sie nur durch Ereignisse wie den Ausfall einer Solr-Instanz ausgelöst. Wenn Dokumente indiziert sind, leitet SolrCloud sie an den leader des shards weiter und der leader verteilt sie an alle shard replicas.

 

Replica - Eine Kopie eines shards. Jede replica existiert in Solr als ein core. Eine collection namens "test", die mit numShards=1 und einem replicationFactor auf zwei gesetzt wurde, hat genau zwei replicas, so dass es zwei cores gibt - jeder auf einer anderen Maschine (oder Solr-Instanz). Eine wird mit test_shard1_replica1 und die andere test_shard1_replica2 benannt. Einer von ihnen wird zum leader ausgewählt.

 

Shard - Ein logisches piece/Stück (oder slice) einer collection. Jedes shard besteht aus einem oder mehreren replicas. Eine elcetion wird durchgeführt, um festzustellen, welches replica der leader ist. Dieser Begriff ist auch in der untenstehenden Allgemeinen Liste enthalten, bezieht sich dort aber auf Solr cores. Das SolrCloud-Konzept eines shards ist eine logische Trennung.

 

Shards / Sharding - "Sharding" ist eine Skalierungstechnik, bei der eine collection in mehrere logische Teile aufgeteilt wird, welche als "shards" bezeichnet werden. Hintergrund ist, dass die Anzahl der Inhalte in einer collection dadurch vergrößert werden kann (auf einem single server).

Eingehende Abfragen werden auf jeden Shard in einer collection verteilt, welche dann mit zusammengefassten Ergebnissen retourniert werden.

 

Replication -Eine weitere verfügbare Technik ist die Erhöhung des "Replikationsfaktors" Ihrer collection.

Sie können Server mit zusätzlichen Kopien Ihrer Sammlung hinzufügen, um eine höhere gleichzeitige Abfragelast zu bewältigen, indem Sie

die Anfragen auf mehrere Maschinen verteilen.

 

Sharding und Replication schließen sich nicht gegenseitig aus und machen Solr zu einer extrem leistungsfähigen und skalierbaren Plattform.

 

Replication Modes - Bis Solr 7 war das SolrCloud model so konzipiert, dass jedes replica eine leader Position einnehmen konnte, wenn ein leader verloren ging. Dies ist für die meisten Anwender sehr effektiv und bietet ein zuverlässiges Failover bei Problemen im Cluster-Betrieb. In großen Clustern bedeutet dies einen hohen Aufwand, da alle Repliken immer synchron gehalten werden müssen.

Um zusätzliche Flexibilität zu bieten, wurden zwei neue Typen von replicas hinzugefügt: TLOG & PULL. Diese neuen Typen bieten Optionen, um replicas zu verwenden, welche nur mit dem Leader synchronisiert werden (indem Indexsegmente aus dem leader kopiert werden). Der TLOG Typ hat den zusätzlichen Vorteil, dass er ein Transaktionslog  führt, welches es ihm ermöglicht, sich zu recovern und bei Bedarf eine leader Position einzunehmen; der PULL-Typ hält kein Transaktionslog, kann also nicht zu einem leader werden.

Als Teil dieser Änderung wird die traditionelle Art der replicas nun NRT genannt. Wenn Sie nicht explizit eine Anzahl der TLOG- oder PULL-replicas definieren,  erstellt Solr standardmäßig NRT-replicas. Wenn dieses Option für ihr System geeignet ist, brauchen sie also nichts zu ändern.

 

 

2. ZooKeeper Cluster – Terminologie

Zookeeper - SolrCloud erfordert Zookeeper - ein eigenständiges Programm, das anderen Programmen hilft, einen funktionierenden Cluster am Laufen zu halten. Er kümmert sich um die Auswahl der leader. Obwohl Solr mit einem eingebetteten Zookeeper betrieben werden kann, wird empfohlen, es separat von Solr zu installieren.  Zookeeper kann auf der gleichen Hardware wie Solr laufen.

 

Zookeeper ensemble and quorum - Das ZooKeeper Service wird über eine Reihe von Hosts repliziert, die als Ensemble bezeichnet werden. Eine replizierte Gruppe von Servern in derselben Anwendung wird als Quorum bezeichnet. Alle Server im Quorum haben Kopien der gleichen Konfigurationsdatei. QuorumPeers bilden ein ZooKeeper-Ensemble. Zookeeper benötigt die "Mehrheit" -  es wird empfohlen, eine ungerade Anzahl von Maschinen/Servern zu verwenden. Zum Beispiel: Fünf Maschinen mit ZooKeeper könnnen den Ausfall von zwei Maschinen bewältigen.

Link: https://myjeeva.com/zookeeper-cluster-setup.html#performance-and-availability-considerations