歡迎光臨
每天分享高質量文章

談談OpenStack的八年之癢

2010年10月,OpenStack發佈了第一個版本;上個月,發佈了它的第十八個版本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 基礎功能的對比:


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

大帳篷樣式的問題到底在哪?

2015年,OpenStack 社區開始使用『大帳篷』樣式。該樣式把OpenStack專案分成兩大類:核心專案和非核心專案。核心專案只有六個,其餘都是非核心專案。

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

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

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

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

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

  • 監控服務Ceilometer:一個雲生產環境離不開一個強壯的監控服務。到目前為止,Ceilometer 專案都還問題重重,比如規模性問題、性能問題、功能改寫問題等。

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

  • 日誌服務:同監控服務一樣,日誌服務也是雲平臺的一個基礎性服務,如同AWS 的CloudWatch和所有專案都打通了一樣。遺憾的是,到現在為止,OpenStack都沒有一個原生的日誌服務專案。

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

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

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

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

(備註:圖中的數字是百分比)

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

私有雲和公有雲對雲平臺需求的差異。下圖是一個我認為比較典型的私有雲環境:

它具有幾個特點:

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

  • 平臺是分離的。這可能有幾個原因,一是管理因素,每個平臺往往由不同部門在管理和使用;二是運維因素,把平臺都放在一起,運維團隊搞不定這個單體平臺的運維,必須分而治之;三是技術因素,私有雲領域還沒出現象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架構演進行程。

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

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

      溫馨提示:

      請搜索“ICT_Architect”“掃一掃”二維碼關註公眾號,點擊原文鏈接獲取解更多電子書詳情

      求知若渴, 虛心若愚

    赞(0)

    分享創造快樂