DC/OS關(guān)鍵技術(shù)與應(yīng)用場景

張基恒，李大中，張呈宇，魏進(jìn)武

（1.中國聯(lián)合網(wǎng)絡(luò)通信有限公司研究院，北京 100032；2.中國聯(lián)合網(wǎng)絡(luò)通信有限公司信息化事業(yè)部，北京 100032）

DC/OS關(guān)鍵技術(shù)與應(yīng)用場景

張基恒1，李大中2，張呈宇1，魏進(jìn)武1

（1.中國聯(lián)合網(wǎng)絡(luò)通信有限公司研究院，北京 100032；2.中國聯(lián)合網(wǎng)絡(luò)通信有限公司信息化事業(yè)部，北京 100032）

首先對數(shù)據(jù)中心操作系統(tǒng)內(nèi)的主要技術(shù)，包括Mesos、Yarn、Kubernetes和容器進(jìn)行了闡述。根據(jù)國內(nèi)外電信運(yùn)營商的現(xiàn)狀和面臨的問題，提出了一種解決方案，并對技術(shù)實(shí)現(xiàn)及選型建議進(jìn)行了討論。最后對電信運(yùn)營商應(yīng)用DC/OS關(guān)鍵技術(shù)的案例進(jìn)行了簡要介紹。

數(shù)據(jù)中心操作系統(tǒng)；資源調(diào)度；開源

1 引言

隨著越來越多的平臺(tái)、架構(gòu)、系統(tǒng)、組件和工具等通過開源社區(qū)、小微型初創(chuàng)項(xiàng)目而衍生，不再由IT或互聯(lián)網(wǎng)巨頭獨(dú)自壟斷，這為IT領(lǐng)域各項(xiàng)技術(shù)的快速、活躍發(fā)展提供了良好的溫床，開源技術(shù)的迅速發(fā)展、活躍的社區(qū)力量，使得一些理念如DC/OS（數(shù)據(jù)中心操作系統(tǒng)）以及技術(shù)如Mesos、Kubernetes和容器等應(yīng)運(yùn)而生，并廣泛地得到了實(shí)驗(yàn)和迭代改進(jìn)。

2 DC/OS關(guān)鍵技術(shù)

DC/OS問世之前，如谷歌（Google）等互聯(lián)網(wǎng)企業(yè)就內(nèi)部資源調(diào)度和分配、負(fù)載，已逐步展開了探索，形成了一些如Borg等的生產(chǎn)化項(xiàng)目。而在2014年，由Mesosphere實(shí)現(xiàn)了第一個(gè)可進(jìn)行統(tǒng)一調(diào)度所有數(shù)據(jù)中心及云資源的軟件堆棧，并稱為DC/OS。目前已投入實(shí)際生產(chǎn)使用的DC/ OS包括Google的Borg/Omega系統(tǒng)和推特（Twitter）、蘋果（Apple）、網(wǎng)飛（Netflix）等公司基于Mesos構(gòu)建的系統(tǒng)。而在2016年4月，Mesosphere將自己的DC/OS代碼進(jìn)行了開源，其中包含超過30項(xiàng)組件技術(shù)，最為典型的有Apache Mesos與Marathon。下文將對可用于DC/OS構(gòu)建的開源技術(shù)包括Mesos、Yarn、Kubernetes和Docker進(jìn)行簡要闡述。

2.1 Mesos

Mesos是開源資源統(tǒng)一管理和調(diào)度平臺(tái)，其實(shí)現(xiàn)邏輯如圖1所示，由美國加州大學(xué)伯克利分校AMPLab開發(fā)，后應(yīng)用于Twitter、Apple、Netflix等企業(yè)。其亮點(diǎn)在于兩層調(diào)度的架構(gòu)可以做到“大集群”、減小“中心節(jié)點(diǎn)”的壓力以及在同一個(gè)集群中可接入多種應(yīng)用、框架，提高分布式集群的利用率。

由于Mesos上的元數(shù)據(jù)可通過各個(gè)計(jì)算節(jié)點(diǎn)重新注冊而進(jìn)行重構(gòu)，因此可通過Zookeeper解決單點(diǎn)故障問題。輕量級的Mesos架構(gòu)包括以下4個(gè)組件。

（1）Mesos管理節(jié)點(diǎn)

系統(tǒng)的核心，負(fù)責(zé)管理接入Mesos的各個(gè)框架和計(jì)算節(jié)點(diǎn)，并將計(jì)算節(jié)點(diǎn)上的資源按某種策略（默認(rèn)使用DRF（dominant resource fairness，主導(dǎo)資源公平）算法）分配給不同的框架。

（2）Mesos計(jì)算節(jié)點(diǎn)

接收并執(zhí)行來自管理節(jié)點(diǎn)的命令、管理節(jié)點(diǎn)上的任務(wù)并為各個(gè)任務(wù)分配資源。

（3）框架

計(jì)算框架，以注冊的方式接入Mesos以便其進(jìn)行統(tǒng)一管理和資源分配。

（4）執(zhí)行器

主要用于啟動(dòng)內(nèi)部任務(wù)。

2.2 Yarn

Yarn是新的Hadoop MapReduce框架，實(shí)現(xiàn)思路如圖2所示。其主要為了解決Hadoop1.0擴(kuò)展性較差、不支持多計(jì)算框架的問題，本質(zhì)是一個(gè)資源管理架構(gòu)。Yarn減小了JobTracker的資源消耗，并且讓監(jiān)測每一個(gè)工作子任務(wù)狀態(tài)的程序更安全、更分布式化；對于資源的表示以內(nèi)存為單位，較舊版本更合理。其亮點(diǎn)在于可以更快地進(jìn)行MapReduce計(jì)算，實(shí)現(xiàn)對多架構(gòu)的支持以及架構(gòu)升級的簡便性。

較1代MapReduce的設(shè)計(jì)思路，Yarn將JobTracker兩個(gè)主要的功能，即資源管理和任務(wù)調(diào)度/監(jiān)控，分解為獨(dú)立組件資源管理器和應(yīng)用管理節(jié)點(diǎn)。資源管理器全局管理所有應(yīng)用程序計(jì)算資源的分配，每一個(gè)應(yīng)用的應(yīng)用管理節(jié)點(diǎn)負(fù)責(zé)相應(yīng)的調(diào)度和協(xié)調(diào)。

2.3 Kubernetes

Kubernetes是Google多年大規(guī)模容器管理技術(shù)的開源版本，其實(shí)現(xiàn)思路如圖3所示。其亮點(diǎn)在于具有容器編排能力、相對輕量級及易于管理運(yùn)行Docker的容器。Kubernetes使用Docker對程序進(jìn)行包裝、實(shí)例化、運(yùn)行，并以集群的方式運(yùn)行、管理跨機(jī)器的容器，同時(shí)解決了Docker跨機(jī)器容器之間的通信問題。

Kubernetes框架包含以下組件。

圖1 Mesos實(shí)現(xiàn)思路

圖2 Yarn實(shí)現(xiàn)思路

圖3 Kubernetes實(shí)現(xiàn)思路

·Kubernetes管理節(jié)點(diǎn)：管理整個(gè)系統(tǒng)。

·Kubernetes API服務(wù)器:系統(tǒng)入口，封裝了核心對象的操作。

·Kubernetes調(diào)度器：負(fù)責(zé)集群資源調(diào)度，為新建的Pod分配機(jī)器。

·Kubernete節(jié)點(diǎn)：運(yùn)行節(jié)點(diǎn)，用于運(yùn)行管理業(yè)務(wù)的容器。

·Kuberlet：負(fù)責(zé)管控容器，從服務(wù)器接收命令。

·Kubernetes代理：負(fù)責(zé)為Pod創(chuàng)建代理服務(wù)。

·Docker：Kubernetes節(jié)點(diǎn)是容器運(yùn)行節(jié)點(diǎn)，需要運(yùn)行Docker服務(wù)。

首先，Kubecfg將請求如創(chuàng)建Pod等，發(fā)送給Kubernetes應(yīng)用客戶端，并由其將該請求發(fā)送給API服務(wù)器。API服務(wù)器根據(jù)請求類型（如創(chuàng)建Pod時(shí)存儲(chǔ)類型是pods）并依此選擇何種REST存儲(chǔ)API對請求作出處理。REST存儲(chǔ)API對請求做相應(yīng)的處理，并將處理結(jié)果存入高可用鍵值存儲(chǔ)系統(tǒng)（ETCD）中，在API服務(wù)器響應(yīng)Kubecfg的請求后，調(diào)度器會(huì)根據(jù)Kubernetes應(yīng)用客戶端獲取集群中運(yùn)行的Pod及從屬節(jié)點(diǎn)的信息。依據(jù)從Kubernetes應(yīng)用客戶端獲取的信息，調(diào)度器將未分發(fā)的Pod分發(fā)到可用的從屬節(jié)點(diǎn)上。

2.4 Docker

Docker是一個(gè)開源的應(yīng)用容器引擎，為開發(fā)者提供一個(gè)可將應(yīng)用及依賴包打包至一個(gè)可移植的容器環(huán)境中，并發(fā)布到任意流行的 Linux機(jī)器上。容器采用沙箱機(jī)制，容器間不存在接口。其亮點(diǎn)在于快速便捷的單次構(gòu)建+導(dǎo)出運(yùn)行模式及愈加豐富的生態(tài)系統(tǒng)。

Docker采用C/S模式，使用遠(yuǎn)程API來管理和創(chuàng)建Docker容器。Docker容器通過Docker鏡像來創(chuàng)建。容器與鏡像的關(guān)系類似于面向?qū)ο缶幊讨械膶ο笈c類。Docker采用C/S架構(gòu)Docker Daemon作為服務(wù)端接受來自客戶的請求，并處理這些請求（創(chuàng)建、運(yùn)行、分發(fā)容器）。客戶端和服務(wù)端既可以運(yùn)行在一個(gè)機(jī)器上，也可通過Socket或者RESTful API來進(jìn)行通信。Docker Daemon一般在宿主主機(jī)后臺(tái)運(yùn)行，等待接收來自客戶端的消息。Docker客戶端則為用戶提供一系列可執(zhí)行命令，用戶用這些命令實(shí)現(xiàn)跟Docker Daemon交互。

3 電信運(yùn)營商DC/OS實(shí)現(xiàn)思路

3.1 現(xiàn)狀與問題

云計(jì)算、大數(shù)據(jù)相關(guān)技術(shù)的普及推進(jìn)了企業(yè)云化的建設(shè)和發(fā)展。雖然大部分國內(nèi)外電信運(yùn)營商已實(shí)現(xiàn)了IaaS資源池化和部分PaaS及應(yīng)用資源池化，能夠滿足生產(chǎn)供給和部署。但大部分運(yùn)營商的數(shù)據(jù)中心采用分隔式集群實(shí)現(xiàn)思路，包括以開源Yarn或定制版大數(shù)據(jù)資源調(diào)度，承載數(shù)據(jù)類作業(yè)的集群以及數(shù)據(jù)庫、緩存集群等；缺乏迫切資源的跨域調(diào)度能力；同時(shí)目前的運(yùn)營系統(tǒng)還存在的資源運(yùn)行不均衡、時(shí)段運(yùn)行不均衡等問題，具體包括：

·應(yīng)用難以實(shí)現(xiàn)靈活、快速地部署，應(yīng)用系統(tǒng)的開發(fā)過程從開發(fā)到生產(chǎn)有不同的部署環(huán)境，對應(yīng)的實(shí)現(xiàn)代碼也面臨著不同環(huán)境的開發(fā)和部署；

·系統(tǒng)彈性伸縮能力不足，擴(kuò)縮容需經(jīng)過較多環(huán)節(jié)，無法實(shí)現(xiàn)快速、自動(dòng)的伸縮，同時(shí)會(huì)造成資源的浪費(fèi)；

·現(xiàn)有資源利用率在15%左右，無法充分實(shí)現(xiàn)資源的有效利用；

·應(yīng)用系統(tǒng)仍舊面臨“煙囪式”的建設(shè)等現(xiàn)實(shí)問題，應(yīng)用與平臺(tái)緊耦合，高可用、有效監(jiān)控、智能運(yùn)維難以標(biāo)準(zhǔn)化。

鑒于此，電信運(yùn)營商需設(shè)計(jì)、研發(fā)一種架構(gòu)，以解決資源調(diào)度等現(xiàn)實(shí)問題并提供微服務(wù)化的實(shí)現(xiàn)環(huán)境。

3.2 功能結(jié)構(gòu)

一種可滿足電信運(yùn)營商需求的DC/OS的功能實(shí)現(xiàn)如圖4所示，分為4部分內(nèi)容，分別是業(yè)務(wù)調(diào)度層、應(yīng)用服務(wù)層、資源管理層以及自動(dòng)化運(yùn)營工具。

業(yè)務(wù)調(diào)度層的主要功能包括集群管理、服務(wù)接入、服務(wù)命名、服務(wù)發(fā)現(xiàn)、服務(wù)目錄管理、負(fù)載均衡、服務(wù)訪問控制等。

應(yīng)用服務(wù)層主要負(fù)責(zé)容器集群的管理和大數(shù)據(jù)集群的管理。

資源管理層的主要功能包括底層計(jì)算資源的管理以及對其上注冊的任務(wù)的管理。

自動(dòng)化運(yùn)營工具包括監(jiān)控和多租戶管理兩大功能，其中監(jiān)控又細(xì)分為對資源、服務(wù)、容器、集群的監(jiān)控。

3.3 技術(shù)實(shí)現(xiàn)框架

為實(shí)現(xiàn)如圖4所示的功能架構(gòu)，需要引入資源調(diào)度技術(shù)、容器技術(shù)等，在技術(shù)路線選擇上，則以社區(qū)領(lǐng)域的開源技術(shù)為基礎(chǔ)形成自有版本，并兼顧開源社區(qū)本身的發(fā)展。一種較為適合運(yùn)營商的DC/OS技術(shù)架構(gòu)如圖5所示。

圖4 總體功能架構(gòu)

3.3.1 Mesos版本選型

開源DC/OS和商用DC/OS對比見表1。

選型建議：可使用開源技術(shù)和自行研發(fā)結(jié)合方式實(shí)現(xiàn)，其中對資源的統(tǒng)一管理和調(diào)度采用開源的Mesos或者開源的DC/OS來支撐，從對比來看開源DC/OS與 ApahceMesos核心模塊功能一致，開源DC/OS增加了如框架的自動(dòng)安裝部署和門戶等附加功能。

3.3.2 Kubernetes和Marathon框架整合

Kubernetes和Marathon對比見表2。

選型建議：Kubernetes和Marathon各有優(yōu)點(diǎn)，且各自都有固定的生態(tài)圈，因此目前階段無法選定對容器的編排和調(diào)度管理采用拿一個(gè)開源工具，因此在DC/OS平臺(tái)需要長期跟蹤和集成兩個(gè)容器編排工具。

圖5 DC/OS技術(shù)實(shí)現(xiàn)框架

表1 開源DC/OS和商用DC/OS對比

表2 Kubernetes和Marathon對比

3.3.3 對大數(shù)據(jù)服務(wù)框架的集成和封裝

通過Myriad實(shí)現(xiàn)大數(shù)據(jù)服務(wù)框架的集成。

4 電信運(yùn)營商DC/OS案例分析

與DC/OS相關(guān)的Mesos、容器等技術(shù)在電信運(yùn)營商領(lǐng)域獲得了廣泛的探索、研發(fā)與實(shí)踐。

4.1 浙江移動(dòng)DC/OS實(shí)現(xiàn)“雙11”1折充值秒殺

中國移動(dòng)以開源技術(shù)Mesos、Marathon、Docker、HA代理為引擎，在其上完成了自有數(shù)據(jù)中心操作系統(tǒng)DC/OS平臺(tái)的設(shè)計(jì)、測試驗(yàn)證，平臺(tái)采用93個(gè)主機(jī)節(jié)點(diǎn)，其中平臺(tái)部分由5個(gè)節(jié)點(diǎn)構(gòu)成Mesos管理節(jié)點(diǎn)集群，8個(gè)節(jié)點(diǎn)構(gòu)成HA代理集群，計(jì)算節(jié)點(diǎn)由80個(gè)Mesos計(jì)算節(jié)點(diǎn)組成。為驗(yàn)證其對業(yè)務(wù)的承載能力，中國移動(dòng)選取浙江移動(dòng)手機(jī)營業(yè)廳作為試點(diǎn)，將其手機(jī)營業(yè)廳系統(tǒng)遷移到DC/OS平臺(tái)上，用于重點(diǎn)解決秒殺場景。并在2015年11月11日，推出手機(jī)營業(yè)廳充值1折秒殺的活動(dòng)，借以實(shí)驗(yàn)和測試平臺(tái)對其業(yè)務(wù)的支撐。在當(dāng)晚8點(diǎn)，DC/OS平臺(tái)充分展現(xiàn)了其在應(yīng)對業(yè)務(wù)高峰時(shí)的能力優(yōu)勢，順利通過“雙11”考驗(yàn)。

數(shù)據(jù)顯示，“雙11”活動(dòng)期間，浙江移動(dòng)手機(jī)營業(yè)廳系統(tǒng)承受的并發(fā)數(shù)峰值接近6萬次/s，后臺(tái)服務(wù)調(diào)用成功率均在99.95%以上，成為浙江移動(dòng)首個(gè)在單日實(shí)現(xiàn)10億級PV的業(yè)務(wù)系統(tǒng)，其平臺(tái)CPU利用率從資源池的10%提高到40%～50%。

隨后，中國移動(dòng)陸續(xù)將CRM核心業(yè)務(wù)逐步遷移，在2016年4月底DC/OS已成功承載其16套應(yīng)用系統(tǒng)，涵蓋CRM營業(yè)廳、手機(jī)營業(yè)廳等多套核心系統(tǒng)。

4.2 Verizon的DC/OS支撐自有系統(tǒng)和應(yīng)用

Verizon公司作為國際電信運(yùn)營商巨頭之一，不僅重視電信運(yùn)營商基礎(chǔ)業(yè)務(wù)如語音及數(shù)據(jù)服務(wù)，同時(shí)也提供面向用戶的應(yīng)用托管業(yè)務(wù)以及Verizon內(nèi)部服務(wù)如云服務(wù)、用戶托管應(yīng)用等。而這些年OTT的興起，令傳統(tǒng)通信業(yè)務(wù)逐漸減少，也令Verizon公司對其他非電信業(yè)務(wù)更加重視。但其傳統(tǒng)的電信業(yè)數(shù)據(jù)中心架構(gòu)仍是集群化的、計(jì)算資源孤島式的，無法實(shí)現(xiàn)應(yīng)用的自動(dòng)化部署、擴(kuò)縮容，因此需要一種較有限的集群管理工具，并可以實(shí)現(xiàn)隔離、灰度升級、打包、資源彈性分配等能力。

鑒于此，在2013年，Verizon為改變計(jì)算和存儲(chǔ)資源的低利用率和隨之而來的運(yùn)營低效率問題，開始選擇Docker容器技術(shù)以及用來管理Docker容器及服務(wù)器集群的Mesos技術(shù)重構(gòu)其基礎(chǔ)設(shè)施架構(gòu)，以支撐Verizon網(wǎng)絡(luò)上數(shù)以萬計(jì)的工作任務(wù)。2014年底，Verizon建立了一種以Linux為核心，由遍布數(shù)據(jù)中心的普通服務(wù)器構(gòu)成的集群。在應(yīng)用了新技術(shù)后，在硬件資源和應(yīng)用部署兩方面均有有效的提升。具體如圖6所示。

（1）硬件資源

·資源利用率提升：其數(shù)據(jù)中心的資源利用率由最初的10%～20%提高到50%以上。

·提升集群使用有效性：參考集群的歷史數(shù)據(jù)，哪些應(yīng)用上云或者從云上下線了，從而將硬件采購做得更合理。

圖6 Verizon傳統(tǒng)/容器化數(shù)據(jù)中心效率

·減少硬件資源規(guī)劃計(jì)劃：閑置的集群資源可提供給新業(yè)務(wù)，因此無需為新業(yè)務(wù)規(guī)劃預(yù)期規(guī)模所使用的資源；進(jìn)一步可根據(jù)所有應(yīng)用的運(yùn)營情況來增加硬件投入，按季度擴(kuò)展集群規(guī)模。這種方法還可以使計(jì)劃更具體和有效。

（2）時(shí)間成本

·應(yīng)用快速部署：支持在 72 s內(nèi)部署 50 000個(gè)Docker容器，應(yīng)用集群部署與過往相比提高了一個(gè)數(shù)量級。

·開發(fā)成本降低：無需關(guān)注機(jī)柜和硬件環(huán)境，應(yīng)用實(shí)現(xiàn)短平快的開發(fā)。

Verizon計(jì)劃在其Mesos集群上運(yùn)行一些服務(wù)，第一批將被遷移到Mesos集群上的服務(wù)包括無線網(wǎng)絡(luò)支撐系統(tǒng)和一些移動(dòng)應(yīng)用的后臺(tái)以及FiOS網(wǎng)絡(luò)支撐系統(tǒng) （光纖到戶）。Verizon還計(jì)劃將其Hadoop和Spark分析任務(wù)從它們的專屬集群上遷移到Mesos集群。其最終目標(biāo)是希望該集群可達(dá)到如互聯(lián)網(wǎng)巨頭般的由廉價(jià)、單一的硬件設(shè)備組成的數(shù)據(jù)中心。

5 結(jié)束語

未來電信行業(yè)將會(huì)是一個(gè)IT、CT融合，電信運(yùn)營商互聯(lián)網(wǎng)化的趨勢，IT所占比重會(huì)越來越大，電信行業(yè)的盈利模式也會(huì)從傳統(tǒng)的提供通道到提供IT資源、提供服務(wù)的方向轉(zhuǎn)變。近幾年隨著大數(shù)據(jù)、云計(jì)算、容器化、微服務(wù)、平臺(tái)戰(zhàn)略等新技術(shù)和新概念的層出不窮和快速發(fā)展，在業(yè)務(wù)支撐、架構(gòu)能力、平臺(tái)擴(kuò)展性等方面對舊有的煙囪式建設(shè)的業(yè)務(wù)支撐系統(tǒng)提出了巨大的挑戰(zhàn)。因此對現(xiàn)有業(yè)務(wù)和設(shè)備進(jìn)行容器化改造，對數(shù)據(jù)中心乃至全網(wǎng)IT系統(tǒng)進(jìn)行DC/OS改造，則成了一個(gè)必然的選擇。

目前，DC/OS相關(guān)技術(shù)已在部分運(yùn)營商有成功使用的案例，證明相關(guān)技術(shù)在運(yùn)營商的業(yè)務(wù)和網(wǎng)絡(luò)中具有不可忽視的作用，同時(shí)運(yùn)營商也需從自身定位和轉(zhuǎn)型戰(zhàn)略的視角來看待DC/OS的發(fā)展，并選擇自身合適的業(yè)務(wù)分步進(jìn)行改造和遷移。

[1]HINDMAN B,KONWINSKI A,ZAHARIA M,et al.Mesos: aplatform for fine-grained resource sharing in the data center[C]// The 8th USENIX Conference on Networked Systems Design and Implementation,March 30-April 1,2011,Boston,MA,USA. New York:ACM Press,2011:429-483.

[2]VAVILAPALLI V K,MURTHY A C,DOUGLAS C,et al. Apache Hadoop YARN:yet another resource negotiator[C]// Symposium on Cloud Computing,May 27-June 1,2013,Valencia, Spain.New York:ACM Press,2013:1-16.

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

[4]MERKEL D.Docker:lightweight Linux containers for consistent development and deployment[J].Linux Journal,2014(239).

[5]程夢瑤.王璞:定義下一代DCOS[J].軟件和集成電路,2016(4): 84-86. CHENG M Y.WANG P:define the next-generation DCOS[J]. Software and Integrated Circuit,2016(4):84-86.

[6]張基恒,魏進(jìn)武.電信運(yùn)營商私有云適應(yīng)性分析 [J].移動(dòng)通信,2015(13):5-11. ZHANG J H,WEI J W.Analysis on private cloud adaptability for telecom operators[J].Mobile Communications,2015(13): 5-11.

張基恒（1990-），女，中國聯(lián)合網(wǎng)絡(luò)通信有限公司研究院工程師，主要從事大數(shù)據(jù)、IT架構(gòu)方面的研究工作。

李大中（1976-），男，中國聯(lián)合網(wǎng)絡(luò)通信有限公司信息化事業(yè)部工程師，主要從事大數(shù)據(jù)架構(gòu)規(guī)劃、數(shù)據(jù)安全訪問控制、大數(shù)據(jù)能力開放的設(shè)計(jì)和研究工作。

張呈宇（1988-），男，中國聯(lián)合網(wǎng)絡(luò)通信有限公司研究院工程師，主要從事虛擬化技術(shù)、云計(jì)算IaaS、容器技術(shù)、數(shù)據(jù)中心操作系統(tǒng)方面的研究工作。

魏進(jìn)武（1978-），男，博士，中國聯(lián)合網(wǎng)絡(luò)通信有限公司研究院軟件與系統(tǒng)實(shí)驗(yàn)室主任、副教授，負(fù)責(zé)和參與了國家“863”計(jì)劃重大項(xiàng)目5項(xiàng)、國家科技重大專項(xiàng)課題2項(xiàng)，負(fù)責(zé)中國聯(lián)通研發(fā)項(xiàng)目50余項(xiàng)，主要從事大數(shù)據(jù)、云計(jì)算以及電信IT系統(tǒng)等的設(shè)計(jì)及研發(fā)工作。

Key technologies and application scenario of DC/OS

ZHANG Jiheng1,LI Dazhong2,ZHANG Chengyu1,WEI Jinwu1
1.China Unicom Research Institute,Beijing 100032,China 2.China Unicom Group Information Division,Beijing 100032,China

Firstly,critical technologies in data center operating system (DC/OS),including Mesos,Yarn, Kubernetes and Docker were presented.Based on the current situations and problems that both domestic and foreign telecom operators faced,a simple resolution was proposed and technical realization as well as the selection of techniques were discussed.At last,several cases of DC/OS application for telecom operator were introduced.

DC/OS,resource allocation,open source

TP316

A

10.11959/j.issn.1000-0801.2016313

2016-11-02；

2016-12-12