OpenStack入門之核心組件梳理（2）——Nova篇

時間 2020-03-10

標籤 openstack 入門核心組件梳理 nova 简体版

原文原文鏈接

OpenStack入門之核心組件梳理（2）——Nova篇

前言

上篇文章咱們從概念到原理，層層遞進深刻講述了Keystone項目，而本文旨在繼續介紹OpenStack核心組件之一的Nova組件項目。html

相對於Keystone項目，Nova項目是做爲OpenStack這個大開源項目最先也是最成熟的項目，從這一層面上也體現出Nova項目所提供的計算服務從始至終都是OpenStack最爲核心的部分，筆者在以前的文章中談到OpenStack這一開源項目所提供和管理的三大資源就是計算、網絡和管理。這一樣也是雲計算的核心部分。html5

從筆者我的理解和觀點來看的話，對於OpenStack而言，其真正的靈魂（能夠理解爲OpenStack中組件的複雜程度、使用機率以及故障出現機率等方面）一是在於宏觀（這裏「宏觀的意思是相對早期版本的OpenStack平臺而言」）的Nova（計算服務），二是在於相對其餘服務最爲複雜的Neutron網絡服務（以後的文章也會針對該組件進行詳細介紹），這裏不包括CEPH分佈式存儲，由於CEPH自己就是能夠認爲是一個獨立的大項目，其做用不只僅是OpenStack中Swift（對象存儲服務）的高效分佈式集羣存儲的替代，還包括與其餘技術的結合和支持等做用。可是不管在實驗環境仍是生產環境部署OpenStack雲平臺基本上選擇CEPH做爲分佈式存儲服務，固然在此我的補充一下，如果要進行OpenStack實驗環境部署的話，對PC所配的硬件資源要求仍是比較高的，包括CPU、內存、存儲（最好是SSD），筆者所配的基礎硬件資源是i79代CPU、32G內存（三級緩存達到9M）、1T的SSD M.2接口的固態盤，網絡是家用百兆寬帶，固然在實驗環境中未必須要太高的配置，能夠相對下降一些要求，不過若是要想體驗感較好的話仍是高配比較好，若是是決定從事這一方向的工做人員，能夠購置服務器來模擬生產環境，這對初學者並不推薦哈。算法

閒話就再也不多說了，接下來筆者將從其概念概述、主要組件、架構模式、工做原理四個方面介紹Nova項目。數據庫

1、Nova概述與發展

1.1 Nova概念介紹

Nova項目，做爲OpenStack核心項目，提供着十分重要的計算服務，雖然說在其發展過程當中，部分核心組件在後來獨立成爲其餘的核心項目及服務，可是Nova自身的核心地位也是很是之高的，由於瞭解OpenStack基礎理論的朋友都知道OpenStack做爲一種IaaS（基礎設施即服務）的雲計算服務，其最爲核心的服務資源就是計算、存儲和網絡，而計算服務居於首位，在OpenStack雲平臺部署上，則正是經過Nova項目實現其計算服務的。api

之因此前言部分從宏觀角度說Nova項目對於OpenStack是最核心也的項目之一是有其具體緣由的。在早期的OpenStack版本中，項目並非一次規劃好的，而Nova項目在初期就將存儲和網絡包含於自身，及nova-volume和nova-network模塊，即後期獨立出的Cinder(塊存儲服務)和Neutron（網絡服務）。瀏覽器

1.2 Nova發展歷程及具體做用

Nova項目從最初爲雲供應商提供實現IaaS服務的解決方案的初衷，到現在聚焦於大規模可擴展、高可用、可彈性伸縮服務和自助服務的目標，Nova一直在被優化改進升級。在2010年OpenStack項目成立之初，Nova項目主要分爲Nova-Compute、Nova-volume和Nova-network三大功能模塊。在2012年9月OpenStack的Folsom版本發行時，OpenStack社區纔將Nova-volume和Nova-network獨立出來分別構建了Cinder和Quantum項目（後因商標緣由改名爲Neutron項目）。緩存

綜上而言，Nova做爲核心項目，在Linux服務器上做爲一組守護程序運行。固然也須要依賴其餘服務從而實現功能，下面講解原理會着重介紹。其具體的功能主要是：負責管理實例虛擬機的生命週期、網絡管理、存儲卷管理。Nova支持建立虛擬機、裸機服務器（經過使用ironic），而且Nova計算資源的使用限額以項目爲單位進行限制。服務器

2、Nova的主要組件

Nova同Keystone同樣，有組成自身的功能模塊。其是由負責不一樣功能的服務進程構成，Nova對外提供的服務接口爲REST API，其內部組件模塊之間的通訊基於RPC（遠程過程調用）消息傳遞機制的。網絡

下面來看一下組成Nova的一些主要組件：架構

2.1 Nova-API

Nova API服務組件。接收並響應最終用戶的計算API調用請求，當其接收到請求後，一般將請求轉發給Nova的其餘組件進行處理，例如Nova-scheduler。

其遵循特定的策略並初始化大部分的編排操做，例如建立實例。

2.2 Nova-API-Metadata

Nova API服務組件。Nova-API-Metadata服務主要是用於接收來自實例的元數據請求。

2.3 Nova-Compute

Nova核心服務組件。Nova-Compute是一個經過Hypervisor API建立和終止實例的工做進程（在後面的架構中將涉及Hypervisor）。先前筆者對OpenStack節點類型介紹過程當中有所說起，當時考慮到理解程度問題，沒有細說。這裏作一下詳細說明。

在咱們部署OpenStack的計算服務時，一般選擇將Nova-Compute單獨部署在支持虛擬化的物理服務器上，咱們將這個物理服務器稱做爲計算節點。而常見的Hypervisor API有支持KVM/QEMU虛擬化引擎的Libvirt API、適用於XenServer / XCP虛擬化引擎的XenAPI以及支持VMware虛擬化引擎的VMware API。通常狀況下，OpenStack默認使用的是KVM虛擬化引擎，所以在Nova-Compute中最經常使用的仍是Libvirt API。

總之，Nova-Compute主要功能就是接收來自消息隊列的請求，而後執行對應的系統命令的。例如啓動KVM實例並更新其在數據庫中的狀態。

2.4 Nova-Scheduler

Nova核心服務組件。主要負責從隊列中獲取虛擬機實例請求，並肯定其在哪臺計算節點主機上運行。其採用的是過濾計算節點算法，即根據計算節點的CPU、內存和磁盤等參數進行篩選過濾。用戶也能夠經過自定義編輯nova.conf文件來指定過濾算法。

2.5 Nova-Conductor

Nova核心服務組件。Nova-Conductor 主要是爲了使Nova-Compute服務與數據庫（雲數據庫）之間進行交互。也就是說，有了Nova-Conductor，在實際運行中，消除了Nova-Compute服務對雲數據庫的直接訪問，而是經過Nova-Conductor實現對數據庫的訪問。

此外，該組件支持水平擴展到多個節點上同時運行（Nova在水平擴展時採用的是Cell的部署方式），可是不能將之部署到運行Nova-Compute的計算節點上，不然沒法實現Nova-Compute與數據庫之間的隔離。

2.6 Nova-Cert

Nova核心服務組件。Nova-Cert是服務器守候進程，主要爲基於X509認證的Nova Cert提供服務。

2.6 Nova-NoVNCproxy

屬於虛擬機控制檯服務。主要是提供用於經過VNC鏈接訪問正在運行的實例的代理。支持基於瀏覽器的NoVNC客戶端。

2.7 Nova-Spicehtml5proxy

屬於虛擬機控制檯服務。主要提供用於經過SPICE鏈接訪問正在運行的實例的代理。支持基於瀏覽器的HTML5客戶端。Spice是Redhat開源虛擬化桌面的主要組件之一，可以提供與物理桌面徹底相同的最終用戶體驗，Open-Stack官方文檔默認使用的虛擬機桌面訪問方式爲NoVNC，若是用戶須要開啓SPICE協議，則須要將NoVNC關閉。

2.8 QUEUE

Nova以外的核心組件。組件進程間消息交換傳遞的中心，通常用RabbitMQ實現。

2.9 Datebase

Nova以外的核心組件。存儲基礎架構中對象的建立時和運行時的狀態，包括：

可用的實例類型；
使用中的實例；
可用網絡；
項目。

從理論上講，OpenStack Compute能夠支持SQLAlchemy支持的任何數據庫。常見的數據庫是用於測試和開發工做的SQLite3，MySQL，MariaDB和PostgreSQL。

舒適提示：對於初學者理解Nova組件，重點在於理解前面的6個組件。

3、Nova的架構理解

3.1 Nova邏輯架構圖梳理

上兩小節主要介紹了Nova項目的概念做用以及組成，本小節來看一下這些組成之間的聯繫，即Nova的邏輯架構示意圖。

該架構圖表示的是OpenStack 提供的計算服務，該服務是由Nova項目的各個功能組件模塊一塊兒支持的。

其中大部分組件在上一小節進行了介紹，其中，nova-consoleauth也是屬虛擬機控制檯的服務，主要爲虛擬機控制檯鏈接提供認證受權服務的，萬萬不要將其與右上角的nova-console混淆，nova-console是XenAPI風格的控制檯服務，對於多數VNC代理軟件，該組件幾乎再也不使用。

針對上圖可能對其中右下角的Hypervisor有所迷惑。同上文說起的Cell同樣，這裏不可能三言兩語將這二者解釋清楚，筆者在這裏主要針對其做用進行說明。

Hypervisor呢，是運行於物理服務器和操做系統之間的軟件層，主要是調度客戶機系統對共享的物理硬件資源的使用請求，是虛擬化的基礎，也是雲計算的核心基礎。因此上述的Nova-Compute組件就是依賴於Hypervisor API的調用來實現實例的建立以及終止的。

而cell呢，該功能模塊主要是爲了解決大規模Nova計算節點部署過程當中的集羣瓶頸問題，該問題涉及到傳統集羣架構與雲計算架構之間的區別了，有興趣的朋友能夠進行資料查閱。該問題就是共享消息隊列系統的性能在大規模的計算節點部署集羣（上百個，500個以上）大大下降。而有了Cell模塊，就基具有支持OpenStack計算節點水平擴展和大規模部署的能力，本文重點並再也不次，關於Cell的具體原理和實現的過程在這裏就不作詳細介紹了。

此外，經過該架構邏輯圖，能夠發現，在Nova經過相應的服務的時候，各個組件服務之間的通訊都是通過QUEUE實現的，通常默認是RabbitMQ。其實，經過前面的幾篇文章，不難發現一些規律（我的的理解或者說是發現），在OpenStack中，大多數狀況下，通訊通常默認使用的的是消息隊列進行的，數據庫默認爲Mariadb數據庫，調用接口通常基於REST風格的RESTful API進行調用。

上圖僅僅是Nova項目自身的架構圖，那麼Nova和其餘服務是怎樣的架構呢？其實上篇文章在講述Keystone工做響應流程時所舉案例包含了Nova所提供的服務功能。這裏很少敘述。

這裏穿插一些關於Cinder和Neutron項目的結構和組件來講明一下Nova與這二者之間的邏輯架構。

3.2 Nova與Cinder、Neutron之間的邏輯架構

爲何將這三者的邏輯架構在這裏給出呢？一方面是加深對Nova的理解，理解其與其餘一些項目之間的聯繫，例如通訊方式等等，另外一方面就是Nova的發展了，前文說過最初的OpenStack項目，Nova是包含塊存儲和網絡的，現在將這兩者獨立出來，成爲兩個項目，分別對應OpenStack Block Service 和 OpenStack Networking服務。

若是對Cinder和Neutron組件不熟悉也不要緊，這邊主要理解上圖中的三根虛線的含義便可。第四小節將會經過案例來簡述Nova的工做原理。

其中，最上面的一條虛線表示的是Nova-Compute與網絡服務Neutron-server之間的通訊關係，Neutron-server是OpenStack網絡服務提供相應的API做爲訪問Neutron的入口，這表示Nova須要使用Neutron提供的網絡服務爲虛擬機實例之間和虛擬機實例與外網之間的通訊提供服務；

下面兩條虛線表示的是Nova服務與塊存儲服務之間的通訊方式，由cinder中volume和scheduler提供接口與之通訊，這表示Nova須要使用Cinder服務提供塊存儲服務做爲虛擬機實例的磁盤。筆者後期持續更新對各個核心項目的文章中，將會詳細介紹Cinder以及Neutron項目等其餘項目的相關知識。

舒適提示：AMPQ :高級消息隊列協議，能夠理解爲一種通訊協議。

4、Nova的工做原理

其實上文也多多少少涉及了Nova的工做流程以及些許原理，這裏經過一個案例結合圖示來說述理解Nova內部的工做機制。

假設須要用戶須要建立一個虛擬機的場景，這裏涉及到的其餘項目提供的服務就儘可能跳過了，方便理解：

用戶經過控制檯（也能夠是命令行等其餘方式）獲取認證後向Nova服務中的Nova-api發送一個"請爲我建立一個虛擬機實例"的請求；
Nova-api接收到請求後進行身份驗證，以後進行必要的處理，而後將建立虛擬機實例的消息存到隊列中；
Nova-scheduler從消息隊列中接收到消息，開始進行調度，從諸多個計算節點中選擇一個節點，而且將"容許在計算節點1上建立虛擬機實例"的信息存放到隊列中；
計算節點1的Nova-compute獲取該信息後再自身節點上開始執行建立虛擬機的操做；
建立虛擬機的同時，計算節點能夠經過消息隊列向Nova-Conductor發送查詢數據庫的信息的消息，那麼Conductor收到該信息後就會去訪問數據庫並給出迴應消息；

經過上面的案例將Nova的組件之間的關係梳理的同時，針對其內部工做原理進行理解。

不過在實際的OpenStack系統運行過程當中，Nova計算服務是須要和其餘的服務進行交互的，例如經過與認證受權服務Keystone交互從而實現身份權限的識別認證過程，並經過OpenStack的鏡像服務Glance爲實例提供系統鏡像，而用戶和雲管理員則經過OpenStack的控制面板服務Horizon與Nova進行交互等等。