一、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 的架構比較復雜，包含很多組件。 這些組件以子服務（后台 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：
虛機調度服務，負責決定在哪個計算節點上運行虛機。創建 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 證書支持
二、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配置文件：
[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]