失敗發生時的預期行為
本節說明 ThingWorx HA 組態中發生的動作，它會針對一個或多個元件的失敗作出回應。
ThingWorx 伺服器失敗
ThingWorx 前置節點失敗
已制定的 HA 程序
1. ZooKeeper 未收到前置節點的回應。
2. ZooKeeper 從待命的 ThingWorx 伺服器集區中選擇新的前置節點。
3. ZooKeeper 會通知待命的節點以使其成為前置節點。
4. 新的前置節點會完全連線至資料庫並初始化 ThingWorx 模型。
5. 新的前置節點會向負載平衡器傳送確認以將所有 ThingWorx 請求路由至其本身。
6. 負載平衡器會將所有 ThingWorx 流量路由至新的前置節點。
負載平衡器失敗
動作與結果將取決於部署的負載平衡器 HA 解決方案。如果負載平衡器提供在所有負載平衡器節點間共用工作階段內容的功能，則不應中斷使用中的工作階段。
HAProxy 伺服器失敗
如果僅 HAProxy 節點失敗或所有 HAProxy 節點均失敗，則會出現下列情形：
• ThingWorx 前置節點仍可透過其 IP 位址存取，但無法透過 HAProxy IP 位址存取。
• 透過 HAProxy 向 ThingWorx 發出的請求將無法到達 ThingWorx。
如果多個 HAProxy 節點的其中一個失敗，則會出現下列情形：
• 備份 HAProxy 變成新的主節點後，即會在 ThingWorx Composer 中識別現有使用者工作階段。使用者應無需再次登入。
• 備份 HAProxy 變成主節點前不會載入混搭。
• 備份 HAProxy 變成主節點前不會載入 Composer 中的瀏覽實體。
• 備份 HAProxy 變成主節點前請求不會到達 ThingWorx。
Zookeeper 節點失敗
一個 ZooKeeper 節點失敗
如果三個 ZooKeeper 節點的其中一個失敗，則會出現下列情形：
• 其他 ZooKeeper 節點偵測到回應失敗。
• 如果失敗的節點為目前的前置節點，則會選擇新的 ZooKeeper 前置節點。
• 所有 ThingWorx 伺服器均不應受到影響。它們仍會保持使用中及可供存取狀態。
兩個 ZooKeeper 節點失敗
• 由於三個原始的 ZooKeeper 節點設定預期有兩個伺服器可用於形成仲裁，因此無法進行 ZooKeeper 前置節點選擇。允許的最大失敗數 = ceil(N/2) - 1
• 剩餘的 ZooKeeper 實例既不是前置節點，也不是待命節點。
• ThingWorx 前置節點將會關閉，因為它無法與 ZooKeeper 通訊以進行前置節點選擇。
• ThingWorx 待命伺服器將反覆嘗試與 ZooKeeper 通訊，直到至少有一個其他 ZooKeeper 節點恢復啟動。
• 兩個或多個 ZooKeeper 節點回到線上後，便可進行 ZooKeeper 前置節點選擇。ThingWorx 待命節點會重新連線至 ZooKeeper，並恢復為新的前置節點。
• 先前的 ThingWorx 前置節點必須重新啟動才能使其成為待命節點。
ThingWorx 與 ZooKeeper 失敗
當 ZooKeeper 與 ThingWorx 的前置節點均失敗時，會出現下列情形：
• 「一個 ZooKeeper 節點失敗」下所列的所有條件。必須首先確定新的 ZooKeeper 前置節點，以便隨後選擇新的 ThingWorx 前置節點。
• 「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 主節點後成功連線。
Pgpool-II 和 PostgreSQL 失敗
當 PostgreSQL 和 Pgpool-II 失敗時，會出現下列情形：
• PostgreSQL 待命節點會變為主節點。
• Pgpool-II 待命節點會變為主節點，並且虛擬 IP 位址會傳輸至此節點。
• 容錯移轉期間服務暫不可用。