OpenStack Dashboard(Horizon,管理介面)：

      提供了一個基於web的自服務門戶，與OpenStack底層服務互動，諸如啟動一個例項，分配IP地址以及配置訪問控制。

 OpenStack Compute(Nova,計算管理):
        OpenStack的組織控制器，提供一個工具來部署雲，包括執行例項、管理網路以及控制使用者和其他專案對雲的訪問。
        Nova各元件的作用：
            a) nova-api守護程序是OpenStack Compute的中心。它為所有API查詢提供端點，初始化絕大多數部署活動(比如執行實 例)，以及實施一些策略(絕大多數的配額檢查)；
            b) nova-compute程序主要是一個部署在HOST上的守護程序，通過虛擬機器管理程式的API建立和終止虛擬機器例項。基本原 理：從佇列中接收行為，然後在更新資料庫的狀態時，執行一系列的系統命令執行他們；
            c) nova-volume給虛擬機器分配額外持久化的儲存，管理對映到計算機例項的卷的建立、附加和取消；
            d) nova-network worker守護程序類似於nova-compute和nova-volume。它從佇列中接收網路任務，然後執行任務以操控 網路，比如建立bridging interfaces或改變iptables rules；
            e) Queue提供中心hub，為守護程序傳遞訊息。當前用RabbitMQ實現。但是理論上能是python ampqlib支援的任何AMPQ訊息佇列。
                AMPQ：Advanced Message Queuing Protocol，即高階訊息佇列協議。
                主要特徵是面向訊息、佇列、路由、可靠性和安全。
            f) SQL database儲存雲基礎架構中的絕大多數編譯時和執行時狀態。這包括了可用的例項型別，在用的例項，可用的網路和專案。當前廣泛使用的資料庫是sqlite3(僅適合測試和開發工作)，MySQL和PostgreSQL；
            g) 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)；
            h) user dashboard是另一個可選的專案。OpenStack Dashboard提供了一個OpenStack Compute介面來給應用開發者和devops staff類似API的功能。
            i) nova-schedule,從佇列上得到一個虛擬機器例項請求並且決定它應該在哪裡執行(特別是它應該執行在哪臺計算伺服器主機之上)
            
        nova計算虛化：
            1) 基於REST API；
            2) 支援大容量水平擴充套件；
            3) 硬體無關，支援多種標準硬體；
            4) 虛擬化平臺無關，支援多種Hypervisor：KVM、LXC、QEMU、UML、ESX、Xen、PowerVM、Hyper-V
        
        服務架構：
        OpenStack Compute採用無共享、基於訊息的架構。
        這意味著安裝OpenStack Compute有多種可能的方法。可能多結點部署唯一的聯合依賴性，是Dashboard必須被安裝在 nova-api伺服器。幾種部署架構如下：
            a) 單結點：一臺伺服器執行所有的nova-services，同時也驅動虛擬例項。
                        這種配置只為嘗試OpenStack Compute，或者為了開發目的;
            b) 雙結點：一個cloud controller 結點執行除nova-compute外的所有nova-services，compute結點執行nova-compute。一臺客戶計算機很可能需要打包映象，以及和伺服器進行互動，但是並不是必要的。
                        這種配置主要用於概念和開發環境的證明。
            c) 多結點：通過簡單部署nova-compute在一臺額外的伺服器以及拷貝nova.conf檔案到這個新增的結點，能在兩結點的基礎上，新增更多的compute結點，形成多結點部署。在較為複雜的多結點部署中，還能增加一個volume controller 和一個network controller作為額外的結點。
                        對於執行多個需要大量處理能力的虛擬機器例項，至少是4個結點是最好的。

 OpenStack Object Storage(Swift,物件儲存)：
        可擴充套件的物件儲存系統。
        Swift提供儲存供不同儲存消費者和客戶使用，每個使用者需要通過認證來識別自己。為此，OpenStack Object Stoage提供了 一個授權系統（swauth）。
            1) 基於REST API；
            2) 資料在整個系統中均勻分佈；
            3) 硬體無關，支援多種標準硬體；
            4) 沒有中央資料庫，沒有單點效能瓶頸或單點失敗的隱患
            5) 易於擴充套件；
            6) Account/Container/Object三級儲存結構均無需檔案系統且均有N(>=3)份拷貝
        一些相關的概念(暫時還不是很理解)：
            a） Account和Account Servers
            b） Authentication 和 Access Permissions
            c） Containers and Objects
            d） Operations
            e） 特定語言的API繫結
        
        Object Storage如何工作：
            a) Ring
                Ring 代表磁碟上儲存的實體的名稱和它們的物理位置的對映。
                accounts, containers, and objects都有單獨的Ring。其他元件要在這三者之一進行任何操作，他們都需要合相應的Ring進行互動以確定它在叢集中的位置。
                Ring用zones，devices，partitions，和replicas來維護對映，在Ring中的每個分割槽都會在叢集中預設有三個副本。分割槽的位置儲存在Ring維護的對映中。
                Ring也負責確定失敗場景中接替的裝置。分割槽的副本要保證儲存在不同的zone。Ring的分割槽分佈在OpenStack Object Storage installation所有裝置中。
                分割槽需要移動的時候，Ring確保一次移動最少的分割槽，一次僅有一個分割槽的副本被移動。
            b) Proxy Server
                Proxy伺服器的功能可以總結為：查詢位置，處理失敗，中轉物件。
                Proxy負責將OpenStack Object Storage架構中其他部分結合在一起。對於每次請求，它都查詢在Ring中查詢account, container, or object的位置，並以此轉發請求。公有APIs也是通過代理伺服器來暴露的
                當一個伺服器不可用，它就會要求Ring來為它找下一個接替的伺服器，並把請求轉發到那裡。
                當物件流進或流出object server時，它們都通過代理伺服器來流給使用者，或者通過它從使用者獲取。代理伺服器不會緩衝它們。
            c) Object Server
                簡單的blob儲存伺服器，能儲存、檢索和刪除本地磁碟上的物件，它以二進位制檔案形式存放在檔案系統中，元資料以檔案的擴充套件屬性存放。
            d) Container Server
                其主要工作是處理物件列表，它不知道物件在哪裡，只是知道哪些物件在一個特定的container。
                列表被儲存為sqlite 資料庫檔案，類似物件的方式在叢集中複製。也進行了跟蹤統計，包括物件的總數，以及container中使用的總儲存量。
            e) Account Server
                它是類似於Container Server，除了它是負責containers的列表而非物件。
            f) Replication
                設計副本的目的是，在面臨網路中斷或驅動失敗等臨時錯誤條件時，保持系統在一致的狀態。
                副本程序會比較本地的資料和每個遠處的副本，以確保他們所有都包含最新的版本。物件副本用一個Hash列表來快速比較每個分割槽的片段，而container和 account replication 用的是Hash和共享的高水印結合的方法。
                副本的更新，是基於推送的。對於物件副本，更新是遠端同步檔案到Peer。Account和container replication通過HTTP or rsync把整個資料庫檔案推送遺失的記錄。
                副本也通過tombstone設定最新版本的方式，確保資料從系統中清除。
            g) 更新器(Updaters)
                失敗的情形或高負載時期，container 或 account資料可能不能被立即更新。該更新會在檔案系統上本地排隊，更新器 將處理這些失敗的更新。
                事件一致性視窗(eventual consistency window)最可能來起作用。
            h) Auditors
                Auditors會檢查objects, containers, 和 accounts的完整性。如果發先損壞的檔案，它將被隔離，好的副本將會取代這個壞的檔案。如果發現其他的錯誤，它們會記入到日誌中
    
OpenStack Image

Sevice(Glance,映象管理):
        虛擬機器映象的儲存、查詢和檢索系統，服務包括的RESTful API允許使用者通過HTTP請求查詢VM映象元資料，以及檢索實際的映象。
        VM映象四種配置方式：
            (1) 簡單的檔案系統;
            (2) 類似OpenStack Object Storage的物件儲存系統;
            (3) 直接用Amazon'sSimpleStorageSolution(S3)儲存;
            (4) 用帶有Object Store的S3間接訪問S3。
            
        包括兩個主要的部分，分別是API server和Registry server
            API Server(執行“glance api”程式)起通訊hub的作用。
            API server轉發客戶端的請求到映象元資料註冊處和它的後端倉儲。OpenStack Image Service就是通過這些機制來實際儲存進來的虛擬機器映象。
        
        支援的後端倉儲：
            a) OpenStack Object Storage。它是OpenStack中高可用的物件儲存專案。
            b) FileSystem。OpenStack Image Service儲存虛擬機器映象的預設後端是後端檔案系統。這個簡單的後端會把映象檔案寫到本地檔案系統。
            c) S3。該後端允許OpenStack Image Service儲存虛擬機器映象在Amazon S3服務中。
            d) HTTP。OpenStack Image Service能通過HTTP在Internet上讀取可用的虛擬機器映象。這種儲存方式是隻讀的。

        根據安裝手冊，兩個服務安裝在同一個伺服器上。映象本身則可儲存在OpenStack Object Storage， Amazon's S3                    infrastructure，fileSystem。如果只需要只讀訪問，可以儲存在一臺Web伺服器上。
        

OpenStack Networking(Neutorn,虛擬網路管理)：
      確保為其它OpenStack服務提供網路連線即服務，比如OpenStack計算。為使用者提供API定義網路和使用。基於外掛的架構其支援眾多的網路提供商和技術。
      主要元件包括：
            a) Neutron Service
            b) Core Plugin(外掛)
            c) 各種Advanced Service Plugin
            d) 各種Agent(代理)
                L2(ovs-agent)
                L3 Agent
                DHCP Agent(DHCP：全稱是 Dynamic Host Configuration Protocol﹐中文名為動態主機配置協議)
                MetaData Agent
           Neutron Plugin通過整合多種虛擬環境網路外掛，實現L2的虛擬網路管理
        
 OpenStack Block Storage(Cinder,塊儲存管理)：
        為執行例項而提供的永續性塊儲存。它的可插拔驅動架構的功能有助於建立和管理塊儲存裝置。
            1) 虛擬機器管理和發放(Nova)、卷管理和發放為獨立服務；
            2) 虛擬機器、卷生命週期獨立；
            3) 眾多傳統儲存廠商（EMC，Netapp，IBM，HP）、虛擬化儲存廠商（VMWare，XenServer，Windows、新興儲存廠商（SolidFire，Ceph）都接入Cinder，以期發揮產品優勢
            
OpenStack Identity Service(Keystore,鑑權)：
        為其他OpenStack服務提供認證和授權服務，為所有的OpenStack服務提供一個端點目錄
            1) user：一個使用openstack雲服務的人、系統或者服務。
            2) project：專案，一組資源集合，包括虛擬資源如網路、虛擬機器、卷等資源關聯。
            3) role：使用者角色，和policy配合使用。
            4) token：一個通過keystone驗證的使用者標識，它的範圍與user+project或者user+domain關聯，根據獲取的token的方式來區分。
            5) service：compute，image，identity，volume，network。
            6) endpoint：service的網路接入地址，具有region屬性。
            7) group：使用者的集合，便於給使用者整體授予和取消許可權
            8) domain：類似名稱空間，含有使用者、角色、Group、Project等。
            9) policy：對於服務的操作規則，和角色相關，可以定義哪個角色可以進行哪些操作（v3版本只增加了crud操作，沒有邏輯實現替代policy.json的功能）
            10) trust：一個使用者可以通過trust將自己的role和個人資訊轉交給另一個使用者使用
        認證流程：
            1) 使用者發起nova請求之前，首先需要驗證使用者身份；
            2) 若使用者對應的credential通過keystone認證，keystone返回token；
            3) 使用者發起nova請求，請求資訊中帶上token ID；
            4) nova會再次向keystone驗證token有效性，若keystone返回有效，執行下一步操作。

七個服務之間的相互聯絡如下圖：

    
除了上部分的七個主要服務外，其他還有：
      OpenStack Telemetry Service(Ceilometer)：為OpenStack雲的計費、基準、擴充套件性以及統計等目的提供監測和計量
      OpenStack Orchestration Service(Heat)：
        既可以使用本地模板格式，亦可使用AWS CloudFormation模板格式，來編排多個綜合的雲應用，通過OpenStack本地             REST API或者是CloudFormation相相容的佇列API。
        Heat是OpenStack中的Orchestration services，也就是應用程式的配置管理。
        Heat用宣告式的方法來管理公有云或者私有云中的應用程式。它和其他OpenStack的服務類似，對外提供ReSTful介面，但     除此之外，它定義了一套配置管理的模版。Heat的模版才是Heat的核心所在；
        Heat與Openstack各服務間採用OpenStack-native Rest API
        Heat中的基本術語：
            1) 棧：棧是CloudFormation中管理一組資源的基本單位。一個棧往往對應與一個應用程式。
            2) 資源：一個棧可以擁有很多資源， 資源是底層服務的抽象。CPU，memory，disk，網路等都可以看作是資源。資源和資源之間會存在依賴關係。Heat在建立棧的時候會自動解析依賴關係，按順序建立資源。