從應用場景的角度分析了Eucalyptus、CloudStack、OpenStack和OpenNebula這四個云管理平臺的不同點。Ignacio認為VMWarevCloud和AWS分別代表了數據中心虛擬化和按需獲取計算資源的兩種典型的應用場景，如上所述四個開源云管理平臺基本上都是以VMWare vCloud或者AWS為參考原型但是在實現細節上又與參考原型有所差別。Ignacio將開源云平臺與其參考原型之間的差異之處稱為靈活性（Flexibility），并以數據中心虛擬化、按需獲取計算資源、低靈活性、高靈活性為四象限將如上所述四個開源云管理平臺放到不同的位置（如下圖所示）。Ignacio進一步指出這個圖例并不是為了說明某個開源云平臺優于其他開源云平臺，而是為了說明不同的開源云管理平臺適用于不同的客戶需求以及不同的應用場景。以目前的狀況而言，私有云市場規模很大，客戶需求以及應用場景之間的差別很大，并不存在一個能夠通吃所有應用場景的云管理平臺。未來Eucalyptus、CloudStack、OpenStack和OpenNebula這四個云管理平臺之間既有競爭也會有合作，并在這種競爭與合作并存的關系中找準適合自己的市場和客戶。
我基本上認同Ignacio M. LIorente的觀點，就是不同的云管理平臺適用于不同的客戶需求以及不同的應用場景，并不存在一個能夠通吃所有應用場景的云管理平臺。出于同樣的道理，Eucalyptus也有自己所擅長的應用場景，以及自己所不擅長的應用場景。作為Eucalyptus的員工，我自然希望各行各業的用戶都使用Eucalyptus來搭建他們的私有云。但是為了能夠充分發揮Eucalyptus的潛力，我建議所有潛在的客戶首先了解一下Eucalyptus是什么（或者不是什么），Eucalyptus能做什么（或者不能做什么），以及應該如何規劃、實施、使用基于Eucalyptus的私有云。
Eucalyptus是（不是）什么？
Eucalyptus是一個開放源代碼的、與AWS高度兼容的云管理平臺。以AWS為參考原型的各種云管理平臺（例如OpenStack）都在某種程度上兼容AWSAPI，但是只有Eucalyptus將忠誠地兼容AWS API上升到企業戰略與核心競爭力的層面。忠誠地兼容AWS API意味著客戶能夠在私有云環境中繼續使用各種現有的與AWSAPI相兼容的工具、腳本和映像（AMI），能夠在基于Eucalyptus的私有云和AWS公有云之間遷移負載和數據，或者是將基于Eucalyptus的私有云作為開發測試環境但是將AWS公有云作為生產環境。
根據Ignacio M. LIorente的云管理平臺四象限圖，VMWare vCloud和AWS分別代表了數據中心虛擬化和按需獲取計算資源的兩種典型的應用場景。以數據中心虛擬化為應用場景的云管理平臺通常采取自下而上的架構設計，旨在解決數據中心的復雜度問題；以按需獲取計算資源為應用場景的云管理平臺通常采取自上而下的架構設計，旨在通過簡單高效的接口提供計算資源。設計理念上的差異，決定了一個云管理平臺很難同時具備VMWarevCloud和AWS的種種特性。Eucalyptus與AWS的高度兼容性決定了Eucalyptus不是VMWare vCloud或者VMWarevCenter的替代品。Eucalyptus和VMWare試圖解決的是不同的問題，適用于不同的應用場景，因此具有不同的功能和特性。常常有用戶將Eucalyptus和VMWarevCloud或者是VMWare vCenter進行功能或者特性對比。他們沒有意識到Eucalyptus和VMWare vCloud或者是VMWarevCenter完全不是同一類型的軟件，是沒有辦法直接進行功能或者特性對比的。
值得一提的是，Eucalyptus是一個開放源代碼的產品，但是桉樹公司并不為特定客戶提供提供軟件定制化服務。經常有一些潛在的客戶問我們是否可以為其提供定制的版本。的確，作為一個開源項目的主要開發者，桉樹公司具備為特定客戶提供特定版本的能力，但是桉樹公司通常不會這么做。為特定客戶提供定制化版本意味著要對產品進行修改，也意味著使用定制版本的用戶在升級到Eucalyptus后續版本時可能會遇到不可預知的風險。盡管在短期內定制化版本可能為客戶解決了某些問題，但是從長期來看它所帶來的問題要大于它所解決的問題。（Eucalyptus是一個開源項目，如果客戶愿意并且具備相應的開發能力的話，當然也可以自己對Eucalyptus進行定制化。但是，用戶自己對Eucalyptus進行定制化同樣也會遇到升級的問題。）
Eucalyptus能（不能）做什么？
目前Eucalyptus的最新發行版本是3.2.1，它能夠很好地用作開發測試環境，或者是用來支撐各種可擴展的Web服務。這兩個應用場景的共同特點是大量地使用非持久性虛擬機實例（EphemeralInstance），以及使用彈性塊存儲（EBS）來保存持久性數據。盡管Eucalyptus也支持從彈性塊存儲啟動（Boot from EBS,BfEBS）的持久性虛擬機實例，但是由于架構設計方面的原因，在一個集群中存在大量BfEBS實例時整個集群的性能會有所下降。一個集群中BfEBS實例的數量越大，集群的性能惡化就越嚴重。因此，我們不建議客戶在Eucalyptus上運行大量BfEBS實例。
Eucalyptus也不能很好地支持各種磁盤IO密集型應用，例如需要高速讀寫磁盤的數據庫應用。嚴格地說，這不是Eucalyptus自身的問題，而是底層虛擬化技術的問題。目前各種虛擬化技術－ 例如VMWare ESX、Xen、KVM等等 － 已經較好地解決了CPU和內存的性能損失問題，但是在磁盤IO方面還是存在一定的性能損失。因此，我們不建議客戶在虛擬機上運行各種磁盤IO密集型應用，包括負載較重的數據庫應用。
在VMWare vCenter里面，系統管理員可以根據應用特征為應用定制網絡參數。在Eucalyptus里面，如果系統管理員希望具備同樣的能力，恐怕他很快就要失望了。為了以簡單高效的途徑提供計算資源，Eucalyptus盡可能自動化地管理整個私有云的網絡配置，留給系統管理員自由發揮的空間不大。
Eucalyptus的硬件拓撲
接下來我們介紹幾個典型的硬件拓撲結構，以幫助各位讀者深入了解適合Eucalyptus的應用場景。在這些拓撲結構圖中有一些縮寫，含義如下：
CLC － 云控制器（Cloud Controller），Eucalyptus中的前端組件Walrus － Eucalyptus中類似于Amazon S3的對象存儲服務CC － 集群控制器（Cluster Controller），管理一個Eucalyptus集群SC － 存儲控制器（Storage Controller），為一個Eucalyptus提供彈性塊存儲（EBS）服務NC － 計算節點（Node Controller）GE － 千兆網10 GE － 萬兆網FC － 光纖通道SAN － SAN存儲
上面這個拓撲圖展示的是一個只有一個計算集群的小型Euclayptus私有云。在這個私有云中，所有服務器都連接到一臺千兆網交換機上，其中CLC和Walrus共同部署在同一臺物理服務器上，CC和SC共同部署在同一臺物理服務器上，SAN存儲通過光纖通道連接到Walrus和SC服務器。如果為了進一步降低成本，SAN存儲設備也可以替換成DAS存儲設備。
在這樣一種拓撲結構下，Eucalyptus使用開源的iSCSI TGT驅動提供EBS服務。大量的實踐表明，開源的iSCSI TGT驅動存在穩定性問題，在存儲壓力比較大的情況下會莫名其妙的崩潰掉。（這個問題不僅僅在Eucalyptus中存在，在所有使用開源的iSCSITGT驅動的應用中都會發生。）EBS服務存在穩定性問題，意味著處于運行狀態的虛擬機可能會突然訪問不到掛載的彈性塊存儲設備，也意味著從彈性塊存儲啟動的BfEBS實例會突然崩潰。這樣的拓撲結構部署在對數據持久性要求不高的開發測試環境中的問題不是很大，但是我們不建議客戶在對數據持久性要求較高的生產環境中使用。
除了EBS的穩定性問題之外，這個拓撲結構的瓶頸在于SC與整個計算集群之間的連接是一個千兆網。整個計算集群訪問EBS服務的吞吐量受到千兆網帶寬的限制，有效吞吐量大概在100MB/s左右。假設每個EBS實例所造成的平均壓力為2 MB/s，一個計算集群能夠同時支持40到50個EBS實例。假設每個EBS實例所造成的平均壓力為4MB/s，一個計算集群只能夠同時支持20到25個EBS實例。需要指出的是，4 MB/s相當于一個質量中等的U盤（USB 2.0）的吞吐能力，其性能遠遠不及老式筆記本電腦中常用的7200轉SATA硬盤，而2MB/s更是一個性能非常低下的極端情況了。如果客戶希望在這樣一種拓撲結構下大量使用EBS服務，建議將SC通過萬兆網連接到交換機。（現在很多接入交換機都帶2～4個萬兆接口了，這樣的改造成本不大。）經過這個簡單改造之后，EBS服務的有效吞吐量一下子增長了10倍，基本可以消除由于帶寬限制所帶來的性能瓶頸。
在生產環境中，我們建議客戶使用基于IP SAN的存儲設備來提供EBS服務。上面這個拓撲圖展示的是一個可用于生產環境的Euclayptus私有云。在這個私有云中，所有Eucalyptus前端組件（CLC、Walrus、CC、SC）都部署到獨立的物理服務器上，所有可能有大流量的組件（IPSAN、Walrus、CC、SC）都通過萬兆網連接到私有云。目前Eucalyptus支持EMC、EqualLogic、NetApp等多個廠商的IPSAN設備，在這種拓撲結構下Eucalyptus使用官方支持的iSCSI驅動EBS服務，其穩定性和可靠性與開源的iSCSI TGT相比都有大幅度的提高。
即使如此，我們依然不建議客戶在Eucalyptus上運行大量從彈性塊存儲啟動的BfEBS實例。Eucalyptus的設計初衷是鼓勵用戶盡可能多地使用非持久性虛擬機實例，在這種情況下虛擬機磁盤映像被存儲在計算節點上，虛擬機內部的磁盤IO不會對私有云的網絡造成壓力，運行在不同計算節點上的虛擬機基本上不會互相影響。由于從彈性塊存儲啟動的虛擬機實例是持久性實例，需要頻繁地與存儲設備進行交互，對網絡帶寬的壓力是很大的。因此，我們對客戶的一般性建議是：（1）盡可能使用非持久性虛擬機實例；（2）在必須使用BfEBS實例的情況下，盡可能將操作系統盤做得比較小，例如10GB；（3）將操作系統盤與數據存儲盤分離，也就是首先啟動一個尺寸較小的BfEBS實例，然后掛載一個尺寸較大的EBS卷用于存儲持久性數據。
上面這個拓撲結構可以進一步加以改造，將存儲網與業務網分離。這樣存儲流量就不會對業務流量造成影響，對私有云各個組件的健康監控也可以在存儲網上進行。
當一個計算集群的容量達到極限的時候，可以往私有云中增加新的計算集群進行擴容，就形成了上面這個拓撲結構。
Eucalyptus的使用建議
前面我們已經說過，不同的云管理平臺有不同的設計理念，適用于不同的應用場景。有些潛在的客戶認為只要投資買了X硬件按照Y拓撲安裝好Z軟件就可以應付一切類型的應用，這種期望基本上是不切實際的。類似于AWS的云計算更多地是一種新的管理和分配計算資源的理念，而不是一種新的技術。使用類似于AWS的云計算服務要求用戶了解一些基本的概念，并且通常需要對應用做一些修改才能夠達到最佳的效果。我們給Eucalyptus客戶提供的一般性建議包括：
（1）盡可能使用非持久性虛擬機實例；
（2）當必須使用BfEBS實例時，盡可能縮小磁盤映像的尺寸；
（3）使用EBS卷保存持久性數據，并且將操作系統盤和數據存儲盤分離；
（4）不要在虛擬機上運行磁盤IO密集型應用；
（5）不要對虛擬機進行縱向擴展，要通過橫向擴展提高應用的處理能力；
（6）通過負載均衡實現應用的高可用性；
（7）避免虛擬機級別的在線遷移，當物理服務器需要進行維護時，使用Eucalyptus的維護模式。
如上圖所示，我們建議用戶將同一個應用部署到多個計算集群上。
當一個計算集群發生失效的時候，應用依然是可用的，但是其處理能力降低了。
對于有計劃的系統維護，可以先將應用的負載遷移到不需要進行維護的計算集群上，然后對處于空閑狀態的計算集群進行維護。這樣既保證了應用的可用性，又保證了應用的處理能力。
需要說明的是，上面我們所提到的“負載遷移”并不是指將一個處于運行狀態的虛擬機從一個計算集群動態遷移到另外一個計算集群，而是在另外一個計算集群中基于同樣的EMI創建一個新的虛擬機實例，并通過負載均衡設置將應用的負載重定向到新的虛擬機實例。到目前為止，Eucalyptus并不提供VM級別的動態遷移（類似于VMWarevMotion）的功能。對于類似于AWS的云服務來說，最終用戶與底層的基礎設施是通過多個層次的抽象措施徹底隔離的。對于最終用戶來說，他所看到的計算資源只有自己的虛擬機。至于他的虛擬機運行在什么樣的物理服務器上以及該服務器上的負載情況，最終用戶應該是一無所知的。因此，提供虛擬機級別的在線遷移功能，其實質是違反了通過抽象措施將最終用戶與基礎設施進行隔離的原則。
在Eucalyptus 3.3中即將提供一個稱為維護模式的功能，允許系統管理員將某個計算集群中的特定物理服務器標志為維護狀態。這時系統就會自動地將指定物理服務器上的所有虛擬機實例遷移到同一計算集群中的其他物理服務器上。這個功能允許系統管理員對計算集群中的特定物理服務器進行維護，同時又不必清空該計算集群中的所有負載。
當應用的負載上升時，通過橫向擴展提升應用的處理能力。
在Eucalyptus 3.3中即將提供的實例監控（Monitoring）、彈性負載均衡（Elastic Load Balancing，ELB）、自動擴展（AutoScaling，AS）功能，會使得應用的橫向擴展更加容易。簡單地說，實例監控功能允許用戶對自己的虛擬機實例進行監控，監控對象包括虛擬機實例的CPU、內存、磁盤IO、網絡IO等等；自動擴展功能允許用戶設定一些簡單的觸發參數，并在監控參數達到觸發參數要求的時候自動地創建或者是銷毀虛擬機實例；彈性負載均衡功能則負責修改與應用相關的負載均衡策略，自動地添加新創建的虛擬機實例或者是移除舊的虛擬機實例。
綜上所述，可以得到我們向客戶所建議的一般性的應用架構設計。可以看出，這個架構設計與我們所熟悉的Web應用架構基本上是一致的。一個典型的Web應用，可能僅僅需要進行少量的改動（如果應用在設計之初就充分考慮到橫向擴展的話，甚至是完全不需要改動），就可以充分利用Eucalyptus私有云的種種特性。
除此之外，在彈性塊存儲EBS服務的使用方面，建議各位感興趣的用戶讀一讀Why EBS was a bad idea這篇文章。盡管我并非完全同意文章中的觀點，但是作者的許多觀察和思考是值得云管理員和應用開發者深入思考的。
Eucalyptus的容量規劃
現在各位讀者已經大致了解了Eucalyptus是（不是）什么，能（不能）做什么，以及應該如何使用基于Eucalyptus的私有云。如果您覺得上面這些描述與您的應用場景相符合，并希望使用Eucalyptus來搭建您的私有云的話，我們建議您在動手之前做一些簡單的容量規劃。容量規劃的基本方法，是將可預見的負載與物理資源進行映射，以確保私有云的容量能夠承載應用和業務所帶來的壓力。一般來說，需要進行考察的參數包括CPU（物理核心數量）、內存、網絡（吞吐量）、存儲（吞吐量和IOPS）。
對于CPU和內存來說，可以通過標準化的VM產品類型（VM Types）進行簡單的換算，其結果可以表達為特定的硬件設備可以支撐多少個某個類型的虛擬機實例。
對于網絡來說，往往需要對即將運行在私有云上的應用的網絡行為進行采樣，獲取其真實的流量特征，并在此基礎上與私有云的網絡配置進行對比。
對于存儲來說，一個集群的容量往往受限于IOPS而不是吞吐量。上個月Eucalyptus公司的聯合創始人之一Graziano Obertelli寫了一篇題為Will My Internet Be Faster的博客文章，用較長的篇幅討論了如何基于IOPS進行容量規劃的問題。我將GrazianoObertelli的博客文章翻譯為《我的網絡會變得更快嗎？》，可供參考。
服務等級協議
經常有客戶問我們：“用了Eucalyptus之后，是不是就可以保證我的云主機不會宕機了呢？”坦率地說，不僅Eucalyptus不能，其他的云管理平臺也不能。
宕機時間，或者說不宕機時間，是數據中心領域的一個奇妙參數，通常被稱為服務等級協議（Service Level Agreement，SLA）。服務等級協議是服務合同的一部分，通常用年度不宕機時間百分比（AnnualUptime Percentage）來表示。很顯然，根據年度不宕機時間百分比，可以計算出一年內允許宕機的總時間。常見的SLA條款包括99%（一年可以宕機3.65天，也就是87.6小時），99.9%（一年可以宕機8.8小時），99.99%（一年可以宕機53分鐘）。Linode的SLA條款為99.9％（一年可以宕機8.8小時），AWS的SLA條款為99.95％（一年可以宕機4.4小時），阿里云的SLA條款為99.9%（一年可以宕機8.8小時），而盛大云則沒有任何關于SLA的承諾。通常來說，更高的SLA條款意味這更高的硬件、軟件和人力資源投入。到目前為止，尚未出現能夠保障100%SLA條款的產品和技術。
其他
成功地運用云計算，需要硬件與拓撲、軟件架構、應用場景、容量規劃、服務等級協議等等多個方面的準備。我們在前面已經說過，類似于AWS的云計算更多地是一種新的管理和分配計算資源的理念，而不是一種新的技術。使用類似于AWS的云計算服務要求用戶了解一些基本的概念，并且通常需要對應用做一些修改才能夠達到最佳的效果。成功的云計算要求服務提供商和服務使用者都要為云計算做好準備。如果你只是想延用老的方式來使用云計算，基本上很難獲得成功。
京公網安備 11010502049343號