《OpenStack高可用集群案例實(shí)踐分享》要點(diǎn)：
本文介紹了OpenStack高可用集群案例實(shí)踐分享，希望對您有用。如果有疑問，可以聯(lián)系我們。

1. 規(guī)劃與部署

本次分享提煉自我們在某企業(yè)部署OpenStack高可用集群的實(shí)際案例,初期平臺面向公網(wǎng)給部分部門提供虛擬化基礎(chǔ)設(shè)施,但仍屬于私有云.其中我借鑒了以往操作比如oVirt(RHEV)、VMWare、Citrix等項(xiàng)目的經(jīng)驗(yàn).考慮到時間關(guān)系,本次內(nèi)容將以方法為主,減少細(xì)節(jié)描述.還有本次涉及到的工具多以開源形式呈現(xiàn),盡量不涉及到產(chǎn)品,以方便大家集成或開發(fā).

架構(gòu)簡圖可參考如下,稍后我們會就其中細(xì)節(jié)進(jìn)行講解.兩個架構(gòu)圖的區(qū)別在于控制節(jié)點(diǎn)的高可用方式.

1.1. 基本環(huán)境

因?yàn)榭蛻艟W(wǎng)絡(luò)環(huán)境復(fù)雜,為了節(jié)省部署時間與減少返工率,我們需要在去現(xiàn)場之前準(zhǔn)備好以下三種安裝方式：

• PXE LiveCD
• 定制系統(tǒng)安裝盤
• 安裝包與安裝腳本

第一種方式即在用戶網(wǎng)絡(luò)環(huán)境下使用現(xiàn)場人員筆記本或者客戶服務(wù)器啟動PXE服務(wù),配置好系統(tǒng)架構(gòu)(服務(wù)器MAC地址、網(wǎng)絡(luò)配置、存儲配置、對應(yīng)的OpenStack模塊與角色、定制包、系統(tǒng)微調(diào)與優(yōu)化措施等),然后開始全自動安裝,功能與Mirantis類似,但對網(wǎng)絡(luò)要求低很多.

第二種方式既是采用定制的系統(tǒng)安裝盤,里面需要準(zhǔn)備盡可能多的存儲設(shè)備與網(wǎng)絡(luò)設(shè)備的驅(qū)動,以盡可能適配客戶服務(wù)器與實(shí)施人員的自帶存儲設(shè)備.

第三種方式作為前兩種方式的替補(bǔ)選項(xiàng),主要是因?yàn)槟承┛蛻舡h(huán)境中安裝非標(biāo)系統(tǒng)需要走很多流程,我們提前讓客戶準(zhǔn)備好操作系統(tǒng),再到現(xiàn)場安裝.如果給你準(zhǔn)備的系統(tǒng)是RHEL、SUSE或者其他標(biāo)準(zhǔn)Linux系統(tǒng)的倒還好,如果他有情懷地花了一兩天給你現(xiàn)編譯上了Gentoo甚至給你準(zhǔn)備了一臺小機(jī),那就沒辦法了(開玩笑,尚未遇到過這樣的客戶,在進(jìn)廠之前要把基本環(huán)境溝通清楚).另外,它也可以作為以上兩種安裝方式失敗后的最佳選項(xiàng).

這幾種方式也不能說孰優(yōu)孰劣,從效率上來說我推薦第一種,但針對難以定制的商業(yè)虛擬化我們就只能采取手動安裝的方式了.

題外話：很多所謂“5分鐘裝完IaaS”的“神話”都不把服務(wù)器從啟動到改BIOS配BMC/IPMI的時間算進(jìn)去.

1.2. 網(wǎng)絡(luò)規(guī)劃

這一步驟優(yōu)先級最高,我們必須在動手之前就按照功能區(qū)域把網(wǎng)絡(luò)進(jìn)行劃分,包括管理、網(wǎng)管、存儲、租戶、顯示、遷移等.當(dāng)然,很多情況下沒必要劃分太細(xì),因?yàn)槲覀円鶕?jù)用戶網(wǎng)絡(luò)環(huán)境和軟件特性對他們進(jìn)行規(guī)劃,規(guī)劃太細(xì)發(fā)現(xiàn)最后配置難以實(shí)現(xiàn),“一把梭”規(guī)劃發(fā)現(xiàn)用戶一上來就喊卡.

一般來說,客戶的物理網(wǎng)絡(luò)主要以VLAN為主,其他情況暫不討論.對于非核心層的虛擬化而言,我們看到的多是untagged網(wǎng)絡(luò),所以規(guī)劃時要時刻留意網(wǎng)關(guān)與掩碼；而對于核心層的虛擬化,那么我們很有可能得到一堆tagged網(wǎng)絡(luò),都由我們自己與客戶商討規(guī)劃.

在網(wǎng)絡(luò)硬件上,僅就虛擬化層面而言,KVM系列的要求不高,而VMWare的FT則要求較為苛刻,萬兆、IB等都是標(biāo)配(題外話：KVM的FT功能尚不穩(wěn)定).如果涉及到下面要講到的“超融合”,那么萬兆專用存儲網(wǎng)絡(luò)真的是標(biāo)配了.如果應(yīng)用層面涉及到諸如Oracle之類的應(yīng)用,那我們很可能就要使用網(wǎng)絡(luò)設(shè)備透傳了,也可看規(guī)劃選擇性地走RDMA.

當(dāng)然,在現(xiàn)場時我們很有可能遇到交換機(jī)是全新并且客戶網(wǎng)管也不太會配置的情況,雖然極少但也是有的.秉著專業(yè)事兒交給專業(yè)人來干的原則,咱們可以等,等網(wǎng)管把交換機(jī)配好(客戶溝通妥善時自帶網(wǎng)管技能也行).

網(wǎng)絡(luò)規(guī)劃時,我們在最大限度保證帶寬的同時,要給予整體充分的可擴(kuò)展性.這次項(xiàng)目中,為了給予客戶享受科技帶來的便利,比如OpenStack Neutron便利網(wǎng)管、實(shí)現(xiàn)NFV導(dǎo)流、Fabric Network、Packet Broken Network、減少網(wǎng)絡(luò)單點(diǎn)故障率等等,我給客戶推薦了幾臺SDN交換機(jī)與其Neutron主機(jī)集成,然后可以在OpenDayLight里開發(fā)應(yīng)用程序并與OpenStack Dashboard結(jié)合呈現(xiàn)出看起來高大上的界面和功能,最大限度地利用OVS.(這里要感謝上海同悅信息龍未來先生協(xié)助開發(fā)的應(yīng)用)

1.3. 存儲規(guī)劃

如果用戶那有現(xiàn)成的存儲設(shè)備那就最好不過了,但也有利有弊.好處是減少了我們的運(yùn)維負(fù)擔(dān),關(guān)鍵時刻也可以“甩鍋”；壞處就是現(xiàn)有存儲很可能限制我們平臺的能力,也存在潛在的兼容性風(fēng)險.

由于軟件定義存儲的風(fēng)行,尤其是VMWare帶來的業(yè)界領(lǐng)導(dǎo)作用,客戶有可能想當(dāng)然地認(rèn)為虛擬化層面的存儲就該我們自己負(fù)責(zé).那沒辦法了,要么找個通過兼容性測試的存儲設(shè)備,要么自己上.這時候,用戶也是有選擇權(quán)的,比如這次就要上Ceph,雖然我個人更偏向于Glusterfs.

這些分布式存儲大同小異,與傳統(tǒng)的集中式存儲相比他們的成本低廉,性能與功能都尚可,能覆蓋絕大多數(shù)普通客戶的需求.但我們上分布式存儲總不能再問客戶要幾臺服務(wù)器專門搭存儲吧,那就得部分“超融合”了.

“超融合”也是現(xiàn)在OpenStack廠商項(xiàng)目部署的主流做法,比如管理組件在虛擬機(jī)中,硬件僅僅充作當(dāng)作功能性代理去操作硬盤.而本次項(xiàng)目中,我們也將Nova與Ceph裝在同一批機(jī)器中,同時采用對兩者進(jìn)程的運(yùn)行時環(huán)境進(jìn)行了優(yōu)化的系列措施,盡量減少“此消彼長”帶來的影響.

1.4. 軟件配置

絕大部分軟件都來自社區(qū)發(fā)布版本,部分核心模塊來自紅帽企業(yè)版,因?yàn)榫筒瓤訋茁识陨鐓^(qū)版本更高,況且我們作為國內(nèi)一個小小的軟件廠商,對紅帽有一種執(zhí)念,哈哈.

到宿主機(jī)層面的網(wǎng)管軟件并沒有額外采購,而是繼承了客戶原有系統(tǒng)；而到虛擬化層面,則額外配置了OpenDayLight結(jié)合OpenStack Dashboard進(jìn)行管理.

由于主機(jī)的存儲空間較多,所以本次也就存儲多網(wǎng)關(guān)協(xié)議進(jìn)行了一些拓展,類似于OpenMediaVault和FreeNAS的功能,以方便其他平臺使用.

本次部署的OpenStack僅涉及到虛擬化以及塊存儲相關(guān)組件,并未涉及到容器部分,因?yàn)榭蛻暨x擇了一家國產(chǎn)廠商的容器平臺作為應(yīng)用平臺.此種環(huán)境下的OpenStack平臺僅僅提供計算與存儲能力,且保證一定的容器隔離性.

題外話：針對平臺軟件開發(fā)的開源參考,個人認(rèn)為首選OpenStack和oVirt這兩者,前者走著公有云標(biāo)準(zhǔn),后者緊跟VMWare腳步.對于基于Docker的PaaS平臺開發(fā),我覺得使用了Kubernetes的OpenShift是個不錯的參考對象.還有OpenStack的那個容器模塊,第一印象很差,就沒再碰過了.

2. 最佳實(shí)踐

2.1. HA策略

HA即高可用(High Availability),在某些關(guān)鍵性服務(wù)上需要實(shí)現(xiàn)HA已保證業(yè)務(wù)連續(xù)性,這次項(xiàng)目中先就OpenStack控制節(jié)點(diǎn)實(shí)現(xiàn)HA.總的來說實(shí)現(xiàn)應(yīng)用的HA我總結(jié)有如下幾種方式：

負(fù)載均衡：雖然嚴(yán)格講負(fù)載均衡很容易存在單點(diǎn)故障,但某些情況下也是一種HA方式.

共享存儲：也就是比較經(jīng)典類似PaceMaker/KeepAlived+DRBD實(shí)現(xiàn)的冗余,適用范圍很廣.

FT：Fault Tolerance,兩臺機(jī)器的系統(tǒng)狀態(tài)隨時保持同步,一臺宕機(jī)后另一臺快速接業(yè)務(wù),可以保證很高的業(yè)務(wù)連續(xù)性.虛擬化平臺中以VMWare最為出名,其實(shí)也有可以單獨(dú)購買的FTServer,但是成本稍貴.目前KVM系列支持不佳.

遷移：在很多虛擬化平臺中,尤其KVM系列基本都有這一個HA措施,但缺點(diǎn)就是比如所在物理機(jī)宕機(jī)后,它會在其他機(jī)器上重啟,所有運(yùn)行時的系統(tǒng)狀態(tài)都會丟失,業(yè)務(wù)連續(xù)性有一定損失.當(dāng)然,它也需要宿主機(jī)的存儲保持同步,一般選用共享存儲.

虛擬管理節(jié)點(diǎn)：這種方式叫Self-Hosted(這個我翻譯不好),它也是虛擬化平臺中較為常見的HA方式,即是將管理節(jié)點(diǎn)作為虛擬機(jī),同時借助于遷移來保證管理節(jié)點(diǎn)的高可用.目前OpenStack尚不提供社區(qū)支持,本次部署中我們使用etcd配合簡單策略進(jìn)行了開發(fā),效果尚可.

其實(shí)針對不同應(yīng)用不同場景HA策略仍有很多,比如實(shí)現(xiàn)RabbitMQ的高可用除了以上方式我們也可直接使用它的鏡像(mirror)部署,實(shí)現(xiàn)Neutron的高可用可以使用VRRP實(shí)現(xiàn)分布式路由.總之HA方法太多了,需要靈活選型與搭配.

2.1. 自服務(wù)

在一些私有云項(xiàng)目里,僅僅部署平臺是不夠的,需要集成到客戶的系統(tǒng)中將虛擬化作為正常的業(yè)務(wù)(服務(wù))進(jìn)行提供.那這個時候,我們就很看中平臺所能提供的API完善度了.

比如自服務(wù)有主機(jī)選型、計費(fèi)、審計、認(rèn)證對接等流程,相當(dāng)一部分的工作都要在客戶環(huán)境下才能完成,雖然某些產(chǎn)品提供了不錯的接口,但是這也正是它的缺點(diǎn).比如這次對接單點(diǎn)登錄時,發(fā)現(xiàn)客戶環(huán)境中的系統(tǒng)繁多,有些老系統(tǒng)甚至不能進(jìn)行再開發(fā),對接難度比較大,如果不具備非常靈活的API與豐富的擴(kuò)展插件,那么繞的彎子就比較多了,部署效率大大降低.

現(xiàn)在一些廠商有提供自服務(wù)的單獨(dú)產(chǎn)品,開源的也有,但在使用時仍需要一定二次開發(fā)工作.

2.2. 無狀態(tài)服務(wù)

這里給個比較通俗的定義吧：在系統(tǒng)重啟前,不需要保存狀態(tài)的稱之為無狀態(tài)內(nèi)容,比如各種可執(zhí)行文件、庫文件等,需要保存狀態(tài)的稱之為有狀態(tài)內(nèi)容,比如存儲內(nèi)容、配置文件等.這里要講的無狀態(tài)包括基礎(chǔ)設(shè)施和上層服務(wù)兩部分.

基礎(chǔ)設(shè)施的無狀態(tài)在很多嵌入式設(shè)備、存儲設(shè)備里都很常見,比如一些交換機(jī)設(shè)備,其基本系統(tǒng)文件來自一個只讀的壓縮分區(qū)(類似squashfs),配置文件另外單獨(dú)存放,這樣能保證交換機(jī)即便出現(xiàn)意外也最多是配置文件丟失,但系統(tǒng)仍能工作.當(dāng)然,這只是軟件系統(tǒng)設(shè)計上的保證,實(shí)際用的時候發(fā)現(xiàn)交換機(jī)其他壞的地方也挺多的.

服務(wù)的無狀態(tài)也與之類似,即服務(wù)本身的載體可以被隨時替換.容器平臺與虛擬化平臺都可以實(shí)現(xiàn)應(yīng)用服務(wù)的無狀態(tài),但前者更加輕量.

無狀態(tài)服務(wù)是一把雙刃劍,優(yōu)點(diǎn)在易維護(hù),缺點(diǎn)也是難維護(hù).比如軟件出問題我們只要重啟機(jī)器就行了,但如果涉及到無狀態(tài)內(nèi)容,除去較為完善的補(bǔ)丁機(jī)制,也有可能重制底包.

以O(shè)penStack計算節(jié)點(diǎn)為例,你需要的無狀態(tài)內(nèi)容為系統(tǒng)本身+nova模塊相關(guān)文件,其他關(guān)鍵配置比如network-interface、sysctl.conf、nova.conf等等都可以單獨(dú)保持,在制作光盤時就需要確定的.

2.3. 備份與恢復(fù)

整體來說,很多IaaS平臺的備份與恢復(fù)都相對簡單,且RTO與RPO的指標(biāo)都非常容易做的很漂亮.

備份方法太多,傳統(tǒng)的軟件備份廠商已經(jīng)做了很多探索并且也有很好的產(chǎn)品了,所以這里只講一些適用于虛擬化的備份策略.

整機(jī)備份：除去傳統(tǒng)軟件外,也有一些虛擬化提供的工具,比如Converter或者virt-tools.在備份功能之外,它們都可以作為很好的PV轉(zhuǎn)換手段.

存儲域(卷)全備：既是將整個存儲域進(jìn)行備份,很大程度上依賴平臺自身與下層存儲的能力.存儲域備份也可以將顆粒度細(xì)化到虛擬機(jī)OVF,但一般不能更細(xì).

快照備份：在備份KVM平臺的虛擬機(jī)時,我們?nèi)匀豢梢詫⒂脖P文件與快照文件單獨(dú)備份,在第一次備份完成之后,以后只需要備份快照就行.這種方法不僅適用于裸鏡像文件,更適用于Ceph RBD.

在這些備份策略里,我比較常用的快照備份.比如OpenStack平臺,如果不依賴底層存儲能力的話,它所能提供備份策略不酷(只到鏡像級別),所以在一些項(xiàng)目中我們就直接從其API定位到實(shí)例的鏡像再進(jìn)行鏡像與快照的單獨(dú)備份.當(dāng)然,恢復(fù)的時候也直接恢復(fù)到實(shí)例.需要注意的是,假如通過網(wǎng)絡(luò)備份或恢復(fù),傳輸鏡像或快照文件的時候要注意文件空洞,否則會大大增加備份時間.

還有就是數(shù)據(jù)庫、配置文件等有狀態(tài)內(nèi)容的備份,備份方法簡單就不討論了.

在恢復(fù)時,OpenStack大多數(shù)模塊的恢復(fù)都比較容易,即數(shù)據(jù)、配置與數(shù)據(jù)庫即可.如果備份的時候包括了進(jìn)行中的任務(wù),那么需要在恢復(fù)后對其進(jìn)行清理.如果虛擬機(jī)數(shù)量不多,那么虛擬機(jī)或者存儲目錄直接導(dǎo)入也是一種方法.

2.4. 設(shè)備重定向

這個話題老生常談了,主要是某些應(yīng)用的U-key,以及高性能的需求,包括網(wǎng)卡、顯卡、硬盤等.實(shí)現(xiàn)手段仁者見仁智者見智,有喜歡走TCP/IP的,有喜歡走設(shè)備直通的.大家隨意選擇.有一點(diǎn)要注意的是,某些機(jī)器你P2V了,U-key也重定向進(jìn)去了,但是最后你發(fā)現(xiàn)這個授權(quán)與機(jī)器硬件環(huán)境掛鉤,那就白忙活一場了.

2.5. vGPU

這個話題是我硬塞的吧,跟本次項(xiàng)目無關(guān),我的書與隨書視頻都介紹了一些,這里我再說一些吧.

去年這時候KVMGT效果尚可,但難以產(chǎn)品化,再往前數(shù)的話就是靠著GPU透傳去實(shí)現(xiàn)了.相比同時期的Citrix,KVM只能望其項(xiàng)背.

而就在上個月KVMGT與Mediated Device都被并入了4.10內(nèi)核主分支與最近的Intel新獨(dú)立顯卡的發(fā)布,這可能是一個拐點(diǎn),意味著KVM下即將擁有靠譜的vGPU方案了.

當(dāng)然,如果nVidia不跳票的話,大家有興趣可以去我的博客看看最近的一篇nVidia的PPT.

2.6. 部分運(yùn)維事項(xiàng)

接下來OpenStack下的運(yùn)維,這點(diǎn)我的經(jīng)驗(yàn)不是很豐富,就講一下某些環(huán)境里需要上的,比如CVE檢測(漏洞檢查)和報表服務(wù).

CVE按理說應(yīng)該屬于企業(yè)網(wǎng)管部分,但我們的宿主機(jī)OS由于是高度定制化的,所以這部分的檢測予以特別考慮,即使被列入了企業(yè)的白名單我們也應(yīng)該有自己的檢測機(jī)制,就是只修復(fù)已經(jīng)經(jīng)過測試的補(bǔ)丁.

還有一個就是報表服務(wù),OpenStack本身可以選擇安裝Telemetry模塊提供簡單的報表服務(wù),然后可以將其作為DataWareHouse的數(shù)據(jù)源之一以方便后期進(jìn)行統(tǒng)計.領(lǐng)導(dǎo)就喜歡看報表嘛.

文章來自微信公眾號：云技術(shù)社區(qū)

作者：蔣迪

云技術(shù)社區(qū)專家,資深虛擬化基礎(chǔ)設(shè)施工程師,《KVM私有云架構(gòu)設(shè)計與實(shí)踐》作者,云技術(shù)社區(qū)專家,擅長KVM云平臺架構(gòu)解析與虛擬化POC,具有一線開發(fā)與交付經(jīng)驗(yàn).

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4098.html