Überlegungen zur Dimensionierung des ThingWorx Clusters
ThingWorx Foundation Knoten dimensionieren
Bei Cluster-Operationen bleibt die Dimensionierung individueller ThingWorx Foundation Knoten größtenteils unverändert. Jeder Cluster-Knoten muss über genügend Arbeitsspeicher verfügen, um das gesamte Ding-Modell zu laden. Daher muss die Größe jedes Cluster-Knotens der Größe eines Einzelserver-Knotens entsprechen. Ein mittelgroßer Einzelserver hat beispielsweise 16 vCPUs und 32 GiB RAM. Entsprechend hätte bei einem Cluster mit zwei Knoten jeder Cluster-Knoten 16 vCPUs und 32 GiB RAM.
Wenn Apache Ignite separat bereitgestellt wird, kann der Foundation Server Arbeitsspeicherverbrauch geringfügig reduziert werden, da Eigenschaftsstatusinformationen auf die Ignite-Knoten übertragen wurden.
Die CPU-Auslastung nimmt zu, um Cluster-Synchronisationsaufgaben im Hintergrund auszuführen. Einzelne Operationen können aufgrund der zusätzlichen Latenz eines geteilten Cache in Cluster-Konfigurationen ebenfalls etwas langsamer sein. Dies wird durch die Möglichkeit ausgeglichen, eine größere Anzahl von Operationen parallel (Geschäftslogik und/oder Benutzeranforderungen) auf mehreren Knoten auszuführen.
Wenn die richtige Größe für einen einzelnen Knoten festgelegt wurde, sollten Sie für hohe Verfügbarkeit mindestens einen weiteren ThingWorx Foundation Knoten bereitstellen, um die Spitzenlast für Ihre Anwendung zu verarbeiten. Dadurch kann der Cluster die Leistungserwartungen im Falle des Ausfalls eines einzelnen Knotens weiterhin erfüllen.
Verbindungsserver-Knoten dimensionieren
Für Cluster-Operationen sind Verbindungsserver erforderlich, um die Gerätelast im Cluster zu verteilen oder neu zu verteilen, wenn ein Knoten ausfällt.
Wie bei Foundation Knoten wird empfohlen, mindestens einen weiteren Verbindungsserver bereitzustellen, um die erwartete Geräteanzahl zu verarbeiten. Dies ermöglicht es den Verbindungsservern, Konnektivität mit allen Geräten zu wahren, wenn ein einzelner Verbindungsserver-Knoten ausfällt.
Systemanforderungen für einzelne Connection Server Optionen finden Sie im Hilfe-Center für ThingWorx Connection Services.
Apache ZooKeeper-Knoten dimensionieren
Apache ZooKeeper ist eine Open-Source-Lösung für die Synchronisation verteilter Anwendungen. Sie ermöglicht die Überwachung und Wahl von Leadern für ThingWorx Knoten.
Ein Satz mit 3 Knoten mit jeweils 2 vCPUs und 2 GiB RAM wird empfohlen. Für die Beibehaltung eines Quorums ist eine ungerade Anzahl von Instanzen erforderlich.
Weitere Informationen finden Sie in den Apache ZooKeeper-Systemanforderungen: https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_systemReq
Datenbankknoten dimensionieren
Nicht nur in Bezug auf hohe Verfügbarkeit steigt die Datenbanklast in ThingWorx Cluster-Konfigurationen. Um dies zu veranschaulichen, wurden identische Lasttests mit fünf unterschiedlichen mittelgroßen Bereitstellungen unter Verwendung von virtuellen Microsoft Azure-Maschinen ausgeführt:
|
Vergleich der Leistung – Einzelknoten und Cluster (nur PostgreSQL)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
-
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
|
InfluxDB
|
-
|
-
|
-
|
-
|
-
|
|
Ergebnisse pro Knoten (Durchschnitt)
|
26.000 WPS
19 HTTP-Operationen
|
12.000 WPS
10 HTTP-Operationen
|
10.000 WPS
6 HTTP-Operationen
|
7.000 WPS
6 HTTP-Operationen
|
6.000 WPS
2 HTTP-Operationen
|
|
Ergebnisse gesamt
|
24.000 WPS
19 HTTP-Operationen
|
30.000 WPS
24 HTTP-Operationen
|
28.000 WPS
22 HTTP-Operationen
|
30.000 WPS
12 HTTP-Operationen
|
|
|
Erinnerung: Empfehlungen aus dem Dimensionierungshandbuch sind als anfängliche Baselines zur Dimensionierung von ThingWorx Implementierungen vorgesehen. Die einzelnen Ergebnisse variieren basierend auf der Edge-Konfiguration, der Anwendungslast usw.
|
|||||
Während die obigen Tests eine kleine Verbesserung bei der Datenaufnahme zeigen, verbessert sich die HTTP-Anforderungsleistung aufgrund unzureichender Datenbankressourcen nicht.
Um dies zu beheben, kann die Skalierbarkeit mit größeren RDBMS-Instanzen und/oder mithilfe von InfluxDB verbessert werden, wie unten angegeben.
|
Vergleich der Leistung – Einzelknoten und Cluster (PostgreSQL + InfluxDB)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
-
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
InfluxDB
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
Ergebnisse pro Knoten (Durchschnitt)
|
90.000 WPS
120 HTTP-Operationen
|
53.000 WPS
187 HTTP-Operationen
|
39.000 WPS
148 HTTP-Operationen
|
31.500 WPS
127 HTTP-Operationen
|
27.000 WPS
108 HTTP-Operationen
|
|
Ergebnisse gesamt
|
106.000 WPS
375 HTTP-Operationen
|
118.000 WPS
445 HTTP-Operationen
|
126.000 WPS
508 HTTP-Operationen
|
135.000 WPS
540 HTTP-Operationen
|
|
|
Erinnerung: Empfehlungen aus dem Dimensionierungshandbuch sind als anfängliche Baselines zur Dimensionierung von ThingWorx Implementierungen vorgesehen. Die einzelnen Ergebnisse variieren basierend auf der Edge-Konfiguration, der Anwendungslast usw.
|
|||||
 |
InfluxDB Open Source wurde für diese Tests verwendet, bietet jedoch keine hohe Verfügbarkeit. InfluxDB Enterprise wird für die ThingWorx Cluster-Implementierungen (Produktion) empfohlen. Planen Sie für die InfluxDB Enterprise-Dimensionierung zwei InfluxDB-Datenknoten wie angegeben, plus drei Metaknoten, in der Regel jeweils 1 bis 2 vCPUs und 0,5 bis 1 GiB RAM. Weitere Hinweise zur InfluxDB-Dimensionierung finden Sie unter https://docs.influxdata.com/influxdb/v1.8/guides/hardware_sizing/.
|
Apache Ignite-Knoten dimensionieren
In einem ThingWorx Cluster stellt Apache Ignite einen geteilten Cache für Eigenschaftswerte und zusätzliche Daten bereit, wie Dateiübertragungsjobs.
Ignite kann in den ThingWorx Foundation Prozess eingebettet werden. Dies erfordert keine separate Installation. Alternativ kann Ignite für eine bessere Lastverteilung auch als separater Cluster bereitgestellt werden.
Ignite kann ferner in einem von zwei Modi ausgeführt werden:
• PARTITIONED-Modus – Daten werden gleichmäßig in Partitionen und zwischen teilnehmenden Knoten aufgeteilt. Beste Cache-Schreibleistung.
• REPLICATED-Modus – Jede Ignite-Instanz weist eine Kopie jedes Datenpunkts auf. Beste Cache-Leseleistung.
Weitere Informationen finden Sie in der Apache Ignite-Dokumentation zu den Cache-Modi: https://apacheignite.readme.io/docs/cache-modes
Die primäre Last von Ignite ist der Netzwerkdurchsatz zwischen den einzelnen Instanzen von ThingWorx Foundation und Ignite. Während CPU-, Festplatten- oder Arbeitsspeicheranforderungen auf kleinere VM-Größen von Cloud-Anbietern hindeuten könnten, ist es wichtig, den begrenzten oder gedrosselten Netzwerkdurchsatz zu beobachten.
Wenn Durchsatzprobleme auftreten, können sie entweder durch Migration zu größeren Systemen mit mehr Netzwerkkapazität oder durch Hinzufügen zusätzlicher Ignite-Knoten (unter Verwendung des PARTITIONED-Modus) zum Verteilen der Last behoben werden.
Als ungefährer Ausgangspunkt wäre eine Arbeitsspeichergröße, die Ihren ThingWorx Foundation Knoten entspricht, eine sichere konservative Schätzung.
So berechnen Sie den Arbeitsspeicherbedarf Ihres geteilten Cache genauer:
1. Berechnen Sie den VTQ-Arbeitsspeicherbedarf (Value, Timestamp und Quality) für den ThingWorx Eigenschafts-Cache.
a. Bestimmen Sie für jeden Dingtyp die Datentypgröße im Arbeitsspeicher. Wenn Ihre Eigenschaft beispielsweise eine Zeichenfolge mit 50 Zeichen ist und jedes Zeichen 2 Byte erfordert, benötigt diese Zeichenfolge 100 Byte Arbeitsspeicher.
b. Fügen Sie 8 Byte hinzu. (4 für Datum/Uhrzeit dieses Werts und 4 für die Qualität des Werts).
c. Multiplizieren Sie mit 2. ThingWorx speichert den aktuellen und vorherigen Wert jeder Eigenschaft im Cache.
d. Multiplizieren Sie mit der Anzahl der Dinge dieses Typs.
e. Addieren Sie das Ergebnis für jeden Dingtyp.
2. Addieren Sie 30 % für die In-Memory-Wertindizes von Ignite.
3. Multiplizieren Sie mit der Anzahl der Datenkopien, die im Ignite-Cluster verfügbar sein sollen. Wenn Sie beispielsweise eine Sicherung der Daten wünschen, sodass keine Daten verloren gehen, wenn ein einzelner Ignite-Knoten ausfällt, multiplizieren Sie mit 2.
4. Dividieren Sie durch die Anzahl der Ignite-Cluster-Knoten, die Sie bereitstellen möchten.
5. Für jeden Ignite-Knoten sind ungefähr zusätzliche 300 MB für den eigenen Betrieb erforderlich.
Weitere Informationen finden Sie in der Apache Ignite-Dokumentation: https://apacheignite.readme.io/docs/capacity-planning