樂視和小米基于openstack云計(jì)算方案

1、樂視云計(jì)算基于OpenStack的IaaS實(shí)踐日期：2015-09-22來源： KVM虛擬化實(shí)踐 作者：字體：大中小本文作者岳龍廣，現(xiàn)在就職于樂視云計(jì)算有限公司，負(fù)責(zé)IaaS部門的工作。從開始工作就混在開源世界里，在虛擬化方面做過CloudStack/Ovirt開發(fā)，現(xiàn)在是做以O(shè)penStack為基礎(chǔ)的樂視云平臺。所以對虛擬化情有獨(dú)鐘，也對虛擬化/云計(jì)算的未來充滿了信心。樂視網(wǎng)的所有服務(wù)是跑在樂視云上的，樂視云提供所有的底層支撐，包括IaaS/PaaS/Storage/CDN等等。為了帶給用戶更好的體驗(yàn)，樂視網(wǎng)的服務(wù)到哪，樂視云的底層服務(wù)就會跟到哪。其中虛擬化是必不可少的部分，它的快速提供、按

2、需分配、資源隔離顯得特別重要，但我們會遇到什么問題呢?今天的主要目的是分享我們在OpenStack項(xiàng)目中做的一部分工作，它們解決了內(nèi)部的一些需求，也是實(shí)際經(jīng)驗(yàn)，希望對大家有所啟發(fā)。開始之前 首先感謝肖總、浩宇、victor等朋友給予的大力支持，感謝群友、技術(shù)愛好者的圍觀。很榮幸有這次機(jī)會來與大家做這個(gè)分享。提綱：1. IaaS Architecture2. OpenStack Deploy & QOS3. Multiple Regions4. LeTV LBaaS5. DEV樂視云計(jì)算IaaS的基本架構(gòu)首先就是介紹一下樂視云計(jì)算基礎(chǔ)架構(gòu)，再介紹OpenStack 網(wǎng)絡(luò)組件的部署，Multipl

3、e Regions是什么樣子的，更方便于使用的LeTV LBaaS，最后是開發(fā)/上線流程。樂視云計(jì)算 IaaS 采用了 OpenStack 和 Ceph 的開源方案，為樂視提供了云主機(jī)、虛擬網(wǎng)絡(luò)、云硬盤和 S3 對象存儲。我們采用了 Ceph RBD 作為 統(tǒng)一存儲，OpenStack使用的Cinder，后端接的是Ceph，Glance也是共享Ceph存儲。我們同時(shí)還提供了 S3 對象存儲，用作于 CND 源站，存儲樂視網(wǎng)的視頻以及客戶需要分發(fā)的資源。S3 也是全國分布式部署，用戶可以就近上傳，再推送到北京。目前樂視云 OpenStack 規(guī)模已達(dá) 900 個(gè)物理節(jié)點(diǎn)，對象存儲的數(shù)據(jù)達(dá)到數(shù)PB

4、。Neutron Deployment & QOS我們 Havana 版本采用了 nova-network 的 FlatDHCP 類型。Icehouse 版本采用了 Neutron，再做足調(diào)研的前提下，我們對 Neutron 做了大量的減法，所用服務(wù)僅為 Neutron Server 和 OpenvSwitch Agent，控制節(jié)點(diǎn)部署 Neutron Server(with ML2 plugin)，計(jì)算節(jié)點(diǎn)部署 OpenvSwitch Agent。沒有網(wǎng)絡(luò)節(jié)點(diǎn)，因而沒有用到DHCP Agent，L3 agent 和 Metadata Agent。 物理網(wǎng)絡(luò)使用 VLAN 做隔離。由于 Reg

5、ion 數(shù)量較多，每個(gè) region 有不同的物理網(wǎng)絡(luò)(對應(yīng)ml2_conf 中的 physical_network 字段)，可以緩解 VLAN 數(shù)量的限制。私有云環(huán)境通過 Config Drive 配置虛擬機(jī)網(wǎng)卡和 metadata，Public IP 地址直接配在虛擬機(jī)網(wǎng)卡上，走物理路由器。無論是 nova-network 還是 neutron，我們都采用了穩(wěn)定可靠的網(wǎng)絡(luò)，由于不存在網(wǎng)絡(luò)節(jié)點(diǎn)的單點(diǎn)問題，因此集群在滿足私有云的需求前提下，兼顧了可靠性、穩(wěn)定性和可擴(kuò)展性。優(yōu)點(diǎn)：簡單穩(wěn)定，性能更好，這也是業(yè)務(wù)最需要的，線上業(yè)務(wù)穩(wěn)定、可用性是最重要的。缺點(diǎn)：犧牲了靈活性，和物理網(wǎng)絡(luò)的耦合度高為了防

6、止某個(gè)虛擬機(jī)負(fù)載過高而影響其它虛擬機(jī)或者宿主機(jī)，我們做了了 CPU，Network 和 Disk IO 的 QoS，其中 Cpu 的 QoS 采用 cgroup 實(shí)現(xiàn)，虛擬機(jī)網(wǎng)卡的 QoS 通過 TC 實(shí)現(xiàn)。一開始我們采用了 cgroup 限制 Disk IO，由于 ceph 采用了 Non-host-block，故 cgroup 無法限制基于 ceph 的 Disk IO, 因此我們采用了 qemu io throttling。和 cgroup 相比，qemu io throttling 不僅僅能支持 non-host-block IO，同時(shí)限速的效果也更為出色，限速后，虛擬機(jī)的 IO 不會

7、有太大抖動(dòng)。此外，如果基于 cgroup 的 Disk IO 設(shè)置過小，會導(dǎo)致虛擬機(jī)刪除失敗。原因在于 qemu 提交的 Direct IO 必須完成后才能退出，使用過小的磁盤帶寬導(dǎo)致此動(dòng)作需很長時(shí)間才能完成，導(dǎo)致 qemu 進(jìn)程不能及時(shí)響應(yīng) libvirt 發(fā)出的 SIGTERM 和 SIGKILL 信號。而如果使用 qemu io throttling，則 io 會現(xiàn)在 qemu block layer 中加入 queue，此時(shí) qemu 可以響應(yīng) libvirt 發(fā)出的信號而退出 。使用 qemu io throttling 需要需注意的是，當(dāng) Xfs 扇區(qū)大小為4k時(shí)，qemu 以 c

8、ache=none 方式啟動(dòng)失敗Multiple Regions由于樂視網(wǎng)業(yè)務(wù)的特殊性，為了讓用戶有更好的體驗(yàn)，服務(wù)會分散部署在全球。樂視網(wǎng)的視頻服務(wù)需要 CDN 的支持，對于某些 CDN 節(jié)點(diǎn)，特別是國外，需要提供云主機(jī)等基礎(chǔ)設(shè)施服務(wù)。我們在國內(nèi)外部署了有 20 多個(gè)集群，每個(gè)集群規(guī)模大小不一，其中最大的有上百個(gè)物理節(jié)點(diǎn)，這種需求也是極罕見的。這些節(jié)點(diǎn)既有 Havana 版本，又有 Icehouse 版本。每個(gè)集群均維護(hù)獨(dú)自的 Dashboard 和用戶信息，這就造成了以下四個(gè)問題：1. 用戶租戶信息不統(tǒng)一，不同集群的用戶信息不一致，對用戶使用有很大的影響2. 訪問不同的集群，用戶需要登錄不

9、同的 IP3. 運(yùn)維難度增加4. 維護(hù) H 和 I 版本的 Keystone 和 Horizon隨著集群數(shù)量的不斷增加，上述問題將顯得越發(fā)突出，于是我們采用了 Multi-Region 方案，把這些集群做了統(tǒng)一的管理。部署方面， Keystone 和 Horizon 全局唯一，其中 Keystone 部署在公網(wǎng)，從而能夠被其它服務(wù)訪問，Horizon 部署在內(nèi)網(wǎng)，從而能夠訪問其它集群。這是大概的分布圖:LeTV LBaaSLeTV LBaaS,在原生LBaaS基礎(chǔ)上做了定制化，為了區(qū)分開來，就叫做LeTV LBaaS。樂視網(wǎng)的服務(wù)需要高可用、擴(kuò)展性。Neutron LBaaS 看起來是個(gè)不錯(cuò)的

10、選擇，基本框架有了，但是還不能完全滿足業(yè)務(wù)需要。要想滿足業(yè)務(wù)需要，除了增強(qiáng)已有的接口，還有開發(fā)新的功能，比如HaProxy 冗余，本身服務(wù)健康檢查，以及與LVS整合。這是實(shí)際業(yè)務(wù)架構(gòu)，通過域名解析到LVS，LVS把流量負(fù)載到LB機(jī)器，在通過LB把流量負(fù)載到其他機(jī)器，實(shí)際提供服務(wù)的機(jī)器可以橫行擴(kuò)展，不管是虛擬機(jī)還是物理機(jī)，甚至是容器。Letv LBaaS 可以輕松滿足業(yè)務(wù)需求，優(yōu)勢如下：1. 不同業(yè)務(wù)之間的LB，互不干擾。Haproxy跑在各自的namespace里面2. Haproxy HA 冗余功能，保證服務(wù)的高可用3. 方便動(dòng)態(tài)增加機(jī)器4. 與LVS整合DevOps & Community

11、開發(fā)上線流程，基本和社區(qū)一致，是方便、可靠的：Commit-Review-Auto Testing-Package-Testing-Production最后總結(jié)一點(diǎn)建議：方案的選取1. 合適的才是最好的2. 業(yè)務(wù)需求優(yōu)先，穩(wěn)定性優(yōu)先組件的選取1. 盡量采用主流軟件，遇到問題可以快速解決版本的選取1. 成熟度與時(shí)新并重虛擬化，虛擬計(jì)算，虛擬網(wǎng)絡(luò)，虛擬存儲，我們大多會第一個(gè)想到OpenStack，或者由OpenStack帶來的這些功能。其實(shí)這些技術(shù)是可以獨(dú)立的，可以完美用到其他方面。讓所有的業(yè)務(wù)都跑在虛擬網(wǎng)絡(luò)里，為他們提供虛擬資源，并且可以輕而易舉的控制調(diào)整它們，方便管理整個(gè)數(shù)據(jù)中心，希望我們以后

12、可以探討更大的話題。Q&A1.為什么沒有使用swift?答： switft 我不熟悉，但是ceph 數(shù)據(jù)分布，性能方面都很不錯(cuò)，crush算法是它的亮點(diǎn)。2.可否介紹下你們的網(wǎng)絡(luò)架構(gòu) ，以及你們目前架構(gòu)下對網(wǎng)絡(luò)的要求答：總體的架構(gòu)是標(biāo)準(zhǔn)的neutron架構(gòu)，但是我們沒有部署網(wǎng)絡(luò)節(jié)點(diǎn)，直接使用物理路由器，這適合穩(wěn)定性高的場景。3.監(jiān)控咱們這邊是怎么做的，是用社區(qū)原生的Celimeter還是自己的監(jiān)控系統(tǒng)答：是的ceilometer，做過優(yōu)化，以及換成influxdb，包括對floatingIP的流量監(jiān)控。4.iaas層是否提供了nas接口，視頻轉(zhuǎn)碼，合成等業(yè)務(wù)軟件訪問存儲是通過S3 接口還是其他

13、接口呢;答：沒有NAS接口。視頻提供了S3和HTTP接口。5.選Haproxy有什么優(yōu)勢嗎?答：HaProxy 是專注于負(fù)載均衡的功能，提供的算法比較豐富，并發(fā)性也更好。6.你提到有的有集群上百個(gè)物理節(jié)點(diǎn)，部署這些物理節(jié)點(diǎn)時(shí)候，采用什么方法的?答：參照問題2。7.集群把公網(wǎng)線和心跳線用反了有什么后鍋，我感覺誰當(dāng)心跳誰當(dāng)公網(wǎng)，沒什么大不了，求解答：你說的心跳線是指什么? 公網(wǎng)是收費(fèi)的，大家不希望浪費(fèi)購買的帶寬，所有不穩(wěn)定的因素多。 內(nèi)網(wǎng)做心跳更好，心跳實(shí)時(shí)性要求高。8.交換機(jī)上的VLAN全手動(dòng)配置?交換機(jī)也手動(dòng)配置與虛擬機(jī)TC相對應(yīng)的QoS?答：是的，這個(gè)地方的QOS 主要是限速。9.高可用如何

14、保證的答：DNS負(fù)載均衡 和 LVS 高可用，共同保證總的高可用。10.那db性能怎么解決?答：一般沒問題，如果ceilometer 采樣頻繁，vm多的話，撐不住。我們現(xiàn)在是influxdb，已經(jīng)對采樣頻率和采樣的內(nèi)容進(jìn)行裁剪。11.對于些開發(fā)能力小的公司來說，使用上openstack不?openstack在虛擬機(jī)的基礎(chǔ)上做了資源管理，目的是充分利用資源吧?cpu方面的分配很好理解，IO能調(diào)配不?有一些場景是，部分機(jī)器io很閑，部分IO很忙，可以調(diào)整利充分用上?樂視的定制版在這方面有改進(jìn)呢?答：如果沒有太多需求，可以用virt-manager,直接管理。 openstack 還是比較復(fù)雜的。但

15、是虛擬化可以大量節(jié)省成本io就是限制讀寫磁盤的速率iops 或者帶寬 ，qemu 自身可以限制。12.公網(wǎng)絡(luò)這塊，這接把pub ip配置到容器，那平臺的防火墻策略在哪一層做限制?答：外層防火墻，一般是3，4層. 是否控制 7層，我不能確定。13.二次開發(fā)主要是改了哪些地方答：社區(qū)有我們提交的代碼。14.底層操作系統(tǒng)是啥?rehl6,7? or ubuntu?答：centos6.5。15.上線往各個(gè)節(jié)點(diǎn)推送文件，是用什么推的呢答：是puppet。16.LVS是什么?會有單點(diǎn)問題嗎?答：LVS 是linux virtual server, 沒有單點(diǎn)故障，參見問題9。17.會有一個(gè)業(yè)務(wù)幾個(gè)regio

16、n都有vm，需要互通嗎?答：部署在幾個(gè)region 是為了高可用性。 大家都會訪問同一個(gè)數(shù)據(jù)庫。18.請問平均一個(gè)節(jié)點(diǎn)多少虛機(jī)?答：為了保證業(yè)務(wù)，我們的配比 比較低。沒有超過1：10. 主要看業(yè)務(wù)和重要程度。19.每次版本更新需要多長時(shí)間，什么范圍內(nèi)更新呢?答：我們現(xiàn)在是長期維護(hù)一個(gè)穩(wěn)定版本。20.在問個(gè)成本問題，是用的整理柜服務(wù)器還是定制的服務(wù)器，一個(gè)機(jī)柜裝幾臺?答：不好意思，這個(gè)問題，我回答不了你，抱歉。21.華為分布式存儲要求各個(gè)機(jī)器硬盤配置一樣，ceph有這個(gè)要求嗎?答：沒有強(qiáng)制要求，ceph 可以設(shè)置機(jī)器的權(quán)重。22.keystone，horizon全局唯一，是放在一個(gè)region里

17、面還是怎么做冗余的?答：主要做好數(shù)據(jù)庫冗余就好，前端部署LB，提供 高可用和并發(fā)。23.想問下硬件資源cpu,mem,storage的超配比，是怎么調(diào)配的答：這個(gè)要根據(jù)自己的策略來定，看你的flavor，超配等。24.請問是否有對云主機(jī)安裝agent用做監(jiān)控來收集信息答：一般不需要，這個(gè)地方只是為了取內(nèi)存數(shù)據(jù)。25. ceph穩(wěn)定性如何?性能和san或者nas做過對比測試嗎?答：和本地做過對比， san 和nas 品種很多，看對IO的要求，業(yè)務(wù)要求，ceph性能和穩(wěn)定性都不錯(cuò)。小米OpenStack項(xiàng)目概況小米目前內(nèi)部建設(shè)的是高可用的私有云平臺，為全公司提供統(tǒng)一的云服務(wù)平臺。提供彈性的資源分配

18、和部署方式，同時(shí)提高資源的分配和管理效率。減少服務(wù)資源的交付周期。為此小米定了四大目標(biāo)： 穩(wěn)定第一：支撐公司多條產(chǎn)品線業(yè)務(wù)，力求穩(wěn)定 性能優(yōu)化：盡快可能的降低虛擬機(jī)的資源消耗，保證虛擬機(jī)的性能 內(nèi)網(wǎng)互通：虛擬機(jī)需要和公司其他主機(jī)互聯(lián)互通。對其他主機(jī)透明 業(yè)務(wù)定制：OpenStack需要和公司其他系統(tǒng)互通（監(jiān)控和主機(jī)信息）小米基于這四點(diǎn)做了私有云平臺，有著數(shù)千臺VM的OpenStack集群，穩(wěn)定服務(wù)公司線上線下業(yè)務(wù)一年多時(shí)間，數(shù)據(jù)說明如下： 可用度達(dá)到99.99%。運(yùn)行16個(gè)月，2次故障，分別是GlusterFS和OpenvSwitch引發(fā)的問題：1.GlusterFS的bug有可能導(dǎo)致文件系統(tǒng)

19、被置為Readonly，據(jù)說bug目前已經(jīng)修復(fù)；2.在廣播風(fēng)暴的情況下，OpenvSwith由于起軟件性能的問題，最有可能被打死，這個(gè)問題是所有的軟網(wǎng)橋（包括VMware）都存在的問題； 目前使用率：平均40%（物理機(jī)利用率），1虛12； 覆蓋度：小米所有產(chǎn)品線； 業(yè)務(wù)類型：開發(fā)，測試，線上（線下70%）?，F(xiàn)在整個(gè)平臺上運(yùn)行在四個(gè)機(jī)房，有2000+VM，4500+物理機(jī)內(nèi)核（E5-2640）；機(jī)器的配置主要為：50T內(nèi)存、1200T虛擬磁盤、480T塊存儲、120T對象存儲。上圖是小米根據(jù)自己的情況定制的Dashboard的，分為動(dòng)態(tài)信息和靜態(tài)信息兩個(gè)部分，靜態(tài)信息顯示的是資源的分配情況，動(dòng)態(tài)

20、信息顯示的是目前資源的使用情況。上圖是OpenStack物理主機(jī)的使用情況，機(jī)器是負(fù)載明顯看出是分層的，因?yàn)槭且慌慌系臋C(jī)器，后面機(jī)器由于虛擬機(jī)的使用還沒有分配滿，所以CPU LOAD會低一些。上圖是虛擬機(jī)的負(fù)載情況，可以看出，有些虛擬機(jī)的負(fù)載程周期性變化，可能是跑的和流量相關(guān)的一些線上業(yè)務(wù)；而有些虛擬機(jī)的CPU卻一直持續(xù)在500%左右，可能是虛擬機(jī)里面跑了高負(fù)載的離線計(jì)算業(yè)務(wù)。小米OpenStack探索之路機(jī)器選型在進(jìn)行機(jī)器選擇時(shí)，可選的類型并不多，一般是在公司內(nèi)部已有的套餐類型中選擇，然后稍加定制，主要的要求實(shí)現(xiàn)服務(wù)器性能的均衡，而且性能比較好的主機(jī)類型。機(jī)器配置詳細(xì)參數(shù)為：計(jì)算節(jié)點(diǎn):

21、DELL _R720 CPU： E5-2640v2*2(32核) MEM：16G*24 磁盤：2*600G SAS（Raid1) + 6*4T（Raid5） SATA 網(wǎng)卡: 1G * 2 + 10G*2 (Intel 82599EB 10-Gigabit SFI/SFP+ )控制節(jié)點(diǎn): DELL_R620 CPU： E5-2630v2*2 (24核) MEM：16G*4 磁盤：2*600G SAS（Raid1) + 2*240G SSD(Raid1) 網(wǎng)卡: 1G * 2 + 10G*2 (Intel 82599EB 10-Gigabit SFI/SFP+ )其實(shí)Dell R720是Dell

22、官方推薦的虛擬機(jī)云計(jì)算主機(jī)，作為OpenStack的計(jì)算節(jié)點(diǎn)還是比較合適的。版本選擇操作系統(tǒng)操作系統(tǒng)選擇：Ubuntu vs CentOS。OpenStack最早默認(rèn)支持的操作系統(tǒng)版本是Ubuntu，后來才加入了Redhat系列操作系統(tǒng)的支持，但公司一般使用CentOS的系統(tǒng)，裝機(jī)方便，系統(tǒng)穩(wěn)定，為了穩(wěn)定性和兼容性，我們也是采用CentOS做為OpenStack的操作系統(tǒng)。采用RDO的方式進(jìn)行安裝，但是在裝的過程中也遇到一些問題。比如在三個(gè)月之前采用RDO部署了一套系統(tǒng)，在三個(gè)月以后我們再需RDO部署的時(shí)候，RDO源上的版本就更新了，有可能導(dǎo)致老版本和新版本不兼容，由于OpenStack版本之

23、間的測試不是特別完備，盡管是大版本相同但是小版本有差異，都有可能導(dǎo)致不兼容，但也有解決的方法：把yum源down下來，即解決了版本問題，同時(shí)也能加快軟件安裝下載的速度。采用RDO安裝還有另外一個(gè)問題，就是在安裝完成以后，不能手動(dòng)更改系統(tǒng)配置的路徑，如數(shù)據(jù)庫路徑或者鏡像存儲路徑，如果一定要改，須連packstack中的Puppet配置路徑一起改。否則在下次啟動(dòng)RDO安裝時(shí)，他會再次將路徑再改成默認(rèn)配置，這個(gè)將導(dǎo)致不可預(yù)知的錯(cuò)誤。如果此時(shí)已經(jīng)跑了服務(wù)，那很有可能會影響的服務(wù)?？偟膩碚f，RDO的優(yōu)點(diǎn)是簡單快速部署，支持多種網(wǎng)絡(luò)結(jié)構(gòu)，缺點(diǎn)也明顯，添加計(jì)算節(jié)點(diǎn)是個(gè)坑，存在各種兼容性問題（packstac

24、k版本、qpid版本、libvirt版本），而解決的辦法就是建立自己的源，手動(dòng)添加計(jì)算節(jié)點(diǎn)。網(wǎng)絡(luò)組件可選擇有Neutron 和 Nova-network。我們選擇的是Neutron，也是跟著大趨勢走。網(wǎng)絡(luò)模型可選擇FLAT、GRE和VLAN。我們選擇了VLAN，因?yàn)楣粳F(xiàn)有網(wǎng)絡(luò)模型也是采用VLAN模型，和OpenStack原生的網(wǎng)絡(luò)模型相比，我們的主要改進(jìn)點(diǎn)是停用了L3 Agent，無單獨(dú)的網(wǎng)絡(luò)節(jié)點(diǎn)，讓虛擬機(jī)網(wǎng)絡(luò)通過Trunk直接和物理路由器相連，因此虛擬機(jī)網(wǎng)絡(luò)比較高效和穩(wěn)定。與此同時(shí)，OpenStack工程師大部分是做開發(fā)和運(yùn)維的，網(wǎng)絡(luò)管理不是他們所擅長的，所以把網(wǎng)絡(luò)節(jié)點(diǎn)去掉由交換機(jī)進(jìn)行管理

25、，全部交由網(wǎng)絡(luò)工程師去做，他們更專業(yè)。同時(shí)，若采用一個(gè)物理的主機(jī)作為一個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)，無論是性能上還是可操作性上，都不如成熟的交換機(jī)。Neutron的穩(wěn)定性確實(shí)不高，經(jīng)常斷掉，導(dǎo)致OpenVswtich無法配置網(wǎng)絡(luò)策略。塊存儲塊存儲的組件選擇有兩個(gè)，一個(gè)是Ceph，另外一個(gè)是GlusterFS。我們對Ceph和GlusterFS做了測試，在四臺機(jī)器上都部署了Ceph和GlusterFS，Ceph和GlusterFS在每臺機(jī)器上各占一塊磁盤，2副本策略，機(jī)器是單網(wǎng)卡，測試結(jié)果請看下圖。從上圖IOSP測試對比中，可以看出在塊比較小的時(shí)候，Ceph的IOPS性能非常高，在塊大小為4KB的時(shí)候，甚至高出G

26、lusterFS 40%左右，但是塊大小大于1MB的時(shí)候，Ceph的性能就不如GlusterFS了，我們推動(dòng)是Ceph和GlusterFS不同的副本同步策略造成的。GlusterFS采用Client直接寫入的策略，即每次寫入以后，節(jié)點(diǎn)之間不需要再同步；而Ceph采用的鏈?zhǔn)綄懭耄碈lient先寫入到一個(gè)節(jié)點(diǎn)上，然后節(jié)點(diǎn)之間再同步，因此會消耗一定的帶寬，當(dāng)沒有專門的同步網(wǎng)絡(luò)的時(shí)候，同步所使用的網(wǎng)絡(luò)帶寬可能會影響到Ceph的寫入性能。因此，寫入方式的差異剛好能夠解釋GlusterFS在大塊寫入的時(shí)候會比Ceph性能好。上圖是對Ceph和GlusterFS進(jìn)行4KB大小塊的連續(xù)測試，我們會發(fā)現(xiàn)Cep

27、h的整體性能會比GlusterFS高，但是他呈現(xiàn)出性能波動(dòng)現(xiàn)象，而GlusterFS卻一直比較穩(wěn)定，這也從一個(gè)層面上說明了Ceph這種鏈?zhǔn)綄懭氲臋C(jī)制對連續(xù)測試可能會產(chǎn)生波動(dòng)性的結(jié)果。總的來說，兩者各有千秋，存儲沒有完美的方案，Ceph逐漸成熟，在小塊寫入的時(shí)候Ceph性能比較好，但是大塊寫入?yún)s不如不如GlusterFS，同時(shí)Ceph的性能具有波動(dòng)性。但是，GlusterFS在實(shí)際使用中可以導(dǎo)致虛擬機(jī)的文件系統(tǒng)被置為Readonly（據(jù)說此Bug已經(jīng)被修復(fù)），需要慎重考慮和測試。不管是Ceph，還是GlusterFS作為虛擬機(jī)的共享存儲，都能夠提供毫秒級別的實(shí)時(shí)遷移，對虛擬機(jī)的負(fù)載均衡、主機(jī)維護(hù)

28、非常有用；同時(shí)多副本的技術(shù)保證用戶數(shù)據(jù)的安全性，將數(shù)據(jù)丟失的風(fēng)險(xiǎn)降低最低。對象存儲所用組件是Swift，架構(gòu)請參見上圖，Swift可以說是OpenStack最古老最成熟的一個(gè)組件，良好的設(shè)計(jì)思想，完全對稱的部署結(jié)構(gòu)，無單點(diǎn)的系統(tǒng)架構(gòu)?？v容有很多好處，但是在用Swift的時(shí)候，有一個(gè)慘痛的教訓(xùn)，Swift作為存儲服務(wù)器沒有丟失過數(shù)據(jù)，但是swift扛壓能力非常小，曾使用Swift做為CDN的源服務(wù)器，流量稍一上來，Swift的服務(wù)器就被打死了，當(dāng)時(shí)觀測流量大約10Mb左右，觀察Swfit資源消耗情況，在完全沒有壓力的情況下，Swift自動(dòng)的組件性能消耗會占一個(gè)核。私有云架構(gòu)上圖所描述的是小米的O

29、penStack架構(gòu)的使用，目前只有兩種節(jié)點(diǎn)，一種是計(jì)算節(jié)點(diǎn)，另一種是控制節(jié)點(diǎn)，但沒有網(wǎng)絡(luò)節(jié)點(diǎn)，所以網(wǎng)絡(luò)不會存在單點(diǎn)，任何一個(gè)計(jì)算節(jié)點(diǎn)宕機(jī)，只會影響其上面承載的虛擬機(jī)，不會影響其他節(jié)點(diǎn)，如果是一個(gè)可以預(yù)知的宕機(jī)，你甚至可以先將其上的虛擬機(jī)遷移到其他機(jī)器，這樣就可以將對服務(wù)的影響降到最低。另外，控制節(jié)點(diǎn)是主備模式，并且采用冷備的方式，但是數(shù)據(jù)庫保持實(shí)時(shí)同步。因?yàn)檫@種私有云的架構(gòu)對控制節(jié)點(diǎn)的依賴非常小，控制節(jié)點(diǎn)宕機(jī)，在不重啟計(jì)算節(jié)點(diǎn)的OpenVswitch-Aagent的情況下，幾乎不會影響虛擬機(jī)的正常運(yùn)行。在網(wǎng)絡(luò)的架構(gòu)上，我們有三種網(wǎng)絡(luò)：虛擬機(jī)網(wǎng)絡(luò)、存儲網(wǎng)絡(luò)和管理網(wǎng)絡(luò)。虛擬機(jī)網(wǎng)絡(luò)通過網(wǎng)橋，采用T

30、runk模式，直接連接到交換機(jī)，具有較好的性能和極高的穩(wěn)定性。管理網(wǎng)絡(luò)是OpenStack各個(gè)組件通信的網(wǎng)絡(luò)，包括鏡像分發(fā)，虛擬機(jī)遷移等都是走這個(gè)網(wǎng)絡(luò)。存儲網(wǎng)絡(luò)是虛擬機(jī)訪問共享存儲Ceph的網(wǎng)絡(luò)。上圖是小米私有云的網(wǎng)絡(luò)詳細(xì)架構(gòu)圖，基于L3-Agent的穩(wěn)定性和性能，我們停用了L3-Agent，虛擬機(jī)首先連接到br-int,，br-int連接到br-em3上，通過Trunk就可以達(dá)到外部網(wǎng)絡(luò)，這樣的架構(gòu)解決了兩個(gè)問題：第一，能夠保證網(wǎng)絡(luò)的性能和穩(wěn)定性，第二，能實(shí)現(xiàn)和內(nèi)網(wǎng)其他機(jī)器無縫互通，性能測試在使用虛擬機(jī)時(shí)候，很多人抱著一個(gè)懷疑的態(tài)度，他們會擔(dān)心虛擬機(jī)的性能是否夠用，我們對虛擬機(jī)的性能做了如下

31、測試：測試1：整體性能測試UnixBench是一個(gè)測試系統(tǒng)整體系能的軟件，測試中我們分別對比了AWS, MiStack,3U8j機(jī)器，從測試結(jié)構(gòu)看，同樣是虛擬機(jī)，MiStack的機(jī)器會比AWS相同的機(jī)型性能好很多，主要原因是AWS為了保障每個(gè)虛擬機(jī)的服務(wù)質(zhì)量，對虛擬機(jī)的資源占用情況做了嚴(yán)格的限制，因此可比性并不大，但是MiStack和3U8相比，其實(shí)相比相差不大，3U8作為一種物理機(jī)器，在性能上只比MiStack主機(jī)好1/6左右，因此，我們可以說虛擬機(jī)的性能可以相當(dāng)于相同配置的物理機(jī)行的80%以上。測試二：磁盤性能測試測試二是詞用IOzone對虛擬機(jī)的磁盤性能進(jìn)行了測試，對比的是MiStack和3U8機(jī)器，從圖上可以看出，在讀取方面，虛擬機(jī)相當(dāng)于物理機(jī)的5/6左右，在寫方面，虛擬機(jī)相當(dāng)于物理機(jī)的9/10左右。測試三：網(wǎng)絡(luò)性能測試網(wǎng)絡(luò)測試分為了兩組測試，一個(gè)測試是用HelloWorld做的，另一個(gè)是PhoInfo做的。采用PhoInfo測試時(shí)，虛擬機(jī)和物理機(jī)的差別并不大，但是在采用HelloWorld測試時(shí)，差別非常明顯，虛擬機(jī)僅相