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