ThingWorx 叢集大小設定考量因素
設定 ThingWorx Foundation 節點的大小
在叢集操作中，個別 ThingWorx Foundation 節點的大小設定很大程度上不會變更。每個叢集節點都必須有足夠的記憶體才能載入整個物模型。因此，每個叢集節點的大小必須與單一伺服器節點的大小相符。例如，中等大小的單一伺服器為 16 vCPU 和 32 GiB RAM。同樣地，對於雙節點的叢集，每個叢集節點都將是 16 vCPU 和 32 GiB RAM。
如果單獨部署 Apache Ignite，Foundation Server 記憶體耗用可能會略微減少，因為內容狀態資訊已傳輸至 Ignite 節點。
CPU 使用率會增加以執行背景叢集同步處理任務。由於共用快取的延遲會增加，因此個別操作在叢集組態中也可能會稍微慢一些。這會因在跨多個節點之間以平行方式 (企業邏輯和/或使用者請求) 執行大量作業的能力而有所補償。
針對高可用性，確定了個別節點的正確大小之後，建議您至少多部署一個需要的 ThingWorx Foundation 節點，來處理應用程式的峰值負載。這可讓叢集在單一節點失敗時繼續符合效能的期望。
設定連線伺服器節點的大小
在叢集操作中，需要有連線伺服器才能跨整個叢集分配裝置負載，或在發生節點失敗時重新分配。
與 Foundation 節點一樣，建議您至少多部署一個需要的連線伺服器，以處理預期的裝置計數。這可讓連線伺服器在單一連線伺服器節點失敗時維持與所有裝置的連線能力。
有關各「連線伺服器」選項的系統需求，請檢閱 ThingWorx Connection Services 說明中心。
設定 Apache Zookeeper 節點的大小
Apache ZooKeeper 是用於同步處理分散式應用程式的開放原始碼解決方案。其為 ThingWorx 節點提供監視及前置節點的選擇。
建議使用三節點集，每個都具有 2 個 vCPU 與 2 GiB 的 RAM。欲維持仲裁，實例數必須是奇數。
如需詳細資訊，請參閱 Apache Zookeeper 系統需求：https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html#sc_systemReq
設定資料庫節點的大小
在高可用性之外，叢集 ThingWorx 組態中的資料庫負載也會增加。為了說明這種情況，相同的負載測試使用了 Microsoft Azure 虛擬機器來以五種不同的「中等」部署執行：
|
單一節點與叢集效能比較 (僅限 PostgreSQL)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
無
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
1 × F16s_v2
|
|
InfluxDB
|
無
|
無
|
無
|
無
|
無
|
|
每個節點的結果 (平均)
|
26,000 WPS
19 次 HTTP 運算
|
12,000 WPS
10 次 HTTP 運算
|
10,000 WPS
6 次 HTTP 運算
|
7,000 WPS
6 次 HTTP 運算
|
6,000 WPS
2 次 HTTP 運算
|
|
結果總數
|
24,000 WPS
19 次 HTTP 運算
|
30,000 WPS
24 次 HTTP 運算
|
28,000 WPS
22 次 HTTP 運算
|
30,000 WPS
12 次 HTTP 運算
|
|
|
提醒：大小設定指南建議適用於使用初始基線來設定 ThingWorx 實行的大小。個別結果會根據邊緣配置、應用程式負載等而有所不同。
|
|||||
雖然以上測試顯示了較小資料擷取的改善，但由於資料庫資源不足，HTTP 請求效能不會改善。
為了解決此問題，可利用較大的 RDBMS 實例與/或使用 InfluxDB 來改善擴充性，如以下所指示。
|
單一節點與叢集效能比較 (PostgreSQL + InfluxDB)
|
|||||
|---|---|---|---|---|---|
|
Foundation
|
1 × F16s_v2
|
2 × F16s_v2
|
3 × F16s_v2
|
4 × F16s_v2
|
5 × F16s_v2
|
|
Ignite
|
無
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
3 × F8s_v2
|
|
PostgreSQL
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
InfluxDB
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
1 × F8s_v2
|
|
每個節點的結果 (平均)
|
90,000 WPS
120 次 HTTP 運算
|
53,000 WPS
187 次 HTTP 運算
|
39,000 WPS
148 次 HTTP 運算
|
31,500 WPS
127 次 HTTP 運算
|
27,000 WPS
108 次 HTTP 運算
|
|
結果總數
|
106,000 WPS
375 次 HTTP 運算
|
118,000 WPS
445 次 HTTP 運算
|
126,000 WPS
508 次 HTTP 運算
|
135,000 WPS
540 次 HTTP 運算
|
|
|
提醒：大小設定指南建議適用於使用初始基線來設定 ThingWorx 實行的大小。個別結果會根據邊緣配置、應用程式負載等而有所不同。
|
|||||
 |
InfluxDB 開放原始碼之前用於這些測試，但不提供高可用性。建議將 InfluxDB Enterprise 用於生產 ThingWorx 叢集實行。針對 InfluxDB Enterprise 大小設定，請依指示規劃兩個 InfluxDB「資料」節點，加上三個「中繼」節點，通常為每個有 1-2 個 vCPU 與 0.5-1GiB 的 RAM。如需有關 InfluxDB 大小設定的更多指引，請審核 https://docs.influxdata.com/influxdb/v1.8/guides/hardware_sizing/。
|
設定 Apache Ignite 節點的大小
在 ThingWorx 叢集中，Apache Ignite 為內容值與檔案傳輸工作等其他資料提供共用快取。
Ignite 可以內嵌在 ThingWorx Foundation 流程中，而不需要單獨安裝。或者，為了達成更大的負載分配，也可以將 Ignite 部署為單獨的叢集。
Ignite 也能夠以下列兩種模式執行：
• PARTITIONED 模式 - 資料會平均分為幾個分區，並在參與節點之間等距分割。最佳快取-寫入效能。
• REPLICATED 模式 - 每個 Ignite 實例都有每個資料點的副本。最佳快取-讀取效能。
如需詳細資訊，請參閱快取模式的 Apache Ignite 文件集：https://apacheignite.readme.io/docs/cache-modes
Ignite 的主要負載是每個 ThingWorx Foundation 與 Ignite 實例之間的網路輸送量。雖然 CPU、磁碟或記憶體需求可能會指出來自雲端服務供應商的 VM 大小較小，但監視受限制或管控的網路輸送量是很重要的。
如果遇到輸送量的問題，則可透過移動至具有較大網路容量的較大系統，或透過新增其他 Ignite 節點 (使用分割模式) 來分配負載，藉以解決這些問題。
作為粗略的起點，與 ThingWorx Foundation 節點相等的記憶體大小將是一種安全的保守預估。
欲更精確地計算共用快取的記憶體佔用空間：
1. 計算 ThingWorx 內容快取的 VTQ (值、時間戳記與品質) 記憶體佔用空間。
a. 針對每種類型的物件，確定記憶體中的資料類型大小。例如，如果您的內容是 50 個字元的字串，且每個字元都需要 2 個位元組，該字串將需要 100 位元組的記憶體。
b. 新增 8 個位元組。(4 個位元組用於該值的日期/時間，另外 4 個位元組用於值的品質)。
c. 乘以 2。ThingWorx 會快取每個內容的目前值與先前值。
d. 乘以該類型物件的數目。
e. 將每個物件類型的結果相加。
2. 針對 Ignite 的記憶體內值索引，加上 30%。
3. 乘以您要跨 Ignite 叢集的資料副本數。例如，如果您想要資料的一個備份，以便在單一 Ignite 節點失敗時不會遺失資料，則乘以 2。
4. 除以您計畫部署的 Ignite 叢集節點數。
5. 每個 Ignite 節點將需要額外的 ~300 MB 供其自己操作。
如需其他詳細資訊，請參閱 Apache Ignite 文件集：https://apacheignite.readme.io/docs/capacity-planning