ThingWorx 部署架構
以下幾節包括典型 ThingWorx 部署的示意圖。架構範圍從簡單開發系統到多節點叢集,以及整體聯合生產系統。如需有關 ThingWorx 元件的資訊,請參閱
ThingWorx Foundation 部署元件。
部署選項
• PTC 雲端服務 - 在管理服務部署中,ThingWorx 應用程式會在協力廠商伺服器 (通常是私人雲端) 上接受託管及管理。外部組織負責管理必要的基礎結構及確保效能。
對於關注管理 ThingWorx 所需 IT 負擔與專業知識的公司,PTC 提供了管理服務部署選項。利用 PTC 雲端服務,購買 ThingWorx 的公司可以加快部署、最小化 IT 成本與需求,並確保保有持續的效能。PTC 雲端服務會將您的 ThingWorx 解決方案託管在能夠持續進行應用程式管理、效能調整與更新之商業雲端服務內的安全環境中。如需詳細資訊,請參閱
www.ptc.com/services/cloud。
• 內部部署 - 使用內部部署即表示在您自己的網站或資料中心的伺服器上安裝及執行 ThingWorx 軟體。您負責採購、安裝和維護基礎結構與軟體應用程式,以及其在健全性、可用性與效能等方面的持續支援。
透過內部部署,您可以自行執行部署,或接洽 PTC 專業服務 (或 PTC 認證的合作夥伴) 來管理部署。此選項適用於具有穩固 IT 組織,以及必須維持內部控制的公司。
如需其他詳細資訊,請參閱下列部份:
ThingWorx Foundation 基本生產系統
對於基本生產系統而言,建議在單獨伺服器上操作資料庫。這是一個很好的中小型企業系統,或中大型製造系統。
元件清單 | 元件數 |
---|
負載平衡器 | 1 |
ThingWorx Connection Server | 1 |
ThingWorx Foundation 伺服器 | 1 |
附加的或 NAS 檔案儲存 | 1 |
資料庫 | 1 |
ThingWorx Foundation 大型生產系統 (非 HA)
大型生產系統整合了其他元件,以支援更多數目的連線裝置及高資料擷取率。
除了平台元件以外,大型生產系統也可能包括 ThingWorx Connection Servers 與 InfluxDB 時間序列資料庫。
InfluxDB 系統會擷取來自資產的資料,ThingWorx 會將其作為已記錄的值串流內容來管理。
維護 ThingWorx 模型仍需要關聯式資料庫。
根據擷取與高可用性需求,可在單一節點或多節點 (企業) 組態中部署 InfluxDB。如需其他詳細資訊,請參閱
使用 InfluxDB 作為持續性提供者。
元件清單 | 元件數 |
---|
負載平衡器 | 1 (將裝置流量分配至連線伺服器) |
ThingWorx Connection Server | 2..n (視裝置數而定) |
ThingWorx Foundation 伺服器 | 1 |
關聯式資料庫 | 1 |
InfluxDB (單一節點) | 1 |
ThingWorx 生產聚集 ·
針對高可用性 (HA) 部署,會新增其他元件以移除應用程式與資料層中的單一失敗點。ThingWorx 平台需要下列元件:
• 高可用性負載平衡器。連線伺服器與 Foundation Server 節點群組都需要負載平衡器實例來分配負載。如果使用,Influx Enterprise 叢集也需要實例。許多負載平衡器選項可以為多個實例提供服務 - 如果適當配置,可以使用單一設備來為所有三個實例提供服務。
• 兩個 (或多個) ThingWorx Connection Servers。在叢集操作中,需要有連線伺服器才能跨整個叢集分配裝置負載,或在發生節點失敗時重新分配。
• 兩個 (或多個) ThingWorx Foundation 實例。每個節點都處於使用中狀態 - 將在它們之間分配負載。
• ThingWorxStorage 是共用的磁碟上儲存空間 (每個節點皆可存取)。
| 針對完整的高可用性部署,負載平衡器與共用的 ThingWorxStorage 也應實行冗餘。 |
• 用來為 ThingWorx Foundation 節點提供共用快取的 Apache Ignite 節點。
• 三個 Apache ZooKeeper 節點。ZooKeeper 會監視 ThingWorx 節點以決定每個節點是否有回應,以及是否如預期般運作。ZooKeeper 節點會形成仲裁,確定 ThingWorx 節點離線的時間。如果 ThingWorx Foundation 節點離線,ZooKeeper 會重新配置 ThingWorx 負載平衡器,以將流量引導至其他 Foundation 節點。
PostgreSQL 資料庫需要下列元件:
• PostgreSQL 伺服器節點 - 最少使用兩個節點,最好是三個。
• pgpool-II 節點 - 在 PostgreSQL 伺服器失敗的情況下,執行容錯移轉與復原任務的最少兩個節點,最好是三個。這些節點會維持用戶端 (ThingWorx) 與伺服器 (PostgreSQL) 之間的連線,並管理 PostgreSQL 伺服器節點之間的內容複寫。
InfluxDB Enterprise 系統需要下列元件:
• InfluxDB Enterprise 中繼節點 - 建議使用三個節點的設定,以便能夠達到仲裁,並允許叢集在一個節點失敗時繼續操作。
• InfluxDB Enterprise 資料節點 - 可以是一個,但建議您至少使用兩個。建議節點計數能由您的 InfluxDB 複製係數整除。
如需有關在高可用性環境中部署 ThingWorx 的其他詳細資訊,請參閱
ThingWorx 高可用性。
大規模 + 高可用性叢集
在此圖中,叢集的每個元件都位於自己的實體電腦、虛擬機器或容器中。如此可在單獨擴充每個不同的元件群組方面提供最大的彈性。
元件清單 | 元件數 |
---|
ThingWorx 連線 伺服器 | 2..n (根據裝置計數) |
負載平衡器 | 2 或 3 個實例: • 將裝置流量路由至連線伺服器 • 在 ThingWorx 節點之間路由流量 • 在 InfluxDB Enterprise 資料節點之間路由流量 (如果使用) |
ThingWorx Foundation 伺服器 | 2 .. n:根據高可用性與擴充性需求 |
網路/企業儲存 | 與所有 ThingWorx Foundation 伺服器共用之 ThingWorx 儲存存放庫的磁碟空間。 |
Ignite | 兩個選項: • 內嵌於 Foundation 流程內 • 2 或多個單獨節點 (視 HA 需求而定) |
ZooKeeper | 最少 3 個。應在奇數分配中。 |
資料庫 | 取決於資料庫: • PostgreSQL:3 個資料庫節點 + 2 個 pgpool-II 節點 • MS SQL Server (無圖):最小 2 個作為容錯移轉組態的一部份。 |
InfluxDB Enterprise | 5 個 (或更多): • 3 個中繼節點 • 2 或多個資料節點,總計數可由複製係數整除 |
最小叢集佔用空間
在此圖中,會將元件封裝或編組到一組較小的實體/虛擬機器或容器上。
此組態可用於高可用性,但與元件共用資源的分散式組態相比,擴充性較低。
此圖也可用於查看多個獨立 ThingWorx 部署利用相同共用基礎結構 (ZooKeeper、DB、網路儲存) 的部署。
元件清單 (每個叢集節點) | 元件數 |
---|
ThingWorx Connection Server | 1個 (每個叢集節點) |
ThingWorx Foundation 伺服器 | 1個 (每個叢集節點) |
Ignite | 無 - 在每個 Foundation Server 流程內以內嵌模式執行。 |
元件清單 (共用) | 元件數 |
---|
負載平衡器實例 | 2 或 3 個實例: • 將裝置流量路由至連線伺服器。 • 在 ThingWorx 節點之間路由流量。 • 在 InfluxDB Enterprise 資料節點之間路由流量 (如果使用)。 |
ZooKeeper | 最少 3 個。應在奇數分配中。 |
資料庫 | 請參閱上個圖。 |
網路/企業儲存 | 與所有 ThingWorx Foundation 伺服器共用之 ThingWorx 儲存存放庫的磁碟空間。 |