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

1. 規劃與部署

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

架構簡圖可參考如下,稍后我們會就其中細節進行講解.兩個架構圖的區別在于控制節點的高可用方式.

1.1. 基本環境

因為客戶網絡環境復雜,為了節省部署時間與減少返工率,我們需要在去現場之前準備好以下三種安裝方式：

• PXE LiveCD
• 定制系統安裝盤
• 安裝包與安裝腳本

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

第二種方式既是采用定制的系統安裝盤,里面需要準備盡可能多的存儲設備與網絡設備的驅動,以盡可能適配客戶服務器與實施人員的自帶存儲設備.

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

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

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

1.2. 網絡規劃

這一步驟優先級最高,我們必須在動手之前就按照功能區域把網絡進行劃分,包括管理、網管、存儲、租戶、顯示、遷移等.當然,很多情況下沒必要劃分太細,因為我們要根據用戶網絡環境和軟件特性對他們進行規劃,規劃太細發現最后配置難以實現,“一把梭”規劃發現用戶一上來就喊卡.

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

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

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

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

1.3. 存儲規劃

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

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

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

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

1.4. 軟件配置

絕大部分軟件都來自社區發布版本,部分核心模塊來自紅帽企業版,因為就踩坑幾率而言社區版本更高,況且我們作為國內一個小小的軟件廠商,對紅帽有一種執念,哈哈.

到宿主機層面的網管軟件并沒有額外采購,而是繼承了客戶原有系統；而到虛擬化層面,則額外配置了OpenDayLight結合OpenStack Dashboard進行管理.

由于主機的存儲空間較多,所以本次也就存儲多網關協議進行了一些拓展,類似于OpenMediaVault和FreeNAS的功能,以方便其他平臺使用.

本次部署的OpenStack僅涉及到虛擬化以及塊存儲相關組件,并未涉及到容器部分,因為客戶選擇了一家國產廠商的容器平臺作為應用平臺.此種環境下的OpenStack平臺僅僅提供計算與存儲能力,且保證一定的容器隔離性.

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

2. 最佳實踐

2.1. HA策略

HA即高可用(High Availability),在某些關鍵性服務上需要實現HA已保證業務連續性,這次項目中先就OpenStack控制節點實現HA.總的來說實現應用的HA我總結有如下幾種方式：

負載均衡：雖然嚴格講負載均衡很容易存在單點故障,但某些情況下也是一種HA方式.

共享存儲：也就是比較經典類似PaceMaker/KeepAlived+DRBD實現的冗余,適用范圍很廣.

FT：Fault Tolerance,兩臺機器的系統狀態隨時保持同步,一臺宕機后另一臺快速接業務,可以保證很高的業務連續性.虛擬化平臺中以VMWare最為出名,其實也有可以單獨購買的FTServer,但是成本稍貴.目前KVM系列支持不佳.

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

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

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

2.1. 自服務

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

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

現在一些廠商有提供自服務的單獨產品,開源的也有,但在使用時仍需要一定二次開發工作.

2.2. 無狀態服務

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

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

服務的無狀態也與之類似,即服務本身的載體可以被隨時替換.容器平臺與虛擬化平臺都可以實現應用服務的無狀態,但前者更加輕量.

無狀態服務是一把雙刃劍,優點在易維護,缺點也是難維護.比如軟件出問題我們只要重啟機器就行了,但如果涉及到無狀態內容,除去較為完善的補丁機制,也有可能重制底包.

以OpenStack計算節點為例,你需要的無狀態內容為系統本身+nova模塊相關文件,其他關鍵配置比如network-interface、sysctl.conf、nova.conf等等都可以單獨保持,在制作光盤時就需要確定的.

2.3. 備份與恢復

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

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

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

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

快照備份：在備份KVM平臺的虛擬機時,我們仍然可以將硬盤文件與快照文件單獨備份,在第一次備份完成之后,以后只需要備份快照就行.這種方法不僅適用于裸鏡像文件,更適用于Ceph RBD.

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

還有就是數據庫、配置文件等有狀態內容的備份,備份方法簡單就不討論了.

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

2.4. 設備重定向

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

2.5. vGPU

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

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

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

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

2.6. 部分運維事項

接下來OpenStack下的運維,這點我的經驗不是很豐富,就講一下某些環境里需要上的,比如CVE檢測(漏洞檢查)和報表服務.

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

還有一個就是報表服務,OpenStack本身可以選擇安裝Telemetry模塊提供簡單的報表服務,然后可以將其作為DataWareHouse的數據源之一以方便后期進行統計.領導就喜歡看報表嘛.

文章來自微信公眾號：云技術社區

作者：蔣迪

云技術社區專家,資深虛擬化基礎設施工程師,《KVM私有云架構設計與實踐》作者,云技術社區專家,擅長KVM云平臺架構解析與虛擬化POC,具有一線開發與交付經驗.

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4098.html