6年！我對賴以掙小錢渡日的OpenStack淌過的河...

成都-子凡 雲技術之家 雲技術之家

微訊號 cloudtech1024

功能介紹 傳播新技術，關注雲端計算、大資料、虛擬化、AI、安全、區塊鏈、物聯網、雲運維、儲存、分散式、OpenStack、SDN、Ceph等前沿領域發展，分享資訊、經驗、技術、堅持乾貨。

昨天

看了世民的《8年！我在OpenStack路上走過的坑。。。》 一文，作為從2012年從E開始使用OpenStack的相對老手，我倒是想和一篇文章，談一下這6年多的時間對於OpenStack使用的感受與認識，但因眼光與視野有限，所論之處，見仁見智，各有千秋，只為一時興致所至，花開八朵。

 

我從modem時代開始弄計算機、網路與軟體，在大家無法想像的時點，1991年，當3+/Novell網路興起時，已開始使用TCP/IP, 對這種無中心節點的通訊方式深感好奇；1993年底就使用Frame Relay（幀中繼）方式配合當時正在建設之中的中國第一個資料通訊局（上海）以加拿大新橋（new bridge）及北電裝置為基礎通過網橋及中央核心路由器完成了上海本地200家證卷公司與上海證卷交易所之間的網路互通互聯，後又在深圳通過背對背基帶64K Modem 自建微波+專線的DDN線路完成了深圳本地200家左右證卷公司與深交所間的網路聯連線，......

 

我的一些從業背景

2012年2月我離開外企後想弄自己的東西，不再想給假詳鬼子打工，不再想代理其他人的東西從貿易中掙錢，於是一個好的機會，在2012年5月我發現了OpenStack，並耐著性子努力在2012年8月開始建設中國第一個使用OpenStack建設的200臺伺服器的小型公有云系統（包含基於OpenStack API的運營門戶軟體開發）-成都艾普寬頻雲系統，並於2013年3月開始公測。當我發出同時建立100臺windows伺服器、100臺linux伺服器而系統表現良好後，高興得不得了；只可惜後期因為中國通訊行業中的運動員與裁判員集於一身的特點，這個雲系統因缺乏IP地址等資源而無法持續運營下去，在2014年底左右不得不關閉。後來在四川本地又實施了接近10餘個小的OpenStack工程, 也獲得了許多實踐經驗，而本地大工程都是大公司拿走了，一直沒有機會再弄一個大一點的工程。

 

話題一：OpenStack的設計和實施所需的基礎

我想說出我的第一個觀點：OpenStack系統的設計與實施者需要具備較深厚的技術與工程經驗積累，雖然每個縱向技術領域不 一定極為深入，但寬度要足夠。

 

早期我參與國內OpenStack技術群觀察許多人提出的問題時，就發現了一個現象：許多OpenStack系統的設計與實施者出身為軟體人員，雖然容易理解OpenStack的程式碼，但對傳統的系統整合工程經驗不足，導致投產後的OpenStack系統問題較多。網上的許文章都充滿了對OpenStack“坑”的描述，一些“坑”確是OpenStack程式碼本身Bug所致，但另一些則來源於對一些基礎知識的缺乏所至，比如對Linux系統本身、KVM本身等等不夠熟悉的原因。

 

雖然可以參考網上各個安裝指導的方法裝起一套OpenStack系統，但如果沒有這些基礎，後期根本沒有能力運維，說到底OpenStack只是一套資源排程管理軟體系統，它是構建在伺服器、作業系統、虛擬化、網路、存貯、冗餘、容錯、資料庫、訊息隊例、監控........等等各縱向知識之上的，沒有這些紮實的基礎，很多人可以搭出一個可以執行的OpenStack系統，但必然會碰到各種“坑”，就是說，大部分“坑”源自於我們對雲平臺本身涉及到的方方面面基礎知識的不足所致，與OpenStack無關。

 

《OpenStack部署實踐》第一、二版出版後，一些讀者來郵件索要電子檔，希望能夠容易複製其中的命令或指令碼程式碼便於安裝時不用再敲一次，我都沒有給，直至出版社本身提供電子檔。究其原因是，如果你喜歡或真打算弄明白OpenStack,那麼最好還是把所涉及的基礎知識都打好了，否則只能是玩玩或搭一個實驗環境，而沒有能力處理生產環境。

 

話題二：OpenStack的三種應用模式

第二個我想指出的是，OpenStack的應用模式問題。

看起來很簡單的一個問題，但許多應用者並沒有完全理清它，我就在這裡幫助理清一下。在我的眼中，OpenStack有三種應用模式：虛擬化應用模式、私有云應用模式及公有云應用模式。

 

1.虛擬化應用模式

許多人將OpenStack的虛擬化應用模式與私有云應用模式給混淆，這也是許多使用者或同仁對OpenStack一直頗有微辭的之處。我對vmware不是很熟悉，整個過程中也沒有深入地去摸它的內部核心，但我覺得OpenStack的虛擬化應用模式應該與vmware 的基本模式相差不大。我在分析使用者應用後，在許多小系統中均採用這種部署模式，它強大而穩定。

 

對於生產環境來說，這一應用模式的核心要點有三：

虛擬機器閘道器指向交換機 Neutron 不需要L3服務，僅提供DHCP服務，DHCP可以冗餘部署； 使用Linux Bridge而不是OVS

 

去年，由HH集團投資的一家外地的雲端計算公司承建的一個成都本地雲端計算專案因為一些原因中間商找到我這裡，說那個系統不好用，磁碟IO差，而且與該公司合作關係不太好，看能不能重建。我看了一下那個系統的部署模式，是一個典型業界鼓吹的那種模式：

 

三個控制節點執行控制及網路服務（包括L3） Ceph 超融合 使用ovs 所有虛擬機器均在rbd卷中

 

我最後重建了這個系統，僅僅使用了我所說的OpenStack虛擬化應用模式，存貯部分既使用了伺服器本地磁碟也使用了卷，只是我使用了GlusterFS,因為這個系統基本上後期很難大規模擴容。

 

模式當然是一件事情，仁者見仁，智者見智。但核心的問題是，你有沒有深入地去了解這個系統上層應用是什麼樣的？這個系統上層需要執行Hadoop之類的大資料存貯及分析業務，當然還有少量的的Mysql之類，應用模式也是傳統的B/S三層架構, 應用仍在虛擬機器中執行，短期內不會封裝到docker 中。

 

如果hadoop叢集三個虛擬機器都執行在ceph rbd卷中，你想想，磁碟IO如何能好？

 

說到底，OpenStack的優勢就在於開放與靈活，一個雲系統如何設計與部署與上層業務應用型別密切相關。比如人們將ceph osd 部署到OpenStack計算節點中視為超融合，那麼如果我根據上層承載的業務應用及執行模式將cinder-volume 服務部署到計算節點中算不算超融合？如果打算用一套技術方案來適應不同的業務場景，自然到處是“坑”。

 

OpenStack的虛擬化應用模式配合商業存貯，它的穩定性與效能，可以滿足大部分企業的應用要求，具體情況具體分析，應該可以替換80%企業使用者的vmware虛擬化平臺，即企業不再需要進一步購買或擴容vmware.

 

我走到美國時，發現絕大多數美國人都在使用本國汽車，不知是否與愛國有關; 看世界盃時，也看到法國隊都穿自己國家品牌的服裝上場奮鬥。而當我看到中興被美國政府罰款4-10億美元時，就在想，這什麼事呀，我們這些天天加班加點工作的人弄了半天給美國政府繳了一堆一錢，憑哈？為什麼我們的企業還這麼樂不思蜀地每年送這麼多錢給vmware，你真的需要vmware 百分之百的功能才能滿足你的應用要求嗎還是隻是想找一個心理依靠？ 甚至我還聽說到一些大企業每年買vmware的費用上億？我們中國人就那麼...xxx....?

 

是的，OpenStack 已有的功能雖然不一定能百分之百滿足一些特定應用要求，但二次開發完成可以做到呀，而且這會省多少錢呀，就算要請專業服務團隊支援，每年要付服務費，有什麼不行？用vmware不是每年也要付許多服務費嗎？

 

OpenStack缺少vMotion等功能，但如果需要確實可以二次開發來實現它，這是其一；其二，如果你上層的應用都部署到k8s中，那麼依靠k8s的機制，通常情況下，你根本就不需要vMotion功能。

 

很多人對此仍會有不解，OpenStack的穩定性行嗎？不是有很多坑嗎？當你瞭解之後就會明白，OpenStack只是一個資源排程管理軟體，虛擬機器建立好後，它的穩定性保障是由Linux與Kvm來確保的，資料安全是由商業存貯保障的。只有你懷疑Linux及KVM虛擬化機制的穩定性如何時，你的問題才會成立。

 

之所以使用ceph,是因為你的錢不夠，如果錢夠用買一些商業存貯系統，為什麼要用ceph?

 

倒過來說，如果你拿幾十萬投資的OpenStack+Ceph與幾百萬投資Vmware+Netapp/EMC系統去比較功能、穩定性、效能等等，不是自找倒黴嗎？難道網上還能有更好的對OpenStack的評論嗎？要比，至少服務費應該收vmware費用的一半才行吧？要比，至少也應該是國產組合，如OpenStack+華為/華三/浪潮存貯模式，以長我等喜歡OpenStack等等同仁的愛國志氣。
 

2.私有云應用模式

私有云應用模式許多企業很少會用到，你看一下有多少國內使用者使用vmware 的cloud模式就知道這個比率了。而OpenStack一些評論也與此有關，因為一些企業本來簡單地使用OpenStack虛擬化模式就可以滿足要求，但一些服務商上來就給弄了一套私有云模式，使用者使用起來麻煩，大多技術服務商也陷到“坑”中。

 

所謂的私有云部署模式是指：虛擬機器提供的服務必須通過浮動IP對外提供，虛擬機器自身的固定IP僅用於內部通訊。

 

技術服務商陷到“坑”中的原因是，仍按官方文件將Neutron L3服務執行在獨立的網路節點中或更簡單地像我看到的北京那家公司那樣，直接將L3服務放到了三臺伺服器中處理（這樣可以節省控制節點的伺服器數量）。這一模式也是Mirantis 的軟體部署模式。

 

這種模式真跑起來時，當整個流量壓力大、同時有效能要求時，問題一堆，而且運維起來極為麻煩。它的原因是，基於伺服器Linux 作業系統執行的Neutron L3服務一是程式碼時間短、成熟度不夠高；二是高效能、高壓力下基於伺服器內執行的L3類軟體穩定性遠遠無法與傳統的交換機與路由器相較。

 

解決這個問題唯一的方法是：將Neutron L3功能轉移到傳統路由器/交換機中執行，且通過路由器/交換機本身的叢集能力提供網路服務冗餘。這一解決方案我已在2017年北京OpenStack大會上做過演講，我這裡就賣個關子，不再說解決方案了，而且以前多次OpenStack meetup時也提到了此點。

 

當然，如果暫時這方面的技術問題無解，一些技術商仍可以考慮使用nova-network直接解決l3/dhcp分散問題而不使用看起來高大上的neutron+DVR，那會帶來更多麻煩。

 

目前許多OpenStack技術服務商都沒有這個能力，也因此至使應用OpenStack系統私有云模式時碰到了許多問題，並把這些問題歸結於OpenStack自身，這是不對的，本身上冤枉了OpenStack。

 

作為技術服務商來說，這個問題不解決，最好不出去混，否則就是給使用者和自己挖“坑”。如果為了艱難的生活而必須出去混，最好使用我提到的OpenStack虛擬化模式，讓使用者與自己都放心且也免除了因為自己學藝不精的原因亂寫關於“坑”的文章，而染汙了八杆子打不著的OpenStack的名聲。

 

3.公有云模式

除了2012年弄的艾普寬頻雲系統外，根本沒機會再碰到了，所以就不再討論了。

 

話題三：關於OpenStack與Kubernetes的關係

對了，是關於OpenStack的發展與K8s的問題，就是世民文章中提到的OpenStack的發展與容器等方面的問題。

 

我們談到OSI網路協議時，都知道有七層協議；談到http協議時，知道它是封裝在TCP中；談到雲端計算時，都知道有IAAS/PAAS/SAAS三個層面。提到k8s時，我們會認為它實際上處於PAAS層面。

 

我們看到了OpenStack社群做了一堆關於K8s的工作，甚至那個基於Kuyr/Heat元件的解決方案看起來都不錯，但說實話到現在為止，我從未在實驗環境中做過關於這些元件的測試，原因是我認為生產系統根本不可能使用這麼複雜的技術，根本無法運維；同時，反過來你也可以看到k8s社群也在做一些設法接管網路與存貯等方面的工作，這很正常，各種路子如同雨後春筍一樣蓬勃發展，這樣才好。

 

但問題是，我們要有自己的主張，特別是針對生產環境應該如何處理OpenStack與K8s的問題。我的觀點以前也寫過文章表述過，記得那篇文章名字是 《OpenStack與K8s融合：醜陋但樸實無華》，核心是，通常情況下將K8s執行到OpenStack 虛擬機器中，k8s是PAAS, OpenStack是IAAS, IAAS 管理計算、網路與存貯系統，OpenStack不做PAAS方面的事，K8s也不做IAAS方面的事，各自發揮優勢互相補足。

 

docker的精華是“一次封包、隨地執行”，K8s的精華在於隨業務變化，彈性管理docker，k8s/docker 本身的優勢並不是“比OpenStack能夠更好地管理網路、更好地管理存貯”。所以如果你打算從OpenStack的外圍元件中尋找與K8s融合的最好方式之前，千萬別忘了這個基礎。

 

另外，在我看來，使用OpenStack元件管理K8s叢集也只是一個美好的願望，如同水中月那樣華而不實。當你真正建設k8s系統用於生產環境時，你就會發現，如果OpenStack一樣，你仍是要對K8s系統做許多調整，如解決iptables在大數量Service後對整體效能的影響、解決自動化服務暴露問題等等，因此就算有一個OpenStack元件能自動地部署了k8s系統，它也僅具備實驗室環境的價值，而對生產環境來說，部署好的k8s系統基本上沒有價值。

 

由OpenStack管理計算、網路及存貯，k8s執行在租戶的虛擬機器中，通過處理網路路由實現互通或隔離是一個針對企業環境較為實際的解決方案。

 

話題四：關於OpenStack核心與非核心元件

第四個問題，關於OpenStack核心和非核心元件。

OpenStack目前好象有近53個元件，而我基本上只用6個核心元件為使用者部署系統，如果你使用ceph一樣，最好只用rbd,這是它的核心；使用glusterfs最好只用檔案方式複製而不是條帶複製。即，對於開源軟體來說，最好只使用它的最核心功能，核心功能原則上是有保障的。我完全可以理解人們對其它元件的失望，而問題在於，你根本不需要使用那些東西，用了，踩了“杭”是你的問題，而不是它的問題，因為本來這些東西都不是很完善，如同我們國內99clould與華為分別做的freezer與karbor那樣，你試著按文件裝一下就明白，文件寫得非常不嚴謹，或者說不好，你又怎麼能期望其他的呢？備份嗎，難道rsync/ceph-backup 簡單地不能滿足？資料庫備份？算了，你為了備份而凍結了資料庫伺服器，業務應用就無法連續來，還是要求業務應用部署時採用叢集吧。

 

是的，以OpenStack 6個核心元件為基礎配合其它的簡單解決方案或稍複雜的二次開發完合可以滿足應用要求了，大多數情況下，不需要其它的元件，踩了“坑”是你的問題，不是OpenStack的。

 

話題五：關於OpenStack對企業的價值

第五個問題：看起來有這麼多“杭”的OpenStack對企業的價值是什麼？

如同世民文章中提到的一些疑惑那樣，如果單純地從技術角度你會困惑此點，即生瑜何生亮？用vmware不就可以完全解決問題了？只是世民還是弄OpenStack的，還是通過心虛地遠瞻前景告訴大家要用OpenStack.

 

之所以手握OpenStack面對Vmware信心不足，原因是好鋼暫未用到地方。對於企業來說，如果你為企業講解OpenStack能節省成本，企業願意試試；但如果企業認識到OpenStack能增加產能，則企業必會堅決使用。

 

我個人認為，粗看起來，企業對IT的需要求可以分為兩個階段：一是通過vmware+netapp/emc 等標準虛擬化解決方案搭建ERP/CRM核心系統解決企業內部生產製造問題；二是即將面臨的物聯網平臺問題。

 

當許多企業，特別是製造類企業，當大家認識到企業在外執行的裝置資料是資產並且通過對這些資料資產進行分析而可以進一步地提高使用者產能或優化產品設計時，企業均會考慮建設物聯網平臺，以收集企業已銷售裝置的執行資料。而由於這個業務本身的彈性較大，對虛擬機器、存貯等要求量都較大，再使用vmware及商業存貯成本與收益的對比就不成比例。這個時候，OpenStack開源、開放、靈活、低成本的價值就會被大家所認識。而且大資料業務本身叢集具備的複製能力、業務應用執行在k8s下自動冗餘處理的機制也使得在企業物聯網平臺中，vmware的vMotion那些價值顯得不重要，甚至不需要。

 

簡單地說，OpenStack用於幫助企業降低成本時，它的價值並不明顯，但若要能用於幫助企業在物聯網平臺方面創造更多收益，那麼OpenStack是當仁不二之選，意即，物聯網平臺中，根本不需要Vmware.

 

話題六：其它？

還有什麼話題？

國內OpenStack服務商的業態？我沒有資格提到這個，我無法體驗到那些拿了投資的公司在經營上的麻煩。我確實參與到系統整合類生意很多年，但如果弄OpenStack變成像在1993年賣Hub/95年賣交換機/97年賣路由器/...., 那樣只是換湯不換藥地仍做著系統整合生意，只是把Hub換成OpenStack然後再開發定製一些使用者軟體，那麼前途可危。原因是系統整合的生意規模天然地受“關係”限制，做不了很大且每年都沒命地奔波新專案才能讓公司獲得好發展，做了多少年根基仍然不穩；同時由於OpenStack開源而且基本功能可以滿足80%的企業使用者要求，依據2/8法則意味著，業界公司只有向20%大使用者提供定製化軟體服務才能得以發展，使用者群的數量限制也會對公司未來發展前景產生影響。

 

出路如何，還需要探索。

 

關於我

我？我是誰？成都-子凡（微信：bai_tang1968），不得不做OpenStack專業服務以掙點小錢渡日之人，當然要說點OpenStack好話了，否則我如何生存？