DCOS

數據中心作業系統（DCOS）是為整個數據中心提供分散式調度與資源協調功能，實現數據中心級彈性伸縮能力的軟體堆疊，它將所有數據中心的資源當做一台計算機來調度和管理。

基本介紹

• 中文名：數據中心作業系統
• 外文名：Data Center Operating System

系統簡介

數據中心作業系統（DCOS）是為整個數據中心提供分散式調度與協調功能，實現數據中心級彈性伸縮能力的軟體堆疊，它將所有數據中心的資源當做一台計算機來調度。

大規模套用的數據中心作業系統有：Google Borg/Omega系統和Twitter、Apple、Netflix等公司基於Mesos構建的系統。

解決方案

可以用於數據中心作業系統構建的開源解決方案有：

1) Mesos：Mesos最早由美國加州大學伯克利分校AMPLab實驗室開發，後在Twitter、Apple、Netflix等網際網路企業廣泛使用，成熟度高。其中，Mesosphere公司DCOS產品，就是以Mesos為核心，支持多領域的分散式集群調度框架，包括Docker容器集群調度框架Marathon、分散式 Cron（周期性執行任務）集群調度框架Chronos和大數據的主流平台Hadoop和Spark的集群調度框架等，實現系統的資源彈性調度。

2) Apache Hadoop YARN：Apache Hadoop YARN一種新的 Hadoop 資源管理器，它是一個通用資源管理系統，可為上層套用提供統一的資源管理和調度。

3) Kubernetes：Kubernetes是Google多年大規模容器管理技術的開源版本，面世以來就受到各大巨頭及初創公司的青睞，社區活躍。

4) Docker Machine + Compose + Swarm：Docker公司的容器編排管理工具。

5) 此外，CloudFoundry/OpenShift等PaaS產品也可以作為DCOS的解決方案。

相關技術在調度級別、生態活躍、適用場景等方面的比較如下表所示：

產品名稱	Mesos	Yarn	Kubernetes	Docker Machine+; Compose; +Swarm	CF/OpenShift
調度級別	二級調度; （Dominant Resource Fairness）	二級調度; （FIFO，Capacity Scheduler，Fair Scheduler）	二級調度（基於Predicates和Priorities兩階段算法）	一級調度 （提供Strategy 和Filter兩種調度策略）	CF 一級調度 （基於Highest-scoring調度策略）/OpenShift使用Kubernetes
生態活躍	活躍	活躍	非常活躍	活躍	一般
適用場景	通用性高，混合場景	大數據生態場景	目前較單一	較單一	較單一
成熟度	高	高	中	低	中
套用與平台耦合度	低	中	中	低	高
套用案例分析	Twitter、Apple、Airbnb、Yelp、Netflix、ebay、Verizon	Hadoop生態圈套用很多	目前快速發展中，生產環境套用較少	很少	較少，套用與平台的耦合度較高

（註：按照公開文檔和使用經驗做簡單比較，未做詳細驗證）

根據對適合構建DCOS的各種技術架構的評估，我們選擇以Mesos為基礎的方案。其優點是成熟度高、使用兩級調度框架、適合多種套用場景、支持混合部署、套用與平台耦合度低。

建設歷程

2014年3月開始關注Docker容器化技術，2014年8月啟動Docker套用的技術驗證。

2014年11月將核心繫統CRM的一個完整集群遷移到容器運行，Docker正式投入生產。

2015年8月提出數據中心作業系統的構想，建設DCOS驗證網。

2015年11月4日中國移動浙江公司DCOS驗證網上線，成功支撐手機門市“雙11”活動，12月10日CRM系統試點遷移到DCOS。

技術架構

中國移動浙江公司DCOS方案採用了以容器為基礎封裝各類套用和運行環境，以Mesos、Marathon為核心實現容器資源的分散式調度與協調，以Haproxy、Confd、Etcd實現服務註冊和業務的引流。架構如下：

(點擊放大圖像)

a) 套用封裝

套用封裝採用Docker做為套用容器引擎，Docker是輕量級虛擬化技術，它在標準的LXC之上融合AUFS分層鏡像管理機制，並以套用為單元進行“集裝封箱”，實現的相關套用封裝能力如下：

1) Docker容器技術可以部署套用到可移植的的容器中，這些容器獨立於硬體、語言、框架、打包系統，幫助實現持續集成與部署。一個標準的Docker容器包含一個軟體組件及其所有的依賴 ，包括二進制檔案、庫、配置檔案、腳本等。

2) Docker容器可以封裝任何有效負載，可以在任何伺服器之間進行一致性運行。開發者構建的套用只需一次構建即可多平台運行。

b) 資源調度

使用Mesos作為資源調度框架，其核心工作原理如下：

1) Mesos Master負責將資源分配給各個框架，而各個框架的Scheduler進一步將資源分配給其內部的各個應用程式。

2) Mesos和不同類型的Framework通信，每種Framework通過各自的Scheculer發起task給Mesos slave，對Mesos集群進行調度管理。

3) Framework的Executor執行其Scheculer發起的task。

c) 任務調度

由於Mesos僅負責分散式集群資源分配，不負責任務調度。因此，需引入Marathon來基於Mesos來做任務調度，Marathon用來調度長期運行的服務。Mesos集群可以混合運行不同類型的任務 ，其任務調度示意圖如下：

1) Marathon基於Mesos的任務調度為動態調度，即每個任務在執行之前是對具體伺服器和綁定連線埠均為未知。

2) Mesos集群上混合運行著包括Marathon在內各種調度框架的任務，當某台伺服器宕機以後，Marathon可把任務遷移到其他伺服器上，實現容錯。

d) 服務註冊及引流

通過Haproxy、Confd、Etcd配合實現數據中心套用的動態服務註冊與引流，其中Etcd是一個高可用的鍵值存儲系統，主要用於共享配置和服務發現。HAProxy提供高可用性、負載均衡的解決方案。其主要的架構流程如下：

1) Marathon通過Mesos啟動Docker容器時，Marathon將容器啟動信息通知Etcd服務。

2) Etcd服務將已經啟動容器信息註冊到Etcd鍵值庫中。

3) Confd監測到Etcd中相關的服務變化，Confd就會根據變化的情況更新Haproxy的cfg配置檔案並執行重新載入命令，使相關變化生效，同樣當容器停止時也會觸發Haproxy更新cfg配置檔案並重新載入，達到動態服務註冊。

4) 業務請求通過HAProxy分發到Docker容器中的套用。

e) 自動彈性擴縮容

Marathon的擴縮容默認只能根據用戶需要進行手動調整，我們結合多年的系統運維經驗，實現基於並發數、回響時間、CPU和記憶體使用率等容量指標進行自動彈性擴縮容調度的模組。結合前面提到的HAProxy、Confd、Etcd動態服務註冊和引流能力，實現套用的自動彈性擴縮容能力。

功能框架

以開源技術Mesos 、Marathon 、Docker、HAProxy為引擎，在其上開發了DCOS控制台、資源管理模組、鑒權模組、統一日誌中心、彈性擴縮容調度模組、監控管理模組、持續集成平台。DCOS的功能框架如下：

(點擊放大圖像)

1) DCOS Dashboard

2) 資源管理模組：服務目錄管理、規則管理、CMDB信息；

3) 監控管理模組：監控數據採集、日誌管理、告警管理和事件管理；

4) 彈性擴縮容調度模組：基於CPU使用率、記憶體使用率、服務並發數、回響時間等容量數據，通過定製的調度算法實現服務的自動彈性擴縮容；

5) 統一日誌中心：採用Elasticsearch、Logstash、Graylog構建，實現對容器日誌的統一存儲及檢索；

6) 鑒權模組：用戶管理、用戶組管理、許可權策略管理和統一認證接口；

7) 持續集成平台：鏡像構建、集成測試、流程管理和上線管理。

套用

在對DCOS平台驗證網充分測試驗證後，我們選取手機門市系統作為業務試點，遷移至DCOS平台。

手機門市是面向中國移動客戶提供快速便捷的查詢、辦理和交費等自助服務的客戶端軟體及系統，中國移動浙江公司手機門市註冊用戶2500萬，日活躍用戶數300萬。

DCOS平台採用93個主機節點，其中平台部分由5個節點構成Mesos Master Cluster，8個節點構成HAproxy Cluster，計算節點由80個Mesos Slave節點組成，平台和計算節點均跨機房部署，該平台可在1分鐘內輕鬆擴展到1000個以上Docker容器。

下圖為DCOS控制台，手機門市WEB和APP兩個套用模組在DCOS資源池中動態調度，容器數量的變化顯示了兩個套用模組的彈性擴縮容情況：

效果總結

1) 高性能高穩定性

雙十一期間，運行在DCOS架構的浙江移動手機門市系統承受的並發數最高峰值接近6萬次/秒，成為浙江移動首個在單日實現10億級PV的業務系統。

2) 高資源利用率

DCOS相較於虛擬機有著基於CPU、記憶體的更細粒度的資源調度，多個計算框架或應用程式可共享資源和數據，提高了資源利用率。

3) 高效的跨數據中心的資源調度

DCOS平台展現了其線上性動態擴展、異地資源調度等方面的優異性能，1分鐘內快速擴展到1000+的容器（如果套用更輕量啟動速度還可以更快），平台和計算節點完全跨機房分散式調度。

4) 自動彈性擴縮容

徹底解決套用的擴縮容問題，容量管理從“給多少用多少”向“用多少給多少”轉變，被動變主動。套用的擴縮容時間從傳統集成方式的2-3天縮短到秒級分鐘級，可以根據業務負載自動彈性擴縮容。

5) 敏捷開發、快速部署

容器和DCOS技術的結合通過將套用和它的依賴進行封裝，隱藏了數據中心硬體和軟體運行環境的複雜性，讓開發、測試、生產的運行環境保持一致，降低套用的開發、發布難度。傳統的部署模式“安裝->配置->運行”轉變為“複製->運行”，實現一鍵部署。

6) 高可用性、容災

DCOS平台所有組件採用分散式架構，套用跨機房分散式調度。自動為宕機伺服器上運行的節點重新分配資源並調度，保障業務不掉線，做到故障自愈。

經驗總結

1. 經驗

1)Marathon自動彈性擴縮容調度

Marathon的擴縮容默認只能根據用戶需要進行手動調整，我們結合多年的系統運維經驗，實現基於並發數、回響時間、CPU和記憶體使用率等容量指標進行自動彈性擴縮容調度的算法。

2)Marathon Etcd聯動實現服務註冊發現

Etcd只是個獨立的服務註冊發現組件，只能通過在宿主機上部署Etcd發現組件，通過其發現宿主機的容器變化來發現，屬於被動的發現，往往會出現發現延遲時間較長的問題，我們通過修改Etcd組件的發現接口，實現與Marathon的Event事件接口進行對接，達到Marathon的任何變動都會及時同步給Etcd組件，提高了系統的發現速度，並且避免在每個宿主機上部署Etcd發現組件。

3)DCOS平台組件容器化改造

為提高DCOS平台的可維護性，我們將DCOS平台的相關組件全部進行Docker化，相關組件運行環境和配置信息都打包到Docker鏡像中，實現快速部署、遷移和升級。

2. 套用遷移經驗

套用要在DCOS平台上動態的擴展和伸縮，對套用的要求是無狀態化。

以常見的三層架構為例，WEB層負責展現，APP層負責處理業務邏輯和資料庫進行互動，WEB層使用負載均衡進行請求分發，WEB到APP層有多種調用方式，如下圖所示：

1) WEB層套用無狀態改造

去HTTP Session：不再採用傳統的HTTP Session保存會話的方式；

將客戶端與WEB端的互動改成http+json短連線方式；

使用快取伺服器來保存用戶的會話信息。

如下所示：

通過以上的套用改造使套用的狀態數據與套用分離，WEB實例的啟動和停止不會導致用戶會話數據的丟失。

2) APP層套用改造

APP層要支持動態的伸縮，除了APP層實現無狀態化外，取決於WEB到APP的RPC調用方式：

HTTP協定：同WEB層一樣使用負載均衡方案HAProxy+Confd+Etcd；

服務化框架：使用服務化框架服務的發現和註冊功能，注意需要將容器外的IP和連線埠上報給配置中心；

未實現服務發現的RPC調用：對於沒有服務發現和註冊功能的傳統套用則需進行改造。我們以移動的CRM系統為例，CRM系統使用EJB技術實現，APP層沒有服務註冊的能力，改造後的架構圖如下所示：

Zookeeper保存APP實例的實時分布數據，Marathon負責監控APP實例的運行狀態，並在狀態發生變化時通知給Zookeeper進行修改APP實例分布數據，WEB層根據分組策略獲取一組的APP實例分布信息，根據該信息輪訓調用組內的APP實例。

分組

為保證APP負載的均衡我們採用分組策略，我們將所有Zookeeper內的APP實例根據Hash算法進行分組，每個組內保持著一定數量的APP實例，每個WEB請求按照路由策略均衡分發到組內APP實例上。

擴縮容調度

垂直調度：因為每次彈性擴縮都會對WEB訪問APP的路由表進行更新，當頻繁更新時有可能會造成服務訪問的短時異常，為避免該問題我們採用垂直調度機制，每個APP組根據彈性調度算法進行垂直擴縮操作，不影響其他組的運行。

水平調度：對APP層整體服務能力進行評估，當能力變化值大於一個組的服務能力時，需要進行水平擴縮操作，以組為單位進行水平擴縮。

3. 問題

1)Marathon Exit容器清理

彈性擴縮容會導致宿主機上產生大量的Exit狀態的Docker容器，清除時較消耗資源，影響系統穩定性。默認Mesos只有基於時長的清除策略，比如幾小時，幾天后清除，沒有基於指定時間的清除策略，比如在系統閒時清除，也無法針對每個服務定製清除策略。

解決方案：修改Marathon的源碼程式，添加Docker容器垃圾清理接口，可以對不同服務按指定策略將Exit狀態的Docker容器進行清理。

2)Docker DeviceMapper dm-thin問題

在CentOS6.5上，我們發現Docker在使用DeviceMapper時會不定時出現Linux Kernel Crash的情況。

解決方案：通過修改dm-thin.c核心源碼修復。

後續計畫

通過將公司兩大核心繫統遷移到DCOS，對於使用Mesos和Docker來構建企業私有雲的彈性計算平台得到了充分的驗證，後續將繼續完善彈性調度功能、複雜套用編排、持續集成等能力。同時對Kubernetes、Swarm與Mesos的集成方案進行跟蹤、測試和比較，構建高效穩定的DCOS平台能力。