Dépannage du clustering haute disponibilité
Une clé d'application existe sur chaque serveur mais sa valeur est vide.
Ce problème se produit lorsque la clé de chiffrement est différente sur chaque serveur. Cela peut se produire si le KeyStore n'est pas correctement partagé.
Vous pouvez configurer les fichiers keystore-password et
keystore.pfx à l'aide de l'
outil de gestion de la sécurité. Le répertoire
ThingworxStorage doit être partagé par chaque instance de plateforme.
Si cela n'est pas possible, vous devez démarrer un serveur pour créer les fichiers keystore-password et keystore.pfx, puis les copier sur l'autre machine avant de la démarrer.
1. Démarrez un serveur pour créer les fichiers /ThingworxPlatform/keystore-password et /ThingworxStorage/keystore.pfx.
2. Copiez ces fichiers sur l'autre serveur, puis démarrez l'autre serveur.
Un objet créé sur le serveur A n'est pas sur le serveur B.
La haute disponibilité (HA) fonctionne en synchronisant le modèle via la base de données. Cette synchronisation a lieu environ toutes les 100 ms mais peut être configurée. Tous les serveurs doivent pointer vers la même instance de base de données PostgreSQL ; par conséquent, vérifiez la configuration de base de données dans les paramètres de la plateforme pour vous assurer que les paramètres de connexion sont corrects. Si vous souhaitez exécuter PostgreSQL dans un cluster haute disponibilité, vous devez suivre la configuration HA de PostgreSQL en utilisant Pgpool-II et une configuration PostgreSQL principale/secondaire.
Les valeurs de propriété ne sont pas définies sur tous les serveurs.
Si vous définissez une valeur de propriété en mémoire sur le serveur A et que vous ne voyez pas la valeur mise à jour sur le serveur B, c'est que la couche de cache qui stocke l'état n'est pas configurée correctement. ThingWorx stocke les états de propriété dans le cache Apache Ignite, qui peut être exécuté en mode intégré ou distribué. Un journal de topologie est écrit dans le journal de l'application et les journaux Ignite, indiquant le nombre de clients et de serveurs dans le cluster. Vous devez vérifier que ce nombre consigné de serveurs correspond au nombre de serveurs attendus. Si les serveurs ne peuvent pas communiquer entre eux, ce qui peut être dû à des pare-feu, Ignite s'exécute uniquement en local.
Par exemple :
# 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]
Le serveur ne démarrera pas en raison d'une erreur HTTP_PORT.
Le HTTP_PORT, que les services externes doivent utiliser pour se connecter à ThingWorx, doit être défini avant le démarrage du serveur pour permettre la découverte des services. Il s'agit du port exposé dans Apache Tomcat sur lequel l'application de plateforme s'exécute. Cette variable d'environnement doit être disponible pour le processus exécutant Tomcat. Vous pouvez la configurer dans le fichier setEnv ou mettre à jour la définition de service.
Définition du service 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 ne parvient pas à se connecter à ThingWorx, avec des erreurs d'authentification.
Vous devez créer une clé d'application sur le serveur ThingWorx et ajouter cette clé d'application à la configuration ThingWorx Connection Server. Si cette clé n'existe pas ou ne correspond pas, ThingWorx Connection Server génère des erreurs d'authentification lors de ses tentatives de création de connexions à la plateforme.
ThingWorx Connection Server ne parvient pas à trouver les serveurs ThingWorx.
Si ThingWorx Connection Server ne se connecte pas à la plateforme, assurez-vous que la variable d'environnement HTTP_PORT stockée sur le serveur ThingWorx est définie sur le port sur lequel la plateforme s'exécute et que le nom du service correspond à celui configuré pour ThingWorx. Si l'un ou l'autre de ces réglages est incorrect, ThingWorx Connection Server ne trouvera pas les serveurs ThingWorx.
Par ailleurs, le serveur ThingWorx peut avoir enregistré une adresse incorrecte dans Apache ZooKeeper. Ceci peut se produire lorsque le serveur ThingWorx tente de déterminer l'adresse IP de la machine sur laquelle ZooKeeper s'exécute. Le résolveur d'adresses analyse toutes les adresses IP de toutes les interfaces réseau sur la machine hôte afin de déterminer l'adresse IP la plus susceptible d'être l'adresse LAN de la machine. Si la machine possède plusieurs adresses IP, cette méthode privilégie une adresse IP locale au site si la machine en possède une (par exemple, 192.168.x.x ou 10.10.x.x, généralement IPv4) et renvoie la première adresse locale au site si elle en possède plus d'une. Si la machine ne possède pas d'adresse locale au site, cette méthode renverra la première adresse sans bouclage trouvée (IPv4 ou IPv6).
Problèmes de performances de l'application.
Dans un environnement de clustering, la manière dont une application est écrite a un impact plus important sur les performances, car les données des objets sont distribuées. Il est important de réduire les allers-retours hors du serveur sur lequel les scripts sont exécutés. Pour plus d'informations, consultez la rubrique
Bonnes pratiques pour les applications haute disponibilité.
Le fournisseur de cache ne démarre pas.
Si le fournisseur de cache Apache Ignite ne démarre pas, il peut s'agir d'un problème de configuration. Par exemple :
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
Nous vous recommandons de vérifier les noeuds ZooKeeper pour vous assurer que ZooKeeper s'exécute correctement et que le noeud local peut accéder au serveur ZooKeeper sur le port configuré.
Si tout va bien en ce qui concerne ZooKeeper, contrôlez que le cluster Ignite fonctionne correctement. Vérifiez que le journal ne contient pas d'erreur et contrôlez le cliché de topologie pour vous assurer que la taille du cluster est correcte. Vérifiez que le noeud local peut accéder à l'hôte Ignite sur tous les ports requis.
Problèmes de connectivité Apache Ignite
Si Ignite rencontre des problèmes d'expiration de la connexion, de connectivité client ou de latence réseau, activez les configurations Ignite avancées suivantes dans les paramètres
cache du fichier
platform-settings.json. Pour plus d'informations sur la configuration de chacun des paramètres, consultez la
documentation Ignite (en anglais). Pour plus d'informations sur le fichier
platform-settings.json, consultez la rubrique
Paramètres de la plateforme pour la haute disponibilité ThingWorx.
# 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
}
Verrous bloqués dans les fournisseurs de modèles.
La synchronisation des modèles utilise des verrous de base de données pour garantir la cohérence dans le journal des modifications. Un verrou bloqué peut bloquer l'ensemble du système, au moins pour les modifications apportées aux modèles. Si vous rencontrez des verrous bloqués, vous pouvez effectuer les opérations suivantes :
• Dans PostgreSQL
Par exemple :
SET lock_timeout = 3000
b. Essayez d'acquérir le verrou sur une table.
c. Si le serveur ne parvient pas à acquérir le verrou en raison du délai d'inactivité de verrouillage, déterminez l'âge du verrou existant à l'aide de la requête suivante :
select extract(epoch from (now() - query_start)) from pg_stat_activity where query like '%lock <tableName> in exclusive mode;'
d. Si l'âge du verrou est supérieur au seuil défini, exécutez la requête suivante pour trouver le processus qui maintient le verrou sur une table donnée :
e. Arrêtez le processus en maintenant le verrou à l'aide de la commande suivante :
SELECT pg_terminate_backend(pid);
• Dans MS SQL :
Par exemple :
set lock_timeout 3000;
b. Essayez d'acquérir le verrou sur une table.
c. Si le serveur ne parvient pas à acquérir le verrou en raison du délai d'inactivité de verrouillage, exécutez la requête suivante pour trouver le processus qui maintient le verrou sur une table donnée :
d. Déterminez l'âge du verrou existant à l'aide de la requête suivante en transmettant le session_id récupéré à l'étape précédente :
select datediff(second, (select last_batch from master.dbo.sysprocesses where spid = <session_id>), CURRENT_TIMESTAMP)
e. Si l'âge du verrou est supérieur au seuil défini, utilisez le session_id de la requête précédente pour arrêter le processus qui maintient le verrou à l'aide de la commande suivante :
kill <sessionId>;
Erreurs EnsembleTracker
Si vous obtenez des erreurs semblables à ce qui suit dans le journal de l'application alors que vos serveurs ZooKeeper fonctionnent normalement, le problème peut être que l'infrastructure Apache Curator est dans l'incapacité de traiter une modification de configuration.
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 solution consiste à modifier la configuration des mappages de serveur utilisés dans zoo.cfg pour inclure le port client.
La configuration suivante peut générer une erreur :
server.1= xx.xxx.x.xx:2888:3888
server.2= xx.xxx.x.xx:2888:3888
server.3= xx.xxx.x.xx:2888:3888
Par conséquent, mettez à jour la configuration comme suit pour inclure le port client :
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