隨著新基建提速換擋，必將帶動基礎設施即服務的新一輪增長。當我們關注高光專案的同時，不應忽略傳統IT需求，傳統IT領域很多應用上雲面臨種種困難，如何讓他們在新基建浪潮提速？

比如在工業製造業、交通、能源電力等傳統行業的業務場景中，可用性永遠是高頻詞彙，如何讓應用主機在不同物理節點之間實現秒級切換？如何獲得可靠、高效的FT/HA技術讓使用者服務“永不宕機”？

在前一篇文章《邊緣計算體驗之二：簡單高可用 ZStack Mini的巧妙設計》中，介紹了ZStack如何在2U機箱設計的ZStack Mini中實現了高可用（HA）。

當監測到物理節點故障無法為應用伺服器提供服務的時候，高可用就將應用伺服器遷移到正常執行的物理節點上，保證業務的連續性，但是業務系統也會受到輕微影響，基於HA的高可用依舊有數分鐘的業務中斷。

這在有些場景下是不可接受的，比如一些場景需要秒級的切換，以保證業務的連續性。在本篇文章中，將介紹ZStack Mini 3.0中的核心功能——FT。

ZStack Mini 3.0——讓易用性更上一層樓

ZStack Mini 3.0是ZStack Mini產品家族的一次重大升級，主要是軟體部分的升級。可以在保持ZStack Mini邊緣計算一體機硬體不變的情況下，將軟體版本從原來的2.0升級到最新的3.0，獲得更多對中小企業實際使用非常有幫助的功能。

ZStack Mini一體機升級到3.0後的管理中心介面，從左側邊欄可以看到，與2.0相比，多了“應用中心”、“我的應用”、“外接磁碟備份”等選單，同時在上圖看不到的是在“儲存”中多了“FC-SAN儲存”的功能。

FC-SAN儲存功能，讓ZStack Mini可以外接FC-SAN儲存陣列，幫助企業更好地利用資料中心內已有的FC-SAN儲存，可以利舊，並有助於資料流通與整合。

在ZStack Mini邊緣計算一體機中安裝額外的FC-HBA卡，即可與資料中心內的FC-SAN儲存進行連線。上圖紅框中即為FC-HBA卡，正與外接FC-SAN儲存進行資料整合

外接磁碟備份，顧名思義，就是通過將USB介面的行動硬碟（或U盤）接入ZStack Mini平臺，將ZStack Mini平臺中現有的資料備份到磁碟之中。

應用中心，在E企研究院測試的ZStack Mini中集成了三個應用模板，分別為MariaDB、LNMP和Tomcat，這是許多中小企業利用Apache開源軟體構建網站的“三駕馬車”，可以說是自建網站的最經典的選擇。

如果利用虛機安裝這三個應用，可能需要花費數小時，而且還極有可能出錯。現在ZStack Mini將這三個應用軟體整合到“應用中心”內，通過滑鼠點選即可一鍵部署，並在數分鐘內完成可用。可以說極大地節省了使用者在安裝、部署和維護方面的難度。

通過這些功能加入，ZStack Mini邊緣計算一體機平臺不但具備已有的簡單易用功能，同時也讓企業使用者在業務部署、後期維護上更簡單。這也與ZStack Mini邊緣計算一體機的易用性特點是一脈相承的，產品的使用並不會因為升級而變得複雜。

接下來，將介紹ZStack Mini 3.0中最重磅的功能——FT功能。

FT——讓可用性進一步提高

在前一篇文章中，採用HA（High Availability，高可用）對ZStack Mini中的虛機進行保護的話，業務依舊會有1分鐘左右的中斷，那麼ZStack Mini 3.0中新加入的FT（Fault-Tolerance，容錯）功能則能夠做到真正意義的秒級切換，且不會對業務造成影響。

在ZStack Mini邊緣計算一體機平臺中，E企研究院事先建立了一個目前最火熱的應用之一——視訊直播。其由兩個虛機構成：

視訊推流伺服器：其作用類似於我們智慧手機的直播App，將手機攝像頭“看到”的影象上傳到雲端的伺服器。稍微與直播不同的是，在演示中，E企研究院用一段視訊替代直播影象，在視訊推流伺服器中將一段視訊實時推流到線上編碼伺服器。

線上編碼伺服器：手機中的直播App將影象上傳到雲端的編碼伺服器，編碼伺服器進行編解碼，然後再推送到觀眾的手機或電腦端（接收端）。在演示中，則用演示用的膝上型電腦作為接收端。

首先，我們在視訊推流伺服器中將一段視訊流推送到線上編碼器，然後用膝上型電腦接收經過線上編碼伺服器處理的音視訊訊號。視訊推流伺服器——線上編碼伺服器——接收端，構成了一個最簡化的視訊直播應用環境。其中，線上編碼伺服器是企業為終端使用者提供視訊直播服務的核心，一旦其出現故障，無法正常執行，整個直播服務將會中斷。

在視訊中，線上編碼伺服器位於IP地址為“172.24.100.3”的物理主機之上，並開啟了FT保護模式。同時在ZStack Mini管理平臺中可以看到，線上編碼伺服器會有一臺備用的雲主機，在“FT輔助雲主機資訊”面板可以看到，其備用雲主機正常執行在IP地址為172.24.100.4的物理主機之上。

線上編碼伺服器詳情，本身位於172.24.100.3物理主機之上，使用FT保護模式，其備用雲主機位於172.24.100.4物理主機之上

在視訊直播正常執行過程中，E企研究院將線上編碼伺服器所在的物理主機（即172.24.100.3）進入維護模式，以模擬這臺物理主機出現故障，需要停機維護，暫時無法提供服務。

在物理主機進入維護模式時，切換到膝上型電腦接收端，音視訊訊號一切正常，並沒有出現停頓。再看線上編碼伺服器的狀態，虛機已經切換到172.24.100.4物理主機之上，因為其原來所在的物理主機進入維護模式（172.24.100.3）。

ZStack Mini邊緣計算一體機最小二節點部署，因為其中一臺物理主機進入維護模式，原本位於172.24.100.3的線上編碼伺服器在第一時間就切換到了172.24.100.4物理主機之上，視訊直播業務正常執行。但是通過上圖可見，線上編碼伺服器已經不再處於保護狀態，因為其已經沒有了備用的雲主機，正處於“單工模式”，一旦其所在的物理主機也需要停機，將影響正在執行的直播業務。因此還是要儘快將故障的物理主機修復或替換，重新上線作為備份節點。

在這個測試驗證場景中，E企研究院進入到“一體機”介面中，將處於“維護模式”的172.24.100.3這臺物理主機啟用，表示故障修復，重新上線。

在172.24.100.3這臺物理主機恢復上線之後，線上編碼伺服器的FT功能自動檢測到新主機加入，將再次恢復FT保護級別；但是，在172.24.100.3這臺物理主機進入維護模式這段時間，視訊直播應用一直在正常執行，不斷產生新的資料，同時記憶體狀態也在實時變化。

這意味著要恢復線上編碼伺服器的“FT保護級別”需要進行資料同步，不僅是儲存的資料同步，還包括記憶體狀態的同步；同步資料與記憶體狀態，在以往的高可用方案中都是一個非常困難的問題，因為一旦出錯，就會造成資料不一致，甚至可能影響到正常執行的業務。

但是在ZStack Mini邊緣計算一體機中，在經過數分鐘的同步之後，線上編碼伺服器重新達成FT保護，視訊直播業務並沒有受到影響。

如上圖所示，線上編碼伺服器重新達成FT保護級別，其所在物理主機的IP地址為172.24.100.4，而原來的172.24.100.3的物理主機則承載備用雲主機，與測試之前的狀態相比，主、備進行了切換，但業務依舊正常執行。

從ZStack Mini 2.0中HA切換需要數分鐘業務停頓——這也是目前大多數虛機遷移或故障切換所需要的時間，到3.0中FT保護縮短到秒級，切換時間極大地被縮短，但並沒有引入新的硬體，也沒有提升使用難度，那麼FT究竟是怎樣的技術？

FT技術背後的原理

傳統的基於SAN儲存的資料保護通常要麼對業務造成短暫影響，要麼需要額外解決方案介入，不在本文討論範圍內。在基於虛擬化技術的雲環境中，虛機遷移或虛機故障切換通常都需要一定的時間，就如同ZStack Mini 2.0中的HA技術一樣，本質上，這都採用的相同技術。

要保證部署虛機上的業務在遷移或切換時儘量不受影響，其最重要的一環就是資料同步——包括儲存資料同步和記憶體狀態同步。因為應用程式不間斷執行，不停產生資料並改變記憶體狀態，這就給資料同步並保持資料一致性帶來極大的挑戰。目前虛機間主流的資料同步方式採用鎖步（Lock-stepping）或連續檢查點（Continuous Checkpoint）。

但這兩種資料同步方式各有各的不足，比如鎖步會導致複製開銷過多，因為虛擬機器中的記憶體訪問是不確定的；而連續檢查點同樣會導致過多的複製，同時還會帶來額外的網路延遲。

ZStack通過與英特爾的合作，延伸出一種新的資料同步方式——粗粒級鎖步（COarse-grain LOck-stepping，簡稱COLO），來實現FT功能所需的快速切換。其通過比較主虛機（Primary VM，PVM）與備用虛機（Secondary VM，SVM）的傳輸資料包來進行資料同步。

粗粒級鎖步（COLO）架構示意圖，其分別通過快複製程序與COLO代理，以及COLO Frame程序來實現資料與記憶體狀態在PVM與SVM之間的同步

因為涉及到儲存資料和記憶體狀態的同步，所以其由不同軟體模組（並行）實現。比如儲存資料同步如下所示：

在儲存資料讀寫方面：

當應用發起讀請求，不僅PVM直接從自身儲存進行資料讀取，SVM也會進行相應的讀取操作，只是正常狀態下並不傳輸給應用。

當應用發起寫請求，PVM將寫請求傳送給SVM，同時將資料寫入自身儲存；而SVM接收到寫請求後，會將原始資料載入到SVM Cache並進行寫入（Copy On Write）。

在記憶體狀態同步方面，COLO採用了一種巧妙的同步方式，如下圖所示：

如上圖所示，主節點會對PVM的髒頁（Dirty Pages）進行跟蹤，並將其傳送到備用節點。備用節點再收到PVM的髒頁之後，將其儲存在PVM記憶體快取（Memory Cache）中，然後在檢查點，將PVM記憶體快取中的狀態更新到SVM記憶體之中。

在之前的COLO技術中，COLO Proxy通常採用核心方案（Kernel Scheme），功能更強但不夠靈活，但最新COLO技術中，基於目前更為流行的使用者空間方案（Userspace scheme）的Proxy程序則具有更佳的靈活性。

通過對FT功能背後的技術解析，我們可以看到ZStack不僅關注使用者的使用體驗，盡最大努力將ZStack Mini的使用做到最簡化，還深入使用者實際業務需求，將ZStack Mini平臺與應用連通，提供更加簡化的使用體驗。

同時，ZStack也沒放棄對創新技術的追求，通過了解使用者痛點與難題，進行鍼對性的開發與合作，用整個生態的力量去改變產品體驗，並將最新的技術融入產品中，傳遞給使用者，幫助使用者在最快時間享受到創新技術帶來的便利。