全文包括三部分:
引言
OpenStack 是構造企業級私有雲的非常理想的基礎。它立志成為新一代雲操作系統的內核。但是,目前它還不是一個完整的雲操作系統。在它將來可能成為雲操作系統之前,我們還是把它看做雲操作系統的內核比較好。
目前,OpenStack 在一些關鍵領域還存在挑戰,要應對這些挑戰,OpenStack 需要通過健壯的企業級產品來交付。業界提供的這些產品,能提供支持、快速安裝、日常管理工具和其它一些必要的東西。如果沒有提供這些產品的廠商,OpenStack 將永遠不會廣泛地被采用。OpenStack 不是 MySQL。它類似 Linux 內核,正如Linux 內核一樣,你需要一個完整的操作系統才能運行它。那企業級 OpenStack 到底需要什么呢?有以下六個關鍵的因素:
- 99.999% 的 API 可用性以及可擴展的控制平面
- 健壯的管理和安全模型
- 開放的架構
- 混合雲兼容性
- 可擴展的彈性架構
- 全面的支持和服務
如果你們公司需要一個企業級OpenStack 方案,請繼續閱讀下去,看看一個真正的企業級私有雲能夠和應該提供什么。接下來兩周,我會寫包括多個部分的一系列博客 “企業級 OpenStack 的6大需求”。首先讓我們看看企業中 OpenStack 所處的位置開始吧。
企業數據中心中的OpenStack
敏捷是雲的一個新的關鍵詞,而 DevOps 被看作實現敏捷的必由之路。正如 Linux 向 Web 應用提供了新的平台一樣,OpenStack 向在企業內部及時交付開發人員的產出提供了一個理想的平台。如果 OpenStack 僅僅是“便宜的 VMware”,那么它對企業來說就沒多大的價值了。相反,OpenStack 提供了一個非常好的有關如何來打造類似於主要公有雲比如亞馬遜(AWS)和 Google Cloud Platform(GCP)的彈性私有雲的樣板。就像 Hadoop 將 Google的 MapReduce (加上它的參考架構)推向大眾一樣,OpenStack 將 AWS/GCP 式樣的的基礎架構即服務(IaaS)推向了每個用戶。它就是能實現企業內部 DevOps 的終極平台。
關於 DevOps 的任何討論,往往很快就會限於語義學爭論的泥潭。然而,我們都認可的是,介於應用開發者和IT基礎架構運維人員之間的障礙必須被移除。一次又一次,我從幾個客戶那里都聽到一個大致相同的故事:“我們帶着我們新應用的長長的需求清單去找我們的基礎設施運維團隊。 他們告訴我,部署這個應用需要18個月的時間和 $10M 的費用。於是我們就去了亞馬遜的網站。我們無法讓他們針對我們的應用做什么定制,因此我們不得不改變我們的應用模型,但是我們馬上就將它發布出去了”。這是因為,亞馬遜的內在價值和成本其實沒多少關系,而是更多的與能立即響應需求的、彈性的、以開發者為中心的交付模型有關。
OpenStack 能在企業內部提供類似的平台。私有雲可以基於公有雲模型來構造,使得開發者同時擁有集中式 IT 控制和支配。本質上,它是兩者融合的最佳平台,這也是OpenStack驅動的私有雲的真正價值。
為什么敏捷如此重要呢?
我覺得這是顯而易見的,敏捷是驅動雲計算的原動力。商務需求的快速演進,已經驅動AWS獲得了不可思議的增長:
這些增長全部是新的網絡應用,或者微軟說的下一代應用。這些新的應用的絕大部分是在聚焦於全新的商業價值,典型地包括移動、社交、網站應用和大數據等。實際上,這種類型的應用的增長是如此快速,以至於 IDC 和 Gartner 都已經開始跟蹤它們了:
按照這個增長速度,新一代的應用在2018年就會和傳統應用在數量上持平了:
需求1 - 99.999%可用的控制平面:有高可靠性要求的應用需要高可靠的雲API
繼續我們圍繞企業級 OpenStack 進行討論,我們來討論一下 API 可用性是多么的關鍵,以及交付下一代應用是如何需要擴展雲控制平面的。
雲 API 的可用性
向全新的雲和 DevOps 模型轉型的一個關鍵能力是提供雲原生應用在彈性雲中的容錯能力。這些應用知道,任何服務器、磁盤、網絡設備隨時都可能出錯。它們及時檢測這些錯誤,並且做出實時響應。這正是亞馬遜和 GCP 如何工作的,以及為什么他們可以以更低的成本但是更高的靈活性來運行這些服務。要使一個應用能實時地適應不同組件的出錯,雲 API 需要有更高的可用性。
你的雲控制面板的吞吐量
API 的可用性不是唯一的衡量標准。你的雲控制平面的吞吐量(throughoutput)同樣關鍵。可以將控制平面想象成雲的指揮中樞。這是中央智能和編排層的核心。你的 API 是控制平面的一部分,對於 OpenStack 來說,包括所有的核心項目,以及日常的雲管理系統(通常是 OpenStack 企業級套件的一部分),以及所有必要的輔助服務,比如數據庫、OpenStack 各廠商插件等等。你的雲的控制平面必須能夠隨着雲的增長而增長。這意味着,總體上,你將會獲得更多的API操作的吞吐量(對象上傳/下載、鏡像上傳/下載、元數據更新等待)。
而這正是一個雲操作系統需要提供的。
99.99% 的 API 可用性和控制平面的擴展性
本質上講,在 99.5% SLA的基礎架構上,如果要運行 99.99-99.999% SLA 的應用的話,應用所需要使用的雲 API 也需要有99.99-99.999%的 SLA。其實你知道,交付5個9可用性的API 可不容易,因為它只允許每年有5.26分鍾的非計划停止運行時間。傳統的高可用方法,比如主/備或者多主選舉系統,往往需要幾分鍾的時間來做故障切換,這期間你的 API 端點(endpoint)是不可用的。
一個企業級的雲操作系統能提供分鍾內的甚至秒級的故障切換,來保證 99.999%甚至 99.9999% (6個9意味着每年只有 31.5 秒的停止服務時間)的可用性。設計上,在相對較低的成本上,使用經典的負載均衡技術,你的雲控制平面和 API 以 N 個主的方式運行,是可以達到這種可用性的。這里的 N 就是隨着雲的增長而需要的數目:
這讓我想到了等式的另一頭:你需要你的雲控制平面隨着你的雲的增長而增長。你不希望在雲增長時重構你的系統,你也不希望使用老的方法來擴展你的 API 端點。當你的系統使用主/備或者多主選舉的高可用方案時,其實每個時刻只有一個API端點可用。這意味着那個正在提供服務的服務器將是系統的瓶頸,而這是今天可擴展雲的世界里所不能接受的。
相反,使用負載均衡模式,你可以運行多主的活動 API 端點,擴展你的控制平面,同時達到高可用。這是最佳的方式,可以使得你的雲原生應用具有實時的容錯能力。
現在我們來談談日常的雲管理和雲安全。
需求2 - 健壯的管理:管理和保證雲安全是需要成本的(Managing and Securing Your Cloud is Not Free)
也許你已經了解到這一點,可是在企業內部打造一個健壯的、可管理的、安全的基礎設施是非常困難的。那種認為私有雲可以在下午構建好,晚上就可以投入生產的觀點是不對的,是和數據中心實際情況不合乎的。因此,如果你想要你的雲在將來能平穩地運轉,同時你又想要它交付得非常快速,那么你選擇一個已經被設計為能夠快速部署、日常管理和安全的 OpenStack 版本將對你有幫助。讓我們接着更深入些地探討這個問題。
健壯的管理
安裝只是管理 OpenStack 的開端。一個真正的雲操作系統將提供一個從設計上就能保證基礎設施團隊能成功交付服務的以運維為核心的雲管理工具套件。這些管理工具將提供:
- 可重用的架構模型,通常使用參考網絡架構將小集群(pod)或者組(block)連接在在一起
- 初始雲安裝和部署
- 典型的日常雲運維工具,包括日志、系統測量值和相關度分析
- 供雲運維人員使用的用來做整合和自動化的 CLI 和 API
- 用於可視化和分析的雲運維圖形界面
很多廠商想解決私有雲系統管理挑戰的嘗試都只停留在安裝上了。安裝只是一個長長過程的開端,如果你的雲的日常管理很麻煩,那么無論它的安裝是多么容易,它都將不怎么重要。我們都知道,運行一個生產系統通常是不容易的。實際上,在許多方面,私有雲都比傳統的基礎設施更復雜。為了簡化這種復雜性,從規模上,象 Google 和亞馬遜這些雲先鋒都已經采用使用基於多個小集群(pod)、集群(cluster)或者塊(block)的方式去設計、部署和管理他們的雲。Google 使用多集群;Facebook 使用多個三重組;但是其實它們本質上是相同的:以類似樂高積木的可重復的方式來構造雲和數據中心。企業級 OpenStack 驅動的雲操作系統將需要類似的方式來組織雲。
雲安裝好並運行起來以后,雲運維人員需要大量的工具來做運維,包括事件日志和系統監測等等。確實,在一個彈性雲中,過去往往非常關鍵的事件已經不是高優先級了(比如服務器或者交換機故障)。然后,你的雲不能是個黑盒子。你需要它是如何天復一天地運行的有關數據和信息,這樣你就可以在需要的時候解決特定的問題,更重要的是,使用相關性分析工具來監測反復發生的問題。單個的一個服務器故障不是什么大問題,但是,在大量設備上出現的任何常見問題,都是需要快速定位和解決的。
那你的雲如何運作的呢?不僅你自己需要知道,你的各種工具也需要知道。整合到已有的系統對雲來說非常關鍵。任何完善的解決方案都會提供 API 和 CLI 供你做整合和自動化。只是用於 OpenStack 管理需要的 CLI 和 API 是不夠的。如果管理你的物理服務器集群和單元?如何做到不僅從OpenStack,還要從 Linux 和其它非OpenStack 應用中按需獲取系統檢測數據和日志數據?你需要一個單一的統一的接口來做雲運維和管理。顯然,如果你有這種 API,還需要提供 GUI 來便於查看系統內的各種樣式和網絡檢測數據。
安全模型
雲的安全模型非常重要。要完整地討論這個主題,遠遠不是這個文章所能涵蓋的,但是有一個事情需要清楚:企業需要雲有一個可以理解的安全模型,特別是對控制平面而言。就像我前面所闡述的那樣,你的雲控制平面的API可用性和吞吐量對下一代應用的容錯性非常關鍵,同樣的,你的雲控制平面的安全性不能簡單地想當然。
你可以很容易地轉型到去中心化模型,但是,去中心化和擴展性不是一回事。你完全可以混用中心化和擴展技術,正如 Google 所采用的方式。將你的雲控制平面放在一個地方會讓你:
- 只需要去一個地方去定位錯誤
- 永遠不用靠猜來確定你的控制平面的位置
- 應用安全策略/域到你的雲控制平面
- 保持你的控制平面數據和數據平面數據完全分離
其中,最后一點可能是最重要的。你不會將你的 OpenStack 數據庫和虛機放在同一個存儲系統上。假如有人突破 Hypervisor 進入虛機會怎么樣呢?或者,相反,如果有人突破 API 進入了控制平面又會怎么樣?
企業內的最優做法是,將不同的組件分到不同的安全域(通常使用多個VLAN),然后對不同的安全域配置不同的安全策略。分區域會延緩黑客的入侵,讓你有時間探測到它們,然后做出響應。在你的私有雲安全模型中使用類似的模型,對於確保你的雲安全非常關鍵。
雲管理和安全
就像我前面說的那樣,你的雲歷程從安裝開始。然后,你需要一系列的工具和安全模型,來使你能非常自信地日常管理你的雲。一個OpenStack驅動的企業級雲操作系統需要盡可能多地提供這些能力。
部分1總結
OpenStack 是為下一代應用搭建下一代私有雲的強大的基礎。只是,目前它還不是一個完整的雲操作系統,你需要有合作伙伴來提供完整的方案。這系列的日志會闡述企業級OpenStack私有雲的6大需求,而今天我談到了高可用的,可擴展的控制平面,以及健壯的安全管理工具。
下一文章中,我會談到圍繞開放的架構和減少廠商鎖定。然后,會闡述擴展性和性能,以及如何選擇提供全面服務和支持的合作伙伴。
原文:The 6 Requirements of Enterprise-grade OpenStack,Posted on Apr 28, 2014 by