本文講的是<b>DC/OS關鍵技術與應用場景</b>【編者的話】文章首先對資料中心作業系統内的主要技術，包括Mesos、Yarn、Kubernetes和容器進行了闡述。根據國内外電信營運商的現狀和面臨的問題，提出了一種解決方案，并對技術實作及選型建議進行了讨論。最後對電信營運商應用DC/OS關鍵技術的案例進行了簡要介紹。
随着越來越多的平台、架構、系統、元件和工具等通過開源社群、小微型初創項目而衍生，不再由IT或網際網路巨頭獨自壟斷，這為IT領域各項技術的快速、活躍發展提供了良好的溫床，開源技術的迅速發展、活躍的社群力量，使得一些理念如DC/OS（資料中心作業系統）以及技術如Mesos、Kubernetes和容器等應運而生，并廣泛地得到了實驗和疊代改進。
DC/OS問世之前，如谷歌（Google）等網際網路企業就内部資源排程和配置設定、負載，已逐漸展開了探索，形成了一些如Borg等的生産化項目。而在2014年，由Mesosphere實作了第一個可進行統一排程所有資料中心及雲資源的軟體堆棧，并稱為DC/OS。目前已投入實際生産使用的DC/OS包括Google的Borg/Omega系統和推特（Twitter）、蘋果（Apple）、網飛（Netflix）等公司基于Mesos建構的系統。而在2016年4月，Mesosphere将自己的DC/OS代碼進行了開源，其中包含超過30項元件技術，最為典型的有Apache Mesos與Marathon。下文将對可用于DC/OS建構的開源技術包括Mesos、Yarn、Kubernetes和Docker進行簡要闡述。
Mesos是開源資源統一管理和排程平台，其實作邏輯如圖1所示，由美國加州大學伯克利分校AMPLab開發，後應用于Twitter、Apple、Netflix等企業。其亮點在于兩層排程的架構可以做到“大叢集”、減小“中心節點”的壓力以及在同一個叢集中可接入多種應用、架構，提高分布式叢集的使用率。
由于Mesos上的中繼資料可通過各個計算節點重新注冊而進行重構，是以可通過Zookeeper解決單點故障問題。輕量級的Mesos架構包括以下4個元件。
Mesos管理節點
系統的核心，負責管理接入Mesos的各個架構和計算節點，并将計算節點上的資源按某種政策（預設使用DRF（dominant resource fairness，主導資源公平）算法）配置設定給不同的架構。
Mesos計算節點
接收并執行來自管理節點的指令、管理節點上的任務并為各個任務配置設定資源。
架構
計算架構，以注冊的方式接入Mesos以便其進行統一管理和資源配置設定。
執行器
主要用于啟動内部任務。
Yarn是新的Hadoop MapReduce架構，實作思路如圖2所示。其主要為了解決Hadoop1.0擴充性較差、不支援多計算架構的問題，本質是一個資源管理架構。Yarn減小了JobTracker的資源消耗，并且讓監測每一個工作子任務狀态的程式更安全、更分布式化；對于資源的表示以記憶體為機關，較舊版本更合理。其亮點在于可以更快地進行MapReduce計算，實作對多架構的支援以及架構更新的簡便性。
較1代MapReduce的設計思路，Yarn将JobTracker兩個主要的功能，即資源管理和任務排程/監控，分解為獨立元件資料總管和應用管理節點。資料總管全局管理所有應用程式計算資源的配置設定，每一個應用的應用管理節點負責相應的排程和協調。
Kubernetes是Google多年大規模容器管理技術的開源版本，其實作思路如圖3所示。其亮點在于具有容器編排能力、相對輕量級及易于管理運作Docker的容器。Kubernetes使用Docker對程式進行包裝、執行個體化、運作，并以叢集的方式運作、管理跨機器的容器，同時解決了Docker跨機器容器之間的通信問題。
Kubernetes架構包含以下元件。
Kubernetes管理節點：管理整個系統。
Kubernetes API伺服器：系統入口，封裝了核心對象的操作。
Kubernetes排程器：負責叢集資源排程，為建立的Pod配置設定機器。
Kubernete節點：運作節點，用于運作管理業務的容器。
Kuberlet：負責管控容器，從伺服器接收指令。
Kubernetes代理：負責為Pod建立代理服務。
Docker：Kubernetes節點是容器運作節點，需要運作Docker服務。
首先，Kubecfg将請求如建立Pod等，發送給Kubernetes應用用戶端，并由其将該請求發送給API伺服器。API伺服器根據請求類型（如建立Pod時存儲類型是pods）并依此選擇何種REST存儲API對請求作出處理。REST存儲API對請求做相應的處理，并将處理結果存入高可用鍵值存儲系統（ETCD）中，在API伺服器響應Kubecfg的請求後，排程器會根據Kubernetes應用用戶端擷取叢集中運作的Pod及從屬節點的資訊。依據從Kubernetes應用用戶端擷取的資訊，排程器将未分發的Pod分發到可用的從屬節點上。
Docker 是一個開源的應用容器引擎，為開發者提供一個可将應用及依賴包打包至一個可移植的容器環境中，并釋出到任意流行的 Linux 機器上。容器采用沙箱機制，容器間不存在接口。其亮點在于快速便捷的單次建構+導出運作模式及愈加豐富的生态系統。
Docker采用C/S模式，使用遠端API來管理和建立Docker容器。Docker容器通過 Docker鏡像來建立。容器與鏡像的關系類似于面向對象程式設計中的對象與類。Docker采用 C/S架構 Docker Daemon作為服務端接受來自客戶的請求，并處理這些請求（建立、運作、分發容器）。用戶端和服務端既可以運作在一個機器上，也可通過Socket或者RESTful API來進行通信。Docker Daemon一般在宿主主機背景運作，等待接收來自用戶端的消息。Docker用戶端則為使用者提供一系列可執行指令，使用者用這些指令實作跟Docker Daemon互動。
雲計算、大資料相關技術的普及推進了企業雲化的建設和發展。雖然大部分國内外電信營運商已實作了IaaS資源池化和部分PaaS及應用資源池化，能夠滿足生産供給和部署。但大部分營運商的資料中心采用分隔式叢集實作思路，包括以開源Yarn或定制版大資料資源排程，承載資料類作業的叢集以及資料庫、緩存叢集等；缺乏迫切資源的跨域排程能力；同時目前的營運系統還存在的資源運作不均衡、時段運作不均衡等問題，具體包括：
應用難以實作靈活、快速地部署，應用系統的開發過程從開發到生産有不同的部署環境，對應的實作代碼也面臨着不同環境的開發和部署；
系統彈性伸縮能力不足，擴縮容需經過較多環節，無法實作快速、自動的伸縮，同時會造成資源的浪費；
現有資源使用率在15%左右，無法充分實作資源的有效利用；
應用系統仍舊面臨“煙囪式”的建設等現實問題，應用與平台緊耦合，高可用、有效監控、智能運維難以标準化。
鑒于此，電信營運商需設計、研發一種架構，以解決資源排程等現實問題并提供微服務化的實作環境。
一種可滿足電信營運商需求的DC/OS的功能實作如圖4所示，分為4部分内容，分别是業務排程層、應用服務層、資源管理層以及自動化營運工具。
業務排程層的主要功能包括叢集管理、服務接入、服務命名、服務發現、服務目錄管理、負載均衡、服務通路控制等。
應用服務層主要負責容器叢集的管理和大資料叢集的管理。
資源管理層的主要功能包括底層計算資源的管理以及對其上注冊的任務的管理。
自動化營運工具包括監控和多租戶管理兩大功能，其中監控又細分為對資源、服務、容器、叢集的監控。
為實作如圖4所示的功能架構，需要引入資源排程技術、容器技術等，在技術路線選擇上，則以社群領域的開源技術為基礎形成自有版本，并兼顧開源社群本身的發展。一種較為适合營運商的DC/OS技術架構如圖5所示。
開源DC/OS和商用DC/OS對比見表1。
選型建議：可使用開源技術和自行研發結合方式實作，其中對資源的統一管理和排程采用開源的Mesos或者開源的DC/OS 來支撐，從對比來看開源DC/OS 與ApahceMesos核心子產品功能一緻，開源 DC/OS增加了如架構的自動安裝部署和門戶等附加功能。
Kubernetes和Marathon對比見表2。
選型建議：Kubernetes和Marathon各有優點，且各自都有固定的生态圈，是以目前階段無法標明對容器的編排和排程管理采用拿一個開源工具，是以在DC/OS平台需要長期跟蹤和內建兩個容器編排工具。
通過Myriad實作大資料服務架構的內建。
與DC/OS相關的Mesos、容器等技術在電信營運商領域獲得了廣泛的探索、研發與實踐。
中國移動以開源技術Mesos、Marathon、Docker、HA代理為引擎，在其上完成了自有資料中心作業系統DC/OS平台的設計、測試驗證，平台采用93個主機節點，其中平台部分由5個節點構成Mesos管理節點叢集，8個節點構成HA代理叢集，計算節點由80個Mesos計算節點組成。為驗證其對業務的承載能力，中國移動選取浙江移動手機營業廳作為試點，将其手機營業廳系統遷移到DC/OS平台上，用于重點解決秒殺場景。并在2015年11月11日，推出手機營業廳充值1折秒殺的活動，借以實驗和測試平台對其業務的支撐。在當晚8點，DC/OS平台充分展現了其在應對業務高峰時的能力優勢，順利通過“雙11”考驗。
資料顯示，“雙11”活動期間，浙江移動手機營業廳系統承受的并發數峰值接近6萬次/s，背景服務調用成功率均在99.95%以上，成為浙江移動首個在單日實作10億級PV的業務系統，其平台CPU使用率從資源池的10%提高到40%~50%。
随後，中國移動陸續将CRM核心業務逐漸遷移，在2016年4月底DC/OS已成功承載其16套應用系統，涵蓋CRM營業廳、手機營業廳等多套核心系統。
Verizon公司作為國際電信營運商巨頭之一，不僅重視電信營運商基礎業務如語音及資料服務，同時也提供面向使用者的應用托管業務以及Verizon内部服務如雲服務、使用者托管應用等。而這些年OTT的興起，令傳統通信業務逐漸減少，也令Verizon公司對其他非電信業務更加重視。但其傳統的電信業資料中心架構仍是叢集化的、計算資源孤島式的，無法實作應用的自動化部署、擴縮容，是以需要一種較有限的叢集管理工具，并可以實作隔離、灰階更新、打包、資源彈性配置設定等能力。
鑒于此，在2013 年，Verizon為改變計算和存儲資源的低使用率和随之而來的營運低效率問題，開始選擇Docker容器技術以及用來管理Docker容器及伺服器叢集的Mesos技術重構其基礎設施架構，以支撐Verizon網絡上數以萬計的工作任務。2014年底，Verizon建立了一種以Linux為核心，由遍布資料中心的普通伺服器構成的叢集。在應用了新技術後，在硬體資源和應用部署兩方面均有有效的提升。具體如圖6所示。
資源使用率提升：其資料中心的資源使用率由最初的10%~20%提高到50%以上。
提升叢集使用有效性：參考叢集的曆史資料，哪些應用上雲或者從雲上下線了，進而将硬體采購做得更合理。
減少硬體資源規劃計劃：閑置的叢集資源可提供給新業務，是以無需為新業務規劃預期規模所使用的資源；進一步可根據所有應用的營運情況來增加硬體投入，按季度擴充叢集規模。這種方法還可以使計劃更具體和有效。
應用快速部署：支援在72 s内部署50 000個Docker容器，應用叢集部署與過往相比提高了一個數量級。
開發成本降低：無需關注機櫃和硬體環境，應用實作短平快的開發。
Verizon計劃在其Mesos叢集上運作一些服務，第一批将被遷移到Mesos叢集上的服務包括無線網絡支撐系統和一些移動應用的背景以及FiOS網絡支撐系統（光纖到戶）。Verizon還計劃将其 Hadoop和Spark分析任務從它們的專屬叢集上遷移到Mesos叢集。其最終目标是希望該叢集可達到如網際網路巨頭般的由廉價、單一的硬體裝置組成的資料中心。
未來電信行業将會是一個IT、CT融合，電信營運商網際網路化的趨勢，IT所占比重會越來越大，電信行業的盈利模式也會從傳統的提供通道到提供IT資源、提供服務的方向轉變。近幾年随着大資料、雲計算、容器化、微服務、平台戰略等新技術和新概念的層出不窮和快速發展，在業務支撐、架構能力、平台擴充性等方面對舊有的煙囪式建設的業務支撐系統提出了巨大的挑戰。是以對現有業務和裝置進行容器化改造，對資料中心乃至全網IT系統進行DC/OS改造，則成了一個必然的選擇。
目前，DC/OS相關技術已在部分營運商有成功使用的案例，證明相關技術在營運商的業務和網絡中具有不可忽視的作用，同時營運商也需從自身定位和轉型戰略的視角來看待DC/OS的發展，并選擇自身合适的業務分步進行改造和遷移。
參考文獻：
[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]. 移動通信, 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.
作者：張基恒、李大中、張呈宇、魏進武
原文釋出時間為：2017-02-21
本文作者：張基恒、李大中、張呈宇、魏進武
本文來自雲栖社群合作夥伴Dockerone.io，了解相關資訊可以關注Dockerone.io。
原文标題：DC/OS關鍵技術與應用場景