OpenStack雲端的資源排程和優化剖析

NO IMAGE

         OpenStack簡介:OpenStack是旨在為公有及私有云的建設與管理提供軟體的一個開源專案,採用Apache授權協議,它的核心任務是簡化雲系統的部署過程,並且賦予其良好的可擴充套件性和可管理性。它已經在當前的基礎設施即服務(IaaS)資源管理領域佔據領導地位,成為公有云、私有云及混合雲管理的“雲作業系統”事實上的標準,在政府、電信、金融、製造、能源、零售、醫療、交通等行業成為企業創新的利器。OpenStack基於開放的架構,支援多種主流的虛擬化技術,許多重量級的科技公司如RedHat,AT&T,IBM,HP,SUSE,Intel,AMD,Cisco,Microsoft,Citrix,Dell等參與貢獻設計和實現,更加推動了OpenStack的高速成長,
打破了Amazon等少數公司在市場上壟斷的局面,解決了雲服務被單一廠商繫結的問題並降低了雲平臺部署成本。

  OpenStack資源排程和優化現狀

  OpenStack的虛擬機器排程策略主要是由FilterScheduler和ChanceScheduler實現的,其中FilterScheduler作為預設的排程引擎實現了基於主機過濾(filtering)和權值計算(weighing)的排程演算法,而ChanceScheduler則是基於隨機演算法來選擇可用主機的簡單排程引擎。如圖1是FilterScheduler的虛擬機器排程過程,它支援多種built-in的filter和weigher來滿足一些常見的業務場景。在設計上,OpenStack基於filter和weigher支援第三方擴充套件,因此使用者可以通過自定義filter和weigher,或者使用json資源選擇表示式來影響虛擬機器的排程策略從而滿足不同的業務需求。

  

圖片描述

 

  圖 1:OpenStack排程workflow

  Built-in的filter(部分):

  ComputeFilter過濾計算節點down機的主機

  CoreFilter過濾vcpu不滿足虛擬機器請求的主機

  DiskFilter過濾disk不滿足虛擬機器請求的主機

  RamFilter過濾ram不滿足虛擬機器請求的主機

  ImagePropertiesFilter過濾 architecture, hypervisor type不滿足虛擬機器請求的主機

  SameHostFilter過濾和指定虛擬機器不在同一個主機上的主機

  DifferentHostFilter過濾和指定虛擬機器在同一個主機上的主機

  JsonFilter過濾不滿足OpenStack自定義的json資源選擇表示式的主機:json資源選擇表示式形如 query=’[“>”, “$cpus”,4]’表示過濾掉cpus小於等於4的主機

  Built-in的weigher(部分):

  RAMWeigher根據主機的可用ram排序

  IoOpsWeigher根據主機的io負載排序

  在一個複雜的雲系統中,對雲端計算資源的監控和優化對於保證雲系統的健康執行,提高IT管理的效率有重要的作用。最新版本的OpenStack也沒有提供類似的功能,這可能是由於雲系統的監控的物件和優化目標對於不同的使用者有不同的要求,難於形成統一實現和架構,但是OpenStack已經意識到這部分的重要性並且啟動了2個專案來彌補這個短板,當前它們都處於孵化階段:

  Watcher(https://github.com/openstack/watcher):一個靈活的、可伸縮的多租戶OpenStack-based雲資源優化服務,通過智慧的虛擬機器遷移策略來減少資料中心的運營成本和增加能源的利用率。

  Congress(https://github.com/openstack/congress):一個基於異構雲環境的策略宣告、監控,實施,審計的框架。

  PRS簡介

  由於OpenStack開源的特性,直接投入商業使用可能面臨後期升級,維護,定製化需求無法推進的問題,因此一些有技術實力的公司都基於OpenStack開發了自己商業化的版本,這些商業化版本的OpenStack都包含了一些獨有的特性並和社群開源的OpenStack形成了差異化, 比如完善了OpenStack虛擬機器的排程和編排功能,加強了雲系統的執行時監控和優化,彌補了雲系統自動化災難恢復的空缺,簡化了雲系統的安裝和部署,引入了基於資源使用時長的帳務費用系統等等。PRS(Platform Resource
Scheduler)是IBM Platform Computing公司的基於OpenStack的商業化資源排程,編排和優化的引擎,它基於對雲端計算資源的抽象和預先定義的排程和優化策略,為虛擬機器的放置動態地分配和平衡計算容量,並且不間斷地監控主機的健康狀況,提高了主機的利用率並保持使用者業務的持續性和穩定性,降低IT管理成本。PRS採用可插拔式的無侵入設計,100%相容OpenStack API, 並且對外提供標準的介面,方便使用者進行二次開發,以滿足不同使用者的業務需求。本文將會從虛擬機器初始排程策略,實時監控和優化策略,使用者自定義OpenStack
Filter,虛擬機器排程失敗的Trouble Shooting Report和基於拓撲結構排程等方面概括介紹PRS的主要功能和使用場景,之後將有一系列文章對每個主題展開深入介紹。

  虛擬機器初始排程策略

  虛擬機器的初始放置策略指的是使用者根據虛擬機器對資源的要求決定虛擬機器究竟應該建立在哪種型別的主機上,這種資源要求就是一些約束條件或者策略。例如,使用者的虛擬機器需要選擇CPU或者記憶體大小滿足一定要求的主機去放置,虛擬機器是需要放置在北京的資料中心還是西安的資料中心,幾個虛擬機器是放在相同的主機上還是放置在不同的主機上等等。原生OpenStack排程框架在靈活的支援第三方的filter和weigher的同時也喪失了對排程策略的統一配置和管理,當前PRS支援如圖2的初始放置策略,並且可以在執行時動態的修改放置策略。

  

圖片描述

 

  圖2:虛擬機器初始放置策略

  Packing: 虛擬機器儘量放置在含有虛擬機器數量最多的主機上

  Stripping: 虛擬機器儘量放置在含有虛擬機器數量最少的主機上

  CPU load balance:虛擬機器儘量放在可用core最多的主機上

  Memory load balance:虛擬機器儘量放在可用memory 最多的主機上

  Affinity : 多個虛擬機器需要放置在相同的主機上

  AntiAffinity: 多個虛擬機器需要放在在不同的主機上

  CPU Utilization load balance:虛擬機器儘量放在CPU利用率最低的主機上

  實時監控和優化策略

  隨著OpenStack雲系統的持續執行,雲系統中的計算資源由於虛擬機器的放置會產生碎片或分配不均,虛擬機器的執行效率由於主機load過載而降低,主機的down機會造成使用者應用程式無法使用等一系列問題。 使用者可以通過人工干預的方式來排除這些問題. 例如使用者可以將load比較高的主機上的虛擬機器migrate到其他主機上來降低該主機的load,通過rebuild虛擬機器從down掉的主機上到其它可用主機上解決使用者應用程式高可用性的問題,但這需要消耗大量的IT維護成本,並且引入更多的人為的風險。PRS針對這些問題提供瞭如圖3的兩種型別的執行時策略來持續的監控和優化雲系統。

  

圖片描述

 

  圖 3:監控和優化策略

  基於虛擬機器的HA策略:當主機down機後,主機上執行的虛擬機器會自動rebuild到新的可用主機上

  基於主機的Load Balance策略 :支援Packing/Stripping/CPU load balance/Memory load balance/CPU Utilization load balance策略,根據使用者設定的閾值持續不斷的平衡系統中主機上的計算資源

  使用者可以根據業務需要定義相應的優化策略監控主機的健康狀況並進行持續不斷的優化。例如,使用者定義的叢集中主機執行時監控Load Balance策略是 CPU Utilization Load Balance,並且閾值是70%, 這就意味著當主機的CPU利用率超過70%的時候,這個主機上的虛擬機器會被PRS線上遷移到別的CPU 利用率小於70%的主機上,從而保證該主機始終處於健康的狀態,並且平衡了叢集中主機的計算資源。這兩種執行時監控策略可以同時執行並且可以指定監控的範圍:

  整個叢集:監控的策略作用於整個叢集中所有的主機

  Host aggregation:host aggregation是OpenStack對一群具有相同主機屬性的一個邏輯劃分,這樣使用者可以根據業務需求對不同的host aggregation定義不同Load Balance策略,例如對 aggregation 1 應用Packing策略, 對 aggregation 2應用Stripping策略。

  使用者自定義OpenStack Filter

  OpenStack對虛擬機器的排程是基於對主機的過濾和權值計算,PRS也實現了相同的功能,並且為提供了更加優雅的介面方便使用者定義出複雜的filter鏈,並且配合使用虛擬機器初始排程策略從而動態的將使用者自定義的虛擬機器放置策略插入到虛擬機器的排程過程中去滿足業務的需求:

  PRS filter支援定義working scope:OpenStack原生的filter會預設作用於虛擬機器排程的整個生命週期,比如 create, live migrate, cold migrate, resize等。而PRS為filter定義了working scope, 這樣可以實現讓某些filter在create虛擬機器的時候生效,某些filter在虛擬機器migrate的時候生效,並且還支援讓一個filter工作在多個working scope.

  PRS filter支援定義include hosts和exclude hosts:使用者可以直接在filter中為虛擬機器指定需要排除的主機列表或者需要放置的主機列表

  PRS filter支援定義PRS資源查詢條件:使用者也可以在filter中定義PRS資源查詢條件,直接選擇條件具備住主機列表,例如 select(vcpu>2 && memSize>1024)

  

圖片描述

 

  圖 4:PRS filter workflow

  虛擬機器排程失敗Trouble Shooting Report

  當虛擬機器建立失敗處於Error的時候,雲系統應該提供足夠的能力方便管理員trouble shooting,從而儘快排除錯誤並保證雲系統正常執行。造成虛擬機器部署失敗的原因主要有2種:第一種是排程失敗,沒有足夠的計算資源或者合適的主機滿足虛擬機器虛擬機器的請求。 第二種是排程成功,但是在計算節點上部署虛擬機器的時候失敗,原因是多種多樣的,比如Libvirt錯誤,image型別錯誤, 建立虛擬機器網路失敗等。當前的OpenStack虛擬機器的Trouble Shooting機制不能夠清晰反映問題的原因,需要管理員大量的分析工作,這無疑增加了排除問題的難度和時間:

  對於虛擬機器排程失敗,OpenStack只提供 NoValidHost的錯誤異常來表明沒有可用的資源,使用者無法通過CLI(nova show $vm_uuid) 得到是哪個filter的約束條件造成排程失敗。

  對於部署失敗,管理員需要SSH到失敗的計算節點去檢查日誌檔案分析失敗原因

  PRS提供了trouble shooting report 統一的檢視顯示虛擬機器整個生命週期(create/migrate/resize/等)操作失敗的原因如圖5,虛擬機器test_vm在第一次建立的時候由於沒有足夠的計算資源或者合適的主機而失敗(“Error Message”選項有失敗原因,”Deployed Host”為空的列表)。由trouble shooting report的“Available Hosts”選項可以知道系統中有4臺主機,綠色的方框表示系統中每一個fillter的資源要求和滿足資源要求的主機列表。最終選擇的主機應該被包含在所有filter主機列表中。由ComputeFilter選擇的主機列表不包含主機“my-comp3”,可以得此主機的nov-compute
service可能被關閉,由DiskFilter的主機列表不包含“my-comp1”和主機“my-comp2”可以得知這些主機的可用disk資源不足(<1024MB),並且這兩個filter選擇的主機沒有交集,因此排程失敗,管理員可以根據這些資訊能明確的知道排程失敗的原因從而輕易的排除錯誤。

  

圖片描述

 

  圖 5:Trouble Shooting Report

  基於拓撲結構的排程

  OpenStack Heat是虛擬機器組的編排元件,它本身沒有排程模組,它基於Nova的FilterScheduler作為排程的引擎對一組或多組虛擬機器進行主機級別的扁平化排程和編排,但這種排程模型每次只能處理一個虛擬機器請求,當部署多個虛擬機器的時候,它不能根據資源請求進行統一的排程和回溯,將會造成排程結果不準確。 PRS不但支援主機級別的扁平化排程,還支援對一組同構虛擬機器內部或者一組虛擬機器和另一組虛擬機器在一個樹形拓撲結構上(Region,Zone,Rack,Host)上進行整體排程。基於拓撲結構的多個虛擬整體排程可以得到一些顯而易見的好處,比如在部署的時候為了拓撲結構上層級之間或虛擬機器之間獲得更好的通訊效能可以選擇Affinity的策略,為了獲得拓撲結構上層級之間或虛擬機器之間的高可用性,可以選擇Anti-Affinity策略。PRS通過和Heat的深度整合實現了基於拓撲結構的整體排程。新的Heat資源型別IBM::Policy::Group用來描述這種一組或多組虛擬機器在一個樹形的拓撲結構上的部署需求。

  Affinity:用來描述一組虛擬機器內部的在指定的拓撲結構層級上是Affinity的或者一組虛擬機器和另一組虛擬機器在指定的拓撲結構層級上是Affinity的。

  Anti-Affinity:用來描述一組虛擬機器內部的在指定的拓撲結構層級上是Anti-Affinity的或者一組虛擬機器和另一組虛擬機器在指定的拓撲結構層級上是Anti-Affinity的。

  MaxResourceLostPerNodeFailure:用來描述當拓撲結構指定層級發生單點故障時,使用者的一組虛擬機器在這個層級上的損失率不能高於一個閾值

  案例1:如圖6,使用者定義了2個auto scaling group tier1和tier2, 每個tier都需要2個虛擬機器,其中tier1需要虛擬機器在rack節點上Anti-Affinity,tier2需要虛擬機器在rack節點上Affinity,並且tier1和tier2上的虛擬機器之間需要滿足Affinity. 這個場景類似於在生產環境上部署2組web application, 要求執行database的虛擬機器(tier1)和執行web的虛擬機器(tier2)在相同的主機上(方便web伺服器和database伺服器通訊),並且2個執行database的虛擬機器(tier1)和2執行web的虛擬機器(tier2)不能同時執行在一臺主機上(rack級別上Anti-Affinity,擔心單rack單點故障造成所有的database伺服器或者web伺服器都不可用)。圖的左邊是一個部署的結果,紅色的虛擬機器的是web伺服器tier1,黃色的虛擬機器是database伺服器(tier2),
這樣host1上的database伺服器直接為host1上的web伺服器提供服務, host6上的database伺服器直接為host6上的web伺服器提供,並且rack1或者rack3的單點故障,不會造成使用者web服務的中斷。

  

圖片描述

 

  圖6: Affinity/Anti-Affinity策略

  案例2:如圖7,使用者定義了1個auto scaling group tier1, 這個tier1需要4個虛擬機器,要求當zone發生單點故障的時候,使用者的4個虛擬機器的損失率不能大於50%。這個場景類似於在生產環境上部署一個Nginx 伺服器叢集,當發生故障時,總有一半的Nginx伺服器能夠正常工作。圖的左邊是一個部署的結果,當zon1或者zone2中人任何一個發生故障,使用者的應用程式最多損失2個Nginx伺服器,滿足使用者的業務要求,這樣使用者在部署的時候就通過整體優化的虛擬機器放置策略實現應用程式的高可用性而不必等節點失敗的時候通過PRS
HA策略的監控策略亡羊補牢。

  

圖片描述

   圖7: MaxResourceLostPerNodeFailure策略