【編者按】針對采用OpenStack部署云平臺的復雜性，CSDN此前介紹過的ZStack是另外一種解決方案。本文是ZStack的深度試用報告，分別從部署、架構和網絡三個層面介紹作者的試用體驗，并與OpenStack進行簡單對比，文章最后也對ZStack的改進方向提出了思考。以下為全文內容：
“這是最好的時代，也是最壞的時代”。這句名言也是當前云計算大環境的真實寫照。云計算給企業帶來極大的便利，不但能夠充分利用現有的資源，而且能夠把資源（計算、存儲、網絡）實現池化，像自來水一樣便捷、精確地使用，形成了新的資源計費（商業）模式。但是，如何有效地、快速地把資源池化管理，這是擺在管理者和技術人員面前的一道難題。當前整個云生態，最成功的案例莫過于Amazon AWS 和開源的OpenStack。AWS可以說是云計算的鼻祖，它的成功毋庸置疑，不夸張地說，是它引領了云計算的時代；但它是閉源的，我們無法窺探它內部的實現邏輯。直到開源的OpenStack的出現，云計算才可以說“飛入尋常百姓家”了。OpenStack讓整個云市場開始紅火起來，各種云如雨后春筍般冒了出來。
隨著對OpenStack的深度普及，它在某些方面的弊端也不斷被管理層和技術人員所提及。整個OpenStack服務組件不斷增加，新的功能陸續被擴展，各種廠商之間不斷角逐，都想主導OpenStack的走向（使之符合自己的利益），而中小企業由于缺乏技術力量，越來越玩不轉龐大的OpenStack，原來期待的易用性、穩定性似乎逐漸地變成了奢望（或者說過往）。作為OpenStack使用者的我，也蒙生了疑問：OpenStack是不是還依然適合我們的使用場景，是否有別的替代品？在一次不經意的瞬間，發現了一個叫ZStack的云平臺，在其官網赫然寫著 “We name our project as ZStack because we hope it's the last effort to make a simple, reliable, and flexible IaaS software.”抱著試一試的心態，開始了我的ZStack之旅。
部署篇
說到部署，吐嘈下OpenStack。對于一個初次體驗者，看到OpenStack浩瀚的部署手冊，估計會使部分體驗者望而生畏。被強烈求知欲驅使著繼續部署的人們，一步一步“復制”、“粘貼”手冊里的命令（有些可能還不理解），硬著頭皮繼續前進。最后滿心期待正常的DASH界面，被一個個“error"傷得體無完膚。最終能正常進入WEB界面的寥寥無幾。雖然現在也出現了不少第三方的自動化部署工具（如RDO、fuel等），但也涉及到復雜的配置（主要是OpenStack融合很多知識），對初次體驗者也不是很友好。
ZStack的部署引導就顯得那么簡潔明了。在”Installation"篇，總共只有三個頁面，分別是”Quick Installation"、“Maunual Installation”、“Multi-node Installation"。 對初次體驗者，使用“Quick Installation"即可。ZStack作者提供了一鍵安裝的腳本，更為貼心地是，為國內“特殊”的網絡環境，定制了相應的套餐方案。
接下來開始我們一鍵安裝部署之旅。
wget -O install-zstack.sh http://download.zstack.org/install.sh
sudo bash install-zstack.sh -a -R http://pypi.douban.com/simple/ -f http://7xi3lj.com1.z0.glb.clouddn.com/zstack-all-in-one-0.6.2.tgz
“人品”差點的話，可能會出現如下情景（還是拜我們“特殊”的網絡環境所賜，(╯﹏╰)）
解決的辦法：把www.w3.org 解析到本機“騙”過腳本檢測就行。
echo "127.0.0.1 www.w3.org" >>/etc/hosts
再來一次繼續我們的路程。（提示目錄已存在，刪除即可）
大約10-20分鐘左右（網絡質量良好），部署就完成，根據提示打開瀏覽器（通過驗證）即可看到管理界面。
總體來說，ZStack整個部署過程還是很友好的，沒有冗雜的配置（部分定制可以查看腳本的幫助，如IP指定等）。
架構篇
部署的簡便性，只是ZStack的一個外在特性。ZStack真正核心價值還在于它的架構。（以下內容僅是本人個人觀點，如有贊同，不勝榮幸。^_^)
全異步架構
傳統的云管理平臺在擴展方面有其特有的軟肋--slow task。在并發不高的情況下，體現不是很明顯，但批量的任務創建時（如創建虛擬機），就會出現任務失敗或超時。想必許多OpenStack使用者都會有這樣的經歷，滿心期待能夠順利創建虛擬機，卻被一行行顯眼的紅色字體澆滅了熱忱的心。其中的原因如下：
OpenStack里任務（或者說消息）傳遞的路徑很長，比如以創建VM為例 ，一個任務要經歷 " service --> scheduler --> image service --> storage service --> network service --> hypervisor " 這條傳遞路徑，每一環節都要一定的耗時，大批量任務執行時，延遲效應就更明顯，最后就出現任務失敗。
任務傳遞并非全異步。某些環節同步傳遞就會出現等待，進一步增加了任務時間。（關于同步與異步的區別，詳見 http://avaj.iteye.com/blog/151724）。下圖展示一個實例：
ZStack在這方面做了改進，把服務之間的消息調用（或者API請求），以及服務內部代碼方法之間的調用全部實現異步架構，如下圖所示：
全異步架構帶來了效率上的提升，本人沒有系統地測試（與OpenStack對比），但僅從感官上講，在ZStack上創建一臺虛擬機，秒秒鐘dash就顯示創建成功了，那種享受，不言而喻。
無狀態服務
在講無狀態服務之前，我先講下有狀態服務下的請求機制。 這里的狀態是指在有多個管理節點時，每個管理節點都會有多個相同的微服務。那么微服務之間就要對自己管理資源的數量進行分配協商，向微服務發送請求的請求者也必須知道是哪個微服務在管理哪個資源。話多必失，還是上圖看看（我大學老師說過，一圖勝千言）：
而在無狀態服務下，這些事情交給hash ring處理，微服務之間無需知道自己或別人管了哪些資源。在請求里只需含一個唯一的UUID，不再需要指出把請求提交給哪個微服務，集群內部會把請求“路由”到指定的微服務 。如下圖所示：
ZStack里，管理節點之間形成一個強一致的hash ring，每個節點都有一份包含所有節點信息（如節點UUID）的副本。當新節點加入或者節點退出時，都會產生廣播消息通知到其他節點，整個集群會重新動態平衡，形成新的強一致的hash ring 。
ZStack自身強一致性的特性是其他IaaS軟件（包括OpenStack）不可比擬的。OpenStack要實現服務的HA特性，必須借助第三方高可用方案，比如keepalived+Haproxy或者pacemaker方案。誠然這些都承受了生產環境的考驗，但無疑給整個平臺增加了復雜度。
微服務體系
云平臺是個復雜的系統，管理著各種子系統（如計算、存儲、網絡、認證等）。每一次的請求任務都需要在各個子系統之間來回協調。比如說創建虛擬機，需要在計算、存儲、網絡、認證各環節都走通，任何一換出問題，都將導致創建失敗。如下圖為OpenStack各個子系統的調度關系圖：
OpenStack服務之間不但有Http交互，也有RPC交互。整個系統錯綜復雜。另一方面，隨著OpenStack的發展，修改代碼有時候會變得不那么容易，甚至不得不重構整個子系統的代碼，就像Neutron已經重構了。
反觀ZStack，服務之間的交互就簡單明了多了，所有交互統一走消息隊列，整個拓撲結構不再緊密，實現星狀的架構。如下圖所示：
星狀架構中，各服務之間只有消息的交互，服務之間基本完成獨立，添加或者刪除某個服務不會影響怎么個架構（只會失去某些功能）。
OpenStack與ZStack兩者雖然都是微服務架構，但在實現上有本質的區別。
OpenStack的微服務是以獨立進程分散到各個節點，這在一定程度實現了負載均衡的效果，但存在以下問題：
服務邊界擴大
給部署、升級、維護帶來困難
紛雜凌亂的配置
增加額外的監控負擔
當擴展時，會生成更多的微服務
鑒于以上原因，ZStack采取all in one process的實現方式，這就帶來下列特點：
更簡潔的依賴關系；所有微服務都集中在一個進程中，相關代碼都在一個包里，給部署、升級、維護、擴展帶來了極大的便利。
集中式的配置管理；OpenStack每個服務都有自己的配置，而且還分散在不同的主機上，維護成本較大；ZStack就容易多了。
微服務只需要關注自己的業務邏輯，高可用、負載均衡、監控都可以交管理節點來完成。
進程級的應用擴展。從代碼層講，ZStack的微服務都是一個個獨立的JAR包，且有自己獨立的API，錯誤代碼，全局配置，全局屬性和系統標簽。開發人員可以直接導入包，來實現自己的需要的功能。
綜上所述，ZStack擁有一個清晰的、解耦的架構，這是實現健壯IaaS平臺的基石。
插件機制
一個軟件的擴展性是評價軟件的重要指標之一。當前OpenStack主要支持兩種插件擴展機制。
strategy pattern （策略模式）
這是一種通用的擴展模式，通過API接口，實現功能擴展。比如OpenStack里Nova Hypervisor Driver 、Cinder Storage Driver等驅動都是通過這種形式實現的。這是一種通過已經定義好的協議來實現插制跟核心交互的。如下圖所示：
The out-of-process service （進程外服務）
這種模式的典型就是外部服務（監控）通過消息監聽，獲取平臺的消息。在OpenStack里，Ceilometer 服務里有很多監控的實現機制就是如此，示意圖如下：
以上兩種插件機制是OpenStack和ZStack所共有的，下面要提的機制是ZStack獨有的。
Observer pattern (觀察者模式)
在這種模式下，插件會深入到監控應用內部的業務邏輯的事件。當應用內部發現事件時，插件會對此事件做出自己的響應，在插件自身的代碼里執行相應的業務流。這種實現，對終端用戶是完全透明的，是純粹的內部實現。舉個 Observer pattern 案例，在OpenStack里Security Group（安全組）功能是集成在Neutron里，不能單獨剝離出來。而在ZStack里，Security Group是一種 Observer pattern plugin，你可以單獨提取，而不影響整個網絡功能的實現。這種插制的實現如下圖所示：
獨特的插件機制，給ZStack帶來了更靈活的實現。開發者可以根據自己業務需求擴展功能，而ZStack 開發者只需維護核心代碼。如此帶來的好處就是，整個云平臺可以快速更迭，功能逐步完善，而整個架構還是健壯的。
以上這些架構特點并非ZStack的全部，比如說ZStack還有回滾機制，一但超時或出錯，整個任務流就會回滾（包括數據庫的修改，比如VM創建失敗，IP會被回收，VM不會停留在errror狀態而是直接被刪除；而OpenStack會出現僵尸VM）。更多ZStack的架構方面的信息，詳見ZStack官網。
網絡篇
在云時代，用戶對網絡提出了更高的要求。云中的網絡不再是固定不變的，而應該可以隨時根據業務進行調整，對網絡的隔離性也有更進一步的要求。另外，傳統網絡的功能（如LB、VPN、FW等）也被引入到了云中，更高級的SDN網絡、NFV功能現在也開始集成了到了云中。OpenStack是網絡集大成者，各種傳統設備廠商、新型SDN公司以及各大運營商都在極力向Neutron靠攏，OpenStack的網絡功能可謂包羅萬象。
ZStack從一開始就把自己定位是私有云解決方案，它沒有像OpenStack那么強大的網絡功能，但基本已經能夠滿足私有云對網絡的需求。ZStack 借鑒了CloudStack的網絡解決方案，把網絡功能都集成到Virtual Router來實現，實現計算、網絡實現良好的隔離。比如說，端口轉發和SNAT功能，OpenStack利用iptables在宿主機上來實現的，這導致宿主機的iptables更加紛雜（即有宿主機自身的規則，也有VM的規則）。而ZStack把這些實現（也是iptables）轉移到了VR，排錯相對比較容易。ZStack把CloudStack的基礎網各和高級網絡融合在了一起，可謂 “打破這種無理的分割”——來自某CS資深用戶（@Star華星_FreeBSD）的肺腑感慨。ZStack在網絡方面更讓人傾心的是，它提供了豐富網絡應用場景向導，基本上囊括了私有云常見的應用聲場景。下面列舉幾個場景應用：
1. Amazon EC2 classic EIP
EIP（彈性IP）是當前云環境中最常見的應用。創建虛擬機的時候會分配一個private IP，當虛擬機綁定EIP的時候，虛擬機就可以實現公網路由了——這是在公有云場景。對應于私有云時，單純private IP無法訪問公網，只有綁定EIP，才能實現公網訪問。EIP是動態的，用戶可以實現更變綁定到不同的虛擬機上。這是云特性之一，彈性！（操作詳見 http://zstack.org/tutorials/ec2-cli.html）
2.Flat network
Flat network是一般企業內部很流行的應用場景。所有虛擬機共處一個廣播域，虛擬機訪問外網通過本地網關出去。如果L3子網在公網是可路由的，那虛擬機就可以直接分配公網IP。（操作詳見 http://zstack.org/tutorials/flat-network-cli.html ）
更多場景詳見 http://zstack.org/tutorials/ ，在此不再一一舉例。
ZStack以上的各種網絡場景是可以共存的，通過Zone設置，可以形成獨立的網絡環境，這大大增強了網絡的靈活性。更多的功能，有待使用者挖掘。
疑惑篇
說了這么多ZStack優勢，也得扒一扒ZStack相關薄弱或者說隱患的地方 。(個人鄙見，^_^)
融合的單進程架構，誠然存在很多優勢，但也有隱患。本人看來，最大的隱患就是核心代碼的處理邏輯，如果核心代碼出現嚴重bug，直接導致進程掛掉，那整個集群就失控了（所有管理節點都是一致的）。ZStack是JAVA編寫的，bug修復與部署都得重來，整個耗時就長了。OpenStack是Python腳本語言，直接線上修改即可，而且OpenStack是分散式微服務架構， bug只會影響具體某項功能，不會對整個集群產生毀滅性打擊。
ZStack當前的認證體系是融合在核心代碼里的（至少我還沒發現是否可以認證接口可以引入第三方認證），這對認證擴展帶來了許多不便。比如說，不能集成現有的認證方式（比如AD、LDAP等），一般企業都有自己的認證體系。而OpenStack的Keystone在這方面做得不錯，它可以無縫銜接第三方的認證（主要是AD、LDAP、Kerberos等）。統一的認證體系給企業在管理上帶來不少的便利。
當前ZStack的版本（0.62）對存儲支持有限，只支持NFS存儲（最新的0.7 預覽版支持iSCSI）。企業對存儲的需求很大，從我目前觀察來看，大部分企業還是挺看重本地存儲。另外，當前的大數據時代，數據不再是線性增長，幾乎可以說是指數增長曲線，所以企業對存儲的擴展性要越來載高，ZStack應該支持更多的存儲插件，比如GlusterFS、Ceph等分布式存儲。
ZStack的VR網絡機制，滿足中小型私有云那是沒有問題，但是否能承受規模化私云的網絡需求，有待考證。最好的方式就是引入SDN解決方案，徹底解決網絡瓶頸。
ZStack的L2網絡當前還只支持VLAN，下一步可以考慮引下VXLAN、GRE等overlay的隔離，如此一來，網絡功能就更加完善了。
外篇
在我看來，ZStack未來的商業模式就是提供私有云咨詢服務，深耕私有云市場，與廠商進行接恰合作，提供專業的存儲、網絡服務。當然前提是做好ZStack的生態圈，讓更多的企業和開發者來參與ZStack的發展。
此文是本人近期對ZStack的體驗一些感受與想法，期間特別感謝ZStack的作者 張鑫、尤永康的幫助，也感謝ZStack社區 （QQ群：410185063 ）的各位朋友的幫助。特別是群管理員 @Star華星_FreeBSD (網名 群小助）的鼎力協助。希望ZStack越來越好，受到市場的關注。
京公網安備 11010502049343號