Resolución de problemas para el agrupamiento de alta disponibilidad
La clave de aplicación existe en cada servidor, pero su valor está en blanco
Este problema se produce cuando la clave de cifrado es diferente en cada servidor. Esto puede suceder si el keystore no se comparte correctamente.
El fichero keystore-password y
keystore. pfx se puede configurar mediante la
Herramienta de gestión de seguridad. El directorio
ThingworxStorage luego debe compartirse entre todas las instancias de la plataforma.
Si no es posible, se debe iniciar un servidor para crear el fichero keystore-password keystore.pfx y, a continuación, copiarlo en el otro ordenador antes de iniciarlo:
1. Inicie un servidor para crear los ficheros /ThingworxPlatform/keystore-password y /ThingworxStorage/keystore.pfx.
2. Copie estos ficheros en el otro servidor y, a continuación, inícielo.
La cosa creada en el servidor A no se encuentra en el servidor B
La alta disponibilidad (HA) funciona sincronizando el modelo a través de la base de datos. Esta sincronización se produce aproximadamente cada 100 ms, pero se puede configurar. Todos los servidores deben apuntar a la misma instancia de base de datos de PostgreSQL. Por lo tanto, verifique la configuración de la base de datos en la configuración de la plataforma para asegurarse de que coincida la configuración de conexión. Si desea ejecutar PostgreSQL en un clúster de alta disponibilidad, debe seguir la configuración de la alta disponibilidad de PostgreSQL mediante Pgpool-II y una configuración de PostgreSQL principal-secundario.
Los valores de propiedad no se definen en todos los servidores
Si se define un valor de propiedad en memoria en el servidor A y no se ve la actualización del valor en el servidor B, la capa de caché que contiene el estado no está configurada correctamente. ThingWorx almacena los estados de propiedad en la caché de Apache Ignite, que se puede ejecutar de manera integrada o distribuida. Se escribe un registro de topología en el registro de la aplicación y los registros de Ignite, que muestran el número de clientes y servidores del clúster. Se debe validar que este número de servidores registrados coincide con el número de servidores previsto. Si los servidores no se pueden comunicar entre sí, lo que podría deberse a barreras de seguridad, Ignite solo se ejecutará localmente.
Por ejemplo:
# 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]
El servidor no se inicia debido a un error de HTTP_PORT
HTTP_PORT, a través del cual se requiere que los servicios externos se conecten a ThingWorx, debe definirse antes del inicio del servidor para implementar la detección de servicios. Se trata del puerto que se expone en Apache Tomcat, en el que se ejecuta la aplicación de la plataforma. Esta variable de entorno debe estar disponible para el proceso que ejecuta Tomcat. Se puede configurar en el fichero setEnv o se puede actualizar la definición de servicio.
Definición del servicio 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 no puede conectarse a ThingWorx con errores de autenticación
Se debe crear una clave de aplicación en el servidor ThingWorx y añadirla a la configuración de ThingWorx Connection Server. Si esta clave no existe o no coincide, Connection Server emitirá errores de autenticación al intentar crear conexiones con la plataforma.
ThingWorx Connection Server no puede encontrar servidores ThingWorx
Si ThingWorx Connection Server no se conecta a la plataforma, asegúrese de que la variable de entorno HTTP_PORT almacenada en el servidor ThingWorx se haya definido en el puerto en el que se ejecuta la plataforma y el nombre del servicio coincida con lo que se ha configurado para ThingWorx. Si alguno de los dos es incorrecto, Connection Server no encontrará los servidores ThingWorx.
Asimismo, el servidor ThingWorx puede haber registrado una dirección incorrecta en Apache Zookeeper. Esto puede ocurrir cuando el servidor ThingWorx intenta determinar la dirección IP del ordenador en el que se ejecuta Zookeeper. El solucionador de direcciones escaneará todas las direcciones IP de todas las interfaces de red del ordenador host para determinar la dirección IP que probablemente sea la dirección LAN del ordenador. Si el ordenador tiene varias direcciones IP, este método preferirá una dirección IP local del sitio si el ordenador tiene una (por ejemplo, 192.168.x.x o 10.10.x.x, normalmente IPv4) y devolverá la primera dirección local del sitio si el ordenador tiene más de una. Si el ordenador no tiene una dirección local del sitio, este método devolverá la primera dirección que no sea de bucle invertido que se encuentre (IPv4 o IPv6).
Incidencias del rendimiento de aplicaciones
En un entorno de agrupación, la forma en que se escribe una aplicación tiene un mayor impacto en el rendimiento, ya que se distribuyen los datos de cosa. Es importante reducir los recorridos de ida y vuelta fuera del servidor en el que se ejecutan los scripts. Para obtener más información, consulte
Prácticas recomendadas para aplicaciones de alta disponibilidad.
El proveedor de caché no se inicia
Si el proveedor de caché de Apache Ignite no se inicia, podría existir un problema de configuración. Por ejemplo:
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
Se recomienda verificar los nodos de Zookeeper para asegurarse de que Zookeeper se esté ejecutando correctamente y verificar que el nodo local pueda acceder al servidor Zookeeper en el puerto configurado.
Si Zookeeper es correcto, verifique si el clúster de Ignite se está ejecutando correctamente. Verifique el registro por si hay problemas y la instantánea de topología para asegurarse de que el clúster tenga el tamaño correcto. Verifique que el nodo local puede acceder al host de Ignite en todos los puertos necesarios.
Problemas de conectividad de Apache Ignite
Si Ignite tiene problemas de tiempo de espera de conexión, de conectividad del cliente o de latencia de red, active las siguientes configuraciones avanzadas de Ignite en la configuración
cache del fichero
platform-settings.json. Consulte la
documentación de Ignite para obtener información sobre cómo configurar cada uno de los valores. Para obtener más información sobre el fichero
platform-settings.json, consulte
Configuración de plataforma para la alta disponibilidad de 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
}
Bloqueos atascados en proveedores de modelos
La sincronización de modelos utiliza bloqueos de base de datos para garantizar la coherencia en el registro de cambios. Un bloqueo atascado podría colgar todo el sistema, al menos para los cambios del modelo. Si se encuentran bloqueos atascados, puede realizar lo siguiente:
• En PostgreSQL
Por ejemplo:
SET lock_timeout = 3000
b. Intente adquirir el bloqueo en una tabla.
c. Si el servidor no puede adquirir el bloqueo debido al tiempo de espera de bloqueo, determine la antigüedad del bloqueo existente mediante la siguiente consulta:
select extract(epoch from (now() - query_start)) from pg_stat_activity where query like '%lock <tableName> in exclusive mode;'
d. Si la antigüedad del bloqueo se encuentra por encima del umbral definido, ejecute la siguiente consulta para buscar el proceso que mantiene el bloqueo en una tabla determinada:
e. Termine el proceso manteniendo el bloqueo con el siguiente comando:
SELECT pg_terminate_backend(pid);
• En MS SQL:
Por ejemplo:
set lock_timeout 3000;
b. Intente adquirir el bloqueo en una tabla.
c. Si el servidor no puede adquirir el bloqueo debido al tiempo de espera del bloqueo, ejecute la siguiente consulta para buscar el proceso que mantiene el bloqueo en una tabla determinada:
d. Determine la antigüedad del bloqueo existente mediante la siguiente consulta pasando el elemento session_id recuperado en el paso anterior:
select datediff(second, (select last_batch from master.dbo.sysprocesses where spid = <session_id>), CURRENT_TIMESTAMP)
e. Si la antigüedad del bloqueo se encuentra por encima del umbral definido, utilice el elemento session_id del resultado de la consulta anterior para terminar el proceso que mantiene el bloqueo, con el siguiente comando:
kill <sessionId>;
Errores de EnsembleTracker
Si se reciben errores como los que se indican a continuación en el registro de aplicación, incluso si los servidores de ZooKeeper están en funcionamiento, el problema puede ser que el marco de Apache Curator no puede gestionar un cambio de configuración.
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 solución es cambiar la configuración de las asignaciones de servidor que se utilizan en zoo.cfg para incluir el puerto de cliente.
La siguiente configuración puede provocar un error:
server.1= xx.xxx.x.xx:2888:3888
server.2= xx.xxx.x.xx:2888:3888
server.3= xx.xxx.x.xx:2888:3888
Por lo tanto, actualice la configuración para incluir el puerto de cliente de la siguiente manera:
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