OpenStack系統(tǒng)可以橫向做大規(guī)模的擴(kuò)展，所有服務(wù)都能以分布式方式部署。但為了簡(jiǎn)化我們決定將一些服務(wù)按照集中式方式部署在一個(gè)云控制器節(jié)點(diǎn)上(更多架構(gòu)信息，請(qǐng)參見“樣例架構(gòu)”章節(jié))。云控制器是一個(gè)單一節(jié)點(diǎn)，用于部署數(shù)據(jù)庫(kù)，消息隊(duì)列服務(wù)，認(rèn)證和權(quán)限服務(wù)，鏡像管理服務(wù)，用戶儀表盤和API endpoints。

云控制器為多節(jié)點(diǎn)的OpenStack部署提供了集中式的管理系統(tǒng)。特別是云控制器管理用戶認(rèn)證并通過消息隊(duì)列發(fā)送消息到所有的系統(tǒng)節(jié)點(diǎn)。在我們的樣例架構(gòu)中，云控制器具有一組nova-*組建。這些組建可以實(shí)現(xiàn)：顯示云系統(tǒng)全局狀態(tài)，服務(wù)間的通訊(如：用戶認(rèn)證)，維護(hù)數(shù)據(jù)庫(kù)中云系統(tǒng)信息，同所有的計(jì)算和存儲(chǔ)節(jié)點(diǎn)通過消息隊(duì)列通訊和提供API的訪問方式。每種運(yùn)行在云控制器上的服務(wù)可以分開部署在不同的節(jié)點(diǎn)上，通過分開部署可以實(shí)現(xiàn)擴(kuò)展性和可用性。

硬件評(píng)估

云控制器可以和計(jì)算節(jié)點(diǎn)配置一樣，未來可以根據(jù)云類型和容量重新考慮硬件配置。云控制器也可以通過所有或部分的服務(wù)放入虛擬機(jī)進(jìn)行管理，比如：消息隊(duì)列。本書中我們假設(shè)所有服務(wù)直接運(yùn)行的云控制節(jié)點(diǎn)的物理環(huán)境中。

為了準(zhǔn)確評(píng)估服務(wù)器配置，決定是否需要使用全部或部分虛擬化，你需要考慮一下因素：

• 你估計(jì)有多少實(shí)例運(yùn)行
• 當(dāng)前擁有多少物理機(jī)用于計(jì)算節(jié)點(diǎn)
• 訪問計(jì)算或存儲(chǔ)服務(wù)的用戶數(shù)量
• 使用你云服務(wù)的用戶是如何進(jìn)行操作的，使用REST API還是通過用戶儀表盤
• 用戶認(rèn)證是否通過外部系統(tǒng)(如：LDAP，Active Directory)
• 單個(gè)實(shí)例會(huì)保持運(yùn)行多久

考慮因素 擴(kuò)展考慮 同時(shí)會(huì)有多少實(shí)例運(yùn)行？ 相應(yīng)需要評(píng)估的有，數(shù)據(jù)庫(kù)的容量，如果許多實(shí)例同時(shí)請(qǐng)求狀態(tài)報(bào)告需要考慮單個(gè)多個(gè)云控制器，新實(shí)例啟動(dòng)時(shí)需要一定的計(jì)算能力。 同時(shí)會(huì)有多少計(jì)算節(jié)點(diǎn)運(yùn)行？ 確保消息隊(duì)列服務(wù)可以處理相應(yīng)容量的請(qǐng)求 多少用戶會(huì)使用API方式訪問？ 如果許多用戶發(fā)出多條請(qǐng)求，確保云控制器的CPU負(fù)載可以處理所有請(qǐng)求。 多少用戶會(huì)使用儀表板方式訪問？ 儀表盤方式會(huì)發(fā)送會(huì)比API方式發(fā)送更多的請(qǐng)求，所以當(dāng)儀表盤方式是用戶主要的操作界面則需要添加更多CPU的計(jì)算能力。 同時(shí)有多少的nova-api服務(wù)在運(yùn)行？使用一個(gè)CPU核心對(duì)應(yīng)一個(gè)服務(wù)的方式評(píng)估云控制器。 單個(gè)實(shí)例會(huì)運(yùn)行多久？ 開始和刪除一個(gè)實(shí)例是在計(jì)算節(jié)點(diǎn)上處理，但云控制器需要在期間處理API查詢和調(diào)度控制。 用戶認(rèn)證是否在外部實(shí)現(xiàn)？ 確保云控制器和外部認(rèn)證系統(tǒng)間的網(wǎng)絡(luò)連接正常，且云控制器的CPU有能力處理相應(yīng)的請(qǐng)求。

分布服務(wù)

在我們的樣例中，相關(guān)的服務(wù)都是集中安裝在一個(gè)物理節(jié)點(diǎn)上。但在實(shí)際應(yīng)用中較好的建議是將服務(wù)分布到不同的物理節(jié)點(diǎn)上。以下是一些我們見到過的部署場(chǎng)景和相應(yīng)的說明。

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

數(shù)據(jù)庫(kù) 大部分的OpenStack集中服務(wù)使用數(shù)據(jù)庫(kù)保存統(tǒng)計(jì)信息(目前也包括nova-compute節(jié)點(diǎn))。不能訪問數(shù)據(jù)庫(kù)服務(wù)就會(huì)導(dǎo)致系統(tǒng)報(bào)錯(cuò)。所以，我們建議通過建立數(shù)據(jù)庫(kù)集群方式防止數(shù)據(jù)庫(kù)的單點(diǎn)故障。

消息隊(duì)列 大部分的OpenStack服務(wù)間使用消息隊(duì)列方式進(jìn)行通訊。通常，如果消息隊(duì)列發(fā)生故障或無法訪問，OpenStack會(huì)系統(tǒng)掛起，最后進(jìn)入只讀狀態(tài)，該狀態(tài)下的所有信息就是最后收到的消息所保留的狀態(tài)。所以我們建議消息隊(duì)列需要建立在集群的架構(gòu)上，并RabbitMQ內(nèi)建支持集群部署。

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

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

就像數(shù)據(jù)庫(kù)和消息隊(duì)列服務(wù)，能有多于1個(gè)API服務(wù)的節(jié)點(diǎn)總是件好事。常用的HTTP負(fù)載均衡技術(shù)也可以實(shí)現(xiàn)對(duì)于nova-api服務(wù)的高可用性。

擴(kuò)展 API說明文檔(http://docs.openstack.org/api/api-specs.html)定義了核心組建，功能和媒體類型?？蛻舳塑浖梢允冀K依賴于核心API。OpenStack將一直完整支持該API。通過嚴(yán)格遵循核心API，使得客戶端可以使用相同的API在多個(gè)不同版本上實(shí)現(xiàn)基本一致的功能。

OpenStack API具有擴(kuò)展性。可通過對(duì)于API的擴(kuò)展增加核心API不具有的功能。新功能的引入，如：MIME類型，動(dòng)作，狀態(tài)，頭，參數(shù)和資源，都通過擴(kuò)展核心API實(shí)現(xiàn)。擴(kuò)展可以在現(xiàn)有基礎(chǔ)上增加新功能而不需要等待新版本，同時(shí)也允許供應(yīng)商提供定制化的功能服務(wù)。

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

出于可用性，大規(guī)模部署或高頻度調(diào)度下，你應(yīng)該考慮選擇使用多個(gè)nova-scheduler服務(wù)。nova-scheduler服務(wù)完全使用消息隊(duì)列通訊，所以不需要使用負(fù)載均衡設(shè)備。

鏡像 OpenStack鏡像分類和交付服務(wù)由2部分glance-api和glance-registry組成。前一部分是用于提供鏡像交付和計(jì)算節(jié)點(diǎn)下載鏡像文件用途。后一部分則維護(hù)了鏡像文件的相關(guān)元數(shù)據(jù)信息，該部分服務(wù)需要數(shù)據(jù)庫(kù)支持。

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

如果你已有OpenStack對(duì)象存儲(chǔ)服務(wù)，我們建議你使用對(duì)象存儲(chǔ)服務(wù)來存放鏡像。對(duì)象存儲(chǔ)服務(wù)具有良好的擴(kuò)展性。除非你不需要通過OpenStack上傳鏡像，否則只有文件系統(tǒng)可以作為實(shí)用的選擇。

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

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

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

身份服務(wù)通過不同的插件支持不同的后端認(rèn)證方式。后端認(rèn)證方式范圍從單純存儲(chǔ)到外部系統(tǒng)，包括：

許多部署方案采用SQL數(shù)據(jù)庫(kù)的方式作為認(rèn)證架構(gòu)集成入OpenStack。LDAP也是一種常用的認(rèn)證機(jī)制。

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

另一個(gè)例子是，當(dāng)你選擇使用單主機(jī)網(wǎng)絡(luò)，云控制器將成為所有實(shí)例的網(wǎng)關(guān)。這種情況下，云控制器必須能支持處理所有從Internet進(jìn)出的網(wǎng)絡(luò)訪問流量。

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