本文遵循「知識共享許可協(xié)議 CC-BY-NC-SA 4.0 International」，未經(jīng)作者書面許可仰税，不允許用于商業(yè)用途的轉(zhuǎn)載构资、分發(fā)、和演繹陨簇。

在本部分吐绵，我們探討當(dāng)傳統(tǒng)IT建設(shè)和云計(jì)算的浪潮相遇的時(shí)候，作為互聯(lián)網(wǎng)企業(yè)究竟應(yīng)該如何抉擇河绽，是順勢而為投入云計(jì)算的懷抱己单，還是堅(jiān)持基礎(chǔ)設(shè)施自建，精耕細(xì)作耙饰。其實(shí)這兩者并不矛盾纹笼，在我們的實(shí)踐過程中，一方面苟跪，在私有云建設(shè)方面持續(xù)投入廷痘，不斷提高技術(shù)、人才儲備件已，實(shí)現(xiàn)資源的最優(yōu)利用以及自動(dòng)化程度的持續(xù)提升牍疏；另一方面，從“輕資產(chǎn)”的思路出發(fā)拨齐，在公有云服務(wù)逐漸普及、單位成本持續(xù)下降的情況下昨寞，按照業(yè)務(wù)的特點(diǎn)類型挂绰，將適合的業(yè)務(wù)遷移至公有云间涵，提升業(yè)務(wù)穩(wěn)定性，減少成本支出。

在展開詳細(xì)內(nèi)容之前，我們先來一起看看傳統(tǒng)的IT建設(shè)方式是什么樣子的调榄。我們用一個(gè)應(yīng)用場景來說明：在企業(yè)內(nèi)部，或多或少地需要一些基礎(chǔ)設(shè)施資源，包括計(jì)算資源值纱、存儲資源和網(wǎng)絡(luò)資源等。傳統(tǒng)的做法是組建一個(gè)系統(tǒng)團(tuán)隊(duì)虐唠，經(jīng)過服務(wù)器選型惰聂、服務(wù)器采購、數(shù)據(jù)中心選擇搓幌、服務(wù)器上架、網(wǎng)絡(luò)建設(shè)等一系列過程溉愁，才能完成資源的交付。整個(gè)過程比較長叉钥，而且需要較多的人力。對于一個(gè)初創(chuàng)公司或者中小型企業(yè)來說枫疆，基礎(chǔ)設(shè)施資源建設(shè)是個(gè)必需但不太劃算的投入，本來公司規(guī)模小息楔、人不多，公司內(nèi)部的人員應(yīng)該更加專注于自己的業(yè)務(wù)值依，基礎(chǔ)設(shè)施資源建設(shè)不應(yīng)該耗費(fèi)公司較多的人力和物力。

和傳統(tǒng)IT建設(shè)方式不同碟案，IaaS（Infrastructure as a Service）作為一種新型的基礎(chǔ)設(shè)施資源的獲取方式產(chǎn)生了愿险，即把服務(wù)器的基礎(chǔ)資源作為一種服務(wù)形式，通過互聯(lián)網(wǎng)提供給大家租賃獲取价说。假設(shè)企業(yè)打算架設(shè)自己的服務(wù)辆亏，原來需要買一堆服務(wù)器、網(wǎng)絡(luò)帶寬等鳖目，現(xiàn)在完全可以通過IaaS服務(wù)商租賃虛擬機(jī)扮叨，而且這些虛擬機(jī)所需要的存儲資源和網(wǎng)絡(luò)資源是可以隨時(shí)按需調(diào)配的，這樣可以節(jié)省大量的人力领迈、物力彻磁。一般的IaaS廠商會比單個(gè)企業(yè)在服務(wù)器規(guī)模上更大碍沐，在資源管理方面也會更加專業(yè)，因此衷蜓，無論是服務(wù)質(zhì)量還是投入成本都比企業(yè)自建更加優(yōu)化累提。

一般來說，IaaS服務(wù)可以分為公共的IaaS和私有的IaaS恍箭。公共的IaaS又稱公有云刻恭，規(guī)模大，服務(wù)比較全面扯夭，通過租賃的方式提供給公眾使用鳍贾，像AWS、金山云交洗、阿里云和騰訊云等都是比較著名的IaaS服務(wù)提供商骑科。私有的IaaS又稱私有云，在公司內(nèi)部組建构拳，把服務(wù)器資源做成服務(wù)咆爽，提供給公司內(nèi)部各個(gè)部門使用，極大地提高了資源分配的靈活性置森，縮短了資源交付周期凫海，相比公有云來說安全可控性更高。IaaS服務(wù)既能有效地提高資源利用率漾稀，又能減少服務(wù)提供成本崭捍。由于私有云在企業(yè)內(nèi)部的建設(shè)更有價(jià)值一些殷蛇，后面我們將重點(diǎn)討論私有云的建設(shè)過程橄浓，以及在使用過程中遇到的問題和解決方法贮配。

IaaS平臺選擇

前面介紹了什么是IaaS泪勒，這里我們討論一下IaaS的形式之一——私有云的建設(shè)過程圆存。最近幾年沦辙，私有云建設(shè)受到了國內(nèi)外很多公司的關(guān)注和參與油讯，阿里、騰訊沈跨、百度等都紛紛建立起自己的私有云平臺饿凛。建立的方式主要有兩種：一種是以開源的虛擬機(jī)計(jì)算平臺為基礎(chǔ)涧窒，開發(fā)自己的云計(jì)算管理分配平臺纠吴；另一種是完全采用開源云技術(shù)方案呜象，如OpenStack等來設(shè)計(jì)自己的私有云平臺碑隆。這兩種方式各有優(yōu)缺點(diǎn)上煤，第一種方式采用自主開發(fā)劫狠，可控性好，對代碼和功能能夠完全掌控呐矾，問題追查也比較方便蜒犯，但是開發(fā)周期長，搭建速度慢玉工，很難在短時(shí)間內(nèi)實(shí)現(xiàn)一套完整的私有云平臺遵班；第二種方式采用開源云技術(shù)方案狭郑，能在短時(shí)間內(nèi)搭建起一套完整的私有云平臺愿阐，但是需要完全熟悉和掌握你所使用的那套開源軟件缨历，有一定的學(xué)習(xí)成本辛孵，隨著開源軟件越來越復(fù)雜赡磅，對平臺的掌控有時(shí)也會力不從心焚廊。具體采用哪種方式咆瘟，主要看公司的規(guī)模和對私有云人力的投入袒餐。大公司由于人力充足，對私有云定制的需求較多卧檐，對平臺的掌控性要求較高霉囚，所以完全可以自己開發(fā)佛嬉。而小公司由于僅想使用私有云來方便自己的資源管理和分配，也不需要對私有云進(jìn)行太多的定制，所以選擇開源的私有云方案是一個(gè)很不錯(cuò)的選擇湾揽。后續(xù)內(nèi)容主要探討開源私有云方案的選擇和架設(shè)過程笼吟。

OpenStack

OpenStack是一個(gè)非常流行的開源云計(jì)算平臺贷帮，以Apache許可證授權(quán)撵枢，提供計(jì)算資源锄禽、存儲資源和網(wǎng)絡(luò)資源的分配與管理，是AWS服務(wù)的一個(gè)開源解決方案磁滚。最早是由美國國家航空航天局和RackSpace聯(lián)合發(fā)起的垂攘，目前由OpenStack基金會管理和維護(hù)晒他，已經(jīng)有AT&T仪芒、Dell掂名、Intel饺蔑、RedHat等200多個(gè)公司參與該項(xiàng)目猾警。

OpenStack發(fā)展更新速度很快，從發(fā)起到現(xiàn)在崔慧，一直維持著半年一個(gè)版本的發(fā)布周期惶室，在產(chǎn)品的規(guī)劃周期里會定時(shí)舉行峰會以確定開發(fā)需求和方向皇钞。操作系統(tǒng)對OpenStack的支持也非常緊密松捉，目前Ubuntu和RedHat對OpenStack都有良好的支持隘世。OpenStack是由Python編寫的以舒，不同的功能被劃分成不同的模塊蔓钟，模塊與模塊之間采用松散耦合的方式滥沫，使用隊(duì)列進(jìn)行異步通信兰绣。OpenStack功能非常完整，社區(qū)非吵袈瘢活躍瓢阴，支持參與的廠商較多荣恐，這些都是它的優(yōu)點(diǎn)叠穆。但是缺點(diǎn)也是非常明顯的硼被，如學(xué)習(xí)成本較高和穩(wěn)定性欠佳等嚷硫。

OpenNebula

OpenNebula起源于2005年的一個(gè)研究性項(xiàng)目论巍，2008年3月發(fā)布第一版嘉汰，目前已經(jīng)發(fā)展成一個(gè)流行的開源云軟件鞋怀，得到了廣大用戶的參與支持密似。OpenNebula的目標(biāo)是將一群實(shí)體集群轉(zhuǎn)換為彈性的虛擬基礎(chǔ)設(shè)備残腌，且可動(dòng)態(tài)調(diào)適服務(wù)器工作負(fù)載的改變贫导，OpenNebula作為在服務(wù)器設(shè)備和應(yīng)用之間新的虛擬層孩灯，使得服務(wù)器的使用效率能夠極大地優(yōu)化峰档。目前OpenNebula可支持Xen和KVM讥巡，更重要的是還支持EC2管理尚卫。OpenNebula可以構(gòu)建私有云吱涉、公有云外里，同時(shí)還提供Deltacloud適配器與Amazon EC2相配合來管理混合云盅蝗。OpenNebula由于起源比較早墩莫，同時(shí)由于項(xiàng)目更加偏向于學(xué)術(shù)研究狂秦，因此OpenNebula有很多創(chuàng)新功能裂问，其中有很多已經(jīng)應(yīng)用到生產(chǎn)實(shí)踐中了堪簿。鑒于其項(xiàng)目性質(zhì)的特點(diǎn)椭更，其穩(wěn)定性方面稍差一些虑瀑，企業(yè)和社區(qū)的支持力度也較小缴川。

CloudStack

CloudStack始于Cloud.com把夸，其目標(biāo)是使服務(wù)供應(yīng)商和企業(yè)創(chuàng)建運(yùn)營能力類似于亞馬遜公司的公有云恋日、私有云岂膳。2010年谈截，Cloud.com提供了基于GPLv3的社區(qū)版本簸喂，供用戶免費(fèi)下載喻鳄，并隨后發(fā)布了兩個(gè)支持版本除呵。思杰（Citrix）公司在2011年7月收購了Cloud.com颜曾。思杰公司是OpenStack社區(qū)早期成員之一，但在2012年決定離開OpenStack社區(qū)绿语。據(jù)媒體報(bào)道，做出這一決定是因?yàn)樗冀芄菊J(rèn)為岗仑，最初由Cloud.com提供的代碼相比OpenStack更穩(wěn)定荠雕，可為用戶提供更多的功能炸卑。

CloudStack是一個(gè)開源的具有高可用性及擴(kuò)展性的云計(jì)算平臺盖文，支持管理大部分主流的Hypervisor五续，如KVM疙驾、VMware它碎、Oracle VM、Xen等傻挂。同時(shí)CloudStack是一個(gè)開源云計(jì)算解決方案踊谋，可以加速高伸縮性的公共云和私有云（IaaS）的部署殖蚕、管理睦疫、配置鞭呕。使用CloudStack作為基礎(chǔ)葫松，數(shù)據(jù)中心運(yùn)營商可以快速腋么、輕松地提供云存儲服務(wù)和彈性云計(jì)算服務(wù)珊擂。CloudStack采用Java編寫摧扇，在設(shè)計(jì)思想上更加趨向于簡單穩(wěn)定扛稽。但在使用者和社區(qū)支持度上，都比OpenStack差了不少锡搜。

IaaS開源軟件選擇

上面介紹了三種IaaS平臺耕餐，它們各有自己的優(yōu)缺點(diǎn)肠缔，如圖1所示是三者近年來的Google趨勢圖，其中藍(lán)線表示OpenStack槽华，紅線表示CloudStack猫态，黃線表示OpenNebula亲雪。從趨勢上看义辕，OpenNebula起源最早灌砖，但是關(guān)注度一直不高基显；CloudStack從2012年開始续镇，已經(jīng)超過了OpenNebula，位居第二舅桩；OpenStack從誕生之日開始擂涛，就非橙雎瑁火爆排监，目前穩(wěn)居第一舆床。

三種IaaS平臺我們已經(jīng)介紹完了嫁佳，該是做決定的時(shí)候了。對于開源軟件的選擇瓤漏，我們認(rèn)為應(yīng)該遵循以下幾個(gè)原則颊埃。

• 功能完備性：所需功能必須完整娃惯，這是選擇的前提趾浅。
• 系統(tǒng)穩(wěn)定性：由于服務(wù)對系統(tǒng)的穩(wěn)定性要求較高皿哨，任何不穩(wěn)定的軟件將會給后續(xù)維護(hù)帶來非常大的困難证膨。
• 使用廣泛性：相信大家的眼光央勒，和別人相同的選擇至少不吃虧崔步。
• 社區(qū)支持度：具備良好的社區(qū)支持度，即使出現(xiàn)問題瑞你，也很容易通過社區(qū)的力量解決希痴。

圖1 IaaS軟件對比趨勢圖

從以上幾點(diǎn)來看过牙，OpenStack是這幾個(gè)候選者中綜合指標(biāo)最好的一個(gè)寇钉，因此，采用OpenStack搭建IaaS平臺是一個(gè)較好的選擇谦秧。后續(xù)將以O(shè)penStack為基礎(chǔ)疚鲤，詳細(xì)介紹IaaS平臺的搭建過程集歇。

IaaS平臺建設(shè)

前面我們已經(jīng)介紹過選擇使用OpenStack建設(shè)IaaS平臺诲宇。在使用OpenStack建設(shè)IaaS平臺時(shí)姑蓝，首先需要明確我們的需求纺荧。我們?yōu)楣窘ㄔO(shè)IaaS平臺宙暇，主要是滿足公司內(nèi)部的服務(wù)器虛擬資源的使用，作為私有云平臺。通過對公司的私有云平臺的需求進(jìn)行收集池充，總結(jié)起來包括如下幾點(diǎn)。

• 提供彈性的缎讼、高效的計(jì)算資源池收夸，縮短機(jī)器的交付周期。
• 提高穩(wěn)定的血崭、高可用性的服務(wù)卧惜，支持公司線上和線下業(yè)務(wù)厘灼。
• 在網(wǎng)絡(luò)連接上與現(xiàn)有業(yè)務(wù)無縫銜接，在使用體驗(yàn)上與物理機(jī)無明顯差異咽瓷。
• 虛擬機(jī)生命周期有效管理设凹，虛擬機(jī)資產(chǎn)有效管理钻洒。

以上這4點(diǎn)需求，是大多數(shù)企業(yè)建設(shè)云平臺的首要需求寓免。第一點(diǎn)需求是云平臺自有的特點(diǎn)困鸥，無須特別關(guān)注艺蝴；第二點(diǎn)是提供高可用性的服務(wù)，鑒于OpenStack目前的穩(wěn)定性，提供一個(gè)企業(yè)級高可用性的服務(wù)還需要做很多事情；第三點(diǎn)主要體現(xiàn)在網(wǎng)絡(luò)方面票罐，要求私有云網(wǎng)絡(luò)和現(xiàn)有的業(yè)務(wù)網(wǎng)絡(luò)高效互通沈善，此外罩润，在性能方面不能和物理機(jī)有太大差異应媚；第四點(diǎn)主要是和現(xiàn)有業(yè)務(wù)系統(tǒng)和管理系統(tǒng)的對接，這和每個(gè)企業(yè)的資產(chǎn)管理系統(tǒng)相關(guān)翩瓜，這里不多敘述了坟桅。下面我們就針對以上需求方灾，了解整個(gè)私有云環(huán)境的建設(shè)過程痛单。

架構(gòu)設(shè)計(jì)

在私有云建設(shè)過程中挥吵，OpenStack的架構(gòu)設(shè)計(jì)是非常重要的一部分郭厌。由于OpenStack的組件相當(dāng)多扇售，搭建起來會有不同的架構(gòu)巷懈「缘考慮到之前收集的需求，高可用性是比較重要的需求鸵膏，因此需要設(shè)計(jì)成一個(gè)高可用性的架構(gòu)债查。由OpenStack提供的私有云服務(wù)速和，主要分為計(jì)算、存儲、網(wǎng)絡(luò)聚假、管理4種資源，對每一種資源我們都要評估其高可用性喷户。

計(jì)算資源主要由KVM、Xen等虛擬機(jī)提供佳吞。虛擬機(jī)技術(shù)已經(jīng)在業(yè)界使用了很多年蒲赂，屬于比較成熟的方案，穩(wěn)定性也已經(jīng)不是問題饺汹。

存儲資源分為兩種：本地磁盤和共享存儲凶硅。本地磁盤的穩(wěn)定性由硬件的穩(wěn)定性保證，一般來說鸭叙，本地磁盤如RAID等已經(jīng)能夠滿足大部分應(yīng)用的穩(wěn)定性需求杨凑。若應(yīng)用需要更高的穩(wěn)定性伪嫁，可以考慮使用共享存儲龙助。OpenStack的共享存儲主要分為GlusterFS和Ceph兩種，都能保證數(shù)據(jù)的高可用性醉鳖。GlusterFS和Ceph我們都測試過屯曹，但是由于一些原因，最后投向了Ceph的懷抱。

網(wǎng)絡(luò)資源是OpenStack私有云最重要的地方，決定了整個(gè)私有云的成敗放坏，必須選擇一種高效穩(wěn)定的模型。在OpenStack中提供了Flat/FlatDHCP、GRE谎砾、VLAN等幾種網(wǎng)絡(luò)模型妆毕。通過對比，VLAN模型是最適合企業(yè)級需求的二驰，具體原因會在后面詳述辜腺。

鑒于目前OpenStack的穩(wěn)定性還不夠高，我們無法保證在大規(guī)模應(yīng)用中纵东，不會因?yàn)镺penStack的問題導(dǎo)致整個(gè)云服務(wù)宕機(jī)示姿。那么我們必須在架構(gòu)設(shè)計(jì)上保證，OpenStack的任何服務(wù)掛掉都不會影響云服務(wù)的穩(wěn)定性缩歪。綜合以上考慮汗洒，我們的私有云架構(gòu)如圖2所示憨攒。

上面的架構(gòu)是從公司的需求出發(fā)，結(jié)合公司業(yè)務(wù)定制而成的阀参。

首先肝集，OpenStack控制節(jié)點(diǎn)故障，不會影響虛擬機(jī)的正常使用蛛壳。因?yàn)樘摂M機(jī)只是通過OpenvSwitch上網(wǎng)杏瞻，通過物理路由器直接路由出去，跟控制節(jié)點(diǎn)沒有關(guān)系衙荐，只是無法對虛擬機(jī)進(jìn)行管理操作捞挥。如若是短時(shí)間宕機(jī)，無須切換備機(jī)忧吟，等待主節(jié)點(diǎn)啟動(dòng)即可砌函。倘若主控制節(jié)點(diǎn)長時(shí)間故障，也可以啟用備控制節(jié)點(diǎn)溜族。

圖2 私有云架構(gòu)圖

其次讹俊，計(jì)算節(jié)點(diǎn)不存在單點(diǎn)，而且計(jì)算節(jié)點(diǎn)之間也不相互依賴煌抒，單個(gè)計(jì)算節(jié)點(diǎn)宕機(jī)只會影響本節(jié)點(diǎn)的虛擬機(jī)仍劈。虛擬機(jī)可以使用本地磁盤和共享云存儲相結(jié)合的方式，本地磁盤可以提高虛擬機(jī)磁盤的性能寡壮，減少網(wǎng)絡(luò)帶寬的消耗贩疙，但是有一定的故障率（取決于系統(tǒng)硬件的故障率），適合做操作系統(tǒng)等非業(yè)務(wù)數(shù)據(jù)诬像。倘若是業(yè)務(wù)數(shù)據(jù)屋群，為了提高數(shù)據(jù)的可用率闸婴，也可以通過存儲網(wǎng)絡(luò)獲取共享存儲資源坏挠。使用共享存儲的虛擬機(jī)，在宿主機(jī)宕機(jī)之時(shí)邪乍，也可以通過實(shí)時(shí)遷移或者重新掛載等方式降狠，快速恢復(fù)虛擬機(jī)的使用。

最后庇楞，虛擬機(jī)上網(wǎng)通過OpenvSwitch直接和硬件交換機(jī)等相連榜配，不需要通過L3 Agent等連接網(wǎng)絡(luò)，規(guī)避了OpenStack L3 Agent不穩(wěn)定問題吕晌，既可以無縫和現(xiàn)有業(yè)務(wù)訪問銜接蛋褥，也可以提高虛擬機(jī)網(wǎng)絡(luò)的效率和穩(wěn)定性，使虛擬機(jī)網(wǎng)絡(luò)和其他物理機(jī)網(wǎng)絡(luò)的穩(wěn)定性在同一個(gè)級別上睛驳。

網(wǎng)絡(luò)設(shè)計(jì)

基于OpenStack的私有云建設(shè)烙心，最復(fù)雜的當(dāng)屬網(wǎng)絡(luò)部分膜廊。在前面，我們提到了虛擬機(jī)網(wǎng)絡(luò)中OpenvSwitch和交換機(jī)直連淫茵，下面重點(diǎn)分析一下為什么這樣設(shè)計(jì)爪瓜。在OpenStack中，支持Flat/FlatDHCP匙瘪、GRE铆铆、VLAN等幾種模型，我們先分析一下這必種網(wǎng)絡(luò)模型丹喻。

（1）Flat/FlatDHCP

Flat和FlatDHCP基本沒有太多差異薄货，只是有無DHCP功能的區(qū)別，它們都屬于一種扁平的網(wǎng)絡(luò)模型碍论，所有的虛擬機(jī)網(wǎng)絡(luò)在一個(gè)大二層的環(huán)境當(dāng)中菲驴，不利于租戶網(wǎng)絡(luò)之間的隔離；由于共享段廣播的存在骑冗，不利于在大規(guī)模網(wǎng)絡(luò)中使用赊瞬。

（2）GRE

一種網(wǎng)絡(luò)隧道的方式，通過OpenvSwitch GRE模塊傳輸贼涩，在IP報(bào)文上添加GRE頭巧涧，重新封裝而成。不需要交換機(jī)特殊配置遥倦，就可以實(shí)現(xiàn)租戶網(wǎng)絡(luò)之間的隔離谤绳，但是GRE的性能不是太好。

（3）VLAN

通過OpenvSwitch在二層報(bào)文上打上相應(yīng)的VLAN Tag袒哥，從而實(shí)現(xiàn)租戶網(wǎng)絡(luò)隔離缩筛，性能比較好。但由于VLAN ID最多4096個(gè)堡称，所以網(wǎng)段只能限制在4096個(gè)瞎抛，而且還需要交換機(jī)做相應(yīng)配置。

Flat/FlatDHCP不能實(shí)現(xiàn)租戶網(wǎng)絡(luò)之間的隔離却紧，同時(shí)由于二層中IP地址數(shù)量的限制桐臊，不太適用于中等規(guī)模以上的私有云建設(shè)幼驶。VLAN和GRE最大的區(qū)別在于性能差別分蓖，因此我們做了一個(gè)VLAN和GRE性能的對比測試，在不同宿主機(jī)上啟動(dòng)兩個(gè)虛擬機(jī)报腔，宿主機(jī)采用萬兆網(wǎng)卡相連巫俺，CPU是Intel E5-2640认烁，測試結(jié)果如表1所示。

表1 測試結(jié)果

從上面的測試結(jié)果可以看出，GRE的性能不太好却嗡，同時(shí)會消耗大量CPU次伶，無法達(dá)到萬兆網(wǎng)卡極限；而VLAN的性能比較好稽穆，可以輕松地達(dá)到網(wǎng)卡極限冠王。在企業(yè)中，性能可能是需要極致追求的東西舌镶，因此VLAN對于多數(shù)企業(yè)的私有云來說都是一種優(yōu)選模型柱彻。

L3（Neutron L3 Agent）也是需要考慮的部分，到目前為止餐胀，OpenStack還沒有提供高可靠性的L3解決方案哟楷。雖然可以使用多網(wǎng)絡(luò)節(jié)點(diǎn)的部署模式，但是它僅是一個(gè)負(fù)載均衡方案否灾，并非一個(gè)高可用性方案卖擅，直到最近的Juno版本提供了基于Keepalived的HA解決方案，但也并非完美的解決方案墨技。我們從以下三點(diǎn)來說明L3目前存在的問題惩阶。

第一，從我們的運(yùn)營經(jīng)驗(yàn)來看扣汪，OpenStack的L3 Agent本身穩(wěn)定性不夠断楷，流量稍大就有可能達(dá)到L3的性能瓶頸，甚至有可能服務(wù)失效崭别。

第二冬筒，多網(wǎng)絡(luò)節(jié)點(diǎn)能解決負(fù)載均衡問題，但無法解決L3穩(wěn)定性問題和節(jié)點(diǎn)失效問題茅主。

第三舞痰，Juno版基于Keepalived的方案，依賴于VIP和VRRP協(xié)議诀姚，從理論上是可行的响牛，但是從我們的經(jīng)驗(yàn)來看，在現(xiàn)實(shí)的網(wǎng)絡(luò)環(huán)境中学搜，VRRP也不是完全可信的娃善，經(jīng)常出現(xiàn)主備來回切換的問題论衍。由于以上問題無法解決瑞佩，因此我們采用去L3的結(jié)構(gòu)，如圖3所示是最終的網(wǎng)絡(luò)方案圖坯台。

圖3 私有云網(wǎng)絡(luò)結(jié)構(gòu)圖

在網(wǎng)絡(luò)結(jié)構(gòu)圖中炬丸，與原生OpenStack的最大不同就是停用了L3 Agent，由物理交換設(shè)備或者路由器承擔(dān)L3的功能，在穩(wěn)定性和性能上較OpenStack軟件的L3 Agent都有很大提升稠炬，同時(shí)也不需要關(guān)注單點(diǎn)問題焕阿。如圖3所示，控制節(jié)點(diǎn)提供Neutron-Server首启、DHCP等功能暮屡，通過eth0管理計(jì)算節(jié)點(diǎn)OVS-Agent，控制OVS-Agent的VLAN ID的映射規(guī)則生成毅桃。虛擬機(jī)連接br-int褒纲，在br-int上已經(jīng)做了VLAN ID映射規(guī)則，VLAN ID轉(zhuǎn)換完成以后钥飞，出br-eth2莺掠，通過eth2的Trunk模式連接物理交換設(shè)備，和其他網(wǎng)絡(luò)相連读宙。不需要浮動(dòng)IP彻秆，就可以實(shí)現(xiàn)和其他網(wǎng)絡(luò)的互通。

存儲選型

存儲選型是OpenStack私有云建設(shè)中比較重要的一部分结闸，好的存儲選型能夠極大地提高系統(tǒng)的穩(wěn)定性和數(shù)據(jù)的可用性唇兑。一般來說，可以分為本地存儲和網(wǎng)絡(luò)存儲兩種方式桦锄。

本地存儲就是用本地磁盤作為虛擬機(jī)的存儲磁盤幔亥，操作簡單，無須任何配置察纯，是OpenStack的默認(rèn)存儲方式帕棉。在性能方面，由于直接讀取磁盤饼记，沒有經(jīng)過網(wǎng)絡(luò)等設(shè)備中轉(zhuǎn)香伴，因此性能較好，比較適合作為系統(tǒng)盤使用具则。但是即纲，由于本地存儲的數(shù)據(jù)可靠性依賴于本地硬件，所以可靠性并不高博肋，因此需要用戶自己做一些冗余性備份低斋。

網(wǎng)絡(luò)存儲是采用一些分布式文件系統(tǒng)作為存儲，通過網(wǎng)絡(luò)的訪問方式匪凡，提供給OpenStack私有云使用膊畴。分布式存儲一般是采用多副本的冗余技術(shù)，當(dāng)一個(gè)副本丟失的時(shí)候病游，系統(tǒng)會自動(dòng)檢查到唇跨，同時(shí)將副本復(fù)制到其他機(jī)器上稠通，以保證副本的數(shù)量不小于設(shè)置的副本數(shù)量。因此买猖，在數(shù)據(jù)可用性方面改橘，分布式存儲要遠(yuǎn)遠(yuǎn)好于本地存儲。在網(wǎng)絡(luò)條件較好和存儲集群規(guī)模較大的情況下玉控，分布式存儲一般能夠提供較高的存儲性能飞主。

但是，分布式存儲由于冗余較大高诺，建設(shè)成本也會較高既棺。在一些典型的云計(jì)算環(huán)境中，一般將本地存儲作為系統(tǒng)盤來提高本地磁盤的利用率懒叛，減少網(wǎng)絡(luò)帶寬的使用丸冕，而數(shù)據(jù)盤則采用分布式存儲來提供數(shù)據(jù)的高可用性。比如AWS就是這樣做的薛窥，當(dāng)系統(tǒng)宕機(jī)以后胖烛，數(shù)據(jù)盤就可以輕松地掛載在其他機(jī)器上，幾乎不影響數(shù)據(jù)的使用诅迷。

1．塊存儲

在OpenStack支持的存儲中佩番，比較常用的是Ceph和GlusterFS。GlusterFS是一個(gè)開源項(xiàng)目罢杉，后來被RedHat收購趟畏，但是仍然提供免費(fèi)版本，是一個(gè)PB級別的分布式文件系統(tǒng)滩租。GlusterFS的主要特點(diǎn)如下赋秀。

（1）高可用性

GlusterFS可以對文件進(jìn)行自動(dòng)復(fù)制，如鏡像或多次復(fù)制律想，從而確保數(shù)據(jù)總是可以訪問猎莲，甚至在硬件故障的情況下也能正常訪問。自我修復(fù)功能能夠把數(shù)據(jù)恢復(fù)到正確的狀態(tài)技即，而且修復(fù)是以增量的方式在后臺執(zhí)行著洼，幾乎不會產(chǎn)生性能負(fù)載。

（2）無元數(shù)據(jù)

GlusterFS采用彈性Hash算法來進(jìn)行數(shù)據(jù)的分布和查找而叼，摒棄了傳統(tǒng)的元數(shù)據(jù)節(jié)點(diǎn)結(jié)構(gòu)身笤，數(shù)據(jù)采用鏡像復(fù)制結(jié)構(gòu)，消除了單點(diǎn)故障和性能瓶頸葵陵，真正實(shí)現(xiàn)了并行化數(shù)據(jù)訪問液荸。

（3）訪問方式

Gluster存儲服務(wù)支持NFS、CIFS埃难、HTTP莹弊、FTP以及Gluster原生協(xié)議涤久，完全與POSIX標(biāo)準(zhǔn)兼容∥谐荆現(xiàn)有的應(yīng)用程序不需要做任何修改或使用專用API忍弛，就可以對Gluster中的數(shù)據(jù)進(jìn)行訪問，非常方便考抄。

在GlusterFS中细疚，分為分布卷（Distributed Volume）、復(fù)制卷（Replicated Volume）川梅、分片卷（Striped Volume）三種卷類型疯兼。分布卷通常用于擴(kuò)展存儲能力，不支持?jǐn)?shù)據(jù)的冗余贫途，除非底層的Brick使用RAID等外部的冗余措施吧彪。復(fù)制卷為GlusterFS提供高可用性，卷創(chuàng)建時(shí)可以指定副本的數(shù)量丢早，當(dāng)某個(gè)卷發(fā)生故障時(shí)能夠自動(dòng)同步和修復(fù)姨裸。分片卷將單個(gè)文件分成小塊（塊大小支持配置默認(rèn)為128KB），然后將小塊存儲在不同的Brick上怨酝，以提升文件的訪問性能傀缩。

在分布式存儲中，Ceph是一支后起之秀农猬，是其創(chuàng)始人Sage Weil在加州大學(xué)攻讀博士期間的研究課題赡艰。隨著云計(jì)算興起以后，OpenStack社區(qū)把Ceph作為其最核心的開源存儲方案之一斤葱，推動(dòng)了Ceph的快速發(fā)展慷垮。Ceph之所以成為OpenStack的官方存儲組件，這和其優(yōu)秀的特性和良好的性能是分不開的揍堕』恢模總地來說，Ceph是為優(yōu)秀的性能鹤啡、可靠性和可擴(kuò)展性而設(shè)計(jì)的惯驼，是一個(gè)統(tǒng)一的、分布式存儲系統(tǒng)递瑰。在Ceph中祟牲，包括OSD、MON抖部、MDS三個(gè)組件说贝，OSD負(fù)責(zé)數(shù)據(jù)的存儲和管理，MON負(fù)責(zé)數(shù)據(jù)的一致性維護(hù)慎颗，MDS負(fù)責(zé)CephFS元數(shù)據(jù)的管理乡恕。其主要特性如下言询。

（1）高可用性

Ceph采用多副本技術(shù)進(jìn)行數(shù)據(jù)的冗余，從而防止了一份數(shù)據(jù)丟失導(dǎo)致整個(gè)數(shù)據(jù)失效的問題傲宜，沒有任何單點(diǎn)运杭。Ceph MON組件實(shí)時(shí)監(jiān)控和管理著數(shù)據(jù)的冗余和一致性，以及所有故障的檢測和自動(dòng)恢復(fù)函卒×俱荆恢復(fù)不需要人工介入，在恢復(fù)期間报嵌，可以保持正常的數(shù)據(jù)訪問虱咧。

（2）分布式元數(shù)據(jù)

在Ceph中，元數(shù)據(jù)存儲是可選的锚国，只有當(dāng)使用CephFS時(shí)腕巡，才會引入元數(shù)據(jù)節(jié)點(diǎn)。Ceph的數(shù)據(jù)訪問采用CRUSH算法血筑，這和GlusterFS類似绘沉，數(shù)據(jù)的訪問通過算法就可以定位地址，真正做到無單點(diǎn)和性能瓶頸云挟。而CephFS中的元數(shù)據(jù)梆砸，采用分布式存儲，數(shù)據(jù)定位也是采用CRUSH算法园欣。

（3）多訪問方式

Ceph提供了塊設(shè)備存儲（Ceph RBD）帖世、文件系統(tǒng)存儲（CephFS）和對象存儲三種方式，為用戶提供更多的訪問方式沸枯。塊設(shè)備存儲允許用戶像使用物理裸磁盤一樣使用Ceph塊設(shè)備日矫，可提供良好的性能和不錯(cuò)的特性，比如設(shè)備快照等绑榴。CephFS提供了一種方便的掛載方式哪轿，用戶采用Ceph客戶端就可以很輕松地將其掛載，訪問較方便翔怎，但是會引入Ceph元數(shù)據(jù)節(jié)點(diǎn)窃诉。Ceph對象存儲和Swift一樣，提供了海量對象存儲空間赤套，同時(shí)擁有較好的性能飘痛。

在設(shè)計(jì)理念和產(chǎn)品特性上，Ceph和GlusterFS具有很大的相似性容握。但是作為OpenStack的存儲組件宣脉，我們到底該如何選擇？其實(shí)作為云存儲組件剔氏，GlusterFS和Ceph都有很多公司在使用塑猖。我們主要考慮使用Ceph竹祷，原因如下。

• OpenStack社區(qū)主推Ceph羊苟，作為社區(qū)的主推組件塑陵，從未來的趨勢來看，會更加有前途和生命力践险。
• Ceph提供多種存儲形式猿妈，尤其是對象存儲吹菱，是GlusterFS不支持的巍虫，而對象存儲是云計(jì)算的一個(gè)核心組件。
• Ceph在OpenStack使用中更加穩(wěn)定（我們的觀點(diǎn)）鳍刷，在作為虛擬機(jī)的磁盤使用過程中占遥，Ceph幾乎沒有出現(xiàn)過問題，而GlusterFS偶爾會出現(xiàn)網(wǎng)絡(luò)超時(shí)引起文件系統(tǒng)置為只讀的情況输瓜。

2．對象存儲

在OpenStack中瓦胎，Swift是對象存儲的核心組件，Swift是一個(gè)高可用的尤揣、完全對稱的搔啊、無單點(diǎn)的、無限擴(kuò)展的對象存儲軟件北戏。最初是由RackSpace公司開發(fā)的高可用性分布式對象存儲服務(wù)负芋，2010年加入OpenStack開源社區(qū)作為其最初的核心子項(xiàng)目之一。Swift包括以下核心服務(wù)嗜愈。

（1）Proxy Server

負(fù)責(zé)處理每個(gè)客戶端的請求旧蛾，將其均勻分散地分發(fā)到后端Storage Server上。Proxy提供了RESTful API蠕嫁，并且符合標(biāo)準(zhǔn)的HTTP協(xié)議規(guī)范锨天，這使得開發(fā)者可以快捷地構(gòu)建定制的Client與Swift交互。

（2）Storage Server

提供磁盤設(shè)備上的存儲服務(wù)剃毒。在Swift中有三類存儲服務(wù)器：Account病袄、Container和Object。其中Container服務(wù)器負(fù)責(zé)處理Object的列表赘阀，Container服務(wù)器并不知道對象存放位置益缠，只知道指定Container里存的是哪些Object。這些Object信息以SQlite數(shù)據(jù)庫文件的形式存儲纤壁。Container服務(wù)器也做一些跟蹤統(tǒng)計(jì)左刽，例如Object的總數(shù)、Container的使用情況酌媒。

（3）Consistency Server

查找并解決由數(shù)據(jù)損壞和硬件故障引起的錯(cuò)誤欠痴。它們會在后臺持續(xù)地掃描磁盤來檢測對象迄靠、Container和賬號的完整性，如果發(fā)現(xiàn)數(shù)據(jù)損壞喇辽，就會以副本拷貝的方式來修復(fù)數(shù)據(jù)掌挚。

從Swift的服務(wù)特點(diǎn)可以看出，Swift是一個(gè)分布式的菩咨、無單點(diǎn)的吠式、能夠自動(dòng)容錯(cuò)的存儲系統(tǒng)。因此抽米，Swift的特點(diǎn)可以總結(jié)如下特占。

（1）高可用性

Swift由多副本技術(shù)進(jìn)行冗余，能夠進(jìn)行自動(dòng)故障恢復(fù)和容錯(cuò)云茸，提供了極高的可用性是目。強(qiáng)一致性的容錯(cuò)方式和完全對稱的結(jié)構(gòu)，使得任何一個(gè)節(jié)點(diǎn)故障都不會影響整個(gè)系統(tǒng)的可用性标捺。

（2）可擴(kuò)展性

Swift的容量通過增加機(jī)器可線性提升懊纳。同時(shí)因?yàn)镾wift是完全對稱的結(jié)構(gòu)，擴(kuò)容只需簡單地新增機(jī)器亡容，系統(tǒng)就會自動(dòng)完成數(shù)據(jù)遷移等工作嗤疯，使各存儲節(jié)點(diǎn)重新達(dá)到平衡狀態(tài)，完全不需要人工干預(yù)闺兢。

（3）無單點(diǎn)故障

Swift的元數(shù)據(jù)存儲是完全均勻隨機(jī)分布的茂缚，并且與對象文件存儲一樣，元數(shù)據(jù)也會存儲多份列敲。在整個(gè)Swift集群中阱佛，也沒有一個(gè)角色是單點(diǎn)的，良好的結(jié)構(gòu)和設(shè)計(jì)保證了無單點(diǎn)故障存在戴而。

典型的Swift架構(gòu)如圖4所示凑术，每個(gè)節(jié)點(diǎn)采用完全相同的軟件結(jié)構(gòu)，以及完全對稱的結(jié)構(gòu)所意，機(jī)器的管理和維護(hù)非常方便淮逊，同時(shí)也不存在任何單點(diǎn)。

圖4 Swift架構(gòu)圖

盡管Swift是OpenStack最穩(wěn)定的組件之一扶踊，也是OpenStack社區(qū)推薦的對象存儲組件泄鹏，但我們在Swift使用過程中也遇到了一些問題。在使用過程中秧耗，作為存儲Swift沒有丟失過任何數(shù)據(jù)备籽，作為OpenStack的Glance后端也完全能夠勝任，但是如果作為其他目的使用，比如圖片存儲等服務(wù)车猬，只要流量稍微一上來霉猛，Swift就必然遇到性能瓶頸，反應(yīng)速度變慢珠闰，最后導(dǎo)致服務(wù)完全中斷惜浅。因此，Swift對象存儲不建議使用在流量較大的業(yè)務(wù)上伏嗜。

通過前面的介紹我們知道坛悉，Ceph和GlusterFS大體的思想是差不多的，都是沒有元數(shù)據(jù)節(jié)點(diǎn)的分布式存儲承绸，采用算法進(jìn)行數(shù)據(jù)尋址裸影，都是非常優(yōu)秀的分布式文件系統(tǒng)。我們在使用GlusterFS作為虛擬機(jī)鏡像時(shí)八酒，經(jīng)常會出現(xiàn)文件系統(tǒng)被寫保護(hù)情況空民，非常影響虛擬機(jī)的使用刃唐。后續(xù)來我們換成了Ceph羞迷，在使用過程中，并沒有出現(xiàn)明顯的問題画饥，因此推薦使用Ceph作為塊存儲衔瓮。同時(shí)，Ceph的社區(qū)非扯陡剩活躍热鞍，更新速度也非常快衔彻，相信在不久的將來薇宠，Ceph一定會變得更加穩(wěn)定和成熟。另外艰额，在對象存儲方面澄港，雖然OpenStack官方主推Swift，但是從筆者的慘痛經(jīng)驗(yàn)來看柄沮，Swift的性能問題已經(jīng)非常影響使用回梧，因此Ceph的對象存儲也是一種不錯(cuò)的選擇。

服務(wù)器選型

私有云的架構(gòu)和網(wǎng)絡(luò)模型已經(jīng)確定了祖搓，接下來我們將對硬件配置進(jìn)行描述狱意。控制節(jié)點(diǎn)需要運(yùn)行MySQL服務(wù)和RabbitMQ服務(wù)拯欧，在穩(wěn)定性上要求較高详囤。同時(shí)，Glance服務(wù)也是運(yùn)行在控制節(jié)點(diǎn)上的镐作，由于Glance需要存儲大量的鏡像文件藏姐，因此也需要較大的存儲空間蚓再。總地來說包各，控制節(jié)點(diǎn)需要穩(wěn)定的大存儲服務(wù)器摘仅。計(jì)算節(jié)點(diǎn)兼計(jì)算和本地存儲兩部分功能，計(jì)算性能和存儲性能要求服務(wù)器性能比較均衡问畅，網(wǎng)絡(luò)節(jié)點(diǎn)由硬件路由設(shè)備擔(dān)任娃属，不需要網(wǎng)絡(luò)節(jié)點(diǎn)。存儲節(jié)點(diǎn)只需能夠多掛載硬盤护姆，使用普通存儲性服務(wù)器即可矾端。下面給出我們使用的硬件配置，如表2所示卵皂，供大家參考秩铆。

表2 硬件配置

安裝部署

由于OpenStack的組件較多，安裝部署一直是OpenStack一個(gè)被詬病的問題刃泌。限于篇幅的原因凡壤，這里我們不再探討每個(gè)組件該如何安裝，只是簡單地說明各種安裝方式需要注意的問題耙替。我們嘗試過的安裝方式有三種：Fuel安裝亚侠、RDO安裝和手動(dòng)安裝。以下是這三種安裝方式的特點(diǎn)俗扇。

（1）Fuel安裝

OpenStack的一鍵部署工具硝烂，由Mirantis公司提供，提供硬件自動(dòng)發(fā)現(xiàn)機(jī)制狐援。通過簡單的Web界面操作钢坦，就可以將OpenStack連同操作系統(tǒng)一起部署完成。這是最簡單的一種部署方式啥酱。

（2）RDO安裝

RDO安裝是使用PackStack安裝部署工具爹凹，將OpenStack的RPM包安裝部署并且完成配置的一種部署方式。整個(gè)過程只需配置一個(gè)PackStack的配置文件镶殷，部署較為方便禾酱。

（3）手動(dòng)部署

使用Yum源，按照OpenStack官方部署文檔，一步一步安裝配置颤陶，安裝比較麻煩颗管，但是能夠增進(jìn)對OpenStack各組件的了解。

Fuel安裝無疑是最簡單的部署方式滓走，作為初學(xué)者使用一個(gè)快速搭建的工具是一個(gè)不錯(cuò)的選擇垦江。但是Fuel作為一個(gè)整體會連操作系統(tǒng)一起安裝，企業(yè)一般會有自己的長期使用的操作系統(tǒng)版本搅方，同時(shí)會在此版本下做大量適合自己業(yè)務(wù)的定制和優(yōu)化比吭，因此，F(xiàn)uel一般不適合已經(jīng)成熟的企業(yè)用來部署私有云姨涡，而且若對OpenStack做了定制化修改衩藤，采用Fuel也不是一個(gè)太好的選擇。

RDO部署相對Fuel來說復(fù)雜度略高涛漂，需要指定PackStack的配置文件赏表，后續(xù)的過程也是自動(dòng)化安裝。有幾個(gè)問題也是要注意的：第一匈仗，由于網(wǎng)絡(luò)的問題瓢剿，PackStack在安裝的過程中有可能失敗，需要反復(fù)重試锚沸。第二跋选，部署完成以后，盡量不要手動(dòng)修改集群配置哗蜈，因?yàn)樵黾庸?jié)點(diǎn)時(shí)，PackStack會再次檢查配置坠韩，將修改的配置覆蓋距潘，可能造成不可預(yù)知的錯(cuò)誤。第三只搁，由于依賴Yum源音比，若集群擴(kuò)容機(jī)器，前后時(shí)間相隔太長氢惋，Yum源上軟件包可能已經(jīng)更新洞翩，可能造成前后安裝的小版本不一致，這可能導(dǎo)致軟件版本不兼容問題焰望。

手動(dòng)安裝是最復(fù)雜的一種方式骚亿，但也是最可控的一種方式。對操作系統(tǒng)和軟件的依賴最小熊赖，只要在一個(gè)系統(tǒng)上正確完成一次安裝来屠，其他節(jié)點(diǎn)就可以大批量部署，效率極高。由于依賴Yum源俱笛，因此和RDO安裝有相同的問題捆姜。為了解決Yum源更新問題，我們可以在第一次部署完成以后迎膜，就將Yum源同步到自己的機(jī)器上并且做成自己的Yum源泥技，以后安裝使用自己的源即可，速度快而且不易出錯(cuò)磕仅。因此零抬，手動(dòng)安裝OpenStack是我們比較推薦的一種方式。

性能優(yōu)化

虛擬化技術(shù)已經(jīng)是一項(xiàng)非常成熟的技術(shù)宽涌，但是在使用虛擬機(jī)時(shí)平夜，很多人還是持半信半疑的態(tài)度，質(zhì)疑虛擬機(jī)的性能問題卸亮。當(dāng)然忽妒，使用虛擬機(jī)，服務(wù)器的性能會有所降低兼贸，到底會降低多少段直，我們用測試數(shù)據(jù)說話。在測試之前溶诞，我們需要對虛擬機(jī)——KVM主機(jī)進(jìn)行一系列調(diào)優(yōu)鸯檬，以便虛擬機(jī)的性能達(dá)到較好的發(fā)揮。

1．CPU調(diào)優(yōu)

CPU綁定是提升虛擬機(jī)性能比較常用的方法螺垢，通過綁定VCPU喧务，能夠減少CPU Cache的失效卤橄，從而提高虛擬機(jī)的性能驰弄。但是目前OpenStack虛擬機(jī)VCPU綁定不能自動(dòng)化，必須手動(dòng)使用virsh對虛擬機(jī)CPU綁定高氮。另外孽亲，為宿主機(jī)預(yù)留CPU資源坎穿，是一個(gè)非常不錯(cuò)的選擇。預(yù)留一定數(shù)量的CPU資源返劲，也能提高整體的計(jì)算性能玲昧，通過配置nova.conf的參數(shù)就可以做到，如下所示：

vcpu_pin_set = 4-$

為宿主機(jī)預(yù)留了4個(gè)核篮绿，保證了宿主機(jī)對虛擬機(jī)的正常調(diào)度孵延。另外，通過配置NUMA屬性搔耕，能夠顯著提升虛擬機(jī)性能隙袁，因?yàn)榻壎ㄔ谕粋€(gè)CPU上的兩個(gè)超線程核心性能低于不同CPU上的兩個(gè)超線程核心痰娱，不過這個(gè)特性只有J版本才支持。

2．內(nèi)存調(diào)優(yōu)

宿主機(jī)上的多個(gè)虛擬機(jī)會存在大量相似的內(nèi)存頁菩收，如果將這些相似的內(nèi)存頁進(jìn)行合并梨睁，就能節(jié)省大量的內(nèi)存，KVM中的KSM就是這種技術(shù)娜饵，開啟后會節(jié)省虛擬機(jī)的內(nèi)存使用坡贺，但是同時(shí)會帶來一定的CPU消耗∠湮瑁考慮到宿主機(jī)一般內(nèi)存比較寬裕遍坟，而CPU增加成本較高，建議關(guān)閉內(nèi)存合并晴股，如下所示：

echo 0 > /sys/kernel/mm/ksm/pages_shared
echo 0 > /sys/kernel/mm/ksm/pages_sharing

另外愿伴，采用Huge Page開啟也能提升一定的性能，不過目前Nova不支持电湘，只能通過修改源碼隔节，需要在Libvirt生成的配置中加入以下內(nèi)容：

<memoryBacking>
 <hugepages/>
</memoryBacking>

3．IO優(yōu)化

在磁盤方面，通過改變磁盤的調(diào)度策略提高磁盤的效率寂呛，主要是將磁盤的調(diào)度方式改為Deadline怎诫，如下所示：

echo dealine > /sys/block/<dev>/queue/scheduler

另外，使用SR_IOV網(wǎng)卡虛擬化技術(shù)可以顯著提高網(wǎng)卡性能贷痪，不過配置起來有點(diǎn)復(fù)雜幻妓，感興趣的讀者可以按照https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking自行配置。

性能測試

基本優(yōu)化工作已經(jīng)完成劫拢，下面對虛擬機(jī)性能做一個(gè)對比測試肉津，測試對比機(jī)型配置如表3所示。

表3 測試對比機(jī)型配置

為了避免虛擬機(jī)之間的競爭尚镰，影響測試結(jié)果阀圾，在物理主機(jī)上只運(yùn)行了一個(gè)虛擬機(jī)。若有多個(gè)虛擬機(jī)狗唉，虛擬機(jī)性能必然下降，此測試的主要目的是測試出KVM Hypervisor帶來的性能損耗涡真，因此單個(gè)虛擬機(jī)就可以說明問題分俯。首先，通過UnixBench測試系統(tǒng)的整體性能哆料，如圖5所示缸剪。

圖5 UnixBench性能測試結(jié)果

從測試結(jié)果可以看出，虛擬機(jī)大約相當(dāng)于物理機(jī)5/6的性能东亦。而且從參數(shù)上看杏节，物理機(jī)的CPU主頻更高唬渗。因此，KVM虛擬機(jī)能夠達(dá)到物理機(jī)接近90%的性能奋渔。

接下來镊逝，我們使用iozone對磁盤的性能進(jìn)行測試，如圖6所示嫉鲸。

圖6 磁盤性能測試結(jié)果

從磁盤的性能測試結(jié)果來看撑蒜，Reader和Re-reader的性能下降較多，下降20%左右玄渗；而Write和Re-Write性能下降較小座菠，下降10%左右。

最后藤树，我們對虛擬機(jī)的網(wǎng)絡(luò)性能進(jìn)行測試浴滴，分別采用小包和大包進(jìn)行測試，如圖7所示岁钓。

對于小包的測試升略，我們采用一個(gè)字節(jié)的文件，通過Web服務(wù)下載甜紫，最后吞吐量8Kbps左右降宅，大約是物理主機(jī)的1/4，主要是受限于虛擬機(jī)網(wǎng)卡的PPS囚霸。對于大包的測試腰根，使用一個(gè)320KB的文件，通過Web服務(wù)進(jìn)行下載拓型，虛擬機(jī)和物理機(jī)基本差不多额嘿，都能將網(wǎng)卡跑到800bps以上。

圖7 網(wǎng)絡(luò)性能測試結(jié)果

總地來說劣挫，虛擬機(jī)的性能和物理機(jī)已經(jīng)非常接近册养，CPU的性能達(dá)到物理機(jī)的90%，磁盤性能達(dá)到物理機(jī)的80%以上压固，網(wǎng)絡(luò)性能在小包處理上較差球拦。但是在現(xiàn)實(shí)應(yīng)用中，存儲小包的場景較少帐我，虛擬機(jī)已經(jīng)足夠應(yīng)付一些常規(guī)業(yè)務(wù)場景坎炼。若一定要追求較好的網(wǎng)絡(luò)性能，則可以使用網(wǎng)卡虛擬機(jī)技術(shù)（SR-IOV）拦键，相信能夠帶來非常顯著的提升谣光。

IaaS平臺運(yùn)營心得

版本升級

版本升級是開源軟件都會遇到的一個(gè)問題，OpenStack也同樣遇到此問題芬为。由于OpenStack組件很多萄金，各組件之間相互關(guān)聯(lián)蟀悦，不同版本之間的組件可能存在兼容性問題，不同版本的數(shù)據(jù)表也存在差異性氧敢，因此日戈，OpenStack的版本升級成本較高，需要慎重福稳。OpenStack版本升級一般有以下兩種原因涎拉。

• Bug修復(fù)。對于此問題的圆，首先應(yīng)考慮能否直接采取Bug修復(fù)補(bǔ)丁鼓拧，這種方法成本較小，最后才考慮版本升級越妈。
• 添加新功能季俩。此種需求，首先應(yīng)考慮新功能是否必需梅掠，有沒有其他的代替方法酌住，最后再考慮升級。

建議的升級方法如下：

在新服務(wù)器上搭建新版本控制節(jié)點(diǎn)阎抒，然后將線上控制節(jié)點(diǎn)數(shù)據(jù)庫導(dǎo)入到新控制節(jié)點(diǎn)上酪我，檢查數(shù)據(jù)庫兼容問題，兩個(gè)控制節(jié)點(diǎn)數(shù)據(jù)庫配置密碼最好保持一致且叁，使用OpenStack-status查看各組件狀態(tài)都哭，如果狀態(tài)正常，說明控件節(jié)點(diǎn)升級完成逞带。計(jì)算節(jié)點(diǎn)升級可能會升級Libvirt欺矫，有可能會導(dǎo)致虛擬機(jī)重啟，因此應(yīng)先升級一臺做測試展氓。為了安全起見穆趴，必須先通知虛擬機(jī)使用者，告知服務(wù)維護(hù)期間可能發(fā)生重啟遇汞。準(zhǔn)備工作都做好了以后未妹，升級安裝Nova和Neturon等，將控制節(jié)點(diǎn)指向新控制節(jié)點(diǎn)空入，其他節(jié)點(diǎn)都按照此操作教寂，OpenStack的升級完成。

宿主機(jī)維護(hù)

虛擬機(jī)都運(yùn)行在宿主機(jī)上执庐，OpenStack的宿主機(jī)維護(hù)也是必須面臨的一個(gè)問題。宿主機(jī)的維護(hù)一般分為可預(yù)知的維護(hù)和不可預(yù)知的故障导梆。

可預(yù)知的維護(hù)比較好處理轨淌，一般采用虛擬機(jī)遷移方式迂烁，OpenStack支持實(shí)時(shí)遷移和帶磁盤遷移。如果使用了Ceph等共享存儲的話递鹉，實(shí)時(shí)遷移是非常不錯(cuò)的選擇盟步，實(shí)時(shí)遷移的時(shí)間與內(nèi)存大小及內(nèi)存修改速度有關(guān)。一般說來躏结，虛擬機(jī)實(shí)時(shí)遷移宕機(jī)時(shí)間會在1秒以下却盘。OpenStack帶磁盤遷移需要的時(shí)間會比較長，而且需要停機(jī)媳拴。由于虛擬機(jī)的磁盤一般較大黄橘，要想將宿主機(jī)上的虛擬機(jī)全部遷出，在短時(shí)間之內(nèi)是無法做到的屈溉，因此可以挑選一些重要性較高的虛擬機(jī)做帶磁盤遷移塞关。

對于不可預(yù)知的故障，宿主機(jī)已經(jīng)停機(jī)子巾，處理就比較麻煩帆赢，如果虛擬機(jī)使用的是共享存儲，只需要修改Nova數(shù)據(jù)庫中宿主機(jī)字段线梗，然后硬重啟虛擬機(jī)椰于，虛擬機(jī)就可以恢復(fù)。如果使用的是本地磁盤仪搔，虛擬機(jī)就無法很快啟動(dòng)了瘾婿，必須等宿主機(jī)故障恢復(fù)以后，虛擬機(jī)才能啟動(dòng)僻造。如果是磁盤問題憋他，虛擬機(jī)磁盤可能就無法找回了。因此髓削，虛擬機(jī)最好要做備份竹挡。虛擬機(jī)備份也是一個(gè)比較棘手的問題，可以從兩個(gè)方面進(jìn)行處理立膛，一是由于虛擬機(jī)磁盤大揪罕，備份成本較高，不停機(jī)備份磁盤可能出現(xiàn)數(shù)據(jù)不一致性問題宝泵，直接備份虛擬機(jī)磁盤的操作成本也較高好啰，這種方法適合一些重要而且能夠短時(shí)間停機(jī)的虛擬機(jī)使用；二是采用應(yīng)用服務(wù)冗余機(jī)制儿奶，在業(yè)務(wù)層面保證有多個(gè)虛擬機(jī)提供同一服務(wù)框往。

RabbitMQ使用和監(jiān)控

在OpenStack中，大量使用消息隊(duì)列作為各組件交互的媒介闯捎，因此椰弊，消息組件的穩(wěn)定性至關(guān)重要许溅。在運(yùn)營過程中，我們經(jīng)常發(fā)現(xiàn)Nova或者Neutron連接RabbitMQ假死秉版，導(dǎo)致虛擬機(jī)無法分配贤重，或者虛擬機(jī)無法上網(wǎng)等情況。官方推薦使用RabbitMQ作為消息組件清焕，盡量對RabbitMQ做高可用性配置并蝗，但是即使做了高可用性配置以后，還是會出現(xiàn)RabbitMQ連接超時(shí)的問題秸妥，因此需要對RabbitMQ進(jìn)行監(jiān)控滚停。可以用Nagios或者Collectd等監(jiān)控工具筛峭，監(jiān)測到隊(duì)列大于某個(gè)長度就可以告警铐刘，如果能寫程序模擬隊(duì)列的生成消費(fèi)行為則更可靠。另外影晓，可以對Nova-Compute和Neutron-OpenvSwitch-Agent的日志進(jìn)行監(jiān)控镰吵，一旦出現(xiàn)連接超時(shí)而且沒有恢復(fù)就可以斷定組件已經(jīng)假死，需要重啟才能恢復(fù)挂签。為了減少消息隊(duì)列的壓力疤祭，盡量不要使用Ceilometer組件，若Ceilometer是必需組件饵婆，Ceilometer盡量使用單獨(dú)的RabbitMQ隊(duì)列勺馆，以減少對核心隊(duì)列的壓力。

虛擬機(jī)網(wǎng)絡(luò)故障

在OpenStack中侨核，經(jīng)常會遇到虛擬機(jī)無法聯(lián)網(wǎng)的情況草穆，定位網(wǎng)絡(luò)故障也是OpenStack運(yùn)維必選課，主要追查流程如下搓译。

（1）在虛擬機(jī)控制臺中使用ifconfig檢查IP配置悲柱，然后ping網(wǎng)關(guān)。
如若不通些己，執(zhí)行步驟2豌鸡。

(1)

（2）通過Dashboard檢查Security Group，查看出口和入口的ICMP協(xié)議是否開啟段标，若在開啟情況下網(wǎng)絡(luò)仍然不通涯冠，執(zhí)行步驟3。

（3）在虛擬機(jī)宿主機(jī)上查看OpenFlow流逼庞。

(3)

若看到VlanID的轉(zhuǎn)換規(guī)則蛇更，則說明VLAN轉(zhuǎn)換沒有問題；否則，需要重啟Neutron-Server和RabbitMQ械荷，再次查看VlanID轉(zhuǎn)換規(guī)則是否已經(jīng)生成共耍。若還不通，執(zhí)行步驟4吨瞎。

（4）在出網(wǎng)的網(wǎng)卡（如em3）上抓包。

(4)

查看是否有包出去穆咐，如果看到包颤诀，則說明OpenStack配置沒有問題，需要檢查交換機(jī)是否配置Trunk模式对湃。

總結(jié)

在本章中崖叫，我們介紹了IaaS建設(shè)的意義，探討了兩種搭建私有IaaS平臺的方式：自己開發(fā)和采用開源方案拍柒⌒目考慮到建設(shè)成本，對比了不同的開源IaaS建設(shè)方案后拆讯，我們選擇基于OpenStack來搭建IaaS平臺脂男。在架構(gòu)設(shè)計(jì)中，重點(diǎn)討論了網(wǎng)絡(luò)架構(gòu)設(shè)計(jì)种呐，因?yàn)榫W(wǎng)絡(luò)架構(gòu)設(shè)計(jì)是OpenStack搭建過程中最復(fù)雜的部分宰翅，也是決定成敗的關(guān)鍵。鑒于對穩(wěn)定性和性能方面的考慮爽室，采用虛擬機(jī)通過Trunk直聯(lián)交換機(jī)的方式汁讼，停用了Neutron-L3-Agent的功能，由物理設(shè)備直接擔(dān)任路由轉(zhuǎn)發(fā)的功能阔墩；在存儲方面嘿架，通過經(jīng)驗(yàn)選擇了Ceph，因?yàn)樗褂闷饋砀臃€(wěn)定啸箫，并且在不斷的完善過程中耸彪。對象存儲Swift的穩(wěn)定性沒有問題，但是性能問題非常明顯筐高，期待Swift的改進(jìn)搜囱。在安裝部署上，推薦使用手動(dòng)安裝方式柑土，這是一種最可控的安裝方式蜀肘，但是需要對OpenStack的安裝方法深入了解，增加了學(xué)習(xí)成本稽屏，同時(shí)建議將Yum源同步到本地扮宠，防止OpenStack源升級后產(chǎn)生不可預(yù)知的錯(cuò)誤。接著，我們對虛擬機(jī)的性能進(jìn)行了測試坛增，以便消除大家對虛擬機(jī)性能的擔(dān)憂获雕。最后，介紹了一些OpenStack運(yùn)營心得收捣，比如版本升級届案、宿主機(jī)維護(hù)等常見問題，供大家參考罢艾。

本文遵循「知識共享許可協(xié)議 CC-BY-NC-SA 4.0 International」楣颠，未經(jīng)作者書面許可，不允許用于商業(yè)用途的轉(zhuǎn)載咐蚯、分發(fā)童漩、和演繹。