ZStack 3.6.0，支持雲主機從任意KVM雲平臺在線遷移至ZStack

 

常常在新聞裏聽到「企業號航母」並非新船，它是1962-2012年服役的，其核心功能已經穩定運行了50年。鐵打的營盤流水的兵，船上的人常常變，電控系統和操做流程，既在尊重傳統，也在持續演進之中。

體驗完ZStack 3.6.0版本的更新，我看到了一個新興商業軟件的成熟過程。

若是用一個航母戰鬥羣來比擬一個私有云計算平臺，ZStack從軟件功能上已經完成了「造一艘航母」的過程，這幾回更新主要是「完善管理和人爲操做的軟裝」，說通俗點就是讓練兵更容易。

核心功能穩定

ZStack好久沒有發佈核心功能更新和關鍵BUG漏洞的補丁了，這並非ZStack黔驢技窮，而是私有云主機產品已經很完善了；我接觸過十幾個ZStack的客戶，你們也都沒反饋有什麼BUG。

這裏既有虛擬化軟件二十年的經驗積累，也是ZStack研發測試團隊的軍功，仍是「私有云/專有云」比公有云更穩定可靠的明證。

每當有朋友想了解雲主機該有哪些功能，我並不會讓他們盲目上手作實驗，而是推薦他們看ZStack的產品說明書，只要是圍繞雲主機開展的功能，1000多頁說明書裏應有盡有。

 

嚴謹靈活的權限和流程

企業軟件的買單決策人是項目負責人、CIO和CEO，在標準軟件功能雷同之後，企業更看重商業軟件和自身的管理流程是否匹配。企業的權限設計是以活動目錄AD爲事實標準的，ZStack是我見到最用心去兼容企業權限設計的私有云軟件。

以ZStack 3.6.0的更新爲例，本次更新將帳號和角色、權限和資源池（部門/項目）作了完全的解耦。這個設計在外行看來是細枝末節，但對於企業付費者是核心訴求。

互聯網產品設計中，一個帳戶表明的天然人是權限和資源設計的核心，你們以帳戶的角度去管理資源，角色只是個「附加屬性」，資源池統計管理的功能也被弱化了。

可是企業產品設計中，並不存在一個資源只被一個帳戶管理的狀況，帳戶只是個身份登陸憑證。角色實際是一個權限集合，企業產品的受權操做是給帳戶賦予某種角色，據此清晰表述一堆用戶對一個資源池的受權粒度。

ZStack的另外一重要功能是承載審批和業務操做的工單。傳統工單更可能是郵件的變體，參與者的角色只有客戶和技術支持，最終工單落實要靠工程師跨到另外一個系統去操做；這種工單拿到企業環境價值不大，還不如郵件審批來的輕快。

帶審批邏輯的工單，須要將「客戶VS技術支持」的簡單溝通，變成全部相關角色參與審批的企業管理過程；ZStack的工單系統還和業務系統緊密結合，流程審批結束時，既能夠自動授予權限，也能夠主動完成工做。這種工單系統本質上是企業客戶要的流程自控系統。

我並不信任互聯網思惟的雲產品設計，只要客戶仍是要「勾選用戶註冊協議」，這就不是一個平等的甲乙方關係，而是一個牧羊人和羊羣的關係，牧羊人不會尊重羊羣的管理訴求。

 

尊重工程師的操做優化

ZStack3.6.0版本但願實現從造船到練兵，要想順暢完成練兵，就要理解和尊重客戶側的工程師，順應他們的傳統工做習慣，並且減小繁瑣易錯操做，讓客戶專一核心業務判斷。

順應傳統工做習慣並非貶義詞，好比在網絡設計中，傳統不等於過期，多是經典場景中的經典設計。

ZStack在本次更新中，一個重要網絡功能就是VPC防火牆。不少人會將防火牆和安全組混淆，將架構師和軟件研發提出的防火牆設置建議，直接扭曲成安全組配置。但ZStack的說明文檔很清楚的解釋了，防火牆不等於安全組。

安全組誕生於大二層網絡時代，作很差二層隔離那就先作好三層隔離，其部署位置在雲主機的網卡上，其重點防範的是其餘雲主機的非受權訪問。在二層隔離VxLan普及之後，安全組的東西向流量隔離功能已經略有雞肋，其南北向訪問的配置規則則過於簡陋。安全組不必識別目標IP和端口，由於做用點就是本網卡；咱們曾經熟悉的「放行全部ESTABLISHED狀態報文」，在安全組模式下也沒法設置。

防火牆是部署在VPC路由器上的，並不關注內網傳輸，但對外部訪問的控制粒度很細，不只能夠識別源IP目標IP，對協議中的報文狀態也有清晰的識別能力。對於老網絡工程師來講，防火牆規則中的「拒絕」和「丟棄」的區別，能夠當作經典面試題，而防火牆規則中複雜的優先級設計，是網絡工程師炫耀邏輯和工程能力的最好戰場。此外VPC路由器支持了NetFlow，在VPC內排查故障，跟在物理環境上已經類似了。

ZStack每次更新都有大量操做簡化優化，3.6.0版也不例外，目標是讓使用者從邊思考邊操做一堆繁瑣命令，變爲只思考一次核心問題，只發出一條簡單指令。

前文談過權限設計以後，管理員就要作一個工做——在私有云平臺上建立用戶。ZStack提供了AD對接、表格導入的方式批量建立用戶；雲平臺管理員不用把時間花在如何點鼠標新增用戶上，而是集中精力判斷該添加哪一個list的用戶。相似的操做優化還有諸如主機硬盤同時快照、雲主機優先在舊宿主啓動，當主機和硬盤遷移時對目標物理機按負載高低排序。

若是說批量建立用戶功能是個很是規的單薄操做，那咱們就看V2V的自動遷移，ZStack很早就支持vCenter雲主機批量遷移，本次更新後支持了KVM雲主機批量自動遷移。

V2V遷移原本是個重度依賴遷移工程師人力的工做，要求遷移工程師對業務瞭解、對通用虛擬化標準瞭解、對新舊V2V資源池的配置瞭解，而後瞪大了眼睛一臺一臺遷移。如今ZStack作了足夠多的適配，將V2V遷移自動化，那遷移工程師的工做量會極大下降，他們的重點精力放在選擇遷移對象和時機上。

高危操做並不能經過「操做優化」來避免，平臺能作的只是精細化權限和明確審批過程，但絕對不是無端拖長審批過程甚至干擾高危操做，執劍人終歸要承擔執劍人的責任。

 

 利器在手活學活用

我常常強調一個概念，成熟的商業軟件絕對不會讓甲方工程師邊緣化和失業；而是給甲方工程師留下「肥而不膩」的工做量。甲方工程師始終是一個有決策能力的專家，而非給供應商打工的苦力。

肥而不膩的肥」，指的是高含金量的工做是有業務價值、沒法被簡單彙總的工做；好比ZStack的權限設計只是個趁手的好工具，甲方工程師仍然要結合實際業務作精細調試；好比防火牆的策略設置比安全組複雜多了。

「肥而不膩的膩」，指的是別讓甲方工程師太過勞累繁瑣，好比我不確認V2V自動遷移能切掉幾個友商KVM的項目，但我相信遷移工程師不會由於選擇了ZStack而面臨過大的工做量。

如今ZStack給甲方工程師打造的這套私有云軟件，是有意識也有能力讓客戶側工程師開心放心的練兵，最終用這套軟件證實自身團隊的價值。

再先進的武器也是爲人設計的，即便無人機也要聽司令官下命令。科幻小說裏常常YY出脫離人類控制的滅世AI軍隊，但能毀掉使用者的程序，就是有嚴重BUG的程序，或者空談式YY。