華云聊創(chuàng)新：云之大腦是如何煉成的

 　　導(dǎo)讀：何謂云之“大腦”?

　　云計算技術(shù)是一系列復(fù)雜基礎(chǔ)技術(shù)的綜合體，包括物理設(shè)備管理、計算虛擬化、分布式存儲、網(wǎng)絡(luò)虛擬化以及軟件定義數(shù)據(jù)中心等，基于這些技術(shù)構(gòu)建的云計算平臺無疑是一套復(fù)雜的系統(tǒng)。在這樣復(fù)雜的系統(tǒng)中充當(dāng)“大腦”角色，管控決策所有資源使用的部件是云調(diào)度器。

　　在云計算的模式下，傳統(tǒng)“煙囪式”的獨立的服務(wù)器、存儲和網(wǎng)絡(luò)等物理資源被虛擬化成一個個共享資源池，云調(diào)度器通過資源使用調(diào)度的策略自動為云平臺上的業(yè)務(wù)統(tǒng)一調(diào)配資源，以滿足業(yè)務(wù)對基礎(chǔ)設(shè)施資源的動態(tài)需求。

　　本文將為您解密云之“大腦”的工作原理，展示華云數(shù)據(jù)在OpenStack核心領(lǐng)域的技術(shù)創(chuàng)新。

　　資源的分配和調(diào)度是云計算中的關(guān)鍵技術(shù)，那么云調(diào)度器是如何工作呢?作為國內(nèi)最早一批開始對Openstack進(jìn)行研究及應(yīng)用的團(tuán)隊，下面就以目前流行的開源云計算平臺Openstack為例，闡述其調(diào)度器(Nova scheduler)組件是如何管理和控制云平臺資源的。Nova scheduler是Openstack核心服務(wù)nova的組件之一，主要負(fù)責(zé)為創(chuàng)建、啟動的云主機(jī)實例尋找合適的計算節(jié)點，同時在遷移云主機(jī)的時候負(fù)責(zé)檢查目標(biāo)端計算節(jié)點的物理資源是否足夠。下面就談一談我們對Nova scheduler技術(shù)原理的解析與應(yīng)用優(yōu)化。

　　原理解析

　　下圖是Openstack架構(gòu)圖，從中我們可以看出Nova scheduler是通過與Message queue和Nova database交互來完成調(diào)度任務(wù)。

　　云調(diào)度器的核心任務(wù)是：基于業(yè)務(wù)對資源的請求，從當(dāng)前所管理的所有云資源中選擇最適合的資源分配給該業(yè)務(wù)，使該業(yè)務(wù)正常部署和運行;但何為“最適合”?在不同的場景下可能實質(zhì)含義不同，有的希望業(yè)務(wù)盡量運行在較少數(shù)量的機(jī)器上以節(jié)省電力消耗，有的則希望業(yè)務(wù)盡量均勻分布在所有可用的服務(wù)器上，以保障運行性能;因此，這里的“最適合”是相對于特定場景下所定義的調(diào)度策略而言的。

　　下圖是Nova scheduler的簡化工作流程圖，首先根據(jù)配置的Filters(過濾器)過濾出符合條件的主機(jī)列表，然后對得到的主機(jī)列表進(jìn)行權(quán)重并排序，最后選出最優(yōu)的Host。

　　Nova scheduler的主要流程包括：

　　2.1主機(jī)過濾(Filters)

　　2.2權(quán)值計算(Weighting)

　　2.1 主機(jī)過濾

　　所有的Filters實現(xiàn)都位于nova/scheduler/filters目錄，以O(shè)penstack Mitaka版本為例：

　　├── affinity_filter.py

　　├── aggregate_image_properties_isolation.py

　　├── aggregate_instance_extra_specs.py

　　├── aggregate_multitenancy_isolation.py

　　├── all_hosts_filter.py

　　├── availability_zone_filter.py

　　├── compute_capabilities_filter.py

　　├── compute_filter.py

　　├── core_filter.py

　　├── cpu_pinning_filter.py

　　├── disk_filter.py

　　├── exact_core_filter.py

　　├── exact_disk_filter.py

　　├── exact_ram_filter.py

　　├── image_props_filter.py

　　├── io_ops_filter.py

　　├── isolated_hosts_filter.py

　　├── json_filter.py

　　├── metrics_filter.py

　　├── numa_topology_filter.py

　　├── num_instances_filter.py

　　├── pci_passthrough_filter.py

　　├── ram_filter.py

　　├── retry_filter.py

　　├── trusted_filter.py

　　├── type_filter.py

　　目前，社區(qū)的OpenStack Mitaka支持以上這些過濾策略，開發(fā)者也可以根據(jù)具體需要實現(xiàn)自己的過濾策略。為了便于擴(kuò)展，Nova將一個調(diào)度器必須要實現(xiàn)的接口提取出來成為nova.scheduler.driver.Scheduler，只要繼承了該類并實現(xiàn)其中的接口，我們就可以自定義任何我們需要的調(diào)度器。啟用它們只需要在 /etc/nova/nova.conf配置文件中的添加該過濾器即可。

　　2.2 權(quán)值計算

　　所有的Weigher實現(xiàn)都位于nova/scheduler/weights目錄，以O(shè)penstack Mitaka版本為例：

　　├── _init__.py

　　├── metrics.py

　　├── ram.py

　　嘗試在一臺不適合的主機(jī)上創(chuàng)建云主機(jī)的代價比在一臺合適主機(jī)上創(chuàng)建的代價要高，比如說在一臺高性能主機(jī)上創(chuàng)建一臺功能簡單的普通云主機(jī)的代價是高的。

　　OpenStack對權(quán)值的計算需要一個或多個(Weight值，代價函數(shù))的組合，然后對每一個經(jīng)過過濾的主機(jī)調(diào)用代價函數(shù)進(jìn)行計算，將得到的值與weight值乘積，得到最終的權(quán)值。開發(fā)者可以實現(xiàn)自己的代價函數(shù)，設(shè)置自己的Weight值來更精確的利用更加復(fù)雜的算法選擇主機(jī)。下圖展示了對于每個宿主節(jié)點如何計算Weight值，以及最后根據(jù)Weight值排序，挑選出當(dāng)前最合適的節(jié)點的過程。

　　華云數(shù)據(jù)對Nova scheduler的優(yōu)化與應(yīng)用

　　3.1 基于指標(biāo)監(jiān)控的動態(tài)調(diào)度支持

　　OpenStack原生調(diào)度器自帶了很多基礎(chǔ)的Filters過濾策略，能夠滿足大部分的使用場景，但是這個調(diào)度的基本機(jī)制是靜態(tài)的，即在資源開通過程中基于請求的資源數(shù)量完成調(diào)度分配決策，而不考慮業(yè)務(wù)實際運行時對各種資源的使用情況，所以可能出現(xiàn)該調(diào)度分配在部署時是最優(yōu)的，但在運行時并不是。比如有兩臺服務(wù)器A和B，vm1已經(jīng)運行在Host A上，現(xiàn)在要開通vm2，假如按照資源最優(yōu)的方式調(diào)度，vm2被調(diào)度到Host B上，經(jīng)過一段時間的運行，發(fā)現(xiàn)vm1與vm2間經(jīng)常有大量網(wǎng)絡(luò)通信，我們知道在云環(huán)境下，跨節(jié)點的網(wǎng)絡(luò)通信性能是不如同節(jié)點上的網(wǎng)絡(luò)直接轉(zhuǎn)發(fā)，所以基于運行時情況，讓vm1與vm2同時運行在一個host上會是較優(yōu)的方式。

　　基于上述考慮，華云云平臺引入了基于運行時指標(biāo)監(jiān)控的動態(tài)調(diào)度支持，即通過對業(yè)務(wù)vm的持續(xù)指標(biāo)監(jiān)控(包括cpu、磁盤、內(nèi)存、網(wǎng)絡(luò)io、業(yè)務(wù)的峰谷、vm間的通信量等)，充分考慮業(yè)務(wù)vm在運行時的資源需求，提供再次優(yōu)化調(diào)度建議。通過納入運行時情況指標(biāo)運算，優(yōu)化調(diào)度所挑選的host和初始調(diào)度的host很可能不一樣，如果不一致，可以通過動態(tài)遷移機(jī)制完成遷移，使之達(dá)到階段性的最優(yōu)分布。

　　3.2 調(diào)整云主機(jī)大小

　　OpenStack Nova的resize功能內(nèi)在實現(xiàn)是基于冷遷移, 只不過resize在遷移后使用了一個不一樣的flavor。

　　OpenStack在處理resize接口的時候，每次resize都會隨機(jī)調(diào)度到某個可用主機(jī)節(jié)點，但這樣做存在一定缺陷。首先，每次resize都是一次冷遷移，即使當(dāng)前節(jié)點的資源足夠，也會發(fā)生一次冷遷移;這個在使用共享存儲的場景不是什么大問題，但是在本地存儲的場景，resize vm一定要做一次遷移就不太智能了。其次，有的客戶希望可以指定resize vm到用戶指定的節(jié)點，希望這個功能有更好的靈活性;

　　基于上述考慮，我們對resize功能進(jìn)行優(yōu)化與調(diào)整，當(dāng)執(zhí)行resize操作的時候，如果當(dāng)前節(jié)點上資源充足，優(yōu)先在當(dāng)前節(jié)點上完成resize，無需遷移;如果當(dāng)前節(jié)點資源不足，則由調(diào)度器調(diào)度到其他可用節(jié)點。此外，擴(kuò)展resize接口，使其支持resize云主機(jī)至隨機(jī)節(jié)點、指定節(jié)點或本地節(jié)點等策略，做到可控可配置。

　　3.3 基于分區(qū)部署的調(diào)度

　　隨著云計算服務(wù)類型的細(xì)化，需要針對不同的業(yè)務(wù)場景提供不同類型的云資源，在同一個數(shù)據(jù)中心內(nèi)會包括不同類型的計算節(jié)點，比如支持CPU獨占、支持GPU虛擬化、支持OVS-DPDK網(wǎng)絡(luò)加速等等。這些計算節(jié)點之間是功能與特性上的差異，華云數(shù)據(jù)合理優(yōu)化與利用Nova scheduler中基于分區(qū)的調(diào)度技術(shù)，實現(xiàn)把不同功能與特性的云主機(jī)需求開通到該類型的計算節(jié)點上。比如當(dāng)用戶創(chuàng)建CPU獨占或者GPU類型的VM時，OpenStack會在相應(yīng)分區(qū)類型的計算節(jié)點上開通。

　　總結(jié)

　　本文簡單介紹了云調(diào)度器Nova scheduler的基本原理與工作流程，同時分享了目前華云數(shù)據(jù)云平臺對其的部分?jǐn)U展優(yōu)化。目前OpenStack社區(qū)也在孵化類似Watcher等云平臺優(yōu)化項目，這些項目會與調(diào)度器結(jié)合提供云平臺的運行時優(yōu)化。如何把搭建的云平臺更好的運行，使之最大化的發(fā)揮能效，仍然有許多可挖掘優(yōu)化的地方。

　　華云數(shù)據(jù)對于OpenStack的研究和應(yīng)用，一直秉承源于社區(qū)、優(yōu)于社區(qū)、回饋社區(qū)的理念，緊跟社區(qū)的步伐，不斷改進(jìn)與優(yōu)化，將優(yōu)化的功能代碼回饋于社區(qū)、將優(yōu)秀的產(chǎn)品功能交付于客戶。

　　關(guān)于華云數(shù)據(jù)

　　華云數(shù)據(jù)集團(tuán)成立于2010年，是專業(yè)從事云計算服務(wù)的創(chuàng)新型公司，公司遍布于北京、上海、無錫、深圳、廈門、杭州、南京、臨沂等;香港、拉斯維加斯擁有運營中心，在國內(nèi)擁有超過15個城市的20余個數(shù)據(jù)中心和上萬臺物理服務(wù)器集群。網(wǎng)絡(luò)覆蓋中國電信、中國聯(lián)通以及華云數(shù)據(jù)自有BGP網(wǎng)絡(luò)，實現(xiàn)從邊緣到核心的全覆蓋。華云數(shù)據(jù)在北京、上海、廣州、深圳、香港打造高速專線直連的高品質(zhì)節(jié)點提升業(yè)務(wù)性能，提高用戶體驗。另外，2個中國電信美洲數(shù)據(jù)中心和2個香港數(shù)據(jù)中心還可滿足客戶對海外業(yè)務(wù)的需求。

　　華云數(shù)據(jù)以為用戶提供定制化混合架構(gòu)為目標(biāo)，產(chǎn)品覆蓋公有云、私有云、混合云及IDC轉(zhuǎn)云等領(lǐng)域，可以為用戶提供數(shù)十種解決方案，深度滿足企業(yè)云化需求。