O02七、看nova-scheduler如何選擇計算節點

參考 http://www.javashuo.com/article/p-hoxrnyyx-gm.html

 

本節重點介紹 nova-scheduler 的調度機制和實現方法：即解決如何選擇在那個計算節點上啓動 instance 的問題。

 

建立Instance 時，用戶會提出資源需求，例如 CPU、內存、磁盤各須要多少。OpenStack 將這些需求定義在 flavor 中，用戶只須要指定用哪一個 flavor 就能夠了。

 

咱們能夠在  Project -> Admin -> System -> Flavor 中查看可用的 flavor

 

 

Flavor 主要定義了 VCPU 、RAM 、DISK 和 metadata 這四類。nova-scheduler 會按照flavor 去選擇合適的計算節點。VCPU、RAM、DISK 比較好理解，而Metadata 比較有意思，咱們後面會討論。

 

下面介紹 nova-scheduler 是如何實現調度的。在/etc/nova/nova.conf 中，nova 經過 scheduler_driver 、scheduler_available-filters 和 scheduler_default_filters 這三個參數來配置 nova-scheduler 

 

stack@DevStack-Compute:~$ cat /etc/nova/nova.conf  | grep sch

scheduler_default_filters = RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter,DifferentHostFilter

scheduler_driver = filter_scheduler

 

Filter scheduler 

 

Filter scheduler 是nova-scheduler 默認的調度器，調度過程分爲兩步：

 

    一、經過過濾器（filter）選擇知足條件的計算節點（運行 nova-compute）

    二、經過權重計算（weighting）選擇在最優（權重值最大）的計算節點上建立Instance 

 

Nova 容許使用第三方 scheduler ，配置 scheduler_driver 便可。這又一次體現了OpenStack 的開放性。Scheduler  可使用多個filter 一次進行過濾，過濾以後的節點在經過計算權重選出最合適的節點。

 

 

上圖是調度過程的一個示例：

 

    一、最開始有6個計算節點 Host1 - Host6

    二、經過多個filter 層層過濾，Host2 和 Host4 沒有經過

    三、Host一、三、五、6 計算權重，結果Host5得分最高，最終入選

 

Filter

 

當Filter Scheduler 須要執行調度操做時，會讓 filter 對計算節點進行判斷，filter 返回 True 或 False 。nova.conf 中的scheduler_available_filters 選項用於配置 scheduler 可用的filter ，默認是全部nova自帶的filter均可以用與過濾操做。

 

scheduler_available_filters = nova.scheduler.filters.all_filters

 

另外還有一個選項scheduler_default_filters ，用於指定scheduler真正使用的filter ，默認值以下 

 

scheduler_default_filters = RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter,DifferentHostFilter

 

scheduler 按照列表中的順序依次過濾。下面依次介紹每一個 filter

 

RetryFilter

 

RetryFilter 的做用是刷掉以前已經調度過的節點。

 

據個例子方便你們理解：假設ABC三個節點都經過了過濾，最終A由於權重值最大被選中執行操做。但因爲某個緣由，操做在A上失敗了。默認狀況下nova-scheduler 會從新執行過濾操做（重複次數由scheduler_max_attempts選項指定，默認是3）。那麼這個時候 RetryFilter 就會將A直接刷掉，避免操做再次失敗。RetryFilter 一般做爲第一個filter。

 

AvailabilityZoneFilter

 

爲提升容災性和提供隔離服務，能夠將計算節點劃分到不一樣的 Availability Zone 中。例如把一個機架上的機器劃分在一個 Availability Zone中。OpenStack 默認有一個命名爲 Nova 的Availability Zone ，全部計算節點初始都是放在Nova 中。用戶可根據須要建立本身的 Availability Zone。

 

 

建立 Instance 時，須要指定將 Instance 部署到哪一個 Availability Zone中。

 

 

nova-scheduler 在作filtering 時，會使用 AvailabilityZoneFilter 將不屬於指定 Availability Zone 的計算節點刷掉。

 

RamFilter

 

Ramfilter 將不能知足 flavor 內存需求的計算節點過濾掉。

 

對內存有一點須要注意：爲了提升系統的資源使用率，OpenStack 在計算節點可用內存時容許 overcommit ，也就是能夠超過實際內存大小。超過的程度是經過 nova.conf中 ram_allocation_ratio 這個參數來控制的，默認值爲 1.5 

 

其含義是：若是計算節點的內容爲 10G ，OpenStack 則會認爲他有 15G （10G * 1.5 ）內存

 

DiskFilter

 

DiskFilter 將不能知足flavor 磁盤需求的計算節點過濾掉。Disk 一樣容許 overcommit ，經過 nova.conf 中 disk_allocation_ratio 控制，默認值爲 1

 

CoreFilter

 

CoreFilter 將不能知足 flavor vCPU 需求的計算節點過濾掉。 vCPU  一樣容許 overcommit ，經過 nova.conf 中 cpu_allocation_ratio 控制，默認值 16

 

這就意味着 一個 8 vCPU的計算節點，nova-scheduler 在調度時認爲他有 128 個vCPU 。須要提醒的是，nova-scheduler 默認使用的 filter 並無包含 CoreFilter 。若是要用，能夠將 CoreFilter 添加到 nova.conf 的scheduler_default_filter 配置選項中

 

ComputeFilter

 

ComputeFilter 保證只有 nova-compute 服務正常工做的計算節點纔可以被 nova-scheduler 調度，顯然這是一個必選的 filter

 

ComputeCapabilitiesFilter

 

根據計算接地那的特性來篩選，這個比較高級，咱們舉例說明。

 

假如咱們的節點有 x86_64 和 ARM 架構，若是想將 Instance 指定部署到 x86_64 架構的節點上，就能夠利用這個過濾器，還記得flavor 中有個 Metadata嗎，Compute 的 Capabilities 就在 Metadata 中指定。

 

若是沒有指定 設置 Metadata ，這個過濾器不會起做用，全部節點都會經過。

 

下面是Metadatalist 和 建立 Instance時選擇 Metadata的界面

 

 

 

ServerGroupAntiAffinityFilter

 

這個過濾器能夠儘可能將 Instance  分散部署到不一樣的節點上。

 

例若有 inst1 inst2 inst3 三個instance ，計算節點有ABC，爲保證分散部署，進行以下操做：

 

一、建立一個 anti-affinity 策略的 server group 「group-1」

 

nova server-group-create --policy anti-affinity group-1

 

請注意，這裏的server group 實際上是instance group，並非計算節點的 group

 

二、依次建立 instance inst一、inst二、inst3 並放到group-1中

 

nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst1

nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst2

nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst3

 

由於group-1的策略是 Antiaffinity ,調度時ServerGroupAntiAffinityFilter 會將 inst1 、inst二、inst3 部署到不一樣計算節點 ABC 上。

 

建立 instance 時若是沒有指定 server group ，改全部計算節點會直接經過該過濾器

 

ServerGroupAffinityFilter

 

與ServerGroupAntiAffinityFilter  正好相反，該過濾器會盡可能將 instance 部署到同一個計算節點上。方法與ServerGroupAntiAffinityFilter 相似

 

nova server-group-create --policy affinity group-2

 

nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst1

nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst2

nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst3

 

Weight

 

通過前面一堆的過濾器，nova-scheduler 選出了可以部署 instance 的計算節點。若是有多個計算節點經過了過濾器，那麼最終會選擇哪一個節點呢？

 

Scheduler 會對每一個計算節點打分，得分最高的獲勝。打分的過程就是weight，翻譯過來就是計算權重值，那麼 Scheduler 是根據什麼來計算權重值呢？

 

目前 nova-scheduler 的默認實現是根據計算節點空閒的內存量計算權重值：內存空閒越多，權重就越大，instance 將部署到當前空閒內存最多的計算節點上。

 

日誌

 

是時候完整的回顧一下 nova-scheduler 的工做過程了。整個過程都被記錄到 nova-scheduler 的日誌文件中。好比當咱們部署一個 instance 時打開 nova-scheduler 的日誌 /opt/stack/logs/n-sch.log （非 DevStack 安裝的話，日誌在 /var/log/nova/scheduler.log）

 

 

 

日誌顯示初始有兩個host（在咱們的實驗環境中就是 DevStack-Controller 和 DevStack-Compute），依次通過9個過濾器，兩個節點都經過了，那麼接下來就是weight了。能夠看出由於 DevStack-Controller 的空閒內存比較多，權重值就大，最終會選在在 DevStack-Controller 上建立instance

 

注意：要顯示 debug日誌，須要在配置文件中打開debug選項。

 

nova-scheduler 就是這些內容了，比較靈活，也比較複雜。