Als Suchdienst werden zwei ähnliche Dienste unterstützt, die beide auf den selben Komponenten aufbauen und sich vor allem durch ihre Lizenzierung unterscheiden: Elasticsearch und Opensearch.

Elasticsearch & OpenSearch

Bis zur Version 7.10.2 ist Elastisearch unter der Apache Lizenz V2.0 frei verfügbar. Ab dieser Version hat der Hersteller Elasticsearch B.V. die Lizenzierung zu der nach eigenen Angaben ebenfalls freien Elastic-Lizenz geändert. Gleichzeitig haben einige Unternehmen (darunter Amazon) diese Version als Basis für die Entwicklung des weiter unter der Apache Lizenz V2.0 verfügbaren OpenSearch verwendet.

Elasticsearch wird auch als kostenpflichtiger Cloudservice angeboten und es gibt zu allen Versionen eine funktional erweiterte Version unter der Elastic-Lizenz. Diese Version ist unter anderem notwendig, wenn eine Authentifizierung gegen den Suchdienst benötigt wird. OpenSearch beinhaltet die Authentifizierung.

Wir haben Elasticsearch 7.0.2 bis 7.17.5 und 8.5.1 inklusive des Cloudservices sowie OpenSearch 1.0 bis 2.4.0 erfolgreich getestet

Produkt Lizenz Authentifizierung Verfügbar für Hosting möglich
Elasticsearch OSS 7.10.2 Apache V2.0 Authentifizierung nicht möglich Windows, MacOS, div Linux ja
Elasticsearch 7.10.2 Elastic Authentifizierung möglich Windows, MacOS, div. Linux nein
Elasticsearch > 7.10.2 Elastic Authentifizierung möglich Windows, MacOS, div. Linux nein
OpenSearch Apache V2.0 Authentifizierung möglich Windows, div. Linux, Docker ja

Wir empfehlen Elasticsearch OSS 7.10.2 oder OpenSearch.

Hinweise zur Installation und Konfiguration von Elasticsearch

  • Manche Elasticsearch Versionen stehen als MSI-Installer und als ZIP zur Verfügung. Die MSI hat in den Tests immer mal wieder Probleme mitgebracht, die ZIP war dabei zuverlässiger.
  • Elasticsearch ist eine Java Anwendung und benötigt ein konfiguriertes JAVA_HOME in den Systemumgebungsvariablen. Bis Version 7.10.x muss dafür die JAVA_HOME Variable verwendet werden, danach die ES_JAVA_HOME.
  • Wenn JAVA Probleme macht, dann mitgelieferte JDK aus dem Elasticsearch-Installationsordner verwenden.
  • Wenn beim Starten eine Fehlermeldung zu nicht ausreichendem Speicher auftaucht, kann dieser in der jvm.options aus dem Config-Unterordner mit „-Xms1g“ und „-Xmx1g“ auf ein GB reduziert werden. Diese Einstellung hat bei unseren Tests auch mit mehreren Anwengungs-Instanzen keine Probleme verursacht.
  • Der Datenpfad für ElasticSearch, kann mit „path.data: d:\daten“ in der „config/elasticsearch.yml” angepasst werden.
  • Sobald ElasticSearch sauber startet, sollte anstelle der exe-Datei der Dienst verwendet werden. Das geht im bin-Verzeichnis mit „elasticsearch-service install“. Danach über die Dienste in Windows den Dienst starten und auf Autostart stellen.
  • Unter der URL „http://127.0.0.1:9200” kann man prüfen, ob Elasticsearch läuft. Unter Chrome macht die Abfrage manchmal Probleme (zu lange Anfragelänge o.ä.), unter Firefox sollte es aber funktionieren. Es werden dann Clustername, Versionsstand und einige weitere Informationen ausgegeben.
  • Wenn der Elasticsearch-Server ein anderer ist, als der Webserver muss Intranetzugriff aktiviert werden. Dies geht in der „elasticsearch.yml” mit „network.host: [local, site]”. Bei Windows-Systemen mit eingerichteter Firewall muss zusätzlich noch der 9200er Port freigegeben werden.
  • ElasticSearch ist defaultmäßig auf 1000 Shards pro Node limitiert wobei pro Suchindex in BA 5 Shards verwendet werden. Bei mehreren BA Instanzen pro Node kann das Limit erreicht werden. In diesem Fall kann die Defaulteinstellung in ElasticSearch erhöht werden:
PUT _cluster/settings
{
   "persistent":{
      "cluster.max_shards_per_node": 3000
   }
}
  • Es kann sinnvoll sein, Kibana zu installieren: eine Oberfläche zum Ansehen der gespeicherten Daten oder für weitere Administrationsaufgaben. Diese ist hier beispielsweise für Elasticsearch 7.0.2 unter der selben Lizenz erhältlich: https://www.elastic.co/de/downloads/past-releases/kibana-oss-7-10-2 Achtung: die Lizenzierung von Kibana und Elasticsearch muss übereinstimmen.

Hinweise zur Anbindung

  • Die URL zum Suchdienst und ggf. notwendige Zugangsdaten sowie weitere Optionen werden in der Customer.Config hinterlegt. Die dazu relevanten Parameter beginnen mit BA:Search.
  • Auf der Service-Seite zur administrativen Übersicht gibt es eine Option zum Löschen von Suchindexen aus anderen Instanzen. Diese Funktion muss in Hosting-Umgebungen, bei denen mehrere Kunden dieselbe Suchdienst-Datenbank verwenden, per Customer.Config deaktiviert werden!
  • Das „Hitlimit” des Suchdienstes darf nicht geändert werden: Standardmäßig liefert Elasticsearch maximal 10.000 Treffer. Diese Option nennt sich „index.max_result_window” und darf auf keinen Fall verändert werden, da ansonsten die reibungslose Änderungsversorgung nicht mehr gegeben ist. Auch dann nicht, wenn es erst einmal so aussieht, als würde alles funktionieren.
  • Weitere Informationen zur Konfiguration der Suchindexe befinden sich hier.

Troubleshooting

  • Wenn die Elastic-Datenbank keinerlei Änderungen mehr annimmt aber lesend noch wunderbar funktioniert, ist sie vielleicht mangels Speicherplatz vorausschauend in den Nur-Lesemodus gewechselt. Eine entsprechende Fehlermeldung findet sich dann im Logfile. In diesem Fall zunächst erst einmal Speicher frei machen und mit folgendem Curl-Befehl wieder das Schreiben ermöglichen: curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_all/_settings -d "{""index.blocks.read_only_allow_delete"": null}". Danach sollten die Indizes sicherheitshalber neu aufgebaut werden, damit die Daten auch konsistent sind. Die Limits, wieviel freier Plattenspeicher notwendig ist, können wie hier beschrieben geändert werden: https://www.elastic.co/guide/en/elasticsearch/reference/7.10/modules-cluster.html#disk-based-shard-allocation
  • Arbeitet man mit großen Dateien kann es sein, dass Kibana eine Fehlermeldung ausgibt, dass die Grenze für Highlighting zu niedrig ist. Das kann man über die Devtools ändern, z.b. so: PUT /bacrm_indexname/_settings { "index" : { "highlight.max_analyzed_offset" : 2000000 } }. Das sollte aber nur getan werden, wenn es wirklich Probleme gibt. Wenn man gar nicht mit Kibana arbeitet, braucht man das auf keinen Fall.
  • Log-Trace: Es ist möglich, eine erweiterte Protokollierung für den Indexer zu aktivieren. Das sollte nur kurzzeitig passieren, da die Logdateien sehr schnell sehr groß werden können! Das Logging erfolgt dann in dem normalen Logfile aus dem AppDate\Logs Ordner. Dazu muss der Logger per CustomNLog.config auf trace gestellt werden:
<nlog><rules>
<logger name="*.IndexUpdateWorker" minlevel="Trace" writeTo="file"/>
<logger name="*.SearchHelper" minlevel="Trace" writeTo="file"/>
</rules></nlog>