ThingWorx 高可用性 > 失敗發生時的預期行為
失敗發生時的預期行為
本主題說明 ThingWorx 叢集組態中發生的動作,它會針對一個或多個元件的失敗作出回應。
負載平衡器失敗
動作與結果將取決於部署的負載平衡器 HA 解決方案。如果負載平衡器提供在所有負載平衡器節點間共用工作階段內容的功能,則不應中斷使用中的工作階段。
HAProxy 伺服器失敗
如果僅 HAProxy 節點失敗或所有 HAProxy 節點均失敗,則會出現下列情形:
ThingWorx 前置節點仍可透過其 IP 位址存取,但無法透過 HAProxy IP 位址存取。
透過 HAProxy 向 ThingWorx 發出的請求將無法到達 ThingWorx。
如果多個 HAProxy 節點的其中一個失敗,則會出現下列情形:
備份 HAProxy 變成新的主節點後,即會在 ThingWorx Composer 中識別現有使用者工作階段。使用者應無需再次登入。
備份 HAProxy 變成主節點前不會載入混搭。
備份 HAProxy 變成主節點前不會載入 Composer 中的瀏覽實體。
備份 HAProxy 變成主節點前請求不會到達 ThingWorx。
ThingWorx 伺服器失敗
當 ThingWorx 伺服器失敗時,會發生下列情況:
會將伺服器從負載平衡器中移除,因為健康狀況檢查 ping 將失敗。其移除時間取決於檢查頻率。
ZooKeeper 將偵測到伺服器已失敗,將其從內部服務探索中移除,並通知監測器,例如 Connection Server。
如果伺服器是單一伺服器,ZooKeeper 會通知其他伺服器,並選取新的單一伺服器。
連線至伺服器的用戶端在轉換時可能會收到錯誤,但其接下來會重新連線至新的伺服器。
在伺服器失敗或伺服器終止時,可能會遺失資料。在這些情況下,批次佇列中的資料將會遺失。如果伺服器關機而不是失敗,則伺服器取消註冊時會發生上述情況,且批次佇列會清空。
ThingWorx Platform 節點停機
只要至少一個 Platform 實例處於良好狀態,就可以在不影響系統的情況下重新啟動其他節點。但是,如果所有 Platform 節點都停機或狀況不良,則儲存在 ignite 中的狀態將會變為不一致。在此情況下,必須在重新啟動之前停止所有 Platform 節點,並停止所有 ignite 節點。
1. 停止所有 Platform 節點。
2. 停止所有 ignite 節點。
3. 重新啟動所有 ignite 節點。
4. 重新啟動所有 Platform 節點。
如果未重新啟動 ignite,則儲存在 ignite 中的繫結對應與其他資料將不會正確,並會導致在一段時間內發生奇怪行為。
ZooKeeper 失敗
節點失敗
如果其中一個 ZooKeeper 節點失敗,則會出現下列情形:
其他 ZooKeeper 節點偵測到回應失敗。
如果失敗的節點為目前的前置節點,則會選擇新的 ZooKeeper 前置節點。
多個節點失敗
如果多個節點失敗且 ZooKeeper 失去其仲裁,它將會進入唯讀模式,並拒絕變更請求。
由於三個原始的 ZooKeeper 節點設定預期有兩個伺服器可用於形成仲裁,因此無法進行 ZooKeeper 前置節點選擇。允許的最大失敗數 = ceil(N/2) - 1
剩餘的 ZooKeeper 實例既不是前置節點,也不是待命節點。
所有用戶端都將收到 SUSPENDED,並最終收到 LOST 狀態。
ThingWorx 伺服器
當處於 SUSPENDED 狀態時,會取消指派單一角色。在此期間,將不會執行任何計時器或排程器。
LOST 狀況下,所有節點都會關閉。
如果 ZooKeeper 在系統逾時之前恢復,將會選擇新的單一項目並繼續處理。
連線伺服器
如果 Connection Server 從 ZooKeeper 取得 LOST 狀態,它將會關閉,因為它並不知道 ThingWorx 伺服器的狀況。
Ignite
行為由其實行定義。如需詳細資訊,請參閱 https://apacheignite.readme.io/docs/zookeeper-discovery
假設 ZooKeeper 叢集一律在叢集的所有節點中可見。如果節點中斷與 ZooKeeper 的連線,它會關閉,而其他節點會將其視為失敗或中斷連線。
Ignite 失敗
Ignite 失敗的影響取決於資料複製層級。應一律將 Ignite 配置為將資料至少儲存在叢集中的兩個節點上。因此,如果遺失任何一個節點,都不會對系統造成任何影響。
如果遺失多個節點,可能會發生資料遺失,而這可導致系統處於不一致的狀態。如果發生這種情況,我們建議您將 Ignite 與 ThingWorx 完全關閉。然後您可以重新啟動 Ignite 並重新啟動 ThingWorx。Ignite 是應用程式記憶體,如果遺失,處理行為可能會非常不一致。
如果 Ignite 完全失敗,讓 ThingWorx 無法連線至任何 Ignite 節點,則 ThingWorx 將會關閉。
如需有關資料備份的資訊,請參閱下列內容:
PostgreSQL 失敗
有關 PostgreSQL 失敗的此類討論基於如下組態:
三個 PostgreSQL 節點 (寫入程式節點、讀取程式節點與待命節點)
在 PostgreSQL 節點間使用串流複製
管理 PostgreSQL 節點的用戶端存取以及管理 PostgreSQL 修復程序的兩個 Pgpool-II 節點
如果 PostgreSQL 伺服器失敗,則使用中的 Pgpool-II 節點會偵測到失敗並停止向此伺服器路由請求。如果在失敗前資訊尚未提交且已複製到其他節點,則在失敗時儲存的使用者或裝置資料可能會遺失。
當主 PostgreSQL 節點失敗時 (假設同步處理與潛在節點已啟動並執行),會出現下列情形:
透過 Pgpool-II 發生向同步節點的容錯移轉。潛在節點現在變成了新主節點的同步節點。仍然可以寫入資料庫 (例如建立新的實體並將資料寫入 BDWS)。
如果原始主節點恢復啟動,則需要手動清理並配置您的環境才能使用原始主節點。
當兩個待命節點均失敗時 (假設主節點仍處於啟動和執行狀態),會出現下列情形:
不會發生容錯移轉,並且主節點應沒有節點可用於複製。
Composer 將仍處於可存取狀態。即將載入的實體可供檢視,但無法儲存。可檢視記錄。
由於 PostgreSQL 必須將資料複製到待命節點,因此無法執行要求寫入至資料庫的動作 (例如建立及儲存實體、將值設定為持續性內容以及新增串流項目)。
當主節點與同步處理待命節點失敗時,會出現下列情形:
發生向潛在節點的容錯移轉。潛在節點目前為主節點,且無用於複製的節點。
Composer 將處於可存取狀態。即將載入的實體可供檢視,但無法儲存。可檢視記錄。
由於寫入將停滯並最終失敗,因此無法執行要求寫入至資料庫的動作 (例如建立及儲存實體、將值設定為持續性內容以及新增串流項目)。
當所有三個節點均失敗時,會出現下列情形:
由於沒有可用的節點,因此不會發生容錯移轉。
Composer 不具有資料庫的存取權限。因此,不應載入實體、大多數服務將無法運作 (與平台子系統類似的子系統服務仍可運作) 且系統功能將會受限 (記錄、系統監控和混搭仍可運作)。
資料庫的讀取和寫入將無法進行。
ThingWorx 和 PostgreSQL 失敗
當 ThingWorx 前置節點和 PostgreSQL 主節點均失敗時,會出現下列情形:
ThingWorx 前置節點關閉且 PostgreSQL 資料庫的同步節點變成 PostgreSQL 主節點後,待命 ThingWorx 實例會變成前置節點。
PostgreSQL 資料庫的潛在節點會變成新的同步節點。
ThingWorx Composer 可用且可寫入 PostgreSQL 資料庫 (可建立、編輯與刪除實體,並可新增資料)。
如果必須將原始的 PostgreSQL 主節點重設為主節點,則必須手動清理 PostgreSQL 節點和 Pgpool-II。
Pgpool-II 節點失敗
使用中的 Pgpool-II 節點失敗
如果使用中的 Pgpool-II 節點失敗,則備份節點會偵測到此節點並接管向 PostgreSQL 伺服器發送的全部請求之處理任務。登入使用中 ThingWorx 伺服器的使用者可能會遭遇應用程式延遲,而且可能遺失 Pgpool-II 節點失敗時所儲存的使用者或裝置資料。
所有 Pgpool-II 節點失敗
當所有 Pgpool-II 實例均失敗時,ThingWorx 會失去 PostgreSQL 內容的存取權限,且大部分功能都將失敗。某些受限功能在下列區域中可用:
記錄 - 應用程式記錄仍可透過錯誤訊息更新。
系統監控 (例如 MonitoringPlatformStats 混搭)
混搭 - 不依賴於服務或資料庫資料的小器具仍可運作。
非持續性內容的內容值
不牽涉資料庫的服務。
ThingWorx 和 Pgpool-II 失敗
當 ThingWorx 前置節點和 Pgpool-II 主節點實例同時失敗時,會出現下列情形:
ThingWorx 前置節點失去主導權,以致其中一個待命節點變成前置節點。
Pgpool-II 主節點將遺失虛擬 IP 位址。其中一個 Pgpool-II 待命節點將成為主節點,並且虛擬 IP 位址會被重新指派給此節點。
ThingWorx 待命伺服器會嘗試全面連線至資料庫,並在建立完新的 Pgpool 主節點後成功連線。
ThingWorx 前置節點失敗下所列的行為與程序適用。
Pgpool-II 和 PostgreSQL 失敗
當 PostgreSQL 和 Pgpool-II 失敗時,會出現下列情形:
PostgreSQL 待命節點會變為主節點。
Pgpool-II 待命節點會變為主節點,並且虛擬 IP 位址會傳輸至此節點。
容錯移轉期間服務暫不可用。
這是否有幫助?