摸索openstack一段時間了，我們自己數據中心也搭了一套。今天分享給大家，有不妥的地方還望列爲技術大師不吝賜教。
關於openstack架構等相關概念就不在這介紹了（這些東西資料一大坨，都被說爛了）。
先來看看我們的系統資源吧，我們的環境中有100臺物理服務器，磁盤RAID採用raid 5，之前曾嘗試過raid 6，發現對性能的損耗很大，得不償失啊。服務器都是雙網卡，eth0跑虛擬機業務，eth1跑數據業務。
我們是基於openstack的F版本進行開發部署的，再來看一下我們的openstack部署架構吧。
- 安裝部署主控節點
安裝部署主控節點用於對openstack進行自動化的批量部署，其中spanner爲我們團隊自編寫的可視化的用於批量安裝腳本。
- 控制節點
控制節點充當着全部節點的“大腦”，安裝了除nova-compute外的全部服務，其中包括：前端界面（horizon），數據庫（mysql），消息隊列（rabbitmq），驗證服務（keystone），鏡像管理（glance），虛擬機管理（nova），雲硬盤管理（cinder），對象存儲管理（swift），監控服務（ceilometer）。控制節點全部服務安裝在1臺物理服務器上。
注：這裏的虛擬機管理服務（nova）開啓了除nova-compute之外的全部nova服務
- 存儲節點
存儲節點用於存儲虛擬機實例（nova-instance）數據、對象存儲（swift）或塊存儲（cinder）數據。存儲節點用6臺物理服務器組成glusterfs分佈式共享存儲集羣，採用寫一份數據寫一份副本（replica=2）的存儲策略，建立3個卷（volume），分別掛載到nova-instance、swift、cinder的數據存儲目錄。關於glusterfs的詳細介紹大家可以看我博客中的其它文章。
- 計算節點
計算節點是一臺一臺虛擬機的宿主機們，理論上每個計算節點上只需要安裝nova-compute服務即可。但在我們的環境中，考慮到控制節點，特別是當nova-api及nova-network服務都只部署在控制節點上時，其承載的壓力過大，而且容易發生單點故障。所以我們在計算節點上同時安裝部署了nova-api和nova-network服務，採用這種分佈式的方式部署後，nova-api和nova-network都指向計算節點本身的nova-api和nova-network服務，而不再指向控制節點的nova-api和nova-network服務。以nova-network爲例，每個虛擬機實例出口網關不再是控制節點的相應網卡，而是其宿主機的相應網卡。關於這點有興趣的讀者可以看我上一篇文章。
- 服務高可用節點
服務高可用節點主要是針對消息隊列負載過大和單點故障情況，應用HAProxy及keepalived對消息隊列服務進行負載均衡。後臺採用mongodb存儲監控數據，以提高查詢效率。