目錄
- 一、OpenStack背景介紹
- （一）OpenStack是什么
- （二）OpenStack的主要服務
- 二、計算服務Nova
- （一）Nova組件介紹
- （二）Libvirt簡介
- （三）Nova中的RabbitMQ解析
??OpenStack既是一個社區，也是一個項目和一個開源軟件，提供了一個部署云的操作平臺或工具集。用OpenStack易于構建虛擬計算或存儲服務的云，既可以為公有云、私有云，也可以為大云、小云提供可擴展、靈活的云計算。
一、OpenStack背景介紹
（一）OpenStack是什么
??OpenStack是一個管理計算、存儲和網絡資源的數據中心云計算開放平臺，通過一個儀表板，為管理員提供了所有的管理控制，同時通過Web界面為其用戶提供資源。
（二）OpenStack的主要服務
??OpenStack有三個主要的服務成員：計算服務（Nova）、存儲服務（Swift）、鏡像服務（Glance）。
1. 計算服務Nova
??Nova是OpenStack云計算架構的控制器，支持OpenStack云內的實例的生命周期所需的所有活動由Nova處理。Nova作為管理平臺管理著OpenStack云里的計算資源、網絡、授權和擴展需求。但是，Nova不能提供本身的虛擬化功能，相反，它使用Libvint的API來支持虛擬機管理程序交互。Nova通過Web服務接口開放所有功能并兼容亞馬遜Web服務的EC2接口。
2. 對象存儲服務Swift
??Swift提供的對象存儲服務，允許對文件進行存儲或者檢索（但不通過掛載文件服務器上目錄的方式來實現）。對于大部分用戶來說，Swift不是必需的，只有存儲數量達到一定級別，而且是非結構化數據才有這樣的需求。Swift為OpenStack提供了分布式的、最終一致的虛擬對象存儲。和亞馬遜的Web服務–簡單存儲服務(S3)類似，通過分布式的存儲節點，Swift 有能力存儲數士億計的對象，Swift具有內置冗余、容錯管理、存檔、流媒體的功能。Swift是高度擴展的。
3. 鏡像服務Glance
??它提供了一個虛擬磁盤鏡像的目錄和存儲倉庫，可以提供對虛擬機鏡像的存儲和檢索。 這些磁盤鏡像廣泛應用于Nova組件之中。Glance能進行多個數據中心的鏡像管理和租戶私有鏡像管理。雖然這種服務在技術上是屬于可選的，但任何規模的云都可能對該服務有需求。目前Glance的鏡像存儲，支持本地存儲、NFS、Swift、sheepdog和Ceph。OpenStack鏡像服務查找和檢索虛擬機的鏡像系統，它可以被配置為使用以下3個存儲后端的任何一個：
（1）OpenStack對象存儲到存儲鏡像。
（2）S3存儲直連。
（3）S3存儲結合對象存儲成為中間級的S3訪問。
4. 身份認證服務keystone
??它為OpenStack上的所有服務提供身份驗證和授權。它還提供了在特定OpenStack云服務上運行的服務的一個目錄。任何系統中，身份認證和授權其實都比較復雜，尤其是Openstack那么龐大的項目，每個組件都需要使用統一認證和授權。
5. 網絡管理服務Quantum
??在接口設備之間提供“網絡連接即服務”的服務，而這些接口設備主要是由Open Stack的其他服務（如Nova）進行管理的。該服務允許用戶創建自己的網絡，然后添加網絡接口設備。Quantum提供了一個可插拔的體系架構，使其能夠支持很多流行的網絡供應商和新的網絡技術。Quantum后端可以是商業產品或者開源。開源產品支持Openvswitch和Linux bridge。網絡設備廠商都在積極參與，讓他們的產品支持Quantum，目前思科、銳捷已經實現支持。
6. 存儲管理服務Cinder
??Cinder存儲管理主要是指虛擬機的存儲管理，Swift主要是對象存儲管理。目前支持開源和商業化產品sheepdog、Ceph等。
??對于企業來說，使用分布式作為虛擬機的存儲，并不能真正節省成本，維護一套分布式存儲，成本還是很高的。目前虛擬機的各種高可用、備份的問題，其實都可以把問題交給商業存儲廠商來解決。
7. 儀表盤Horizon
??嚴格意義來說，Horizon不會為OpenStack增加一個功能，更多的是一個演示。對于很多用戶來說，了解Open Stack基本都是從Horizon、 dashboard開始。從這個角度來看，它在OpenStack各個項目里顯得非常重要。
二、計算服務Nova
??Nova是OpenStack云中的計算組織控制器。Nova處理OpenStack云中實例（instances）生命周期的所有活動。這樣使得Nova成為一個負責管理計算資源、網絡、認證、所需可擴展性的平臺。
??但是，Nova并不具有虛擬化能力，相反它使用Libvirt API來與被支持的Hypervisors交互。Nova通過一個與Amazon Web Services（AWS）EC2 API兼容的Web Services API來對外提供服務。
（一）Nova組件介紹
1. API Server（Nova-Api）
??API Server對外提供一個與云基礎設施交互的接口，也是外部可用于管理基礎設施的唯一組件。
2. Message Queue（Rabbit MQ Server）
??OpenStack節點之間通過消息隊列使用AMQP（Advanced Message Queue Protocol）完成通信。
3. Compute Worker（Nova-Compute）
??Compute Worker管理實例生命周期，通過Message Queue接收實例生命周期管理的請求，并承擔操作工作。
4. Network Controller（Nova-Network）
??Network Controller處理主機的網絡配置，包括IP地址分配、為項目配置VLAN、實現安全組、配置計算節點網絡。
5. Volume Workers（Nova-Volume）
??Volume Workers用來管理基于LVM（Logical Volume Manager）的實例卷。Volume Workers有卷的相關功能，例如新建卷、刪除卷、為實例附加卷、為實例分離卷。
6. Scheduler（Nova-Scheduler）
??調度器Scheduler把Nova-API調用映射為OpenStack組件。調度器作為一個Nova-Schedule守護進程運行，通過恰當的調度算法從可用資源池獲得一個計算服務。當前Nova-Schedule實現了一些基本的調度算法：隨機算法、可用域算法和簡單算法。
（二）Libvirt簡介
??Nova通過獨立的軟件管理模塊實現XenServer、Hyper-V和VMWare ESX的調用與管理。同時對于其他的Hypervisor，如KVM、LXC、QEMU、UML和Xen則通過Libvirt標準接口統一實現。為了更好地理解在Nova環境下Libvirt如何管理底層的Hypervisor，先要基本了解Libvirt的體系架構與實現方法。
1. 什么是Libvirt
??虛擬云實現的三部曲：虛擬化技術實現→虛擬機管理→集群資源管理（云管理）。各種不同的虛擬化技術都提供了基本的管理工具，比如啟動、停用、配置、連接控制臺等。這樣在構建云管理的時候就存在兩個問題。
（1）如果采用混合虛擬技術，上層就需要對不同的虛擬化技術調用不同管理工具，很是麻煩。
（2）可能有新的虛擬化技術更加符合現在的應用場景，需要遷移過去。這樣管理平臺就需要大幅改動。
??Libvirt的主要目標是為各種虛擬化工具提供一套方便、可靠的編程接口，用一種單一的方式管理多種不同的虛擬化提供方式。
2. Libvirt主要支持的功能
（1）虛擬機管理：包括不同的領域生命周期操作，支持多種設備類型的熱插拔操作。
（2）遠程機器支持：只要機器上運行了Libvirt Daemon，所有的Libvirt功能就都可以訪問和使用。
（3）存儲管理：任何運行了Libvirt Daemon的主機都可以用來管理不同類型的存儲,創建不同格式的文件鏡像。
（4）網絡接口管理：任何運行了Libvirt Daemon的主機都可以用來管理物理和邏輯的網絡接口。
（5）虛擬NAT和基于路由的網絡：任何運行了Libvirt Daemon的主機都可以用來管理和創建虛擬網絡。
3. Libvirt體系結構
沒有使用Libvirt的虛擬機管理方式：
Libvirt API與相關驅動程序的層次結構：
Libvirt的控制方式有以下兩種。
（1）管理位于同一節點上的應用程序和域。管理應用程序通過Libvirt工作，以控制本地域。
（2）管理位于不同節點上的應用程序和域。該管理應用程序通過一種通用協議從本地Llibvirt連接到遠程Libvirt。
（三）Nova中的RabbitMQ解析
1. RabbitMQ
??RabbitMQ是一種處理消息驗證、消息轉換和消息路由的架構模式，它協調應用程序之間的信息通信，并使得應用程序或者軟件模塊之間的相互意識最小化，有效實現解耦。
??RabbitMQ適合部署在一個拓撲靈活易擴展的規模化系統環境中，有效保證不同模塊、不同節點、不同進程之間消息通信的時效性；RabbitMQ特有的集群HA安全保障能力可以實現信息樞紐中心的系統級備份，同時單節點具備消息恢復能力。
2. AMQP
- AMQP是應用層協議的一個開放標準，為面向消息的中間件而設計
- RabbitMQ是AMQP協議的一個開源實現
- OpenStack Nova各軟件模塊通過AMQP協議實現信息通信
- AMQP協議的設計理念可歸納為基于狀態的面向無連接通信系統模式
- 對于AMQP來講，消息隊列的狀態信息決定通信系統的轉發路徑
- IP數據包根據路由表實現報文的本地存儲與逐級轉發
??“消息”是AMQP實現通信的基本因素，交換器和隊列是AMQP的核心要素。
??交換器（Exchange）：交換器由消費者應用程序創建，并且可與其他應用程序實現共享服務。接收消息之后通過路由表將消息準確且安全地轉發至相應的消息隊列。每個交換器通過唯一的Exchange ID進行識別。交換器主要分為三種：
（1）持久交換器：持久交換器并不會因為系統重啟或者應用程序終止而消除
（2）臨時交換器：駐留在內存中，隨著系統的關閉而消失
（3）自動刪除交換器：隨著宿主應用程序的中止而自動消亡
??隊列（Queue）：主要用于實現存儲與轉發交換器發送來的消息，隊列同時也具備靈活的生命周期屬性配置，可實現隊列的持久保存、臨時駐留與自動刪除。
??消息、隊列和交換器是構成AMQP的三個關鍵組件，任何一個組件的失效都會導致信息通信的中斷，因此鑒于三個關鍵組件的重要性，系統在創建三個組件的同時會打上“Durable”標簽，表明在系統重啟之后立即恢復業務功能。
??構成AMQP的三個關鍵要素的工作方式如圖所示。
??三種不同類型的交換器：廣播式交換器（Fanout Exchange）、直接式交換器（Direct Exchange）和主題式交換器（Topic Exchange）。
3. Nova中的RabbitMQ應用
??目前Nova中的各個模塊通過RabbitMQ服務器以RPC（遠程過程調用）的方式實現通信，而且各模塊之間形成松耦合關聯關系，在擴展性、安全性以及性能方面均體現優勢。以下是三個比較重要的概念。
（1）交換器
??接受消息并且將消息轉發給隊列。應用程序在它的權限范圍之內可以創建、刪除、使用和共享交換器實例。交換器可以是持久的、臨時的或者自動刪除的。
（2）隊列
??“消息隊列”，它是一個具名緩沖區，它代表一組消費者應用程序保存消息。這些應用程序在它們的權限范圍內可以創建、使用、共享消息隊列。
（3）綁定
??可以理解為交換器和消息隊列之間的一種關系，綁定之后交換器會知道應該把消息發給哪個隊列，綁定的關鍵字稱為binding_key。
下面介紹一下RabbitMQ的三種類型的交換器。
1）廣播式交換器類型（fanout）
??該類交換器不分析所接收到消息中的Routing Key，默認將消息轉發到所有與該交換器綁定的隊列中去。廣播式交換器轉發效率最高，但是安全性較低，消費者應用程序可獲取本不屬于自己的消息。
??廣播交換器是最簡單的一種類型，就像我們從字面上理解到的一樣，它把所有接收到的消息廣播到所有它所知道的隊列中去，不論消息的關鍵字是什么，消息都會被路由到和該交換器綁定的隊列中去。
??在程序中申明一個廣播式交換器的代碼如下：
channel.exchange_declare（exchange='fanout',type='fanout'）
2）直接式交換器類型（direct）
??直接式交換器的轉發效率較高，安全性較好，但是缺乏靈活性，系統配置量較大。相對廣播交換器來說，直接交換器可以給我們帶來更多的靈活性。
??直接交換器的路由算法很簡單：一個消息的routing_key完全匹配一個隊列的binding_key，就將這個消息路由到該隊列。綁定的關鍵字將隊列和交換器綁定到一起。當消息的routing_key和多個綁定關鍵字匹配時消息可能會被發送到多個隊列中。
3）主題式交換器（Topic Exchange）
??Nova基于RabbitMQ實現兩種RPC調用：RPC.CALL基于請求與響應方式，RPC.CAST只是提供單向請求。
??Nova的各個模塊在邏輯功能上可以劃分為兩種：Invoker模塊主要功能是向消息隊列中發送系統請求消息，如Nova-API和Nova-Scheduler；Worker模塊從消息隊列中獲取Invoker模塊發送的系統請求消息以及向Invoker模塊回復系統響應消息，如Nova-Compute、Nova-Volume和Nova-Network。
??（1）Invoker端生成一個Topic消息生產者和一個Direct消息消費者。其中，Topic消息生產者發送系統請求消息到Topic交換器，Direct消息消費者等待響應消息。
??（2）Topic交換器根據消息的Routing Key轉發消息，Topic消費者從相應的消息隊列中接收消息，并傳遞給負責執行相關任務的Worker。
??（3）Worker根據請求消息執行完任務之后，分配一個Direct消息生產者，Direct消息生產者將響應消息發送到Direct交換器。
??（4）Direct交換器根據響應消息的Routing Key轉發至相應的消息隊列，Direct消費者接收并把它傳遞給Invoker。
??RPC.CAST的遠程調用流程與RPC.CALL類似，只是缺少了系統消息響應流程。
