【文章內(nèi)容簡介】 是作者的理解。通過覆蓋OpenStack Compute 邏輯組件，Glance和Dashboard，來表示功能范圍。對于每一個覆蓋，都有相應(yīng)的提供該功能的邏輯組件的名稱。l 在這種覆蓋范圍中，最大的差距是logging和billing。此刻，OpenStack Compute沒有能協(xié)調(diào)logging事件、記錄日志以及創(chuàng)建/呈現(xiàn)bills的Billing組件。真正的焦點是logging和Billing的整合。這能通過以下方式來補救。比如代碼擴充，商業(yè)產(chǎn)品或者服務(wù)或者自定義日志解析的整合。l Identity也是未來可能要補充的一點。l customer portal也是一個整合點。user dashboard（見運行的實例，啟動新的實例）沒有提供一個界面，來允許應(yīng)用擁有者簽署服務(wù)，跟蹤它們的費用以及聲明有問題的票據(jù)（lodge trouble tickets）。而且，這很可能對我們設(shè)想的服務(wù)提供商來說是合適的。l 理想的情況是，Admin API會復(fù)制我們能通過命令行接口做的所有功能。在帶有Admin API work的Diablo 發(fā)布中會更好。l 云監(jiān)控和操作將是服務(wù)提供商關(guān)注的重點。好操作方法的關(guān)鍵是好的工具。當(dāng)前，OpenStack Compute 提供 novainstancemonitor，它跟蹤計算結(jié)點使用情況。未來我們還需要三方工具來監(jiān)控。l Policy是極其重要的方面，但是會與供應(yīng)商很相關(guān)。從quotas到QoS，到隱私控制都在其管轄內(nèi)。當(dāng)前圖上有部分覆蓋，但是這取決于供應(yīng)商的復(fù)雜需求。為準(zhǔn)確起見，OpenStack Compute 為實例，浮點IP地址以及元數(shù)據(jù)提供配額。l 當(dāng)前，OpenStack Compute內(nèi)的Scheduling對于大的安裝來說是相當(dāng)初步的。調(diào)度器是以插件的方式設(shè)計的，目前支持chance(隨機主機分配)，simple(最少負(fù)載)和zone（在一個可用區(qū)域里的隨機結(jié)點。）分布式的調(diào)度器和理解異構(gòu)主機的調(diào)度器正在開發(fā)之中。 如你所見，OpenStack Compute為我們想象的服務(wù)提供商，提供了一個不錯的基礎(chǔ)，只要服務(wù)提供商愿意做一些整合。 OpenStack Compute系統(tǒng)架構(gòu)OpenStack Compute由一些主要組件組成。“Cloud controller”包含很多組件，它表示全局狀態(tài)，以及與其他組件交互。實際上，它提供的是Novaapi服務(wù)。它的功能是：為所有API查詢提供一個端點，初始化絕大多數(shù)的部署活動，以及實施一些策略。API 服務(wù)器起cloud controller web Service前端的作用。Compute controller 提供pute服務(wù)資源，典型包含pute service，Object Store ponent可選地提供存儲服務(wù)。Auth manager提供認(rèn)證和授權(quán)服務(wù)，Volume controller為pute servers提供快速和持久的塊級別存儲。Network controller提供虛擬網(wǎng)絡(luò)使pute servers彼此交互以及與公網(wǎng)進(jìn)行交互。Scheduler選擇最合適的pute controller來管理（host）一個實例。OpenStack Compute建立在無共享、基于消息的架構(gòu)上。Cloud controller通過HTTP與internal object store交互，通過AMQP和scheduler、network controller、 和volume controller 來進(jìn)行通信。為了避免在等待接收時阻塞每個組件，OpenStack Compute用異步調(diào)用的方式。為了獲得帶有一個組件多個備份的無共享屬性，OpenStack Compute將所有的云系統(tǒng)狀態(tài)保持在分布式的數(shù)據(jù)存儲中。對系統(tǒng)狀態(tài)的更新會寫到這個存儲中，必要時用質(zhì)子事務(wù)。對系統(tǒng)狀態(tài)的請求會從store中讀出。在少數(shù)情況下，控制器也會短時間緩存讀取結(jié)果。 OpenStack Compute物理架構(gòu)OpenStack Compute采用無共享、基于消息的架構(gòu)，非常靈活，我們能安裝每個nova service在單獨的服務(wù)器上，這意味著安裝OpenStack Compute有多種可能的方法?？赡芏嘟Y(jié)點部署唯一的聯(lián)合依賴性，是Dashboard必須被安裝在novaapi服務(wù)器。幾種部署架構(gòu)如下：a) 單結(jié)點：一臺服務(wù)器運行所有的nova services，同時也驅(qū)動虛擬實例。這種配置只為嘗試OpenStack Compute，或者為了開發(fā)目的；b) 雙結(jié)點：一個cloud controller 結(jié)點運行除novapute外的所有novaservices，pute結(jié)點運行novapute。一臺客戶計算機很可能需要打包鏡像，以及和服務(wù)器進(jìn)行交互，但是并不是必要的。這種配置主要用于概念和開發(fā)環(huán)境的證明。c) 多結(jié)點：，你能在兩結(jié)點的基礎(chǔ)上，添加更多的pute結(jié)點，形成多結(jié)點部署。在較為復(fù)雜的多結(jié)點部署中，還能增加一個volume controller 和一個network controller作為額外的結(jié)點。對于運行多個需要大量處理能力的虛擬機實例，至少是4個結(jié)點是最好的。一個可能的Openstack Compute多服務(wù)器部署（集群中聯(lián)網(wǎng)的虛擬服務(wù)器可能會改變）如下33所示：33 OpenStack Compute物理架構(gòu)一 如果你注意到消息隊列中大量的復(fù)制引發(fā)了性能問題，一種可選的架構(gòu)是增加更多的Messaging服務(wù)器。在這種情形下，除了可以擴展數(shù)據(jù)庫服務(wù)器外，還可以增加一臺額外的RabbitMQ服務(wù)器。部署中可以在任意服務(wù)器上運行任意novaservice，并且這些服務(wù)器能發(fā)送消息到它。 下圖34是另外一種多結(jié)點的部署架構(gòu)。34 多結(jié)點的部署架構(gòu)二 OpenStack Compute服務(wù)架構(gòu)因為Compute有多個服務(wù)，也可能有多種配置，下圖35顯示了總體的服務(wù)架構(gòu)，以及服務(wù)之間的通信系統(tǒng)。35 OpenStack Compute服務(wù)架構(gòu)1. OpenStack Image ServiceOpenStack Image Service包括兩個主要的部分，分別是API server和Registry server(s)。OpenStack Image Service的設(shè)計，盡可能適合各種后端倉儲和注冊數(shù)據(jù)庫方案。API Server（運行“glance api”程序）起通信hub的作用。比如各種各樣的客戶程序，鏡像元數(shù)據(jù)的注冊，實際包含虛擬機鏡像數(shù)據(jù)的存儲系統(tǒng)，都是通過它來進(jìn)行通信的。API server轉(zhuǎn)發(fā)客戶端的請求到鏡像元數(shù)據(jù)注冊處和它的后端倉儲。OpenStack Image Service就是通過這些機制來實際保存進(jìn)來的虛擬機鏡像的。OpenStack Image Service支持的后端倉儲有：l OpenStack Object Storage。它是OpenStack中高可用的對象存儲項目。l FileSystem。OpenStack Image Service存儲虛擬機鏡像的默認(rèn)后端是后端文件系統(tǒng)。這個簡單的后端會把鏡像文件寫到本地文件系統(tǒng)。l S3。該后端允許OpenStack Image Service存儲虛擬機鏡像在Amazon S3服務(wù)中。l HTTP。OpenStack Image Service能通過HTTP在Internet上讀取可用的虛擬機鏡像。這種存儲方式是只讀的。OpenStack Image Service registry servers是遵守OpenStack Image Service Registry API的服務(wù)器。根據(jù)安裝手冊，這兩個服務(wù)安裝在同一個服務(wù)器上。鏡像本身則可存儲在OpenStack Object Storage， Amazon39。s S3 infrastructure，fileSystem。如果你只需要只讀訪問，可以存儲在一臺Web服務(wù)器上。2. OpenStack Object Storage 關(guān)鍵概念216。 Accounts和 Account ServersOpenStack Object Storage系統(tǒng)被設(shè)計來供許多不同的存儲消費者或客戶使用。每個用戶必須通過認(rèn)證系統(tǒng)來識別自己。為此，OpenStack Object Storage提供了一個授權(quán)系統(tǒng)（swauth）。運行Account服務(wù)的結(jié)點與個體賬戶是不同的概念。Account服務(wù)器是存儲系統(tǒng)的部分，必須和Container服務(wù)器和Object服務(wù)器配置在一起。216。 Authentication 和 Access Permissions你必須通過認(rèn)證服務(wù)來認(rèn)證，以接收OpenStack Object Storage連接參數(shù)和認(rèn)證令牌。令牌必須為所有后面的container/object操作而傳遞。典型的，特定語言的API處理認(rèn)證，令牌傳遞和HTTPS request/response 通信。 通過運用XContainerRead: accountname和 XContainerWrite: accountname:username，你能為用戶或者賬戶對對象執(zhí)行訪問控制。比如，這個設(shè)置就允許來自accountname賬戶的的任意用戶來讀，但是只允許accountname賬戶里的用戶username來寫。你也能給OpenStack Object Storage中存儲的對象授予公共訪問的權(quán)限，而且可以通過Referer頭部阻止像熱鏈接這種基于站點的內(nèi)容盜竊，來限制公共訪問。公共的container設(shè)置被用作訪問控制列表之上的默認(rèn)授權(quán)。比如，XContainerRead: referer: any 這個設(shè)置，允許任何人能從container中讀，而不管其他的授權(quán)設(shè)置。 一般來說，每個用戶能完全訪問自己的存儲賬戶。用戶必須用他們的證書來認(rèn)證，一旦被認(rèn)證，他們就能創(chuàng)建或刪除container，以及賬戶之類的對象。一個用戶能訪問另一個賬戶的內(nèi)容的唯一方式是，他們享有一個API訪問key或你的認(rèn)證系統(tǒng)提供的會話令牌。216。 Containers and Objects一個Container是一個存儲隔間，為你提供一種組織屬于屬于你的數(shù)據(jù)的方式。它比較類似于文件夾或目錄。Container和其他文件系統(tǒng)概念的主要差異是containers不能嵌套。然而，你可以在你的賬戶內(nèi)創(chuàng)建無數(shù)的containers。但是你必須在你的賬戶上有一個container，因為數(shù)據(jù)必須存在Container中。 Container取名上的限制是，它們不能包含“/”，而且長度上少于256字節(jié)。長度的限制也適用于經(jīng)過URL編碼后的名字。比如，Course Docs的Container名經(jīng)過URL編碼后是“Course%20Docs”，因此此時的長度是13字節(jié)而非11字節(jié)。 一個對象是基本的存儲實體，和表示你存儲在OpenStack Object Storage系統(tǒng)中文件的任何可選的元數(shù)據(jù)。當(dāng)你上傳數(shù)據(jù)到OpenStack Object Storage，它原樣存儲，由一個位置（container），對象名，以及key/value對組成的任何元數(shù)據(jù)。比如，你可選擇存儲你數(shù)字照片的副本，把它們組織為一個影集。在這種情況下，每個對象可以用元數(shù)據(jù)Album :Caribbean Cruise 或Album : Aspen Ski Trip來標(biāo)記。 對象名上唯一的限制是，在經(jīng)過URL編碼后，它們的長度要少于1024個字節(jié)。 上傳的存儲對象的允許的最大大小5GB，最小是0字節(jié)。你能用內(nèi)嵌的大對象支持和St工具來檢索5GB以上的對象。對于元數(shù)據(jù)，每個對象不應(yīng)該超過90個key/value對，所有key/value對的總字節(jié)長度不應(yīng)該超過4KB。216。 Operations Operations是你在OpenStack Object Storage系統(tǒng)上執(zhí)行的行為，比如創(chuàng)建或刪除containers，上傳或下載objects等等。Operations的完全清單可以在開發(fā)文檔上找到。Operations能通過ReST web service API或特定語言的API來執(zhí)行。值得強調(diào)的是，所有操作必須包括一個來自你授權(quán)系統(tǒng)的有效的授權(quán)令牌。216。 特定語言的API綁定一些流行語言支持的API 綁定，在RackSpace云文件產(chǎn)品中是可用的。這些綁定在基礎(chǔ)ReST API上提供了一層抽象，允許變成人員直接與container和object模型打交道，而不是HTTP請求和響應(yīng)。這些綁定可免費下載，使用和修改。它們遵循MIT許可協(xié)議。對于OpenStack Object Storage，當(dāng)前支持的API綁定是：PHP，Python，Java，C/.NET 和Ruby。 Object Storage如何工作 u RingRing 代表磁盤上存儲的實體的名稱和它們的物理位置的映射。accounts, containers, and objects都有單獨的Ring。其他組件要在這三者之一進(jìn)行任何操作，他們都需要合相應(yīng)的Ring進(jìn)行交互以確定它在集群中的位置。Ring用zones，devices，partitions，和replicas來維護映射，在Ring中的每個分區(qū)都會在集群中默認(rèn)有三個副本。分區(qū)的位置存儲在Ring維護的映射中。Ring也負(fù)責(zé)確定失敗場景中接替的設(shè)備。（這點類似HDFS副本的復(fù)制）。分區(qū)的副本要保證存儲在不同的zone。Ring的分區(qū)分布在OpenStack Object Storage installation所有設(shè)備中。分區(qū)需要移動的時候，Ring確保一次移動最少的分區(qū)，一次僅有一個分區(qū)的副本被移動。權(quán)重能用來平衡分區(qū)在磁盤驅(qū)動上的分布。Ring在代理服務(wù)器和一些背景進(jìn)程中使用。u Proxy Server代理服務(wù)器負(fù)責(zé)將OpenStack Object Storage架構(gòu)中其他部分結(jié)合在一起。對于每次請求，它都查詢在Ring中查詢account, contai