Hochverfügbarkeit mit ThingWorx
Übersicht über ThingWorx Hochverfügbarkeits-Clustering
Um die Dauer von Ausfällen für kritische IoT-Systeme zu reduzieren, können Sie ThingWorx für den Betrieb in einer High Availability-Umgebung (HA) im Clustermodus konfigurieren. Das Clustering bietet zusätzliche Skalierbarkeit und hohe Verfügbarkeit, vorausgesetzt, alle Komponenten sind ordnungsgemäß konfiguriert.
 |
HA-Clustering sollte nicht für eine Notfall-Wiederherstellung-Lösung verwendet werden.
|
|
|
Die Verwendung mehrerer Verfügbarkeitszonen für eine HA-Bereitstellung wird nicht unterstützt. Die Netzwerklatenz zwischen den Zonen kann für die ständige Kommunikation zwischen ThingWorx und Apache Ignite-Knoten zu groß sein.
|
In den folgenden Abschnitten werden die Einrichtung und Konfiguration einer Clustering-Umgebung sowie die Komponenten und Überlegungen für eine ThingWorx HA-Bereitstellung erläutert.
Alle HA-Bereitstellungen erfordern zusätzliche Ressourcen, wenn Sie mit einer Bereitstellung verglichen werden, die nur den Anforderungen an Funktionalität und Skalierung entsprechen soll. Diese zusätzlichen Ressourcen sind hardwarebasiert (wie Server, Datenträger, Lastenausgleichsmodule usw.) und softwarebasiert (wie Synchronisierungsdienste und Lastenausgleichsmodule). Die zusätzlichen Ressourcen werden konfiguriert, um sicherzustellen, dass innerhalb der HA-Bereitstellung keine einzelnen Fehlerstellen vorhanden sind.
Alle HA-Bereitstellungen sollten auf einer Dienstleistungsvereinbarung (Service Level Agreement, SLA) basieren, in der Sie die Betriebszeitanforderungen der Anwendung für Ihre Bereitstellung analysiert haben. Wie viele Stunden pro Monat kann das System beispielsweise offline sein? Ist das die zulässige Ausfallzeit für Systemausfälle, Anwendungs-Upgrades oder beides? Die Anzahl der zusätzlichen Ressourcen, die für ein HA-System erforderlich sind, hängt vom SLA ab, die es einhalten soll. Wenn der Umfang des SLA zunimmt, steigt in der Regel auch das Erfordernis, dass Ressourcen diese einhalten.
Begriffsglossar
• Hochverfügbarkeit
Systeme oder Komponenten, die für einen möglichst langen Zeitraum kontinuierlich in Betrieb sind.
• Skalierbarkeit
Möglichkeit, die Last zu erhöhen, die ein System durch Vergrößern des Arbeitsspeichers, der Festplatte oder der CPU oder durch Hinzufügen von Servern unterstützen kann.
• Cluster
Instanzen derselben Anwendung, die gleichzeitig funktionieren. Ein Cluster bietet hohe Verfügbarkeit und Skalierbarkeit.
• Singleton
Der Singleton-Server ist ein Server im Cluster, der Verhaltensweisen zwischen Clustern verarbeitet (beispielsweise Zeitgeber und Scheduler). Er stellt sicher, dass Aufgaben nur einmal innerhalb des Clusters ausgeführt werden.
• virtuelle IP-Adresse
IP-Adresse, die für eine Anwendung steht. Clients, die die virtuelle IP verwenden, werden normalerweise an ein Lastenausgleichsmodul weitergeleitet, das die Anforderung dann an den Server weiterleitet, auf dem die Anwendung ausgeführt wird.
• Lastenausgleichsmodul
Gerät, das Netzwerkverkehr empfängt und an die Anwendungen weiterleitet, die bereit sind, diesen anzunehmen.
• Failover
Backup-Betriebsmodus, in dem die Funktionen einer Systemkomponente (wie Prozessor, Server, Netzwerk oder Datenbank) von sekundären Systemkomponenten übernommen werden, wenn die primäre Komponente aufgrund eines Fehlers oder einer geplanten Ausfallzeit nicht verfügbar ist.
• letztendliche Konsistenz
Änderungen werden nach und nach auf alle Server in einer Cluster-Umgebung übertragen.Weitere Informationen finden Sie unter Letztendliche Konsistenz in ThingWorx HA.
• geteilter Status
Status, der von mehreren Servern im Cluster geteilt wird und garantiert identisch ist, unabhängig davon, welcher Server ihn betrachtet.Eigenschaftsdaten sind ein Beispiel eines geteilten Status, wobei der aktuelle Eigenschaftswert auf allen Servern gleich ist.
ThingWorx Referenzarchitektur für Hochverfügbarkeit
Die folgende Abbildung zeigt ThingWorx in einer Cluster-Konfiguration.
Die folgenden Komponenten können Teil einer Cluster-Bereitstellung sein:
• Benutzer und Geräte – Keine Rolle bei der HA-Funktionalität. Aus ihrer Perspektive ändert sich nichts. Sie verwenden immer dieselben URLs und dieselbe IP-Adresse, auch wenn sich der primäre ThingWorx Server geändert hat.
• Firewalls – Keine HA-Funktion und als optional anzusehen. Firewalls werden häufig platziert, um Sicherheitsanforderungen zu implementieren.
• Lastenausgleichsmodule – Lastenausgleichsmodule verwalten eine virtuelle IP-Adresse für die Anwendung, die sie unterstützen. Der gesamte Datenverkehr, der an diese virtuelle IP-Adresse weitergeleitet wird, wird an die aktive Anwendung geleitet, die ihn empfangen kann.
• ThingWorx Connection Servers – Empfängt Web Socket-Verkehr von Assets und leitet ihn an ThingWorx Platform weiter. Die Connection Server können in einer Cluster-Konfiguration ausgeführt werden. Sobald ein Asset an einen bestimmten Connection Server weitergeleitet wird, sollte es immer denselben Connection Server verwenden. Wenn dieser Server offline geschaltet wird, sollte das Asset zu einem anderen verfügbaren Connection Server umgeleitet werden.
• ThingWorx Foundation – Empfängt den gesamten Benutzer- und Asset-Datenverkehr.
• ThingWorx Repositories – Dies sind erforderliche Speicherorte wie ThingworxPlatform, ThingworxStorage und ThingworxBackupStorage sowie zusätzliche Speicherorte, die zur Unterstützung Ihrer Implementierung hinzugefügt wurden. Für eine Cluster-Umgebung müssen die Speicherordner an einem gemeinsamen Speicherort vorhanden sein, an dem alle ThingWorx Server gleichermaßen auf sie zugreifen können.
• Apache ZooKeeper – ZooKeeper ist ein zentralisierter Koordinationsdienst, der von ThingWorx Connection Server und Ignite für Diensterkennung, Singleton-Auswahl und verteilte Koordination verwendet wird.
• Apache Ignite – Ignite bietet einen verteilten Arbeitsspeicher-Cache für das Teilen des Status zwischen Servern im Cluster.
• PostgreSQL – Für eine HA-Konfiguration arbeitet PostgreSQL über zwei oder mehr Serverknoten in einer Hot-Standby-Konfiguration. Ein Knoten empfängt den gesamten Schreibdatenverkehr, und einer der anderen Knoten kann den gesamten Lesedatenverkehr empfangen. Die Streaming-Replikation wird zwischen allen Knoten aktiviert, damit jeder Knoten stets auf dem neuesten Stand ist.
• pgpool-II – Wird nur in PostgreSQL-HA-Konfigurationen verwendet. pgpool-II-Knoten empfangen die ThingWorx Anfragen (Lese- und Schreibvorgänge) und leiten sie an den entsprechenden PostgreSQL-Knoten weiter. Sie überwachen auch die Integrität jedes PostgreSQL-Knotens und können Failover-Aufgaben und Neuzuweisungen initiieren, wenn einer der Knoten offline geht.
• Microsoft SQL Server (nicht abgebildet) – Microsoft Failover wird verwendet, um sicherzustellen, dass mindestens ein MS SQL Server online und verfügbar ist.
• InfluxDB – Eine InfluxDB-Implementierung ist für eine ThingWorx Clustering-Konfiguration nicht erforderlich. Wenn sie erforderlich ist, um die Erfassungsanforderungen der Implementierung zu erfüllen, stellen Sie sicher, dass sie für HA konfiguriert ist.