Lastenausgleich für Hochverfügbarkeit mit ThingWorx
Für eine ThingWorx Konfiguration mit Hochverfügbarkeit (High Availability, HA) sind ein oder zwei Lastenausgleichsmodule erforderlich.
• Ein Lastenausgleichsmodul für die Weiterleitung von Datenverkehr zu den ThingWorx Connection Servers. Das ist nur erforderlich, wenn ThingWorx Connection Servers Teil der Bereitstellung sind.
• Ein Lastenausgleichsmodul für die Weiterleitung von Datenverkehr zum ThingWorx Server, der der aktuelle Leader-Server ist. Dieses Lastenausgleichsmodul ist in allen ThingWorx HA-Konfigurationen erforderlich.
Allgemeine Anforderungen an den Lastenausgleich
• Das Lastenausgleichsmodul muss innerhalb seiner eigenen Hochverfügbarkeitskonfiguration funktionieren.
• Es kann Websocketverkehr weiterleiten.
• Es kann statische Sitzungen (oder "Sticky Sessions") verwalten.
• (optional) Es kann SSL-Beendigung verwalten.
Lastenausgleich für ThingWorx Connection Servers
Wenn ein Lastenausgleichsmodul für die Connection Servers erforderlich ist, muss es den gesamten ThingWorx Datenverkehr empfangen und basierend auf den folgenden Regeln verteilen:
• Das Lastenausgleichsmodul darf nur den Web Socket-Verkehr an die Connection Servers weiterleiten. Benutzerdatenverkehr und anderer Nicht-Websocketverkehr müssen an das andere Lastenausgleichsmodul geleitet werden, das Datenverkehr an den ThingWorx Leader weiterleitet.
• Um eine optimale Leistung zu erzielen, sollte der Web Socket-Verkehr von einem Asset immer unter Verwendung von Sticky Sessions an denselben Connection Server geleitet werden.
◦ Wenn dieser Connection Server offline geschaltet wird, sollte der Datenverkehr dieses Assets an einen anderen Connection Server weitergeleitet werden.
◦ Wenn die Sitzung zwischen Asset und Connection Server inaktiv wird, kann eine neue Sitzung mit einem verfügbaren Connection Server eingerichtet werden.
Lastenausgleich für ThingWorx Server
Der gesamte Datenverkehr zum ThingWorx Server (Benutzer, Asset, Connection Servers usw.) sollte über dieses Lastenausgleichsmodul geleitet werden, um sicherzustellen, dass er zum aktuellen ThingWorx Leader geleitet wird.
Das Lastenausgleichsmodul ruft in regelmäßigen Abständen einen Dienst auf jedem ThingWorx Server auf. Dieser Dienst antwortet mit seinem Leader-Status. Der ThingWorx Server, der den Leader-Code an das Lastenausgleichsmodul zurückgibt, empfängt Benutzer- und Asset-Datenverkehr. ThingWorx Server, die Standby-Code zurückgeben, sollten keinen Datenverkehr empfangen.
Jedes Lastenausgleichsmodul, das die folgenden Kriterien erfüllen kann, kann verwendet werden:
• Das Lastenausgleichsmodul kann die folgende GET-Anweisung in regelmäßigen Abständen an den ThingWorx Leader senden und auf die Antwort reagieren.
GET /Thingworx/Admin/HA/LeaderCheck
HTTP/1.0\r\nAuthorization:\ Basic\ <base64-encoded-string>
• Dabei ist <base64-encoded-string> eine Base64-codierte Benutzer:Passwort-Zeichenfolge, die mit dem Wert der LoadBalancerBase64EncodedCredentials-Einstellungen in platform-settings.json übereinstimmt.
• Das Lastenausgleichsmodul sollte diesen Aufruf alle 15-20 Sekunden an jeden ThingWorx Leader senden.
• Eine ordnungsgemäße Antwort vom ThingWorx Leader ist der Antwortcode 200.
◦ Während der Leader den Antwortcode 200 sendet, sollten die Standby-Server die Antwortcodes 400, 401 oder 503 zurückgeben.
• Wenn der Leader drei Antwortcodes sendet, die nicht dem Antwortcode 200 entsprechen, dann gilt Folgendes:
◦ Das Lastenausgleichsmodul muss ThingWorx Standby-Server auf den Antwortcode 200 überprüfen.
◦ Der Standby-Server, der jetzt den Antwortcode 200 sendet, ist als neuer ThingWorx Leader anzusehen.
◦ Der gesamte Datenverkehr ist an den neuen ThingWorx Leader zu leiten.
Jedes Lastenausgleichsmodul, das die obigen Anforderungen erfüllen kann, kann in der ThingWorx HA-Bereitstellung verwendet werden. Eine Beispielkonfiguration eines Lastenausgleichsmoduls finden Sie im
HAProxy-Beispiel. Das Beispiel basiert auf HAProxy (
http://www.haproxy.org).