OpenStack的八年之癢

2010年10月，OpenStack發布了第一個版本；上個月，發布了它的第18個版本Rocky。幾年前氣氛火爆，如今卻冷冷清清。Rocky版本宣布后，OpenStack群里也就出現了幾篇簡短的翻譯過來的文章。圈子里也不時飄出『OpenStack是不是死了？』『誰誰誰又把全部OpenStack替換成Kubernetes了』這種消息。這到底是為什么才短短幾年卻出現如此轉折呢？作為一個OpenStack用戶，在這篇文章里，我會從用戶視角，反思在過去的八年里，它到底走了一條怎樣的路；我也會試着展望從現在起的八年之后，OpenStack會過得好不好，甚至還在不在。 

我們是怎樣的一個用戶？

我們作為HH集團雲平台團隊的一部分，在集團內搭建了如下圖所示的基礎雲平台：

 

其主要特征如下：

• 計算：支持KVM、ESXi 和裸金屬服務器等三個資源池。

• 網絡：采用 Neutron + VLAN + OVS 實現了虛擬網絡。

• 存儲：采用 Ceph 和 SAN 實現了塊存儲，采用Ceph實現了對象存儲。

• 區：在兩個城市三個機房部署了3個區域，每個區域內划分資源池，資源池內再按機架划分可用區。三個層級都用戶都可見，可按需選擇。另外，我們還嘗試搞過一個小型公有雲區域。

• 功能：利用了Mitaka版本中的Glance/Nova/Neutron/Cinder/Keystone/Heat/Telemetry/OVSvAPP/Trove/Ironic等組件。

• 管理：采用自研雲管理平台管理多個區域。

• 容器雲平台：基於Kubernetes的容器雲平台運行在自己管理的物理機上。

• 團隊：最多時候8個人的OpenStack研發團隊，3個人的運維團隊。

一些感受：

• 總得來說運行的還蠻好，我們在技術和產品選型、研發、運維等方面都做得不錯，團隊非常給力，研發周期較短，迭代快速。現在它支撐着集團大大小小幾百套系統，而且很穩定，運維壓力已經比較小了。在此，我也要感謝並肩戰斗過的小伙伴們。

• 也出現過一些穩定性問題：比如Neutron VR 偶爾會自動切換（我們還有一個小型公有雲環境，采用Neutron + VR + OVS 架構）；KVM虛擬機偶爾自動重啟甚至宕機等；KVM對windows的支持比較差，偶爾出現莫名其妙的問題，比如磁盤脫機、藍屏、無法啟動等。

• 監控組件、日志組件很不健全，都需要我們自己大改或者從零搭建。

• 除了核心模塊，其它模塊幾乎都是半拉子工程。以Trove 為例，我們花了不少時間，幾乎重寫了一半的代碼，也就實現了最基本的數據庫實例的創建和管理功能。

• OpenStack 離公有雲需求的差距實在太遠。

OpenStack 的定位和對標到底該是什么？

  OpenStack社區在2010年提出的原始使命是『提供一個滿足公有雲和私有雲需求的開源的雲計算平台』。那個時候，私有雲還沒什么參照物，因此可以認為最早的時候OpenStack 的使命就是做開源的AWS。這真是一個宏偉的目標，多么讓人激動人心啊，甚至搞得VMware和AWS的心里都泛起了層層漣漪！然而，從2014年起的用戶調查結果看，OpenStack做不了公有雲，私有雲才是OpenStack的主戰場，因為兩種私有雲環境加起來有80%，而公有雲的比率在2017年才12%，而且是在不斷萎縮。因此，說OpenStack的實際定位是在私有雲，這個毋庸置疑。

 

企業私有雲環境中，VMware 是真正的老大。因此，OpenStack這要做私有雲的目標，說好聽點，要向 VMware學習；說難聽點，就是要替代掉VMware。而 VMware vSphere 提供的只是虛擬化環境，因此 OpenStack 對標的對象我認為應該是 『VMware的 虛擬化功能』+『AWS的 Cloud 功能，主要是雲API』。但是，因為一開始 OpenStack 對標的是 AWS，而AWS 是公有雲不是私有雲，這就導致了后來很多問題的出現，下文會仔細道來。 

 『VMware 虛擬化』+『AWS Cloud 功能』這兩部分中，因為一開始OpenStack 就是對標AWS的，因此 『Cloud』部分應該說做得還是很不錯的，或者說克隆的不錯。這從用戶調查的『為什么組織會選擇OpenStack？』部分的答案中也能看出來，即開放平台和API的標准化是第一業務驅動力。 

 那『VMware 虛擬化』對標部分的情況又如何呢？來看一下 VMware vSphere 和 OpenStack 基礎功能的對比：

VMware 功能	描述	相應的OpenStack功能
vMotion	可以使運行中的虛擬機從一台物理服務器實時遷移到另一台物理服務器，它實現了零停機時間和連續可用的服務。vSphere 6.0 支持跨數據中心的vMotion。	可以利用 KVM live migration 功能實現虛擬的實時遷移，但是需要結合第三方工具。
DRS（分布式資源調度）	跨資源池不間斷地監控利用率，並根據反映業務需要和不斷變化的優先級的預定義規則，在多台虛擬機之間智能地分配可用資源。	不支持。
分布式電源管理（DPM）	DPM提供了通過動態調整群集容量來匹配虛擬機資源需求，以達到節省電力的目的，DPM自動整合虛擬機到較少的ESXi主機上，並對一定周期內資源利用率低的多於ESXi主機執行斷電，如果資源需求增加，ESXi主機重新通電回到群集，虛擬機重新分配到群集內所有可用的ESXI主機上。	不支持。
HA	持續監控資源池中的所有物理服務器，並重啟受服務器故障影響的虛擬機。還可以監控和檢測虛擬機的“客戶操作系統”故障，並在用戶指定的間隔后自動啟動虛擬機	不支持。
FT	通過創建和維護等同於主虛擬機並可在發生故障切換時替換主虛擬機的輔助虛擬機來為虛擬機提供連續可用性	不支持。
vShield	VMware 安全虛擬設備套件	Neutron 的安全組和防火牆實現了 vShield 的部分功能
vDS（分布式虛擬交換機）	讓用戶可以從一個集中界面為整個數據中心設置虛擬機訪問交換，從而簡化虛擬機網絡連接。	Neutron 利用 OVS 實現了部分功能
Storage API		Cinder
SRM	站點災難恢復	有Freezer 項目，但尚不足以進入生產環境。

從上表可以看出，大部分的vSphere 的功能OpenStack都沒有實現，或者只實現了一點。那結果只能是，OpenStack 不具備對 VMware 的替代能力，也就無法驅動用戶去放棄VMware 轉向 OpenStack了。

大帳篷模式的問題到底在哪？

2015年，OpenStack 社區開始使用『大帳篷』模式。該模式把OpenStack項目分成兩大類：核心項目和非核心項目。核心項目只有六個，其余都是非核心項目。

 

根據個人理解，我簡單地對這個圖的一些問題做下說明：

1. 六個核心服務發展得確實不錯，但是問題依然不少。

   一方面，如下面2017年4月的用戶調查結果，前幾個核心項目的使用率都超過了90%。另一方面，用戶對核心項目的吐槽一直沒停止過，每年的用戶調查報告中都有好幾頁記錄着用戶的槽點。

2. 不管是對比VMware 還是對比AWS，OpenStack核心服務的范圍都太小了，導致它缺乏了一些必要的功能。我認為至少以下幾個服務需要進入核心服務列表：

• 編排服務Heat：編排服務是雲的基礎性服務之一。一來用戶可以通過編排服務自行創建和銷毀雲資源，二來很多二級服務可以通過提供編排模版的方式來提供給用戶，三來可以與第三方雲管平台和工具對接，從而培育其生態。

• 監控服務Ceilometer：一個雲生產環境離不開一個強壯的監控服務。到目前為止，Ceilometer 項目都還問題重重，比如規模性問題、性能問題、功能覆蓋問題等。

• 裸機服務 Ironic：裸機在私有雲中有很多的應用場景，比如運行數據庫、大數據平台、容器平台等。如果OpenStack把Ironic做好了，那這就會成為與VMware相比的一大優勢，同時還能成為一些需要利用裸機的應用的支撐平台。現在的Ironic項目，實在太重太復雜，與物理網絡設備關聯太深。但是，如果可以像LINUX的kickstart和cobbler一樣，就靈活輕量多了，這個過程比如像vmware里物理機可以批量部署ESXI，然后把ESXI納管進來，就可以使用VC里的所有服務，這樣的過程就比較合理了。

• 日志服務：同監控服務一樣，日志服務也是雲平台的一個基礎性服務，如同AWS 的CloudWatch和所有項目都打通了一樣。遺憾的是，到現在為止，OpenStack都沒有一個原生的日志服務項目。

• 部署服務：部署對私有雲很重要。OpenStack需要一個提供象 Mirantis Fuel 這樣的圖形化一鍵部署工具的核心服務。

3. OpenStack社區把過多精力耗費在了一些看起來很有前途，但實際上卻比較雞肋的服務項目中，比如容器服務Magnum、大數據服務 Sahara、數據庫服務 Trove、容器化部署服務Kolla。好吧，我曉得你可能有不同的看法，我不想爭論，還是來看用戶調查報告中的數據吧。

•  一方面，用戶對這些項目很感興趣。我認為至少有三個原因，一來是人們對新事物都有好奇心，二來是OpenStack社區的大力宣揚，三是殷切期望。下面的數據來自201704 用戶調查報告：

 

• 但是這些服務在實際的生產環境中部署的案例卻非常少，而且是越來越少：

 

（備注：圖中的數字是百分比）

• 那到底是什么原因導致這些新服務叫好不叫座呢？我認為有幾個原因：

（1）私有雲和公有雲對雲平台需求的差異。

下圖是一個我認為比較典型的私有雲環境：

 

它具有幾個特點：

• 只有底層的物理機管理系統是統一的，而上面的多個平台是分離的。而公有雲上，雲平台是統一的。

• 平台是分離的。這可能有幾個原因，一是管理因素，每個平台往往由不同部門在管理和使用；二是運維因素，把平台都放在一起，運維團隊搞不定這個單體平台的運維，必須分而治之；三是技術因素，私有雲領域還沒出現象AWS和阿里雲這種能把這幾個平台納管在一起的統一雲平台；四是在某些企業里限於等保和安全的需要，某個大業務需要獨占資源池。

• 除了基礎雲平台是在虛擬機級別實現多租戶外，其它平台往往只是在管理平台層面實現了多租戶，或者業務層面自己實現了多租戶，而下面是一個或幾個大的資源池。

私有雲環境中和公有雲環境中，這些服務（其實應該稱為應用服務，與基礎服務分開來）的創建和管理方式迥然不同。在公有雲環境中，因為多租戶需求，雲供應商需要提供這些服務的創建和管理服務，使得用戶自行創建、管理和銷毀這些環境。但是，私有雲中，並沒有那么多需求，需要反復地創建和銷毀這些服務的運行環境。因此，在OpenStack 中實現容器平台、大數據平台的自動化創建和銷毀服務這種需求不那么強烈，甚至可以認為是偽需求。針對這些新應用，OpenStack的使命首先應該是讓它們在自身平台上『運行好』，而不是『把運行環境創建好』。

究其原因，我認為這和早期OpenStack的使命有關，因為一開始OpenStack是想做成開源的AWS，自然AWS的服務長什么樣子，OpenStack的服務就長成什么樣子。問題是，對於私有雲和公有雲的區別，OpenStack一直沒有重視，或者沒能力重視，因為參照AWS的各個服務在OpenStack中再實現一套，相對來說是比較容易的。而且，在OpenStack紅火的時候，能開一個新的項目，是多么榮耀的事情啊，PR稿都會發好多。

那為什么不應該在這些項目上浪費那么多時間，或者社區不該帶錯方向呢？

• 還是OpenStack的定位沒有明確和及時糾正。面對這些不斷出現的新應用，OpenStack到底該做什么？是一門心思搞好自己的一畝三分地，同時滿足它們對自己的需求，實現對它們的良好支撐，還是不管如何都要去插一腿呢？我認為本來應該選擇的是前者，但社區實際上選擇的是后者。

• 這些應用的原生部署工具更好。OpenStack上的對應項目，從一開始就做不好這些應用的環境的創建和管理，隨着這些應用的新版本發布，差距只會越來越大，到最后只留下一些既沒人維護也沒有用戶的半拉子項目。

• OpenStack 社區中這些項目基本上都是不能進入生產環境的半拉子工程，而且改動成本相當高。以我們使用Trove為例，在修改了幾乎一半的代碼后，也就實現了基本的數據庫實例創建和管理功能，離實際生產需求還有不小的差距。

• OpenStack 對 AWS 的學習只停留在『形』的表面，而沒有學到『神』。盡管AWS 上有一百多個服務，但是，我們看到的是AWS 扎扎實實地把基礎服務做好。舉幾個例子吧。區塊鏈現在很火是吧，AWS 上目前卻只提供了 CloudFormation 模板讓用戶自己去編排運行區塊鏈的雲資源；Kubernetes 現在也很火是吧，但AWS 卻連管理K8S集群的界面都不提供。 

那OpenStack 對這些新型應用到底該有什么樣的態度和做法呢？我認為應該是兩點：

• 以不變應萬變，做好這些新應用的運行基礎架構環境，使得這些服務可以良好地運行在由OpenStack管理的虛擬機/物理機、網絡和存儲中。

• 做好Heat服務，象AWS一樣提供好模版，在用戶需要的時候，管理員使用這些模版把這些環境編排出來，然后交給普通用戶使用即可。 

為什么OpenStack在青年時期就出現了中年危機呢？ 

我認為有如下幾個原因。當然了，這肯定不是全部。

（1）容器的出現，對OpenStack的沖擊很大。但是，我們也要看到，容器的出現，並沒有使得VMware 和以AWS 為代表的IaaS雲服務商叫苦連天。OpenStack該做的不是去抱怨『既生瑜，何生亮』，而應該是反思為什么OpenStack沒能做好容器的底層架構。

• 以 AWS 為例，它有兩個容器相關項目，一個是它自研的ECS，這是一個Docker 容器管理服務，容器運行在EC2主機上。另一個是EKS，是一個Kubernetes 運行環境的創建和管理服務。AWS 為了支撐容器，主要做了幾件事情：1. 創造了 amazon-ecs-cni-plugin 項目，使得容器可以很好地運行在VPC 中。2. 打通了用戶權限，用戶可以使用 AWS 的賬號登錄到 Kubernetes 環境中。3. 實現了一套Docker 容器管理服務，以及K8S管理節點。

• 反觀 OpenStack 對容器的支持，它主要做了幾件事情，一是大張旗鼓搞 Magnum 項目，花很大力氣做K8S 環境的編排。另一個是有幾個網絡相關的項目，但是好像也沒什么人在用。

• 結果就是，在OpenStack 環境中，K8S 環境的編排也沒做好（當然了，要不要在私有雲中做K8S 集群的創建和管理，前面有過討論），K8S 在OpenStack 環境中也運行不好（因為針對K8S的網絡、存儲都沒怎么搞好）。所以，我認為，是OpenStack 沒有及時為 K8S 做好支撐，才導致 K8S 和 OpenStack 的分離之勢的。

（2）社區沒規划和控制好OpenStack的發展方向，在關鍵的發展階段浪費了寶貴的時間和資源。前面講過，OpenStack 社區沒能做好自己的定位，並聚焦於基礎性的核心服務，把底部做結實。相反，就像一個毛頭小伙一樣，年輕時不好好學習苦練內功卻被外面的花花世界吸引，成天不務正業，到了成年時卻發現沒能培養其基本的競爭力。另外，在問題出現的時候，社區沒能做到力挽狂瀾，沒能及時糾正發展方向。

（3）部分OpenStack創業公司太浮躁，沒能做好非常關鍵的產品研發和服務。在高峰時，一些創業公司們追求的是社區的貢獻量，而不管貢獻質量，甚至是刷貢獻量；追求的是用戶數量，不惜以低於成本價的方式，而不管項目能不能做成，用戶會不會滿意；追求的是PR文章和各種炒作，而沒能認真地去做用戶案例。總之，產品和服務沒有做好，用戶對OpenStack的口碑和信心沒有樹立起來。相對地，一些認認真真做產品的公司，其OpenStack雲業務卻發展得很好，這說明OpenStack其實是可以做好的，用戶也是願意用的。

（4）很多客戶，特別是大部分傳統企業，實際上用VMware虛擬化就夠了，不一定需要用雲。公司的運維體系、資源交付體系，以及應用的研發、運行和設計架構，都還是虛擬化時代的那一套，因此VMware支撐現有應用也夠了。這從VMware 財報上其收入繼續增長也能看出來。 因此，讓這些客戶從VMware轉到OpenStack的動力能有多大，其實是個很大的問題。

OpenStack的未來到底會如何呢？

 個人認為OpenStack的未來會有兩條路：

• 一條是OpenStack 只作為KVM虛擬機和Ceph存儲卷的編排器而會走的路。這條路走下去，它會免不了走到和CloudStack這樣的開源雲平台同樣的結局，那就是還未真正興起就開始真正凋零。

 

• 另一條是OpenStack走AWS甚至VMware的道路，成為基礎雲、原生雲和未來Serverless雲的支撐平台。這種情況下，它的路會很長。

 

但是，遺憾的是，從現在的情況看，OpenStack應該是走在第一條路上，也許這就是很多人認為OpenStack快死掉了甚至已經死掉了的原因吧。 

我對OpenStack的感情 

我對OpenStack有着挺深的感情。是它，讓我認識了什么是雲，雲是怎么構建的、是如何運行的、是如何維護的等等。是從研究它開始，我開始從傳統軟件領域進入了雲領域，我也開始了寫博客的漫漫歷程，也通過它結識了很多朋友。因此，當看到有人故意詆毀它，甚至對它落井下石時，心里很不是滋味。其實，我覺得不光是我，整個IT領域都應該感謝OpenStack，它的出現大大加速了IT架構演進進程。

前面的內容，也許噴的成分居多，但是，請理解我的心情，因為本來OpenStack是可以發展得更好的，畢竟它曾經擁有過多么好的天時、地利和人和啊。從實際情況來看，如果企業有一個OpenStack研發團隊，或者找了一個靠譜的外部供應商，而且規模不是特別大，業務不是那么復雜，還有幾個給力的運維，OpenStack私有雲還是可以跑得挺好的。至少在國內，OpenStack已經成為了自主可控的私有雲雲平台的主要代表之一，在各行各業發光發熱。

不管它的結局如何，OpenStack都將在IT發展史上留下了濃墨重彩的一筆。 在此，我想感謝OpenStack項目、感謝OpenStack每一行代碼和每一個文檔、OpenStack社區，和所有給OpenStack做過貢獻的公司和人們。

 

謝謝您的閱讀，歡迎關注我的個人公眾號：

 

在我的微信公眾號上發表文章后，一天之后的閱讀情況如下：

所以也慶祝一下本人第一篇閱讀過萬的公眾號文章。：）

再對比一下在博客園的閱讀量和點贊數，我有幾點感受：

• 網站式博客在公眾號面前的競爭力已經很弱了。移動端的閱讀量已經占據絕大多數。
• 博客園的文章更多聚焦前端技術，以及較傳統的軟件開發技術，比如.Net 這種。
• 微信公眾號粉絲人數因為這篇文章增長了800多人，而博客園上粉絲只增加了2人。
• 博客園的運營模式也許在新形勢下需要有重新思考了。