本節討論 nova-compute,並詳細分析 instance 部署的全過程。
node
先給你們道個歉:今天這篇文章的篇幅比以往要多一些,原本想分兩次發,但考慮到文章的完整和系統性,仍是一次發了出來,此次可能要超出 5 分鐘了,你們見諒。
nova-compute 在計算節點上運行,負責管理節點上的 instance。 OpenStack 對 instance 的操做,最後都是交給 nova-compute 來完成的。 nova-compute 與 Hypervisor 一塊兒實現 OpenStack 對 instance 生命週期的管理。linux
接着的問題是:如今市面上有這麼多 Hypervisor,nova-compute 如何與它們配合呢? 這就是咱們以前討論過的 Driver 架構。網絡
nova-compute 爲這些 Hypervisor 定義了統一的接口,Hypervisor 只須要實現這些接口,就能夠 Driver 的形式即插即用到 OpenStack 系統中。 下面是Nova Driver的架構示意圖架構
咱們能夠在 /opt/stack/nova/nova/virt/ 目錄下查看到 OpenStack 源代碼中已經自帶了上面這幾個 Hypervisor 的 Driverdom
某個特定的計算節點上只會運行一種 Hypervisor,只需在該節點 nova-compute 的配置文件 /etc/nova/nova.conf 中配置所對應的 compute_driver 就能夠了。學習
在咱們的環境中由於是 KVM,因此配置的是 Libvirt 的 driver。spa
nova-compute 的功能能夠分爲兩類:3d
定時向 OpenStack 報告計算節點的狀態日誌
實現 instance 生命週期的管理orm
下面咱們依次介紹。
前面咱們看到 nova-scheduler 的不少 Filter 是根據算節點的資源使用狀況進行過濾的。 好比 RamFilter 要檢查計算節點當前能夠的內存量;CoreFilter 檢查可用的 vCPU 數量;DiskFilter 則會檢查可用的磁盤空間。
那這裏有個問題:OpenStack 是如何得知每一個計算節點的這些信息呢? 答案就是:nova-compute 會按期向 OpenStack 報告。
從 nova-compute 的日誌 /opt/stack/logs/n-cpu.log 能夠發現: 每隔一段時間,nova-compute 就會報告當前計算節點的資源使用狀況和 nova-compute 服務狀態。
若是咱們再深刻問一個問題:nova-compute 是如何得到當前計算節點的資源使用信息的? 給你們一分鐘本身先思考一下?
好,揭曉答案。
要獲得計算節點的資源使用詳細狀況,須要知道當前節點上全部 instance 的資源佔用信息。 這些信息誰最清楚? 固然是 Hypervisor。
你們還記得以前咱們討論的 Nova Driver 架構吧,nova-compute 能夠經過 Hypervisor 的 driver 拿到這些信息。
舉例來講,在咱們的實驗環境下 Hypervisor 是 KVM,用的 Driver 是 LibvirtDriver。 LibvirtDriver 能夠調用相關的 API 得到資源信息,這些 API 的做用至關於咱們在 CLI 裏執行 virsh nodeinfo、virsh dominfo 等命令。
OpenStack 對 instance 最主要的操做都是經過 nova-compute 實現的,包括 instance 的 launch、shutdown、reboot、suspend、resume、terminate、resize、migration、snapshot 等。
本小節重點學習 nova-compute 如何實現 instance launch(部署)操做,其它操做將會在後面的章節討論。
當 nova-scheduler 選定了部署 instance 的計算節點後,會經過消息中間件 rabbitMQ 向選定的計算節點發出 launch instance 的命令。 該計算節點上運行的 nova-compute 收到消息後會執行 instance 建立操做。 日誌 /opt/stack/logs/n-cpu.log 記錄了整個操做過程。
nova-compute 建立 instance 的過程能夠分爲 4 步:
爲 instance 準備資源
建立 instance 的鏡像文件
建立 instance 的 XML 定義文件
建立虛擬網絡並啓動虛擬機
下面咱們依次討論每一個步驟。
nova-compute 首先會根據指定的 flavor 依次爲 instance 分配內存、磁盤空間和 vCPU。 能夠在日誌中看到這些細節
網絡資源也會提早分配。
資源準備好以後,nova-compute 會爲 instance 建立鏡像文件。 OpenStack 啓動一個 instance 時,會選擇一個 image,這個 image 由 Glance 管理。 nova-compute會:
首先將該 image 下載到計算節點
而後將其做爲 backing file 建立 instance 的鏡像文件。
從 Glance 下載 image
nova-compute 首先會檢查 image 是否已經下載(好比以前已經建立過基於相同 image 的 instance)。若是沒有,就從 Glance 下載 image 到本地。
由此可知,若是計算節點上要運行多個相同 image 的 instance,只會在啓動第一個 instance 的時候從 Glance 下載 image,後面的 instance 啓動速度就大大加快了。 日誌以下:
能夠看到
image(ID爲 917d60ef-f663-4e2d-b85b-e4511bb56bc2)是 qcow2 格式,nova-compute 將其下載,而後經過 qemu-img 轉換成 raw 格式。 轉換的緣由是下一步須要將其做爲 instance 的鏡像文件的 backing file,而 backing file不能是 qcow2 格式。
image 的存放目錄是 /opt/stack/data/nova/instances/_base,這是由 /etc/nova/nova.conf 的下面兩個配置選項決定的。
instances_path = /opt/stack/data/nova/instances
base_dir_name = _base
下載的 image 文件被命名爲 60bba5916c6c90ed2ef7d3263de8f653111dd35f,這是 image id 的 SHA1 哈希值。
爲 instance 建立鏡像文件
有了 image 以後,instance 的鏡像文件直接經過 qemu-img 命令建立,backing file 就是下載的 image。
這裏 instance 的鏡像文件位於 /opt/stack/data/nova/instances/f1e22596-6844-4d7a-84a3-e41e6d7618ef/disk,格式爲 qcow2,其中 f1e22596-6844-4d7a-84a3-e41e6d7618ef 就是 instance 的 id。
能夠經過 qume-info 查看 disk 文件的屬性
這裏有兩個容易搞混淆的術語,在此特別說明一下:
image,指的是 Glance 上保存的鏡像,做爲 instance 運行的模板。 計算節點將下載的 image 存放在 /opt/stack/data/nova/instances/_base 目錄下。
鏡像文件,指的是 instance 啓動盤所對應的文件
兩者的關係是:image 是鏡像文件 的 backing file。image 不會變,而鏡像文件會發生變化。好比安裝新的軟件後,鏡像文件會變大。
由於英文中二者都叫 「image」,爲避免混淆,咱們用 「image」 和 「鏡像文件」 做區分。
建立的 XML 文件會保存到該 instance 目錄 /opt/stack/data/nova/instances/f1e22596-6844-4d7a-84a3-e41e6d7618ef,命名爲 libvirt.xml
接下來即是爲 instance 建立虛擬網絡設備
本環境用的是 linux-bridge 實現的虛擬網絡,在 Neutron 章節咱們會詳細討論 OpenStack 虛擬網絡的不一樣實現方式。
一切就緒,接下來能夠啓動 instance 了。
至此,instance 已經成功啓動。 OpenStack 圖形界面和 KVM CLI 均可以查看到 instance 的運行狀態。
在計算節點上,instance 並非以 OpenStack上 的名字命名,而是用 instance-xxxxx 的格式。
哇,竟然堅持看完了!
在下面給本身點個贊吧 :-)