OpenStack入門以及一些資料之（零，nova計算）

最近看了些OpenStack的代碼，深感自己還有很多不足，于是便想起了之前讀過的華為孔令賢的csdn部落格（原位址，現已遷移到github，位址），花費了一些時間通讀了一遍，獲益頗多，在這裡整理并記錄一下。

0，計算

關于排程（scheduler），它的主要作用是決定虛拟機建立在哪個節點上，主要是通過一些過濾器（filter）來實作的。

參考：OpenStack Scheduler 入門

         Grizzly版本中Scheduler filter機制詳解

         Nova目前的filter及其功能

---------------------------------------------------------------------------

關于消息隊列，nova中的每個元件都會連接配接消息伺服器，一個元件可能是一個消息發送者（如API、Scheduler），也可能是一個消息接收者（如compute、volume、network）。發送消息主要有兩種方式：同步調用rpc.call和異步調用rpc.cast。還有其他的消息發送方式，比如notify等。

一些比較重要的概念：

交換器(exchange)：接收消息并且将消息轉發給隊列。在每個主機的内部，交換器都有唯一對應的名字。交換器可以使持久的，臨時的或者自動删除的。持久的交換器會一直存在與server端直到它被顯式的删除；臨時交換器在伺服器關閉時停止工作哦；自動删除的交換器在沒有應用程式使用它的時候被伺服器删除。交換器主要有三種類型：

廣播式交換器類型(fanout）:不分析所接收到消息中的routingkey，預設将消息轉發到所有與該交換器綁定的隊列中去。

直接式交換器類型(direct)：需要精确比對routingkey和bindingkey，如消息的routingkey = cloud，那麼該條消息隻能被轉發至bindingkey = cloud的消息隊列中去。

主題式交換器(Topic Exchange)：通過消息的routingkey與bindingkey的模式比對，将消息轉發至所有符合綁定規則的隊列中。

隊列：“消息隊列”，它是一個具名緩沖區，代表一組消費者應用程式儲存消息。這些應用程式在它們的全縣範圍内可以建立、使用、共享消息隊列。類似于交換器，消息隊列也可以是持久的，臨時的或者自動删除的。

綁定：可以了解為交換器和消息隊列之間的一種關系，綁定之後交換器會知道應該把消息發給哪個隊列，綁定的關鍵字稱為binding_key.

參考：OpenStack 消息隊列入門

         依據AMQP通信架構實作消息發送機制解析之一

---------------------------------------------------------------------------

在Folsom版本中，對應不同的hypervisor實作，所有插件類全部繼承于一個基類/nova/virt/driver.py

參考：Nova虛拟化層Driver分析(基于F版)

         OpenStack使用XenServer資源池淺析

---------------------------------------------------------------------------

[nova中的policy]任何對外暴露接口的系統，都必須有分權分域以及認證鑒權的功能。在openstack中，keystone元件用來對使用者進行認證，說白了就是看使用者是否是系統的合法使用者，而policy機制則主要看使用者的操作是否滿足特定的條件，比如一些接口是特權接口（僅限管理者使用），普通使用者不允許調用。

參考：OpenStack Nova中的policy

---------------------------------------------------------------------------

OpenStack的循環任務以及資源重新整理機制。對于循環任務，OpenStack并未使用python中的threading或者multiprocessing子產品，而是大量使用了一種叫做協程(coroutine)的東西，也叫“綠色線程”，主要在eventlet庫中，OpenStack又對其作了一些封裝。而資源重新整理，并不是計算節點定期将自己的資訊寫入共享DB，讓scheduler在排程時從DB中讀取資源資料，而是讓個節點定時上報，把對DB的壓力轉移到了nova-scheduler程序。但是當節點數目上去之後，nova-scheduler程序能否支撐如此頻繁調用和如此大的資料量，還是一個疑問。

參考：OpenStack Nova的資源重新整理機制

         OpenStack中的循環任務和子任務--以Nova為例

         Openstack Eventlet分析(1)

         OpenStack Eventlet分析(2)

---------------------------------------------------------------------------

Cell in nova：為了增加橫向擴充以及分布式，大規模(地理位置級别)部署能力，但又不增加資料庫和消息中間件的複雜度，并将cell排程和主機排程隔離。G版重新提出cell概念。Cell之間的通信的可信的，基于AMQP協定。概括如下：

》每一個Cell中擁有獨立的DB和AMQP broker

》引入新的nova-cell服務

    -消息路由

    -排程(與主機排程不同，子Cell通過定時重新整理将自己能力和資源上報給父Cell)

》cell之間通信通過RPC

》cells之間是樹狀結構

    -頂層是API cell，不感覺底層實體主機以及虛拟化

    -子cell無nova-api服務

    -子cell無quota概念(NoopQuota)

參考：G版中關于Nova的Cell

       F版和G版中的AvailabilityZone

---------------------------------------------------------------------------

nova-conductor：在G版的nova中，取消了nova-compute的直接資料庫通路，主要以下幾個原因：

1，安全：

a)     Benefit：因為compute節點通常會運作不可信的使用者負載，一旦服務被攻擊或使用者虛拟機的流量溢出，則資料庫會邊臨直接暴露的風險，增加nova-conductor更加安全。

b)    Limitation：雖然nova-conductor限制了直接DB通路，但compute節點仍然可以通過nova-conductor擷取所有節點的虛拟機資料，删除虛拟機等操作。特别是使用E版的multihost，nova-api-metadata和nova-network不能使用nova-conductor。這樣計算節點仍然是不安全地。

2，友善更新：

a)     Benefit：将nova-compute與資料庫解耦的同時，也會與模式（schema）解耦，是以就不會擔心就的代碼通路新的資料庫模式。

b)    Limitation：目前rolling upgrade在G版并不ready

3，性能：

a)     Benefit：當使用green thread時，所有的DB通路都是阻塞的。而如果使用nova-conductor，可以多線程使用RPC通路。

b)    Limitation：通過rpc通路nova-conductor會受網絡時延影響。同時，nova-conductor的DB通路也是阻塞的，如果nova-conductor執行個體較少，效果反而會更差。

目前，nova-conductor暴露的方法主要是資料庫通路，但後續從nova-compute移植更多的功能，讓nova-compute看起來更像一個沒有大腦的幹活者，而nova-conductor則會實作一些複雜而耗時的任務，比如migration（遷移）或者resize（修改虛拟機規格）。

參考：Grizzly中的nova-conductor

 ---------------------------------------------------------------------------

虛拟機建立時與網絡的互動

參考：建立虛拟機時與Quantum的互動（F版）

 ---------------------------------------------------------------------------

關于nova中虛拟機的三個操作：forcedelete,delete(soft delete),restore.相關配置項:reclaim_instance_interval

1.    delete(soft delete)

如果配置了reclaim_instance_interval,則講虛拟機“假删除”，狀态置為soft_delete，底層不會真正删除。但過了reclaim_instance_interval表示的時間（機關是秒），使用者沒有觸發restore操作，虛拟機就會被自動删除。

如果沒有配置，則虛拟機就被徹底删除。

2.    restore

用來回退狀态為soft_delete的虛拟機，隻要虛拟機還沒有被自動删除

3.    force delete

無視reclaim_instance_interval配置，直接将虛拟機徹底删除。

參考：Nova中的delete和restore

 ---------------------------------------------------------------------------

Nova中的rebuild，evacuate，resize，migrate，liva-migration

rebuild：類似于重裝系統的過程，原先是windows，想要更換linux，用rebuild。實作上，就是在虛拟機所在的host上，将原來的虛拟機删除，再根據新的鏡像建立新的虛拟機，實作虛拟機系統盤的變更，而使用者盤的資料是不變的，虛拟機的網絡資訊也不變。

evacuate：虛拟機所在的host當機，用evacuate講虛拟機在另外一個host上啟起來。（利用這個接口配合host監控工具，可以實作虛拟機的HA能力）。Evacuate和rebuild的底層實作是一樣的。差別在于：1、rebuild需要多做一步删除虛拟機的操作，而evacuate是直接建立新虛拟機。2、rebuild使用的竟像是接口指定的新的鏡像（可以與老鏡像相同），而evacuate使用的是虛拟機原來的鏡像。

migrate/resize:在虛拟機active和stopped狀态下可以進行migrate/resize，兩者的差別是在遷移的同時，改變虛拟機的flavor。配置項allow_resize_to_same_host表示是否允許遷移到本機，預設是False。

os-migrateLive：migrate操作會先将虛拟機停掉，也就是所謂的“冷遷移”，而os-migrateLive是“熱遷移”，虛拟機不會停機。live-migration是在虛拟機active狀态下的操作，且不允許熱遷移到本機。

熱遷移步驟：

1、 準備libvirt開啟tcp監控

2、 Scp鏡像檔案和console.log以及其他檔案到目标主機

3、 遷移 virsh migrate vm_name --live qemu+ssh://intent_ip/system --copy-storage-inc 

4、 清理源節點

參考：基于libvirt的虛機熱遷移

         Nova中的rebuild和evacuate

         nova resize修改執行個體配置報錯的解決辦法

         Nova中的migrate/resize/live-migration

---------------------------------------------------------------------------