雲計算openstack核心組件——nova計算服務

一、nova介紹：

      Nova 是 OpenStack 最核心的服務，負責維護和管理雲環境的計算資源。OpenStack 作為 IaaS 的雲操作系統，虛擬機生命周期管理也就是通過 Nova 來實現的。

 

用途與功能 :

1) 實例生命周期管理

2) 管理計算資源

3) 網絡和認證管理

4)REST 風格的 API

5) 異步的一致性通信

6)Hypervisor 透明：支持Xen,XenServer/XCP,KVM, UML, VMware vSphere and Hyper-V

 

 

在上圖中可以看到，Nova 處於 Openstak 架構的中心，其他組件都為 Nova 提供支持： Glance 為 VM 提供 image Cinder 和 Swift 分別為 VM 提供塊存儲和對象存儲 Neutron 為 VM 提供網絡連接。

 

Nova 架構如下：

 

Nova 的架構比較復雜，包含很多組件。 這些組件以子服務（后台 deamon 進程）的形式運行，可以分為以下幾類：

 

API

 

nova-api

是整個 Nova 組件的門戶，接收和響應客戶的 API 調用。所有對 Nova 的請求都首先由 nova-api 處理。nova-api 向外界暴露若干 HTTP REST API 接口 在 keystone 中我們可以查詢 nova-api 的 endponits。

客戶端就可以將請求發送到 endponits 指定的地址，向 nova-api 請求操作。 當然，作為最終用戶的我們不會直接發送 Rest AP I請求。 OpenStack CLI，Dashboard 和其他需要跟 Nova 交換的組件會使用這些 API。

 

Nova-api 對接收到的 HTTP API 請求會做如下處理：

1. 檢查客戶端傳入的參數是否合法有效

2. 調用 Nova 其他子服務的處理客戶端 HTTP 請求

3. 格式化 Nova 其他子服務返回的結果並返回給客戶端

 

nova-api 接收哪些請求？

簡單的說，只要是跟虛擬機生命周期相關的操作，nova-api 都可以響應。 大部分操作都可以在 Dashboard 上找到。打開Instance管理界面

除了提供 OpenStack 自己的API，nova-api 還支持 Amazon EC2 API。 也就是說，如果客戶以前使用 Amazon EC2，並且用 EC2 的 API 開發了些工具來管理虛機，那么如果現在要換成 OpenStack，這些工具可以無縫遷移到 OpenStack，因為 nova-api 兼容 EC2 API，無需做任何修改。

 

Compute Core

 

a）nova-scheduler：1

虛機調度服務，負責決定在哪個計算節點上運行虛機。創建 Instance 時，用戶會提出資源需求，例如 CPU、內存、磁盤各需要多少。OpenStack 將這些需求定義在 flavor 中，用戶只需要指定用哪個 flavor 就可以了。

可用的 flavor 在 System->Flavors 中管理。

 

下面介紹 nova-scheduler 是如何實現調度的。在 /etc/nova/nova.conf 中，nova 通過 driver=filter_scheduler 這個參數來配置 nova-scheduler。

driver=filter_scheduler

 

Filter scheduler

Filter scheduler 是 nova-scheduler 默認的調度器，調度過程分為兩步：

1. 通過過濾器（filter）選擇滿足條件的計算節點（運行 nova-compute）

2. 通過權重計算（weighting）選擇在最優（權重值最大）的計算節點上創建 Instance。

 

Nova 允許使用第三方 scheduler，配置 scheduler_driver 即可。 這又一次體現了OpenStack的開放性。Scheduler 可以使用多個 filter 依次進行過濾，過濾之后的節點再通過計算權重選出最適合的節點。

上圖是調度過程的一個示例：

1. 最開始有 6 個計算節點 Host1-Host6

2. 通過多個 filter 層層過濾，Host2 和 Host4 沒有通過，被刷掉了

3. Host1，Host3，Host5，Host6 計算權重，結果 Host5 得分最高，最終入選

 

當 Filter scheduler 需要執行調度操作時，會讓 filter 對計算節點進行判斷，filter 返回 True 或 False。經過前面一堆 filter 的過濾，nova-scheduler 選出了能夠部署 instance 的計算節點。

 

如果有多個計算節點通過了過濾，那么最終選擇哪個節點呢？

 

Scheduler 會對每個計算節點打分，得分最高的獲勝。 打分的過程就是 weight，翻譯過來就是計算權重值，那么 scheduler 是根據什么來計算權重值呢？ 

 

目前 nova-scheduler 的默認實現是根據計算節點空閑的內存量計算權重值： 空閑內存越多，權重越大，instance 將被部署到當前空閑內存最多的計算節點上。

 

 

b）nova-compute：

nova-compute 是管理虛機的核心服務，在計算節點上運行。通過調用Hypervisor API實現節點上的 instance的生命周期管理。 OpenStack 對 instance 的操作，最后都是交給 nova-compute 來完成的。 nova-compute 與 Hypervisor 一起實現 OpenStack 對 instance 生命周期的管理。

Openstack中虛機默認的保存路徑在：/var/lib/nova/instances

 

通過Driver架構支持多種Hypervisor

Hypervisor是計算節點上跑的虛擬化管理程序，虛機管理最底層的程序。 不同虛擬化技術提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM，Xen， VMWare 等。nova-compute 為這些 Hypervisor 定義了統一的接口，Hypervisor 只需要實現這些接口，就可以 Driver 的形式即插即用到 OpenStack 系統中。 下面是Nova Driver的架構示意圖：

 

 

 

c）nova-conductor：

nova-compute 經常需要更新數據庫，比如更新和獲取虛機的狀態。 出於安全性和伸縮性的考慮，nova-compute 並不會直接訪問數據庫，而是將這個任務委托給 nova-conductor。

這樣做有兩個顯著好處：

1. 更高的系統安全性

2. 更好的系統伸縮性

 

 

Console Interface

 

nova-console： 用戶可以通過多種方式訪問虛機的控制台：

nova-novncproxy： 基於 Web 瀏覽器的 VNC 訪問

nova-spicehtml5proxy： 基於 HTML5 瀏覽器的 SPICE 訪問

nova-xvpnvncproxy： 基於 Java 客戶端的 VNC 訪問

nova-consoleauth： 負責對訪問虛機控制台請求提供 Token 認證

nova-cert： 提供 x509 證書支持

 

Database

 

Nova 會有一些數據需要存放到數據庫中，一般使用 MySQL。數據庫安裝在控制節點上。 Nova 使用命名為 “nova” 的數據庫。

 

 

Message Queue

在前面我們了解到 Nova 包含眾多的子服務，這些子服務之間需要相互協調和通信。為解耦各個子服務，Nova 通過 Message Queue 作為子服務的信息中轉站。 所以在架構圖上我們看到了子服務之間沒有直接的連線，是通過 Message Queue 聯系的。

 

 

OpenStack 默認是用 RabbitMQ 作為 Message Queue。 MQ 是 OpenStack 的核心基礎組件，我們后面也會詳細介紹。

 

 

二、Nova 組件如何協同工作

 

Nova 物理部署方案                                                                                       

 

       前面大家已經看到 Nova 由很多子服務組成，我們也知道 OpenStack 是一個分布式系統，可以部署到若干節點上，那么接下來大家可能就會問：Nova 的這些服務在物理上應該如何部署呢？

 

對於 Nova，這些服務會部署在兩類節點上：計算節點和控制節點。

 

計算節點上安裝了 Hypervisor，上面運行虛擬機。 由此可知：

1. 只有 nova-compute 需要放在計算節點上。

2. 其他子服務則是放在控制節點上的。

 

下面我們可以看看實驗環境的具體部署情況。 通過在計算節點和控制節點上運行

ps -elf | grep nova 來查看運行的 nova 子服務

計算節點compute只運行了nova-compute子服務

 

控制節點controller運行了若干nova-*子服務

 

RabbitMQ 和 MySQL 也是放在控制節點上的。可能細心的同學已經發現我們的控制節點上也運行了 nova-compute。 這實際上也就意味着 devstack-controller 既是一個控制節點，同時也是一個計算節點，也可以在上面運行虛機。

 

這也向我們展示了 OpenStack 這種分布式架構部署上的靈活性： 可以將所有服務都放在一台物理機上，作為一個 All-in-One 的測試環境； 也可以將服務部署在多台物理機上，獲得更好的性能和高可用。

 

另外，也可以用 nova service-list 查看 nova-* 子服務都分布在哪些節點上

 

 

從虛機創建流程看 nova-* 子服務如何協同工作                                    

      

     從學習 Nova 的角度看，虛機創建是一個非常好的場景，涉及的 nova-* 子服務很全，下面是流程圖。

 

1. 客戶（可以是 OpenStack 最終用戶，也可以是其他程序）向 API（nova-api）發送請求：“幫我創建一個虛機”

    
2. API 對請求做一些必要處理后，向 Messaging（RabbitMQ）發送了一條消息：“讓 Scheduler 創建一個虛機”

    
3. Scheduler（nova-scheduler）從 Messaging 獲取到 API 發給它的消息，然后執行調度算法，從若干計算節點中選出節點 A

    
4. Scheduler 向 Messaging 發送了一條消息：“在計算節點 A 上創建這個虛機”

    
5. 計算節點 A 的 Compute（nova-compute）從 Messaging 中獲取到 Scheduler 發給它的消息，然后在本節點的 Hypervisor 上啟動虛機。

    
6. 在虛機創建的過程中，Compute 如果需要查詢或更新數據庫信息，會通過 Messaging 向 Conductor（nova-conductor）發送消息，Conductor 負責數據庫訪問。

    

以上是創建虛機最核心的步驟， 這幾個步驟向我們展示了 nova-* 子服務之間的協作的方式，也體現了 OpenStack 整個系統的分布式設計思想，掌握這種思想對我們深入理解 OpenStack 會非常有幫助。

 

三、Nova 創建虛擬機詳細過程

 

 

1、界面或命令行通過RESTful API向keystone獲取認證信息。

2、keystone通過用戶請求認證信息，並生成auth-token返回給對應的認證請求。

3、界面或命令行通過RESTful API向nova-api發送一個boot instance的請求（攜帶auth-token）。

4、nova-api接受請求后向keystone發送認證請求，查看token是否為有效用戶和token。

5、keystone驗證token是否有效，如有效則返回有效的認證和對應的角色（注：有些操作需要有角色權限才能操作）。

6、通過認證后nova-api和數據庫通訊。

7、初始化新建虛擬機的數據庫記錄。

8、nova-api通過rpc.call向nova-scheduler請求是否有創建虛擬機的資源(Host ID)。

9、nova-scheduler進程偵聽消息隊列，獲取nova-api的請求。

10、nova-scheduler通過查詢nova數據庫中計算資源的情況，並通過調度算法計算符合虛擬機創建需要的主機。

11、對於有符合虛擬機創建的主機，nova-scheduler更新數據庫中虛擬機對應的物理主機信息。

12、nova-scheduler通過rpc.cast向nova-compute發送對應的創建虛擬機請求的消息。

13、nova-compute會從對應的消息隊列中獲取創建虛擬機請求的消息。

14、nova-compute通過rpc.call向nova-conductor請求獲取虛擬機消息。（Flavor）

15、nova-conductor從消息隊隊列中拿到nova-compute請求消息。

16、nova-conductor根據消息查詢虛擬機對應的信息。

17、nova-conductor從數據庫中獲得虛擬機對應信息。

18、nova-conductor把虛擬機信息通過消息的方式發送到消息隊列中。

19、nova-compute從對應的消息隊列中獲取虛擬機信息消息。

20、nova-compute通過keystone的RESTfull API拿到認證的token，並通過HTTP請求glance-api獲取創建虛擬機所需要鏡像。

21、glance-api向keystone認證token是否有效，並返回驗證結果。

22、token驗證通過，nova-compute獲得虛擬機鏡像信息(URL)。

23、nova-compute通過keystone的RESTfull API拿到認證k的token，並通過HTTP請求neutron-server獲取創建虛擬機所需要的網絡信息。

24、neutron-server向keystone認證token是否有效，並返回驗證結果。

25、token驗證通過，nova-compute獲得虛擬機網絡信息。

26、nova-compute通過keystone的RESTfull API拿到認證的token，並通過HTTP請求cinder-api獲取創建虛擬機所需要的持久化存儲信息。

27、cinder-api向keystone認證token是否有效，並返回驗證結果。

28、token驗證通過，nova-compute獲得虛擬機持久化存儲信息。

29、nova-compute根據instance的信息調用配置的虛擬化驅動來創建虛擬機。

四、徹底刪除nova-compute節點

1、控制節點上操作查看計算節點，刪除node1

1 2	openstack host list nova service-list

2、將node1上的計算服務設置為down，然后disabled

1 2	systemctl stop openstack-nova-compute nova service-list

1 2	nova service-disable node1 nova-compute nova service-list

3、在數據庫里清理（nova庫）

（1）參看現在數據庫狀態

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

[root@node1 ~] # mysql -u root -p Enter password: Welcome to the MariaDB monitor.  Commands end with ; or \g. Your MariaDB connection id  is 90 Server version: 10.1.20-MariaDB MariaDB Server   Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.   Type 'help;'  or '\h'  for  help. Type '\c'  to clear  the current input statement.   MariaDB [(none)]> use nova; Reading table information for  completion of table and column names You can turn off this feature to get a quicker startup with -A   Database changed MariaDB [nova]> select  host from nova.services; +---------+ | host    | +---------+ | 0.0.0.0 | | 0.0.0.0 | | node1   | | node1   | | node1   | | node1   | | node2   | +---------+ 7 rows in  set  (0.00 sec)   MariaDB [nova]> select  hypervisor_hostname from compute_nodes; +---------------------+ | hypervisor_hostname | +---------------------+ | node1               | | node2               | +---------------------+ 2 rows in  set  (0.00 sec)

 （2）刪除數據庫中的node1節點信息

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

MariaDB [nova]> delete from nova.services where host= "node1" ; Query OK, 4 rows affected (0.01 sec)   MariaDB [nova]> delete from compute_nodes where hypervisor_hostname= "node1" ; Query OK, 1 row affected (0.00 sec)   MariaDB [nova]> MariaDB [nova]> MariaDB [nova]> MariaDB [nova]> select  host from nova.services; +---------+ | host    | +---------+ | 0.0.0.0 | | 0.0.0.0 | | node2   | +---------+ 3 rows in  set  (0.00 sec)   MariaDB [nova]> select  hypervisor_hostname from compute_nodes; +---------------------+ | hypervisor_hostname | +---------------------+ | node2               | +---------------------+ 1 row in  set  (0.00 sec)   MariaDB [nova]>

 

五、nova配置文件：

[DEFAULT]

my_ip=172.16.254.63

use_neutron = True

firewall_driver = nova.virt.firewall.NoopFirewallDriver

enabled_apis=osapi_compute,metadata

transport_url =  rabbit://openstack:admin@controller

 

[api]

auth_strategy = keystone

 

[api_database]

connection = mysql+ pymysql://nova:NOVA_DBPASS@controller/nova_api

 

[barbican]

 

[cache]

 

[cells]

 

[cinder]

os_region_name = RegionOne

 

[cloudpipe]

 

[conductor]

 

[console]

 

[consoleauth]

 

[cors]

 

[cors.subdomain]

 

[crypto]

 

[database]

connection = mysql+ pymysql://nova:NOVA_DBPASS@controller/nova

 

[ephemeral_storage_encryption]

 

[filter_scheduler]

 

[glance]

api_servers =  http://controller:9292

 

[guestfs]

 

[healthcheck]

 

[hyperv]

 

[image_file_url]

 

[ironic]

 

[key_manager]

 

[keystone_authtoken]

auth_uri =  http://controller:5000

auth_url =  http://controller:35357

memcached_servers = controller:11211

auth_type = password

project_domain_name = default

user_domain_name = default

project_name = service

username = nova

password = nova

 

[libvirt]

virt_type=qemu

 

[matchmaker_redis]

 

[metrics]

 

[mks]

 

[neutron]

url =  http://controller:9696

auth_url =  http://controller:35357

auth_type = password

project_domain_name = default

user_domain_name = default

region_name = RegionOne

project_name = service

username = neutron

password = neutron

service_metadata_proxy = true

metadata_proxy_shared_secret = METADATA_SECRET

 

[notifications]

 

[osapi_v21]

 

[oslo_concurrency]

lock_path=/var/lib/nova/tmp

 

[oslo_messaging_amqp]

 

[oslo_messaging_kafka]

 

[oslo_messaging_notifications]

 

[oslo_messaging_rabbit]

 

[oslo_messaging_zmq]

 

[oslo_middleware]

 

[oslo_policy]

 

[pci]

[placement]

os_region_name = RegionOne

auth_type = password

auth_url =  http://controller:35357/v3

project_name = service

project_domain_name = Default

username = placement

password = placement

user_domain_name = Default

 

[quota]

 

[rdp]

 

[remote_debug]

 

[scheduler]

 

[serial_console]

 

[service_user]

 

[spice]

 

[ssl]

 

[trusted_computing]

 

[upgrade_levels]

 

[vendordata_dynamic_auth]

 

[vmware]

 

[vnc]

enabled=true

vncserver_listen=$my_ip

vncserver_proxyclient_address=$my_ip

novncproxy_base_url =  http://172.16.254.63:6080/vnc_auto.html

 

[workarounds]

 

[wsgi]

 

[xenserver]

 

[xvp]