OpenStack在小米私有云平臺的實踐

小米 OpenStack 項目概況

小米目前內部建設的是高可用的私有云平臺，為全公司提供統一的云服務平臺。提供彈性的資源分配和部署方式，同時提高資源的分配和管理效率。減少服務資源的交付周期。為此小米定了四大目標：

• 穩定第一：支撐公司多條產品線業務，力求穩定
• 性能優化：盡快可能的降低虛擬機的資源消耗，保證虛擬機的性能
• 內網互通：虛擬機需要和公司其他主機互聯互通。對其他主機透明
• 業務定制：OpenStack需要和公司其他系統互通（監控和主機信息）

小米基于這四點做了私有云平臺，有著數千臺VM的OpenStack集群，穩定服務公司線上線下業務一年多時間，數據說明如下：

• 可用度達到99.99%。運行16個月，2次故障，分別是GlusterFS和OpenvSwitch引發的問 題：1.GlusterFS的bug有可能導致文件系統被置為Readonly，據說bug目前已經修復；2.在廣播風暴的情況下，OpenvSwith 由于起軟件性能的問題，最有可能被打死，這個問題是所有的軟網橋（包括VMware）都存在的問題；
• 目前使用率：平均40%（物理機利用率），1虛12；
• 覆蓋度：小米所有產品線；
• 業務類型：開發，測試，線上（線下70%）。

現在整個平臺上運行在四個機房，有2000+VM，4500+物理機內核（E5-2640）；機器的配置主要為：50T內存、1200T虛擬磁盤、480T塊存儲、120T對象存儲。

上圖是小米根據自己的情況定制的Dashboard的，分為動態信息和靜態信息兩個部分，靜態信息顯示的是資源的分配情況，動態信息顯示的是目前資源的使用情況。

上圖是OpenStack物理主機的使用情況，機器是負載明顯看出是分層的，因為是一批一批上的機器，后面機器由于虛擬機的使用還沒有分配滿，所以CPU LOAD會低一些。

上圖是虛擬機的負載情況，可以看出，有些虛擬機的負載程周期性變化，可能是跑的和流量相關的一些線上業務；而有些虛擬機的CPU卻一直持續在500%左右，可能是虛擬機里面跑了高負載的離線計算業務。

小米 OpenStack 探索之路

機器選型

在進行機器選擇時，可選的類型并不多，一般是在公司內部已有的套餐類型中選擇，然后稍加定制，主要的要求實現服務器性能的均衡，而且性能比較好的主機類型。機器配置詳細參數為：

計算節點:  DELL _R720

• CPU： E5-2640v2*2(32核)
•   MEM：16G*24
•   磁盤：2*600G SAS（Raid1) + 6*4T（Raid5） SATA
•   網卡:  1G * 2 + 10G*2 (Intel 82599EB 10-Gigabit SFI/SFP+ )

控制節點:  DELL_R620

• CPU： E5-2630v2*2 (24核)
• MEM：16G*4
• 磁盤：2*600G SAS（Raid1) + 2*240G SSD(Raid1)
• 網卡:  1G * 2 + 10G*2 (Intel 82599EB 10-Gigabit SFI/SFP+ )

其實Dell R720是Dell官方推薦的虛擬機云計算主機，作為OpenStack的計算節點還是比較合適的。

版本選擇

操作系統

操作系統選擇：Ubuntu vs CentOS。

OpenStack最早默認支持的操作系統版本是Ubuntu，后來才加入了Redhat系列操作系統的支持，但公司一般使用CentOS的系 統，裝機方便，系統穩定，為了穩定性和兼容性，我們也是采用CentOS做為OpenStack的操作系統。采用RDO的方式進行安裝，但是在裝的過程中 也遇到一些問題。比如在三個月之前采用RDO部署了一套系統，在三個月以后我們再需RDO部署的時候，RDO源上的版本就更新了，有可能導致老版本和新版 本不兼容，由于OpenStack版本之間的測試不是特別完備，盡管是大版本相同但是小版本有差異，都有可能導致不兼容，但也有解決的方法：把yum源 down下來，即解決了版本問題，同時也能加快軟件安裝下載的速度。

采用RDO安裝還有另外一個問題，就是在安裝完成以后，不能手動更改系統配置的路徑，如數據庫路徑或者鏡像存儲路徑，如果一定要改，須連 packstack中的Puppet配置路徑一起改。否則在下次啟動RDO安裝時，他會再次將路徑再改成默認配置，這個將導致不可預知的錯誤。如果此時已 經跑了服務，那很有可能會影響的服務。

總的來說，RDO的優點是簡單快速部署，支持多種網絡結構，缺點也明顯，添加計算節點是個坑，存在各種兼容性問題（packstack版本、qpid版本、libvirt版本），而解決的辦法就是建立自己的源，手動添加計算節點。

網絡

組件可選擇有Neutron 和 Nova-network。

我們選擇的是Neutron，也是跟著大趨勢走。網絡模型可選擇FLAT、GRE和VLAN。我們選擇了VLAN，因為公司現有網絡模型也是采用 VLAN模型，和OpenStack原生的網絡模型相比，我們的主要改進點是停用了L3 Agent，無單獨的網絡節點，讓虛擬機網絡通過Trunk直接和物理路由器相連，因此虛擬機網絡比較高效和穩定。與此同時，OpenStack工程師大 部分是做開發和運維的，網絡管理不是他們所擅長的，所以把網絡節點去掉由交換機進行管理，全部交由網絡工程師去做，他們更專業。同時，若采用一個物理的主 機作為一個網絡節點，無論是性能上還是可操作性上，都不如成熟的交換機。Neutron的穩定性確實不高，經常斷掉，導致OpenVswtich無法配置 網絡策略。

塊存儲

塊存儲的組件選擇有兩個，一個是Ceph，另外一個是GlusterFS。我們對Ceph和GlusterFS做了測試，在四臺機器上都部署了 Ceph和GlusterFS，Ceph和GlusterFS在每臺機器上各占一塊磁盤，2副本策略，機器是單網卡，測試結果請看下圖。

從上圖IOSP測試對比中，可以看出在塊比較小的時候，Ceph的IOPS性能非常高，在塊大小為4KB的時候，甚至高出GlusterFS 40%左右，但是塊大小大于1MB的時候，Ceph的性能就不如GlusterFS了，我們推動是Ceph和GlusterFS不同的副本同步策略造成 的。GlusterFS采用Client直接寫入的策略，即每次寫入以后，節點之間不需要再同步；而Ceph采用的鏈式寫入，即Client先寫入到一個 節點上，然后節點之間再同步，因此會消耗一定的帶寬，當沒有專門的同步網絡的時候，同步所使用的網絡帶寬可能會影響到Ceph的寫入性能。因此，寫入方式 的差異剛好能夠解釋GlusterFS在大塊寫入的時候會比Ceph性能好。

上圖是對Ceph和GlusterFS進行4KB大小塊的連續測試，我們會發現Ceph的整體性能會比GlusterFS高，但是他呈現出性能波 動現象，而GlusterFS卻一直比較穩定，這也從一個層面上說明了Ceph這種鏈式寫入的機制對連續測試可能會產生波動性的結果。總的來說，兩者各有 千秋，存儲沒有完美的方案，Ceph逐漸成熟，在小塊寫入的時候Ceph性能比較好，但是大塊寫入卻不如不如GlusterFS，同時Ceph的性能具有 波動性。但是，GlusterFS在實際使用中可以導致虛擬機的文件系統被置為Readonly（據說此Bug已經被修復），需要慎重考慮和測試。不管是 Ceph，還是GlusterFS作為虛擬機的共享存儲，都能夠提供毫秒級別的實時遷移，對虛擬機的負載均衡、主機維護非常有用；同時多副本的技術保證用 戶數據的安全性，將數據丟失的風險降低最低。

對象存儲

所用組件是Swift，架構請參見上圖，Swift可以說是OpenStack最古老最成熟的一個組件，良好的設計思想，完全對稱的部署結構，無 單點的系統架構。縱容有很多好處，但是在用Swift的時候，有一個慘痛的教訓，Swift作為存儲服務器沒有丟失過數據，但是swift扛壓能力非常 小，曾使用Swift做為CDN的源服務器，流量稍一上來，Swift的服務器就被打死了，當時觀測流量大約10Mb左右，觀察Swfit資源消耗情況， 在完全沒有壓力的情況下，Swift自動的組件性能消耗會占一個核。

私有云架構

上圖所描述的是小米的OpenStack架構的使用，目前只有兩種節點，一種是計算節點，另一種是控制節點，但沒有網絡節點，所以網絡不會存在單 點，任何一個計算節點宕機，只會影響其上面承載的虛擬機，不會影響其他節點，如果是一個可以預知的宕機，你甚至可以先將其上的虛擬機遷移到其他機器，這樣 就可以將對服務的影響降到最低。另外，控制節點是主備模式，并且采用冷備的方式，但是數據庫保持實時同步。因為這種私有云的架構對控制節點的依賴非常小， 控制節點宕機，在不重啟計算節點的OpenVswitch-Aagent的情況下，幾乎不會影響虛擬機的正常運行。在網絡的架構上，我們有三種網絡：虛擬 機網絡、存儲網絡和管理網絡。虛擬機網絡通過網橋，采用Trunk模式，直接連接到交換機，具有較好的性能和極高的穩定性。管理網絡是OpenStack 各個組件通信的網絡，包括鏡像分發，虛擬機遷移等都是走這個網絡。存儲網絡是虛擬機訪問共享存儲Ceph的網絡。

上圖是小米私有云的網絡詳細架構圖，基于L3-Agent的穩定性和性能，我們停用了L3-Agent，虛擬機首先連接到br-int,，br- int連接到br-em3上，通過Trunk就可以達到外部網絡，這樣的架構解決了兩個問題：第一，能夠保證網絡的性能和穩定性，第二，能實現和內網其他 機器無縫互通，

性能測試

在使用虛擬機時候，很多人抱著一個懷疑的態度，他們會擔心虛擬機的性能是否夠用，我們對虛擬機的性能做了如下測試：

測試1：整體性能測試

UnixBench是一個測試系統整體系能的軟件，測試中我們分別對比了AWS, MiStack,3U8j機器，從測試結構看，同樣是虛擬機，MiStack的機器會比AWS相同的機型性能好很多，主要原因是AWS為了保障每個虛擬機 的服務質量，對虛擬機的資源占用情況做了嚴格的限制，因此可比性并不大，但是MiStack和3U8相比，其實相比相差不大，3U8作為一種物理機器，在 性能上只比MiStack主機好1/6左右，因此，我們可以說虛擬機的性能可以相當于相同配置的物理機行的80%以上。

測試二：磁盤性能測試

測試二是詞用IOzone對虛擬機的磁盤性能進行了測試，對比的是MiStack和3U8機器，從圖上可以看出，在讀取方面，虛擬機相當于物理機的5/6左右，在寫方面，虛擬機相當于物理機的9/10左右。

測試三：網絡性能測試

網絡測試分為了兩組測試，一個測試是用HelloWorld做的，另一個是PhoInfo做的。采用PhoInfo測試時，虛擬機和物理機的差別 并不大，但是在采用HelloWorld測試時，差別非常明顯，虛擬機僅相當于物理機的1/4。我們對原因進行了分析，由于HelloWorld頁面非常 小，測試過程相當于產生了很多小數據包，而PhpInfo相對頁面很大，從而產生的數據包也比較大。當在小包測試下，網絡的瓶頸在PPS上，我們反復測試 過，虛擬機軟網橋的性能只能到達5wPPS左右，此時OpenVswitch已經到了極限，而普通的物理網卡確定達到200wPPS。在打包測試時，網絡 的瓶頸在網絡帶寬上，因此，虛擬機和物理機帶寬相差不大，因此測試的結果也相差不大。

維護方案- 虛擬機遷移

為實現物理機故障維護和虛擬機的負載均衡，虛擬機通常需要遷移，主要分為兩種維護方案：實時遷移和帶磁盤的遷移。

維護方案-實時遷移

因為企業很難接受頻繁的更換，如果一兩個月換一次，那么一個月要維護一兩次，若這時全部都通知用戶把機器和業務停了，會很痛苦。虛擬機遷移可以很 好地實現“無痛遷移”。虛擬機遷移方案中的實時遷移是用一個precopy算法去迭代拷貝，在每次拷貝的過程中用內部記錄的方式記錄內存“臟”頁，當 “臟”張頁數據集小于一定程度時，比如4K的時候，停止虛擬機，把內容和寄存器遷移，由于需要停機拷貝的內容非常少，因此停機的時間非常短，不過實時遷移 一般是相同體系的CPU才能相互遷移。上圖是實時遷移，它的停機時間會很短。

維護方案-帶磁盤遷移

帶磁盤的遷移是將磁盤和內存一起拷貝到目前機器，由于磁盤數量很大，所以一般是先做快照，然后將形成的數據寫到增量中去，然后我們開始拷貝快照， 當所有的快照都已經拷貝完成以后，再開始拷貝增量文件，一般在拷貝的過程中，產生的增量文件是非常小的，因此停機時間還是可以接受的。但是 OpenStack沒有這么做，他只做了一個快照，那就是鏡像文件，其他的數據都是增量，這樣會導致OpenStack虛擬機的增量文件非常大，停機拷貝 的時間非常長，如上圖。

總的來說，實時遷移是采用precopy算法循環拷貝內存到目的機器，停機時間極短，但需要共享存儲；而帶磁盤遷移：將磁盤做快照后拷貝磁盤到目的機器，后面過程跟實時遷移一樣，整個過程時間取決于磁盤大小，停機時間稍長。（責編/周建丁）

作者簡介： 潘曉東， 畢業于華中科技大學集群與網格實驗室，從2007年開始研究虛擬化云計算技術，曾對XEN的 實時遷移算法進行改進和優化。先后在百度、小米等公司從事運維、開發工作，現為小米OpenStack項目負責人。在小米一直致力于高穩定的 OpenStack私有云建設，目前小米集群分布在多個IDC、數千臺虛擬機，服務公司幾十個產品線的線上和線下業務。