国产日韩欧美一区二区三区三州_亚洲少妇熟女av_久久久久亚洲av国产精品_波多野结衣网站一区二区_亚洲欧美色片在线91_国产亚洲精品精品国产优播av_日本一区二区三区波多野结衣 _久久国产av不卡

?

一種基于容器編排技術(shù)的資源運(yùn)維系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

2018-07-03 08:39:24張勛張呈宇魏進(jìn)武
電信科學(xué) 2018年6期
關(guān)鍵詞:容器集群運(yùn)維

張勛,張呈宇,魏進(jìn)武

?

一種基于容器編排技術(shù)的資源運(yùn)維系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

張勛,張呈宇,魏進(jìn)武

(中國(guó)聯(lián)合網(wǎng)絡(luò)通信有限公司研究院大數(shù)據(jù)研究中心,北京 100176)

容器運(yùn)行、容器編排、框架編排是構(gòu)建容器運(yùn)維系統(tǒng)的核心功能。容器資源運(yùn)維系統(tǒng)的工作原理是運(yùn)用Mesos進(jìn)行資源調(diào)度、運(yùn)用Kubernetes進(jìn)行容器編排、運(yùn)用Marathon技術(shù)進(jìn)行框架管理。這3種技術(shù)在容器運(yùn)維中相互關(guān)聯(lián)、相互銜接,使得系統(tǒng)內(nèi)部機(jī)制正常運(yùn)轉(zhuǎn)。深入闡述了這3項(xiàng)技術(shù)是如何應(yīng)用到實(shí)際系統(tǒng)構(gòu)建中的,給了設(shè)計(jì)的組合架構(gòu)及改進(jìn)技術(shù)難點(diǎn),以解決中國(guó)聯(lián)通現(xiàn)有業(yè)務(wù)應(yīng)用容器化之后資源調(diào)度不平衡的問(wèn)題、現(xiàn)有物理集群彈性擴(kuò)/縮容的問(wèn)題以及實(shí)際業(yè)務(wù)部署統(tǒng)一運(yùn)營(yíng)的問(wèn)題,從而實(shí)現(xiàn)容器運(yùn)維管理系統(tǒng)的建設(shè)。

資源運(yùn)維系統(tǒng);容器調(diào)度;彈性擴(kuò)/縮容

1 引言

目前中國(guó)聯(lián)合網(wǎng)絡(luò)通信公司(以下簡(jiǎn)稱聯(lián)通)采用的以VMware虛擬機(jī)為主的虛擬化技術(shù),并不能滿足現(xiàn)有通信領(lǐng)域,實(shí)際業(yè)務(wù)應(yīng)用使用容器技術(shù)進(jìn)行虛擬化擴(kuò)/縮容的要求;并且聯(lián)通現(xiàn)有大數(shù)據(jù)集群,是以Hadoop為主的傳統(tǒng)固定集群模式,擴(kuò)/縮容需要依靠人工添加實(shí)際物理機(jī)的模式,重新安裝集群,人員、硬件成本開(kāi)銷(xiāo)較大。而現(xiàn)有開(kāi)源技術(shù)中,Kubernetes可以很好地解決使用Docker虛擬化技術(shù)之后容器的生命周期問(wèn)題,以及實(shí)際業(yè)務(wù)應(yīng)用容器化技術(shù)之后快速擴(kuò)/縮容的問(wèn)題。而Mesos可以解決Hadoop集群自動(dòng)化擴(kuò)/縮容的問(wèn)題。因此中國(guó)聯(lián)通研究院建設(shè)CU-DCOS容器運(yùn)維系統(tǒng),結(jié)合現(xiàn)有開(kāi)源技術(shù)解決上述兩項(xiàng)生產(chǎn)環(huán)境的固有問(wèn)題。研究開(kāi)源技術(shù)與聯(lián)通現(xiàn)有環(huán)境集成的容器資源運(yùn)維系統(tǒng)的實(shí)現(xiàn)。

2 現(xiàn)有容器應(yīng)用運(yùn)維的問(wèn)題

中國(guó)聯(lián)通目前的IT系統(tǒng)能夠滿足生產(chǎn)供給和部署,但在實(shí)際運(yùn)維中卻十分依賴第三方廠商的協(xié)助,仍舊是每個(gè)業(yè)務(wù)一個(gè)團(tuán)隊(duì)的“作坊”模式。每年的人力維護(hù)成本十分巨大,且效率較低。隨著中國(guó)聯(lián)通承載的實(shí)際業(yè)務(wù)越來(lái)越多,不同業(yè)務(wù)應(yīng)用團(tuán)隊(duì)之間主機(jī)資源不平衡程度加劇,擴(kuò)/縮容能力較低,嚴(yán)重影響了生產(chǎn)環(huán)境的穩(wěn)定性和頑健性,如圖1和圖2所示。目前的各個(gè)業(yè)務(wù)系統(tǒng)運(yùn)營(yíng)存在資源運(yùn)行不均衡、時(shí)段運(yùn)行不均衡等重大問(wèn)題,主要體現(xiàn)在以下幾點(diǎn):

圖1 不同作業(yè)的內(nèi)存分時(shí)段使用率統(tǒng)計(jì)

圖2 不同作業(yè)的CPU分段使用率統(tǒng)計(jì)

?集群分布在多個(gè)機(jī)房,業(yè)務(wù)增長(zhǎng)過(guò)快導(dǎo)致頻繁的數(shù)據(jù)遷移,針對(duì)性的平臺(tái)性能優(yōu)化不足;

??因GP故障、生產(chǎn)性能不足等問(wèn)題,自2015年至今經(jīng)歷多次數(shù)據(jù)遷移,存儲(chǔ)資源不足及必要的數(shù)據(jù)留存周期造成無(wú)法針對(duì)性做進(jìn)一步優(yōu)化;

?HBase庫(kù)在數(shù)據(jù)量增大后,讀的概率下降,查詢效率會(huì)逐步降低,需要持續(xù)優(yōu)化保障,其他業(yè)務(wù)需求增多,與核心生產(chǎn)服務(wù)資源征用情況相比較明顯,直接影響到cBSS原始明細(xì)下發(fā)、對(duì)外實(shí)時(shí)查詢等服務(wù);

??單個(gè)業(yè)務(wù)團(tuán)隊(duì)運(yùn)維人員投入急劇增加,尤其需要增加實(shí)際業(yè)務(wù)自動(dòng)化運(yùn)維監(jiān)控功能,落地自動(dòng)化運(yùn)維監(jiān)控平臺(tái),減少人員運(yùn)維成本;

??如圖1、圖2所示,如果能將不同主機(jī)的主機(jī)資源共享,將大大提高主機(jī)資源的使用率。生產(chǎn)系統(tǒng)中,每一個(gè)計(jì)算集群都部署在專門(mén)的物理機(jī)中,計(jì)算任務(wù)完成后,則會(huì)閑置,而其他的計(jì)算集群也無(wú)法使用該主機(jī)資源。原有的技術(shù)結(jié)構(gòu)存在的問(wèn)題是缺乏純物理機(jī)資源的粗、細(xì)顆粒度的調(diào)度能力。

本文研究填補(bǔ)了中國(guó)聯(lián)通沒(méi)有統(tǒng)一的容器化資源運(yùn)維平臺(tái)的空白,讓實(shí)際業(yè)務(wù)應(yīng)用在無(wú)狀態(tài)化、容器化之后,統(tǒng)一管理業(yè)務(wù)應(yīng)用的生命周期。打通現(xiàn)有運(yùn)維模式,統(tǒng)一運(yùn)維所有的業(yè)務(wù)應(yīng)用資源,使現(xiàn)有的開(kāi)源技術(shù)有機(jī)地和聯(lián)通傳統(tǒng)業(yè)務(wù)相結(jié)合。

3 國(guó)內(nèi)研究現(xiàn)狀

網(wǎng)狀網(wǎng)作為整個(gè)一級(jí)業(yè)務(wù)支撐系統(tǒng)的核心系統(tǒng),是中國(guó)移動(dòng)內(nèi)外部信息傳輸交換、服務(wù)管控、數(shù)據(jù)處理、業(yè)務(wù)支撐、運(yùn)營(yíng)開(kāi)放為一體的綜合信息交換樞紐。目前承載200多個(gè)平臺(tái)的接入,支撐業(yè)務(wù)達(dá)到2 000多個(gè),系統(tǒng)承載業(yè)務(wù)具有容量大、實(shí)時(shí)性強(qiáng)、波動(dòng)劇烈、增長(zhǎng)迅速、重要性強(qiáng)、客戶影響大、無(wú)狀態(tài)業(yè)務(wù)居多等特點(diǎn),非常適合做PaaS平臺(tái)的試點(diǎn)。業(yè)務(wù)支撐中心和網(wǎng)狀網(wǎng)項(xiàng)目技術(shù)團(tuán)隊(duì)經(jīng)過(guò)大量的研討,創(chuàng)新性地提出了應(yīng)用進(jìn)程單元(application process unit,APU)的概念,把資源和應(yīng)用有效地結(jié)合在一起,解決未來(lái)系統(tǒng)發(fā)展和管理的瓶頸。而且通過(guò)深入的技術(shù)研究和實(shí)踐探索,在Docker基礎(chǔ)上通過(guò)增強(qiáng)接口和管理功能,實(shí)現(xiàn)了APU概念的落地。結(jié)合Kunbernetes作為集群管理平臺(tái),搭建了能夠承載網(wǎng)狀網(wǎng)系統(tǒng)的PaaS平臺(tái)試點(diǎn),實(shí)現(xiàn)了整個(gè)平臺(tái)的容器化改造和集群的部署、管理和監(jiān)控。

4 容器運(yùn)維系統(tǒng)的設(shè)計(jì)

4.1 功能架構(gòu)及其設(shè)計(jì)思路

一般地,較設(shè)計(jì)需求來(lái)說(shuō),容器運(yùn)維系統(tǒng)是面向生產(chǎn)系統(tǒng)各應(yīng)用提供大數(shù)據(jù)微服務(wù)化能力管理、調(diào)度和開(kāi)放化運(yùn)營(yíng)的管理框架,并面向不同的業(yè)務(wù)部門(mén)和信息域的需求,實(shí)現(xiàn)多租戶管理的能力開(kāi)放。因此在設(shè)計(jì)容器運(yùn)維系統(tǒng)的功能時(shí),需要綜合考量。核心的必要功能羅列如下。

(1)容器管理

需包括整個(gè)容器的生命周期管理,即容器服務(wù)的部署創(chuàng)建、容器服務(wù)配置的修改管理、容器服務(wù)的銷(xiāo)毀、容器服務(wù)的應(yīng)用監(jiān)控。為適應(yīng)不同的用戶,還應(yīng)具備服務(wù)訪問(wèn)的權(quán)限[1]。如管理員可以訪問(wèn)所有的容器實(shí)例,而單個(gè)用戶只能訪問(wèn)自己創(chuàng)建或者同組之間賦予權(quán)限的容器實(shí)例。各個(gè)分組之間應(yīng)是完全物理隔離或邏輯隔離的[2]。

(2)框架管理

也需包括整個(gè)框架的生命周期管理,即框架服務(wù)的部署與創(chuàng)建、框架服務(wù)配置的修改管理、框架服務(wù)的銷(xiāo)毀、框架服務(wù)的監(jiān)控。需要與容器有所區(qū)分的是,框架相對(duì)容器的生命周期較長(zhǎng),且一般都是相對(duì)復(fù)雜的應(yīng)用,交付方式也不單是網(wǎng)址端口如此簡(jiǎn)單明確。很多業(yè)務(wù)場(chǎng)景下,如Hadoop的能力,其創(chuàng)建不應(yīng)由用戶自行創(chuàng)建,更多的業(yè)務(wù)場(chǎng)景則是用戶來(lái)發(fā)起工單、申請(qǐng)能力、管理員開(kāi)通、交付使用。所以框架的生命周期管理應(yīng)由管理員掌控[3]。

(3)集群管理

相對(duì)地,也需要包括集群的全生命周期管理,如集群的創(chuàng)建、集群節(jié)點(diǎn)數(shù)量等服務(wù)配置的修改管理、集群的銷(xiāo)毀與監(jiān)控[4]。

其次需要包括完整的工單系統(tǒng),包括用戶和管理員這兩個(gè)基本權(quán)限角色,同時(shí)為了管理更有序,還需要對(duì)用戶進(jìn)行分組,實(shí)現(xiàn)組間、組內(nèi)多租戶更細(xì)化地分配資源。作為工單系統(tǒng),角色的注冊(cè)和權(quán)限管理也是必不可少的。另外還需要對(duì)已有的軟件資源(物理機(jī)、框架、鏡像)設(shè)計(jì)相對(duì)應(yīng)的管理功能。

?鏡像倉(cāng)庫(kù):鏡像的添加或刪除。

??框架倉(cāng)庫(kù):框架的添加或刪除。

??物理機(jī)資源:資源納管,將物理機(jī)納入策略設(shè)置[5]。

圖3 容器運(yùn)維系統(tǒng)功能

除了以上的核心功能,還需根據(jù)實(shí)際業(yè)務(wù)情況設(shè)計(jì)針對(duì)性的進(jìn)階功能,如針對(duì)快速迭代的DevOps管理、容器存儲(chǔ)的持久化、一鍵部署所需的應(yīng)用包功能。經(jīng)過(guò)功能梳理后,容器運(yùn)維系統(tǒng)的功能如圖3所示。

4.2 容器運(yùn)維系統(tǒng)的技術(shù)路線

經(jīng)過(guò)前期的技術(shù)選型通過(guò)集成已有的開(kāi)源軟件技術(shù)可以完成以下功能的搭建。

? DCOS:集群生命周期管理、框架倉(cāng)庫(kù)、物理機(jī)資源納管。

? Kubernetes: 容器生命周期管理、租戶管理。

? ? Mesos:資源調(diào)度。

? Marathon:框架生命周期管理。

? Harbor:鏡像庫(kù)管理。

? ? Nginx&Flannel:服務(wù)注冊(cè)、負(fù)載均衡、訪問(wèn)鑒權(quán)。

? ? Helm:應(yīng)用分組管理。

? ? Ceph:容器持久化存儲(chǔ)。

? ? Jenkins:DevOps迭代開(kāi)發(fā)。

? ? Heapster&&EFK:監(jiān)控容器運(yùn)行情況并輸出監(jiān)控日志。

容器資源運(yùn)維系統(tǒng)使用DCOS+Marathon+ Kubernetes 的架構(gòu)模式(如圖4所示),完成集群、框架、容器三大維度生命周期的管理。容器資源運(yùn)維系統(tǒng)從技術(shù)架構(gòu)上分為接入層、服務(wù)層、框架調(diào)度層和前臺(tái)的管理系統(tǒng)[6]。

? 接入層:負(fù)責(zé)服務(wù)發(fā)現(xiàn)和服務(wù)路由,把每個(gè)容器業(yè)務(wù)應(yīng)用串聯(lián)起來(lái)。

? 服務(wù)層:應(yīng)用Helm技術(shù),把每個(gè)用戶自定義的容器配置保存起來(lái)打包,以便二次部署;基于Jenkins技術(shù),在線編譯程序,快速構(gòu)建驗(yàn)證與開(kāi)發(fā)環(huán)境,實(shí)現(xiàn)應(yīng)用的容器化封裝。

? 框架調(diào)度層:應(yīng)用Heapster,實(shí)現(xiàn)容器的健康度實(shí)時(shí)監(jiān)控;EFK完成系統(tǒng)日志層面的搜索、輸出、展示;Kubernetes完成容器的生命周期管理;Marathon完成框架的生命周期管理;Mesos提供這兩個(gè)模塊的資源調(diào)度。

圖4 系統(tǒng)技術(shù)架構(gòu)

圖5 Hadoop集群資源調(diào)度實(shí)例

? 前臺(tái)管理:用Java編寫(xiě)前臺(tái)的客戶端,調(diào)用現(xiàn)有技術(shù)的API,實(shí)現(xiàn)所有技術(shù)的調(diào)用。

5 關(guān)鍵問(wèn)題技術(shù)Mesos

5.1 Mesos的資源調(diào)度改進(jìn)設(shè)計(jì)

容器資源運(yùn)維系統(tǒng)針對(duì)主流的Hadoop系列大數(shù)據(jù)應(yīng)用,采用兩級(jí)調(diào)度策略,由Mesos發(fā)起資源分配,實(shí)際的應(yīng)用框架消費(fèi)資源,合理化使用物理機(jī)資源,如圖5所示,做到資源空閑時(shí),大數(shù)據(jù)應(yīng)用集群搶占系統(tǒng)資源;資源緊張時(shí),大數(shù)據(jù)應(yīng)用自動(dòng)釋放資源,并且不影響實(shí)際業(yè)務(wù)使用。這其中包括改進(jìn)的Mesos資源配置機(jī)制,如圖6所示。

圖6 Mesos資源機(jī)制

? 預(yù)留資源:由特定框架或角色靜態(tài)或動(dòng)態(tài)聲明的資源,包括一些已分配的資源。

? 已分配資源:已提供給框架或由框架接受并作為執(zhí)行程序/任務(wù)提供的資源。

? 可撤銷(xiāo)資源:可以由分配器或代理在任何時(shí)間/短期通知回收的資源以及這些資源上的容器將被銷(xiāo)毀。可撤銷(xiāo)資源可以由分配器和代理使用超額預(yù)訂生成。在代理使用超額預(yù)訂的上下文中,“可撤銷(xiāo)”的含義還包括容器可能經(jīng)歷節(jié)流的東西(例如較低的CPU份額、較少的網(wǎng)絡(luò)優(yōu)先級(jí)等)[7]。

5.2 Mesos的任務(wù)機(jī)制改進(jìn)設(shè)計(jì)

? 正常任務(wù):在不可撤銷(xiāo)資源上運(yùn)行的任務(wù),與AWS保留實(shí)例相同。

? 可撤銷(xiāo)任務(wù):低優(yōu)先級(jí)和易碎的任務(wù),如AWS spot實(shí)例。

? Lender框架:一個(gè)運(yùn)行正常任務(wù)并保留資源的框架,這個(gè)框架可能沒(méi)有充分利用那些保留的資源,這就像目前存在的任何框架。

? Tenant框架:一種運(yùn)行可撤銷(xiāo)任務(wù)并利用Lender框架中的資源的框架的新范例。這種類型的框架可以處理不穩(wěn)定/笨拙的資源和更高的任務(wù)故障率。租戶框架需要具有啟用“REVOCABLE_RESOURCES”的能力。

如圖7、圖8所示,Lender框架決定使用其保留的資源時(shí),使用來(lái)自分配器所提供的資源來(lái)啟動(dòng)任務(wù)。如果任務(wù)不適合當(dāng)前可用的資源,則代理首先通過(guò)殺死正在使用可撤銷(xiāo)的不可節(jié)制的資源的執(zhí)行器來(lái)驅(qū)逐一些任務(wù)[8]。這可以由預(yù)訂超額預(yù)訂和動(dòng)態(tài)預(yù)留之間的交互觸發(fā)。在框架或操作者移除一些保留的資源之后,同時(shí)由“被移除的保留資源”所生成的“可撤銷(xiāo)非節(jié)流資源”正由任務(wù)/執(zhí)行器使用,則可撤銷(xiāo)的不可節(jié)制資源總量也將在代理上減少[9]。

圖7 驅(qū)逐保留資源任務(wù)

圖8 驅(qū)逐正常資源任務(wù)

6 結(jié)果驗(yàn)證

本文以CentOS 7為驗(yàn)證環(huán)境,驗(yàn)證了主機(jī)10.1.24.108、10.1.24.39、10.1.24.137、10.1.24.234這4臺(tái)x86機(jī)架服務(wù)器,集成Docker(1.11)、Hadoop2.7、Kubernetes1.5、Open DCOS 1.05、Mesos 1.0.0等開(kāi)源軟件設(shè)計(jì)實(shí)現(xiàn)容器運(yùn)維系統(tǒng)。

(1)資源調(diào)度驗(yàn)證

由于設(shè)計(jì)方案?jìng)?cè)重大數(shù)據(jù)的資源調(diào)度。為了對(duì)比容器運(yùn)維系統(tǒng)與Open DCOS兩個(gè)調(diào)度大數(shù)據(jù)資源的方法,采用實(shí)際驗(yàn)證法對(duì)兩個(gè)方法進(jìn)行了驗(yàn)證。結(jié)果如下。

首先,驗(yàn)證了兩個(gè)系統(tǒng)對(duì)于Myriad框架對(duì)細(xì)粒度資源的支持。目的是驗(yàn)證Myriad框架對(duì)執(zhí)行任務(wù)時(shí),按照細(xì)粒度模式申請(qǐng)資源,任務(wù)運(yùn)行時(shí)資源的利用情況。

實(shí)際驗(yàn)證結(jié)果如下。

Open DCOS:細(xì)粒度執(zhí)行時(shí)間為165.476 s,固定模塊執(zhí)行時(shí)間為147.648 s。

CU-DCOS容器運(yùn)維系統(tǒng):細(xì)粒度執(zhí)行時(shí)間為164.693 s,固定模塊執(zhí)行時(shí)間為144.976 s。

通過(guò)驗(yàn)證發(fā)現(xiàn),在資源模板配置零的情況下,計(jì)算任務(wù)的時(shí)間比固定資源配置要長(zhǎng)一些,且兩種方法都支持Myriad框架對(duì)細(xì)粒度資源進(jìn)行調(diào)度。

其次,驗(yàn)證了兩個(gè)系統(tǒng)對(duì)于資源預(yù)留功能方面的功能實(shí)現(xiàn)。目的是驗(yàn)證Myriad的基礎(chǔ)資源預(yù)留功能以及在這個(gè)基礎(chǔ)上的附加功能,包括動(dòng)態(tài)資源預(yù)留、資源搶占等。

在Mesos-slave機(jī)器上配置資源選項(xiàng)做配置,為CPU、內(nèi)存、角色等進(jìn)行資源靜態(tài)預(yù)留。在Myriad框架上,調(diào)用容器運(yùn)維系統(tǒng)新增的RESTful接口發(fā)起動(dòng)態(tài)預(yù)留信息,將資源等配置資源到固定機(jī)器上。

實(shí)際驗(yàn)證結(jié)果如下。

圖9 容器運(yùn)維系統(tǒng)資源監(jiān)控

圖10 集群1壓力較大時(shí)容器運(yùn)維系統(tǒng)資源監(jiān)控

Open DCOS和容器運(yùn)維系統(tǒng)均支持動(dòng)態(tài)、靜態(tài)資源預(yù)留,Open DCOS對(duì)資源搶占功能不支持,但容器運(yùn)維系統(tǒng)對(duì)于資源搶占功能支持。集群資源搶占效果如圖9所示,圖9中集群1有2臺(tái)主機(jī),集群2有2臺(tái)主機(jī)。當(dāng)集群1壓力較大時(shí),會(huì)搶占集群2較為空閑的主機(jī)資源參與計(jì)算,如圖10所示。

(2)Mesos運(yùn)行模式驗(yàn)證

驗(yàn)證結(jié)果發(fā)現(xiàn)應(yīng)用框架方便實(shí)用,并且可以根據(jù)需要自行開(kāi)發(fā)。容器化需要對(duì)應(yīng)用進(jìn)行無(wú)狀態(tài)改造工作。改造工作主要針對(duì)以下3個(gè)有狀態(tài)內(nèi)容:會(huì)話方面使用Redis緩存或Memcached;日志使用日志服務(wù)器Graylog;非日志數(shù)據(jù)文件通過(guò)外掛存儲(chǔ)的方式移至持久化存儲(chǔ)。

(3)基于Mesos的未容器化的應(yīng)用解決方案

驗(yàn)證結(jié)果發(fā)現(xiàn)部分業(yè)務(wù)暫時(shí)難以容器化改造的應(yīng)用,特點(diǎn)為:有狀態(tài)、體量大、自身封閉、難以微服務(wù)化,且無(wú)響應(yīng)應(yīng)用框架,如核心應(yīng)用、Oracle等。

基于Kubernetes的大顆粒度Docker容器:使用大顆粒度容器承載整個(gè)應(yīng)用。這樣便于部署和管理,可以提高資源利用率,持續(xù)集成(DevOps),且Docker占用資源極少。

使用Marathon支持的Mesos-容器。Mesos-容器比Docker更輕,只針對(duì)進(jìn)程用CGroup做CPU、內(nèi)存的隔離,不對(duì)文件系統(tǒng)、網(wǎng)絡(luò)等進(jìn)行限制。不需要使用鏡像啟動(dòng),直接運(yùn)行命令行啟動(dòng)該容器。

(4)技術(shù)路線對(duì)比驗(yàn)證

Kubernetes相較于Marathon(見(jiàn)表1)有更好的潛力,在容器化調(diào)度方面,支持證書(shū),支持容器的持久化卷等額外的擴(kuò)展功能,且在多集群和容災(zāi)方面都比Marathon有更好的安全性保證??傮w來(lái)說(shuō),Kubernetes更適合容器的編排和調(diào)度。在Mesos方面需要使用開(kāi)源技術(shù)和自行研發(fā)結(jié)合方式實(shí)現(xiàn),其中對(duì)資源的統(tǒng)一管理和調(diào)度采用開(kāi)源的Mesos來(lái)支撐,但缺乏框架的自動(dòng)安裝部署和門(mén)戶等附加功能,需要在穩(wěn)定的Mesos版本上深度研發(fā)。

7 結(jié)束語(yǔ)

容器運(yùn)維系統(tǒng)旨在通過(guò)新一代的云計(jì)算架構(gòu)——容器技術(shù),解決聯(lián)通面臨的實(shí)際問(wèn)題。在解決問(wèn)題過(guò)程中,依賴于開(kāi)源軟件通過(guò)自主架構(gòu)、自主方案設(shè)計(jì),部分核心能力自主研發(fā);形成了面向生產(chǎn)環(huán)境下的IT系統(tǒng),實(shí)現(xiàn)資源的一體化調(diào)度、大數(shù)據(jù)微服務(wù)化管理能力;完成IT資源的集中管理的新一代的私有云平臺(tái)系統(tǒng)。一方面驗(yàn)證了以容器為基礎(chǔ)的PaaS平臺(tái)從模式、到技術(shù)的可行性,另一方面在行業(yè)內(nèi)首次實(shí)現(xiàn)了面向大數(shù)據(jù)、物理資源彈性調(diào)度、多租戶管理的“資源+數(shù)據(jù)+能力”的平臺(tái)架構(gòu)。

表1 技術(shù)對(duì)比驗(yàn)證

[1] BAIER J. Getting started with Kubernetes[M]. Birmingham: Packt Publishing, 2015.

[2] BERNSTEIN D. Containers and cloud: from LXC to Docker to Kubernetes[J]. IEEE Cloud Computing, 2015, 1(3): 81-84.

[3] HINDMAN B, KONWINSKI A, ZAHARIA M, et al. Mesos: a platform for fine-grained resource sharing in the data center[C]// USENIX Conference on Networked Systems Design & Implementation, April 2-5, 2010, Lombard, IL, USA. New York: ACM Press, 2010: 429-483.

[4] 吳龍輝. Kubernetes第1版實(shí)戰(zhàn)[M].北京: 電子工業(yè)出版社, 2015: 13-211.

WU L H. Kubernetes application 1st ed[M]. Beijing: Electronic Industry Press, 2015: 13-211.

[5] SIERRA K, BATES B. O’Reilly: head first java(中文版)[M]. O’Reilly Taiwan譯. 北京: 中國(guó)電力出版社, 2007.

SIERRA K, BATES B. O’Reilly: head first Java[M]. Translated by O’Reilly Taiwan. Beijing: China Electric Power Press, 2007.

[6] KAKADIA D. Mesos 大數(shù)據(jù)資源調(diào)度與大規(guī)模容器運(yùn)行最佳實(shí)踐[M]. 崔婧雯, 劉夢(mèng)馨, 譯. 北京: 電子工業(yè)出版社, 2015.

KAKADIA D. Applications on Mesos[M]. Translated by CUI J W, LIU M X. Beijing: Electronic Industry Press, 2015.

[7] 曹旭, 曹瑞彤. 基于大數(shù)據(jù)分析的網(wǎng)絡(luò)異常檢測(cè)方法[J]. 電信科學(xué), 2014, 30(6): 152-156.

CAO X, CAO R T. Network anomaly prediction method based on big data [J]. Telecommunications Science, 2014, 30(6): 152-156.

[8] 漆晨曦. 立足小數(shù)據(jù)基礎(chǔ)的電信企業(yè)大數(shù)據(jù)分析應(yīng)用發(fā)展策略[J]. 電信科學(xué), 2014, 30(10): 15-20.

QI C X. Analysis and application development strategy of telecom enterprise big data based on small data [J]. Telecommunications Science, 2014, 30(10): 15-20.

[9] 韓晶, 張智江, 王健全, 等. 面向統(tǒng)一運(yùn)營(yíng)的電信運(yùn)營(yíng)商大數(shù)據(jù)戰(zhàn)略[J]. 電信科學(xué), 2014, 30(11): 154-158.

HAN J, ZHANG Z J, WANG J Q, et al. The unified-operation-oriented big data strategy for telecom operators[J]. Telecommunications Science, 2014, 30(11): 154-158.

Design and implementation of a resource operation and maintenance system based on container arrangement technology

ZHANG Xun, ZHANG Chengyu, WEI Jinwu

Big Data Center of China Unicom Research Institute, Beijing 100176, China

Kubernetes container layout tools, Docker operation technology and Mesos framework choreography technology selection were used to solve China Unicom’s existing problems of business application container’s unbalance of resource scheduling. The problem of existing physical cluster elastic scalability capacity was solved. Through cluster and the technique of Mesos, the original big data deploy faster and the scalability problems were solved. Finally, container operation and management system was realized.

resource operation system, container scheduling, elastic scalability capacity

TN923

A

10.11959/j.issn.1000?0801.2018110

張勛(1990?),男,中國(guó)聯(lián)合網(wǎng)絡(luò)通信有限公司研究院大數(shù)據(jù)研究中心軟件開(kāi)發(fā)工程師,主要研究方向?yàn)殚_(kāi)源技術(shù)、容器技術(shù)等。

張呈宇(1988?),男,中國(guó)聯(lián)合網(wǎng)絡(luò)通信有限公司研究院大數(shù)據(jù)實(shí)驗(yàn)室大數(shù)據(jù)平臺(tái)技術(shù)研發(fā)組組長(zhǎng),主要從事大數(shù)據(jù)、云計(jì)算IaaS、容器技術(shù)等的研發(fā)工作。

魏進(jìn)武(1978?),男,博士,現(xiàn)就職于中國(guó)聯(lián)合網(wǎng)絡(luò)通信有限公司研究院大數(shù)據(jù)研究中心,主要負(fù)責(zé)大數(shù)據(jù)架構(gòu)設(shè)計(jì)、規(guī)劃、實(shí)施方案,統(tǒng)一云化研究等的研究工作。

2017?10?20;

2018?02?09

猜你喜歡
容器集群運(yùn)維
Different Containers不同的容器
難以置信的事情
海上小型無(wú)人機(jī)集群的反制裝備需求與應(yīng)對(duì)之策研究
運(yùn)維技術(shù)研發(fā)決策中ITSS運(yùn)維成熟度模型應(yīng)用初探
風(fēng)電運(yùn)維困局
能源(2018年8期)2018-09-21 07:57:24
一種無(wú)人機(jī)集群發(fā)射回收裝置的控制系統(tǒng)設(shè)計(jì)
電子制作(2018年11期)2018-08-04 03:25:40
雜亂無(wú)章的光伏運(yùn)維 百億市場(chǎng)如何成長(zhǎng)
能源(2017年11期)2017-12-13 08:12:25
Python與Spark集群在收費(fèi)數(shù)據(jù)分析中的應(yīng)用
勤快又呆萌的集群機(jī)器人
基于ITIL的運(yùn)維管理創(chuàng)新實(shí)踐淺析
和顺县| 纳雍县| 旬邑县| 河津市| 曲松县| 建瓯市| 泗洪县| 安顺市| 黄山市| 雅安市| 灵寿县| 通许县| 曲靖市| 平陆县| 界首市| 巫溪县| 甘谷县| 银川市| 玛多县| 大荔县| 华池县| 安国市| 红桥区| 陵水| 安塞县| 深圳市| 济阳县| 东乡县| 福建省| 嘉祥县| 府谷县| 龙岩市| 祁连县| 铜鼓县| 涪陵区| 美姑县| 双辽市| 望城县| 永兴县| 郓城县| 台安县|