張基恒,李大中,張呈宇,魏進武
(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,魏進武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èi)外電信運營商的現(xiàn)狀和面臨的問題,提出了一種解決方案,并對技術(shù)實現(xiàn)及選型建議進行了討論。最后對電信運營商應(yīng)用DC/OS關(guān)鍵技術(shù)的案例進行了簡要介紹。
數(shù)據(jù)中心操作系統(tǒng);資源調(diào)度;開源
隨著越來越多的平臺、架構(gòu)、系統(tǒng)、組件和工具等通過開源社區(qū)、小微型初創(chuàng)項目而衍生,不再由IT或互聯(lián)網(wǎng)巨頭獨自壟斷,這為IT領(lǐng)域各項技術(shù)的快速、活躍發(fā)展提供了良好的溫床,開源技術(shù)的迅速發(fā)展、活躍的社區(qū)力量,使得一些理念如DC/OS(數(shù)據(jù)中心操作系統(tǒng))以及技術(shù)如Mesos、Kubernetes和容器等應(yīng)運而生,并廣泛地得到了實驗和迭代改進。
DC/OS問世之前,如谷歌(Google)等互聯(lián)網(wǎng)企業(yè)就內(nèi)部資源調(diào)度和分配、負載,已逐步展開了探索,形成了一些如Borg等的生產(chǎn)化項目。而在2014年,由Mesosphere實現(xiàn)了第一個可進行統(tǒng)一調(diào)度所有數(shù)據(jù)中心及云資源的軟件堆棧,并稱為DC/OS。目前已投入實際生產(chǎn)使用的DC/ OS包括Google的Borg/Omega系統(tǒng)和推特(Twitter)、蘋果(Apple)、網(wǎng)飛(Netflix)等公司基于Mesos構(gòu)建的系統(tǒng)。而在2016年4月,Mesosphere將自己的DC/OS代碼進行了開源,其中包含超過30項組件技術(shù),最為典型的有Apache Mesos與Marathon。下文將對可用于DC/OS構(gòu)建的開源技術(shù)包括Mesos、Yarn、Kubernetes和Docker進行簡要闡述。
2.1 Mesos
Mesos是開源資源統(tǒng)一管理和調(diào)度平臺,其實現(xiàn)邏輯如圖1所示,由美國加州大學伯克利分校AMPLab開發(fā),后應(yīng)用于Twitter、Apple、Netflix等企業(yè)。其亮點在于兩層調(diào)度的架構(gòu)可以做到“大集群”、減小“中心節(jié)點”的壓力以及在同一個集群中可接入多種應(yīng)用、框架,提高分布式集群的利用率。
由于Mesos上的元數(shù)據(jù)可通過各個計算節(jié)點重新注冊而進行重構(gòu),因此可通過Zookeeper解決單點故障問題。輕量級的Mesos架構(gòu)包括以下4個組件。
(1)Mesos管理節(jié)點
系統(tǒng)的核心,負責管理接入Mesos的各個框架和計算節(jié)點,并將計算節(jié)點上的資源按某種策略(默認使用DRF(dominant resource fairness,主導(dǎo)資源公平)算法)分配給不同的框架。
(2)Mesos計算節(jié)點
接收并執(zhí)行來自管理節(jié)點的命令、管理節(jié)點上的任務(wù)并為各個任務(wù)分配資源。
(3)框架
計算框架,以注冊的方式接入Mesos以便其進行統(tǒng)一管理和資源分配。
(4)執(zhí)行器
主要用于啟動內(nèi)部任務(wù)。
2.2 Yarn
Yarn是新的Hadoop MapReduce框架,實現(xiàn)思路如圖2所示。其主要為了解決Hadoop1.0擴展性較差、不支持多計算框架的問題,本質(zhì)是一個資源管理架構(gòu)。Yarn減小了JobTracker的資源消耗,并且讓監(jiān)測每一個工作子任務(wù)狀態(tài)的程序更安全、更分布式化;對于資源的表示以內(nèi)存為單位,較舊版本更合理。其亮點在于可以更快地進行MapReduce計算,實現(xiàn)對多架構(gòu)的支持以及架構(gòu)升級的簡便性。
較1代MapReduce的設(shè)計思路,Yarn將JobTracker兩個主要的功能,即資源管理和任務(wù)調(diào)度/監(jiān)控,分解為獨立組件資源管理器和應(yīng)用管理節(jié)點。資源管理器全局管理所有應(yīng)用程序計算資源的分配,每一個應(yīng)用的應(yīng)用管理節(jié)點負責相應(yīng)的調(diào)度和協(xié)調(diào)。
2.3 Kubernetes
Kubernetes是Google多年大規(guī)模容器管理技術(shù)的開源版本,其實現(xiàn)思路如圖3所示。其亮點在于具有容器編排能力、相對輕量級及易于管理運行Docker的容器。Kubernetes使用Docker對程序進行包裝、實例化、運行,并以集群的方式運行、管理跨機器的容器,同時解決了Docker跨機器容器之間的通信問題。
Kubernetes框架包含以下組件。
圖1 Mesos實現(xiàn)思路
圖2 Yarn實現(xiàn)思路
圖3 Kubernetes實現(xiàn)思路
·Kubernetes管理節(jié)點:管理整個系統(tǒng)。
·Kubernetes API服務(wù)器:系統(tǒng)入口,封裝了核心對象的操作。
·Kubernetes調(diào)度器:負責集群資源調(diào)度,為新建的Pod分配機器。
·Kubernete節(jié)點:運行節(jié)點,用于運行管理業(yè)務(wù)的容器。
·Kuberlet:負責管控容器,從服務(wù)器接收命令。
·Kubernetes代理:負責為Pod創(chuàng)建代理服務(wù)。
·Docker:Kubernetes節(jié)點是容器運行節(jié)點,需要運行Docker服務(wù)。
首先,Kubecfg將請求如創(chuàng)建Pod等,發(fā)送給Kubernetes應(yīng)用客戶端,并由其將該請求發(fā)送給API服務(wù)器。API服務(wù)器根據(jù)請求類型(如創(chuàng)建Pod時存儲類型是pods)并依此選擇何種REST存儲API對請求作出處理。REST存儲API對請求做相應(yīng)的處理,并將處理結(jié)果存入高可用鍵值存儲系統(tǒng)(ETCD)中,在API服務(wù)器響應(yīng)Kubecfg的請求后,調(diào)度器會根據(jù)Kubernetes應(yīng)用客戶端獲取集群中運行的Pod及從屬節(jié)點的信息。依據(jù)從Kubernetes應(yīng)用客戶端獲取的信息,調(diào)度器將未分發(fā)的Pod分發(fā)到可用的從屬節(jié)點上。
2.4 Docker
Docker是一個開源的應(yīng)用容器引擎,為開發(fā)者提供一個可將應(yīng)用及依賴包打包至一個可移植的容器環(huán)境中,并發(fā)布到任意流行的 Linux機器上。容器采用沙箱機制,容器間不存在接口。其亮點在于快速便捷的單次構(gòu)建+導(dǎo)出運行模式及愈加豐富的生態(tài)系統(tǒng)。
Docker采用C/S模式,使用遠程API來管理和創(chuàng)建Docker容器。Docker容器通過Docker鏡像來創(chuàng)建。容器與鏡像的關(guān)系類似于面向?qū)ο缶幊讨械膶ο笈c類。Docker采用C/S架構(gòu)Docker Daemon作為服務(wù)端接受來自客戶的請求,并處理這些請求(創(chuàng)建、運行、分發(fā)容器)。客戶端和服務(wù)端既可以運行在一個機器上,也可通過Socket或者RESTful API來進行通信。Docker Daemon一般在宿主主機后臺運行,等待接收來自客戶端的消息。Docker客戶端則為用戶提供一系列可執(zhí)行命令,用戶用這些命令實現(xiàn)跟Docker Daemon交互。
3.1 現(xiàn)狀與問題
云計算、大數(shù)據(jù)相關(guān)技術(shù)的普及推進了企業(yè)云化的建設(shè)和發(fā)展。雖然大部分國內(nèi)外電信運營商已實現(xiàn)了IaaS資源池化和部分PaaS及應(yīng)用資源池化,能夠滿足生產(chǎn)供給和部署。但大部分運營商的數(shù)據(jù)中心采用分隔式集群實現(xiàn)思路,包括以開源Yarn或定制版大數(shù)據(jù)資源調(diào)度,承載數(shù)據(jù)類作業(yè)的集群以及數(shù)據(jù)庫、緩存集群等;缺乏迫切資源的跨域調(diào)度能力;同時目前的運營系統(tǒng)還存在的資源運行不均衡、時段運行不均衡等問題,具體包括:
·應(yīng)用難以實現(xiàn)靈活、快速地部署,應(yīng)用系統(tǒng)的開發(fā)過程從開發(fā)到生產(chǎn)有不同的部署環(huán)境,對應(yīng)的實現(xiàn)代碼也面臨著不同環(huán)境的開發(fā)和部署;
·系統(tǒng)彈性伸縮能力不足,擴縮容需經(jīng)過較多環(huán)節(jié),無法實現(xiàn)快速、自動的伸縮,同時會造成資源的浪費;
·現(xiàn)有資源利用率在15%左右,無法充分實現(xiàn)資源的有效利用;
·應(yīng)用系統(tǒng)仍舊面臨“煙囪式”的建設(shè)等現(xiàn)實問題,應(yīng)用與平臺緊耦合,高可用、有效監(jiān)控、智能運維難以標準化。
鑒于此,電信運營商需設(shè)計、研發(fā)一種架構(gòu),以解決資源調(diào)度等現(xiàn)實問題并提供微服務(wù)化的實現(xiàn)環(huán)境。
3.2 功能結(jié)構(gòu)
一種可滿足電信運營商需求的DC/OS的功能實現(xiàn)如圖4所示,分為4部分內(nèi)容,分別是業(yè)務(wù)調(diào)度層、應(yīng)用服務(wù)層、資源管理層以及自動化運營工具。
業(yè)務(wù)調(diào)度層的主要功能包括集群管理、服務(wù)接入、服務(wù)命名、服務(wù)發(fā)現(xiàn)、服務(wù)目錄管理、負載均衡、服務(wù)訪問控制等。
應(yīng)用服務(wù)層主要負責容器集群的管理和大數(shù)據(jù)集群的管理。
資源管理層的主要功能包括底層計算資源的管理以及對其上注冊的任務(wù)的管理。
自動化運營工具包括監(jiān)控和多租戶管理兩大功能,其中監(jiān)控又細分為對資源、服務(wù)、容器、集群的監(jiān)控。
3.3 技術(shù)實現(xiàn)框架
為實現(xiàn)如圖4所示的功能架構(gòu),需要引入資源調(diào)度技術(shù)、容器技術(shù)等,在技術(shù)路線選擇上,則以社區(qū)領(lǐng)域的開源技術(shù)為基礎(chǔ)形成自有版本,并兼顧開源社區(qū)本身的發(fā)展。一種較為適合運營商的DC/OS技術(shù)架構(gòu)如圖5所示。
圖4 總體功能架構(gòu)
3.3.1 Mesos版本選型
開源DC/OS和商用DC/OS對比見表1。
選型建議:可使用開源技術(shù)和自行研發(fā)結(jié)合方式實現(xiàn),其中對資源的統(tǒng)一管理和調(diào)度采用開源的Mesos或者開源的DC/OS來支撐,從對比來看開源DC/OS與 ApahceMesos核心模塊功能一致,開源DC/OS增加了如框架的自動安裝部署和門戶等附加功能。
3.3.2 Kubernetes和Marathon框架整合
Kubernetes和Marathon對比見表2。
選型建議:Kubernetes和Marathon各有優(yōu)點,且各自都有固定的生態(tài)圈,因此目前階段無法選定對容器的編排和調(diào)度管理采用拿一個開源工具,因此在DC/OS平臺需要長期跟蹤和集成兩個容器編排工具。
圖5 DC/OS技術(shù)實現(xiàn)框架
表1 開源DC/OS和商用DC/OS對比
表2 Kubernetes和Marathon對比
3.3.3 對大數(shù)據(jù)服務(wù)框架的集成和封裝
通過Myriad實現(xiàn)大數(shù)據(jù)服務(wù)框架的集成。
與DC/OS相關(guān)的Mesos、容器等技術(shù)在電信運營商領(lǐng)域獲得了廣泛的探索、研發(fā)與實踐。
4.1 浙江移動DC/OS實現(xiàn)“雙11”1折充值秒殺
中國移動以開源技術(shù)Mesos、Marathon、Docker、HA代理為引擎,在其上完成了自有數(shù)據(jù)中心操作系統(tǒng)DC/OS平臺的設(shè)計、測試驗證,平臺采用93個主機節(jié)點,其中平臺部分由5個節(jié)點構(gòu)成Mesos管理節(jié)點集群,8個節(jié)點構(gòu)成HA代理集群,計算節(jié)點由80個Mesos計算節(jié)點組成。為驗證其對業(yè)務(wù)的承載能力,中國移動選取浙江移動手機營業(yè)廳作為試點,將其手機營業(yè)廳系統(tǒng)遷移到DC/OS平臺上,用于重點解決秒殺場景。并在2015年11月11日,推出手機營業(yè)廳充值1折秒殺的活動,借以實驗和測試平臺對其業(yè)務(wù)的支撐。在當晚8點,DC/OS平臺充分展現(xiàn)了其在應(yīng)對業(yè)務(wù)高峰時的能力優(yōu)勢,順利通過“雙11”考驗。
數(shù)據(jù)顯示,“雙11”活動期間,浙江移動手機營業(yè)廳系統(tǒng)承受的并發(fā)數(shù)峰值接近6萬次/s,后臺服務(wù)調(diào)用成功率均在99.95%以上,成為浙江移動首個在單日實現(xiàn)10億級PV的業(yè)務(wù)系統(tǒng),其平臺CPU利用率從資源池的10%提高到40%~50%。
隨后,中國移動陸續(xù)將CRM核心業(yè)務(wù)逐步遷移,在2016年4月底DC/OS已成功承載其16套應(yīng)用系統(tǒng),涵蓋CRM營業(yè)廳、手機營業(yè)廳等多套核心系統(tǒng)。
4.2 Verizon的DC/OS支撐自有系統(tǒng)和應(yīng)用
Verizon公司作為國際電信運營商巨頭之一,不僅重視電信運營商基礎(chǔ)業(yè)務(wù)如語音及數(shù)據(jù)服務(wù),同時也提供面向用戶的應(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)仍是集群化的、計算資源孤島式的,無法實現(xiàn)應(yīng)用的自動化部署、擴縮容,因此需要一種較有限的集群管理工具,并可以實現(xiàn)隔離、灰度升級、打包、資源彈性分配等能力。
鑒于此,在2013年,Verizon為改變計算和存儲資源的低利用率和隨之而來的運營低效率問題,開始選擇Docker容器技術(shù)以及用來管理Docker容器及服務(wù)器集群的Mesos技術(shù)重構(gòu)其基礎(chǔ)設(shè)施架構(gòu),以支撐Verizon網(wǎng)絡(luò)上數(shù)以萬計的工作任務(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ī)劃計劃:閑置的集群資源可提供給新業(yè)務(wù),因此無需為新業(yè)務(wù)規(guī)劃預(yù)期規(guī)模所使用的資源;進一步可根據(jù)所有應(yīng)用的運營情況來增加硬件投入,按季度擴展集群規(guī)模。這種方法還可以使計劃更具體和有效。
(2)時間成本
·應(yīng)用快速部署:支持在 72 s內(nèi)部署 50 000個Docker容器,應(yīng)用集群部署與過往相比提高了一個數(shù)量級。
·開發(fā)成本降低:無需關(guān)注機柜和硬件環(huán)境,應(yīng)用實現(xiàn)短平快的開發(fā)。
Verizon計劃在其Mesos集群上運行一些服務(wù),第一批將被遷移到Mesos集群上的服務(wù)包括無線網(wǎng)絡(luò)支撐系統(tǒng)和一些移動應(yīng)用的后臺以及FiOS網(wǎng)絡(luò)支撐系統(tǒng) (光纖到戶)。Verizon還計劃將其Hadoop和Spark分析任務(wù)從它們的專屬集群上遷移到Mesos集群。其最終目標是希望該集群可達到如互聯(lián)網(wǎng)巨頭般的由廉價、單一的硬件設(shè)備組成的數(shù)據(jù)中心。
未來電信行業(yè)將會是一個IT、CT融合,電信運營商互聯(lián)網(wǎng)化的趨勢,IT所占比重會越來越大,電信行業(yè)的盈利模式也會從傳統(tǒng)的提供通道到提供IT資源、提供服務(wù)的方向轉(zhuǎn)變。近幾年隨著大數(shù)據(jù)、云計算、容器化、微服務(wù)、平臺戰(zhàn)略等新技術(shù)和新概念的層出不窮和快速發(fā)展,在業(yè)務(wù)支撐、架構(gòu)能力、平臺擴展性等方面對舊有的煙囪式建設(shè)的業(yè)務(wù)支撐系統(tǒng)提出了巨大的挑戰(zhàn)。因此對現(xiàn)有業(yè)務(wù)和設(shè)備進行容器化改造,對數(shù)據(jù)中心乃至全網(wǎng)IT系統(tǒng)進行DC/OS改造,則成了一個必然的選擇。
目前,DC/OS相關(guān)技術(shù)已在部分運營商有成功使用的案例,證明相關(guān)技術(shù)在運營商的業(yè)務(wù)和網(wǎng)絡(luò)中具有不可忽視的作用,同時運營商也需從自身定位和轉(zhuǎn)型戰(zhàn)略的視角來看待DC/OS的發(fā)展,并選擇自身合適的業(yè)務(wù)分步進行改造和遷移。
[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]張基恒,魏進武.電信運營商私有云適應(yīng)性分析 [J].移動通信,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è)計和研究工作。
張呈宇(1988-),男,中國聯(lián)合網(wǎng)絡(luò)通信有限公司研究院工程師,主要從事虛擬化技術(shù)、云計算IaaS、容器技術(shù)、數(shù)據(jù)中心操作系統(tǒng)方面的研究工作。
魏進武(1978-),男,博士,中國聯(lián)合網(wǎng)絡(luò)通信有限公司研究院軟件與系統(tǒng)實驗室主任、副教授,負責和參與了國家“863”計劃重大項目5項、國家科技重大專項課題2項,負責中國聯(lián)通研發(fā)項目50余項,主要從事大數(shù)據(jù)、云計算以及電信IT系統(tǒng)等的設(shè)計及研發(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