OpenStack系統可以橫向做大規模的擴展，所有服務都能以分布式方式部署。但為了簡化我們決定將一些服務按照集中式方式部署在一個云控制器節點上(更多架構信息，請參見“樣例架構”章節)。云控制器是一個單一節點，用于部署數據庫，消息隊列服務，認證和權限服務，鏡像管理服務，用戶儀表盤和API endpoints。

云控制器為多節點的OpenStack部署提供了集中式的管理系統。特別是云控制器管理用戶認證并通過消息隊列發送消息到所有的系統節點。在我們的樣例架構中，云控制器具有一組nova-*組建。這些組建可以實現：顯示云系統全局狀態，服務間的通訊(如：用戶認證)，維護數據庫中云系統信息，同所有的計算和存儲節點通過消息隊列通訊和提供API的訪問方式。每種運行在云控制器上的服務可以分開部署在不同的節點上，通過分開部署可以實現擴展性和可用性。

硬件評估

云控制器可以和計算節點配置一樣，未來可以根據云類型和容量重新考慮硬件配置。云控制器也可以通過所有或部分的服務放入虛擬機進行管理，比如：消息隊列。本書中我們假設所有服務直接運行的云控制節點的物理環境中。

為了準確評估服務器配置，決定是否需要使用全部或部分虛擬化，你需要考慮一下因素：

• 你估計有多少實例運行
• 當前擁有多少物理機用于計算節點
• 訪問計算或存儲服務的用戶數量
• 使用你云服務的用戶是如何進行操作的，使用REST API還是通過用戶儀表盤
• 用戶認證是否通過外部系統(如：LDAP，Active Directory)
• 單個實例會保持運行多久

考慮因素 擴展考慮 同時會有多少實例運行？ 相應需要評估的有，數據庫的容量，如果許多實例同時請求狀態報告需要考慮單個多個云控制器，新實例啟動時需要一定的計算能力。 同時會有多少計算節點運行？ 確保消息隊列服務可以處理相應容量的請求 多少用戶會使用API方式訪問？ 如果許多用戶發出多條請求，確保云控制器的CPU負載可以處理所有請求。 多少用戶會使用儀表板方式訪問？ 儀表盤方式會發送會比API方式發送更多的請求，所以當儀表盤方式是用戶主要的操作界面則需要添加更多CPU的計算能力。 同時有多少的nova-api服務在運行？使用一個CPU核心對應一個服務的方式評估云控制器。 單個實例會運行多久？ 開始和刪除一個實例是在計算節點上處理，但云控制器需要在期間處理API查詢和調度控制。 用戶認證是否在外部實現？ 確保云控制器和外部認證系統間的網絡連接正常，且云控制器的CPU有能力處理相應的請求。

分布服務

在我們的樣例中，相關的服務都是集中安裝在一個物理節點上。但在實際應用中較好的建議是將服務分布到不同的物理節點上。以下是一些我們見到過的部署場景和相應的說明。

最常見的一個選擇是是否需要使用虛擬化。有些服務如：nova-compute，swift-proxy和swift-object服務不應運行于虛擬化環境中。但是，云控制相關服務通常都可以運行在虛擬化環境中。運行在虛擬化環境中有一定的性能損失，但是相應可以運行更多的服務。

數據庫 大部分的OpenStack集中服務使用數據庫保存統計信息(目前也包括nova-compute節點)。不能訪問數據庫服務就會導致系統報錯。所以，我們建議通過建立數據庫集群方式防止數據庫的單點故障。

消息隊列 大部分的OpenStack服務間使用消息隊列方式進行通訊。通常，如果消息隊列發生故障或無法訪問，OpenStack會系統掛起，最后進入只讀狀態，該狀態下的所有信息就是最后收到的消息所保留的狀態。所以我們建議消息隊列需要建立在集群的架構上，并RabbitMQ內建支持集群部署。

API 所有的公共訪問方式，不管是直接的，通過命令行方式或通過基于web的儀表盤方式都是通過API服務實現。詳細的API信息可以訪問http://api.openstack.org/

你需要在是否兼容Amazon EC2 API和只支持OpenStack API之間進行選擇。當同時使用2種API時常見的不兼容問題涉及到鏡像和實例的使用。比如：EC2 API使用包含16進制的ID來標示實例，但OpenStack API使用名字和數字標示。類似情況還有，EC2 API更多的依賴于DNS解析的別名和實例進行連接，而OpenStack則使用IP地址。如果OpenStack沒有使用正確方式進行配置，通常的情況就是用戶無法訪問他們的實例。盡管兼容EC2 API方式存在問題，但是方式下能協助用戶從Amazon云遷移到OpenStack上。

就像數據庫和消息隊列服務，能有多于1個API服務的節點總是件好事。常用的HTTP負載均衡技術也可以實現對于nova-api服務的高可用性。

擴展 API說明文檔(http://docs.openstack.org/api/api-specs.html)定義了核心組建，功能和媒體類型。客戶端軟件可以始終依賴于核心API。OpenStack將一直完整支持該API。通過嚴格遵循核心API，使得客戶端可以使用相同的API在多個不同版本上實現基本一致的功能。

OpenStack API具有擴展性。可通過對于API的擴展增加核心API不具有的功能。新功能的引入，如：MIME類型，動作，狀態，頭，參數和資源，都通過擴展核心API實現。擴展可以在現有基礎上增加新功能而不需要等待新版本，同時也允許供應商提供定制化的功能服務。

調度器 將不同配置的虛擬機調度安排運行在不同性能的物理計算節點上是一個極富挑戰的問題，通常該問題也是計算機科學中所涉及到的一系列研究課題。目前有多種技術用于處理調度。其中有：按照虛擬機的配置線性測量法，將物理節點容量均衡分段法等。如何解決調度問題的算法已超出本書范圍。OpenStack提供了幾種不同的調度引擎，通過訪問(http://docs.openstack.org/folsom/openstack-compute/admin/content/ch_scheduling.html)可以獲得詳細的調度器說明文檔。

出于可用性，大規模部署或高頻度調度下，你應該考慮選擇使用多個nova-scheduler服務。nova-scheduler服務完全使用消息隊列通訊，所以不需要使用負載均衡設備。

鏡像 OpenStack鏡像分類和交付服務由2部分glance-api和glance-registry組成。前一部分是用于提供鏡像交付和計算節點下載鏡像文件用途。后一部分則維護了鏡像文件的相關元數據信息，該部分服務需要數據庫支持。

glance-api部分是一個抽象層，它支持多種的后端存儲方式。目前支持的有：

如果你已有OpenStack對象存儲服務，我們建議你使用對象存儲服務來存放鏡像。對象存儲服務具有良好的擴展性。除非你不需要通過OpenStack上傳鏡像，否則只有文件系統可以作為實用的選擇。

儀表盤 OpenStack儀表盤使用的是運行在Apache httpd服務上的Python web應用。所以，你可以和其他web應用一樣的維護方式，確保儀表盤應用可以通過網絡訪問API服務(包括管理endpoints)。

認證和授權 OpenStack中的認證和授權概念和其他常用系統中的一致。用戶使用安全憑證(如：用戶名和密碼)進行認證。用戶可以屬于一個或多個組(在OpenStack中稱作項目或租戶)。比如：一個云系統管理員可以列出所有云中運行的實例，而一個普通用戶只能看到他所屬組的實例。資源配額(比如可以使用的CPU內核數，磁盤空間等)是和項目相關聯的。

OpenStack身份服務(Keystone)提供用戶認證和用戶屬性信息。該服務也為其他的OpenStack服務提供認證。可通過文件policy.json配置策略，請參見**用戶支持章節**獲得更多如何配置信息。

身份服務通過不同的插件支持不同的后端認證方式。后端認證方式范圍從單純存儲到外部系統，包括：

許多部署方案采用SQL數據庫的方式作為認證架構集成入OpenStack。LDAP也是一種常用的認證機制。

網絡評估 由于云控制器集中了很多不同的服務，所以云控制器相應的網絡通訊產生的流量也很多。比如：如果將OpenStack的鏡像服務安裝在云控制器上，云控制器需要能以可接受的網速傳輸鏡像文件。

另一個例子是，當你選擇使用單主機網絡，云控制器將成為所有實例的網關。這種情況下，云控制器必須能支持處理所有從Internet進出的網絡訪問流量。

建議采用高速網卡，如：10gb網卡。你也可以同時使用2張10gb網卡，并將它們綁定在一起。在雙網卡綁定下總帶寬不是總能達到20gb，不同的數據傳輸流將使用不同的網卡。比如：當云控制器正在傳輸2個鏡像文件，每個文件將各自使用一張網卡進行傳輸，這種情況下，充分利用了各自的10gb帶寬。