[譯] 企業級 OpenStack 的六大需求（第 1 部分）：API 高可用、管理和安全

全文包括三部分：

• 第一部分：API 高可用和管理以及安全模型
• 第二部分：開放架構和混合雲兼容
• 第三部分：彈性架構和全球交付

 

引言

    OpenStack 是構造企業級私有云的很是理想的基礎。它立志成爲新一代雲操做系統的內核。可是，目前它還不是一個完整的雲操做系統。在它未來可能成爲雲操做系統以前，咱們仍是把它看作雲操做系統的內核比較好。

    目前，OpenStack 在一些關鍵領域還存在挑戰，要應對這些挑戰，OpenStack 須要經過健壯的企業級產品來交付。業界提供的這些產品，能提供支持、快速安裝、平常管理工具和其它一些必要的東西。若是沒有提供這些產品的廠商，OpenStack 將永遠不會普遍地被採用。OpenStack 不是 MySQL。它相似 Linux 內核，正如Linux 內核同樣，你須要一個完整的操做系統才能運行它。那企業級 OpenStack 到底須要什麼呢？有如下六個關鍵的因素：

1. 99.999% 的 API 可用性以及可擴展的控制平面
2. 健壯的管理和安全模型
3. 開放的架構
4. 混合雲兼容性
5. 可擴展的彈性架構
6. 全面的支持和服務

    若是大家公司須要一個企業級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年就會和傳統應用在數量上持平了：

    

  下一代應用將會是大多數企業將來競爭力之源泉，它們也已經在引領這些企業加速採用適應雲的流程，以及從新思考他們的雲戰略。正是已經觀察到這個現象，Forrester 的分析師 Craig Le Clari 寫道：」僅僅十年時間，財富1000名單上的百分之七十的企業已經消失了 - 由於它們不能適應這種變化「。

 

  咱們已經進入了一個關係到企業生死存亡的時刻，而 OpenStack 將會成爲採用敏捷和成功實施 DevOps 的關鍵。  

  需求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 Randy Bias