https://yikun.github.io/2017/09/27/OpenStack-Nova%E8%99%9A%E6%8B%9F%E6%9C%BA%E5%88%9B%E5%BB%BA%E6%B5%81%E7%A8%8B%E8%A7%A3%E6%9E%90/html
1. 概述
Nova是OpenStack中處理計算業務（虛擬機、裸機、容器）的組件，總體的虛擬機建立流程天然是學習和熟悉Nova組件的第一步。本篇文章主要基於OpenStack Pike版本，基於最新的Cell v2架構部署爲例，來介紹虛擬機的建立流程，並分析了Pike等最近幾個版本中，虛擬機建立流程的關鍵變化。python
2. 虛擬機建立流程
上圖是虛擬機建立流程的總體流程，能夠看到總體虛擬機建立流程一次通過了API、Conductor、Scheduler、Placement、Compute等主要服務，下面咱們逐步介紹下虛擬機建立時，這些服務作的一些事情以及在Pike版本新引入的部分：git
2.1 Nova-API
在OpenStack的組件中，基本每一個組件都會有一個API服務，對於Nova來講API服務主要的做用就是接收由用戶經過Client或者一些其餘REST請求工具（好比 curl、postman）發送的請求。通常來講會包含一些虛擬機建立的參數，好比虛擬機的規格、可用域之類的信息。github
在虛擬機建立的流程中，API就是Nova的入口，當API接收到請求後，主要會處理一些關於參數校驗、配額檢測等事務。數據庫
1. 參數校驗
例如，咱們指定鏡像和規格來建立一個虛擬機時，一般會使用：json
|
1
|
nova --debug boot --image 81e58b1a-4732-4255-b4f8-c844430485d2 --flavor 1 yikun
|
咱們經過--debug來開啓debug模式，來看看命令行究竟作了什麼事，能夠從回顯中，看到一個關鍵的信息：api
curl -g -i -X POST http://xxx.xxx.xxx.xxx/compute/v2.1/servers -H 「Accept: application/json」 -H 「User-Agent: python-novaclient」 -H 「OpenStack-API-Version: compute 2.53」 -H 「X-OpenStack-Nova-API-Version: 2.53」 -H 「X-Auth-Token: $token」 -H 「Content-Type: application/json」 -d ‘{「server」: {「name」: 「yikun」, 「imageRef」: 「81e58b1a-4732-4255-b4f8-c844430485d2」, 「flavorRef」: 「1」, 「max_count」: 1, 「min_count」: 1, 「networks」: 「auto」}}’網絡
咱們能夠看到虛擬機建立時，傳入了一些諸如虛擬機名稱、鏡像、規格、個數、網絡等基本信息。在API中，首先就會對這些參數進行校驗，好比鏡像ID是否合法、網絡是否正確等。數據結構
2. 配額檢測
值得一提的是，在Pike版本的虛擬機建立開始時，對配額檢測進行了優化。架構
我先看看以前的實現，在以前版本的Nova中，Quota檢測過程相對來講比較複雜，首先會進行reserve操做，對資源進行預佔，而後預佔成功，而且建立成功後，最終會進行commit操做。然而，爲了保證在併發的場景下，不會對超過用戶配額（這都是錢啊！），所以在reserve和commit進行資源更新的時候都會quota相關的數據表的用戶相關行加把鎖，也就是說更新quota記錄的時候，一個用戶去更新時，其餘用戶再想刷新只能等着，直到前一個用戶完成數據庫記錄刷新爲止，這樣就大大下降的效率，併發的性能也就不是很客觀了。
另外，因爲須要對cell v2進行支持，目前全部的quota表均已移動到API的數據庫了能夠參考BPCellsV2 - Move quota tables to API database。Cell V2的設計思想是，由API、Super Conductor去訪問上層的全局數據庫（nova_api數據庫），而底下的cell中的組件，只須要關心cell中的邏輯便可。所以，爲了完全的解耦，讓cell中的compute無需再訪問api數據庫進行諸如commit操做，在Pike版本，社區對quota機制進行了優化，詳情能夠參考Count resources to check quota in API for cells這個BP。
所以Pike版本以後，配額檢測變成了這樣：
- 首先，api中進行第一次Quota檢測，主要方法就是收集地下各個cell數據庫中的資源信息，而後和api數據庫中的quota上限進行對比。例如，一個用戶能夠建立10個虛擬機，在cell1中有2個，cell2中有7個，再建立一個虛擬機時，會蒐集cell1和cell2中的虛擬機個數之和（9個），而後加上變化（新增一個），與總配額進行比較。
- 二次檢測（cell v2在super conductor裏作）。因爲在併發場景下，可能出現同時檢測發現知足，以後進行建立，就會形成配額的超分，針對這個問題，社區目前給出的方案是，在建立虛擬機記錄以後，再進行recheck，若是發現超額了，會將超額分配的虛擬機標記爲ERROR，再也不繼續往下走了。
每次檢測的邏輯都調用相同的函數，具體邏輯以下圖所示：
2.2 Nova Super Conductor
Super Conductor在建立虛擬機的流程其實和以前差很少，選個合適的節點（調度），而後，寫入虛擬機相關的記錄，而後，投遞消息到選定的Compute節點進行虛擬機的建立。
在Cell v2場景，虛擬機的建立記錄已經須要寫入的子cell中，所以，conductor須要作的事，包括一下幾個步驟：
- 進行調度，選出host。
- 根據host，經過host_mappings找到對應的cell
- 在對應的cell db中建立虛擬機記錄，而且記錄instances_mappings信息
- 經過cell_mappings來查找對應的cell的mq，而後投遞到對應的cell中的compute
完成這些操做時，須要牽扯到3個關鍵的數據結構，咱們來簡單的看一下：
- host_mappings：記錄了host和cell的映射信息
- instances_mappings：記錄了虛擬機和cell的映射信息
- cell_mappings：記錄了cell和cell對應的mq的映射信息
與Cell v1不太相同，在目前的設計中，認爲scheduler能看到的應該是底下可以提供資源的具體的全部的Resource Provider（對於計算資源來講，就是全部的計算節點），而不是整個cell，也就是說全部cell中的資源scheduler均可以看到，而子cell就負責建立就行了。所以，在super conductor中，須要作一些transfer的事情，這樣也就沒必要在像cell v1那樣，在子cell裏還得搞個scheduler去作調度。
2.3 Nova-Scheduler
剛纔咱們在conductor中，已經介紹了，在選擇具體哪一個節點來建立虛擬機時，調用了Scheduler的select_destination方法，在以前的版本的調度中，就是OpenStack最經典的Filter&Weight的調度，已經有大量的資料介紹過具體的實現和用法。能夠參考官方文檔Filter Scheduler。
在Pike版本中，在調度這部分仍是作了比較大的調度，主要就是2個相關變更。
-
經過Placement獲取可用的備選資源，參考Placement Allocation Requests的實現。
在Ocata版本時，Resource Providers - Scheduler Filters in DB這個BP就已經在調度前加了一步，獲取備選節點。從BP的標題就能夠看出，設計者想經過Placement服務提供的新的一套機制，來作過濾。緣由是以前的調度須要在scheduler維護每個compute節點的hoststate信息，而後調度的時候，再一個個去查，這過低效了，尤爲是在計算節點數目比較多的時候。所以，增長了一個「預過濾」的流程，經過向Placement查詢，Placement服務直接經過SQL去查一把，把知足條件（好比CPU充足、RAM充足等）先獲取到。
而原來獲取備選節點的時候，只支持獲取單一的Resource Provider，這個BP加強了獲取備選資源的能力，用於後續支持更復雜的請求，好比共享資源、嵌套資源的Provider查詢。後面，Placement還會陸續支持更多的請求，好比對一些非存量不可計數的資源的支持。這樣留給後面Filter&Weight的壓力就小一些了，再日後，會不會徹底取代Filter呢？我想，現有的各類過濾均可以經過Placement支持後，徹底有可能的。 -
Scheduler經過Placement來claim資源。參考Scheduler claiming resources to the Placement API的實現。
在最先的時候，claim資源是由compute來作的，如今至關於提早到scheduler去搞了。有什麼好處呢？咱們先看看原來的問題：
調度時刻和真正的去compute節點去claim資源的時刻之間是由一段時間的，在資源不是那麼充足的環境，就會形成在scheduler調度的時候，資源還沒刷新，因此調度時候成功了，可是真正下來的時候，才發現compute實際已經沒有資源了，而後又「跨越半個地球」去作重調度，無形地增長了系統的負載。
並且增長了建立的時長（哦，哪怕建立失敗呢？），你想一想，用戶創了那麼久的虛擬機，最後你告訴我調度失敗了，用戶不太能忍。
因此這個BP就把Claim資源放在調度處了，我上一個調度請求處理完，立刻就告訴placement，這資源老子用了，其餘人不要動了。OK，世界終於清淨了，能拿到資源的拿到了，拿不到資源的立刻也知道本身拿不到了，大大加強了調度的用戶體驗。
2.4 Placement
恩，在調度的時候，已經介紹過這個服務了，在虛擬機建立的流程中，比較經常使用的接口就是獲取備選資源和claim資源。
Placement目標很宏偉，大體的做用就是：資源我來管，要資源問我要，用了資源告訴我。後面準備用一篇文章總體介紹一下Placement。（yep，這個Flag我立下了，會寫的）
2.5 Nova-Compute
好吧，到最後一個服務了，Compute。這個裏面依舊仍是作那麼幾件事，掛卷，掛網卡，調driver的接口啓動一下虛擬機。至此，咱們可愛的虛擬機就起來了。
3. 結語
總體的看一下，其實在Pike版本，Nova仍是有不少的變更。真的是一個版本過去了，建立虛擬機的流程已經面目全非了。
從P版本的虛擬機建立流程來看，主要的優化集中在基於Cell V2架構下的多cell支持、調度的優化、Quota的優化，然後續的發展，目前也是集中在Placement各類資源的支持以及在Cell v2場景的諸如基本流程、調度等的優化。