ThingWorx 高可用性 > HA 群集的故障排除
HA 群集的故障排除
应用程序密钥存在于每个服务器上，但其值为空
当各个服务器上的加密密钥不相同时，会出现此问题。如果 keystore 未正确共享，则会发生这种情况。
您可以使用安全管理工具配置 keystore-password 和 keystore.pfx。ThingworxStorage 目录应共享至每个平台实例。
如果无法共享，则必须启动一台服务器来创建 keystore-password 和 keystore.pfx 文件，然后将其复制到另一台计算机中，再启动后者：
1. 启动一台服务器来创建 /ThingworxPlatform/keystore-password 和 /ThingworxStorage/keystore.pfx 文件。
2. 将这些文件复制到其他服务器，然后启动另一台服务器。
在服务器 A 上创建的事物不在服务器 B 上
高可用性 (HA) 通过在数据库中同步模型来实现。此同步大约每隔 100 毫秒进行一次，但此间隔可以进行配置。所有服务器都必须指向相同的 PostgreSQL 数据库实例；因此，请检查平台设置中的数据库配置，以确保连接设置相匹配。如果要在 HA 群集中运行 PostgreSQL，则必须遵循使用 Pgpool-II 的 PostgreSQL HA 配置以及主要-辅助 PostgreSQL 配置。
并非在所有服务器上均设置了此属性值
如果已在服务器 A 上设置内存中属性值，但无法在服务器 B 上看到值更新，则表明用于保存状态的缓存层配置不正确。ThingWorx 将属性状态存储在以嵌入或分布形式运行的 Apache Ignite 缓存中。拓扑日志会写入到应用程序日志和 Ignite 日志，其中将显示群集中的客户端和服务器的数量。您应该验证此处记录的服务器数是否与预期的服务器数相匹配。如果服务器因防火墙原因无法相互通信，则 Ignite 将仅在本地运行。
例如：
# 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]
服务器因 HTTP_PORT 错误无法启动
要实现服务发现，必须首先定义将外部服务连接至 ThingWorx 所需的 HTTP_PORT，然后再启动服务器。这是将在运行平台应用程序的 Apache Tomcat 中显示的端口。此环境变量必须在运行 Tomcat 的进程中可用。可以在 setEnv 文件中对此进行配置，也可以更新服务定义。
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 无法于存在身份验证错误的情况下连接至 ThingWorx
必须在 ThingWorx 服务器上创建一个应用程序密钥，并将此应用程序密钥添加到 ThingWorx Connection Server 配置。如果此密钥不存在或不匹配，则在尝试创建与平台之间的连接时，连接服务器将抛出身份验证错误。
ThingWorx Connection Server 找不到 ThingWorx 服务器
如果 ThingWorx Connection Server 无法连接到平台，请确保将 ThingWorx 服务器上存储的 HTTP_PORT 环境变量设置为平台运行所在的端口，且使得服务名称与为 ThingWorx 配置的名称相匹配。如果以上任一配置不正确，则 Connection Server 将无法找到 ThingWorx 服务器。
此外，ThingWorx 服务器可能在 Apache ZooKeeper 中注册了错误的地址。当 ThingWorx 服务器尝试确定正在运行 ZooKeeper 的计算机的 IP 地址时，会发生这种情况。地址解析器将扫描主机计算机上所有网络接口的所有 IP 地址，以确定最可能是计算机 LAN 地址的 IP 地址。计算机有多个 IP 地址时，如果有一个站点本地 IP 地址 (例如，192.168.x.x 或 10.10.x.x，通常为 IPv4)，则此方法会首选该本地 IP 地址，如果计算机有多个本地 IP 地址，则将返回第一个。如果计算机没有站点本地地址，则此方法将返回找到的第一个非环回地址 (IPv4 或 IPv6)。
应用程序性能问题
在群集环境中，应用程序编写方式会对性能产生比较大的影响，因为将分布事物数据。减少脚本运行所在服务器之外的往返非常重要。有关详细信息，请参阅 HA 应用程序的最佳做法。
缓存提供程序不启动
如果 Apache Ignite 缓存提供工具无法启动，可能存在配置问题。例如：
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
我们建议检查 ZooKeeper 节点，以确保 ZooKeeper 正常运行，并验证本地节点是否可以访问配置端口上的 ZooKeeper 服务器。
如果 ZooKeeper 正常，请检查 Ignite 群集以确定其是否能够正常运行。请检查日志中是否存在问题和拓扑快照以确保群集大小正确。验证本地节点是否可以访问所有必要端口上的 Ignite 主机。
Apache Ignite 连接问题
如果 Ignite 存在连接超时、客户端连接或网络延迟问题，请在 platform-settings.json 文件中的 cache 设置下启用以下高级 Ignite 配置。有关各个值的配置方法，请参阅 Ignite 文档。有关 platform-settings.json 文件的详细信息，请参阅 ThingWorx HA 的平台设置。
# 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
}
模型提供工具中的阻塞锁
模型同步使用数据库锁来保证更改日志的一致性。阻塞锁可能会使整个系统挂起，至少在模型更改的情况下是这样。如遇阻塞锁，可执行以下操作：
• 在 PostgreSQL 中：
a. 在 PostgreSQL 中设置锁定超时，以避免在等待阻塞锁时出现挂起，如下所述：https://www.postgresql.org/docs/9.3/static/runtime-config-client.html
例如：
SET lock_timeout = 3000
b. 尝试获取表格锁定。
c. 如因锁定超时而使服务器无法获取锁定，请执行以下查询来确定现有锁定的存在时间：
select extract(epoch from (now() - query_start)) from pg_stat_activity where query like '%lock <tableName> in exclusive mode;'
d. 如锁定的存在时间高于设定阈值，请执行以下查询来查找保持给定表格锁定的进程：
SELECT t.schemaname,
t.relname,
l.locktype,
l.page,
l.virtualtransaction,
l.pid,
l.mode,
l.granted
FROM pg_locks l
JOIN pg_stat_all_tables t ON l.relation = t.relid
WHERE t.schemaname <> 'pg_toast'::name AND t.schemaname <> 'pg_catalog'::name and t.relname = '<tableName>'
e. 使用以下命令来终止保持锁定的进程：
SELECT pg_terminate_backend(pid);
• 在 MS SQL 中：
a. 在 MS SQL 中设置锁定超时，以避免在等待阻塞锁时出现挂起，如下所述：https://docs.microsoft.com/en-us/sql/t-sql/statements/set-lock-timeout-transact-sql?view=sql-server-2017
例如：
set lock_timeout 3000;
b. 尝试获取表格锁定。
c. 如因锁定超时而使服务器无法获取锁定，请执行以下查询来查找保持给定表格锁定的进程：
select
object_name(p.object_id) as tablename, request_owner_id, session_id
from
sys.dm_tran_locks l
inner join sys.partitions p on l.resource_associated_entity_id = p.object_id inner join sys.dm_tran_session_transactions tst ON l.request_owner_id = tst.transaction_id
and object_name(p.object_id) = '<tableName>'
d. 执行以下查询来确定现有锁定的存在时间，方法是传入上一步骤中检索的 session_id：
select datediff(second, (select last_batch from master.dbo.sysprocesses where spid = <session_id>), CURRENT_TIMESTAMP)
e. 如锁定的存在时间高于设定阈值，请利用上一查询结果中的 session_id，通过以下命令来终止保持给定表格锁定的进程：
kill <sessionId>;
EnsembleTracker 错误
如果您在应用程序日志中遇到与如下所示相似的错误，即使 ZooKeeper 服务器已启动且正在运行，问题也可能是 Apache Curator 框架无法处理配置更改。
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}
解决方案是在 zoo.cfg 中更改所使用的服务器映射的配置，以包括客户端端口。
以下配置可能会导致错误：
server.1= xx.xxx.x.xx:2888:3888
server.2= xx.xxx.x.xx:2888:3888
server.3= xx.xxx.x.xx:2888:3888
因此，更新配置以包括客户端端口，如下所示：
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
这对您有帮助吗?