Erwartete Verhaltensweisen, wenn Fehler auftreten
In diesem Abschnitt werden die Aktionen beschrieben, die in einer ThingWorx Konfiguration für Hochverfügbarkeit (ThingWorx HA-Konfiguration) auftreten, wenn sie auf einen Fehler einer oder mehrerer Komponenten reagiert.
ThingWorx Server-Fehler
ThingWorx Leader-Knoten fällt aus
Erfolgtes HA-Verfahren
1. ZooKeeper erhält keine Antwort vom Leader.
2. ZooKeeper wählt einen neuen Leader aus dem Pool der ThingWorx Standby-Server aus.
3. ZooKeeper benachrichtigt den Standby-Knoten, damit dieser zum Leader wird.
4. Der neue Leader stellt eine vollständige Verbindung zur Datenbank her und initialisiert das ThingWorx Modell.
5. Der neue Leader sendet eine Bestätigung an das Lastenausgleichsmodul, damit alle ThingWorx Anforderungen an ihn weitergeleitet werden.
6. Das Lastenausgleichsmodul leitet den gesamten ThingWorx Datenverkehr an den neuen Leader weiter.
Fehler beim Lastenausgleich
Aktionen und Ergebnisse hängen von der bereitgestellten Lastenausgleichs-HA-Lösung ab. Aktive Sitzungen dürfen nicht unterbrochen werden, wenn das Lastenausgleichsmodul die Kapazität hat, Sitzungsinhalte über alle Lastenausgleichsknoten hinweg zu teilen.
HAProxy-Serverfehler
Wenn der einzige HAProxy-Knoten ausfällt oder alle HAProxy-Knoten ausfallen, geschieht Folgendes:
• Auf den ThingWorx Leader kann weiterhin über dessen IP-Adresse zugegriffen werden, jedoch nicht über die IP-Adresse des HAProxy.
• Anfragen zu ThingWorx über HAProxy erreichen ThingWorx nicht.
Wenn einer von mehreren HAProxy-Knoten ausfällt, geschieht Folgendes:
• Vorhandene Benutzersitzungen werden in ThingWorx Composer erkannt, sobald der Sicherungs-HAProxy zum neuen Master wird. Benutzer sollten sich nicht erneut anmelden müssen.
• Mashups werden erst geladen, wenn der Sicherungs-HAProxy zum Master wird.
• Das Durchsuchen von Entitäten in Composer wird erst dann geladen, wenn der Sicherungs-HAProxy zum Master wird.
• Anfragen erreichen ThingWorx erst, wenn der Sicherungs-HAProxy zum Master wird.
ZooKeeper-Knotenfehler
Fehler bei einem ZooKeeper-Knoten
Wenn einer der drei ZooKeeper-Knoten ausfällt, geschieht Folgendes:
• Andere ZooKeeper-Knoten erkennen die ausbleibende Reaktion.
• Ein neuer ZooKeeper-Leader wird gewählt, wenn der ausgefallene Knoten der aktuelle Leader ist.
• Die ThingWorx Server sollten nicht beeinflusst werden. Sie bleiben aktiv und zugänglich.
Fehler bei zwei ZooKeeper-Knoten
• Ein ZooKeeper-Leader kann nicht gewählt werden, da aufgrund des ursprünglichen Setups mit drei Knoten erwartet wird, dass zwei Server zur Bildung eines Quorums verfügbar sind. Maximal zulässige Fehler = ceil(N/2) - 1
• Die verbleibende ZooKeeper-Instanz ist weder ein Leader noch ein Standby-Knoten.
• Der ThingWorx Leader wird heruntergefahren, da er nicht zwecks Wahl des Leaders mit ZooKeeper kommunizieren kann.
• Der ThingWorx Standby-Server versucht weiterhin, mit ZooKeeper zu kommunizieren, bis mindestens ein anderer ZooKeeper-Knoten wieder reagiert.
• Sobald zwei oder mehr ZooKeeper-Knoten wieder online sind, wird der ZooKeeper-Leader gewählt. Der ThingWorx Standby-Knoten wird erneut mit ZooKeeper verbunden und ist jetzt der neue Leader.
• Der vorherige ThingWorx Leader muss neu gestartet werden, damit er zum Standby-Knoten wird.
Fehler in ThingWorx und ZooKeeper
Wenn die Leader für ZooKeeper und ThingWorx ausfallen, geschieht Folgendes:
• Alle Bedingungen, die unter "Fehler bei einem ZooKeeper-Knoten" aufgeführt sind. Der neue ZooKeeper-Leader muss zuerst bestimmt werden, damit dieser dann den neuen ThingWorx Leader wählt.
• Alle Bedingungen, die unter "ThingWorx Leader-Knoten fällt aus" aufgeführt sind.
PostgreSQL-Fehler
Die Besprechung der PostgreSQL-Fehler basiert auf der folgenden Konfiguration:
• Drei PostgreSQL-Knoten (Writer, Reader und Standby)
• Verwendung der Streaming-Replikation zwischen PostgreSQL-Knoten
• Zwei pgpool-II-Knoten, die den Client-Zugriff auf PostgreSQL-Knoten und die PostgreSQL-Wiederherstellungsverfahren verwalten
Wenn ein PostgreSQL-Server ausfällt, erkennt der aktive pgpool-II-Knoten den Fehler und beendet die Weiterleitung von Anfragen an diesen Server. Benutzer- oder Gerätedaten, die zum Zeitpunkt des Fehlers gespeichert werden, gehen verloren, wenn die Informationen vor dem Fehler nicht bestätigt und an andere Knoten repliziert wurden.
Wenn der PostgreSQL-Masterknoten ausfällt (vorausgesetzt, Synchronisierungsknoten und potenzielle Knoten werden ausgeführt), geschieht Folgendes:
• Ein Failover zum Synchronisierungsknoten erfolgt über pgpool-II. Der potenzielle Knoten wird jetzt zum Synchronisierungsknoten des neuen Masterknotens. Schreibvorgänge in die Datenbank sind weiterhin möglich (wie das Erstellen neuer Entitäten und das Schreiben von Daten in BDWS).
• Wenn der ursprüngliche Master wieder zur Verfügung steht, müssen Sie die Umgebung manuell bereinigen und konfigurieren, um den ursprünglichen Master zu verwenden.
Wenn beide Standby-Knoten fehlschlagen (vorausgesetzt, der Masterknoten wird noch ausgeführt), geschieht Folgendes:
• Es tritt kein Failover auf, und der Masterknoten sollte 0 Knoten für die Replikation aufweisen.
• Composer ist weiterhin verfügbar. Entitäten werden geladen und können angezeigt, aber nicht gespeichert werden. Protokolle können angezeigt werden.
• Aktionen, die Schreibvorgänge in die Datenbank erfordern (wie das Erstellen und Speichern einer Entität, das Festlegen von Werten für persistente Eigenschaften und das Hinzufügen eines Stream-Eintrags), sind nicht erfolgreich, da PostgreSQL die Daten an einen Standby-Knoten replizieren muss.
Wenn der Masterknoten und der Standby-Synchronisierungsknoten fehlschlagen, geschieht Folgendes:
• Ein Failover auf den potenziellen Knoten erfolgt. Der potenzielle Knoten ist jetzt der Masterknoten mit 0 Knoten für die Replikation.
• Composer ist verfügbar. Entitäten werden geladen und können angezeigt, aber nicht gespeichert werden. Protokolle können angezeigt werden.
• Aktionen, die Schreibvorgänge in die Datenbank erfordern (wie das Erstellen und Speichern einer Entität, das Festlegen von Werten für persistente Eigenschaften und das Hinzufügen eines Stream-Eintrags), sind nicht erfolgreich, da die Schreibvorgänge hängen und schließlich fehlschlagen.
Wenn alle drei Knoten fehlschlagen, geschieht Folgendes:
• Es tritt kein Failover auf, da keine verfügbaren Knoten vorhanden sind.
• Composer hat keinen Zugriff auf die Datenbank. Daher sollten Entitäten nicht geladen werden. Die meisten Dienste funktionieren nicht. (Untersystemdienste wie Plattformuntersystem funktionieren möglicherweise noch.) Die Systemfunktionalität ist eingeschränkt. (Protokolle, Systemüberwachung und Mashups funktionieren möglicherweise.)
• Schreibvorgänge in die Datenbank und Lesevorgänge aus der Datenbank sind nicht möglich.
Fehler in ThingWorx und PostgreSQL
Wenn der ThingWorx Leader und der PostgreSQL-Master ausfallen, geschieht Folgendes:
• Die ThingWorx Standby-Instanz wird zum Leader, nachdem der ThingWorx Leader ausgefallen ist, und der Synchronisierungsknoten der PostgreSQL-Datenbank wird zum PostgreSQL-Masterknoten.
◦ Der potenzielle Knoten der PostgreSQL-Datenbank wird zum neuen Synchronisierungsknoten.
◦ ThingWorx Composer ist verfügbar, und Schreibvorgänge in die PostgreSQL-Datenbank sind möglich. (Entitäten können erstellt, bearbeitet und gelöscht und Daten hinzugefügt werden.)
• Wenn der ursprüngliche PostgreSQL-Masterknoten als Masterknoten zurückgesetzt werden muss, müssen Sie die PostgreSQL-Knoten und pgpool-II manuell bereinigen.
Ausfall des pgpool-II-Knotens
Ausfall des aktiven pgpool-II-Knotens
Wenn der aktive pgpool-II-Knoten ausfällt, wird dies von der Sicherung erkannt, die die Verarbeitung aller Anfragen an die PostgreSQL-Server übernimmt. Benutzer, die beim aktiven ThingWorx Server angemeldet sind, können Verzögerungen in Ihren Anwendungen erleben, und es kann zu einem Verlust von Benutzer- oder Gerätedaten kommen, die gerade gespeichert wurden, als der pgpool-II-Knoten ausgefallen ist.
Ausfall aller pgpool-II-Knoten
Wenn alle pgpool-II-Instanzen ausfallen, verliert ThingWorx den Zugriff auf den PostgreSQL-Inhalt, und die meisten Funktionen schlagen fehl. Einige eingeschränkte Funktionen stehen möglicherweise in den folgenden Bereichen zur Verfügung:
• Protokollierung – Das Anwendungsprotokoll wird möglicherweise weiterhin mit Fehlermeldungen aktualisiert.
• Systemüberwachung (z.B. MonitoringPlatformStats-Mashup)
• Mashups – Widgets, die nicht auf Diensten oder Daten aus der Datenbank basieren, funktionieren möglicherweise weiterhin.
• Eigenschaftswerte aus nicht persistenten Eigenschaften
• Dienste, die nicht mit der Datenbank verbunden sind
Ausfall von ThingWorx und pgpool-II
Wenn der ThingWorx Leader und die pgpool-II-Masterinstanzen gleichzeitig ausfallen, geschieht Folgendes:
• Der ThingWorx Leader verliert die Leader-Position, sodass einer der Standby-Knoten zum Leader wird.
• Der pgpool-II-Master verliert die virtuelle IP-Adresse. Einer der pgpool-II-Standby-Knoten wird zum Master, und die virtuelle IP-Adresse wird ihm erneut zugewiesen.
• Der ThingWorx Standby-Server versucht, sich vollständig mit der Datenbank zu verbinden. Dieser Vorgang ist erfolgreich, sobald der neue pgpool-Master eingerichtet wurde.
Ausfall von pgpool-II und PostgreSQL
Wenn PostgreSQL und pgpool-II ausfallen, geschieht Folgendes:
• Der PostgreSQL-Standby-Knoten wird zum Masterknoten.
• Der pgpool-II-Standby-Knoten wird zum Masterknoten, und die virtuelle IP-Adresse wird an ihn übertragen.
• Dienste sind während des Failovers für kurze Zeit nicht verfügbar.