Erwartete Verhaltensweisen, wenn Fehler auftreten
In diesem Thema werden die Aktionen beschrieben, die in einer ThingWorx Clustering-Konfiguration auftreten, wenn sie auf einen Fehler einer oder mehrerer Komponenten reagiert.
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.
ThingWorx Serverausfall
Wenn ein ThingWorx Server ausfällt, geschieht Folgendes:
• Der Server wird aus dem Lastenausgleich entfernt, da der Ping der Integritätsprüfung fehlschlägt. Der Zeitpunkt der Entfernung hängt von der Prüfungshäufigkeit ab.
• ZooKeeper erkennt, dass der Server ausgefallen ist, entfernt ihn aus der internen Diensterkennung und benachrichtigt Watcher, z.B. den Connection Server.
• Wenn der Server der Singleton-Server war, benachrichtigt ZooKeeper die anderen Server und wählt einen neuen Singleton-Server aus.
Clients, die mit dem Server verbunden sind, erhalten möglicherweise Fehler beim Switchover, werden dann jedoch erneut mit einem neuen Server verbunden.
Es ist möglich, dass Daten bei einem Serverausfall oder -absturz verloren gehen. In diesen Fällen erfolgt der Datenverlust in den Batch-Warteschlangen. Wenn der Server heruntergefahren wird, statt auszufallen, geschieht obiges durch die Deregistrierung des Servers. Die Batch-Warteschlangen werden bereinigt.
ThingWorx Platform Knoten sind ausgefallen
Solange sich mindestens eine Platform Variante in einem fehlerfreien Zustand befindet, können andere Knoten ohne Auswirkungen auf das System neu gestartet werden. Wenn allerdings alle Platform Knoten ausfallen oder fehlerhaft sind, wird der in Ignite gespeicherte Zustand inkonsistent. In diesem Fall ist es erforderlich, dass alle Platform Knoten und alle Ignite-Knoten vor dem Neustart angehalten werden.
1. Halten Sie alle Platform Knoten an.
2. Halten Sie alle Ignite-Knoten an.
3. Starten Sie alle Ignite-Knoten neu.
4. Starten Sie alle Platform Knoten neu.
Wenn Ignite nicht neu gestartet wird, sind Bind Maps und andere in Ignite gespeicherte Daten nicht korrekt und führen im Laufe der Zeit zu seltsamem Verhalten.
ZooKeeper-Ausfälle
Knotenausfall
Wenn einer der 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.
Ausfall mehrerer Knoten
Wenn mehrere Knoten ausfallen und ZooKeeper sein Quorum verliert, wird es in den schreibgeschützten Modus gesetzt und lehnt Änderungsanforderungen ab.
• 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 verbleibenden ZooKeeper-Instanzen sind weder Leader noch Standby.
• Alle Clients haben den Status SUSPENDED und schließlich LOST.
ThingWorx Server
• Die Zuweisung der Singleton-Rolle wird im Status SUSPENDED aufgehoben. Während dieser Zeit werden keine Zeitgeber oder Scheduler ausgeführt.
• Im Status LOST werden alle Knoten heruntergefahren.
• Wenn ZooKeeper vor dem System-Timeout wiederhergestellt wird, wird ein neuer Singleton gewählt und die Verarbeitung fortgesetzt.
Connection Server
• Wenn der Connection Server den Status LOST von ZooKeeper erhält, wird er heruntergefahren, da er den Status der ThingWorx Server nicht kennt.
Ignite
• Es wird davon ausgegangen, dass der ZooKeeper-Cluster immer für alle Knoten im Cluster sichtbar ist. Wenn ein Knoten von ZooKeeper getrennt wird, wird er heruntergefahren, und andere Knoten behandeln ihn als ausgefallen oder getrennt.
Ignite-Ausfälle
Die Auswirkung von Ignite-Ausfällen basiert auf der Datenreplikationsebene. Ignite sollte immer so konfiguriert werden, dass Daten auf mindestens zwei Knoten im Cluster gespeichert sind. Wenn also ein Knoten ausfällt, hat dies keine Auswirkungen auf das System.
Wenn mehrere Knoten ausfallen, ist Datenverlust möglich, der zu einem inkonsistenten Zustand des Systems führen kann. In diesem Fall empfehlen wir die vollständige Abschaltung von Ignite und ThingWorx. Anschließend können Sie Ignite und ThingWorx neu starten. Ignite ist der Anwendungsarbeitsspeicher. Wenn er ausfällt, kann das Verarbeitungsverhalten sehr inkonsistent sein.
Bei einem Totalausfall von Ignite, bei dem ThingWorx keine Verbindung zu Ignite-Knoten herstellen kann, wird ThingWorx heruntergefahren.
Informationen zu Datensicherungen finden Sie hier:
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.
• Das Verfahren und das Verhalten, die unter "ThingWorx Leader-Knoten fällt aus" aufgeführt sind, werden angewendet.
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.