BPC Cluster

Ein BPC Cluster besteht aus einem OpenSearch Cluster sowie einem Verbund von Karaf Installationen.

Illustration 1. BPC Cluster

Vorbereitungen

Auf den zur Verfügung stehenden Servern installieren Sie, nach der Installationsanleitung, die gewünschte Anzahl von OpenSearch Nodes und Karaf Instanzen welche den BPC Cluster bilden sollen. Der OpenSearch Cluster sollte aus mindestens 3 Nodes bestehen. Der Karaf Verbund sollte sich aus mindestens 2 Instanzen zusammensetzen.

OpenSearch Cluster

Folgend sind die notwendigen Einstellungen zu finden, um einen OpenSearch Cluster aufzusetzen. Änderungen an diesen Einstellungen benötigen einen Neustart der betroffenen Karaf und OpenSearch-Installationen.

Weitere Informationen zur Bildung eines OpenSearch Clusters können in der OpenSearch Dokumentation nachgelesen werden.

Bei einem OpenSearch Cluster muss, wenn die FS (Filesystem) Variante weiterhin als Backup Repository Typ verwendet werden soll, es sich beim Ziel-Verzeichnis (opensearch_data/bpc_backup) um ein Shared Filesystem handeln.

Fall dies nicht so einfach möglich sein sollte, könnte auch bei einer On-Premise-Installation S3 als Backup Repository Typ festgelegt werden, indem eine S3 kompatible Lösung wie MinIO installiert und verwendet wird. Siehe dazu MinIO als S3 Backup für OpenSearch verwenden.

Das zu verwendende Backup Repository wird über die Core Services Einstellung Core_BackupRepository festgelegt. Der Wert dieser Einstellung ist eins-zu-eins der Wert welcher von OpenSearch verwendet wird. Die Konfigurationsmöglichkeiten können in der OpenSearch Dokumentation nachgelesen werden.

OpenSearch-ClusterName

OpenSearch benutzt einen Cluster-Namen, um zusammengehörende Knoten zu identifizieren. Default bindet sich OpenSearch nur an lokale Netzwerkinterfaces, daher können sich auf unterschiedlichen Servern installierte Instanzen nicht sehen und daher ohne Komplikationen mit dem gleichen Cluster-Namen betrieben werden. Werden aber mehrere getrennte Instanzen auf einem Server betrieben oder werden tatsächlich die Listener bewusst an mehr als Localhost gebunden (bspw. um bewusst Cluster aufzubauen), die entstehenden Cluster sollen dann allerdings voneinander getrennt sein (bspw. mehrere Stages), müssen die Cluster-Namen umgestellt werden.

Erfolgt in der Datei <OS_Root>/config/opensearch.yml:

cluster.name: opensearch_virtimo

OpenSearch-NodeName

Den jeweiligen Nodes/Knoten im Cluster einen sprechenden Namen zu geben ist zwar optional aber empfehlenswert. Wenn kein Name gesetzt wird, dann weist OpenSearch einen maschinell erzeugten Namen zu, der die Überwachung und Fehlerbehebung des Knotens erschwert.

Erfolgt in der Datei <OS_Root>/config/opensearch.yml:

node.name=bpc-opensearch-node1

OpenSearch-NodeRoles

Den Nodes/Knoten im Cluster können unterschiedliche Rollen zugeordnet werden. Per Default bekommt ein Node alle Rollen: cluster_manager, data, ingest, remote_cluster_client

Wenn man viele Nodes (> 3) zur Verfügung hat, dann kann man zum Beispiel einen Node als Cluster Manager festlegen. Dieser speichert dann keine Daten und kann sich nur um das Management des Clusters kümmern.

Erfolgt in der Datei <OS_Root>/config/opensearch.yml:

node.name: bpc-opensearch-cluster_manager
node.roles: [ cluster_manager ]

Folgend ist die Voreinstellung:

node.roles=cluster_manager,data,ingest,remote_cluster_client

OpenSearch-NetworkInterface

Will man OpenSearch auf mehr als nur die lokalen Netzwerkinterfaces lauschen lassen, kann das ebenfalls in der Datei <OS_Root>/config/opensearch.yml konfiguriert werden (bspw. durch Setzen auf _global_):

network.host: _global_

Hier können IP-Adressen, Hostnamen oder spezielle Platzhalter gesetzt werden. Mögliche Spezial-Parameter hier sind:

_local_ → Nur lokale Interfaces
_[NetzwerkInterfaceName]_ → ein bestimmtes Netzwerkinterface wie eth0 → _[eth0]_
_site_ → Lokal zugewiesene Adressen des Hosts
_global_ → Global zugewiesene Adressen des Hosts

Auch eine Kombination davon ist möglich:

network.host: ["192.168.1.3", "unserbpchost.virtimo.net", "_[tun0]_"]

Wird unter network.host eine IP-Adresse gesetzt, dann muss man diese auch in karaf/etc/de.virtimo.bpc.core.cfg unter de.virtimo.bpc.core.opensearch.host gesetzt werden. "localhost" ist dann nicht mehr verfügbar.

OpenSearch-DiscoveryHosts

Damit es dann allerdings auch Kontakt mit anderen Cluster Nodes aufnimmt, muss mindestens ein anderer (besser alle anderen) Knoten bekannt gemacht werden.

Erfolgt in der Datei <OS_Root>/config/opensearch.yml:

discovery.seed_hosts: ["<opensearch-1>", "<opensearch-2>", "<opensearch-3>"]

OpenSearch-InitialClusterManagerNode

Initial muss ein Cluster Manager Node festgelegt werden:

Erfolgt in der Datei <OS_Root>/config/opensearch.yml:

cluster.initial_cluster_manager_nodes: ["bpc-opensearch-node1"]

Firewall

ist eine Firewall im Einsatz, dann müssen mind. folgende Verbindungen offen sein.

Karaf → OpenSearch : HTTP Port (opensearch/config/opensearch.yml | http.port)
Karaf → OpenSearch : WebSocket Port (opensearch/config/opensearch.yml | os-bpc-plugin.websocket.port)
OpenSearch → OpenSearch : Transport Port (opensearch/config/opensearch.yml | transport.tcp.port)

Karaf Verbund

Bei jedem Karaf hinterlegen Sie in der BPC Konfigurationsdatei über die Option de.virtimo.bpc.core.opensearch.hosts Kommata getrennt die URLs der einzelnen Nodes des OpenSearch Clusters. Dadurch sind alle Nodes bekannt und es gibt keine Probleme, wenn einer mal nicht erreichbar sein sollte.

Keywords: