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，具有一線開發與交付經驗。