Netzwerk
Es wird die zentrale Port-Konfiguration über bpc.env.sh empfohlen.
|
TL;DR opensearch/config/opensearch.yml http.port: 9200 transport.tcp.port: 9300 os-bpc-plugin.websocket.port: 9203 karaf/etc/de.virtimo.bpc.core.cfg de.virtimo.bpc.core.opensearch.port = 9200 karaf/etc/org.apache.karaf.shell.cfg sshPort = 8101 karaf/etc/org.apache.karaf.management.cfg rmiRegistryPort = 1099 rmiServerPort = 44444 karaf/etc/org.ops4j.pax.web.cfg org.osgi.service.http.port = 8181 org.osgi.service.http.port.secure = 8282 |
Um mehrere getrennte Instanzen auf einem Server zu betreiben, müssen diverse Parameter umgesetzt werden. Auch aus anderen Gründen (bereits belegte Ports, …), können diese Anpassungen nötig sein und sollen hier näher beschrieben werden.
Relevante Anpassungsparameter
Grundsätzlich sind folgende Parameter zu berücksichtigen:
-
OpenSearch-Ports (Default 9200-9300 und 9300-9400 Erläuterung siehe unten)
-
OpenSearch-ClusterID (Default opensearch_virtimo)
-
Karaf BPC-Instanz-Name (Default BPC)
-
Karaf-Ports für:
-
HTTP (Default 8181)
-
HTTPS (Default 8282)
-
SSH (Default 8101)
-
JMX/RMI-Port (Default 1099, 44444)
-
Anpassungsdetails
Unten stehende Karaf-Parameter können auch über die Karaf-Console gesetzt werden (Syntax: config:property-set -p de.virtimo.bpc.core CONFIGKEY CONFIGVALUE).
An dieser Stelle wird allerdings immer die Konfiguration via Konfigurationsdatei beschrieben, da diese auch "offline" durchgeführt und einfacher auf weitere Instanzen übernommen werden kann.
OpenSearch-Ports
Die OpenSearch-Ports müssen sowohl im OpenSearch als auch im Karaf angepasst werden, damit beide Produkte wieder miteinander kommunizieren können.
OpenSearch hat im Auslieferungszustand 2 Port Ranges definiert (9200-9300 und 9300-9400) und nimmt sich jeweils den niedrigsten nicht belegten Port. Dies sollte unbedingt geändert und auf einen festen Port definiert werden, da Karaf ohnehin nur genau einen Port abfragt und ansonsten möglicherweise unbewusst mehrere Instanzen des gleichen OpenSearch ausgeführt werden (und auch funktionieren, da sich jede neue Instanz einfach den nächsten Port schnappt und dann sagt "Hey Cluster, ich bin einer von Euch, sprecht mit mir").
OpenSearch selbst liest seine Port-Konfiguration aus der Datei <OS_Root>/config/opensearch.yml.
Es genügt daher, am Ende der Datei diese drei Werte mit den neuen Ports zu definieren:
http.port: 9200 transport.tcp.port: 9300 # Default: 9203 os-bpc-plugin.websocket.port: 9204
Damit Karaf OpenSearch dann auch unter dem neuen Port erreicht, muss dieser noch im BPC-Konfig-File <Karaf_Root>/etc/de.virtimo.bpc.core.cfg hinterlegt werden
(Wert des Parameters http.port aus der OpenSearch-Konfiguration):
de.virtimo.bpc.core.opensearch.port = 9200
|
Das BPC/Karaf stellt eine Websocket Verbindung zum OpenSearch her (Wert des Parameters os-bpc-plugin.websocket.port aus der OpenSearch-Konfiguration). Der Port muss im BPC nicht konfiguriert werden, da dieser zur Laufzeit vom OpenSearch abgefragt wird. |
Anschließend müssen natürlich beide Dienste neu gestartet werden.
OpenSearch Cluster
Folgend sind die notwendigen Einstellungen zu finden, um einen OpenSearch Cluster aufzusetzen. Änderungen an diesen Einstellungen benötigen einen Neustart beider Dienste.
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 |
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)
BPC-Instanz-Name
Das Session Cookie wird ohne Port-Information, also für einen Host unabhängig des verwendeten Ports, abgelegt (Dank RFC6265 "cookies for a given host are shared across all the ports on that host").
Das hat zur Folge, dass man eine Session über mehrere Instanzen hinweg versuchen würde zu verwenden.
BPC erkennt korrekterweise, dass es diese Session (einer anderen BPC-Instanz) nicht kennt und entsorgt sie.
Das hat zur Folge, dass man sich nicht auf mehreren Instanzen eines Hosts gleichzeitig anmelden könnte.
Inzwischen gibt es einen Instanznamen als Prefix für die Session-Informationen, damit können mehrere Sessions innerhalb eines Browsers für den gleichen Zielhost verwaltet werden.
Innerhalb der Datei <Karaf_Root>/etc/de.virtimo.bpc.core.cfg ist dazu folgender Key mit einem neuen Instanznamen zu setzen:
de.virtimo.bpc.core.name = BPC
Anschließend bitte den Karaf neu starten.
Karaf-Ports
Karaf benutzt zur Kommunikation unterschiedliche Protokolle und Ports. So stellt es unter anderem eine SSH-, eine HTTP- und eine HTTPS-Schnittstelle bereit. Auch eine JMX/RMI-Schnittstelle wird angeboten und sollte bei bereits belegten Ports angepasst werden.
Der Hinweis auf Neustart des Karaf nach jeglichen Portänderungen sollte an dieser Stelle obsolet sein.
SSH-Port
Karaf stellt unter Linux wie auch unter Windows eine SSH-Schnittstelle für Konfigurations- und Analyse-Zwecke zur Verfügung.
Diese ist per Default unter dem Port 8101 erreichbar.
Geändert werden kann dies in der Datei <Karaf_Root>/etc/org.apache.karaf.shell.cfg über folgendes Setting:
sshPort = 8101
Um zu verhindern, dass der Post auch nach außen erreichbar ist, kann man folgende option bspw. an Localhost oder ein anderes lokales Interface binden (0.0.0.0 = Global/alle IPv4-Adressen des Host):
sshHost = 0.0.0.0
HTTP(S)-Port
Die Ports für HTTP und HTTPS werden in der Datei <Karaf_Root>/etc/org.ops4j.pax.web.cfg festgelegt:
org.osgi.service.http.port = 8181 org.osgi.service.http.port.secure = 8282
Hier kann das jeweilige Protokoll auch separat aktiviert/deaktiviert werden (bspw. um nur HTTPS zu erlauben):
org.osgi.service.http.enabled = false org.osgi.service.http.secure.enabled = true
JMX/RMI-Ports
Die Ports für die JMX/RMI-Schnittstelle werden in der Datei <Karaf_Root>/etc/org.apache.karaf.management.cfg über folgende Parameter konfiguriert:
rmiRegistryPort = 1099 rmiServerPort = 44444
Um JMX/RMI nur lokal verfügbar zu machen, kann man (analog zu SSH) auch hier den Listener vom globalen 0.0.0.0 an irgendein lokales Interface (bspw. 127.0.0.1) binden:
rmiRegistryHost = 0.0.0.0 rmiServerHost = 0.0.0.0
