隨著新基建提速換擋，必將帶動基礎設施即服務的新一輪增長。當我們關注高光項目的同時，不應忽略傳統(tǒng)IT需求，傳統(tǒng)IT領域很多應用上云面臨種種困難，如何讓他們在新基建浪潮提速?
比如在工業(yè)制造業(yè)、交通、能源電力等傳統(tǒng)行業(yè)的業(yè)務場景中，可用性永遠是高頻詞匯，如何讓應用主機在不同物理節(jié)點之間實現(xiàn)秒級切換?如何獲得可靠、高效的FT/HA技術讓用戶服務“永不宕機”?
在前一篇文章《邊緣計算體驗之二：簡單高可用 ZStack Mini的巧妙設計》中，介紹了ZStack如何在2U機箱設計的ZStack Mini中實現(xiàn)了高可用(HA)。
當監(jiān)測到物理節(jié)點故障無法為應用服務器提供服務的時候，高可用就將應用服務器遷移到正常運行的物理節(jié)點上，保證業(yè)務的連續(xù)性，但是業(yè)務系統(tǒng)也會受到輕微影響，基于HA的高可用依舊有數(shù)分鐘的業(yè)務中斷。
這在有些場景下是不可接受的，比如一些場景需要秒級的切換，以保證業(yè)務的連續(xù)性。在本篇文章中，將介紹ZStack Mini 3.0中的核心功能——FT。
ZStack Mini 3.0——讓易用性更上一層樓
ZStack Mini 3.0是ZStack Mini產(chǎn)品家族的一次重大升級，主要是軟件部分的升級。可以在保持ZStack Mini邊緣計算一體機硬件不變的情況下，將軟件版本從原來的2.0升級到最新的3.0，獲得更多對中小企業(yè)實際使用非常有幫助的功能。
ZStack Mini一體機升級到3.0后的管理中心界面，從左側(cè)邊欄可以看到，與2.0相比，多了“應用中心”、“我的應用”、“外接磁盤備份”等菜單，同時在上圖看不到的是在“存儲”中多了“FC-SAN存儲”的功能。
FC-SAN存儲功能，讓ZStack Mini可以外接FC-SAN存儲陣列，幫助企業(yè)更好地利用數(shù)據(jù)中心內(nèi)已有的FC-SAN存儲，可以利舊，并有助于數(shù)據(jù)流通與整合。
在ZStack Mini邊緣計算一體機中安裝額外的FC-HBA卡，即可與數(shù)據(jù)中心內(nèi)的FC-SAN存儲進行連接。上圖紅框中即為FC-HBA卡，正與外接FC-SAN存儲進行數(shù)據(jù)整合
外接磁盤備份，顧名思義，就是通過將USB接口的移動硬盤(或U盤)接入ZStack Mini平臺，將ZStack Mini平臺中現(xiàn)有的數(shù)據(jù)備份到磁盤之中。
應用中心，在E企研究院測試的ZStack Mini中集成了三個應用模板，分別為MariaDB、LNMP和Tomcat，這是許多中小企業(yè)利用Apache開源軟件構建網(wǎng)站的“三駕馬車”，可以說是自建網(wǎng)站的最經(jīng)典的選擇。
在E企研究院使用的ZStack Mini中，集成了LNMP、MariaDB和Tomcat三個最常使用的應用
如果利用虛機安裝這三個應用，可能需要花費數(shù)小時，而且還極有可能出錯。現(xiàn)在ZStack Mini將這三個應用軟件集成到“應用中心”內(nèi)，通過鼠標點擊即可一鍵部署，并在數(shù)分鐘內(nèi)完成可用?？梢哉f極大地節(jié)省了用戶在安裝、部署和維護方面的難度。
通過這些功能加入，ZStack Mini邊緣計算一體機平臺不但具備已有的簡單易用功能，同時也讓企業(yè)用戶在業(yè)務部署、后期維護上更簡單。這也與ZStack Mini邊緣計算一體機的易用性特點是一脈相承的，產(chǎn)品的使用并不會因為升級而變得復雜。
接下來，將介紹ZStack Mini 3.0中最重磅的功能——FT功能。
FT——讓可用性進一步提高
在前一篇文章中，采用HA(High Availability，高可用)對ZStack Mini中的虛機進行保護的話，業(yè)務依舊會有1分鐘左右的中斷，那么ZStack Mini 3.0中新加入的FT(Fault-Tolerance，容錯)功能則能夠做到真正意義的秒級切換，且不會對業(yè)務造成影響。
口說無憑，眼見為實，我們依舊用一段視頻來演示ZStack Mini 3.0中的FT功能。
在ZStack Mini邊緣計算一體機平臺中，E企研究院事先創(chuàng)建了一個目前最火熱的應用之一——視頻直播。其由兩個虛機構成：視頻推流服務器： 其作用類似于我們智能手機的直播App，將手機攝像頭“看到”的圖像上傳到云端的服務器。稍微與直播不同的是，在演示中，E企研究院用一段視頻替代直播圖像，在視頻推流服務器中將一段視頻實時推流到在線編碼服務器。 在線編碼服務器： 手機中的直播App將圖像上傳到云端的編碼服務器，編碼服務器進行編解碼，然后再推送到觀眾的手機或電腦端(接收端)。在演示中，則用演示用的筆記本電腦作為接收端。
首先，我們在視頻推流服務器中將一段視頻流推送到在線編碼器，然后用筆記本電腦接收經(jīng)過在線編碼服務器處理的音視頻信號。視頻推流服務器——在線編碼服務器——接收端，構成了一個最簡化的視頻直播應用環(huán)境。其中，在線編碼服務器是企業(yè)為最終用戶提供視頻直播服務的核心，一旦其出現(xiàn)故障，無法正常運行，整個直播服務將會中斷。
在視頻中，在線編碼服務器位于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)進入維護模式，以模擬這臺物理主機出現(xiàn)故障，需要停機維護，暫時無法提供服務。
ZStack Mini邊緣計算一體機中，IP地址為172.24.100.3的物理主機進入維護模式
在物理主機進入維護模式時，切換到筆記本電腦接收端，音視頻信號一切正常，并沒有出現(xiàn)停頓。再看在線編碼服務器的狀態(tài)，虛機已經(jīng)切換到172.24.100.4物理主機之上，因為其原來所在的物理主機進入維護模式(172.24.100.3)。
ZStack Mini邊緣計算一體機最小二節(jié)點部署，因為其中一臺物理主機進入維護模式，原本位于172.24.100.3的在線編碼服務器在第一時間就切換到了172.24.100.4物理主機之上，視頻直播業(yè)務正常運行。但是通過上圖可見，在線編碼服務器已經(jīng)不再處于保護狀態(tài)，因為其已經(jīng)沒有了備用的云主機，正處于“單工模式”，一旦其所在的物理主機也需要停機，將影響正在運行的直播業(yè)務。因此還是要盡快將故障的物理主機修復或替換，重新上線作為備份節(jié)點。
在這個測試驗證場景中，E企研究院進入到“一體機”界面中，將處于“維護模式”的172.24.100.3這臺物理主機啟用，表示故障修復，重新上線。
在172.24.100.3這臺物理主機恢復上線之后，在線編碼服務器的FT功能自動檢測到新主機加入，將再次恢復FT保護級別;但是，在172.24.100.3這臺物理主機進入維護模式這段時間，視頻直播應用一直在正常運行，不斷產(chǎn)生新的數(shù)據(jù)，同時內(nèi)存狀態(tài)也在實時變化。
這意味著要恢復在線編碼服務器的“FT保護級別”需要進行數(shù)據(jù)同步，不僅是存儲的數(shù)據(jù)同步，還包括內(nèi)存狀態(tài)的同步;同步數(shù)據(jù)與內(nèi)存狀態(tài)，在以往的高可用方案中都是一個非常困難的問題，因為一旦出錯，就會造成數(shù)據(jù)不一致，甚至可能影響到正常運行的業(yè)務。
但是在ZStack Mini邊緣計算一體機中，在經(jīng)過數(shù)分鐘的同步之后，在線編碼服務器重新達成FT保護，視頻直播業(yè)務并沒有受到影響。
如上圖所示，在線編碼服務器重新達成FT保護級別，其所在物理主機的IP地址為172.24.100.4，而原來的172.24.100.3的物理主機則承載備用云主機，與測試之前的狀態(tài)相比，主、備進行了切換，但業(yè)務依舊正常運行。
從ZStack Mini 2.0中HA切換需要數(shù)分鐘業(yè)務停頓——這也是目前大多數(shù)虛機遷移或故障切換所需要的時間，到3.0中FT保護縮短到秒級，切換時間極大地被縮短，但并沒有引入新的硬件，也沒有提升使用難度，那么FT究竟是怎樣的技術?
FT技術背后的原理
傳統(tǒng)的基于SAN存儲的數(shù)據(jù)保護通常要么對業(yè)務造成短暫影響，要么需要額外解決方案介入，不在本文討論范圍內(nèi)。在基于虛擬化技術的云環(huán)境中，虛機遷移或虛機故障切換通常都需要一定的時間，就如同ZStack Mini 2.0中的HA技術一樣，本質(zhì)上，這都采用的相同技術。
要保證部署虛機上的業(yè)務在遷移或切換時盡量不受影響，其最重要的一環(huán)就是數(shù)據(jù)同步——包括存儲數(shù)據(jù)同步和內(nèi)存狀態(tài)同步。因為應用程序不間斷運行，不停產(chǎn)生數(shù)據(jù)并改變內(nèi)存狀態(tài)，這就給數(shù)據(jù)同步并保持數(shù)據(jù)一致性帶來極大的挑戰(zhàn)。目前虛機間主流的數(shù)據(jù)同步方式采用鎖步(Lock-stepping)或連續(xù)檢查點(Continuous Checkpoint)。
但這兩種數(shù)據(jù)同步方式各有各的不足，比如鎖步會導致復制開銷過多，因為虛擬機中的內(nèi)存訪問是不確定的;而連續(xù)檢查點同樣會導致過多的復制，同時還會帶來額外的網(wǎng)絡延遲。
ZStack通過與英特爾的合作，延伸出一種新的數(shù)據(jù)同步方式——粗粒級鎖步(COarse-grain LOck-stepping，簡稱COLO)，來實現(xiàn)FT功能所需的快速切換。其通過比較主虛機(Primary VM，PVM)與備用虛機(Secondary VM，SVM)的傳輸數(shù)據(jù)包來進行數(shù)據(jù)同步。
粗粒級鎖步(COLO)架構示意圖，其分別通過快復制進程與COLO代理，以及COLO Frame進程來實現(xiàn)數(shù)據(jù)與內(nèi)存狀態(tài)在PVM與SVM之間的同步
因為涉及到存儲數(shù)據(jù)和內(nèi)存狀態(tài)的同步，所以其由不同軟件模塊（并行）實現(xiàn)。比如存儲數(shù)據(jù)同步如下所示：
COLO中的讀、寫流程示意圖
在存儲數(shù)據(jù)讀寫方面：
當應用發(fā)起讀請求，不僅PVM直接從自身存儲進行數(shù)據(jù)讀取，SVM也會進行相應的讀取操作，只是正常狀態(tài)下并不傳輸給應用。
當應用發(fā)起寫請求，PVM將寫請求發(fā)送給SVM，同時將數(shù)據(jù)寫入自身存儲;而SVM接收到寫請求后，會將原始數(shù)據(jù)加載到SVM Cache并進行寫入(Copy O n Write)。
在內(nèi)存狀態(tài)同步方面，COLO采用了一種巧妙的同步方式，如下圖所示：
COLO技術中的內(nèi)存狀態(tài)同步示意圖
如上圖所示，主節(jié)點會對PVM的臟頁(Dirty Pages)進行跟蹤，并將其發(fā)送到備用節(jié)點。備用節(jié)點再收到PVM的臟頁之后，將其保存在PVM內(nèi)存緩存(Memory Cache)中，然后在檢查點，將PVM內(nèi)存緩存中的狀態(tài)更新到SVM內(nèi)存之中。
在之前的COLO技術中，COLO Proxy通常采用內(nèi)核方案(Kernel Scheme)，功能更強但不夠靈活，但最新COLO技術中，基于目前更為流行的用戶空間方案(Userspace scheme)的Proxy進程則具有更佳的靈活性。
通過對FT功能背后的技術解析，我們可以看到ZStack不僅關注用戶的使用體驗，盡最大努力將ZStack Mini的使用做到最簡化，還深入用戶實際業(yè)務需求，將ZStack Mini平臺與應用連通，提供更加簡化的使用體驗。
同時，ZStack也沒放棄對創(chuàng)新技術的追求，通過了解用戶痛點與難題，進行針對性的開發(fā)與合作，用整個生態(tài)的力量去改變產(chǎn)品體驗，并將最新的技術融入產(chǎn)品中，傳遞給用戶，幫助用戶在最快時間享受到創(chuàng)新技術帶來的便利。
9月15日ZStack Mini邊緣計算一體機將在中國國際工業(yè)博覽會上亮相，有關FT新功能的更多詳細內(nèi)容，請掃描二維碼獲悉。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
