隨著新基建提速換擋，必將帶動基礎設施即服務的新一輪增長。當我們關注高光項目的同時，不應忽略傳統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開源軟件構建網站的“三駕馬車”，可以說是自建網站的最經典的選擇。

在E企研究院使用的ZStack Mini中，集成了LNMP、MariaDB和Tomcat三個最常使用的應用

如果利用虛機安裝這三個應用，可能需要花費數小時，而且還極有可能出錯。現在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 3.0中的FT功能。

在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)進入維護模式，以模擬這臺物理主機出現故障，需要停機維護，暫時無法提供服務。

ZStack Mini邊緣計算一體機中，IP地址為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之間的同步

因為涉及到存儲數據和內存狀態的同步，所以其由不同軟件模塊（并行）實現。比如存儲數據同步如下所示：

COLO中的讀、寫流程示意圖

在存儲數據讀寫方面：

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

當應用發起寫請求，PVM將寫請求發送給SVM，同時將數據寫入自身存儲;而SVM接收到寫請求后，會將原始數據加載到SVM Cache并進行寫入(Copy O n Write)。

在內存狀態同步方面，COLO采用了一種巧妙的同步方式，如下圖所示：

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也沒放棄對創新技術的追求，通過了解用戶痛點與難題，進行針對性的開發與合作，用整個生態的力量去改變產品體驗，并將最新的技術融入產品中，傳遞給用戶，幫助用戶在最快時間享受到創新技術帶來的便利。

9月15日ZStack Mini邊緣計算一體機將在中國國際工業博覽會上亮相，有關FT新功能的更多詳細內容，請掃描二維碼獲悉。

申請創業報道，分享創業好點子。點擊此處，共同探討創業新機遇！