ThingWorx 高可用性 > HA 叢集疑難排解
HA 叢集疑難排解
應用程式金鑰存在於每部伺服器上，但其值為空白
當每部伺服器上的加密金鑰不同時，會發生此問題。如果未正確共用 keystore，可能會發生此情況。
您可以使用安全性管理工具來配置 keystore 密碼與 keystore.pfx 檔案。然後，應將 ThingworxStorage 目錄共用給每個平台實例。
如果無法共用，您必須先啟動一部伺服器來建立 keystore 密碼與 keystore.pfx 檔案，然後將其複製到另一部伺服器，之後再啟動該伺服器。
1. 啟動一部伺服器來建立 /ThingworxPlatform/keystore-password 與 /ThingworxStorage/keystore.pfx 檔案。
2. 將這兩個檔案複製到其他伺服器，然後啟動其他伺服器。
在伺服器 A 上建立的物件不在伺服器 B 上
高可用性 (HA) 的運作方式是透過資料庫同步處理模型。此同步處理會約每 100 ms 進行一次，但可以配置。所有伺服器都必須指向相同的 PostgreSQL 資料庫實例；因此，請檢查平台設定中的資料庫組態，以確保連線設定相符。如果您要在 HA 叢集中執行 PostgreSQL，必須遵循使用 Pgpool-II 與主要-次要 PostgreSQL 的 PostgreSQL HA 組態。
並未在所有伺服器上設定內容值
如果您在伺服器 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 組態。如果此金鑰不存在或不相符，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 位址時，如果電腦有一個位址 (例如，192.168.x.x 或 10.10.x.x，通常為 IPv4) 時，此方法將會優先採用網站本機 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
這是否有幫助?