初識OpenStack

雲計算是分佈式計算，並行計算，效用存儲，網絡存儲，虛擬化，負載均衡，熱備份冗餘等傳統計算機和網絡技術發展融合的產物。

服務類型
* IaaS:將硬件設備等基礎資源封裝成服務供用戶使用。在IaaS環境中，用戶至關於在使用裸機和磁盤，既可讓它運行Windows，也可讓它運行Linux。 IaaS最大優點在於它容許用戶動態申請或釋放節點，按使用量計費。而IaaS是由公衆共享的，於是具備更高的資源使用效率。
* PaaS：提供用戶應用程序的運行環境，典型的如Google App Engine。PaaS自身負責資源的動態擴展和容錯管理，用戶應用程序沒必要過多考慮節點間的配合問題。但與此同時，用戶的自主權下降，必須使用特定的編程環境並遵守特定的編程模型，只適用於解決某些特定的計算問題。
* SaaS：針對性更強，它將某些特定應用軟件功能封裝成服務。SaaS既不像PaaS同樣提供計算或存儲資源類型的服務，也不像IaaS同樣提供運行用戶自定義應用程序的環境，它只提供某些專門用途的服務供應用調用。

OpenStack基本概念

OpenStack便是一個社區，也算一個項目和一個開源軟件，提升開放源碼軟件，創建公共雲和私有云，它提供了一個部署雲的操做平臺或工具集。

    官網：

https://www.openstack.org/

 

三種網絡和四種節點

管理網絡 是 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