Risoluzione dei problemi per il clustering a disponibilità elevata
La chiave di accesso è presente in ogni server ma il relativo valore è vuoto
Questo problema si verifica quando esiste una chiave di crittografia diversa per ciascun server. Questo può accadere se il keystore non è stato condiviso correttamente.
È possibile configurare i file keystore-password e
keystore.pfx utilizzando lo
strumento di gestione della protezione. La directory
ThingworxStorage deve essere quindi condivisa da ciascuna istanza della piattaforma.
Se non è possibile, è necessario avviare un server per creare i file keystore-password e keystore.pfx e quindi copiarli nell'altro computer prima di avviarlo.
1. Avviare un server per creare i file /ThingworxPlatform/keystore-password e /ThingworxStorage/keystore.pfx.
2. Copiare i file nell'altro server e avviarlo.
L'oggetto creato sul server A non si trova sul server B
La disponibilità elevata (HA) funziona sincronizzando il modello tramite il database. Questa sincronizzazione si verifica approssimativamente ogni 100 ms ma è possibile configurare questa impostazione. Tutti i server devono puntare alla stessa istanza del database PostgreSQL, pertanto è opportuno controllare la configurazione del database nelle impostazioni della piattaforma per verificare che le impostazioni di connessione corrispondano. Se si desidera eseguire PostgreSQL in un cluster a disponibilità elevata, è necessario seguire la configurazione di PostgreSQL HA utilizzando Pgpool-II e una configurazione di PostgreSQL principale-secondaria.
I valori delle proprietà non vengono impostati su tutti i server
Se si imposta un valore di proprietà in memoria nel server A e l'aggiornamento del valore non viene visualizzato nel server B, il livello della cache che contiene lo stato non è configurato correttamente. ThingWorx memorizza gli Stati delle proprietà nella cache Apache Ignite, che può essere eseguita come incorporata o distribuita. Viene scritto un log della topologia nel log dell'applicazione e nei log Ignite, che mostrano il numero di client e server del cluster. È necessario verificare che il numero di server registrato corrisponda a quello previsto. Se i server non riescono a comunicare, ad esempio a causa dei firewall, Ignite verrà eseguito solo localmente.
Ad esempio:
# log entry showing platform 1 has 2 clients and 1 server
platform1_1 | 13-Jan-2020 17:08:53.231 INFO [disco-event-worker-#37%twx-core-server%] org.apache.ignite.logger.java.JavaLogger.info Topology snapshot [ver=5, locNode=0cab6e47, servers=1, clients=2, state=ACTIVE, CPUs=12, offheap=1.6GB, heap=9.9GB]
# log entry showing platform 2 has 2 clients and 1 server
platform2_1 | 13-Jan-2020 15:02:29.736 INFO [ForkJoinPool.commonPool-worker-1] org.apache.ignite.logger.java.JavaLogger.info Topology snapshot [ver=4, locNode=c7383c40, servers=1, clients=3, state=ACTIVE, CPUs=16, offheap=1.6GB, heap=14.0GB]
Il server non viene avviato a causa di un errore HTTP_PORT
Per implementare l'individuazione dei servizi, prima dell'avvio del server è necessario definire la HTTP_PORT attraverso cui i servizi esterni devono connettersi a ThingWorx. Si tratta della porta esposta in Apache Tomcat su cui è in esecuzione l'applicazione Platform. Questa variabile di ambiente deve essere disponibile per il processo che esegue Tomcat. È possibile configurarlo nel file setEnv oppure aggiornare la definizione del servizio.
Definizione del servizio Tomcat:
[Unit]
Description=Apache Tomcat Web Application Container
After=network.target
[Service]
Type=forking
PIDFile=/var/run/tomcat.pid
Environment=CATALINA_PID=/var/run/tomcat.pid
Environment=JAVA_HOME=/usr/lib/jvm/jdk1.8.0_191
Environment=HTTP_PORT=8080
Environment=CATALINA_HOME=/usr/share/tomcat9/9.0.26
Environment=CATALINA_BASE=/usr/share/tomcat9/9.0.26
ThingWorx Connection Server non è in grado di connettersi a ThingWorx con errori di autenticazione
È necessario creare una chiave di accesso nel server ThingWorx e aggiungerla alla configurazione di ThingWorx Connection Server. Se questa chiave non esiste o non corrisponde, il server connessioni genererà errori di autenticazione durante il tentativo di creare connessioni alla piattaforma.
ThingWorx Connection Server non riesce a trovare i server ThingWorx
Se ThingWorx Connection Server non si connette alla piattaforma, assicurarsi che la variabile di ambiente HTTP_PORT memorizzata nel server ThingWorx sia impostata sulla porta su cui è in esecuzione la piattaforma e che il nome del servizio corrisponda a quello configurato per ThingWorx. In caso contrario, il server connessioni non troverà i server ThingWorx.
Inoltre, il server ThingWorx potrebbe aver registrato un indirizzo errato in Apache Zookeeper. Questo può verificarsi quando il server ThingWorx tenta di determinare l'indirizzo IP del computer su cui è in esecuzione Zookeeper. Il resolver dell'indirizzo esegue la scansione di tutti gli indirizzi IP su tutte le interfacce di rete nel sistema host per determinare l'indirizzo IP che con maggiore probabilità corrisponde all'indirizzo LAN del computer. Se il computer presenta più indirizzi IP, questo metodo preferisce un indirizzo IP locale rispetto al sito, se esiste (ad esempio, 192.168.x.x oppure 10.10.x.x, in genere IPv4) e, se ne esiste più di uno, restituisce il primo di essi. Se il computer non è dotato di un indirizzo locale rispetto al sito, questo metodo restituisce il primo indirizzo non di loopback trovato (IPv4 o IPv6).
Problemi di prestazioni dell'applicazione
In un ambiente clustering il modo in cui un'applicazione viene scritta ha un impatto maggiore sulle prestazioni, poiché i dati dell'oggetto vengono distribuiti. È importante ridurre i round trip al di fuori del server in cui sono in esecuzione gli script. Per ulteriori informazioni, vedere
Best practice per le applicazioni a disponibilità elevata.
Il provider di cache non si avvia
Se il provider di cache Ignite Apache non si avvia, è possibile che sia presente un problema di configurazione. Ad esempio,
platform1_1 | 2020-07-13 17:34:14.965+0000 [L: ERROR] [O: E.c.q.l.c.Logger] [I: ] [U: SuperUser] [S: ] [P: platform1] [T: main] *** CRITICAL ERROR ON STARTUP: Failed to start CacheProvider com.thingworx.cache.ignite.IgniteCacheProvider
Si consiglia di controllare i nodi Zookeeper per assicurarsi che Zookeeper sia in esecuzione senza problemi e di verificare che il nodo locale possa accedere al server Zookeeper tramite la porta configurata.
Se Zookeeper non presenta problemi, controllare il cluster di Ignite per verificarne la corretta esecuzione. Controllare se nel log sono riportati problemi e l'istantanea della topologia per verificare che il cluster sia della dimensione corretta. Verificare che il nodo locale possa accedere all'host Ignite su tutte le porte necessarie.
Apache Client Ignite arresta la JVM ThingWorx
Il client Ignite può potenzialmente rallentare la JVM ThingWorx con il seguente errore nei log di Catalina.
SEVERE: Blocked system-critical thread has been detected. This can lead to cluster-wide undefined behaviour [workerName=sys-stripe-5, threadName=sys-stripe-5-#6%twx-core-server%, blockedFor=10s] ...
SEVERE: JVM will be halted immediately due to the failure: [failureCtx=FailureContext [type=CRITICAL_ERROR, err=class o.a.i.IgniteInterruptedException: Got interrupted while waiting for future to complete.]]
Se i per determinato un periodo di tempo i nodi Ignite non vengono sincronizzati, la VM viene arrestata perché la memoria non è sincronizzata.
Questo comportamento è dovuto a problemi di progettazione dell'applicazione e si verifica in genere quando come proprietà vengono utilizzate infotable di dimensioni molto grandi. Ogni operazione di scrittura di queste infotable di grandi dimensioni determina la sincronizzazione completa della proprietà della tabella. Di conseguenza, la JVM viene arrestata.
Si consiglia di convertire le proprietà infotable di grandi dimensioni in tabelle di database.
Problemi di connettività di Apache Ignite
Se Ignite presenta problemi di timeout della connessione, di connettività client o di latenza di rete, attivare le seguenti configurazioni di Ignite avanzate nelle impostazioni
cache nel file
platform-settings.json. Per informazioni su come configurare ciascuno dei valori, consultare la
documentazione di Ignite. Per ulteriori informazioni sul file
platform-settings.json, vedere
Impostazioni di piattaforma per ThingWorx a disponibilità elevata.
# This failure timeout automatically controls the following parameters: getSocketTimeout(), getAckTimeout(), getMaxAckTimeout(), getReconnectCount().
# If any of those parameters is set explicitly, the failure timeout setting will be ignored. For example, for stable low-latency networks the
# failure detection timeout may be set to ~120 ms.
failure-detection-timeout = 10000
client-failure-detection-timeout = 30000
# should only be used for advanced configuration
tcp-communication-spi {
connection-timeout = 5000
socket-write-timeout = 2000
slow-client-queue-limit = 0
}
# should only be used for advanced configuration
tcp-discovery-spi {
socket-timeout = 5000
ack-timeout = 5000
join-timeout = 5000
network-timeout = 5000
connection-recovery-timeout = 5000
reconnect-count = 10
reconnect-delay = 2000
so-linger = 5
stats-print-frequency = 0
}
Blocchi in errore nei provider di modelli
La sincronizzazione dei modelli utilizza blocchi di database per garantire la coerenza nel log delle modifiche. Un blocco in errore potrebbe interrompere il funzionamento dell'intero sistema, almeno per quanto riguardo le modifiche dei modelli. In questo caso, è possibile eseguire le operazioni descritte di seguito.
• In PostgreSQL
Ad esempio:
SET lock_timeout = 3000
b. Provare ad acquisire il blocco su una tabella.
c. Se il server non riesce a ottenere il blocco a causa del timeout di blocco, determinare l'età del blocco esistente utilizzando l'interrogazione seguente:
select extract(epoch from (now() - query_start)) from pg_stat_activity where query like '%lock <tableName> in exclusive mode;'
d. Se l'età del blocco è superiore alla soglia impostata, eseguire l'interrogazione seguente per trovare il processo contenente il blocco in una determinata tabella:
e. Terminare il processo contenente il blocco mediante il comando seguente:
SELECT pg_terminate_backend(pid);
• In MS SQL:
Ad esempio:
set lock_timeout 3000;
b. Provare ad acquisire il blocco su una tabella.
c. Se il server non riesce a ottenere il blocco a causa del timeout di blocco, eseguire l'interrogazione seguente per trovare il processo contenente il blocco in una determinata tabella:
d. Determinare l'età del blocco esistente utilizzando l'interrogazione seguente mediante il passaggio del session_id recuperato nel passo precedente:
select datediff(second, (select last_batch from master.dbo.sysprocesses where spid = <session_id>), CURRENT_TIMESTAMP)
e. Se l'età del blocco è superiore alla soglia impostata, utilizzare il session_id dell'interrogazione precedente per terminare il processo contenente il blocco mediante il comando seguente:
kill <sessionId>;
Errori EnsembleTracker
Se si verificano errori come quelli riportati di seguito nel log dell'applicazione, anche quando i server ZooKeeper sono attivi e in esecuzione, il problema può dipendere dal framework Apache Curator che non è in grado di gestire una modifica di configurazione.
2021-03-22 06:35:10.092+0000 [L: ERROR] [O: o.a.c.f.i.EnsembleTracker] [I: ] [U: ] [S: ] [P: VTWSandboxSVA2] [T: main-EventThread] Invalid config event received: {server.2=52.149.229.159:2888:3888:participant, server.1=0.0.0.0:2888:3888:participant, server.3=13.92.154.53:2888:3888:participant, version=0}
La soluzione consiste nel modificare la configurazione per le mappature del server utilizzate in zoo.cfg in modo da includere la porta client.
La configurazione seguente può determinare un errore:
server.1= xx.xxx.x.xx:2888:3888
server.2= xx.xxx.x.xx:2888:3888
server.3= xx.xxx.x.xx:2888:3888
Pertanto, aggiornare la configurazione in modo da includere la porta client come segue:
server.1= xx.xxx.x.xx:2888:3888;2181
server.2= xx.xxx.x.xx:2888:3888;2181
server.3= xx.xxx.x.xx:2888:3888;2181