雲計算是分佈式計算，並行計算，效用存儲，網絡存儲，虛擬化，負載均衡，熱備份冗餘等傳統計算機和網絡技術發展融合的產物。
服務類型
* IaaS:將硬件設備等基礎資源封裝成服務供用戶使用。在IaaS環境中，用戶相當於在使用裸機和磁盤，既可以讓它運行Windows，也可以讓它運行Linux。 IaaS最大優勢在於它允許用戶動態申請或釋放節點，按使用量計費。而IaaS是由公衆共享的，因而具有更高的資源使用效率。
* PaaS：提供用戶應用程序的運行環境，典型的如Google App Engine。PaaS自身負責資源的動態擴展和容錯管理，用戶應用程序不必過多考慮節點間的配合問題。但與此同時，用戶的自主權降低，必須使用特定的編程環境並遵照特定的編程模型，只適用於解決某些特定的計算問題。
* SaaS：針對性更強，它將某些特定應用軟件功能封裝成服務。SaaS既不像PaaS一樣提供計算或存儲資源類型的服務，也不像IaaS一樣提供運行用戶自定義應用程序的環境，它只提供某些專門用途的服務供應用調用。
OpenStack基本概念
OpenStack即是一個社區，也算一個項目和一個開源軟件，提高開放源碼軟件，建立公共雲和私有云，它提供了一個部署雲的操作平臺或工具集。
官網：
三種網絡和四種節點
管理網絡 是 OpenStack 的管理節點或者說是它的管理服務對其它的節點去進行管理的這樣一個網絡，他們之間有 “不同組件之間的 API 調用，虛擬機之間的遷移” 等等；
存儲網絡 是計算節點訪問存儲服務的網絡，包括向存儲設備裏面讀寫數據的流量基本上都需要從存儲網絡走，還有另外一種是服務網絡；
服務網絡 是由 OpenStack 去管理的虛擬機對外提供服務的網絡，服務器上通常都是一臺服務器上帶好幾塊網卡，好幾塊網口，我們可以給各個網絡做隔離。隔離的好處是，它們的流量不會交叉，比方說我們在讀寫存儲設備的時候，可能在存儲網絡上的流量特別大，但是它不會影響到我們這些節點對外提供服務，同樣，在我們做虛擬機遷移的時候可能在管理網絡上它的數據流量會非常大，但是它同樣不會影響到我們這些計算節點對存儲設備的讀寫性能。
整個OpenStack是由控制節點，計算節點，網絡節點，存儲節點四大部分組成。
其中：
控制節點：負責對其餘節點的控制，包含虛擬機建立，遷移，網絡分配，存儲分配等。
計算節點：負責虛擬機運行。
網絡節點： 負責對外網絡與內網絡之間的通信。
存儲節點：負責對虛擬機的額外存儲管理等。
OpenStack組件之間的通信關係
OpenStack 組件之間的通信分爲四類：
基於 HTTP 協議
基於 AMQP 協議（基於消息隊列協議）
基於數據庫連接（主要是 SQL 的通信）
Native API（基於第三方的 API）
OpenStack幾種不同的存儲
OpenStack的存儲服務分爲三種：Glance、Swift、Cinder；
Glance（鏡像存儲）是一個鏡像存儲管理服務，本身不具備存儲的功能；
Cinder （塊存儲）提供塊存儲的接口；本身也不提供數據的存儲，後面也需要接一個存儲的後端，像 EMC 的散設備，華爲的存儲設備，NetApp 的存儲設備可以做它的後端。還有一個比較火的開源分佈式存儲叫 Ceph，Ceph 也提供塊存儲服務，也可以用來作爲 Cinder 的後端。Cinder 的作用就是爲 OpenStack 提供塊存儲的接口，有個很重要的功能叫卷管理功能，虛擬機並不直接去使用存儲設備（並不直接去使用後端的存儲系統），使用的是虛擬機上的塊設備（卷 Volume），實際上 Cinder 就是創建和管理這些 Volume 並且把它掛載到虛擬機上。Cinder 是從 Nova Volume 裏面獨立出來的，獨立出來之後很受各種存儲廠商的歡迎，可以通過寫 Cinder Driver 的形式把自己的存儲設備納入到 OpenStack 的生態圈裏面去。
Swift （對象存儲）提供的是對象存儲服務，同樣的具有像亞馬遜 IWSS3 的特點，提供通過RESTful API 的方式去訪問數據，這樣做是爲了解決兩個問題：第一個，我們可以直接去訪問一個存儲，而不需要在通過自己開發的 Web 服務器去做一次數據的轉發，否則對服務器的負載來說是一種壓力。第二個，在我們的大數據時代，當數據量特別大的時候，如果我們用文件系統就會出現問題：文件的數量激增以後，存儲的性能會急劇下降，而對象存儲實際上則是解決這個問題的，對象存儲拋棄了那種目錄樹的結構，用一種扁平化的結構去管理數據。Swift 實際上只有三層結構，即 Account、Container、Object。Object 就是最終的那個數據了，就是文件，前面有兩級管理，一級是 Container 容器，它把 Object 放到容器裏面，然後再上面一級是 Account，是和賬戶去關聯的，Container 相當於是把這些 Object 做了分類，用 Account 去跟賬戶關聯起來。
三種存儲的概念：文件存儲、塊存儲、對象存儲
有 POSIX 接口或者 POSIX 兼容的接口，就可認爲它是一個文件系統，比較典型的分佈式文件系統有像 Glance 的 FS，Hadoop 裏的 HDFS
電腦上的一個盤格式化之後是一個文件系統，那麼在格式化之前是一個塊設備，也就是塊存儲，實際上我們在數據中心裏面，像 EMC 的很多設備，像華爲的一些叫作 SAN 的設備，像 NetApp 的一些設備，如果是散存儲一般來說就是提供塊存儲的；
對象存儲的典型代表是亞馬遜的 AWS S3，它的接口不是 POSIX，也不是像一塊硬盤那樣作爲一個塊存儲的接口，是通過 RESTful Web API 去訪問的，對於應用開發者來說優勢在於可以很方便的去訪問存儲裏面存的數據，對象存儲裏存的數據通常叫做 Object，實際上它就是 File，但是對象存儲裏面爲了和文件系統做一個區別，便被叫作對象 Object
OpenStack服務
| 服務 | 項目名稱 | 描述 |
| Compute （計算服務） | Nova | 負責實例生命週期的管理，計算資源的單位。對Hypervisor進行屏蔽，支持多種虛擬化技術（KVM），支持橫向擴展。 |
| Network （網絡服務） | Neutron | 負責虛擬網絡的管理。 |
| Identity （身份認證服務） | Keystone | 對用戶、租戶和角色、服務 進行認證和授權 |
| Dashboard （控制面板服務） | Horizon | 提供web界面管理，與OpenStack底層服務進行交互 |
| Image Server （鏡像服務） | Glance | 提供虛擬機鏡像模板的註冊與管理，將最好系統複製爲鏡像模板，在創建虛擬機時直接使用。 |
| Block Storage （塊存儲服務） | Cinder | 負責爲允許實例提供持久的塊存儲設備，可進行方便擴展，按需付費，支持多種後端存儲。 |
| Object Storage （對象存儲服務） | Swift | 爲OpenStack提供基於雲的彈性存儲，支持羣集無單點故障 |
| Telemetry （計量服務） | Ceilometer | 用於度量、監控和控制數據資源的集中來源，爲OpenStack用戶提供記賬途徑 |
部署OpenStack硬件需求
| 硬件\需求 | 控制節點 | 計算節點 |
| CPU | 支持Intel 64或AMD64 CPU擴展，啓用AMD-V或Intel VT硬件虛擬化支持的64位 x86處理器 | |
| 內存 | 2GB | 至少2GB |
| 磁盤空間 | 50GB | 最低50GB |
| 網絡 | 2個1Gbps網卡 | 2個1Gbps網卡 |
OpenStack工作流程
總共有 28 個步驟，主要是和 Nova 相關的，實際上在 Keystone Glance Neutron Cinder Swift 等組件內部還有很多小步驟，加起來恐怕有50多個步驟。現在主要看這28個基本步驟，這裏的大部分信息發表在來自 ilearnstack 網站上的一篇文章，在 Dashboard 上創建虛擬機的過程.
第 1 步，首先，Horizon 或者是命令行工具向 keystone 發起了 REST 調用，並且把用戶名和密碼發給 Keystone；
第 2 步，Keystone 對接收到的用戶名及其密碼進行驗證，並生成 Token，這個 Token 在後面爲其他組件發送 REST 調用時使用；
第 3 步，Horizon 或者命令行客戶端把啓動虛擬機操作或者在命令行上敲的 nova boot 命令，包括上一步說的 Token 轉化成 RESTful Web API 發送給 Nova-API；
第 4 步，Nova-API 收到請求之後向Keystone 驗證客戶端發來的 Token 的合法性，這就是說 Nova 和 Keystone 之間有一個交互了；
第 5 步，Keystone 驗證完 Token 之後，將用戶的角色和權限返回給 Nova，也是返回到 Nova-API；
第 6 步，是 Nova-API與 Nova Database 之間有一個交互的過程；
第 7 步，是 Nova Database 爲新的虛擬機實例創建一條記錄，並且將結果返回給 Nova-API。
第 8 步，Nova-API 通過 AMQP 向 Nova-Scheduler 發送一個同步遠程調用請求，這裏的同步遠程調用請求實際上是 AMQP 協議裏的叫作 rpc.call request，這地方是同步調用，同步調用的意思就是，它發送完請求以後就一直在等待，一直等待到這個隊列（消息隊列）裏面給它返回來結果，所以就是在等待獲得新的虛擬機實例的條目和 Host ID，Host ID 是虛擬機將來要啓動的寄主機的 ID；
第 9 步，Nova-Scheduler 從消息隊列裏面取出請求，因爲中間有 AMQP 組件在這，所以 Nova 的其他各個組件之間的交互基本上都是通過 AMQP 來做的，實際上 AMQP 的實現用的是 RabbitMQ；
第 10 步，是 Nova-Scheduler 與 Nova Database 進行交互並且挑選出一臺適合的宿主機來啓動這個虛擬機，（挑選的過程很複雜）；
第 11 步，是 Nova-Scheduler 通過 AMQP 返回給前面的 Nova-API 的調用，並且將宿主機的 ID 發送給它；
第 12 步，是 Nova-Scheduler 通過消息隊列，向 Nova-Compute 發出一個在上述宿主機上啓動虛擬機的異步調用請求，這裏是異步調用請求（Nova-Schduler 把請求發送到消息隊列裏面以後它就返回了，就不用再等待這個請求給它返回結果，在 AMQP 裏面是 rpc-cast 這個請求）；
第 13 步，是 Nova-Compute 從隊列裏面取該請求；
第 14 步，是 Nova-Compute 通過消息隊列向 Nova-Conducter 發送一個 rpc.call 同步調用請求獲取虛擬機的信息（包括宿主機的 ID，虛擬機配置信息有內存大小、CPU 配置、硬盤大小等等）；
第 15 步，Nova-Conducter 從隊列裏取出上述請求；
第 16 步，Nova-Conducter 與數據庫進行交互；
第 17 步，Nova-Conducter 返回前面 Nova-Compute 請求的這些信息；
第 18 步，Nova-Compute 從消息隊列裏面取出 Nova-Conducter 返回的信息，也就是同步調用到這裏就結束了；
第 19 步，是 Nova-Compute 向 Glance-API 發出帶有 Token 的 REST 請求，去請求這個鏡像數據；
第 20 步，是 Glance-API 向 Keystone 去驗證這個 Token 的合法性，在前面有類似的步驟（Nova 去驗證 Token 的合法性，其實在 19 步和 20 步兩步裏面還有很多細節比如說，如果是 Swift 來存儲 Glance 的鏡像，中間還有 Swift 和 Glance 之間的交互，Glance 內部也有一些交互）；
第 21 步，是 Nova-Compute 獲取鏡像的元數據，前面幾步相當於把鏡像的元數據給獲取了，知道了鏡像是從哪裏來的長什麼樣的。後面的 22 到 24 步這幾步是爲虛擬機去準備網絡，還是以 Nova-Compute 爲中心的；
第 22 步，是 Nova-Compute 向 Neutron API 發送帶有 Token 的 REST 請求進行網絡配置，並獲得分配給待創建的這個虛擬機的 IP 地址，這中間其實 Neutron 做了一些工作，也有很多細節；
第 23 步，Neutron Server 向 Keystone 去驗證 Token 的合法性；
第 24 步，Nova-Compute 就獲得了網絡的配置信息，後面這幾步是給虛擬機去準備虛擬機的硬盤，也就是前面提到過的卷存儲或塊存儲；
第 25 步，是 Nova-Compute 調用 Cinder-API 的 RESTful 接口給虛擬機掛載卷，也就是塊設備或者是虛擬硬盤；
第 26 步，跟上面的 Glance 和 Neutron 類似，Cinder-API 也要向 Keystone 去驗證，這個Token 的合法性；
第 27 步，Nova-Compute 就會得到這個虛擬機的塊存儲的信息；經過 27 個步驟，這樣創建一個虛擬機所需要的各種信息和條件才正式地準備完畢；
第 28 步，Nova-Compute 去調用 Hypervisor 或者 Libvirt 的接口創建虛擬機，當然，在 Libvirt 或者說是 Hypervisor 去創建虛擬機的過程中，內部也是一個非常複雜的過程；
---------------------
本文部分來自：https://blog.csdn.net/Heartyhu/article/details/51033450