Netzwerk
Es wird die zentrale Port-Konfiguration über bpc.env.sh empfohlen.
|
TL;DR opensearch/config/opensearch.yml http.port: 19200 transport.tcp.port: 19300 os-bpc-plugin.websocket.port: 19203 de.virtimo.bpc.core.cfg de.virtimo.bpc.core.opensearch.port = 19200 karaf/etc/org.apache.karaf.shell.cfg sshPort = 18101 org.apache.karaf.management.cfg rmiRegistryPort = 11099 rmiServerPort = 14444 org.ops4j.pax.web.cfg org.osgi.service.http.port = 18181 org.osgi.service.http.port.secure = 18282 |
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
Anschließend müssen natürlich beide Dienste neu gestartet werden.
OpenSearch Cluster
Will man OpenSearch auf mehr als nur die lokalen Netzwerkinterfaces lauschen lassen, kann das ebenfalls in der Datei <ES_Root>/config/opensearch.yml konfiguriert werden (bspw. durch Setzen auf global):
network.host: local
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]_"]
Damit es dann allerdings auch Kontakt mit anderen Cluster Nodes aufnimmt, muss mindestens ein anderer (besser alle anderen) Knoten bekannt gemacht werden. Auch dies findet in dieser Konfigurationsdatei mit folgendem Parameter statt (Default guckt er auch hier nur lokal):
discovery.zen.ping.unicast.hosts: ["127.0.0.1", "[::1]"]
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. Auch dies muss sowohl im OpenSearch als auch im Karaf erfolgen.
|
OpenSearch organisiert seine Dateien für den jeweiligen Cache lokal auch bereits mit dem ClusterNamen in der Ordnerstruktur. Ggf. bereits vorhandene Daten gehen damit verloren - es sei denn, man schiebt die Cluster-Daten ebenfalls noch um (siehe unten). Sauberer ist es aber, den Cluster vor dem Befüllen umzubenennen. |
Im OpenSearch erfolgt dies ebenfalls in der Datei <ES_Root>/config/opensearch.yml:
cluster.name: opensearch_virtimo
Wenn schon Daten im Cluster liegen, sind diese (bei heruntergefahrenem OpenSearch) noch zu verschieben:
cd <OS_Root>/data/ mv <AlterClusterName> <NeuerClusterName> #bspw. mv opensearch_virtimo opensearch_virtimo_instance2
Auch diese Anpassungen benötigt natürlich einen Neustart beider Dienste.
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 = 2099 rmiServerPort = 54444
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
