Netzwerk

Es wird die zentrale Port-Konfiguration über bpc.env.sh empfohlen.

TL;DR

elasticsearch/config/elasticsearch.yml

http.port: 19200
transport.tcp.port: 19300
es-bpc-plugin.websocket.port: 19203

de.virtimo.bpc.core.cfg

de.virtimo.bpc.core.es.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:

Elasticsearch-Ports (Default 9200-9300 und 9300-9400 Erläuterung siehe unten)
Elasticsearch-ClusterID (Default elasticsearch_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.

Elasticsearch-Ports

Die Elasticsearch-Ports müssen sowohl im Elasticsearch als auch im Karaf angepasst werden, damit beide Produkte wieder miteinander kommunizieren können.

Elasticsearch 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 Elasticsearch 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").

Elasticsearch selbst liest seine Port-Konfiguration aus der Datei <ES_Root>/config/elasticsearch.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
es-bpc-plugin.websocket.port: 9204

Damit Karaf Elasticsearch 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 ES-Konfiguration):

de.virtimo.bpc.core.es.port = 9200

Anschließend müssen natürlich beide Dienste neu gestartet werden.

Elasticsearch Cluster

Will man Elasticsearch auf mehr als nur die lokalen Netzwerkinterfaces lauschen lassen, kann das ebenfalls in der Datei <ES_Root>/config/elasticsearch.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]"]

Elasticsearch-ClusterName

Elasticsearch benutzt einen Cluster-Namen, um zusammengehörende Knoten zu identifizieren. Default bindet sich Elasticsearch 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 Elasticsearch als auch im Karaf erfolgen.

Elasticsearch 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 Elasticsearch erfolgt dies ebenfalls in der Datei <ES_Root>/config/elasticsearch.yml:

cluster.name: elasticsearch_virtimo

Im Karaf ist der neue vergebene Name in der Datei <Karaf_Root>/etc/de.virtimo.bpc.core.cfg zu pflegen:

de.virtimo.bpc.core.es.clustername = elasticsearch_virtimo

Wenn schon Daten im Cluster liegen, sind diese (bei herunter gefahrenem Elasticsearch) noch zu verschieben:

cd <ES_Root>/data/
mv <AlterClusterName> <NeuerClusterName>
#bspw. mv elasticsearch_virtimo elasticsearch_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

Keywords: