前篇講了hypervisor概述及其管理，但是nova創(chuàng)建一個(gè)虛機(jī)都要給哪些模塊交互呢？

OpenStack實(shí)例創(chuàng)建過程

在OpenStack中創(chuàng)建實(shí)例的大致流程為：

[1,2]用戶通過Dashboard界面或命令行發(fā)起實(shí)例創(chuàng)建請(qǐng)求，Keystone從請(qǐng)求中獲取用戶相關(guān)信息并進(jìn)行身份驗(yàn)證；

[3] 驗(yàn)證通過后，用戶獲得認(rèn)證Token，實(shí)例創(chuàng)建請(qǐng)求進(jìn)入Nova-api；

[4,5] 在向Keystone驗(yàn)證用戶Token有效后，Nova-api([6,7]將信息存入Nova DB，[8]然后將請(qǐng)求放入Queue消息隊(duì)列)[9]將請(qǐng)求轉(zhuǎn)入Nova-scheduler;

Nova-scheduler([10,11]從Nova DB獲取虛機(jī)信息)進(jìn)行實(shí)例創(chuàng)建目的主機(jī)的調(diào)度選擇，目標(biāo)主機(jī)選取完成后，([12]將請(qǐng)求放入Queue消息隊(duì)列)[13]請(qǐng)求轉(zhuǎn)入Nova-compute;

Nova-compute([14]將請(qǐng)求再次放入Queue消息隊(duì)列)與Nova-conductor[15]([16,17]從Nova DB獲取虛機(jī)信息)交互以獲取創(chuàng)建實(shí)例的信息，在成功獲取實(shí)例信息后，Nova-compute[18,14]分別與Glance[19,21](glance-api)、Neutron[24,22](neutron server)和Cinder[25,27](Cinder-api)交互以獲取鏡像資源、網(wǎng)絡(luò)資源和云存儲(chǔ)資源；

一切資源準(zhǔn)備就緒后，Nova-compute便通過Libvirt API與具體的Hypervisor交互[28]并創(chuàng)建虛擬機(jī)。

[20,23,26]分別為Glance(glance-api)、Neutron(neutron server)和Cinder(Cinder-api)收到nova-compute請(qǐng)求，將其token帶到keystone進(jìn)行驗(yàn)證，驗(yàn)證通過后再處理流程。

從nova創(chuàng)建虛機(jī)的流程看出來涉及到模塊包括Keystone，nova的nova-api/nova-scheduler/nova-conductor/nova-compute/glance/neutron/cinder。下面從每個(gè)模塊的角色來講述各自的實(shí)現(xiàn)，見1、2、3、4、5。創(chuàng)建虛機(jī)過程中的狀態(tài)變更見6。

1．Keystone工作流程

任何終端用戶在與OpenStack的服務(wù)項(xiàng)目交互時(shí)，第一步便是進(jìn)行身份認(rèn)證與授權(quán)，而Keystone負(fù)責(zé)OpenStack全部項(xiàng)目的認(rèn)證與授權(quán)任務(wù)。Nova-api/glance-api/neutron-server/glance-api都是首先和keystone交互，獲取token或驗(yàn)證token成功后再繼續(xù)業(yè)務(wù)邏輯處理。

Nova客戶端通過Keystone的身份驗(yàn)證(用戶名、密碼和項(xiàng)目project，可能還有https的證書)，則Keystone為其生成授權(quán)Token，并將此Token存儲(chǔ)到后端數(shù)據(jù)庫中。Keystone的后端數(shù)據(jù)庫可以是SQL數(shù)據(jù)庫，也可以是如Memcache這樣的緩存系統(tǒng)。為了快速響應(yīng)后續(xù)OpenStack服務(wù)組件發(fā)起的Token核實(shí)過程，建議盡量使用基于內(nèi)存的緩存系統(tǒng)作為Keystone的后端存儲(chǔ)數(shù)據(jù)庫。Keystone的身份驗(yàn)證過程可以在本地進(jìn)行，也可以通過LDAP服務(wù)器進(jìn)行身份驗(yàn)證，以nova客戶端為例，原理圖如下

Nova客戶端身份驗(yàn)證與授權(quán)

2．Nova-api工作流程

Nova-api向Keystone驗(yàn)證Token的有效性成功后，Nova-api開始判斷實(shí)例創(chuàng)建請(qǐng)求所攜帶的參數(shù)是否有效合法：

1) 檢查虛擬機(jī)名字是否符合命名規(guī)范；

2) 使用的虛擬機(jī)模板flavor_id在數(shù)據(jù)庫中是否存在；

3) 使用的鏡像image_uuid是否是有效的uuid格式；

4) 檢查instance、vCPU、RAM的數(shù)量是否超出了配置文件中的限制，通常每個(gè)Project擁有的資源都是有限的；

5) 檢查相關(guān)metadata的長(zhǎng)度是否超過限制，inject_files的數(shù)目是否超過限制，一般情況下這些參數(shù)都為空；

6) 檢查請(qǐng)求中的network是否存在且可用；

7) image和flavor是否存在且可用，同時(shí)還會(huì)檢測(cè)請(qǐng)求中flavor的磁盤是否滿足image需求等；

當(dāng)所有資源檢查都通過后，Nova-api便在nova數(shù)據(jù)庫中初始化虛擬機(jī)相關(guān)的記錄（intial entry），主要包括instance、block_device_mapping和quota等記錄，并將instance記錄中的vm_states字段設(shè)為building，task_state字段設(shè)為scheduling。

然后Nova-api調(diào)用Nova-conductor并將請(qǐng)求傳遞到消息隊(duì)列（MQ）中。由于Nova-api將請(qǐng)求以RPC cast的方式發(fā)送給Nova-conductor，而cast()方法發(fā)送的請(qǐng)求并不會(huì)返回消息，因此Nova客戶端此時(shí)只會(huì)接收到請(qǐng)求已被接受的返回，但是具體的虛擬創(chuàng)建過程還在后臺(tái)繼續(xù)執(zhí)行，而Nova客戶端可以查到的虛擬機(jī)vmstate為building，task_state為scheduling(估計(jì)是從數(shù)據(jù)庫中查到的，其他信息沒有返回就查不到)。

nova-api在虛機(jī)創(chuàng)建過程的流程圖

3．Nova-conductor工作流程

在Nova各個(gè)組件中，除Nova-api需要接受外部請(qǐng)求外，其他組件僅進(jìn)行彼此之間的交互調(diào)用，并且組件之間的交互以RPC調(diào)用的方式通過消息隊(duì)列來實(shí)現(xiàn)。

由于Nova-conductor提供了build_instances()這個(gè)RPC方法，因此一直處于消息隊(duì)列監(jiān)聽狀態(tài)，一旦監(jiān)聽的隊(duì)列有消息進(jìn)入，Nova-conductor便開始執(zhí)行build_instances()方法。

Nova-conductor向Nova-schduler發(fā)出RPC call調(diào)用，并要求其返回計(jì)算節(jié)點(diǎn)調(diào)度結(jié)果，在收到Nova-scheduler的調(diào)度結(jié)果后，Nova-conductor的build_instances()方法將請(qǐng)求傳遞到Nova-compute的消息隊(duì)列中。

Nova-conductor在虛機(jī)創(chuàng)建過程的流程圖

4．Nova-scheduler工作流程

Nova-scheduler的功能是負(fù)責(zé)監(jiān)聽消息隊(duì)列，并在獲取消息隊(duì)列之后進(jìn)行計(jì)算節(jié)點(diǎn)的調(diào)度選取，同時(shí)將調(diào)度結(jié)果傳遞給消息隊(duì)列。

為了獲取創(chuàng)建實(shí)例的目標(biāo)主機(jī)，Nova-conductor會(huì)向Nova-scheduler發(fā)起RPC call調(diào)用，并調(diào)用Nova-scheduler的select_destin-ations()方法；Nova-scheduler在消息隊(duì)列中接收到調(diào)用消息后，根據(jù)nova.conf配置文件中關(guān)于Filters和Weight的配置參數(shù)對(duì)計(jì)算節(jié)點(diǎn)主機(jī)列表進(jìn)行過濾和加權(quán)調(diào)度，在這個(gè)過程中，Nova-scheduler需要訪問數(shù)據(jù)庫以獲取節(jié)點(diǎn)相關(guān)的信息；在獲取信息后，Nova-scheduler便開始進(jìn)行節(jié)點(diǎn)調(diào)度，默認(rèn)使用的調(diào)度驅(qū)動(dòng)為FilterScheduler，調(diào)度完成之后，將節(jié)點(diǎn)調(diào)度結(jié)果傳遞到消息隊(duì)列，以完成Nova-conductor的RPC call調(diào)用過程。

nova-scheduler在虛機(jī)創(chuàng)建過程的流程圖

5．Nova-compute工作流程

Nova-compute是Nova服務(wù)項(xiàng)目中最復(fù)雜和最關(guān)鍵的組件，運(yùn)行Nova-compute的節(jié)點(diǎn)稱為計(jì)算節(jié)點(diǎn)，通常Nova-compute部署在獨(dú)立的計(jì)算節(jié)點(diǎn)上，并與Nova項(xiàng)目的其他組件分開部署。在實(shí)例創(chuàng)建過程中，Nova-compute隨時(shí)監(jiān)聽topic:compute-computeN（computeN為計(jì)算節(jié)點(diǎn)名稱）消息隊(duì)列，在監(jiān)聽到Nova-conductor傳遞的實(shí)例創(chuàng)建請(qǐng)求后，Nova-compute開始啟動(dòng)內(nèi)部工作流程以響應(yīng)實(shí)例創(chuàng)建請(qǐng)求。在Nova-api的工作流程中，請(qǐng)求中創(chuàng)建實(shí)例所需的鏡像、網(wǎng)絡(luò)和存儲(chǔ)等資源已經(jīng)做過有效性和可用性的檢查，因此Nova-compute將直接與Glance交互以獲取鏡像資源，與Cinder交互獲取塊存儲(chǔ)資源。如果配置了Ceph塊存儲(chǔ)或?qū)ο蟠鎯?chǔ)服務(wù)，Nova-compute還會(huì)與Ceph RADOS進(jìn)行交互以訪問Ceph存儲(chǔ)集群。Nova-compute與Glance、Cidner和Ceph的交互訪問流程如圖所示

Nova-compute與Glance、Cidner和Ceph的交互訪問流程

在獲取鏡像和存儲(chǔ)資源后，Nova-compute還需與OpenStack的網(wǎng)絡(luò)服務(wù)項(xiàng)目Neutron進(jìn)行交互訪問以獲取網(wǎng)絡(luò)資源。由于網(wǎng)絡(luò)資源的有效性和可用性已經(jīng)在Nova-api工作流程中完成，這里主要是獲取虛擬機(jī)的Fixed IP等網(wǎng)絡(luò)資源。Nova-compute與Neutron的交互過程如圖。

Nova-compute與Neutron交互獲取網(wǎng)絡(luò)資源

在準(zhǔn)備好常見實(shí)例所需的一切資源后，Nova-compute將通過Libvirt與對(duì)應(yīng)的Hyper-visor API進(jìn)行交互，并通過Libvirt API接口進(jìn)行虛擬機(jī)的創(chuàng)建工作。Nova-compute與Libvirt交互創(chuàng)建實(shí)例的過程如圖。

Nova-compute與Libvirt交互創(chuàng)建虛擬機(jī)

6. Nova實(shí)例狀態(tài)變更

在虛擬機(jī)實(shí)例的創(chuàng)建和運(yùn)行維護(hù)過程中，Nova使用三個(gè)變量來描述虛擬機(jī)當(dāng)前的狀態(tài)，分別為vm_state、power_state和task_state。其中，power_state代表虛擬機(jī)電源狀態(tài)，其本質(zhì)上反應(yīng)的是Hypervisor的狀態(tài)，其狀態(tài)值遵循“由下至上（bottom-up）”的變更過程，即先是底層計(jì)算節(jié)點(diǎn)上Hypervisor狀態(tài)變更，然后上層數(shù)據(jù)庫對(duì)應(yīng)值變更；vm_state反應(yīng)的是基于API調(diào)用的一種穩(wěn)定狀態(tài)，其狀態(tài)變更比較符合用戶的邏輯思維，是一種由上至下（top-down）的API實(shí)現(xiàn)過程；task_state代表的是API調(diào)用過程中的過渡狀態(tài)，反映了不同階段所調(diào)用API對(duì)實(shí)例進(jìn)行的操作。

實(shí)例創(chuàng)建過程中的vm_state、power_state和task_state狀態(tài)值

1)．power_State

power_state是Nova程序調(diào)用特定虛擬機(jī)上的虛擬驅(qū)動(dòng)所獲取的狀態(tài)。數(shù)據(jù)庫中關(guān)于特定實(shí)例的power_state值僅是虛擬機(jī)最近一段時(shí)間的快照值，并不能真正反映當(dāng)前虛擬機(jī)的實(shí)際power_state，虛擬機(jī)當(dāng)前power_state的實(shí)際值位于Hypervisor中。

計(jì)算節(jié)點(diǎn)首先報(bào)告虛擬機(jī)power_state已經(jīng)更新，然后再刷新數(shù)據(jù)庫中的power_state字段值。power_state狀態(tài)值衍生自Libvirt（其中BLOCKED狀態(tài)值也被丟棄），其本質(zhì)上代表的是RUNNING狀態(tài)，SHUTOFF被映射為SHUTDOWN狀態(tài)，F(xiàn)AILED被映射為NOSTATE狀態(tài)，因此power_state目前有RUNNING、SHUTDOWN和NOSTATE三種狀態(tài)。

2)．vm_State

vm_state狀態(tài)值是對(duì)虛擬機(jī)當(dāng)前穩(wěn)定狀態(tài)的描述，而不是過渡狀態(tài)。也就是說，如果針對(duì)特定虛擬機(jī)已經(jīng)沒有API繼續(xù)調(diào)用，則應(yīng)該用vm_state來描述此時(shí)虛擬機(jī)的穩(wěn)定狀態(tài)。

vm_state狀態(tài)值更新的前提是針對(duì)此虛擬機(jī)有任務(wù)發(fā)生，并且任務(wù)成功完成，同時(shí)task_state被置為NOSTATE。如果沒有API調(diào)用發(fā)生，則vm_state狀態(tài)值絕對(duì)不會(huì)改變；如果對(duì)虛擬機(jī)的操作任務(wù)失敗，但是成功回滾（rollback），則vm_state狀態(tài)值也不會(huì)改變；如果不能回滾成功，則vm_state被置為ERROR狀態(tài)。

3)．task_state

task_state代表的是過渡狀態(tài)，并且與調(diào)用的API函數(shù)密切相關(guān)，其狀態(tài)值描述了虛擬機(jī)當(dāng)前正在執(zhí)行的任務(wù)。只有對(duì)虛擬機(jī)發(fā)起了操作任務(wù)時(shí)，才會(huì)有task_state狀態(tài)值出現(xiàn)，而當(dāng)vm_state處于穩(wěn)定值時(shí)，task_state通常為NOSTATE。task_state有5種狀態(tài)包括Scheduling、None、Networking、Block_Device_Mapping和Spawning。

其他服務(wù)說明

如果要使用虛擬網(wǎng)絡(luò)控制臺(tái)VNC與實(shí)例交互，則Nova-consoleauth和Nova-novncproxy是必須的；

如果使用AWS風(fēng)格API，則Nova-cert和Nova-objectstore是必須的。

筆記整理來自山金孝的《OpenStack高可用集群（上冊(cè)）：原理與架構(gòu)》8.6章節(jié)，如有侵權(quán)請(qǐng)通知?jiǎng)h除