下面個是51CTO上一位朋友發布的O版OpenStack核心組件說明,總結的非常到位，所以我就不再造輪子了.~,~
https://down.51cto.com/data/2448945
私有雲
公有雲
混合雲
IaaS(基礎架構即服務)：OpenStack，CloudStack
PaaS(平台即服務)：Docker，Openshift
SaaS(服務即服務)：主要面對終端用戶,可通過一個瀏覽器就可以實現使用任何應用,而無需安裝。
DBaaS（Database as a Service）
FWaaS(Firewall as a Service)
異步隊列服務：接收創建、啟動、刪除等等任務的隊列，當同時要啟動200個VM實例時,我只需將啟動VM的請求放到異步隊列中后,
我就開始干其它事情了。
OpenStack的組件:
OpenStack的API風格為：RESTful，它可以兼容AWS(亞馬遜雲)、S3；即Openstack可直接調用AWS或S3上的應用，
也可以直接在AWS、S3上調用OpenStack的應用；可非常方便的組件混合雲。
核心組件：
1. 服務名:Compute(代碼名:Nova) :它主要用來管理VM實例的完整生命周期,啟動、資源分配、關閉、銷毀、運行中SSH密鑰注入、SSH連接的提供等，均由它來提供。
2.服務名:Networking(代碼名:Neutron):早期由Nova,即Compute來提供，從F版(Folsom release)開始獨立出來,用於提供網絡連接服務，它采用插件設計,支持眾多流行的網絡管理插件.
3.Storage ：分兩個組件，一個為Block存儲(Cinder), 另一個為對象存儲(Swift)
對象存儲：類似於VMware的磁盤文件,但VMware的磁盤文件並非是對象存儲,對象存儲是自身包含自身的元數據，即便將它放到一個沒有文件系統的磁盤上，它也能自我管理。OpenStack采用Swift這個重量級的分布式存儲系統,是因為開發該系統的公司是OpenStack的早期發起人之一,並且該公司還將自己的分布式存儲系統貢獻給OpenStack作為其對象存儲系統,該系統就是Swift。
Object Storage: 代碼名:Swift,它是通過RESTful接口來存儲和檢索非結構化的數據對象，它是一個高容錯可伸縮的存儲架構。
Block Storage：代碼名:Cinder,早期由Nova,即Compute組件來提供,從F版開始獨立出來,它主要為VM提供持久的塊存儲的組件。
4. Identify，代碼名: Keystore ,它為除自身外的其它所有組件提供了一個認證和授權的服務及端點編錄服務,即類似與目錄服務的功能,可通過它檢索所有組件的訪問路徑。
5. Image，代碼名：Glance，它是作為Swift的前端,用來提供存儲對象元數據檢索的,簡單說:即VM啟動前需要知道磁盤鏡像文件存在哪,它就需要訪問Image服務來檢索,Image服務上存儲了所有Swift的存儲位置信息，它會告訴VMclient到哪去下載鏡像,然后,VMclient再自己去找。
6. Dashboard（用戶交互界面）(Horizon) ：它是一個與OpenStack個組件交互的基於Web的訪問接口。
7. Telemetry,代碼名:Ceilometer, 監控和計量VM,計量:即根據用戶使用VM的資源來收費,如:你使用了多少RAM、CPU、網絡帶寬、磁盤空間等等。
8. Orachestration:代碼名:Heat, 基於模板格式或AWS的CloudFormation模板格式來實現快速將多個資源聯動起來,完成統一服務功能.簡單理解:基於模板來實現系統管理.
9. Database: 代碼名:Trove, 用來提供DBaaS的組件。
10.Data processing: 代碼名:Sahara(沙哈拉), 用於在OpenStack中實現Hadoop的按需可伸縮的管理。
OpenStack各組件間的交互圖
各組件間交互的簡略描述:
1.通過Dashboard/CLI(OpenStack命令行接口)/自己開發的創建VM的界面,要啟動VM,需先到Keystore認證並登錄,接着用獲得的Token,來訪問Nova-API.
2.Nova-API它是接收用戶請求的調用接口,它需要監聽在一個套接字上,來通過TCP/IP協議來訪問.當Dashboard/CLI發過來請求后,Nova-API會先驗證它的Token是否合法,若合法則接收請求。接着向Nova-DB(MySQL)請求查詢該VM,Nova-DB從已創建的VM中查詢,若有要啟動的VM則獲取該VM的信息(如:實例名/RAM大小/CPU/磁盤等信息),並將這些信息返回給Nova-API。
3.當Nova-API獲得的VM的信息后,Nova-API會將該VM信息組織成Hypervisor或Nova-compute上借助Hypervisor來操作VM的特定請求包,並發送給Hypervisor或Nova-compute,由它來負責操作VM, Nova-API和Nova-compute的交互是異步的,它們中間隔着一個隊列.;
【注: Nova-API它僅是用來接收VM操作請求,驗證是否有權限操作VM,並獲取VM信息交給Hypervisor來完成VM的實際管理操作.】
4.Nova-API將特定請求包丟入隊列后,Nova-Scheduler會獲得這些請求,並為該請求調度選擇運行節點,完成后,Nova-scheduler會將該調度信息再次丟入隊列中,同時向Nova-DB發送VM已啟動的更新信息,Nova-DB更新完該VM的狀態后,會通知Nova-scheduler.
5.Nova-compute可以看成是具體的一個物理實體機,它會從隊列中獲取Nova-scheduler發出的調度信息,並判斷是否是自己的任務,若是則獲取該啟動VM的任務,並生成VM的已在啟動中的狀態信息,在丟入隊列中。
6.當Nova-conductor發現Nova-compute丟入隊列中的VM狀態更新信息后,它會讀取該信息,並將該信息發給Nova-DB來更新該VM的狀態,當Nova-DB更新完成后，Nova-DB會通知Nova-conductor,接着Nova-conductor會將該信息丟入隊列,當Nova-compute檢測到Nova-conductor丟入的更新成功的信息后，Nova-compute便開始進行接下來的VM啟動步驟。
7.當知道VM更新信息已經完成后,Nova-compute開始向glance-API請求啟動該VM的磁盤鏡像,這時glance-API會先從通過glance-registry來查詢glance-DB看是否存在該VM的磁盤信息,若有則glance-registry會將該磁盤鏡像信息返回給glance-API,然后，glance-API會先到Keystore驗證該Nova-compute提供的Token是否合法,若合法,則通過該VM磁盤鏡像信息到Image Store中去下載該VM啟動的磁盤鏡像文件,並返回給Nova-compute。
8.quantum-server: 它是負責為VM創建網絡基礎設施的,如:構建虛擬網橋,虛擬路由器並添加相應轉發規則,甚至是NAT; quantum-server是一個非常繁忙的系統,因為它需要為每個VM創建網絡基礎設施,但quantum-server並不直接為VM創建網絡基礎設施,而是將請求丟入到quantum子系統內部的隊列中。
9.相應的quantum-plugin會從quantum子系統內部的隊列中讀取構建網絡設施的信息,並通過查詢Quantum-DB來判斷那些部分在真正運行VM的Nova-compute上創建(如:創建網橋就需要在本地創建.)，那些在quantum上創建,若需要在運行VM的節點上創建,則quantum-plugin會將這些信息丟入內部隊列中，Nova-compute上運行的quantum-agent會從quantum內部隊列中獲得這些信息,並在本地創建相應的網絡基礎設施，完成后，quantum-agent會將完成信息發送給Quantum-DB來更新該網絡基礎設施的狀態信息。【注:quantum-server也會在收到Nova-compute的請求到Keystore上去驗證是否有合法。】最后，quantum-server會通告Nova-compute網絡已經構建完成。
10.Nova-compute會從獲得的啟動VM的信息中看是否需要加載它曾經關聯過的Block設備,若有則向cinder-API發起請求,cinder-API會先將請求信息發給cinder-volume,由它來查詢Cinder-DB看是否存在Nova-compute請求的Block設備,若有則cinder-volume會通知cinder-API,cinder-API在向Keystore發起驗證請求,驗證通過后，cinder-api會直接將Block設備信息返回給nova-compute,若這是一個創建Block的請求，則cinder-volume會將Block信息丟入cinder內部隊列中,由cinder-scheduler從cinder-DB中獲取后端存儲的信息，並根據要創建Volume的大小，VolumeType，所需具有的特性等信息，從后端存儲主機中選出一個最匹配的，並將結果寫入cinder隊列中，cinder-volume通過該信息在存儲節點上調用相應的存儲驅動創建volume，創建完成后將這些信息寫入cinder-db中，最后cinder-volume告訴cinder-api，cinder-api在返回信息給nove-compute.
Controller Node + Network Node + Compute Node 這種三節點OpenStack架構是OpenStack的最小結構。
Controller Node:
基礎服務：
1.Identity(認證)服務。即Keystore
2.Image Service.
3.compute的Nova Management。
4.Networking: Neutron server, ML2 Plug-in.
5.Dashboard ：圖形管理界面
支持服務:
1.Database MySQL or MariaDB
2.Message Broker: RabbitMQ or Qpid，它是用來為基礎服務和數據庫連接提供緩存區的。
它至少需要一個網卡接口，來作為管理接口。
1.需要注意: 若需要向外網提供公有雲服務,則應該還需要改Controller Node提供一個外網訪問網卡.
以便外部可調用Cinder提供的Block Storage或Object Storage，以及Image Service.
Network Node:
需要提供基礎的Networking服務,該服務包含:
ML2 Plug-in(第二層插件),
Layer2 Agent(第二層代理:OVS): OVS是用來構建橋、VLAN、VxLAN、GRE、與Network Node節點通信均有它來完成。
Layer3 Agent(第三層代理):創建NAT NS並構建NAT規則,iptables過濾規則、路由轉發規則等
DHCP Agent:用來提供DHCP服務,為VM提供動態地址分配管理。
它需要提供三個網卡接口:
1.Management 接口。
2.與實例構建隧道的接口.
3.與外網連接的接口。
Compute Node:
它是運行VM的基本節點。它可以有非常多。
它需要運行的基礎服務：
1.Compute(計算服務):Nova Hypervisor; KVM or QEMU
2.Networking: ML2 Plug-in, Layer2 Agent(OVS)
它需要兩個網卡接口:
1. Management接口
2.構建Tunnel的接口。
控制節點需要哪些必要組件？
對於控制節點來說，最主要的組件有 nova（nova-api, nova-sheduler,nova-conductor等），neutron-server(neutron的二層，三層，元數據代理)，Glance(鏡像服務)，keystone(認證服務)，通常也都會部署cinder服務，因此控制節點一般這些基礎服務端進程是需要運行在控制節點的，但有時也需要使用想manila，heat這些服務，也需要在控制節點部署，但heat我研究不多，我的實踐中，nova，neutron，glance，keystone，cinder是必須要配置的，像我們啟動一台VM，首先就要訪問nova-api，由nova-api來訪問keystone驗證用戶提供的憑據，身份驗證通過后，才會將請求做進一步處理，比如說要創建VM，nova-api就會將請求發給nova-sheduler,而它會查詢nova數據庫，獲取當前所有計算節點上資源的使用情況，並根據調度算法，選出一個最佳的計算節點，並將創建VM的請求發送到對應的消息隊列的管道中，這樣所有訂閱了這個管道的計算節點上的nova-compute就都能收到，並解析請求，若是自己的任務，就會在自己的節點上啟動創建VM的任務，當然這個過程涉及到了前面提到的所有組件，比如它會先訪問glance獲取創建VM的鏡像，隨后訪問neurton創建必須的網絡，最后還會訪問cinder獲取VM所需要掛載的雲盤信息等等，最后還要通知nova-conductor將VM的啟動狀態寫入nova數據庫中，當然這啟動之初就會先告知nova-conductor，這樣我們在前端Dashboard上才能看到VM的啟動狀態到那一步了，所以狀態報告是每個階段都需要有的. 另外像neutron，它通常會在用戶創建網絡時，如二層網絡，或虛擬路由器等，會由neutron-server通過消息隊列通知各個計算節點上的neutron-代理來完成計算節點上基礎虛擬網橋的創建。
另外我在實踐中發現，像消息隊列服務,通常使用rabbitmq，緩存及Session保持常用memcached，數據庫通常用Mariadb，並且這三個服務最好分別部署，一般部署測試環境時，會將它們單獨放到一台主機上來部署，前面用HAProxy或Nginx+Keepalived，這樣部署會盡可能降低消息隊列，緩存及數據庫的壓力，降低瓶頸，不會出現mysql掛了，所有服務都不能正常工作，mysql做雙主會多些，但使用時，還按照主從方式用.
計算節點通常需要哪些組件？
對於計算節點來說，通常需要運行nova-compute,這是最基本的，因為控制節點上nova-api驗證用戶完用戶身份后，就以創建VM為例來說，它會將創建VM的任務交給nova-scheduler，由它來從查詢nova數據庫獲取每個計算節點的信息,比如內存,磁盤,CPU等信息,找一個資源最富裕的計算節點,並通過消息隊列,通知給訂閱了該消息通道的nova-compute，nova-compute就需要在當前計算節點與底層的hapyervsior通信，不過基本是跟libvirtd通信，因為libvirtd已經統一了底層絕大部分haypervsior,在Linux上通常做IaaS層面的私有雲，首選通常是KVM+Qume，不過若硬件不支持虛擬化，就只能使用Qume這種模擬器了，不過對於服務器來說這是不可能的。能創建VM，但也必須讓用戶能訪問它才行，所以，neutron的代理是必須要安裝的，neutron就是通過如linuxbridge-agent,ovs-agent這些計算節點上的網絡代理來實現接受neutron-server通過消息隊列發來的創建虛擬網絡的指令，這樣計算節點上就可以創建二層網橋，並自動將虛擬網線的一端安裝到VM中，另一段連接到網橋上，當然若使用安全組，VM和虛擬網絡之間就還需要一個網絡名稱空間來做安全策略，這樣就可以能讓VM連接的隧道網絡上了，通常不會直接讓VM連接的公網橋上的，而是通過tunnel network連接到Neutron-server端，在通過NAT來讓VM上網的，但對於VM的遠程管理，就比較復雜了，這一塊主要涉及到nova的幾個主要組件計算節點上的nova-compute,控制節點上的nova-consoleauth,nova-novncproxy，nova-api他們之間經過復雜交換，生成token，轉換URL為公網可訪問的URL，最后返回給用戶的瀏覽器，最終用戶才得以看到VM的管理控制台，這期間是不涉及neutron網絡組件的。