Problembehandlung für HA Clustering
Anwendungsschlüssel ist auf jedem Server vorhanden, aber der Wert ist leer
Dieses Problem tritt auf, wenn der Verschlüsselungsschlüssel auf jedem Server unterschiedlich ist. Dies kann passieren, wenn der Keystore nicht ordnungsgemäß geteilt wird.
Sie können die Dateien keystore-password und
keystore.pfx unter Verwendung des
Sicherheitsmanagement-Tools konfigurieren. Das Verzeichnis
ThingworxStorage sollte anschließend von allen Plattforminstanzen gemeinsam genutzt werden.
Ist dies nicht möglich, so müssen Sie einen Server starten, um die keystore-password- und die keystore.pfx-Datei zu erstellen, und diese dann auf den anderen Rechner kopieren, bevor Sie ihn starten.
1. Starten Sie einen Server, um die Dateien /ThingworxPlatform/keystore-password und /ThingworxStorage/keystore.pfx zu erstellen.
2. Kopieren Sie diese Dateien auf den anderen Server, und starten Sie dann den anderen Server.
Auf Server A erstelltes Ding ist nicht auf Server B vorhanden
Hochverfügbarkeit (High Availability, HA) wird realisiert, indem das Modell über die Datenbank synchronisiert wird. Diese Synchronisation erfolgt etwa alle 100 Millisekunden, das Intervall kann jedoch konfiguriert werden. Alle Server müssen auf dieselbe PostgreSQL-Datenbankinstanz verweisen. Überprüfen Sie daher die Datenbankkonfiguration in den Plattformeinstellungen, um sicherzustellen, dass die Verbindungseinstellungen übereinstimmen. Wenn Sie PostgreSQL in einem HA-Cluster ausführen möchten, müssen Sie der PostgreSQL-HA-Konfiguration folgen, indem Sie pgpool-II und eine primäre/sekundäre PostgreSQL-Konfiguration verwenden.
Eigenschaftswerte werden nicht auf allen Servern festgelegt
Wenn Sie einen Eigenschaftswert im Arbeitsspeicher auf Server A festlegen und der Wert auf Server B nicht aktualisiert wird, ist die Cache-Ebene, die den Status enthält, nicht ordnungsgemäß konfiguriert. ThingWorx speichert Eigenschaftsstatus im Apache Ignite-Cache, der eingebettet oder verteilt ausgeführt werden kann. Ein Topologieprotokoll wird in das Anwendungsprotokoll und in Ignite-Protokolle geschrieben, die die Anzahl der Clients und Server im Cluster anzeigen. Sie sollten überprüfen, ob diese protokollierte Anzahl von Servern mit der erwarteten Anzahl von Servern übereinstimmt. Wenn die Server nicht miteinander kommunizieren können, was auf Firewalls zurückzuführen sein kann, wird Ignite nur lokal ausgeführt.
Beispiel:
# log entry showing platform 1 has 2 clients and 1 server
platform1_1 | 13-Jan-2020 17:08:53.231 INFO [disco-event-worker-#37%twx-core-server%] org.apache.ignite.logger.java.JavaLogger.info Topology snapshot [ver=5, locNode=0cab6e47, servers=1, clients=2, state=ACTIVE, CPUs=12, offheap=1.6GB, heap=9.9GB]
# log entry showing platform 2 has 2 clients and 1 server
platform2_1 | 13-Jan-2020 15:02:29.736 INFO [ForkJoinPool.commonPool-worker-1] org.apache.ignite.logger.java.JavaLogger.info Topology snapshot [ver=4, locNode=c7383c40, servers=1, clients=3, state=ACTIVE, CPUs=16, offheap=1.6GB, heap=14.0GB]
Server wird aufgrund von HTTP_PORT-Fehler nicht gestartet
Der HTTP_PORT, durch den externe Dienste eine Verbindung zu ThingWorx herstellen müssen, muss vor dem Serverstart definiert werden, um die Dienstermittlung zu implementieren. Dies ist der Port, der auf dem Apache Tomcat-Rechner verfügbar ist, auf dem die Plattform-Anwendung ausgeführt wird. Diese Umgebungsvariable muss für den Prozess verfügbar sein, der Tomcat ausführt. Sie können dies in der setEnv-Datei konfigurieren, oder Sie können die Dienstdefinition aktualisieren.
Tomcat-Dienstdefinition:
[Unit]
Description=Apache Tomcat Web Application Container
After=network.target
[Service]
Type=forking
PIDFile=/var/run/tomcat.pid
Environment=CATALINA_PID=/var/run/tomcat.pid
Environment=JAVA_HOME=/usr/lib/jvm/jdk1.8.0_191
Environment=HTTP_PORT=8080
Environment=CATALINA_HOME=/usr/share/tomcat9/9.0.26
Environment=CATALINA_BASE=/usr/share/tomcat9/9.0.26
ThingWorx Connection Server kann keine Verbindung zu ThingWorx herstellen, Authentifizierungsfehler werden ausgegeben
Sie müssen einen Anwendungsschlüssel auf dem ThingWorx Server erstellen und diesen Anwendungsschlüssel zur Konfiguration von ThingWorx Connection Server hinzufügen. Wenn dieser Schlüssel nicht vorhanden ist oder nicht übereinstimmt, löst der Verbindungsserver Authentifizierungsfehler aus, wenn versucht wird, Verbindungen zur Plattform herzustellen.
ThingWorx Connection Server kann keine ThingWorx Server finden
Wenn ThingWorx Connection Server keine Verbindung zur Plattform herstellt, stellen Sie sicher, dass die auf dem ThingWorx Server gespeicherte Umgebungsvariable HTTP_PORT auf den Port festgelegt ist, auf dem die Plattform ausgeführt wird und dass der Dienstname mit der Konfiguration für ThingWorx übereinstimmt. Wenn einer der Werte falsch ist, findet der Verbindungsserver die ThingWorx Server nicht.
Außerdem könnte der ThingWorx Server eine ungültige Adresse bei Apache ZooKeeper registriert haben. Dies kann passieren, wenn der ThingWorx Server versucht, die IP-Adresse des Rechners zu bestimmen, auf dem ZooKeeper ausgeführt wird. Der Adressenauflöser scannt alle IP-Adressen auf allen Netzwerkschnittstellen auf dem Hostrechner, um die IP-Adresse zu bestimmen, die höchstwahrscheinlich die LAN-Adresse des Rechners ist. Wenn der Rechner mehrere IP-Adressen hat, bevorzugt diese Methode eine standortlokale IP-Adresse, sofern der Rechner über eine solche verfügt (z.B. 192.168.x.x oder 10.10.x.x, normalerweise IPv4), und gibt die erste standortlokale Adresse zurück, wenn der Rechner mehr als eine hat. Hat der Rechner keine standortlokale Adresse, gibt diese Methode die erste gefundene Nicht-Loopback-Adresse (IPv4 oder IPv6) zurück.
Probleme mit der Anwendungsleistung
In einer Cluster-Umgebung hat die Art und Weise, wie eine Anwendung geschrieben wird, größere Auswirkungen auf die Leistung, da die Dingdaten verteilt werden. Es ist wichtig, Roundtrips außerhalb des Servers, auf dem Skripts ausgeführt werden, zu reduzieren. Weitere Informationen finden Sie unter
Optimale Vorgehensweisen für HA-Anwendungen.
Cache-Anbieter wird nicht gestartet
Wenn der Apache Ignite-Cache-Anbieter nicht gestartet wird, kann ein Problem mit der Konfiguration vorliegen. Beispiel:
platform1_1 | 2020-07-13 17:34:14.965+0000 [L: ERROR] [O: E.c.q.l.c.Logger] [I: ] [U: SuperUser] [S: ] [P: platform1] [T: main] *** CRITICAL ERROR ON STARTUP: Failed to start CacheProvider com.thingworx.cache.ignite.IgniteCacheProvider
Es wird empfohlen, die ZooKeeper-Knoten zu prüfen, um sicherzustellen, dass ZooKeeper ordnungsgemäß ausgeführt wird, und zu verifizieren, ob der lokale Knoten auf den ZooKeeper-Server auf dem konfigurierten Port zugreifen kann.
Wenn ZooKeeper in Ordnung ist, überprüfen Sie den Ignite-Cluster, um festzustellen, ob er ordnungsgemäß ausgeführt wird. Prüfen Sie das Protokoll auf Probleme und den Topologie-Schnappschuss, um sicherzustellen, dass der Cluster die richtige Größe hat. Verifizieren Sie, ob der lokale Knoten auf den Ignite-Host auf allen erforderlichen Ports zugreifen kann.
Apache Ignite-Konnektivitätsprobleme
Wenn Ignite Probleme mit einem Verbindungs-Timeout, der Client-Konnektivität oder der Netzwerklatenz hat, aktivieren Sie die folgenden erweiterten Ignite-Konfigurationen unter den
cache-Einstellungen in der Datei
platform-settings.json. In der
Ignite-Dokumentation finden Sie Informationen dazu, wie Sie die einzelnen Werte konfigurieren. Weitere Informationen zur Datei
platform-settings.json finden Sie unter
Plattformeinstellungen für ThingWorx HA.
# This failure timeout automatically controls the following parameters: getSocketTimeout(), getAckTimeout(), getMaxAckTimeout(), getReconnectCount().
# If any of those parameters is set explicitly, the failure timeout setting will be ignored. For example, for stable low-latency networks the
# failure detection timeout may be set to ~120 ms.
failure-detection-timeout = 10000
client-failure-detection-timeout = 30000
# should only be used for advanced configuration
tcp-communication-spi {
connection-timeout = 5000
socket-write-timeout = 2000
slow-client-queue-limit = 0
}
# should only be used for advanced configuration
tcp-discovery-spi {
socket-timeout = 5000
ack-timeout = 5000
join-timeout = 5000
network-timeout = 5000
connection-recovery-timeout = 5000
reconnect-count = 10
reconnect-delay = 2000
so-linger = 5
stats-print-frequency = 0
}
Hängende Sperren in Modellanbietern
Die Modellsynchronisierung verwendet Datenbanksperren, um Konsistenz im Änderungsprotokoll zu gewährleisten. Eine hängende Sperre kann das gesamte System lahmlegen, zumindest bei Modelländerungen. Wenn Sie auf hängende Sperren stoßen, haben Sie folgende Möglichkeiten:
• In PostgreSQL
Zum Beispiel:
SET lock_timeout = 3000
b. Versuchen Sie, die Tabellensperre abzurufen.
c. Wenn der Server die Sperre aufgrund des Sperren-Timeouts nicht abrufen kann, bestimmen Sie das Alter der vorhandenen Sperre mithilfe der folgenden Abfrage:
select extract(epoch from (now() - query_start)) from pg_stat_activity where query like '%lock <tableName> in exclusive mode;'
d. Wenn das Alter der Sperre oberhalb des festgelegten Schwellenwerts liegt, führen Sie die folgende Abfrage aus, um den Prozess zu suchen, der die Sperre für eine bestimmte Tabelle beinhaltet:
e. Beenden Sie den Prozess, der die Sperre beinhaltet, mit dem folgenden Befehl:
SELECT pg_terminate_backend(pid);
• In MS SQL:
Zum Beispiel:
set lock_timeout 3000;
b. Versuchen Sie, die Tabellensperre abzurufen.
c. Wenn der Server die Sperre aufgrund des Sperren-Timeouts nicht abrufen kann, führen Sie die folgende Abfrage aus, um den Prozess zu suchen, der die Sperre für eine gegebene Tabelle enthält:
d. Bestimmen Sie das Alter der vorhandenen Sperre mithilfe der folgenden Abfrage, indem Sie die im vorherigen Schritt abgerufene session_id übergeben:
select datediff(second, (select last_batch from master.dbo.sysprocesses where spid = <session_id>), CURRENT_TIMESTAMP)
e. Wenn das Alter der Sperre oberhalb des festgelegten Schwellenwerts liegt, verwenden Sie die session_id aus dem vorherigen Abfrageergebnis, um den Prozess, der die Sperre enthält, mit dem folgenden Befehl zu beenden:
kill <sessionId>;
EnsembleTracker-Fehler
Wenn im Anwendungsprotokoll Fehler wie der folgende ausgegeben werden, selbst wenn die ZooKeeper-Server aktiv sind und ausgeführt werden, kann das Problem darin liegen, dass das Apache Curator-Framework eine Konfigurationsänderung nicht verarbeiten kann.
2021-03-22 06:35:10.092+0000 [L: ERROR] [O: o.a.c.f.i.EnsembleTracker] [I: ] [U: ] [S: ] [P: VTWSandboxSVA2] [T: main-EventThread] Invalid config event received: {server.2=52.149.229.159:2888:3888:participant, server.1=0.0.0.0:2888:3888:participant, server.3=13.92.154.53:2888:3888:participant, version=0}
Die Lösung besteht darin, die Konfiguration für die Serverzuordnungen in zoo.cfg so zu ändern, dass sie den Client-Port einschließt.
Die folgende Konfiguration kann einen Fehler verursachen:
server.1= xx.xxx.x.xx:2888:3888
server.2= xx.xxx.x.xx:2888:3888
server.3= xx.xxx.x.xx:2888:3888
Aktualisieren Sie daher die Konfiguration wie folgt, um den Client-Port einzuschließen:
server.1= xx.xxx.x.xx:2888:3888;2181
server.2= xx.xxx.x.xx:2888:3888;2181
server.3= xx.xxx.x.xx:2888:3888;2181