OpenStack簡(jiǎn)介：OpenStack是旨在為公有及私有云的建設(shè)與管理提供軟件的一個(gè)開(kāi)源項(xiàng)目，采用Apache授權(quán)協(xié)議，它的核心任務(wù)是簡(jiǎn)化云系統(tǒng)的部署過(guò)程，并且賦予其良好的可擴(kuò)展性和可管理性。它已經(jīng)在當(dāng)前的基礎(chǔ)設(shè)施即服務(wù)(IaaS)資源管理領(lǐng)域占據(jù)領(lǐng)導(dǎo)地位，成為公有云、私有云及混合云管理的“云操作系統(tǒng)”事實(shí)上的標(biāo)準(zhǔn)，在政府、電信、金融、制造、能源、零售、醫(yī)療、交通等行業(yè)成為企業(yè)創(chuàng)新的利器。OpenStack基于開(kāi)放的架構(gòu)，支持多種主流的虛擬化技術(shù)，許多重量級(jí)的科技公司如RedHat，AT&T，IBM，HP，SUSE，Intel，AMD，Cisco，Microsoft，Citrix，Dell等參與貢獻(xiàn)設(shè)計(jì)和實(shí)現(xiàn)，更加推動(dòng)了OpenStack的高速成長(zhǎng)，打破了Amazon等少數(shù)公司在市場(chǎng)上壟斷的局面，解決云服務(wù)被單一廠商綁定的問(wèn)題并降低了云平臺(tái)部署成本。
OpenStack資源調(diào)度和優(yōu)化現(xiàn)狀
OpenStack的虛擬機(jī)調(diào)度策略主要是由FilterScheduler和ChanceScheduler實(shí)現(xiàn)的，其中FilterScheduler作為默認(rèn)的調(diào)度引擎實(shí)現(xiàn)了基于主機(jī)過(guò)濾(filtering)和權(quán)值計(jì)算(weighing)的調(diào)度算法，而ChanceScheduler則是基于隨機(jī)算法來(lái)選擇可用主機(jī)的簡(jiǎn)單調(diào)度引擎。如圖1是FilterScheduler的虛擬機(jī)調(diào)度過(guò)程，它支持多種built-in的filter和weigher來(lái)滿(mǎn)足一些常見(jiàn)的業(yè)務(wù)場(chǎng)景。在設(shè)計(jì)上，OpenStack基于filter和weigher支持第三方擴(kuò)展，因此用戶(hù)可以通過(guò)自定義filter和weigher，或者使用json資源選擇表達(dá)式來(lái)影響虛擬機(jī)的調(diào)度策略從而滿(mǎn)足不同的業(yè)務(wù)需求。
圖1 OpenStack調(diào)度workflow
Built-in的filter(部分)：
1 ComputeFilter過(guò)濾計(jì)算節(jié)點(diǎn)down機(jī)的主機(jī)
2 CoreFilter過(guò)濾vcpu不滿(mǎn)足虛擬機(jī)請(qǐng)求的主機(jī)
3 DiskFilter過(guò)濾disk不滿(mǎn)足虛擬機(jī)請(qǐng)求的主機(jī)
4 RamFilter過(guò)濾ram不滿(mǎn)足虛擬機(jī)請(qǐng)求的主機(jī)
5 ImagePropertiesFilter過(guò)濾architecture，hypervisortype不滿(mǎn)足虛擬機(jī)請(qǐng)求的主機(jī)
6 SameHostFilter過(guò)濾和指定虛擬機(jī)不在同一個(gè)主機(jī)上的主機(jī)
7 DifferentHostFilter過(guò)濾和指定虛擬機(jī)在同一個(gè)主機(jī)上的主機(jī)
JsonFilter過(guò)濾不滿(mǎn)足OpenStack自定義的json資源選擇表達(dá)式的主機(jī)：json資源選擇表達(dá)式形如query=’[“>”，“$cpus”，4]’表示過(guò)濾掉cpus小于等于4的主機(jī)
Built-in的weigher(部分)：
1 RAMWeigher根據(jù)主機(jī)的可用ram排序
2 IoOpsWeigher根據(jù)主機(jī)的io負(fù)載排序
在一個(gè)復(fù)雜的云系統(tǒng)中，對(duì)云計(jì)算資源的監(jiān)控和優(yōu)化對(duì)于保證云系統(tǒng)的健康運(yùn)行，提高IT管理的效率有重要的作用。最新版本的OpenStack也沒(méi)有提供類(lèi)似的功能，這可能是由于云系統(tǒng)的監(jiān)控的對(duì)象和優(yōu)化目標(biāo)對(duì)于不同的用戶(hù)有不同的要求，難于形成統(tǒng)一實(shí)現(xiàn)和架構(gòu)，但是OpenStack已經(jīng)意識(shí)到這部分的重要性并且啟動(dòng)了2個(gè)項(xiàng)目來(lái)彌補(bǔ)這個(gè)短板，當(dāng)前它們都處于孵化階段：
Watcher(https：//github.com/openstack/watcher)：一個(gè)靈活的、可伸縮的多租戶(hù)OpenStack-based云資源優(yōu)化服務(wù)，通過(guò)智能的虛擬機(jī)遷移策略來(lái)減少數(shù)據(jù)中心的運(yùn)營(yíng)成本和增加能源的利用率。
Congress(https：//github.com/openstack/congress)：一個(gè)基于異構(gòu)云環(huán)境的策略聲明、監(jiān)控，實(shí)施，審計(jì)的框架。
PRS簡(jiǎn)介
由于OpenStack開(kāi)源的特性，直接投入商業(yè)使用可能面臨后期升級(jí)，維護(hù)，定制化需求無(wú)法推進(jìn)的問(wèn)題，因此一些有技術(shù)實(shí)力的公司都基于OpenStack開(kāi)發(fā)了自己商業(yè)化的版本，這些商業(yè)化版本的OpenStack都包含了一些獨(dú)有的特性并和社區(qū)開(kāi)源的OpenStack形成了差異化，比如完善了OpenStack虛擬機(jī)的調(diào)度和編排功能，加強(qiáng)了云系統(tǒng)的運(yùn)行時(shí)監(jiān)控和優(yōu)化，彌補(bǔ)了云系統(tǒng)自動(dòng)化災(zāi)難恢復(fù)的空缺，簡(jiǎn)化了云系統(tǒng)的安裝和部署，引入了基于資源使用時(shí)長(zhǎng)的帳務(wù)費(fèi)用系統(tǒng)等等。PRS(PlatformResourceScheduler)是IBMPlatformComputing公司的基于OpenStack的商業(yè)化資源調(diào)度，編排和優(yōu)化的引擎，它基于對(duì)云計(jì)算資源的抽象和預(yù)先定義的調(diào)度和優(yōu)化策略，為虛擬機(jī)的放置動(dòng)態(tài)地分配和平衡計(jì)算容量，并且不間斷地監(jiān)控主機(jī)的健康狀況，提高了主機(jī)的利用率并保持用戶(hù)業(yè)務(wù)的持續(xù)性和穩(wěn)定性，降低IT管理成本。PRS采用可插拔式的無(wú)侵入設(shè)計(jì)，100%兼容OpenStackAPI，并且對(duì)外提供標(biāo)準(zhǔn)的接口，方便用戶(hù)進(jìn)行二次開(kāi)發(fā)，以滿(mǎn)足不同用戶(hù)的業(yè)務(wù)需求。本文將會(huì)從虛擬機(jī)初始調(diào)度策略，實(shí)時(shí)監(jiān)控和優(yōu)化策略，用戶(hù)自定義OpenStackFilter，虛擬機(jī)調(diào)度失敗的TroubleShootingReport和基于拓?fù)浣Y(jié)構(gòu)調(diào)度等方面概括介紹PRS的主要功能和使用場(chǎng)景，之后將有一系列文章對(duì)每個(gè)主題展開(kāi)深入介紹。
虛擬機(jī)初始調(diào)度策略
虛擬機(jī)的初始放置策略指的是用戶(hù)根據(jù)虛擬機(jī)對(duì)資源的要求決定虛擬機(jī)究竟應(yīng)該創(chuàng)建在哪種類(lèi)型的主機(jī)上，這種資源要求就是一些約束條件或者策略。例如，用戶(hù)的虛擬機(jī)需要選擇CPU或者內(nèi)存大小滿(mǎn)足一定要求的主機(jī)去放置，虛擬機(jī)是需要放置在北京的數(shù)據(jù)中心還是西安的數(shù)據(jù)中心，幾個(gè)虛擬機(jī)是放在相同的主機(jī)上還是放置在不同的主機(jī)上等等。原生OpenStack調(diào)度框架在靈活的支持第三方的filter和weigher的同時(shí)也喪失了對(duì)調(diào)度策略的統(tǒng)一配置和管理，當(dāng)前PRS支持如圖2的初始放置策略，并且可以在運(yùn)行時(shí)動(dòng)態(tài)的修改放置策略。
圖2 虛似機(jī)初始放置策略
- Packing：虛擬機(jī)盡量放置在含有虛擬機(jī)數(shù)量最多的主機(jī)上
- Stripping：虛擬機(jī)盡量放置在含有虛擬機(jī)數(shù)量最少的主機(jī)上
- CPUlOAdbalance：虛擬機(jī)盡量放在可用core最多的主機(jī)上
- Memoryloadbalance：虛擬機(jī)盡量放在可用memory最多的主機(jī)上
- Affinity：多個(gè)虛擬機(jī)需要放置在相同的主機(jī)上
- AntiAffinity：多個(gè)虛擬機(jī)需要放在在不同的主機(jī)上
- CPUUtilizationloadbalance：虛擬機(jī)盡量放在CPU利用率最低的主機(jī)上
實(shí)時(shí)監(jiān)控和優(yōu)化策略
隨著OpenStack云系統(tǒng)的持續(xù)運(yùn)行，云系統(tǒng)中的計(jì)算資源由于虛擬機(jī)的放置會(huì)產(chǎn)生碎片或分配不均，虛擬機(jī)的運(yùn)行效率由于主機(jī)load過(guò)載而降低，主機(jī)的down機(jī)會(huì)造成用戶(hù)應(yīng)用程序無(wú)法使用等一系列問(wèn)題。用戶(hù)可以通過(guò)人工干預(yù)的方式來(lái)排除這些問(wèn)題.例如用戶(hù)可以將load比較高的主機(jī)上的虛擬機(jī)migrate到其他主機(jī)上來(lái)降低該主機(jī)的load，通過(guò)rebuild虛擬機(jī)從down掉的主機(jī)上到其它可用主機(jī)上解決用戶(hù)應(yīng)用程序高可用性的問(wèn)題，但這需要消耗大量的IT維護(hù)成本，并且引入更多的人為的風(fēng)險(xiǎn)。PRS針對(duì)這些問(wèn)題提供了如圖3的兩種類(lèi)型的運(yùn)行時(shí)策略來(lái)持續(xù)的監(jiān)控和優(yōu)化云系統(tǒng)。
圖3 監(jiān)控和優(yōu)化策略
基于虛擬機(jī)的HA策略：當(dāng)主機(jī)down機(jī)后，主機(jī)上運(yùn)行的虛擬機(jī)會(huì)自動(dòng)rebuild到新的可用主機(jī)上
基于主機(jī)的LoadBalance策略：支持Packing/Stripping/CPUloadbalance/Memoryloadbalance/CPUUtilizationloadbalance策略，根據(jù)用戶(hù)設(shè)置的閾值持續(xù)不斷的平衡系統(tǒng)中主機(jī)上的計(jì)算資源
用戶(hù)可以根據(jù)業(yè)務(wù)需要定義相應(yīng)的優(yōu)化策略監(jiān)控主機(jī)的健康狀況并進(jìn)行持續(xù)不斷的優(yōu)化。例如，用戶(hù)定義的集群中主機(jī)運(yùn)行時(shí)監(jiān)控LoadBalance策略是CPUUtilizationLoadBalance，并且閾值是70%，這就意味著當(dāng)主機(jī)的CPU利用率超過(guò)70%的時(shí)候，這個(gè)主機(jī)上的虛擬機(jī)會(huì)被PRS在線遷移到別的CPU利用率小于70%的主機(jī)上，從而保證該主機(jī)始終處于健康的狀態(tài)，并且平衡了集群中主機(jī)的計(jì)算資源。這兩種運(yùn)行時(shí)監(jiān)控策略可以同時(shí)運(yùn)行并且可以指定監(jiān)控的范圍：
整個(gè)集群：監(jiān)控的策略作用于整個(gè)集群中所有的主機(jī)
Hostaggregation：hostaggregation是OpenStack對(duì)一群具有相同主機(jī)屬性的一個(gè)邏輯劃分，這樣用戶(hù)可以根據(jù)業(yè)務(wù)需求對(duì)不同的hostaggregation定義不同LoadBalance策略，例如對(duì)aggregation1應(yīng)用Packing策略，對(duì)aggregation2應(yīng)用Stripping策略。
用戶(hù)自定義OpenStackFilter
OpenStack對(duì)虛擬機(jī)的調(diào)度是基于對(duì)主機(jī)的過(guò)濾和權(quán)值計(jì)算，PRS也實(shí)現(xiàn)了相同的功能，并且為提供了更加優(yōu)雅的接口方便用戶(hù)定義出復(fù)雜的filter鏈，并且配合使用虛擬機(jī)初始調(diào)度策略從而動(dòng)態(tài)的將用戶(hù)自定義的虛擬機(jī)放置策略插入到虛擬機(jī)的調(diào)度過(guò)程中去滿(mǎn)足業(yè)務(wù)需求：
PRSfilter支持定義workingscope：OpenStack原生的filter會(huì)默認(rèn)作用于虛擬機(jī)調(diào)度的整個(gè)生命周期，比如create，livemigrate，coldmigrate，resize等。而PRS為filter定義了workingscope，這樣可以實(shí)現(xiàn)讓某些filter在create虛擬機(jī)的時(shí)候生效，某些filter在虛擬機(jī)migrate的時(shí)候生效，并且還支持讓一個(gè)filter工作在多個(gè)workingscope
PRSfilter支持定義includehosts和excludehosts：用戶(hù)可以直接在filter中為虛擬機(jī)指定需要排除的主機(jī)列表或者需要放置的主機(jī)列表
PRSfilter支持定義PRS資源查詢(xún)條件：用戶(hù)也可以在filter中定義PRS資源查詢(xún)條件，直接選擇條件具備住主機(jī)列表，例如select(vcpu>2&&memSize>1024)
圖4 PRS filter workflow
虛擬機(jī)調(diào)度失敗TroubleShootingReport
當(dāng)虛擬機(jī)創(chuàng)建失敗處于Error的時(shí)候，云系統(tǒng)應(yīng)該提供足夠的能力方便管理員troubleshooting，從而盡快排除錯(cuò)誤并保證云系統(tǒng)正常運(yùn)行。造成虛擬機(jī)部署失敗的原因主要有2種：第一種是調(diào)度失敗，沒(méi)有足夠的計(jì)算資源或者合適的主機(jī)滿(mǎn)足虛擬機(jī)虛擬機(jī)的請(qǐng)求。第二種是調(diào)度成功，但是在計(jì)算節(jié)點(diǎn)上部署虛擬機(jī)的時(shí)候失敗，原因是多種多樣的，比如Libvirt錯(cuò)誤，image類(lèi)型錯(cuò)誤，創(chuàng)建虛擬機(jī)網(wǎng)絡(luò)失敗等。當(dāng)前的OpenStack虛擬機(jī)的TroubleShooting機(jī)制不能清晰反映問(wèn)題的原因，需要管理員大量的分析工作，這無(wú)疑增加了排除問(wèn)題的難度和時(shí)間：
對(duì)于虛擬機(jī)調(diào)度失敗，OpenStack只提供NoValidHost的錯(cuò)誤異常來(lái)表明沒(méi)有可用的資源，用戶(hù)無(wú)法通過(guò)CLI(novashow$vm_uuid)得到是哪個(gè)filter的約束條件造成調(diào)度失敗。
對(duì)于部署失敗，管理員需要SSH到失敗的計(jì)算節(jié)點(diǎn)去檢查日志文件分析失敗原因
PRS提供了troubleshootingreport統(tǒng)一的視圖顯示虛擬機(jī)整個(gè)生命周期(create/migrate/resize/等)操作失敗的原因如圖5，虛擬機(jī)test_vm在第一次創(chuàng)建的時(shí)候由于沒(méi)有足夠的計(jì)算資源或者合適的主機(jī)而失敗(“ErrorMessage”選項(xiàng)有失敗原因，”DeployedHost”為空的列表)。由troubleshootingreport的“AvailableHosts”選項(xiàng)可以知道系統(tǒng)中有4臺(tái)主機(jī)，綠色的方框表示系統(tǒng)中每一個(gè)fillter的資源要求和滿(mǎn)足資源要求的主機(jī)列表。最終選擇的主機(jī)應(yīng)該被包含在所有filter主機(jī)列表中。由ComputeFilter選擇的主機(jī)列表不包含主機(jī)“my-comp3”，可以得此主機(jī)的nov-computeservice可能被關(guān)閉，由DiskFilter的主機(jī)列表不包含“my-comp1”和主機(jī)“my-comp2”可以得知這些主機(jī)的可用disk資源不足(<1024MB)，并且這兩個(gè)filter選擇的主機(jī)沒(méi)有交集，因此調(diào)度失敗，管理員可以根據(jù)這些信息能明確的知道調(diào)度失敗的原因從而輕易的排除錯(cuò)誤。
圖5 Trouble Shooting Report
基于拓?fù)浣Y(jié)構(gòu)的調(diào)度
OpenStackHeat是虛擬機(jī)組的編排組件，它本身沒(méi)有調(diào)度模塊，它基于Nova的FilterScheduler作為調(diào)度的引擎對(duì)一組或多組虛擬機(jī)進(jìn)行主機(jī)級(jí)別的扁平化調(diào)度和編排，但這種調(diào)度模型每次只能處理一個(gè)虛擬機(jī)請(qǐng)求，當(dāng)部署多個(gè)虛擬機(jī)的時(shí)候，它不能根據(jù)資源請(qǐng)求進(jìn)行統(tǒng)一的調(diào)度和回溯，將會(huì)造成調(diào)度結(jié)果不準(zhǔn)確。PRS不但支持主機(jī)級(jí)別的扁平化調(diào)度，還支持對(duì)一組同構(gòu)虛擬機(jī)內(nèi)部或者一組虛擬機(jī)和另一組虛擬機(jī)在一個(gè)樹(shù)形拓?fù)浣Y(jié)構(gòu)上(Region，Zone，Rack，Host)上進(jìn)行整體調(diào)度�；谕�?fù)浣Y(jié)構(gòu)的多個(gè)虛擬整體調(diào)度可以得到一些顯而易見(jiàn)的好處，比如在部署的時(shí)候?yàn)榱送負(fù)浣Y(jié)構(gòu)上層級(jí)之間或虛擬機(jī)之間獲得更好的通信性能可以選擇Affinity的策略，為了獲得拓?fù)浣Y(jié)構(gòu)上層級(jí)之間或虛擬機(jī)之間的高可用性，可以選擇Anti-Affinity策略。PRS通過(guò)和Heat的深度集成實(shí)現(xiàn)了基于拓?fù)浣Y(jié)構(gòu)的整體調(diào)度。新的Heat資源類(lèi)型IBM：：Policy：：Group用來(lái)描述這種一組或多組虛擬機(jī)在一個(gè)樹(shù)形的拓?fù)浣Y(jié)構(gòu)上的部署需求。
Affinity：用來(lái)描述一組虛擬機(jī)內(nèi)部的在指定的拓?fù)浣Y(jié)構(gòu)層級(jí)上是Affinity的或者一組虛擬機(jī)和另一組虛擬機(jī)在指定的拓?fù)浣Y(jié)構(gòu)層級(jí)上是Affinity的。
Anti-Affinity：用來(lái)描述一組虛擬機(jī)內(nèi)部的在指定的拓?fù)浣Y(jié)構(gòu)層級(jí)上是Anti-Affinity的或者一組虛擬機(jī)和另一組虛擬機(jī)在指定的拓?fù)浣Y(jié)構(gòu)層級(jí)上是Anti-Affinity的。
MaxResourceLostPerNodeFailure：用來(lái)描述當(dāng)拓?fù)浣Y(jié)構(gòu)指定層級(jí)發(fā)生單點(diǎn)故障時(shí)，用戶(hù)的一組虛擬機(jī)在這個(gè)層級(jí)上的損失率不能高于一個(gè)閾值。
案例1：如圖6，用戶(hù)定義了2個(gè)autoscalinggrouptier1和tier2，每個(gè)tier都需要2個(gè)虛擬機(jī)，其中tier1需要虛擬機(jī)在rack節(jié)點(diǎn)上Anti-Affinity，tier2需要虛擬機(jī)在rack節(jié)點(diǎn)上Affinity，并且tier1和tier2上的虛擬機(jī)之間需要滿(mǎn)足Affinity.這個(gè)場(chǎng)景類(lèi)似于在生產(chǎn)環(huán)境上部署2組webapplication，要求運(yùn)行database的虛擬機(jī)(tier1)和運(yùn)行web的虛擬機(jī)(tier2)在相同的主機(jī)上(方便web服務(wù)器和database服務(wù)器通信)，并且2個(gè)運(yùn)行database的虛擬機(jī)(tier1)和2運(yùn)行web的虛擬機(jī)(tier2)不能同時(shí)運(yùn)行在一臺(tái)主機(jī)上(rack級(jí)別上Anti-Affinity，擔(dān)心單rack單點(diǎn)故障造成所有的database服務(wù)器或者web服務(wù)器都不可用)。
圖的左邊是一個(gè)部署的結(jié)果，紅色的虛擬機(jī)的是web服務(wù)器tier1，黃色的虛擬機(jī)是database服務(wù)器(tier2)，這樣host1上的database服務(wù)器直接為host1上的web服務(wù)器提供服務(wù)，host6上的database服務(wù)器直接為host6上的web服務(wù)器提供，并且rack1或者rack3的單點(diǎn)故障，不會(huì)造成用戶(hù)web服務(wù)的中斷。
圖6 Affintylanti-Affinity策略
案例2：如圖7，用戶(hù)定義了1個(gè)autoscalinggrouptier1，這個(gè)tier1需要4個(gè)虛擬機(jī)，要求當(dāng)zone發(fā)生單點(diǎn)故障的時(shí)候，用戶(hù)的4個(gè)虛擬機(jī)的損失率不能大于50%。這個(gè)場(chǎng)景類(lèi)似于在生產(chǎn)環(huán)境上部署一個(gè)Nginx服務(wù)器集群，當(dāng)發(fā)生故障時(shí)，總有一半的Nginx服務(wù)器能夠正常工作。圖的左邊是一個(gè)部署的結(jié)果，當(dāng)zon1或者zone2中人任何一個(gè)發(fā)生故障，用戶(hù)的應(yīng)用程序最多損失2個(gè)Nginx服務(wù)器，滿(mǎn)足用戶(hù)的業(yè)務(wù)要求，這樣用戶(hù)在部署的時(shí)候就通過(guò)整體優(yōu)化的虛擬機(jī)放置策略實(shí)現(xiàn)應(yīng)用程序的高可用性而不必等節(jié)點(diǎn)失敗的時(shí)候通過(guò)PRSHA策略的監(jiān)控策略亡羊補(bǔ)牢。
圖7 MaxResourceLostPerNodeFailure策略
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴(lài)品牌。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題：OpenStack云端的資源調(diào)度和優(yōu)化剖析
本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839719604.html
相關(guān)文章
