《OpenStack高可用集群（下冊）：部署與運維》—11.2 OpenStack集群高可用部署架構設計

11.2OpenStack集群高可用部署架構設計

對于OpenStack高可用集群部署而言，筆者建議在生產環境中正式部署之前，先在實驗環境中進行OpenStack各個功能模塊和高可用性的驗證。通過實驗環境從理論上完全實現了前期需求分析中對IaaS基礎架構的各種需求之后，生產環境中的部署將會變得非常快速和簡單（通常只需將實驗環境中部署成功的代碼復制一份，并放到生產環境中運行即可），而且不會因為很多意外問題而額外占用很多諸如電力、網絡等生產環境資源。因此，本節將從實驗環境準備和生產環境準備兩個方面來介紹OpenStack高可用集群部署的硬件環境塔建。值得指出的是，由于OpenStack部署模式的靈活性，事實上并不存在絕對唯一的部署架構，例如不同的服務可以合并部署到一個節點，也可以分開部署到不同節點，而多個服務又可以以不同的組合形式部署。因此，這里給出的僅是參考實現架構，不同用戶根據自身的實際環境，通常需要作出適當的調整。

11.2.1　OpenStack高可用部署實驗環境架構

為了實現一個“移動式”OpenStack高可用實驗環境，筆者建議將實驗環境部署在一臺筆記本電腦上，以方便隨時隨地全身心投入OpenStack的研究部署中，當然也可以部署在數據中心PC Server上。由于普通筆記本物理資源，尤其是內存，難以滿足集群需求，因此在開始OpenStack環境塔建之前，可能需要對個人筆記本進行硬件升級。這里硬件升級通常指升級內存條。不同型號筆記本支持的最大內存受主板限制可能不一樣，較老型號的可能僅支持最大4GB或8GB，而較新的主板可能支持16GB或32GB。查看主板支持的最大內存方式如圖11-3所示，在cmd命令窗口中輸入wmic memphysical get maxcapacity命令即可查看，圖11-3中筆記本最大支持16GB內存。

由于OpenStack高可用集群實驗環境僅做功能驗證測試，不做性能壓力測試，因此根據筆者經驗，16GB內存通過虛擬化完全可以實現三個控制節點和兩個計算節點的OpenStack高可用集群實驗環境。此外，如果希望在此電腦上進行Ceph存儲使用，則建議增大硬盤容量，1TB的硬盤空間足以滿足存儲節點實驗和虛擬機的多次快照保存。以筆者的實驗環境為例，筆記本型號為聯想T440p，內存16GB，CPU為Intel酷睿i5處理器，存儲為兩塊500GB硬盤，操作系統為64位Windows7 SP1旗艦版，虛擬化軟件為VMware Workstaion11，一共創建5臺VMware虛擬機，其中3臺控制節點用于實現OpenStack服務的高可用，2臺計算節點用于實現實例HA。另外，由于OpenStack高可用環境中必須實現Quorum機制，并能夠對控制節點進行隔離操作（Fencing），而VMware虛擬機在實現Fencing上有一定困難，因此在三臺控制節點VMware虛擬機上又各自創建了一臺KVM虛擬機，并且將這三臺KVM虛擬機作為最終的OpenStack高可用集群控制節點。筆者的實驗環境物理架構如圖11-4所示。在圖11-4中，控制節點由三臺VMware虛擬機中的三臺KVM虛擬機組成。計算節點由兩臺VMware虛擬機組成，OpenStack高可用集群由運行Pacemaker和Corosync進程的控制節點，以及運行Pacemaker_remote的計算節點組成。計算節點之所以僅運行Pacemaker_remote，是因為生產環境中如果計算節點也運行Pacemaker和Corosync進程，則Pacemaker高可用集群最大僅支持16個節點，而這顯然不能滿足生產環境中大規模節點部署的需求。Pacemaker_remote為Redhat專為解決Pacemaker集群節點限制而開發的精簡版Pacemaker，計算節點在運行Pacemaker_remote時，并不存在最大16個節點的限制，并且運行Pacemaker_remote的計算節點完全可以作為Pacemaker集群節點存在并接受控制節點的控制。

圖11-3　查看主板支持最大內存

圖11-4　OpenStack高可用部署實驗環境架構

在基于圖11-4所示實現的實驗環境中，服務器節點的部署實現所需要準備的工作便是準備好5臺VMware虛擬機（3臺為控制節點，2臺為計算節點）。控制節點VMware虛擬機的配置如圖11-5所示。

圖11-5　控制節點VMware虛擬機配置

為了能夠在VMware虛擬機中嵌套創建KVM虛擬機，在VMware虛擬機設置的處理器選項中，為處理器選擇Intel VT-x/EPT或AMD-V/RVI虛擬化引擎。此外，處理器的數量不易設置過大，否則容易出現因資源分配問題而導致的VMware虛擬機Holding問題。如果對VMware虛擬機CPU數量有要求，可以通過每個處理器的核心數來控制。由于3臺VMware虛擬機需要嵌套創建KVM虛擬機來作為控制節點，并且3臺KVM虛擬機控制節點需要運行絕大部分的OpenStack相關基礎服務和OpenStack核心服務，因此建議分配相對較多的內存。圖11-5所示分配了4GB內存給VMware虛擬機，其中的3GB用于VMware虛擬機中創建的KVM虛擬機控制節點。與控制節點不同，計算節點主要負責用戶實例創建，如果資源允許，計算節點可以分配較多的CPU和內存等資源。此外，對于一個高可用的OpenStack集群而言，任何節點都應該支持Fencing功能。由于是實驗環境，圖11-4所示的架構中僅運行在VMware虛擬機中的3個KVM虛擬機控制節點通過虛擬機Fencing驅動實現了隔離Fencing功能，而兩個運行在VMware虛擬機上的計算節點并沒有實現Fencing，但是這并不影響實驗環境中OpenStack集群的多數高可用功能驗證。如果在生產環境中，則計算節點的Fencing功能是必須的。

根據圖11-4所示的實驗環境架構，如果想要在自己的筆記本上部署一套高可用的OpenStack實驗環境，則可以按照如下步驟進行實現。

1）準備一臺硬件相對高配的筆記本電腦，進入主板BIOS，打開虛擬化支持功能（Intel-VT或AMD-V）。通常筆記本或PC服務器出廠時虛擬化支持功能均會打開，但是仍然建議進行檢查，因為后面很多與虛擬化相關的奇怪問題可能均與主板虛擬化功能是否開啟有關。

圖11-6　計算節點VMware虛擬機配置

2）在Windows系統中安裝VMware Workstation虛擬化軟件，VMware Workstation與VMware ESXi系列虛擬化引擎不一樣，Workstation是一種操作系統層面的虛擬化機制，其以應用程序的形式運行在操作系統中，因此在啟動實驗環境后，建議不要在同一個操作系統里面運行過多的其他應用程序，尤其是資源密集型的應用程序，以保證VMware Workstaion可以獲得最多的資源。

3）在VMware Workstation中創建三臺VMware虛擬機（虛擬機名稱分別為Controller1、Controller2和Controller3），虛擬機具體配置可以參考圖11-5所示。三臺VMware虛擬機用作OpenStack高可用集群控制節點宿主機。VMware虛擬機安裝Centos7.1系統。為了最大化KVM虛擬機控制節點的資源使用，VMware虛擬機操作系統安裝方式選為最小安裝。

4）在VMware Workstation中創建兩臺VMware虛擬機（虛擬機名稱分別為Compute1和Compute2），兩臺虛擬機用作OpenStack高可用集群的計算節點，虛擬機具體配置可以參考圖11-6所示。VMware虛擬機安裝Centos7.1系統。為了最大化將計算節點資源應用到用戶實例中，計算節點操作系統選用最小安裝方式安裝。

5）將控制節點Controller1設置為Master控制節點，Master控制節點將同時充當管理集群節點的角色，后續此節點將被配置為NFS服務器。因為實驗環境采用離線安裝方式，在運行部署腳本之前，先將Centos71系統鏡像和OpenStack離線安裝所需的rpm軟件包和依賴包上傳到Master上。

6）運行自動化配置腳本，初始化Controller1、Controller2和Controller3這三臺VMware虛擬機，為后期部署OpenStack服務準備好系統環境。初始化完成后，Controller1將被配置為Master控制節點和集群管理節點，同時被配置為集群NFS服務器。

7）運行自動化配置腳本初始化Compute1和Compute2這兩臺VMware虛擬機。初始化完成后，兩臺虛擬機將被配置為計算節點環境，從而為后期部署OpenStack的Nova-compute和Pacemaker_remote服務準備好系統環境。

8）將自動化配置所需的全部腳本上傳到Master控制節點，并在其上運行相應的腳本以在三個控制節點上安裝配置OpenStack相關服務，同時設置Pacemaker集群資源和資源約束等與集群管理相關的參數配置。

9）在Master控制節點上運行相應配置腳本，以在兩個計算節點上安裝配置Compute相關服務，并設置Pacemaker_remote相關資源和集群約束。

10）啟動Pacemaker集群服務并驗證集群服務運行情況。

11）驗證OpenStack集群服務的高可用性。

通常，實驗環境各個節點資源有限，在實驗環境中僅限于對OpenStack高可用集群的部分關鍵功能進行測試，對于諸如壓力測試等生產環境下必須的測試環節，實驗環境無能為力。此外，由于資源限制，某些理論上可以正常實現的功能，也可能因為資源不足而不能實現，甚至無法啟動某些服務。此時需要明白故障背后的深層原因，究竟是因為資源不足導致還是因為軟件問題、配置不對或配置沖突等問題導致的？正常情況下，實驗環境中可以正常實現的功能，在遷移至生產環境后，都可以成功實現，用戶需要注意的是隨著集群規模的擴大，客戶端連接數的增加為數據庫和消息隊列等基礎服務帶來的影響，例如數據庫的最大連接數設置和消息隊列的阻塞等問題。

OpenStack 云計算

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。