OpenSearch¶

Siehe auch

Verwandte Artikel

Offizielle Dokumentation

Linuxfabrik

OpenSearch ist eine Open-Source-Such- und Analyse-Engine auf Basis von Apache Lucene. Sie speichert Daten als JSON-Dokumente, verteilt sie über ein Cluster und stellt eine REST-Schnittstelle für Indizierung und Suche bereit. OpenSearch entstand 2021 als Fork von Elasticsearch; Aufbau und API sind weitgehend deckungsgleich (siehe Vergleich zwischen OpenSearch und Elasticsearch).

Begriffe¶

Index: Sammlung an „Dokumenten“, wobei ein Dokument ein JSON-Objekt ist. Analogie zu Datenbanken: alle Studenten aus einer Tabelle. Zusätzlich definiert ein Index über das Mapping, wie Felder analysiert und gespeichert werden.
Shard: Ein Index wird in Häppchen (Shards) aufgeteilt und gleichmässig im Cluster verteilt. Shards dienen der Lastverteilung und ermöglichen die Parallelarbeit an Such- und Schreiboperationen. Ein Shard ist ein vollständiger Lucene-Index und belegt CPU- und RAM-Ressourcen. In der Regel sollte OpenSearch jedem Node die „Anzahl Shards im Index“ geteilt durch „Anzahl Nodes“ zuweisen. Shards sollten in der Praxis zwischen 10 und maximal 40 GB gross werden und nicht mehr als 200 Millionen Dokumente enthalten.
Shard Replica: Backup-Kopie für den Ausfall eines Nodes, dient zusätzlich dem Lastbalancing bei Suchanfragen.

Sharding / Shard Allocation:

OpenSearch platziert Replica Shards nach Möglichkeit auf andere Nodes als die zugehörigen Primary Shards. Sind alle Primaries zugewiesen, aber nicht alle Replicas, wird der Clusterstatus gelb.
Dokumente werden anhand eines Routing-Algorithmus auf die Shards verteilt: shard_number = hash(id) % number_of_shards. So landen identische Routing-Werte immer im selben Primary Shard.
Die Anzahl der Primary Shards (index.number_of_shards) wird bei der Indexerstellung festgelegt und kann später nicht geändert werden, da die Dokumente sonst im falschen Shard gesucht bzw. abgelegt würden. Anpassungen erfordern einen neuen Index (z.B. per Reindex).
Die Anzahl der Replica (index.number_of_replicas) lässt sich dagegen zur Laufzeit pro Index ändern.
Falls mehrere Nodes gleichzeitig ausfallen könnten (z.B. weil sie auf dem gleichen Hypervisor oder im gleichen Rechenzentrum laufen), sollten sie in Zonen gruppiert werden. Diese werden dann bei der Shard Allocation berücksichtigt.

Berechnung des Speichervolumens:

Diskgrösse im Cluster ist ungefähr Tagesvolumen_GB × Retention_Tage × Replikationsfaktor × Overhead
Beispiel mit 50 GB/Tag, 90 Tage Retention Time, number_of_replicas: 1 und 3 Nodes:
- Rohdaten: 50 GB/Tag × 90 Tage = 4500 GB
- Replikationsfaktor bei number_of_replicas: 1 ist ungefähr 2.0 (Primary + Replica)
- Overhead (Index-Struktur, Segment-Metadaten, Lösch-Markierungen, ISM usw.) ist ungefähr 1.1 bis 1.3
- Ergibt ca. 10 TB Daten für den gesamten Cluster
- Verteilt auf 3 Nodes: ungefähr je 3.3 TB Netto-Daten pro Node
- Da Platten typischerweise nicht über 70 bis 75 % vollgeschrieben werden sollten, ergeben sich in der Praxis 4 bis 6 TB nutzbare Disk pro Node.

Vergleich zwischen OpenSearch und Elasticsearch¶

OpenSearch erschien 2021 unter der Apache License 2.0 als Fork von Elasticsearch 7.10.2. Die Entwicklung wird von Amazon AWS angeführt. OpenSearch und Elasticsearch entwickeln sich seit dem Fork auseinander. Software-Produkte wie Graylog unterstützen oft beide, verweisen dann aber auf explizit einzusetzende Versionen, um eine gewisse Kompatibilität sicherzustellen.

EOL-Dates:

Elasticsearch: https://endoflife.date/elasticsearch
OpenSearch: https://endoflife.date/opensearch

Features:

Da beide auf Lucene basieren, wird alles von der Indizierung und Zusammenführung von Dokumenten bis hin zu Ähnlichkeiten und Filter-Caches unterstützt. Aktualisieren beide auf neuere Lucene-Versionen, übernehmen beide dieselben Verbesserungen und Bugfixes. Neben Lucene gibt es gemeinsame Funktionen aus Elasticsearch 7.10.2, auf dem OpenSearch ursprünglich basiert. Da sich beide getrennt weiterentwickeln, wird immer mehr dieses Codes durch neue Entwicklungen ersetzt.
Funktionen wie Authentifizierung, Autorisierung, Indexverwaltung und Alarmierung waren in Elasticsearch proprietär, weshalb OpenSearch Open-Source-Alternativen implementiert hat. Während Elasticsearch über Index Lifecycle Management verfügt, bietet OpenSearch Index State Management. Im Grossen tun sie das Gleiche, der Unterschied liegt in den (sich häufiger ändernden) Details. Nicht alle Funktionen in Elasticsearch sind frei: Index Lifecycle Management ist kostenlos, Cross-Cluster Replication oder LDAP/OpenID/SAML-Authentication nicht (siehe Subscriptions Page). Funktionen, die in OpenSearch kostenlos enthalten sind, in Elasticsearch aber nicht: IP-Filtering, konfigurierbare Retention, Anomaly Detection, Tableau Connector, JDBC- und ODBC-Treiber sowie Machine-Learning-Features.
Beide bieten inzwischen unterschiedliche Funktionen. Elasticsearch hat Zeitreihendatenströme, OpenSearch hat die Segmentreplikation wieder eingeführt.
„Searchable Snapshots“ sind in Elasticsearch länger und in OpenSearch seit 2.7 produktiv: eine „Offline“-Suchfunktion, die die Hardware für ältere, selten abgerufene Daten erheblich reduziert. In Elasticsearch kostet das Feature, in OpenSearch ist es kostenlos.
Aktuelle Elastic-Komponenten wie Logstash, Beats und Client-Bibliotheken prüfen, ob das Ziel ein Elasticsearch ist, und verweigern die Zusammenarbeit mit OpenSearch. OpenSearch stellt sich dem mit dem Projekt Data Prepper entgegen.

Security:

OpenSearch bietet die gleichen Security-Features wie das Premium-Level von Elasticsearch, aber komplett frei. Das Security-Modul von OpenSearch wird vollständig offen entwickelt und beherrscht Active Directory und LDAP, SAML, OpenID, Zugriffskontrolle inklusive Maskierung und Sicherheit auf Feldebene, Audit-Protokolle und Verschlüsselung. Dazu kommt das Security Analytics Plugin, eine SIEM-Lösung speziell für OpenSearch.

Lizenz:

Die Elastic License ist nicht von der Open Source Initiative (OSI) zertifiziert und untersagt unter anderem den Einsatz als as-a-Service.
OpenSearch steht unter der Apache-Lizenz, dem kommerziellen Einsatz steht damit nichts im Weg.

Installation¶

OpenSearch 2.15.x (inkl. Pinning):

curl \
    --show-error \
    --location \
    --output /etc/yum.repos.d/opensearch-2.x.repo \
    https://artifacts.opensearch.org/releases/bundle/opensearch/2.x/opensearch-2.x.repo

export OPENSEARCH_INITIAL_ADMIN_PASSWORD=$(tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 32)
echo "Admin Password: $OPENSEARCH_INITIAL_ADMIN_PASSWORD"
dnf --assumeyes install opensearch-2.15.0

Bemerkung

Eine separate Java-Runtime ist nicht nötig, OpenSearch bringt sein JDK mit, siehe /usr/share/opensearch/jdk/bin/java -version.

Konfiguration¶

Mindestens die JVM-Options an die RAM-Grösse der Maschine anpassen (Faustregel: halber Arbeitsspeicher, maximal etwa 31 GB):

cp /etc/opensearch/jvm.options /etc/opensearch/jvm.options.d/z00-linuxfabrik.options

/etc/opensearch/jvm.options.d/z00-linuxfabrik.options¶

# update the Xms and Xmx settings with half of the installed system memory
-Xms3g
-Xmx3g

Cluster-Name anpassen, er muss unternehmensweit eindeutig sein: