Basiseinstellung
|
Standard
|
Beschreibung
|
---|---|---|
EnableClusteredMode
|
false
|
Bestimmt, ob ThingWorx als Cluster (Einstellung ist true) oder als unabhängiger Server (Einstellung ist false) ausgeführt wird.
|
Richtlinie für den Import von Erweiterungspaketen – Einstellung
|
Standard
|
Beschreibung
|
---|---|---|
haCompatibilityImportLevel
|
WARN
|
Wenn Sie ThingWorx im Cluster-Modus ausführen, können Sie den Import von Erweiterungen auf diejenigen beschränken, für die das haCompatibility-Flag in den Erweiterungsmetadaten auf true festgelegt ist. Die Standardeinstellung ist WARN. Sie ermöglicht den Import, generiert aber eine Warnmeldung. Sie können die Einstellung in DENY ändern. In diesem Fall schlägt der Import fehl, und es wird ein Fehler generiert.
|
Cluster-Modus – Einstellung
|
Standard
|
Beschreibung
|
||
---|---|---|---|---|
PlatformId
|
Keine
|
Eine eindeutige ID für jeden Knoten im Cluster. Diese ID wird in aggregierten Protokollen angezeigt. Sie muss alphanumerisch sein und weniger als 32 Zeichen umfassen. Sie sollte dem Muster "^[a-zA-Z0-9]{1,32}$" entsprechen.
|
||
CoordinatorHosts
|
Keine
|
Kommagetrennte Liste von Apache ZooKeeper Servern zum Koordinieren der ThingWorx Prioritätsauswahl. Zeichenfolgenmuster ist: IP:port. (z.B. "127.0.0.1:2181, 127.0.0.2:2181").
|
||
ZKNamespace
|
ThingWorx
|
Der Wurzelknoten-Pfad zur Nachverfolgung von Informationen in ZooKeeper für den Cluster. Er ist erforderlich, wenn mehrere Cluster unter Verwendung desselben ZooKeeper ausgeführt werden. Es gelten die Einschränkungen für die Benennung in ZooKeeper; siehe http://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#ch_zkDataModel.
|
||
ModelSyncPollInterval
|
100
|
Häufigkeit in Millisekunden, mit der das Modell zwischen Servern im Cluster synchronisiert wird. Jeder Server prüft in dieser Häufigkeit auf Modelländerungen und wendet alle gefundenen Änderungen an.
|
||
ModelSyncWaitPeriod
|
3000
|
Bei der Kommunikation über WebSockets wird der Datenverkehr im Rundlauf-Verfahren zwischen den Servern synchronisiert. Wenn eine Modelländerung über WebSockets vorgenommen wird, wartet die nächste Anforderung, bis die angegebene Zeit in Millisekunden verstrichen ist, bis das Modell auf dem Server synchronisiert wird, auf dem es landet. Wenn vor dem Timeout keine Synchronisierung stattfindet, schlägt die Anforderung mit einem Timeout-Fehler fehl.
|
||
ModelSyncTimeout
|
120000
|
Wartezeit (in Millisekunden) auf die einzelnen Wiederholungsversuche.
|
||
ModelSyncMaxDBUnavailableErrors
|
10
|
Anzahl der aufeinanderfolgenden Synchronisierungsfehler durch nicht vorhandene Datenbankkonnektivität, die zulässig sind, bevor der Server heruntergefahren wird. Der Zeitrahmen in Millisekunden beträgt ungefähr ModelSyncPollInterval * diesen Wert.
|
||
ModelSyncMaxCacheUnavailableErrors
|
10
|
Anzahl der aufeinanderfolgenden Synchronisierungsfehler durch nicht vorhandene Cache-Konnektivität, die zulässig sind, bevor der Server heruntergefahren wird. Der Zeitrahmen in Millisekunden beträgt ungefähr ModelSyncPollInterval * diesen Wert.
|
||
CoordinatorMaxRetries
|
3
|
Im Falle eines Fehlers bei der Kommunikation mit dem Koordinator, erfolgt n Mal eine Wiederholung, bevor der Vorgang fehlschlägt.
|
||
CoordinatorSessionTimeout
|
90000
|
Zeitraum (in Millisekunden), den ThingWorx wartet, ohne einen Takt vom Apache ZooKeeper-Dienst zu erhalten, der zum Koordinieren der ThingWorx Priorität verwendet wird.
|
||
CoordinatorConnectionTimeout
|
10000
|
Die Dauer (in Millisekunden), die das System auf eine Verbindung mit dem Koordinator wartet.
|
||
MetricsCacheFrequency
|
60000
|
Metriken werden pro Server verfolgt und für Metriken auf Cluster-Ebene aggregiert. Dieser Wert ist die Häufigkeit (in Millisekunden), in der die Cluster-Metriken aktualisiert werden.
|
||
IgnoreInactiveInterfaces
|
wahr
|
Optional. Wenn der Cluster-Modus aktiviert ist, wird versucht, den ThingWorx Server als Dienst bei einem Diensterkennungs-Anbieter zu registrieren. Dazu werden alle verfügbaren Adapter und deren Adressen geprüft, und es wird versucht, eine standortlokale Adresse zu finden. Wenn keine gefunden wird, wird die erste gefundene Adresse verwendet, die nicht standortlokal ist. Diese Einstellung wirkt sich auf diese Logik aus. Wenn diese Einstellung auf "wahr" festgelegt ist, werden inaktive Schnittstellen ignoriert.
|
||
IgnoreVirtualInterfaces
|
wahr
|
Optional. Wenn diese Einstellung auf "wahr" festgelegt ist, werden virtuelle Schnittstellen ignoriert. Weitere Informationen finden Sie oben in der Beschreibung für IgnoreInactiveInterfaces.
|
||
HostAddressFilter
|
Keine
|
Optional. Wenn angegeben, werden Adressen basierend auf dem regulären Ausdruck gefiltert. Andernfalls wird kein Filter angewendet. Geben Sie beispielsweise “10\\\\..” an, um Adressen zu filtern, die mit 10 beginnen, oder “^.:.*$” zum Filtern von Adressen, die : enthalten. Weitere Informationen finden Sie oben in der Beschreibung für IgnoreInactiveInterfaces.
|
Einstellung
|
Standard
|
Beschreibung
|
||
---|---|---|---|---|
basePath
|
/services
|
Ignite erstellt einen Ignite-Ordner unter basePath, in dem die Ignite-Knoteneinträge für die Diensterkennung gespeichert werden. Wenn Sie einen ZooKeeper für mehrere Cluster-Instanzen verwenden, ändern Sie den Standardwert in der Ignite-Clientkonfiguration und auf der Ignite-Serverseite in /clusterXX/services. Weitere Informationen finden Sie unter Zentrale ZooKeeper-Cluster konfigurieren.
|
||
client-mode
|
wahr
|
Bestimmt, ob das eingebettete Ignite als Client (Standard) oder Server ausgeführt wird. Ist im Server-Modus beteiligt an der Speicherung von Daten und verwendet mehr Arbeitsspeicher.
|
||
connection
|
Kein
|
Für eine address-resolver type von zookeeper eine kommagetrennte Liste von Apache ZooKeeper Servern zum Koordinieren der ThingWorx Prioritätsauswahl. Das Zeichenfolgenmuster ist IP:Port (z. B. 127.0.0.1:2181, 127.0.0.2:2181).
|
||
default-cache-mode
|
Kein
|
Dies kann auf REPLICATED oder PARTITIONED festgelegt werden. Bei Einstellung auf PARTITIONED werden Daten im Cluster verteilt und auf Grundlage der backups-Einstellung auf andere Server repliziert. Bei Einstellung auf REPLICATED werden alle Daten aus allen Caches auf allen Servern im Ignite-Cluster gespeichert.
Ihre Einstellungen hängen von den HA-Anforderungen des Systems und der Anzahl der ausgeführten Ignite-Server ab.
|
||
default-atomicity-mode
|
ATOMIC
|
Der Cache-Atomaritäts-Modus bestimmt, ob der Cache vollständige Transaktionssemantik oder ein einfacheres Atomaritäts-Verhalten aufrecht erhält. Der Modus ATOMIC sollte verwendet werden, wenn Transaktionen und explizites Sperren nicht benötigt werden. Im Modus ATOMIC behält der Cache vollständige Datenkonsistenz über alle Cache-Knoten bei.
|
||
default-backups
|
Kein
|
Diese Einstellung gilt nur, wenn cache-mode auf PARTITIONED festgelegt ist. Sie definiert die Anzahl der Server, die eine Kopie der Daten aufbewahren. Für eine HA-Umgebung muss sie auf 1 oder höher festgelegt werden.
|
||
default-read-from-backup
|
falsch
|
Bei Ausführung im eingebetteten Modus (client-mode ist auf false festgelegt), legen Sie default-read-from-backup auf true fest, sodass der Cache lokal gelesen und die Leistung erhöht wird.Bei Ausführung im verteilten Modus ist diese Einstellung nicht von Nutzen, da Sie immer über das Netzwerk zu einem anderen Knoten gehen müssen. In diesem Fall sollte die Einstellung false lauten.
|
||
default-write-sync-mode
|
PRIMARY_SYNC
|
Sie können diese Einstellung auf Folgendes ändern:
• FULL_ASYNC
Ignite wartet nicht auf Schreib- oder Commit-Antworten von teilnehmenden Knoten. Daher kann der Status von Remote-Knoten nach Abschluss der Cache-Schreibmethoden oder nach Abschluss der Transaction.commit()-Methode aktualisiert werden.
• FULL_SYNC
Ignite sollte auf Schreib- oder Commit-Antworten von allen Knoten warten.
• PRIMARY_SYNC
Diese Einstellung gilt nur für die Modi CacheMode.PARTITIONED und CacheMode.REPLICATED.
• FULL_ASYNC
Nicht empfohlen. Bei Systemfehlern gehen zwar keine Daten verloren, aber die Schreibleistung verschlechtert sich.
|
||
provider-type
|
Kein
|
Muss auf "com.thingworx.cache.ignite.IgniteCacheProvider" festgelegt werden, wodurch der verteilte Cache aktiviert wird.
|