談?wù)凮penStack的八年之癢

1、 談?wù)凮penStack的八年之癢 2010年10月，OpenStack發(fā)布了第一個(gè)版本；上個(gè)月，發(fā)布了它的第十八個(gè)版本Rocky。幾年前氣氛火爆，如今卻冷冷清清。Rocky版本宣布后，OpenStack群里也就出現(xiàn)了幾篇簡短的翻譯過來的文章。圈子里也不時(shí)飄出OpenStack是不是死了？誰誰誰又把全部OpenStack替換成Kubernetes了這種消息。這到底是為什么才短短幾年卻出現(xiàn)如此轉(zhuǎn)折呢？作為一個(gè)OpenStack用戶，在這篇文章里，我會(huì)從用戶視角，反思在過去的八年里，它到底走了一條怎樣的路；我也會(huì)試著展望從現(xiàn)在起的八年之后，OpenStack會(huì)過得好不好，甚至還在不在。我們是怎樣的

2、一個(gè)用戶？我們作為HH集團(tuán)云平臺團(tuán)隊(duì)的一部分，在集團(tuán)內(nèi)搭建了如下圖所示的基礎(chǔ)云平臺：其主要特征如下：計(jì)算：支持KVM、ESXi 和裸金屬服務(wù)器等三個(gè)資源池。網(wǎng)絡(luò)：采用 Neutron + VLAN + OVS 實(shí)現(xiàn)了虛擬網(wǎng)絡(luò)。存儲(chǔ)：采用 Ceph 和 SAN 實(shí)現(xiàn)了塊存儲(chǔ)，采用Ceph實(shí)現(xiàn)了對象存儲(chǔ)。區(qū)：在兩個(gè)城市三個(gè)機(jī)房部署了3個(gè)區(qū)域，每個(gè)區(qū)域內(nèi)劃分資源池，資源池內(nèi)再按機(jī)架劃分可用區(qū)。三個(gè)層級都用戶都可見，可按需選擇。另外，我們還嘗試搞過一個(gè)小型公有云區(qū)域。功能：利用了Mitaka版本中的Glance/Nova/Neutron/Cinder/Keystone/Heat/Telemetry/O

3、VSvAPP/Trove/Ironic等組件。管理：采用自研云管理平臺管理多個(gè)區(qū)域。容器云平臺：基于Kubernetes的容器云平臺運(yùn)行在自己管理的物理機(jī)上。團(tuán)隊(duì)：最多時(shí)候8個(gè)人的OpenStack研發(fā)團(tuán)隊(duì)，3個(gè)人的運(yùn)維團(tuán)隊(duì)。一些感受：總得來說運(yùn)行的還蠻好，我們在技術(shù)和產(chǎn)品選型、研發(fā)、運(yùn)維等方面都做得不錯(cuò)，團(tuán)隊(duì)非常給力，研發(fā)周期較短，迭代快速?，F(xiàn)在它支撐著集團(tuán)大大小小幾百套系統(tǒng)，而且很穩(wěn)定，運(yùn)維壓力已經(jīng)比較小了。在此，我也要感謝并肩戰(zhàn)斗過的小伙伴們。也出現(xiàn)過一些穩(wěn)定性問題：比如Neutron VR 偶爾會(huì)自動(dòng)切換（我們還有一個(gè)小型公有云環(huán)境，采用Neutron + VR + OVS 架構(gòu)）；K

4、VM虛擬機(jī)偶爾自動(dòng)重啟甚至宕機(jī)等；KVM對windows的支持比較差，偶爾出現(xiàn)莫名其妙的問題，比如磁盤脫機(jī)、藍(lán)屏、無法啟動(dòng)等。監(jiān)控組件、日志組件很不健全，都需要我們自己大改或者從零搭建。除了核心模塊，其它模塊幾乎都是半拉子工程。以Trove 為例，我們花了不少時(shí)間，幾乎重寫了一半的代碼，也就實(shí)現(xiàn)了最基本的數(shù)據(jù)庫實(shí)例的創(chuàng)建和管理功能。OpenStack 離公有云需求的差距實(shí)在太遠(yuǎn)。OpenStack 的定位和對標(biāo)到底該是什么？ OpenStack社區(qū)在2010年提出的原始使命是提供一個(gè)滿足公有云和私有云需求的開源的云計(jì)算平臺。那個(gè)時(shí)候，私有云還沒什么參照物，因此可以認(rèn)為最早的時(shí)候OpenStac

5、k 的使命就是做開源的AWS。這真是一個(gè)宏偉的目標(biāo)，多么讓人激動(dòng)人心啊，甚至搞得VMware和AWS的心里都泛起了層層漣漪！然而，從2014年起的用戶調(diào)查結(jié)果看，OpenStack做不了公有云，私有云才是OpenStack的主戰(zhàn)場，因?yàn)閮煞N私有云環(huán)境加起來有80%，而公有云的比率在2017年才12%，而且是在不斷萎縮。因此，說OpenStack的實(shí)際定位是在私有云，這個(gè)毋庸置疑。企業(yè)私有云環(huán)境中，VMware 是真正的老大。因此，OpenStack這要做私有云的目標(biāo)，說好聽點(diǎn)，要向 VMware學(xué)習(xí)；說難聽點(diǎn)，就是要替代掉VMware。而 VMware vSphere 提供的只是虛擬化環(huán)境，因

6、此 OpenStack 對標(biāo)的對象我認(rèn)為應(yīng)該是 VMware的 虛擬化功能+AWS的 Cloud 功能，主要是云API。但是，因?yàn)橐婚_始 OpenStack 對標(biāo)的是 AWS，而AWS 是公有云不是私有云，這就導(dǎo)致了后來很多問題的出現(xiàn)，下文會(huì)仔細(xì)道來。VMware 虛擬化+AWS Cloud 功能這兩部分中，因?yàn)橐婚_始OpenStack 就是對標(biāo)AWS的，因此 Cloud部分應(yīng)該說做得還是很不錯(cuò)的，或者說克隆的不錯(cuò)。這從用戶調(diào)查的為什么組織會(huì)選擇OpenStack？部分的答案中也能看出來，即開放平臺和API的標(biāo)準(zhǔn)化是第一業(yè)務(wù)驅(qū)動(dòng)力。那VMware 虛擬化對標(biāo)部分的情況又如何呢？來看一下 VMw

7、are vSphere 和 OpenStack 基礎(chǔ)功能的對比：從上表可以看出，大部分的vSphere 的功能OpenStack都沒有實(shí)現(xiàn)，或者只實(shí)現(xiàn)了一點(diǎn)。那結(jié)果只能是，OpenStack 不具備對 VMware 的替代能力，也就無法驅(qū)動(dòng)用戶去放棄VMware 轉(zhuǎn)向 OpenStack了。大帳篷模式的問題到底在哪？2015年，OpenStack 社區(qū)開始使用大帳篷模式。該模式把OpenStack項(xiàng)目分成兩大類：核心項(xiàng)目和非核心項(xiàng)目。核心項(xiàng)目只有六個(gè)，其余都是非核心項(xiàng)目。根據(jù)個(gè)人理解，我簡單地對這個(gè)圖的一些問題做下說明：六個(gè)核心服務(wù)發(fā)展得確實(shí)不錯(cuò)，但是問題依然不少。一方面，如下面2017年4月

8、的用戶調(diào)查結(jié)果，前幾個(gè)核心項(xiàng)目的使用率都超過了90%。另一方面，用戶對核心項(xiàng)目的吐槽一直沒停止過，每年的用戶調(diào)查報(bào)告中都有好幾頁記錄著用戶的槽點(diǎn)。不管是對比VMware 還是對比AWS，OpenStack核心服務(wù)的范圍都太小了，導(dǎo)致它缺乏了一些必要的功能。我認(rèn)為至少以下幾個(gè)服務(wù)需要進(jìn)入核心服務(wù)列表：編排服務(wù)Heat：編排服務(wù)是云的基礎(chǔ)性服務(wù)之一。一來用戶可以通過編排服務(wù)自行創(chuàng)建和銷毀云資源，二來很多二級服務(wù)可以通過提供編排模版的方式來提供給用戶，三來可以與第三方云管平臺和工具對接，從而培育其生態(tài)。監(jiān)控服務(wù)Ceilometer：一個(gè)云生產(chǎn)環(huán)境離不開一個(gè)強(qiáng)壯的監(jiān)控服務(wù)。到目前為止，Ceilomet

9、er 項(xiàng)目都還問題重重，比如規(guī)模性問題、性能問題、功能覆蓋問題等。裸機(jī)服務(wù) Ironic：裸機(jī)在私有云中有很多的應(yīng)用場景，比如運(yùn)行數(shù)據(jù)庫、大數(shù)據(jù)平臺、容器平臺等。如果OpenStack把Ironic做好了，那這就會(huì)成為與VMware相比的一大優(yōu)勢，同時(shí)還能成為一些需要利用裸機(jī)的應(yīng)用的支撐平臺?，F(xiàn)在的Ironic項(xiàng)目，實(shí)在太重太復(fù)雜，與物理網(wǎng)絡(luò)設(shè)備關(guān)聯(lián)太深。但是，如果可以像LINUX的kickstart和cobbler一樣，就靈活輕量多了，這個(gè)過程比如像vmware里物理機(jī)可以批量部署ESXI，然后把ESXI納管進(jìn)來，就可以使用VC里的所有服務(wù)，這樣的過程就比較合理了。日志服務(wù)：同監(jiān)控服務(wù)一樣，

10、日志服務(wù)也是云平臺的一個(gè)基礎(chǔ)性服務(wù)，如同AWS 的CloudWatch和所有項(xiàng)目都打通了一樣。遺憾的是，到現(xiàn)在為止，OpenStack都沒有一個(gè)原生的日志服務(wù)項(xiàng)目。部署服務(wù)：部署對私有云很重要。OpenStack需要一個(gè)提供象 Mirantis Fuel 這樣的圖形化一鍵部署工具的核心服務(wù)。OpenStack社區(qū)把過多精力耗費(fèi)在了一些看起來很有前途，但實(shí)際上卻比較雞肋的服務(wù)項(xiàng)目中，比如容器服務(wù)Magnum、大數(shù)據(jù)服務(wù) Sahara、數(shù)據(jù)庫服務(wù) Trove、容器化部署服務(wù)Kolla。好吧，我曉得你可能有不同的看法，我不想爭論，還是來看用戶調(diào)查報(bào)告中的數(shù)據(jù)吧。一方面，用戶對這些項(xiàng)目很感興趣。我認(rèn)為

11、至少有三個(gè)原因，一來是人們對新事物都有好奇心，二來是OpenStack社區(qū)的大力宣揚(yáng)，三是殷切期望。下面的數(shù)據(jù)來自201704 用戶調(diào)查報(bào)告：但是這些服務(wù)在實(shí)際的生產(chǎn)環(huán)境中部署的案例卻非常少，而且是越來越少：（備注：圖中的數(shù)字是百分比）那到底是什么原因?qū)е逻@些新服務(wù)叫好不叫座呢？我認(rèn)為有幾個(gè)原因：私有云和公有云對云平臺需求的差異。下圖是一個(gè)我認(rèn)為比較典型的私有云環(huán)境：它具有幾個(gè)特點(diǎn)：只有底層的物理機(jī)管理系統(tǒng)是統(tǒng)一的，而上面的多個(gè)平臺是分離的。而公有云上，云平臺是統(tǒng)一的。平臺是分離的。這可能有幾個(gè)原因，一是管理因素，每個(gè)平臺往往由不同部門在管理和使用；二是運(yùn)維因素，把平臺都放在一起，運(yùn)維團(tuán)隊(duì)搞不

12、定這個(gè)單體平臺的運(yùn)維，必須分而治之；三是技術(shù)因素，私有云領(lǐng)域還沒出現(xiàn)象AWS和阿里云這種能把這幾個(gè)平臺納管在一起的統(tǒng)一云平臺；四是在某些企業(yè)里限于等保和安全的需要，某個(gè)大業(yè)務(wù)需要獨(dú)占資源池。除了基礎(chǔ)云平臺是在虛擬機(jī)級別實(shí)現(xiàn)多租戶外，其它平臺往往只是在管理平臺層面實(shí)現(xiàn)了多租戶，或者業(yè)務(wù)層面自己實(shí)現(xiàn)了多租戶，而下面是一個(gè)或幾個(gè)大的資源池。私有云環(huán)境中和公有云環(huán)境中，這些服務(wù)（其實(shí)應(yīng)該稱為應(yīng)用服務(wù)，與基礎(chǔ)服務(wù)分開來）的創(chuàng)建和管理方式迥然不同。在公有云環(huán)境中，因?yàn)槎嘧鈶粜枨?，云供?yīng)商需要提供這些服務(wù)的創(chuàng)建和管理服務(wù)，使得用戶自行創(chuàng)建、管理和銷毀這些環(huán)境。但是，私有云中，并沒有那么多需求，需要反復(fù)地創(chuàng)建

13、和銷毀這些服務(wù)的運(yùn)行環(huán)境。因此，在OpenStack 中實(shí)現(xiàn)容器平臺、大數(shù)據(jù)平臺的自動(dòng)化創(chuàng)建和銷毀服務(wù)這種需求不那么強(qiáng)烈，甚至可以認(rèn)為是偽需求。針對這些新應(yīng)用，OpenStack的使命首先應(yīng)該是讓它們在自身平臺上運(yùn)行好，而不是把運(yùn)行環(huán)境創(chuàng)建好。究其原因，我認(rèn)為這和早期OpenStack的使命有關(guān)，因?yàn)橐婚_始OpenStack是想做成開源的AWS，自然AWS的服務(wù)長什么樣子，OpenStack的服務(wù)就長成什么樣子。問題是，對于私有云和公有云的區(qū)別，OpenStack一直沒有重視，或者沒能力重視，因?yàn)閰⒄誂WS的各個(gè)服務(wù)在OpenStack中再實(shí)現(xiàn)一套，相對來說是比較容易的。而且，在OpenSta

14、ck紅火的時(shí)候，能開一個(gè)新的項(xiàng)目，是多么榮耀的事情啊，PR稿都會(huì)發(fā)好多。那為什么不應(yīng)該在這些項(xiàng)目上浪費(fèi)那么多時(shí)間，或者社區(qū)不該帶錯(cuò)方向呢？還是OpenStack的定位沒有明確和及時(shí)糾正。面對這些不斷出現(xiàn)的新應(yīng)用，OpenStack到底該做什么？是一門心思搞好自己的一畝三分地，同時(shí)滿足它們對自己的需求，實(shí)現(xiàn)對它們的良好支撐，還是不管如何都要去插一腿呢？我認(rèn)為本來應(yīng)該選擇的是前者，但社區(qū)實(shí)際上選擇的是后者。這些應(yīng)用的原生部署工具更好。OpenStack上的對應(yīng)項(xiàng)目，從一開始就做不好這些應(yīng)用的環(huán)境的創(chuàng)建和管理，隨著這些應(yīng)用的新版本發(fā)布，差距只會(huì)越來越大，到最后只留下一些既沒人維護(hù)也沒有用戶的半拉子項(xiàng)

15、目。OpenStack 社區(qū)中這些項(xiàng)目基本上都是不能進(jìn)入生產(chǎn)環(huán)境的半拉子工程，而且改動(dòng)成本相當(dāng)高。以我們使用Trove為例，在修改了幾乎一半的代碼后，也就實(shí)現(xiàn)了基本的數(shù)據(jù)庫實(shí)例創(chuàng)建和管理功能，離實(shí)際生產(chǎn)需求還有不小的差距。OpenStack 對 AWS 的學(xué)習(xí)只停留在形的表面，而沒有學(xué)到神。盡管AWS 上有一百多個(gè)服務(wù)，但是，我們看到的是AWS 扎扎實(shí)實(shí)地把基礎(chǔ)服務(wù)做好。舉幾個(gè)例子吧。區(qū)塊鏈現(xiàn)在很火是吧，AWS 上目前卻只提供了 CloudFormation 模板讓用戶自己去編排運(yùn)行區(qū)塊鏈的云資源；Kubernetes 現(xiàn)在也很火是吧，但AWS 卻連管理K8S集群的界面都不提供。那OpenSt

16、ack 對這些新型應(yīng)用到底該有什么樣的態(tài)度和做法呢？我認(rèn)為應(yīng)該是兩點(diǎn)：以不變應(yīng)萬變，做好這些新應(yīng)用的運(yùn)行基礎(chǔ)架構(gòu)環(huán)境，使得這些服務(wù)可以良好地運(yùn)行在由OpenStack管理的虛擬機(jī)/物理機(jī)、網(wǎng)絡(luò)和存儲(chǔ)中。做好Heat服務(wù)，象AWS一樣提供好模版，在用戶需要的時(shí)候，管理員使用這些模版把這些環(huán)境編排出來，然后交給普通用戶使用即可。為什么OpenStack在青年時(shí)期就出現(xiàn)了中年危機(jī)呢？ 我認(rèn)為有如下幾個(gè)原因。當(dāng)然了，這肯定不是全部。(1)容器的出現(xiàn)，對OpenStack的沖擊很大。但是，我們也要看到，容器的出現(xiàn)，并沒有使得VMware 和以AWS 為代表的IaaS云服務(wù)商叫苦連天。OpenStack該

17、做的不是去抱怨既生瑜，何生亮，而應(yīng)該是反思為什么OpenStack沒能做好容器的底層架構(gòu)。以 AWS 為例，它有兩個(gè)容器相關(guān)項(xiàng)目，一個(gè)是它自研的ECS，這是一個(gè)Docker 容器管理服務(wù)，容器運(yùn)行在EC2主機(jī)上。另一個(gè)是EKS，是一個(gè)Kubernetes 運(yùn)行環(huán)境的創(chuàng)建和管理服務(wù)。AWS 為了支撐容器，主要做了幾件事情：1. 創(chuàng)造了 amazon-ecs-cni-plugin 項(xiàng)目，使得容器可以很好地運(yùn)行在VPC 中。2. 打通了用戶權(quán)限，用戶可以使用 AWS 的賬號登錄到 Kubernetes 環(huán)境中。3. 實(shí)現(xiàn)了一套Docker 容器管理服務(wù)，以及K8S管理節(jié)點(diǎn)。反觀 OpenStack

18、對容器的支持，它主要做了幾件事情，一是大張旗鼓搞 Magnum 項(xiàng)目，花很大力氣做K8S 環(huán)境的編排。另一個(gè)是有幾個(gè)網(wǎng)絡(luò)相關(guān)的項(xiàng)目，但是好像也沒什么人在用。結(jié)果就是，在OpenStack 環(huán)境中，K8S 環(huán)境的編排也沒做好（當(dāng)然了，要不要在私有云中做K8S 集群的創(chuàng)建和管理，前面有過討論），K8S 在OpenStack 環(huán)境中也運(yùn)行不好（因?yàn)獒槍8S的網(wǎng)絡(luò)、存儲(chǔ)都沒怎么搞好）。所以，我認(rèn)為，是OpenStack 沒有及時(shí)為 K8S 做好支撐，才導(dǎo)致 K8S 和 OpenStack 的分離之勢的。(2)社區(qū)沒規(guī)劃和控制好OpenStack的發(fā)展方向，在關(guān)鍵的發(fā)展階段浪費(fèi)了寶貴的時(shí)間和資源。前面

19、講過，OpenStack 社區(qū)沒能做好自己的定位，并聚焦于基礎(chǔ)性的核心服務(wù)，把底部做結(jié)實(shí)。相反，就像一個(gè)毛頭小伙一樣，年輕時(shí)不好好學(xué)習(xí)苦練內(nèi)功卻被外面的花花世界吸引，成天不務(wù)正業(yè)，到了成年時(shí)卻發(fā)現(xiàn)沒能培養(yǎng)其基本的競爭力。另外，在問題出現(xiàn)的時(shí)候，社區(qū)沒能做到力挽狂瀾，沒能及時(shí)糾正發(fā)展方向。(3)部分OpenStack創(chuàng)業(yè)公司太浮躁，沒能做好非常關(guān)鍵的產(chǎn)品研發(fā)和服務(wù)。在高峰時(shí)，一些創(chuàng)業(yè)公司們追求的是社區(qū)的貢獻(xiàn)量，而不管貢獻(xiàn)質(zhì)量，甚至是刷貢獻(xiàn)量；追求的是用戶數(shù)量，不惜以低于成本價(jià)的方式，而不管項(xiàng)目能不能做成，用戶會(huì)不會(huì)滿意；追求的是PR文章和各種炒作，而沒能認(rèn)真地去做用戶案例?？傊a(chǎn)品和服務(wù)沒有做

20、好，用戶對OpenStack的口碑和信心沒有樹立起來。相對地，一些認(rèn)認(rèn)真真做產(chǎn)品的公司，其OpenStack云業(yè)務(wù)卻發(fā)展得很好，這說明OpenStack其實(shí)是可以做好的，用戶也是愿意用的。(4)很多客戶，特別是大部分傳統(tǒng)企業(yè)，實(shí)際上用VMware虛擬化就夠了，不一定需要用云。公司的運(yùn)維體系、資源交付體系，以及應(yīng)用的研發(fā)、運(yùn)行和設(shè)計(jì)架構(gòu)，都還是虛擬化時(shí)代的那一套，因此VMware支撐現(xiàn)有應(yīng)用也夠了。這從VMware 財(cái)報(bào)上其收入繼續(xù)增長也能看出來。 因此，讓這些客戶從VMware轉(zhuǎn)到OpenStack的動(dòng)力能有多大，其實(shí)是個(gè)很大的問題。OpenStack的未來到底會(huì)如何呢？個(gè)人認(rèn)為OpenStack的未來會(huì)有兩條路：一條是OpenStack 只作為KVM虛擬機(jī)和Ceph存儲(chǔ)卷的編排器而會(huì)走的路。這條路走下去，它會(huì)免不了走到和CloudStack這樣的開源云平臺同樣的結(jié)局，那就是還未真正興起就開始真正凋零