優(yōu)惠活動 - 12周年慶本月新客福利
優(yōu)惠活動 - 12周年慶本月新客福利
優(yōu)惠活動 - 12周年慶本月新客福利

網(wǎng)站制作資源抽象層

資源抽象層主要是將下層的物理硬件資源統(tǒng)一進(jìn)行抽象,抽象成和單個(gè)物理硬件無關(guān)的資源集合,上層無須關(guān)心物理機(jī)器的型號,只需專注于具體的資源即可。
 
資源抽象層需要重點(diǎn)做好以下三件事。第一,收集和管理具體物理資源;
 
第二,重新封裝抽象的硬件資源屬性,使之成為上層可以使用的一個(gè)實(shí)體,既可以是容器也可以是虛擬機(jī)或者資源集合;
 
第三,數(shù)據(jù)存儲問題。做業(yè)務(wù)少不了要在本機(jī)存儲數(shù)據(jù),這樣機(jī)器就成為“有狀態(tài)”的,不利于全局調(diào)度資源。為了能夠全局調(diào)度,需要解決三個(gè)場景下的問題:是數(shù)據(jù)不需要永久本地存儲但是會實(shí)時(shí)寫到本地的,如應(yīng)用的日志;二是需要永久存儲的如DB數(shù)據(jù);三是分布式存儲場景中,要做到存儲與計(jì)算分離。


 
資源的收集和管理
 
資源的收集就是收集物理機(jī)的資源,例如當(dāng)前型號的機(jī)器有多少可用的CPU、內(nèi)存、磁盤等信息,它可以分為四個(gè)方面的內(nèi)容。
 
第一,資源的信息管理。有多少,用了多少,還有多少;
 
第二,大量物理機(jī)器的集群管理。除了通常幾十萬臺的機(jī)器管理功能外,還有一部分的任務(wù)管理,如負(fù)責(zé)接收 Master創(chuàng)建容器的任務(wù)等。
 
第三,資源的合理分配策略和算法。上層的資源請求最終會在每臺物理機(jī)上進(jìn)行分配,那么如何能?這里有根合理的分配策略和算法支撐。
 
第四,資源的信息管理就是要實(shí)現(xiàn)一個(gè)CMDB,能管理物理機(jī)和 vhost I的關(guān)聯(lián)關(guān)系,必須能管理上萬臺甚至十幾萬臺規(guī)模的機(jī)器集群。這樣的機(jī)器集群管理框架目前可選的比較少,我們選擇的是 Mesos,主要基于以下兩方面的考慮。一是 Mesos目前相對比較成熟,主流的大公司使用較多,在實(shí)際場景中的使用規(guī)模已達(dá)5萬臺左右;二是 Mesos擴(kuò)展性比較好,本身是輕量級的,可以靈活定制各種 Framework滿足業(yè)務(wù)需要。
 
我們分析一下為什么Msos能管理這么大的集群,它的資源分配策略以及它是如何靈活創(chuàng)建各種容器和配置網(wǎng)絡(luò)的。 Mesos的集群架構(gòu)。
 
Mesos的模塊化設(shè)計(jì)使得它的集群管理本身可做的事情并不多: Master僅僅把從Save收集的資源數(shù)據(jù)匯報(bào)給 Framework; Master和 Slave通過消息交互消息,不需要一直保持長連接。隨著 Slave規(guī)模的擴(kuò)大, Master的壓力并不會顯著增長。 Master本身的高可用是通過ZK( Zookeeper)來保證的,整個(gè)集群的架構(gòu)設(shè)計(jì)非常清晰。
 
當(dāng)集群規(guī)模很大時(shí),資源的管理和分配策略就會非常重要。分配策略對于最大化充分利用物理資源非常關(guān)鍵,所以要自己定制 Framework以便更精細(xì)化地分配資源。目前我們設(shè)計(jì)了4個(gè)分配策略。
 
(1)最大內(nèi)存剩余優(yōu)先分配策略。即集群中內(nèi)存剩余最多的優(yōu)先分配,目的是充
 
(2)最大CPU剩余優(yōu)先分配策略。類似于內(nèi)存分配,根據(jù)剩余的CPU數(shù)優(yōu)先分配給對CPU資源需求大的任務(wù);
 
3)最大最小資源公平分配策略。這種分配是根據(jù)當(dāng)前任務(wù)申請的資源,要查看當(dāng)前集群中的每臺機(jī)器、每種資源的使用量是否飽和,優(yōu)先把任務(wù)分配給當(dāng)前最空閑的機(jī)器;
 
(4)根據(jù)資源分配指定分配策略。這種方式比較靈活,就是可以根據(jù)用戶的需要把任務(wù)分配到指定的機(jī)器上執(zhí)行,例如可以給一些機(jī)器打上標(biāo)簽,讓某類任務(wù)在這些帶有標(biāo)簽的機(jī)器上執(zhí)行。
 
從上面的介紹可以知道網(wǎng)站制作Framework的修改需要比較靈活的支持,而當(dāng)前 Mesos的 Framework的更新還比較麻煩。如果要更新 Framework的代碼,就需要重啟每個(gè)Slave的 execute,進(jìn)而可能要停止 Slave上的任務(wù),這在生產(chǎn)環(huán)境中是很難接受的。有鑒于此,我們對 Framework進(jìn)行了無狀態(tài)設(shè)計(jì),在代碼實(shí)現(xiàn)上,改用動態(tài)語言如Groovy來編寫需要經(jīng)常修改的邏輯,這樣Govy實(shí)現(xiàn)的代碼就可以動態(tài)加載而不需重啟任務(wù),對 Framework的功能進(jìn)行調(diào)整就非常方便了。
本文地址:http://m.cdrpkj.cn//article/4544.html
相關(guān)文章:
最新文章: