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人。
• 博客園的運營模式也許在新形勢下須要有從新思考了。