ThingWorx Bereitstellungsarchitekturen
Die folgenden Abschnitte enthalten Diagramme typischer ThingWorx Bereitstellungen. Die Architekturen reichen von einfachen Entwicklungssystemen über Cluster mit mehreren Knoten bis hin zu globalen Verbund-Produktionssystemen. Informationen zu ThingWorx Komponenten finden Sie unter ThingWorx Foundation Bereitstellungskomponenten.
 |
Informationen zur Bereitstellung von ThingWorx in Hybrid- und Multi-Site-Bereitstellungen finden Sie unter Distributed ThingWorx Deployment.
|
Bereitstellungsoptionen
• PTC Cloud Services – In einer Managed-Services-Bereitstellung wird die ThingWorx Anwendung auf einem Drittanbieterserver, häufig einer Private Cloud, gehostet und verwaltet. Eine externe Organisation ist für die Verwaltung der erforderlichen Infrastruktur und die Sicherstellung der Leistung verantwortlich.
Für Unternehmen, die sich Gedanken um den IT-Aufwand und das Expertenwissen für die Verwaltung von ThingWorx machen, bietet PTC eine Bereitstellungsoption für Managed Services. Mit PTC Cloud Services können Unternehmen, die ThingWorx erwerben, die Bereitstellung beschleunigen, die IT-Kosten und -Anforderungen minimieren und die laufende Leistung sicherstellen. PTC Cloud Services hostet Ihre ThingWorx Lösung in einer sicheren Umgebung in kommerziellen Cloud-Diensten, die fortlaufende Anwendungsverwaltung, Leistungsoptimierung und Aktualisierungen bietet. Weitere Informationen finden Sie unter www.ptc.com/services/cloud.
• Bereitstellung vor Ort – Bei einer lokalen Bereitstellung wird die ThingWorx Software auf Servern an Ihrem eigenen Standort oder in Ihrem eigenen Rechenzentrum installiert und ausgeführt. Sie sind für die Beschaffung, Installation und Wartung der Infrastruktur und Software-Anwendungen sowie deren fortlaufenden Support in Bezug auf Integrität, Verfügbarkeit und Leistung verantwortlich.
Bei einer lokalen Bereitstellung können Sie die Bereitstellung selbst ausführen oder PTC Professional Services (oder einen PTC zertifizierten Partner) für die Verwaltung der Bereitstellung einsetzen. Diese Option eignet sich für Unternehmen mit einer robusten IT-Organisation, die die interne Steuerung beibehalten möchten.
Weitere Informationen finden Sie in den folgenden Abschnitten:
ThingWorx Foundation Basis-Produktionssystem
Für ein Basis-Produktionssystem wird empfohlen, die Datenbank auf einem separaten Server zu betreiben. Dies ist ein gutes System für kleine und mittelgroße Unternehmen oder ein mittelgroßes bis großes Fertigungssystem.
Liste der Komponenten | Anzahl der Komponenten |
|---|---|
Lastenausgleichsmodul | 1 |
ThingWorx Connection Server | 1 |
ThingWorx Foundation Server | 1 |
Angehängter oder NAS-Dateispeicher | 1 |
Datenbank | 1 |
Großes ThingWorx Foundation Produktionssystem (nicht-HA)
Ein großes Produktionssystem enthält zusätzliche Komponenten, um eine höhere Anzahl verbundener Geräte und hohe Datenaufnahmeraten zu unterstützen.
Zusätzlich zu den Plattformkomponenten kann ein großes Produktionssystem ThingWorx Connection Server und eine InfluxDB-Zeitreihendatenbank enthalten.
Das InfluxDB-System nimmt Daten aus den Assets auf, die ThingWorx als protokollierten Wert-Stream-Inhalt verwaltet.
Trotzdem ist eine relationale Datenbank zur Beibehaltung des ThingWorx Modells erforderlich.
InfluxDB kann in Konfigurationen mit einem oder mehreren Knoten (Enterprise) bereitgestellt werden, basierend auf den Anforderungen für Aufnahme und Hochverfügbarkeit. Weitere Informationen finden Sie unter InfluxDB als Persistenzanbieter verwenden.
Liste der Komponenten | Anzahl der Komponenten |
|---|---|
Lastenausgleichsmodul | 1 (verteilt den Gerätedatenverkehr an Verbindungsserver) |
ThingWorx Connection Server | 2..n (hängt von der Anzahl der Geräte ab) |
ThingWorx Foundation Server | 1 |
Relationale Datenbank | 1 |
InfluxDB (einzelner Knoten) | 1 |
ThingWorx Produktions-Cluster
Für eine Hochverfügbarkeitsbereitstellung (High Availability, HA) werden zusätzliche Komponenten hinzugefügt, um einzelne Fehlerstellen in den Anwendungs- und Datenebenen zu entfernen. Die folgenden Komponenten sind für die ThingWorx Platform erforderlich:
• Ein Lastenausgleichsmodul für hohe Verfügbarkeit. Die Verbindungsserver und die Foundation Server Knotengruppen benötigen beide eine Lastenausgleichsinstanz, um die Last zu verteilen. Ein InfluxDB Enterprise-Cluster erfordert bei Verwendung ebenfalls eine Instanz. Viele Lastenausgleichsoptionen sind in der Lage, mehrere Instanzen zu bedienen. So kann eine einzelne Appliance bei entsprechender Konfiguration verwendet werden, um alle drei Instanzen zu bedienen.
• Zwei (oder mehr) ThingWorx Connection Servers. Für Cluster-Operationen sind Verbindungsserver erforderlich, um die Gerätelast im Cluster zu verteilen oder neu zu verteilen, wenn ein Knoten ausfällt.
• Zwei (oder mehr) ThingWorx Foundation Instanzen. Jeder Knoten ist aktiv: Die Last wird zwischen ihnen verteilt.
• ThingWorxStorage ist Speicher auf der Festplatte, der geteilt wird (für jeden Knoten zugänglich).
| | Für eine vollständige Hochverfügbarkeitsbereitstellung sollte auch für Lastenausgleichsmodule und geteilten ThingWorxStorage Redundanz implementiert sein. |
• Apache Ignite-Knoten stellen geteilten Cache für die ThingWorx Foundation Knoten bereit.
• Drei Apache ZooKeeper-Knoten. ZooKeeper überwacht ThingWorx Knoten, um zu bestimmen, ob jeder reaktionsfähig ist und wie erwartet funktioniert. Die ZooKeeper-Knoten bilden ein Quorum und entscheiden, wann ein ThingWorx Knoten offline ist. Wenn ein ThingWorx Foundation Knoten offline geht, konfiguriert ZooKeeper das ThingWorx Lastenausgleichsmodul neu, um den Verkehr an die anderen Foundation Knoten weiterzuleiten.
Die folgenden Komponenten sind für die PostgreSQL-Datenbank erforderlich:
• PostgreSQL-Serverknoten – Es werden mindestens zwei, idealerweise drei Knoten verwendet.
• pgpool-II-Knoten – Mindestens zwei, idealerweise drei Knoten, die Failover- und Wiederherstellungsaufgaben im Falle eines PostgreSQL-Serverfehlers ausführen. Diese Knoten erhalten Verbindungen zwischen Client (ThingWorx) und Servern (PostgreSQL) aufrecht und verwalten die Replikation von Inhalten zwischen PostgreSQL-Serverknoten.
Die folgenden Komponenten sind für das InfluxDB Enterprise-System erforderlich:
• InfluxDB Enterprise-Metaknoten – Ein Setup mit drei Knoten wird empfohlen, sodass ein Quorum erreicht werden und der Cluster weiterhin funktionieren kann, wenn ein Knoten ausfällt.
• InfluxDB Enterprise-Datenknoten – Einer ist ausreichend, aber mindestens zwei werden empfohlen. Eine Knotenanzahl, die ganzzahlig durch den InfluxDB-Replikationsfaktor teilbar ist, wird empfohlen.
Weitere Informationen zum Bereitstellen von ThingWorx in einer Hochverfügbarkeitsumgebung finden Sie unter Hochverfügbarkeit mit ThingWorx.
Cluster mit hoher Skalierbarkeit + hoher Verfügbarkeit
In diesem Diagramm befindet sich jede Komponente des Clusters in ihrer eigenen physischen Maschine, virtuellen Maschine oder in einem eigenen Container. Dies bietet größtmögliche Flexibilität in Bezug auf die unabhängige Skalierung jeder einzelnen Komponentengruppe.
Liste der Komponenten | Anzahl der Komponenten |
|---|---|
ThingWorx Verbindung Server | 2..n (basierend auf Geräteanzahl) |
Lastenausgleichsmodul | 2 oder 3 Instanzen: • Weiterleiten des Gerätedatenverkehrs an Verbindungsserver • Weiterleiten des Datenverkehrs zwischen ThingWorx Knoten • Weiterleiten des Datenverkehrs zwischen InfluxDB Enterprise-Datenknoten (falls verwendet) |
ThingWorx Foundation Server | 2.. n: basierend auf Anforderungen an hohe Verfügbarkeit und Skalierbarkeit |
Netzwerk-/Unternehmensspeicher | Speicherplatz für ThingWorx Speicher-Repositories, der mit allen ThingWorx Foundation Servern geteilt wird. |
Ignite | 2 Optionen: • Eingebettet in Foundation Prozesse. • 2 oder mehr separate Knoten (abhängig von den HA-Anforderungen) |
ZooKeeper | Mindestens 3. Sollten in ungeraden Kontingenten sein. |
Datenbank | Hängt von der Datenbank ab: • PostgreSQL: 3 Datenbankknoten + 2 pgpool-II-Knoten • MS SQL Server (nicht abgebildet): mindestens 2 als Teil einer Failover-Konfiguration. |
InfluxDB Enterprise | 5 (oder mehr): • 3 Metaknoten • 2 oder mehr Datenknoten, wobei Gesamtzahl ganzzahlig durch Replikationsfaktor teilbar ist |
Minimaler Cluster-Footprint
In diesem Diagramm werden Komponenten in einen kleineren Satz physischer/virtueller Maschinen oder Container gepackt oder gruppiert.
Diese Konfiguration kann für hohe Verfügbarkeit verwendet werden, ist jedoch im Vergleich zu einer verteilten Konfiguration, in der Komponenten Ressourcen teilen, weniger skalierbar.
Dieses Diagramm kann auch verwendet werden, um Bereitstellungen zu prüfen, bei denen mehrere unabhängige ThingWorx Bereitstellungen dieselbe geteilte Infrastruktur nutzen (ZooKeeper, DB, Network Storage).
Liste der Komponenten (pro Cluster-Knoten) | Anzahl der Komponenten |
|---|---|
ThingWorx Connection Server | 1 (pro Cluster-Knoten) |
ThingWorx Foundation Server | 1 (pro Cluster-Knoten) |
Ignite | Keine – wird im eingebetteten Modus innerhalb jedes Foundation Server Prozesses ausgeführt. |
Liste der Komponenten (geteilt) | Anzahl der Komponenten |
|---|---|
Lastenausgleichsinstanzen | 2 oder 3 Instanzen: • Weiterleiten des Gerätedatenverkehrs an Verbindungsserver. • Weiterleiten des Datenverkehrs zwischen ThingWorx Knoten. • Weiterleiten des Datenverkehrs zwischen InfluxDB Enterprise-Datenknoten (falls verwendet). |
ZooKeeper | Mindestens 3. Sollten in ungeraden Kontingenten sein. |
Datenbanken | Siehe vorheriges Diagramm. |
Netzwerk-/Unternehmensspeicher | Speicherplatz für ThingWorx Speicher-Repositories, der mit allen ThingWorx Foundation Servern geteilt wird. |