OpenStack的架構
OpenStack是什麼
OpenStack既是一個社區,也是一個項目和一個開源軟件,它提供了一個部署雲的操作平臺或工具集。其宗旨在於,幫助組織運行爲虛擬計算或存儲服務的雲,爲公有云、私有云,也爲大雲、小云提供可擴展的、靈活的雲計算。
OpenStack旗下包含了一組由社區維護的開源項目,他們分別是OpenStack Compute(Nova),OpenStack Object Storage(Swift),以及OpenStack Image Service(Glance)。
OpenStack Compute[1],爲雲組織的控制器,它提供一個工具來部署雲,包括運行實例、管理網絡以及控制用戶和其他項目對雲的訪問(the cloud through users and projects)。它底層的開源項目名稱是Nova,其提供的軟件能控制IaaS雲計算平臺,類似於Amazon EC2和Rackspace Cloud Servers。實際上它定義的是,與運行在主機操作系統上潛在的虛擬化機制交互的驅動,暴露基於Web API的功能。
OpenStack Object Storage[2],是一個可擴展的對象存儲系統。對象存儲支持多種應用,比如複製和存檔數據,圖像或視頻服務,存儲次級靜態數據,開發數據存儲整合的新應用,存儲容量難以估計的數據,爲Web應用創建基於雲的彈性存儲。
OpenStack Image Service[1],是一個虛擬機鏡像的存儲、查詢和檢索系統,服務包括的RESTful API允許用戶通過HTTP請求查詢VM鏡像元數據,以及檢索實際的鏡像。VM鏡像有四種配置方式:簡單的文件系統,類似OpenStack Object Storage的對象存儲系統,直接用Amazon's Simple Storage Solution (S3) 存儲,用帶有Object Store的S3間接訪問S3。
三個項目的基本關係如下圖1-1所示:
1-1 OpenStack三個組件的關係
雲服務提供商的概念架構
OpenStack能幫我們建立自己的IaaS,提供類似Amazon Web Service的服務給客戶。爲實現這一點,我們需要提供幾個高級特性:
允許應用擁有者註冊雲服務,查看運用和計費情況;
允許Developers/DevOps folks創建和存儲他們應用的自定義鏡像;
允許他們啓動、監控和終止實例;
允許Cloud Operator配置和操作基礎架構
這四點都直擊提供IaaS的核心,現在假設你同意了這四個特性,現在就可以將它們放進如下所示的概念架構2-1中。
2-1 OpenStack 概念架構
在此模型中,作者假設了需要與雲交互的四個用戶集:developers, devops, owners and operators,併爲每類用戶劃分了他們所需要的功能。該架構採用的是非常普通的分層方法(presentation, logic and resources),它帶有兩個正交區域。
展示層,組件與用戶交互,接受和呈現信息。Web portals爲非開發者提供圖形界面,爲開發者提供API端點。如果是更復雜的結構,負載均衡,控制代理,安全和名稱服務也都會在這層。
邏輯層爲雲提供邏輯(intelligence)和控制功能。這層包括部署(複雜任務的工作流),調度(作業到資源的映射),策略(配額等等),鏡像註冊image registry (實例鏡像的元數據),日誌 (事件和計量) 。
假設絕大多數服務提供者已經有客戶身份和計費系統。任何雲架構都需要整合這些系統。
在任何複雜的環境下,我們都將需要一個management層來操作這個環境。它應該包括一個API訪問雲管理特性以及一些監控形式(forms)。很可能,監控功能將以整合的形式加入一個已存在的工具中。當前的架構中已經爲我們虛擬的服務提供商加入了monitoring和admin API,在更完全的架構中,你將見到一系列的支持功能,比如provisioning和 configuration management。
最後,資源層。既然這是一個compute雲,我們就需要實際的compute、network 和 storage資源,以供應給我們的客戶。該層提供這些服務,無論他們是服務器,網絡交換機,NAS(network attached storage)還是其他的一些資源。
OpenStack Compute架構
OpenStack Compute邏輯架構
OpenStack Compute邏輯架構中,組件中的絕大多數可分爲兩種自定義編寫的Python守護進程(custom written python daemons)。
接收和協調API調用的WSGI應用(nova-api, glance-api, etc)
執行部署任務的Worker守護進程(nova-compute, nova-network, nova-schedule, etc.)
然而,邏輯架構中有兩個重要的部分,既不是自定義編寫,也不是基於Python,它們是消息隊列和數據庫。二者簡化了複雜任務(通過消息傳遞和信息共享的任務)的異步部署。
邏輯架構圖3-1如下所示:
3-1 OpenStack Compute邏輯架構
從圖中,我們可以總結出三點:
終端用戶(DevOps, Developers 和其他的 OpenStack 組件)通過和nova-api對話來與OpenStack Compute交互。
OpenStack Compute守護進程之間通過隊列(行爲)和數據庫(信息)來交換信息,以執行API請求。
OpenStack Glance基本上是獨立的基礎架構,OpenStack Compute通過Glance API來和它交互。
其各個組件的情況如下:
nova-api守護進程是OpenStack Compute的中心。它爲所有API查詢(OpenStack API 或 EC2 API)提供端點,初始化絕大多數部署活動(比如運行實例),以及實施一些策略(絕大多數的配額檢查)。
nova-compute進程主要是一個創建和終止虛擬機實例的Worker守護進程。其過程相當複雜,但是基本原理很簡單:從隊列中接收行爲,然後在更新數據庫的狀態時,執行一系列的系統命令執行他們。
nova-volume管理映射到計算機實例的卷的創建、附加和取消。這些卷可以來自很多提供商,比如,ISCSI和AoE。
Nova-network worker守護進程類似於nova-compute和nova-volume。它從隊列中接收網絡任務,然後執行任務以操控網絡,比如創建bridging interfaces或改變iptables rules。
Queue提供中心hub,爲守護進程傳遞消息。當前用RabbitMQ實現。但是理論上能是python ampqlib支持的任何AMPQ消息隊列。
SQL database存儲雲基礎架構中的絕大多數編譯時和運行時狀態。這包括了可用的實例類型,在用的實例,可用的網絡和項目。理論上,OpenStack Compute能支持SQL-Alchemy支持的任何數據庫,但是當前廣泛使用的數據庫是sqlite3(僅適合測試和開發工作),MySQL和PostgreSQL。
OpenStack Glance,是一個單獨的項目,它是一個compute架構中可選的部分,分爲三個部分:glance-api, glance-registry and the image store. 其中,glance-api接受API調用,glance-registry負責存儲和檢索鏡像的元數據,實際的Image Blob存儲在Image Store中。Image Store可以是多種不同的Object Store,包括OpenStack Object Storage (Swift)
最後,user dashboard是另一個可選的項目。OpenStack Dashboard提供了一個OpenStack Compute界面來給應用開發者和devops staff類似API的功能。當前它是作爲Django web Application來實現的。當然,也有其他可用的Web前端。
概念映射
將邏輯架構映射到概念架構中(如3-2所示),可以看見我們還缺少什麼。
3-2 邏輯架構到概念架構的映射
這種覆蓋方式並不是唯一的,這裏的只是作者的理解。通過覆蓋OpenStack Compute 邏輯組件,Glance和Dashboard,來表示功能範圍。對於每一個覆蓋,都有相應的提供該功能的邏輯組件的名稱。
在這種覆蓋範圍中,最大的差距是logging和billing。此刻,OpenStack Compute沒有能協調logging事件、記錄日誌以及創建/呈現bills的Billing組件。真正的焦點是logging和Billing的整合。這能通過以下方式來補救。比如代碼擴充,商業產品或者服務或者自定義日誌解析的整合。
Identity也是未來可能要補充的一點。
customer portal也是一個整合點。user dashboard(見運行的實例,啓動新的實例)沒有提供一個界面,來允許應用擁有者簽署服務,跟蹤它們的費用以及聲明有問題的票據(lodge trouble tickets)。而且,這很可能對我們設想的服務提供商來說是合適的。
理想的情況是,Admin API會複製我們能通過命令行接口做的所有功能。在帶有Admin API work的Diablo 發佈中會更好。
雲監控和操作將是服務提供商關注的重點。好操作方法的關鍵是好的工具。當前,OpenStack Compute 提供 nova-instancemonitor,它跟蹤計算結點使用情況。未來我們還需要三方工具來監控。
Policy是極其重要的方面,但是會與供應商很相關。從quotas到QoS,到隱私控制都在其管轄內。當前圖上有部分覆蓋,但是這取決於供應商的複雜需求。爲準確起見,OpenStack Compute 爲實例,浮點IP地址以及元數據提供配額。
當前,OpenStack Compute內的Scheduling對於大的安裝來說是相當初步的。調度器是以插件的方式設計的,目前支持chance(隨機主機分配),simple(最少負載)和zone(在一個可用區域裏的隨機結點。)分佈式的調度器和理解異構主機的調度器正在開發之中。
如你所見,OpenStack Compute爲我們想象的服務提供商,提供了一個不錯的基礎,只要服務提供商願意做一些整合。
OpenStack Compute系統架構
OpenStack Compute由一些主要組件組成。“Cloud controller”包含很多組件,它表示全局狀態,以及與其他組件交互。實際上,它提供的是Nova-api服務。它的功能是:爲所有API查詢提供一個端點,初始化絕大多數的部署活動,以及實施一些策略。API 服務器起cloud controller web Service前端的作用。Compute controller 提供compute服務資源,典型包含compute service,Object Store component可選地提供存儲服務。Auth manager提供認證和授權服務,Volume controller爲compute servers提供快速和持久的塊級別存儲。Network controller提供虛擬網絡使compute servers彼此交互以及與公網進行交互。Scheduler選擇最合適的compute controller來管理(host)一個實例。
OpenStack Compute建立在無共享、基於消息的架構上。Cloud controller通過HTTP與internal object store交互,通過AMQP和scheduler、network controller、 和volume controller 來進行通信。爲了避免在等待接收時阻塞每個組件,OpenStack Compute用異步調用的方式。
爲了獲得帶有一個組件多個備份的無共享屬性,OpenStack Compute將所有的雲系統狀態保持在分佈式的數據存儲中。對系統狀態的更新會寫到這個存儲中,必要時用質子事務。
對系統狀態的請求會從store中讀出。在少數情況下,控制器也會短時間緩存讀取結果。
OpenStack Compute物理架構
OpenStack Compute採用無共享、基於消息的架構,非常靈活,我們能安裝每個nova- service在單獨的服務器上,這意味着安裝OpenStack Compute有多種可能的方法。可能多結點部署唯一的聯合依賴性,是Dashboard必須被安裝在nova-api服務器。幾種部署架構如下:
單結點:一臺服務器運行所有的nova- services,同時也驅動虛擬實例。這種配置只爲嘗試OpenStack Compute,或者爲了開發目的;
雙結點:一個cloud controller 結點運行除nova-compute外的所有nova-services,compute結點運行nova-compute。一臺客戶計算機很可能需要打包鏡像,以及和服務器進行交互,但是並不是必要的。這種配置主要用於概念和開發環境的證明。
多結點:通過簡單部署nova-compute在一臺額外的服務器以及拷貝nova.conf文件到這個新增的結點,你能在兩結點的基礎上,添加更多的compute結點,形成多結點部署。在較爲複雜的多結點部署中,還能增加一個volume controller 和一個network controller作爲額外的結點。對於運行多個需要大量處理能力的虛擬機實例,至少是4個結點是最好的。
一個可能的Openstack Compute多服務器部署(集羣中聯網的虛擬服務器可能會改變)如下3-3所示:
3-3 OpenStack Compute物理架構一
如果你注意到消息隊列中大量的複製引發了性能問題,一種可選的架構是增加更多的Messaging服務器。在這種情形下,除了可以擴展數據庫服務器外,還可以增加一臺額外的RabbitMQ服務器。部署中可以在任意服務器上運行任意nova-service,只要nova.conf中配置爲指向RabbitMQ服務器,並且這些服務器能發送消息到它。
下圖3-4是另外一種多結點的部署架構。
3-4 多結點的部署架構二
OpenStack Compute服務架構
因爲Compute有多個服務,也可能有多種配置,下圖3-5顯示了總體的服務架構,以及服務之間的通信系統。
3-5 OpenStack Compute服務架構
OpenStack Image Service
OpenStack Image Service包括兩個主要的部分,分別是API server和Registry server(s)。
OpenStack Image Service的設計,儘可能適合各種後端倉儲和註冊數據庫方案。API Server(運行“glance api”程序)起通信hub的作用。比如各種各樣的客戶程序,鏡像元數據的註冊,實際包含虛擬機鏡像數據的存儲系統,都是通過它來進行通信的。API server轉發客戶端的請求到鏡像元數據註冊處和它的後端倉儲。OpenStack Image Service就是通過這些機制來實際保存進來的虛擬機鏡像的。
OpenStack Image Service支持的後端倉儲有:
OpenStack Object Storage。它是OpenStack中高可用的對象存儲項目。
FileSystem。OpenStack Image Service存儲虛擬機鏡像的默認後端是後端文件系統。這個簡單的後端會把鏡像文件寫到本地文件系統。
S3。該後端允許OpenStack Image Service存儲虛擬機鏡像在Amazon S3服務中。
HTTP。OpenStack Image Service能通過HTTP在Internet上讀取可用的虛擬機鏡像。這種存儲方式是隻讀的。
OpenStack Image Service registry servers是遵守OpenStack Image Service Registry API的服務器。
根據安裝手冊,這兩個服務安裝在同一個服務器上。鏡像本身則可存儲在OpenStack Object Storage, Amazon's S3 infrastructure,fileSystem。如果你只需要只讀訪問,可以存儲在一臺Web服務器上。
OpenStack Object Storage
關鍵概念
Accounts和 Account Servers
OpenStack Object Storage系統被設計來供許多不同的存儲消費者或客戶使用。每個用戶必須通過認證系統來識別自己。爲此,OpenStack Object Storage提供了一個授權系統(swauth)。
運行Account服務的結點與個體賬戶是不同的概念。Account服務器是存儲系統的部分,必須和Container服務器和Object服務器配置在一起。
Authentication 和 Access Permissions
你必須通過認證服務來認證,以接收OpenStack Object Storage連接參數和認證令牌。令牌必須爲所有後面的container/object操作而傳遞。典型的,特定語言的API處理認證,令牌傳遞和HTTPS request/response 通信。
通過運用X-Container-Read: accountname和 X-Container-Write: accountname:username,你能爲用戶或者賬戶對對象執行訪問控制。比如,這個設置就允許來自accountname賬戶的的任意用戶來讀,但是隻允許accountname賬戶裏的用戶username來寫。你也能給OpenStack Object Storage中存儲的對象授予公共訪問的權限,而且可以通過Referer頭部阻止像熱鏈接這種基於站點的內容盜竊,來限制公共訪問。公共的container設置被用作訪問控制列表之上的默認授權。比如,X-Container-Read: referer: any 這個設置,允許任何人能從container中讀,而不管其他的授權設置。
一般來說,每個用戶能完全訪問自己的存儲賬戶。用戶必須用他們的證書來認證,一旦被認證,他們就能創建或刪除container,以及賬戶之類的對象。一個用戶能訪問另一個賬戶的內容的唯一方式是,他們享有一個API訪問key或你的認證系統提供的會話令牌。
Containers and Objects
一個Container是一個存儲隔間,爲你提供一種組織屬於屬於你的數據的方式。它比較類似於文件夾或目錄。Container和其他文件系統概念的主要差異是containers不能嵌套。然而,你可以在你的賬戶內創建無數的containers。但是你必須在你的賬戶上有一個container,因爲數據必須存在Container中。
Container取名上的限制是,它們不能包含“/”,而且長度上少於256字節。長度的限制也適用於經過URL編碼後的名字。比如,Course Docs的Container名經過URL編碼後是“Course%20Docs”,因此此時的長度是13字節而非11字節。
一個對象是基本的存儲實體,和表示你存儲在OpenStack Object Storage系統中文件的任何可選的元數據。當你上傳數據到OpenStack Object Storage,它原樣存儲,由一個位置(container),對象名,以及key/value對組成的任何元數據。比如,你可選擇存儲你數字照片的副本,把它們組織爲一個影集。在這種情況下,每個對象可以用元數據Album :
Caribbean Cruise 或Album : Aspen Ski Trip來標記。
對象名上唯一的限制是,在經過URL編碼後,它們的長度要少於1024個字節。
上傳的存儲對象的允許的最大大小5GB,最小是0字節。你能用內嵌的大對象支持和St工具來檢索5GB以上的對象。對於元數據,每個對象不應該超過90個key/value對,所有key/value對的總字節長度不應該超過4KB。
Operations
Operations是你在OpenStack Object Storage系統上執行的行爲,比如創建或刪除containers,上傳或下載objects等等。Operations的完全清單可以在開發文檔上找到。Operations能通過ReST web service API或特定語言的API來執行。值得強調的是,所有操作必須包括一個來自你授權系統的有效的授權令牌。
特定語言的API綁定
一些流行語言支持的API 綁定,在RackSpace雲文件產品中是可用的。這些綁定在基礎ReST API上提供了一層抽象,允許變成人員直接與container和object模型打交道,而不是HTTP請求和響應。這些綁定可免費下載,使用和修改。它們遵循MIT許可協議。對於OpenStack Object Storage,當前支持的API綁定是:PHP,Python,Java,C#/.NET 和Ruby。
Object Storage如何工作
Ring
Ring 代表磁盤上存儲的實體的名稱和它們的物理位置的映射。accounts, containers, and objects都有單獨的Ring。其他組件要在這三者之一進行任何操作,他們都需要合相應的Ring進行交互以確定它在集羣中的位置。
Ring用zones,devices,partitions,和replicas來維護映射,在Ring中的每個分區都會在集羣中默認有三個副本。分區的位置存儲在Ring維護的映射中。Ring也負責確定失敗場景中接替的設備。(這點類似HDFS副本的複製)。分區的副本要保證存儲在不同的zone。Ring的分區分佈在OpenStack Object Storage installation所有設備中。分區需要移動的時候,Ring確保一次移動最少的分區,一次僅有一個分區的副本被移動。
權重能用來平衡分區在磁盤驅動上的分佈。Ring在代理服務器和一些背景進程中使用。
Proxy Server
代理服務器負責將OpenStack Object Storage架構中其他部分結合在一起。對於每次請求,它都查詢在Ring中查詢account, container, or object的位置,並以此轉發請求。公有APIs也是通過代理服務器來暴露的。
大量的失敗也是由代理服務器來進行處理。比如一個服務器不可用,它就會要求Ring來爲它找下一個接替的服務器,並把請求轉發到那裏。
當對象流進或流出object server時,它們都通過代理服務器來流給用戶,或者通過它從用戶獲取。代理服務器不會緩衝它們。
Proxy服務器的功能可以總結爲:查詢位置,處理失敗,中轉對象。
Object Server
Object Server,是非常簡單的blob存儲服務器,能存儲、檢索和刪除本地磁盤上的對象,它以二進制文件形式存放在文件系統中,元數據以文件的擴展屬性存放。
對象以源於對象名的hash和操作的時間戳的路徑來存放。上一次寫總會成功,確保最新的版本將被使用。刪除也視作文件的一個版本:這確保刪除的文件也被正確複製,更舊的把本不會因爲失敗情形離奇消失。
Container Server
其主要工作是處理對象列表,它不知道對象在哪裏,只是知道哪些對象在一個特定的container。列表被存儲爲sqlite 數據庫文件,類似對象的方式在集羣中複製。也進行了跟蹤統計,包括對象的總數,以及container中使用的總存儲量。
Account Server
它是類似於Container Server,除了它是負責containers的列表而非對象。
Replication
設計副本的目的是,在面臨網絡中斷或驅動失敗等臨時錯誤條件時,保持系統在一致的狀態。
副本進程會比較本地的數據和每個遠處的副本,以確保他們所有都包含最新的版本。對象副本用一個Hash列表來快速比較每個分區的片段,而containe和 account replication 用的是Hash和共享的高水印結合的方法。
副本的更新,是基於推送的。對於對象副本,更新是遠程同步文件到Peer。Account和container replication通過HTTP or rsync把整個數據庫文件推送遺失的記錄。
副本也通過tombstone設置最新版本的方式,確保數據從系統中清除。
更新器(Updaters)
有時,container 或 account數據不能被立即更新,這通常是發生在失敗的情形或高負載時期。如果一個更新失敗,該更新會在文件系統上本地排隊,更新器將處理這些失敗的更新。事件一致性窗口(eventual consistency window)最可能來起作用。比如,假設一個container服務器正處於載入之中,一個新對象正被放進系統,代理服務器一響應客戶端成功,該對象就立即可讀了。然而,container服務器沒有更新Object列表,所以更新就進入隊列,以等待稍後的更新。Container列表,因此可能還不會立即包含這個對象。
實際上,一致性窗口只是與updater運行的頻率一樣大,當代理服務器將轉發清單請求到響應的第一個container服務器中,也許甚至還不會被注意。在載入之下的服務器可能還不是服務後續清單請求的那個。另外兩個副本中的一個可能處理這個清單。
Auditors
Auditors會檢查objects, containers, 和 accounts的完整性。如果發先損壞的文件,它將被隔離,好的副本將會取代這個壞的文件。如果發現其他的錯誤,它們會記入到日誌中。
OpenStack Object Storage物理架構
Proxy Services 偏向於CPU和network I/O 密集型,而 Object Services, Container Services, Account Services 偏向於disk and networkI/O 密集型。
可以在每一服務器上安裝所有的服務,在Rackspace內部, 他們將Proxy Services放在他們自己的服務器上,而所有存儲服務則放在同一服務器上。這允許我們發送10G的網絡給代理,1G給存儲服務器,從而保持對代理服務器的負載平衡更好管理。我們能通過增加更多代理來擴展整個API吞吐量。如果需要獲得Account或 Container Services更
OpenStack的架構
OpenStack是什麼
OpenStack既是一個社區,也是一個項目和一個開源軟件,它提供了一個部署雲的操作平臺或工具集。其宗旨在於,幫助組織運行爲虛擬計算或存儲服務的雲,爲公有云、私有云,也爲大雲、小云提供可擴展的、靈活的雲計算。
OpenStack旗下包含了一組由社區維護的開源項目,他們分別是OpenStack Compute(Nova),OpenStack Object Storage(Swift),以及OpenStack Image Service(Glance)。
OpenStack Compute[1],爲雲組織的控制器,它提供一個工具來部署雲,包括運行實例、管理網絡以及控制用戶和其他項目對雲的訪問(the cloud through users and projects)。它底層的開源項目名稱是Nova,其提供的軟件能控制IaaS雲計算平臺,類似於Amazon EC2和Rackspace Cloud Servers。實際上它定義的是,與運行在主機操作系統上潛在的虛擬化機制交互的驅動,暴露基於Web API的功能。
OpenStack Object Storage[2],是一個可擴展的對象存儲系統。對象存儲支持多種應用,比如複製和存檔數據,圖像或視頻服務,存儲次級靜態數據,開發數據存儲整合的新應用,存儲容量難以估計的數據,爲Web應用創建基於雲的彈性存儲。
OpenStack Image Service[1],是一個虛擬機鏡像的存儲、查詢和檢索系統,服務包括的RESTful API允許用戶通過HTTP請求查詢VM鏡像元數據,以及檢索實際的鏡像。VM鏡像有四種配置方式:簡單的文件系統,類似OpenStack Object Storage的對象存儲系統,直接用Amazon's Simple Storage Solution (S3) 存儲,用帶有Object Store的S3間接訪問S3。
三個項目的基本關係如下圖1-1所示:
1-1 OpenStack三個組件的關係
雲服務提供商的概念架構
OpenStack能幫我們建立自己的IaaS,提供類似Amazon Web Service的服務給客戶。爲實現這一點,我們需要提供幾個高級特性:
允許應用擁有者註冊雲服務,查看運用和計費情況;
允許Developers/DevOps folks創建和存儲他們應用的自定義鏡像;
允許他們啓動、監控和終止實例;
允許Cloud Operator配置和操作基礎架構
這四點都直擊提供IaaS的核心,現在假設你同意了這四個特性,現在就可以將它們放進如下所示的概念架構2-1中。
2-1 OpenStack 概念架構
在此模型中,作者假設了需要與雲交互的四個用戶集:developers, devops, owners and operators,併爲每類用戶劃分了他們所需要的功能。該架構採用的是非常普通的分層方法(presentation, logic and resources),它帶有兩個正交區域。
展示層,組件與用戶交互,接受和呈現信息。Web portals爲非開發者提供圖形界面,爲開發者提供API端點。如果是更復雜的結構,負載均衡,控制代理,安全和名稱服務也都會在這層。
邏輯層爲雲提供邏輯(intelligence)和控制功能。這層包括部署(複雜任務的工作流),調度(作業到資源的映射),策略(配額等等),鏡像註冊image registry (實例鏡像的元數據),日誌 (事件和計量) 。
假設絕大多數服務提供者已經有客戶身份和計費系統。任何雲架構都需要整合這些系統。
在任何複雜的環境下,我們都將需要一個management層來操作這個環境。它應該包括一個API訪問雲管理特性以及一些監控形式(forms)。很可能,監控功能將以整合的形式加入一個已存在的工具中。當前的架構中已經爲我們虛擬的服務提供商加入了monitoring和admin API,在更完全的架構中,你將見到一系列的支持功能,比如provisioning和 configuration management。
最後,資源層。既然這是一個compute雲,我們就需要實際的compute、network 和 storage資源,以供應給我們的客戶。該層提供這些服務,無論他們是服務器,網絡交換機,NAS(network attached storage)還是其他的一些資源。
OpenStack Compute架構
OpenStack Compute邏輯架構
OpenStack Compute邏輯架構中,組件中的絕大多數可分爲兩種自定義編寫的Python守護進程(custom written python daemons)。
接收和協調API調用的WSGI應用(nova-api, glance-api, etc)
執行部署任務的Worker守護進程(nova-compute, nova-network, nova-schedule, etc.)
然而,邏輯架構中有兩個重要的部分,既不是自定義編寫,也不是基於Python,它們是消息隊列和數據庫。二者簡化了複雜任務(通過消息傳遞和信息共享的任務)的異步部署。
邏輯架構圖3-1如下所示:
3-1 OpenStack Compute邏輯架構
從圖中,我們可以總結出三點:
終端用戶(DevOps, Developers 和其他的 OpenStack 組件)通過和nova-api對話來與OpenStack Compute交互。
OpenStack Compute守護進程之間通過隊列(行爲)和數據庫(信息)來交換信息,以執行API請求。
OpenStack Glance基本上是獨立的基礎架構,OpenStack Compute通過Glance API來和它交互。
其各個組件的情況如下:
nova-api守護進程是OpenStack Compute的中心。它爲所有API查詢(OpenStack API 或 EC2 API)提供端點,初始化絕大多數部署活動(比如運行實例),以及實施一些策略(絕大多數的配額檢查)。
nova-compute進程主要是一個創建和終止虛擬機實例的Worker守護進程。其過程相當複雜,但是基本原理很簡單:從隊列中接收行爲,然後在更新數據庫的狀態時,執行一系列的系統命令執行他們。
nova-volume管理映射到計算機實例的卷的創建、附加和取消。這些卷可以來自很多提供商,比如,ISCSI和AoE。
Nova-network worker守護進程類似於nova-compute和nova-volume。它從隊列中接收網絡任務,然後執行任務以操控網絡,比如創建bridging interfaces或改變iptables rules。
Queue提供中心hub,爲守護進程傳遞消息。當前用RabbitMQ實現。但是理論上能是python ampqlib支持的任何AMPQ消息隊列。
SQL database存儲雲基礎架構中的絕大多數編譯時和運行時狀態。這包括了可用的實例類型,在用的實例,可用的網絡和項目。理論上,OpenStack Compute能支持SQL-Alchemy支持的任何數據庫,但是當前廣泛使用的數據庫是sqlite3(僅適合測試和開發工作),MySQL和PostgreSQL。
OpenStack Glance,是一個單獨的項目,它是一個compute架構中可選的部分,分爲三個部分:glance-api, glance-registry and the image store. 其中,glance-api接受API調用,glance-registry負責存儲和檢索鏡像的元數據,實際的Image Blob存儲在Image Store中。Image Store可以是多種不同的Object Store,包括OpenStack Object Storage (Swift)
最後,user dashboard是另一個可選的項目。OpenStack Dashboard提供了一個OpenStack Compute界面來給應用開發者和devops staff類似API的功能。當前它是作爲Django web Application來實現的。當然,也有其他可用的Web前端。
概念映射
將邏輯架構映射到概念架構中(如3-2所示),可以看見我們還缺少什麼。
3-2 邏輯架構到概念架構的映射
這種覆蓋方式並不是唯一的,這裏的只是作者的理解。通過覆蓋OpenStack Compute 邏輯組件,Glance和Dashboard,來表示功能範圍。對於每一個覆蓋,都有相應的提供該功能的邏輯組件的名稱。
在這種覆蓋範圍中,最大的差距是logging和billing。此刻,OpenStack Compute沒有能協調logging事件、記錄日誌以及創建/呈現bills的Billing組件。真正的焦點是logging和Billing的整合。這能通過以下方式來補救。比如代碼擴充,商業產品或者服務或者自定義日誌解析的整合。
Identity也是未來可能要補充的一點。
customer portal也是一個整合點。user dashboard(見運行的實例,啓動新的實例)沒有提供一個界面,來允許應用擁有者簽署服務,跟蹤它們的費用以及聲明有問題的票據(lodge trouble tickets)。而且,這很可能對我們設想的服務提供商來說是合適的。
理想的情況是,Admin API會複製我們能通過命令行接口做的所有功能。在帶有Admin API work的Diablo 發佈中會更好。
雲監控和操作將是服務提供商關注的重點。好操作方法的關鍵是好的工具。當前,OpenStack Compute 提供 nova-instancemonitor,它跟蹤計算結點使用情況。未來我們還需要三方工具來監控。
Policy是極其重要的方面,但是會與供應商很相關。從quotas到QoS,到隱私控制都在其管轄內。當前圖上有部分覆蓋,但是這取決於供應商的複雜需求。爲準確起見,OpenStack Compute 爲實例,浮點IP地址以及元數據提供配額。
當前,OpenStack Compute內的Scheduling對於大的安裝來說是相當初步的。調度器是以插件的方式設計的,目前支持chance(隨機主機分配),simple(最少負載)和zone(在一個可用區域裏的隨機結點。)分佈式的調度器和理解異構主機的調度器正在開發之中。
如你所見,OpenStack Compute爲我們想象的服務提供商,提供了一個不錯的基礎,只要服務提供商願意做一些整合。
OpenStack Compute系統架構
OpenStack Compute由一些主要組件組成。“Cloud controller”包含很多組件,它表示全局狀態,以及與其他組件交互。實際上,它提供的是Nova-api服務。它的功能是:爲所有API查詢提供一個端點,初始化絕大多數的部署活動,以及實施一些策略。API 服務器起cloud controller web Service前端的作用。Compute controller 提供compute服務資源,典型包含compute service,Object Store component可選地提供存儲服務。Auth manager提供認證和授權服務,Volume controller爲compute servers提供快速和持久的塊級別存儲。Network controller提供虛擬網絡使compute servers彼此交互以及與公網進行交互。Scheduler選擇最合適的compute controller來管理(host)一個實例。
OpenStack Compute建立在無共享、基於消息的架構上。Cloud controller通過HTTP與internal object store交互,通過AMQP和scheduler、network controller、 和volume controller 來進行通信。爲了避免在等待接收時阻塞每個組件,OpenStack Compute用異步調用的方式。
爲了獲得帶有一個組件多個備份的無共享屬性,OpenStack Compute將所有的雲系統狀態保持在分佈式的數據存儲中。對系統狀態的更新會寫到這個存儲中,必要時用質子事務。
對系統狀態的請求會從store中讀出。在少數情況下,控制器也會短時間緩存讀取結果。
OpenStack Compute物理架構
OpenStack Compute採用無共享、基於消息的架構,非常靈活,我們能安裝每個nova- service在單獨的服務器上,這意味着安裝OpenStack Compute有多種可能的方法。可能多結點部署唯一的聯合依賴性,是Dashboard必須被安裝在nova-api服務器。幾種部署架構如下:
單結點:一臺服務器運行所有的nova- services,同時也驅動虛擬實例。這種配置只爲嘗試OpenStack Compute,或者爲了開發目的;
雙結點:一個cloud controller 結點運行除nova-compute外的所有nova-services,compute結點運行nova-compute。一臺客戶計算機很可能需要打包鏡像,以及和服務器進行交互,但是並不是必要的。這種配置主要用於概念和開發環境的證明。
多結點:通過簡單部署nova-compute在一臺額外的服務器以及拷貝nova.conf文件到這個新增的結點,你能在兩結點的基礎上,添加更多的compute結點,形成多結點部署。在較爲複雜的多結點部署中,還能增加一個volume controller 和一個network controller作爲額外的結點。對於運行多個需要大量處理能力的虛擬機實例,至少是4個結點是最好的。
一個可能的Openstack Compute多服務器部署(集羣中聯網的虛擬服務器可能會改變)如下3-3所示:
3-3 OpenStack Compute物理架構一
如果你注意到消息隊列中大量的複製引發了性能問題,一種可選的架構是增加更多的Messaging服務器。在這種情形下,除了可以擴展數據庫服務器外,還可以增加一臺額外的RabbitMQ服務器。部署中可以在任意服務器上運行任意nova-service,只要nova.conf中配置爲指向RabbitMQ服務器,並且這些服務器能發送消息到它。
下圖3-4是另外一種多結點的部署架構。
3-4 多結點的部署架構二
OpenStack Compute服務架構
因爲Compute有多個服務,也可能有多種配置,下圖3-5顯示了總體的服務架構,以及服務之間的通信系統。
3-5 OpenStack Compute服務架構
OpenStack Image Service
OpenStack Image Service包括兩個主要的部分,分別是API server和Registry server(s)。
OpenStack Image Service的設計,儘可能適合各種後端倉儲和註冊數據庫方案。API Server(運行“glance api”程序)起通信hub的作用。比如各種各樣的客戶程序,鏡像元數據的註冊,實際包含虛擬機鏡像數據的存儲系統,都是通過它來進行通信的。API server轉發客戶端的請求到鏡像元數據註冊處和它的後端倉儲。OpenStack Image Service就是通過這些機制來實際保存進來的虛擬機鏡像的。
OpenStack Image Service支持的後端倉儲有:
OpenStack Object Storage。它是OpenStack中高可用的對象存儲項目。
FileSystem。OpenStack Image Service存儲虛擬機鏡像的默認後端是後端文件系統。這個簡單的後端會把鏡像文件寫到本地文件系統。
S3。該後端允許OpenStack Image Service存儲虛擬機鏡像在Amazon S3服務中。
HTTP。OpenStack Image Service能通過HTTP在Internet上讀取可用的虛擬機鏡像。這種存儲方式是隻讀的。
OpenStack Image Service registry servers是遵守OpenStack Image Service Registry API的服務器。
根據安裝手冊,這兩個服務安裝在同一個服務器上。鏡像本身則可存儲在OpenStack Object Storage, Amazon's S3 infrastructure,fileSystem。如果你只需要只讀訪問,可以存儲在一臺Web服務器上。
OpenStack Object Storage
關鍵概念
Accounts和 Account Servers
OpenStack Object Storage系統被設計來供許多不同的存儲消費者或客戶使用。每個用戶必須通過認證系統來識別自己。爲此,OpenStack Object Storage提供了一個授權系統(swauth)。
運行Account服務的結點與個體賬戶是不同的概念。Account服務器是存儲系統的部分,必須和Container服務器和Object服務器配置在一起。
Authentication 和 Access Permissions
你必須通過認證服務來認證,以接收OpenStack Object Storage連接參數和認證令牌。令牌必須爲所有後面的container/object操作而傳遞。典型的,特定語言的API處理認證,令牌傳遞和HTTPS request/response 通信。
通過運用X-Container-Read: accountname和 X-Container-Write: accountname:username,你能爲用戶或者賬戶對對象執行訪問控制。比如,這個設置就允許來自accountname賬戶的的任意用戶來讀,但是隻允許accountname賬戶裏的用戶username來寫。你也能給OpenStack Object Storage中存儲的對象授予公共訪問的權限,而且可以通過Referer頭部阻止像熱鏈接這種基於站點的內容盜竊,來限制公共訪問。公共的container設置被用作訪問控制列表之上的默認授權。比如,X-Container-Read: referer: any 這個設置,允許任何人能從container中讀,而不管其他的授權設置。
一般來說,每個用戶能完全訪問自己的存儲賬戶。用戶必須用他們的證書來認證,一旦被認證,他們就能創建或刪除container,以及賬戶之類的對象。一個用戶能訪問另一個賬戶的內容的唯一方式是,他們享有一個API訪問key或你的認證系統提供的會話令牌。
Containers and Objects
一個Container是一個存儲隔間,爲你提供一種組織屬於屬於你的數據的方式。它比較類似於文件夾或目錄。Container和其他文件系統概念的主要差異是containers不能嵌套。然而,你可以在你的賬戶內創建無數的containers。但是你必須在你的賬戶上有一個container,因爲數據必須存在Container中。
Container取名上的限制是,它們不能包含“/”,而且長度上少於256字節。長度的限制也適用於經過URL編碼後的名字。比如,Course Docs的Container名經過URL編碼後是“Course%20Docs”,因此此時的長度是13字節而非11字節。
一個對象是基本的存儲實體,和表示你存儲在OpenStack Object Storage系統中文件的任何可選的元數據。當你上傳數據到OpenStack Object Storage,它原樣存儲,由一個位置(container),對象名,以及key/value對組成的任何元數據。比如,你可選擇存儲你數字照片的副本,把它們組織爲一個影集。在這種情況下,每個對象可以用元數據Album :
Caribbean Cruise 或Album : Aspen Ski Trip來標記。
對象名上唯一的限制是,在經過URL編碼後,它們的長度要少於1024個字節。
上傳的存儲對象的允許的最大大小5GB,最小是0字節。你能用內嵌的大對象支持和St工具來檢索5GB以上的對象。對於元數據,每個對象不應該超過90個key/value對,所有key/value對的總字節長度不應該超過4KB。
Operations
Operations是你在OpenStack Object Storage系統上執行的行爲,比如創建或刪除containers,上傳或下載objects等等。Operations的完全清單可以在開發文檔上找到。Operations能通過ReST web service API或特定語言的API來執行。值得強調的是,所有操作必須包括一個來自你授權系統的有效的授權令牌。
特定語言的API綁定
一些流行語言支持的API 綁定,在RackSpace雲文件產品中是可用的。這些綁定在基礎ReST API上提供了一層抽象,允許變成人員直接與container和object模型打交道,而不是HTTP請求和響應。這些綁定可免費下載,使用和修改。它們遵循MIT許可協議。對於OpenStack Object Storage,當前支持的API綁定是:PHP,Python,Java,C#/.NET 和Ruby。
Object Storage如何工作
Ring
Ring 代表磁盤上存儲的實體的名稱和它們的物理位置的映射。accounts, containers, and objects都有單獨的Ring。其他組件要在這三者之一進行任何操作,他們都需要合相應的Ring進行交互以確定它在集羣中的位置。
Ring用zones,devices,partitions,和replicas來維護映射,在Ring中的每個分區都會在集羣中默認有三個副本。分區的位置存儲在Ring維護的映射中。Ring也負責確定失敗場景中接替的設備。(這點類似HDFS副本的複製)。分區的副本要保證存儲在不同的zone。Ring的分區分佈在OpenStack Object Storage installation所有設備中。分區需要移動的時候,Ring確保一次移動最少的分區,一次僅有一個分區的副本被移動。
權重能用來平衡分區在磁盤驅動上的分佈。Ring在代理服務器和一些背景進程中使用。
Proxy Server
代理服務器負責將OpenStack Object Storage架構中其他部分結合在一起。對於每次請求,它都查詢在Ring中查詢account, container, or object的位置,並以此轉發請求。公有APIs也是通過代理服務器來暴露的。
大量的失敗也是由代理服務器來進行處理。比如一個服務器不可用,它就會要求Ring來爲它找下一個接替的服務器,並把請求轉發到那裏。
當對象流進或流出object server時,它們都通過代理服務器來流給用戶,或者通過它從用戶獲取。代理服務器不會緩衝它們。
Proxy服務器的功能可以總結爲:查詢位置,處理失敗,中轉對象。
Object Server
Object Server,是非常簡單的blob存儲服務器,能存儲、檢索和刪除本地磁盤上的對象,它以二進制文件形式存放在文件系統中,元數據以文件的擴展屬性存放。
對象以源於對象名的hash和操作的時間戳的路徑來存放。上一次寫總會成功,確保最新的版本將被使用。刪除也視作文件的一個版本:這確保刪除的文件也被正確複製,更舊的把本不會因爲失敗情形離奇消失。
Container Server
其主要工作是處理對象列表,它不知道對象在哪裏,只是知道哪些對象在一個特定的container。列表被存儲爲sqlite 數據庫文件,類似對象的方式在集羣中複製。也進行了跟蹤統計,包括對象的總數,以及container中使用的總存儲量。
Account Server
它是類似於Container Server,除了它是負責containers的列表而非對象。
Replication
設計副本的目的是,在面臨網絡中斷或驅動失敗等臨時錯誤條件時,保持系統在一致的狀態。
副本進程會比較本地的數據和每個遠處的副本,以確保他們所有都包含最新的版本。對象副本用一個Hash列表來快速比較每個分區的片段,而containe和 account replication 用的是Hash和共享的高水印結合的方法。
副本的更新,是基於推送的。對於對象副本,更新是遠程同步文件到Peer。Account和container replication通過HTTP or rsync把整個數據庫文件推送遺失的記錄。
副本也通過tombstone設置最新版本的方式,確保數據從系統中清除。
更新器(Updaters)
有時,container 或 account數據不能被立即更新,這通常是發生在失敗的情形或高負載時期。如果一個更新失敗,該更新會在文件系統上本地排隊,更新器將處理這些失敗的更新。事件一致性窗口(eventual consistency window)最可能來起作用。比如,假設一個container服務器正處於載入之中,一個新對象正被放進系統,代理服務器一響應客戶端成功,該對象就立即可讀了。然而,container服務器沒有更新Object列表,所以更新就進入隊列,以等待稍後的更新。Container列表,因此可能還不會立即包含這個對象。
實際上,一致性窗口只是與updater運行的頻率一樣大,當代理服務器將轉發清單請求到響應的第一個container服務器中,也許甚至還不會被注意。在載入之下的服務器可能還不是服務後續清單請求的那個。另外兩個副本中的一個可能處理這個清單。
Auditors
Auditors會檢查objects, containers, 和 accounts的完整性。如果發先損壞的文件,它將被隔離,好的副本將會取代這個壞的文件。如果發現其他的錯誤,它們會記入到日誌中。
OpenStack Object Storage物理架構
Proxy Services 偏向於CPU和network I/O 密集型,而 Object Services, Container Services, Account Services 偏向於disk and networkI/O 密集型。
可以在每一服務器上安裝所有的服務,在Rackspace內部, 他們將Proxy Services放在他們自己的服務器上,而所有存儲服務則放在同一服務器上。這允許我們發送10G的網絡給代理,1G給存儲服務器,從而保持對代理服務器的負載平衡更好管理。我們能通過增加更多代理來擴展整個API吞吐量。如果需要獲得Account或 Container Services更大的吞吐量,它們也可以部署到自己的服務器上。
在部署OpenStack Object Storage時,可以單結點安裝,但是它只適用於開發和測試目的。也可以多服務器的安裝,它能獲得分佈式對象存儲系統需要的高可用性和冗餘。
有這樣一個樣本部署架構,如圖5-1所示。一個Proxy 結點,運行代理服務,一個Auth 結點,運行認證服務,五個Storage結點,運行Account,Container和Object服務。
5-1 五個Storage結點的OpenStack Object Storage物理架構
參考文獻
OpenStack Compute Administration Manual.
http://docs.openstack.org/cactus/openstack-compute/admin/content.
OpenStack Object Storage Developer Guide.http://docs.openstack.org/.
以上是我閒暇時間,自己整理總結的,希望對愛學習的朋友有所幫助,可以加下我的好友:1753938973 精彩的公益課程免費共享以及持續分享更多的學習資料,非誠勿擾。。。。