雲端計算與OpenStack

“雲端計算”算是近年來最熱的詞了。現在IT行業見面不說這三個字您都不好意思跟人家打招呼。對於雲端計算，學術界有各種定義，大家有興趣可以百度一下。

CloudMan這裡主要想從技術的角度談談對雲端計算的理解。

基本概念

所有的新事物都不是突然冒出來的，都有前世和今生。雲端計算也是IT技術不斷髮展的產物。要理解雲端計算，需要對IT系統架構的發展過程有所認識。請看下圖

IT系統架構的發展到目前為止大致可以分為3個階段：

1.物理機架構

這一階段，應用部署和執行在物理機上。比如企業要上一個ERP系統，如果規模不大，可以找3臺物理機，分別部署Web伺服器、應用伺服器和資料庫伺服器。如果規模大一點，各種伺服器可以採用叢集架構，但每個叢集成員也還是直接部署在物理機上。我見過的客戶早期都是這種架構，一套應用一套伺服器，通常系統的資源使用率都很低，達到20%的都是好的。

2.虛擬化架構

摩爾定律決定了物理伺服器的計算能力越來越強，虛擬化技術的發展大大提高了物理伺服器的資源使用率。這個階段，物理機上執行若干虛擬機器，應用系統直接部署到虛擬機器上。虛擬化的好處還體現在減少了需要管理的物理機數量，同時節省了維護成本。

3.雲端計算架構虛擬化提高了單臺物理機的資源使用率，隨著虛擬化技術的應用，IT環境中有越來越多的虛擬機器，這時新的需求產生了：如何對IT環境中的虛擬機器進行統一和高效的管理。有需求就有供給，雲端計算登上了歷史舞臺。

計算（CPU/記憶體）、儲存和網路是IT系統的三類資源。通過雲端計算平臺，這三類資源變成了三個池子。當需要虛機的時候，只需要向平臺提供虛機的規格。平臺會快速從三個資源池分配相應的資源，部署出這樣一個滿足規格的虛機。虛機的使用者不再需要關心虛機執行在哪裡，儲存空間從哪裡來，IP是如何分配，這些雲平臺都搞定了。

雲平臺是一個面向服務的架構，按照提供服務的不同分為IaaS、PaaS和SaaS。請看下圖

IaaS（InfrastructureasaService）提供的服務是虛擬機器。IaaS負責管理虛機的生命週期，包括建立、修改、備份、啟停、銷燬等。使用者從雲平臺得到的是一個已經安裝好映象（作業系統+其他預裝軟體）的虛擬機器。使用者需要關心虛機的型別（OS）和配置（CPU、記憶體、磁碟），並且自己負責部署上層的中介軟體和應用。IaaS的使用者通常是資料中心的系統管理員。典型的IaaS例子有AWS、Rackspace、阿里雲等

PaaS（PlatformasaService）提供的服務是應用的執行環境和一系列中介軟體服務（比如資料庫、訊息佇列等）。使用者只需專注應用的開發，並將自己的應用和資料部署到PaaS環境中。PaaS負責保證這些服務的可用性和效能。PaaS的使用者通常是應用的開發人員。典型的PaaS有GoogleAppEngine、IBMBlueMix等

SaaS（SoftwareasaService）提供的是應用服務。使用者只需要登入並使用應用，無需關心應用使用什麼技術實現，也不需要關係應用部署在哪裡。SaaS的使用者通常是應用的終端使用者。典型的SaaS有GoogleGmail、Salesforce等

雲端計算和OpenStack

OpenStackisacloudoperatingsystemthatcontrolslargepoolsofcompute,storage,andnetworkingresourcesthroughoutadatacenter,allmanagedthroughadashboardthatgivesadministratorscontrolwhileempoweringtheiruserstoprovisionresourcesthroughawebinterface.

以上是官網對OpenStack的定義，OpenStack對資料中心的計算、儲存和網路資源進行統一管理。由此可見，OpenStack針對的是IT基礎設施，是IaaS這個層次的雲作業系統。

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

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

建立Instance時，使用者會提出資源需求，例如CPU、記憶體、磁碟各需要多少。

OpenStack將這些需求定義在flavor中，使用者只需要指定用哪個flavor就可以了。

可用的flavor在System->Flavors中管理。

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

下面介紹nova-scheduler是如何實現排程的。

在/etc/nova/nova.conf中，nova通過scheduler_driver，scheduler_available_filters和scheduler_default_filters這三個引數來配置nova-scheduler。

Filterscheduler

Filterscheduler是nova-scheduler預設的排程器，排程過程分為兩步：

1.通過過濾器（filter）選擇滿足條件的計算節點（執行nova-compute）

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

2.scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler

Nova允許使用第三方scheduler，配置scheduler_driver即可。這又一次體現了OpenStack的開放性。

Scheduler可以使用多個filter依次進行過濾，過濾之後的節點再通過計算權重選出最適合的節點。

上圖是排程過程的一個示例：

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

通過多個filter層層過濾，Host2和Host4沒有通過，被刷掉了

Host1，Host3，Host5，Host6計算權重，結果Host5得分最高，最終入選

Filter

當Filterscheduler需要執行排程操作時，會讓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

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

RetryFilter

RetryFilter的作用是刷掉之前已經排程過的節點。

舉個例子方便大家理解：假設A,B,C三個節點都通過了過濾，最終A因為權重值最大被選中執行操作。但由於某個原因，操作在A上失敗了。預設情況下，nova-scheduler會重新執行過濾操作（重複次數由scheduler_max_attempts選項指定，預設是3）。那麼這時候RetryFilter就會將A直接刷掉，避免操作再次失敗。RetryFilter通常作為第一個filter。

AvailabilityZoneFilter

為提高容災性和提供隔離服務，可以將計算節點劃分到不同的AvailabilityZone中。

例如把一個機架上的機器劃分在一個AvailabilityZone中。OpenStack預設有一個命名為“Nova”的AvailabilityZone，所有的計算節點初始都是放在“Nova”中。使用者可以根據需要建立自己的AvailabilityZone。

建立Instance時，需要指定將Instance部署到在哪個AvailabilityZone中。

nova-scheduler在做filtering時，會使用AvailabilityZoneFilter將不屬於指定AvailabilityZone的計算節點過濾掉。

RamFilter

RamFilter將不能滿足flavor記憶體需求的計算節點過濾掉。

對於記憶體有一點需要注意：為了提高系統的資源使用率，OpenStack在計算節點可用記憶體時允許overcommit，也就是可以超過實際記憶體大小。超過的程度是通過nova.conf中ram_allocation_ratio這個引數來控制的，預設值為1.5

ram_allocation_ratio=1.5

其含義是：如果計算節點的記憶體有10GB，OpenStack則會認為它有15GB（10*1.5）的記憶體。

DiskFilter

DiskFilter將不能滿足flavor磁碟需求的計算節點過濾掉。

Disk同樣允許overcommit，通過nova.conf中disk_allocation_ratio控制，預設值為1

disk_allocation_ratio=1.0

CoreFilter

CoreFilter將不能滿足flavorvCPU需求的計算節點過濾掉。

vCPU同樣允許overcommit，通過nova.conf中cpu_allocation_ratio控制，預設值為16

cpu_allocation_ratio=16.0

這意味著一個8vCPU的計算節點，nova-scheduler在排程時認為它有128個vCPU。需要提醒的是：nova-scheduler預設使用的filter並沒有包含CoreFilter。如果要用，可以將CoreFilter新增到nova.conf的scheduler_default_filters配置選項中。

ComputeFilter

ComputeFilter保證只有nova-compute服務正常工作的計算節點才能夠被nova-scheduler排程。
ComputeFilter顯然是必選的filter。

ComputeCapabilitiesFilter

ComputeCapabilitiesFilter根據計算節點的特性來篩選。

這個比較高階，我們舉例說明。例如我們的節點有x86_64和ARM架構的，如果想將Instance

指定部署到x86_64架構的節點上，就可以利用到ComputeCapabilitiesFilter。

還記得flavor中有個Metadata嗎，Compute的Capabilities就在Metadata中指定。

“ComputeHostCapabilities”列出了所有可設定Capabilities。

點選“Architecture”後面的“+”，就可以在右邊的列表中指定具體的架構。

配置好後，ComputeCapabilitiesFilter在排程時只會篩選出x86_64的節點。如果沒有設定Metadata，ComputeCapabilitiesFilter不會起作用，所有節點都會通過篩選。

ImagePropertiesFilter

ImagePropertiesFilter根據所選p_w_picpath的屬性來篩選匹配的計算節點。跟flavor類似，p_w_picpath也有metadata，用於指定其屬性。

例如希望某個p_w_picpath只能執行在kvm的hypervisor上，可以通過“HypervisorType”屬性來指定。

點選“+”，然後在右邊的列表中選擇“kvm”。

配置好後，ImagePropertiesFilter在排程時只會篩選出kvm的節點。如果沒有設定Image的Metadata，ImagePropertiesFilter不會起作用，所有節點都會通過篩選。

ServerGroupAntiAffinityFilter

ServerGroupAntiAffinityFilter可以儘量將Instance分散部署到不同的節點上。

例如有inst1，inst2和inst3三個instance，計算節點有A,B和C。為保證分散部署，進行如下操作：

1.建立一個anti-affinity策略的servergroup“group-1”

2.novaserver-group-create--policyanti-affinitygroup-1

請注意，這裡的servergroup其實是instancegroup，並不是計算節點的group。

1.依次建立Instance，將inst1,inst2和inst3放到group-1中

2.novaboot--p_w_picpathIMAGE_ID--flavor1--hintgroup=group-1inst1novaboot--p_w_picpathIMAGE_ID--flavor1--hintgroup=group-1inst2novaboot--p_w_picpathIMAGE_ID--flavor1--hintgroup=group-1inst3

因為group-1的策略是AntiAffinity，排程時ServerGroupAntiAffinityFilter會將inst1,inst2和inst3部署到不同計算節點A,B和C。

目前只能在CLI中指定servergroup來建立instance。

建立instance時如果沒有指定servergroup，ServerGroupAntiAffinityFilter會直接通過，不做任何過濾。

ServerGroupAffinityFilter

與ServerGroupAntiAffinityFilter的作用相反，ServerGroupAffinityFilter會盡量將instance部署到同一個計算節點上。方法類似

1.建立一個affinity策略的servergroup“group-2”

2.novaserver-group-create--policyaffinitygroup-2

1.依次建立instance，將inst1,inst2和inst3放到group-2中

2.novaboot--p_w_picpathIMAGE_ID--flavor1--hintgroup=group-2inst1novaboot--p_w_picpathIMAGE_ID--flavor1--hintgroup=group-2inst2novaboot--p_w_picpathIMAGE_ID--flavor1--hintgroup=group-2inst3

因為group-2的策略是Affinity，排程時ServerGroupAffinityFilter會將inst1,inst2和inst3部署到同一個計算節點。

建立instance時如果沒有指定servergroup，ServerGroupAffinityFilter會直接通過，不做任何過濾。

Weight

經過前面一堆 filter 的過濾，nova-scheduler 選出了能夠部署 instance 的計算節點。 如果有多個計算節點通過了過濾，那麼最終選擇哪個節點呢？

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

目前 nova-scheduler 的預設實現是根據計算節點空閒的記憶體量計算權重值： 空閒記憶體

日誌

是時候完整的回顧一下nova-scheduler的工作過程了。整個過程都被記錄到nova-scheduler的日誌中。比如當我們部署一個instance時

開啟nova-scheduler的日誌/opt/stack/logs/n-sch.log（非devstack安裝其日誌在/var/log/nova/scheduler.log）

日誌顯示初始有兩個host（在我們的實驗環境中就是devstack-controller和devstack-compute1），依次經過9個filter的過濾（RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter），兩個計算節點都通過了。

那麼接下來就該weight了：

可以看到因為devstack-controller的空閒記憶體比devstack-compute1多（7466>3434），權重值更大（1.0>0.4599），最終選擇devstack-controller。

注：要顯示DEBUG日誌，需要在/etc/nova/nova.conf中開啟debug選項

[DEFAULT]debug=True

轉載於:https://blog.51cto.com/risingair/1867673