iServFT
傳統高可用技術在異常發生後需重新分配資源並重啟服務，可能導致業務中斷與效能下降。而 iServFT 採用先進容錯技術，於意外發生時可即時無縫移轉服務，確保系統持續運行、不間斷服務。透過智慧監控與自動調整機制，iServFT 不僅提升運算效率，更有效降低風險，讓企業運營更加穩定、安全且具彈性。
# Non Stop
容錯技術
透過 iServFT 突破限制，全面提升穩定性
傳統高可用技術在異常發生後，必須重新分配資源、重新啟動服務
- 連線中斷、重新啟動部分服務有風險且耗時較長
- 或需重新開發服務以利用負載平衡等機制
主要服務主機
備援主機
在備援主機上重新啟動服務
容錯技術於意外發生時可無中斷移轉服務
- 透過即時快照與複製整部虛擬機器，處理器、記憶體、硬碟與網路卡狀態可隨時移轉
主要服務主機
備援主機
無中斷移轉並繼續服務
適用情境
需要更高可用性的自動化設備或系統服務
重新啟動與恢復客戶端不易的服務
開發或更新軟體成本受限制的傳統/特殊應用程式
# Non Stop
虛擬機器接手流程
系統正常運作
主要服務主機傳送裝置狀態、記憶體與硬碟增量備份資料，維持備援主機為有效副本。
只有當副本已確認有效時，客戶端才會收到回應。
主要服務主機故障
備援主機從兩條線路逾時無法取得主要服務主機回應，立即準備接手服務。
備援主機接手服務運作
備援主機發送 ARP 位址廣播使網路基礎建設重新導向客戶端封包，繼續提供客戶端服務。
備援主機擁有完整的服務執行中狀態，故客戶端僅會感受些許延遲。
# Modern
適用於不同情境的備援模式
| 容錯備援 ( FT ) | 災難備援 ( DR ) | |
|---|---|---|
| 備份內容 | VM 整機 | VM 整機 / 僅硬碟 |
| 應用程式無中斷 ( 透明轉移 ) | 是 | 無 ( 回溯到最後回復點 ) |
| RPO ( 回復點目標 ) | 0 ( 無資料損失 ) | 秒~小時 ( 依設定 ) |
| 自動故障偵測與轉移 | 支援 | 支援 |
每部 VM 所占頻寬 ( 實際情況視保護的應用程式而定 ) | 未壓縮 : 3~5 Gbps 啟用壓縮 : 300Mbps ~ 1Gbps ( 建議總可用頻寬至少為 10Gbps 等級，以降低延遲) | 50Mbps ~ 1Gbps ( 可用頻寬影響 RPO 達成率 ) |
| 應用程式效能影響 | 視應用程式 | 幾乎不影響 |
| 降低傳統備援模式 ( 僅硬碟資料 ) | 否 | 可，單一還原點 |
# Modern
iServFT 與類似產品部署方式、需求對照
| iServFT ( FT Mode ) | VMware Fault Tolerance | Stratus everRun ( fault tolerance ) | |
|---|---|---|---|
| 部署方式 | 獨立安裝 或 與 iServCloud / OpenStack 共存 | 需搭配 vCenter | 獨立安裝 |
基礎作業系統 ( Host OS ) | Ubuntu 20.04 或支援 docker 的其他 Linux 系統發行版( RHEL, CentOS, debian ) | VMware ESXi | 僅可用由 Stratus 提供的 CentOS 7 |
| Host 網卡等其他硬體相容性 | 與 Host OS 相同 | 僅 VMware 相容硬體 | 僅 CentOS 7 相容性 |
| Controller 離線後可繼續控制 FT | 可 | 只能停止 | 可 |
| FT 資料傳輸預留頻寬建議 | 1 Gbps 或以上 | 10 Gbps 或以上 ( Fault Tolerance Logging ) | 10 Gbps 或以上 ( A-Link ) |
| Guest OS 限制 | Win Server 2008R2-2022, Windows 11, Linux, FreeBSD 等等常見作業系統 ( 支援 virtio 網卡驅動程式即可 ) | 常見作業系統 ( Windows 11 需 vSphere 8.0 updatae 1 授權 ) | Windows 10 / Server 2012-2022 / Linux |
| 授權限制 | ( 可洽談 ) | vSphere Standard ( 2 vCPUs) vSphere Enterprise Plus ( 8 vCPUs ) ( per VM; no host maximum ) | everRun Enterprise |
# Modern
iServFT 與類似產品部署方式、需求對照
| iServFT ( FT Mode ) | VMware Fault Tolerance | Stratus everRun ( fault tolerance ) | |
|---|---|---|---|
容錯技術基礎 ( 註1 ) | 連續檢查點 | 連續檢查點( vSphere 6.0~8.0 ),vLockStep( vSphere 4.x ) | 連續檢查點 |
備援主機同步方式 ( 註2 ) | Active-Passive | Active-Passive | Active-Passive |
| 虛擬化技術 | KVM | VMware ESXi | KVM |
| 支援 UEFI + TPM | 可 | 可 | 無 |
作業系統核心版本特殊限制 ( 註3 ) | 無 | ( 自行開發的作業系統 ) | 有 ( everRun 客製化 ) |
註 1 :
連續檢查點可簡單理解為對 VM 持續做毫秒級的增量快照做為容錯的基礎。vLockstep 則為同步於備援主機執行處理器指令，但無法支援多核心系統，現已不被 VMware 支援(在該公司相關文件會稱為 Legacy FT)。
註 2 :
Active-Passive: 備援機平時僅 VM 暖機暫停，不會啟動 VM CPU；Active-Active 備援機則會主要主機與備援主機皆啟動 VM CPU 執行相同 VM，透過封包比對與控管技術減少所需的備援資料傳輸量，代表產品如 HUAWEI FusionSphere / COLO (COarse-grained LOck-stepping Virtual Machines)。
註 3 :
客製化作業系統核心可以提高容錯系統的效率，但會因此綁定作業系統核心版本，後續安全性更新和硬體支援會有明顯延遲或窒礙難行，難以跟上游發行版 (RHEL/Ubuntu/Debian等) 同步更新和修正問題，且不易與其他虛擬化平台整合於同一主機。iServFT 建議使用通用的 linux kernel，版本至少為 4.15 或以上，多數 linux 發行版 (Ubuntu 18.04/20.04/22.04, RHEL 8/9, Debian 10/11/12) 預設即符合建議。