資料中心作業系統 DC/OS的深入理解

DC/OS 是 Mesosphere 開源的資料中心作業系統。可輕鬆的部署和執行有狀態和無狀態的容器、大資料以及傳統應用。該系統基於 Apache Mesos 構建，其經驗來自 Mesosphere, Yelp, Twitter, Airbnb, 以及很多創新的公司。

管理介面截圖：

技術不斷演進迭代，企業面臨著眾多挑戰，例如：快速開發服務，收集和分析海量資料，接下來是如何對海量資料做出快速響應等挑戰。可以預見，軟體是企業直面這些眾多挑戰的重要因素，當然軟體也驅動了個各種裝置，汽車，銀行系統等等。

建立一個支援快速部署服務的現代資料中心平臺是一個日益複雜的挑戰。IT組織面臨巨大的壓力來實現這些目標，同時還要關注傳統中的需求，比如：保持敏捷性，高效率，安全性，服務質量和運營方面等。為了滿足不斷增長的業務需求，IT組織和服務提供商正在轉向資料中心作業系統（DC/OS）。

DC/OS是一個開源軟體專案，可在資料中心和雲端的所有伺服器上抽象計算資源。DC/OS由Apache Mesos分散式系統核心提供支援，這是一個可擴充套件的二層排程程式，它可以集中基礎設施資源並跨多個分散式應用共享資源。DC/OS利用Mesos，Marathon和相關元件，為執行應用服務和大型資料平臺提供高彈性和可擴充套件的解決方案

現代應用狀況

容器化技術已成為IT公司的頭等大事。其中很大一部分是由於軟體執行發生變化，軟體如何快速開發和部署。如果開發商應該開始容器之旅，運營商需要弄清楚如何執行在生產環境中。現在，這個談話已經從容器方式轉變成為世界各地現代應用程式提供強大而可擴充套件的編排系統。

速度和敏捷性在當今的數字化環境中至關重要因素。未來幾年各種裝置產生的海量資料會令人難以置信。為了加快創新步伐，公司正在迅速從傳統的應用轉型為微服務。

而傳統的應用程式會繫結單個虛擬機器或裸機伺服器，現代應用程式完全解耦：由許多容器化的微服務應用和有狀態的大資料引擎組成。大部分公司廣泛使用開源軟體，受益於社群貢獻，讓自己的開發團隊專注於自己業務價值實現。

並不是每個公司都有Google，Facebook，Twitter，Apple或Uber的資源優勢。這些公司花費了巨大人力和財力在平臺建設上，並需要強大的效能，彈性，可用性和安全性去處理最先進的應用程式。

DC/OS為企業和服務提供商提供了一個平臺，可以獲得同樣的好處 - 一個執行容器和平臺服務的平臺，共享統一的基礎設施。DC/OS技術在生產中擁有比任何其他開放原始碼軟體更多的容器支援。

什麼是DC/OS

DC/OS的核心是Mesos分散式系統核心，在對生產環境最苛刻的環境（如Twitter和Apple）中通過了測試和驗證。DC/OS利用Mesos進行叢集資源管理，以處理作業排程，資源管理和抽象，高可用性以及其他基礎設施級流程。

資源排程只是架構的一部分，它的上層技術是Mesos，然後構成了完整的DC/OS平臺。這些包括本地容器平臺（Marathon）;DC/OS安裝程式，Universe軟體包儲存庫; GUI和CLI進行管理和監控;以及許多其他功能，包括網路，儲存，安全，負載平衡和服務發現。

DC/OS是唯一將所有這些元件捆綁在一起併成為分散式軟體部署的開源專案。DC/OS使每個公司都有能力成為Mesos受益者。做的事情只是自己工作的小部分。

好處包括：

●生產驗證：基於Mesos和Marathon，是業界最成熟，最具企業級的容器編排平臺。

●二層排程：Mesos具有兩層排程設計，允許平臺服務通過自動分發任務和容器來智慧地排程工作負載，從而提高利用率。

●有狀態服務：複雜的分散式系統可以在幾分鐘內部署。

●自動故障恢復：針對所有型別的應用程式，服務和工作負載內建高可用性和容錯能力。

●資源效率：容器實現了效能隔離，消除了靜態分割槽環境並解放了更高的伺服器利用率。在DC/OS上執行Spark，Kafka和Cassandra，可以動態地擴縮容各種計算資源

●簡化操作：通過基於GUI/CLI的監控和管理來控制整個資料中心資源。DC/OS提供了一個單一GUI介面和互操作接入，用於管理應用程式和有狀態服務的連續生命週期。

●寫一次，在任何地方執行：DC/OS提供了一個抽象層，無論部署在裸機，虛擬機器，私有云或公共雲上，都能提供標準使用者體驗。

擁有充滿活力的使用者群體，合作伙伴和貢獻者使我們能夠將DC/OS視為新的需求，出現用例。

DC/OS是開源技術，但它也是一個完整的生態系統。保持高速發展勢頭，建立一個充滿活力的社群是很重要的。合作伙伴包括雲端計算提供商，如微軟，領先的系統整合商，如埃森哲，以及世界上最創新的消費者技術公司，如Yelp。DC/OS目前由Mesosphere組織，提供社群提交者的貢獻和路線圖。

使用DC/OS 1.9，增加了諸如Pods和GPU支援等令人興奮的新功能，以加強現代資料豐富的應用程式的企業級解決方案。這使得傳統遺留應用程式的工作負載能夠進行機器學習。DC/OS現在允許您分離和預留GPU資源，和神經網路與CPU相比提高高達10-20％。此外，增強的監控，日誌記錄和故障排除功能使生產中的執行容器更加容易。

超越容器

容器技術已經存在了一段時間。 Apache Mesos在2010年開始使用容器。自2000年初以來，Google決定使用容器而不是Borg的虛擬機器，使用容器的資源管理系統。隨著分散式系統和微型伺服器的興起，通過引入簡化的容器管理工具，最近出現了人氣的激增。

DC/OS與其他受歡迎的容器技術（如Kubernetes和Docker Datacenter）能夠脫穎而出是如下原因：

1.DC/OS不單單支援Docker，也適用於所有基於OCI容器技術。DC/OS和它的容器編排平臺（Marathon）是執行Docker容器的出色平臺。然而現代平臺需要更多靈活性。DC/OS支援新興的容器格式，如AppC和OCI。

最後，所有容器引擎都使用現代Linux作業系統中的Linux cgroups和名稱空間。使用者不必考慮容器引擎的實際實現或隔離資源的機制。

2.DC/OS對於容器操作，不僅僅是容器編排。 Marathon容器技術流程平臺包含一系列功能強大的功能，用於管理整個容器生命週期。很多正在使用Marathon使用者包括Verizon，三星，Yelp，Autodesk，迪士尼，Mattermark等。

3.DC/OS有一個獨一無二的兩層排程器，可以執行許多分散式 系統作為服務。通過從核心資源排程程式中分離解決方案特定的排程邏輯，叢集資源可以在諸如Marathon，Spark，Kafka，Cassandra和Jenkins等眾多平臺之間共享資源。

有狀態的服務特別受益於這種體系結構，因為框架排程器可以處理諸如節點配置和跨故障區域的資料的智慧複製等操作任務，從而提高可用性和資料永續性。

資料中心的應用市場

通過抽象所有資料中心資源，DC/OS可以將微服務的打包，部署和操作等複雜操作進行簡潔化處理。對於現代CI/CD到大資料串聯的場景不會在複雜，也不需要以前那些高度專業化的部署和運營技能。從前需要花費數天，甚至數週的時間來部署有狀態的分散式應用程式是很常見的。

DC/OS Universe是一個包（Package）倉庫，包括開源和商業軟體交付。通過點選按鈕，您可以輕鬆部署各種平臺服務，如Cassandra，Chronos，Elasticsearch，HDFS，Jenkins，Kafka，Marathon-LB，Spark等。安裝時間以分鐘而不是數天或數週計算。

如果您正在尋找的應用程式不在Universe中，請可以自行打包應用程式並上線應用商城。DC/OS還提供了為私有定製應用程式部署離線本地Universe的功能。

傳統意義上，資料服務框架一般很難使用，通常需要數千行程式碼。必須嚴格實施，並達到高可用性等功能，以確保框架能夠生產就緒。

Mesosphere新開發的開源元件叫包SDK，用於在DC/OS上構建新的有狀態服務。使用SDK，開發人員可以使用持續卷，容器和配置方式來編寫大約100行程式碼的狀態服務。 
該SDK是Mesosphere為DC/OS（如Kafka，Cassandra和HDFS）編寫時留下來的經驗產物。使用DC/OS SDK編寫將極大提高生產率，並通過與合作伙伴和相關軟體運營商進行配合，制定共同標準，開發和上線時間從幾個月縮短到幾天。

企業級DC/OS

雖然Mesosphere完全繼續支援Mesos，Marathon和新興的DC/OS社群，我們也是一家向全球2000企業提供產品和服務的軟體公司。 Mesosphere Enterprise DC/ OS通過提供關於安全性，效能，網路，合規性，監控和多租戶支援的關鍵企業功能來增強開源DC/OS專案。

深入解析DC/OS 1.8

– 高可靠的微服務及大資料管理平臺

 

大家好，歡迎大家參加這次DC/OS的技術分享。

先做個自我介紹，劉超，Linker Networks首席架構師，Open DC/OS社群貢獻者，長期專注於OpenStack, Docker, Mesos等開源軟體的企業級應用與產品化。

從事容器方面工作的朋友可能已經聽說過DC/OS，往往大家誤解DC/OS就是marathon + mesos，其實DC/OS包含很多的元件，DC/OS 1.8九月份釋出了，此次分享給大家做一個介紹。

所謂的DC/OS，全稱為資料中心作業系統，其基本的思想就是使得運維人員操作整個資料中如操作一臺電腦一樣。

DC/OS使用了哪些技術可以做到這一點呢？

如圖，左面是普通的Linux作業系統，右面是DC/OS，在這裡做了一個對比。

無論是哪種作業系統，都需要管理外部的硬體裝置，最重要的四種硬體資源即CPU，記憶體，儲存，網路。

最初使用匯編語言寫程式的前輩，還是需要指定使用那些硬體資源的，例如指定使用哪個暫存器，放在記憶體的哪個位置，寫入或者讀取那個串列埠等，對於這些資源的使用，需要程式設計師自己心裡非常的清楚，要不然一旦JUMP錯了位置，程式就無法執行。這就像運維資料中心的一臺臺物理機的前輩一樣，那個程式放在了哪臺機器上，使用多少記憶體，多少硬碟，都需要心裡非常的清楚。

為了將程式設計師從對硬體的直接操作中解放出來，提升程式設計的效率，從而有了作業系統這一層，實現對於硬體資源的統一管理。某個程式使用哪個CPU，哪部分記憶體，哪部分硬碟，程式只需要呼叫API就可以了，由作業系統自行分配和管理，其實作業系統只做了一件事情，就是排程。對應到資料中心，也需要一個排程器，將運維人員從指定物理機或者虛擬機器的痛苦中解放出來，這就是Mesos。Mesos即使資料中心作業系統的核心。

在使用作業系統的時候，我們可以開發驅動程式來識別新的硬體資源，可以開發核心模組(例如openvswitch.ko)來干預對於硬體資源的使用，對於Mesos，同樣可以開發isolator來識別新的硬體資源例如GPU，也可以開發Executor來干預資源的使用。

在核心之上，就是系統服務，例如systemd，是用來維護程式執行的，如果systemctl enable xxx，則保證服務掛掉後自動重啟。對於DC/OS，保持服務long run的是marathon，但是僅僅只有marathon還不夠，因為服務是啟動在多臺機器上的，而且服務之間是有依賴關係的，一個服務掛掉了，在另外一臺機器啟動起來，如何保持服務之間的呼叫不需要人工干預呢？這需要另外的技術，稱為服務發現，多是通過DNS，負載均衡，虛擬機器IP等技術實現的。

使用作業系統，需要安裝一些軟體，於是需要yum之類的包管理系統，使得軟體的使用者和軟體的編譯者分隔開來，軟體的編譯者需要知道這個軟體需要安裝哪些包，包之間的依賴關係是什麼，軟體安裝到什麼地方，而軟體的使用者僅僅需要yum install就可以了。DC/OS就有這樣一套包管理軟體，和其他的容器管理平臺需要自己編譯Docker映象，自己寫yml，自己管理依賴不同，DC/OS的軟體使用者只需要dcos package install就可以安裝好軟體了，軟體的配置，節點數目，依賴關係都是有軟體編譯者設定。

在最外層，DC/OS像普通的作業系統一樣，有統一的介面和命令列。通過它們，可以管理安裝包，管理節點，執行任務等。DC/OS不僅僅是執行容器的平臺，如果僅僅執行容器，就是容器管理平臺，而非資料中心作業系統。通過DC/OS，你可以在每臺機器上執行一個命令來進行統一的配置，而無需登入到每臺機器上去。你可以執行容器應用和大資料分析應用並共享資源，並且可以相互發現，這更加符合現代網際網路應用，微服務和大資料不可分割。而且Mesos的架構非常開放，你可以通過開發Framework, Executor, Modules, Hooks等，輕鬆干預微服務或者大資料任務的執行過程，來定製化你的應用。這也符合作業系統微核心的概念。

Mesos架構如下

這個圖比較的著名了，也有很多文章介紹這個圖，詳情可以看文章http://mesos.apache.org/documentation/latest/architecture/，這裡不做過多的介紹。

從圖中可以看到，Mesos有Framework(Framework裡面有Scheduler), Master(Master裡面有allocator), Agent, Executor, Task幾部分組成。這裡面有兩層的Scheduler，一層在Master裡面，allocator會將資源公平的分給每一個Framework，二層在Framework裡面，Framework的scheduler將資源按規則分配給Task。

 

Mesos的這幾個角色在一個任務執行的生命週期中，相互關係如下：

 

Agent會將資源彙報給Master，Master會根據allocator的策略將資源offer給framework的scheduler。Scheduler 可以accept這個資源，執行一個Task，Master將Task交給Agent，Agent交給Executor去真正的執行這個Task。

 

這個圖相對比較的簡略，真正詳細的過程比這個複雜很多，大家可以參考這篇部落格http://www.cnblogs.com/popsuper1982/p/5926724.html，在程式碼級別分析了整個任務執行的過程，還畫了一個泳道圖http://images2015.cnblogs.com/blog/635909/201608/635909-20160806163718778-1628977219.png。

 

要研究Mesos，熟悉整個過程非常重要，這樣一個任務執行出現問題的時候，才能比較好的定位問題在哪裡，如果解決。Mesos將一個簡單的任務的執行過程，分成如此多的層次，如此多的角色來做，是為了雙層排程和靈活配置，這是一個核心應該做的事情。

 

我們如何幹預一個Task的執行過程呢？

如果你想完全自己控制Task的執行，而非讓Marathon來執行並保持一個無狀態的Task長執行，就需要自己寫一個Framework，在你的Framework裡面，三個Task之間的關係你可以自己定義，而非像Marathon一樣，Task * 3，3個任務不分彼此，你的Framework可以控制這三個Task一主兩備，可以控制三個Task的啟動順序，可以將一個先啟動的Task的IP，位置等通過環境變數告知另外兩個Task。

寫一個Framework需要寫一個Scheduler，實現一些介面，如文件http://mesos.apache.org/documentation/latest/app-framework-development-guide/中所述。

然後使用使用MesosSchedulerDriver來執行這個Scheduler。

其實Mesos這些模組之間的通訊都是通過Protocol Buffer定義訊息來互動的，然而如果讓Framework的開發人員還要學會如何使用Protocol Buffer訊息和Mesos Master通訊，是很痛苦的事情，所以MesosSchedulerDriver幫助你做了這個事情，你只需要實現Scheduler定義的介面就可以了，不需要了解這些介面是誰呼叫的，呼叫了介面之後，訊息如何傳給Mesos Master。

所有的介面裡面，最重要的是resourceOffers函式，根據得到的offers(每個slave都有多少資源)，建立一系列tasks，然後呼叫MesosSchedulerDriver的launchTasks函式，MesosSchedulerDriver會將這些tasks封裝為LaunchTasksMessage傳送給Mesos Master。

 

第二、寫一個Allocator

通過上面的描述，Mesos有兩層排程，第一層就是Allocator，將資源分配給Framework。

Mesos允許使用者通過自己寫Module的方式，寫一個so，然後啟動的時候載入進去，然後在命令列裡面指定使用so中的哪個Module。

當然寫Allocator的不多，因為Mesos的DRF演算法是Mesos的核心，如果不用這個演算法，還不如不用mesos。

Mesos原始碼中預設的Allocator，即HierarchicalDRFAllocator的位置在$MESOS_HOME/src/master/allocator/mesos/hierarchical.hpp，而DRF中對每個Framework排序的Sorter位於$MESOS_HOME/src/master/allocator/sorter/drf/sorter.cpp，可以檢視其原始碼瞭解它的工作原理。

HierarchicalDRF的基本原理

如何作出offer分配的決定是由資源分配模組Allocator實現的，該模組存在於Master之中。資源分配模組確定Framework接受offer的順序，與此同時，確保在資源利用最大化的條件下公平地共享資源。

由於Mesos為跨資料中心排程資源並且是異構的資源需求時，資源分配相比普通排程將會更加困難。因此Mesos採用了DRF（主導資源公平演算法 Dominant Resource Fairness）

Framework擁有的全部資源型別份額中佔最高百分比的就是Framework的主導份額。DRF演算法會使用所有已註冊的Framework來計算主導份額，以確保每個Framework能接收到其主導資源的公平份額。

 

舉個例子

考慮一個9CPU，18GBRAM的系統，擁有兩個使用者，其中使用者A執行的任務的需求向量為{1CPU, 4GB}，使用者B執行的任務的需求向量為{3CPU，1GB}，使用者可以執行儘量多的任務來使用系統的資源。

 

在上述方案中，A的每個任務消耗總cpu的1/9和總記憶體的2/9，所以A的dominant resource是記憶體；B的每個任務消耗總cpu的1/3和總記憶體的1/18，所以B的dominant resource為CPU。DRF會均衡使用者的dominant shares，執行3個使用者A的任務，執行2個使用者B的任務。三個使用者A的任務總共消耗了{3CPU，12GB}，兩個使用者B的任務總共消耗了{6CPU，2GB}；在這個分配中，每一個使用者的dominant share是相等的，使用者A獲得了2/3的RAM，而使用者B獲得了2/3的CPU。

 

以上的這個分配可以用如下方式計算出來：x和y分別是使用者A和使用者B的分配任務的數目，那麼使用者A消耗了{xCPU，4xGB}，使用者B消耗了{3yCPU，yGB}，在圖三中使用者A和使用者B消耗了同等dominant resource；使用者A的dominant share為4x/18，使用者B的dominant share為3y/9。所以DRF分配可以通過求解以下的優化問題來得到：

max(x,y) #(Maximize allocations)

subject to

x + 3y <= 9 #(CPU constraint)

4x + y <= 18 #(Memory Constraint)

2x/9 = y/3 #(Equalize dominant shares)

最後解出x=3以及y=2，因而使用者A獲得{3CPU，12GB}，B得到{6CPU， 2GB}。

 

HierarchicalDRF核心演算法實現在Src/main/allocator/mesos/hierarchical.cpp中HierarchicalAllocatorProcess::allocate函式中。

 

概況來說呼叫了三個Sorter(quotaRoleSorter, roleSorter, frameworkSorter)，對所有的Framework進行排序，哪個先得到資源，哪個後得到資源。

 

總的來說分兩大步：先保證有quota的role，呼叫quotaRoleSorter，然後其他的資源沒有quota的再分，呼叫roleSorter。

 

對於每一個大步分兩個層次排序：一層是按照role排序，第二層是相同的role的不同Framework排序，呼叫frameworkSorter。

 

每一層的排序都是按照計算的share進行排序來先給誰，再給誰。

 

這裡有幾個概念容易混淆：Quota, Reservation, Role, Weight

• 每個Framework可以有Role，既用於許可權，也用於資源分配
• 可以給某個role在offerResources的時候回覆Offer::Operation::RESERVE,來預訂某臺slave上面的資源。Reservation是很具體的，具體到哪臺機器的多少資源屬於哪個Role
• Quota是每個Role的最小保證量，但是不具體到某個節點，而是在整個叢集中保證有這麼多就行了。
• Reserved資源也算在Quota裡面。
• 不同的Role之間可以有Weight

 

在allocator演算法結束之後，便呼叫Master::Offer，最終呼叫Framework的Scheduler的resourceOffers，讓Framework進行二次排程。同上面的邏輯就串聯起來。

 

第三、寫一個Hook

你可以寫hook模組，講程式碼插在很多關鍵的步驟，從而改寫整個Executor或者Docker或者Task的啟動的整個過程。

 

可以干預的hook的地方定義在mesos/hook.hpp中。

 

Class hook定義如下：

其中比較常用的是slavePrelaunchDockerHook，可以在Docker啟動之前做一些事情，比如準備工作。

還有slaveRemoveExecutorHook，這個可以在executor結束的時候，做一些事情，比如清理工作。

 

第四、建立Isolator

當你有一種新的資源需要管理，並且每個Task需要針對這個資源進行隔離的時候，寫一個Isolator就是有必要的了。

例如預設的容器並不能動態指定並限制任務硬碟使用的大小，所以mesos-containerizer就有了"disk/du"來定時檢視任務使用的硬碟大小，當超出限制的時候採取操作。

Src/slave/containerizer/mesos/containerizer.cpp裡面列出了當前支援的isolator，你也可以實現自己的isolator，並且通過modules引數load進去。

 

Isolator定義了以下函式

 

在執行一個容器的最後，會呼叫每一個isolator的isolate函式，通過這個函式，可以對資源進行一定的限制，例如寫入cgroup檔案等，但是對於硬碟使用量，其實沒有cgroup可以設定，需要過一段時間du一些，這就需要實現watch函式，過一段時間檢視一下硬碟使用量，超過後做一定的操作。

 

第五、寫一個Executor

如果執行一個普通的容器，或者命令列，則不需要實現Executor，僅僅Mesos預設的Executor就能夠實現這個功能。如果你需要在Executor裡面做很多自己定製化的工作，則需要自己寫Executor。

 

寫一個Executor需要實現一些介面，最重要的就是launchTask介面，然後MesosExecutorDriver將這個Executor執行起來。

 

就像Framework一樣，Executor也是通過protocol buffer協議和Mesos-Agent進行溝通，通過MesosExecutorDriver，你不需要關心協議的事情，僅僅需要實現介面即可。

 

下面的圖描述了DC/OS的部署架構圖：

在DC/OS看來，所有的節點分為三個區域，一個是管理區域，主要處理對於服務的管理方面的操作，如增刪查改，啟停擴縮等。為了高可用，Master節點可以是多個，在多個Master節點之前，需要有一個負載均衡器。第二個是對外服務區域，也即外界能夠訪問DC/OS內部的服務的區域，這個區域裡面的服務多為對外的Nginx之類的，也會有marathon-lb來做外部的負載均衡器，所有對外服務區域的節點之外還需要一個負載均衡器。第三個區域是內部服務區域，用於部署內部服務，如資料庫，訊息匯流排等，這些內部節點不能對外訪問。

 

第一、Admin Router

AdminRouter是一個反向代理，正是它將對外的區域和對內的區域完全隔離開來，在admin router之外，可以通過公網訪問，在admin router之內全部是私網地址，這樣提供了安全的統一訪問機制。

 

安裝完畢Open DC/OS之後，安裝一個dcos的命令列工具，通過這個工具可以ssh到master的節點上。

1. eval `ssh-agent -s`
2. ssh-add .ssh/aws01.pem
3. dcos node ssh --master-proxy --leader

在這個節點上/etc/systemd/system路徑下面有三個systemd的service，Open DC/OS的所有元件都是用systemd進行管理的。

1. ip-10-0-7-1 system # ls -l | grep adminrouter
2. lrwxrwxrwx. 1 root root 135 Oct 3 08:00 dcos-adminrouter-reload.service -> /opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/dcos.target.wants_master/dcos-adminrouter-reload.service
3. lrwxrwxrwx. 1 root root 133 Oct 3 08:00 dcos-adminrouter-reload.timer -> /opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/dcos.target.wants_master/dcos-adminrouter-reload.timer
4. lrwxrwxrwx. 1 root root 128 Oct 3 08:00 dcos-adminrouter.service -> /opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/dcos.target.wants_master/dcos-adminrouter.service

可以看到dcos-adminrouter.service是指向/opt/mesosphere/packages下面的一個路徑，Open DC/OS的所有元件都是安裝在這個路徑下面的。

 

在/opt/mesosphere/packages/adminrouter--cee9a2abb16c28d1ca6c74af1aff6bc4aac3f134/nginx/conf這個路徑下面，有一個檔案nginx.master.conf，開啟這個檔案，就能看到熟悉的對於nginx的配置。

1. upstream mesos {
2.     server leader.mesos:5050;
3. }
4.  
5. upstream marathon {
6.     server master.mesos:8080;
7. }
8.  
9. location /mesos/ {
10.     access_by_lua 'auth.validate_jwt_or_exit()';
11.     proxy_set_header Host $http_host;
12.     proxy_pass http://mesos/;
13. }
14.  
15. location /marathon/ {
16.     # Enforce access restriction. Auth-wise, treat /marathon*
17.     # equivalently to /service/marathon*.
18.     access_by_lua 'auth.validate_jwt_or_exit()';
19.     proxy_set_header Host $http_host;
20.     proxy_pass http://marathon/;
21. }

從這個配置檔案可以看出，所有對內的訪問marathon的頁面，訪問mesos的頁面，都是通過leader.mesos進行，這個域名是mesos-dns給出的，對應的是內部的IP地址，如果從外部訪問marathon或者mesos的頁面，則必須通過admin router，通過http://admin-router-external-ip/marathon或者http://admin-router-external-ip/mesos來訪問。

 

第二、Mesos-DNS

對於資料中心作業系統來講，服務發現和負載均衡是最最核心的功能，只有有了這些功能，才能使得服務的物理佈局，服務之間的依賴關係，服務掛掉之後的自動修復不需要使用者關心，才能使得使用者像用一臺電腦一樣使用整個資料中心。

如果服務之間的相互呼叫不使用IP地址，而使用域名的話，問題會簡單很多。

如圖所示，對於Mesos上執行的每一個Task，Mesos-DNS都可以通過呼叫Mesos-Master的API得到，並且為每個Task分配一個域名和IP的對應項。如果一個Task需要訪問另一個Task，則需要配置域名即可，無論Task如何掛掉，如何分配到其他的節點上執行，域名都不會變，當然Task的IP可能會變，但是不用擔心，Mesos-DNS會更新它。每個Mesos-Agent只需要配置/etc/resolv.conf指向mesos-dns就可以了。

 

當一個Task執行的時候，Mesos-DNS會建立一個域名<task>.<service>.mesos對應：

• Mesos-Agent的IP地址
• 如果是Mesos Containerizer的話，返回的是Task內部容器的IP

 

另外<task>.<service>.slave.mesos還會提供所在的物理機的IP地址。這樣通過hostport和Mesos-DNS所給的域名，可以實現服務的發現。

 

第三：marathon-lb

 

使用DNS雖然可以實現服務的自發現，但是不容易實現服務的負載均衡和彈性伸縮，而marathon-lb實現了這些功能。

Marathon-lb是一個基於haproxy的負載均衡器，但是它會監聽marathon event bus，每當註冊到marathon-lb上的服務數目變化的時候，marathon-lb也會自動更新haproxy的配置檔案，從而實現負載均衡。Marathon-lb可以如圖中實現對外的負載均衡，也可以實現對內的服務之間相互呼叫的負載均衡。

 

Marathon的安裝可以在介面中universe裡面搜尋marathon-lb安裝，也可以通過命令列執行dcos package install Marathon-LB進行安裝，預設安裝的對外的負載均衡器。

 

我們在服務裡面建立如下的應用：

1. {
2.   "id": "nginx",
3.   "container": {
4.     "type": "DOCKER",
5.     "docker": {
6.       "image": "nginx:1.7.7",
7.       "network": "BRIDGE",
8.       "portMappings": [
9.         { "hostPort": 0, "containerPort": 80, "servicePort": 10000 }
10.       ],
11.       "forcePullImage":true
12.     }
13.   },
14.   "instances": 1,
15.   "cpus": 0.1,
16.   "mem": 65,
17.   "healthChecks": [{
18.       "protocol": "HTTP",
19.       "path": "/",
20.       "portIndex": 0,
21.       "timeoutSeconds": 10,
22.       "gracePeriodSeconds": 10,
23.       "intervalSeconds": 2,
24.       "maxConsecutiveFailures": 10
25.   }],
26.   "labels":{
27.     "HAPROXY_GROUP":"external"
28.   }
29. }

在這個應用裡面，servicePort為10000則說明我們註冊到marathon-lb上的外部埠為10000, labels裡面寫的是external，也即註冊到外部的負載均衡器上。

 

這個時候，我們訪問public slave上的10000埠，就能看到啟動的nginx的頁面http://54.254.148.129:10000/，內部其他的應用可以通過http://marathon-lb.marathon.mesos:10000來訪問這個nginx

如果我們訪問public slave上的haproxy的配置頁面http://54.254.148.129:9090/haproxy?stats，可以看到如下的對映關係。

對外marathon-lb監聽10000埠，對內對映為10.0.1.78上的20215埠，如果我們從服務頁面上檢視，的確啟動的nginx是監聽20215埠的。

 

接下來我們部署marathon-lb-autoscale，它監控haproxy，發現RPS(request per seconds)超過一定的數目，就對應用進行彈性擴充套件。

 

1. {
2.   "id": "marathon-lb-autoscale",
3.   "args":[
4.     "--marathon", "http://leader.mesos:8080",
5.     "--haproxy", "http://marathon-lb.marathon.mesos:9090",
6.     "--target-rps", "100",
7.     "--apps", "nginx_10000"
8.   ],
9.   "cpus": 0.1,
10.   "mem": 16.0,
11.   "instances": 1,
12.   "container": {
13.     "type": "DOCKER",
14.     "docker": {
15.       "image": "brndnmtthws/marathon-lb-autoscale",
16.       "network": "HOST",
17.       "forcePullImage": true
18.     }
19.   }
20. }

 

接下來，我們部署應用siege向nginx傳送請求

1. {
2.   "id": "siege",
3.   "args":[
4.     "-d1",
5.     "-r1000",
6.     "-c100",
7.     "http://marathon-lb.marathon.mesos:10000/"
8.   ],
9.   "cpus": 0.5,
10.   "mem": 16.0,
11.   "instances": 1,
12.   "container": {
13.     "type": "DOCKER",
14.     "volumes": [],
15.     "docker": {
16.       "image": "yokogawa/siege",
17.       "network": "HOST",
18.       "privileged": false,
19.       "parameters": [],
20.       "forcePullImage": false
21.     }
22.   }
23. }

 

如果我們看haproxy的stats頁面，發現已經有請求發過來了。這個時候我們增加siege到10，給nginx加壓。

過一段時間就會發現marathon-lb-autoscale已經有動作了。

將一個nginx變成8個nginx

 

當我們將siege從10個變回0個的時候。

 

第四、Minuteman

Minuteman是一個內部的東西向的負載均衡器，可用於設定VIP，多個例項使用同一個VIP來進行負載均衡。

在建立服務的時候，選擇Load Balanced，則下面會出現一行地址：nginxdocker.marathon.l4lb.thisdcos.directory:80，這個就是minuteman分配的VIP。

 

當服務建立好了之後，通過curl http://nginxdocker.marathon.l4lb.thisdcos.directory:80就可以訪問這個服務，但是我們如果ping這個域名卻是不通的，而且對於的IP地址也是很奇怪的IP地址，這個IP就是VIP.

 

這是怎麼做到的呢？minuteman的load balancer是基於Netfilter的，在dcos的slave節點上，我們能看到多出來了四個iptables規則。其中前兩個規則是在raw表裡面的，後兩個規則是在filter表裡面的。

1. -A PREROUTING -p tcp -m set --match-set minuteman dst,dst -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j NFQUEUE --queue-balance 50:58
2. -A OUTPUT -p tcp -m set --match-set minuteman dst,dst -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j NFQUEUE --queue-balance 50:58
3. -A FORWARD -p tcp -m set --match-set minuteman dst,dst -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
4. -A OUTPUT -p tcp -m set --match-set minuteman dst,dst -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable

根據iptbles的規則raw表中的規則會被先執行，一旦到達了filter表的minuteman的包就都過濾掉了。

NFQUEUE的規則表示將對於包的處理權交給使用者態的一個程式。--queue-balance表示會將包發給幾個queue，然後使用者態程式會使用libnetfilter_queue連線到這些queue中，將包讀出來，根據包的內容做決策後放回核心進行傳送。

 

在每一個Mesos-Agent節點上都執行這一個minuteman的程式，監聽這些queue，我們可以通過訪問API檢視VIP的對映關係，curl http://localhost:61421/vips。

 

我們可以看到VIP的11.112.175.214後面跟著兩個節點10.0.1.78:27003和10.0.1.78:4989，正好對應nginx的兩個例項。

 

DC/OS是基於Mesos的，Mesos的靈活框架機制可以使得DC/OS既能夠部署容器，也能夠部署大資料框架，大資料框架在不執行任務的時候，幾乎不佔用資源，從而真正實現微服務和大資料框架的資源共享。

前面我們部署容器的時候，都是自己準備marathon的json進行部署的，這就需要使用服務的人和設計服務的人同樣的專業。

DC/OS採用了一種package管理機制，將執行一個微服務或者框架所需要的各種配置製作成模板，模板由專業人士製作好上傳到package repository，使用者就不需要那麼專業，只要執行dcos package install安裝即可。

 

Mesosphere提供了官方的package repository，名為universe，地址為https://universe.mesosphere.com/repo，在github上可以找到對應的程式碼https://github.com/mesosphere/universe。

 

 

對於一個package，往往包含下面的部分：

• package.json：這裡面儲存了一些metadata的資料，例如對於spark

1. "name": "spark",
2. "description": "Spark is a fast and general cluster computing system for Big Data. Documentation: https://docs.mesosphere.com/current/usage/service-guides/spark/",
3. "licenses": [
4.     {
5.         "name": "Apache License Version 2.0",
6.         "url": "https://raw.githubusercontent.com/apache/spark/master/LICENSE"
7.     }
8. ],
9. "tags": [
10.     "bigdata",
11.     "mapreduce",
12.     "batch",
13.     "analytics"
14. ],

• config.json：儲存一些配置項，例如對於spark

1. "name": {
2.     "default": "spark",
3.     "description": "The Spark Dispatcher will register with Mesos with this as a framework name. This service will be available at http://<dcos_url>/service/<name>/",
4.     "type": "string"
5. },
6. "cpus": {
7.     "default": 1,
8.     "description": "CPU shares",
9.     "minimum": 0.0,
10.     "type": "number"
11. },
12. "mem": {
13.     "default": 1024.0,
14.     "description": "Memory (MB)",
15.     "minimum": 1024.0,
16.     "type": "number"
17. },
18. "role": {
19.     "description": "The Spark Dispatcher will register with Mesos with this role.",
20.     "type": "string",
21.     "default": "*"
22. },

• marathon.json.mustache：是一個模板，裡面的一些變數會替換為config.json裡面的內容，最終變成可以直接傳送給marathon的請求。以spark為例

1. "id": "{{service.name}}",
2. "cpus": {{service.cpus}},
3. "mem": {{service.mem}},
4. "container": {
5.     "type": "DOCKER",
6.     "docker": {
7.         "image": "{{resource.assets.container.docker.spark_docker}}",
8.         "network": "HOST",
9.         "forcePullImage": true
10.     }
11. },

• resource.json：是一些資源，如image，tar.gz檔案等

1. "assets": {
2.     "container": {
3.         "docker": {
4.             "spark_docker": "mesosphere/spark:1.0.2-2.0.0"
5.         }
6.     }
7. },

所有的這些配置都像模板一樣已經預先寫好，安裝的時候介面上一點，或者一行命令就安裝好了。

當然你如果點選Advanced Installation，則所有的配置都可以定製化

 

就像yum裡面一樣，將mysql-server的yum包的製作者和mysql的使用者分開，普通使用者作為使用者，不需要了解太多的細節，用就是了。

 

如果想在資料中心裡面使用package管理，可以生成自己的local universe，裡面放入自己的應用，只要專業人士設計一次，便可以多次使用。也可以一次安裝多個軟體形成一個group，裡面包含微服務的，也包含大資料的，兩者可以通過服務發現相互訪問。

 

我們在這裡先安裝一個spark的軟體

 

最初安裝完畢spark，卻發現只有一個docker

Spark不是一個叢集計算框架嗎，怎麼會只有一個Docker呢？這就是mesos對大資料框架管理的特殊之處。在spark不執行任務的時候，就僅僅佔用這一個docker，其實是一個框架。

安裝過程如圖所示：

1. dcos package install spark會將請求提交給admin router
2. admin router會將請求提交給cosmos，也即package管理的服務
3. cosmos將config.json, resource.json, marathon.json組合成為一個marathon請求提交給marathon
4. marathon將請求交給mesos-master，然後交給mesos-agent
5. mesos-agent啟動一個容器執行spark
6. 啟動的spark容器會註冊到mesos裡面成為一個新的framework

 

真正執行spark任務的時候，才會有其他佔用資源的任務被建立出來。

1. dcos spark run --submit-args='-Dspark.mesos.coarse=true --driver-cores 1 --driver-memory 1024M --class org.apache.spark.examples.SparkPi https://downloads.mesosphere.com/spark/assets/spark-examples_2.10-1.4.0-SNAPSHOT.jar 30'

 

 

Spark執行過程如圖：

1. dcos spark run將任務提交給admin router
2. admin router將任務提交給spark framework
3. spark framework將任務提交給mesos-master
4. mesos-master將任務分發給mesos-agent進行分別處理
5. 任務執行完畢後，所有mesos-agent上佔用的資源又都釋放了。

 

正是這種模式，才實現微服務和大資料框架的共享資源，與此相對應的是使用Docker來部署spark叢集，然後叢集自管理，不歸mesos管理。這樣在建立spark叢集的時候，就需要指定spark worker佔用的資源，比如16G，然而這16G資源則無論spark是否在計算，都會被佔用，都不會被其他的框架使用。

 

對於最新的DC/OS 1.8，有一個部落格https://dcos.io/blog/2016/introducing-dc-os-1-8-ga/index.html描述了最新的功能。

 

其中第一個重要的功能為Mesos 1.0 and the Universal Container Runtime，也即可以使用mesos-containerizer來執行Docker的映象了。這也是DC/OS對於容器的管理越來越獨立的體現。

 

我們在mesos-agent所在的機器上可以檢視

1. ip-10-0-1-78 dcos.target.wants_slave # ps aux | grep mesos-agent
2. root 1824 0.6 0.3 1069204 46948 ? Ssl Oct03 9:57 /opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004/bin/mesos-agent

mesos-agent的配置在路徑/opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004下面，在/opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004/dcos.target.wants_slave/dcos-mesos-slave.service裡面是mesos-slave的啟動引數的設定，通過mesos的文件，我們知道對於mesos的引數可以使用環境變數進行設定。

1. ip-10-0-1-78 dcos.target.wants_slave # cat dcos-mesos-slave.service
2. [Unit]
3. Description=Mesos Agent: DC/OS Mesos Agent Service
4.  
5. [Service]
6. Restart=always
7. StartLimitInterval=0
8. RestartSec=5
9. KillMode=control-group
10. Delegate=true
11. LimitNOFILE=infinity
12. TasksMax=infinity
13. EnvironmentFile=/opt/mesosphere/environment
14. EnvironmentFile=/opt/mesosphere/etc/mesos-slave-common
15. EnvironmentFile=/opt/mesosphere/etc/mesos-slave
16. EnvironmentFile=/opt/mesosphere/etc/proxy.env
17. EnvironmentFile=-/opt/mesosphere/etc/mesos-slave-common-extras
18. EnvironmentFile=-/var/lib/dcos/mesos-slave-common
19. EnvironmentFile=-/var/lib/dcos/mesos-resources
20. EnvironmentFile=-/run/dcos/etc/mesos-slave
21. ExecStartPre=/bin/ping -c1 ready.spartan
22. ExecStartPre=/bin/ping -c1 leader.mesos
23. ExecStartPre=/opt/mesosphere/bin/bootstrap dcos-mesos-slave
24. ExecStartPre=/opt/mesosphere/bin/make_disk_resources.py /var/lib/dcos/mesos-resources
25. ExecStartPre=/bin/bash -c 'for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 2 > $i; echo -n "$i: "; cat $i; done'
26. ExecStart=/opt/mesosphere/packages/mesos--19a545facb66e57dfe2bb905a001a58b7eaf6004/bin/mesos-agent

 

在檔案/opt/mesosphere/etc/mesos-slave-common中配置了大量的mesos-agent的引數

1. MESOS_MASTER=zk://zk-1.zk:2181,zk-2.zk:2181,zk-3.zk:2181,zk-4.zk:2181,zk-5.zk:2181/mesos
2. MESOS_CONTAINERIZERS=docker,mesos
3. MESOS_LOG_DIR=/var/log/mesos
4. MESOS_MODULES_DIR=/opt/mesosphere/etc/mesos-slave-modules
5. MESOS_CONTAINER_LOGGER=org_apache_mesos_LogrotateContainerLogger
6. MESOS_ISOLATION=cgroups/cpu,cgroups/mem,disk/du,network/cni,filesystem/linux,docker/runtime,docker/volume
7. MESOS_DOCKER_VOLUME_CHECKPOINT_DIR=/var/lib/mesos/isolators/docker/volume
8. MESOS_IMAGE_PROVIDERS=docker
9. MESOS_NETWORK_CNI_CONFIG_DIR=/opt/mesosphere/etc/dcos/network/cni
10. MESOS_NETWORK_CNI_PLUGINS_DIR=/opt/mesosphere/active/cni/
11. MESOS_WORK_DIR=/var/lib/mesos/slave
12. MESOS_SLAVE_SUBSYSTEMS=cpu,memory
13. MESOS_EXECUTOR_ENVIRONMENT_VARIABLES=file:///opt/mesosphere/etc/mesos-executor-environment.json
14. MESOS_EXECUTOR_REGISTRATION_TIMEOUT=10mins
15. MESOS_CGROUPS_ENABLE_CFS=true
16. MESOS_CGROUPS_LIMIT_SWAP=false
17. MESOS_DOCKER_REMOVE_DELAY=1hrs
18. MESOS_DOCKER_STOP_TIMEOUT=20secs
19. MESOS_DOCKER_STORE_DIR=/var/lib/mesos/slave/store/docker
20. MESOS_GC_DELAY=2days
21. MESOS_HOSTNAME_LOOKUP=false
22. GLOG_drop_log_memory=false

預設的mesos-containerizer的隔離只包括cpu和memory，然而在最新的mesos版本里面，多了provisioner這一層，在上面的配置裡面隔離了MESOS_ISOLATION=cgroups/cpu,cgroups/mem,disk/du,network/cni,filesystem/linux,docker/runtime,docker/volume，從而可以啟動docker的映象了。

 

第二個最重要的功能是CNI, container network interface。

 

 

CNI要工作需要三部分：

首先DC/OS不需要外接的IPAM，而是由mesos-master的replicated_log負責管理分配IP地址，Mesos需要啟動的時候，載入overlay network的modules。

在路徑/opt/mesosphere/etc/mesos-slave-modules下面有檔案overlay_slave_modules.json

1. ip-10-0-1-78 mesos-slave-modules # cat overlay_slave_modules.json
2. {
3.   "libraries":
4.   [
5.     {
6.       "file": "/opt/mesosphere/active/mesos-overlay-modules/lib/mesos/libmesos_network_overlay.so",
7.       "modules":
8.         [
9.           {
10.             "name": "com_mesosphere_mesos_OverlayAgentManager",
11.             "parameters" :
12.               [
13.                 {
14.                   "key": "agent_config",
15.                   "value" : "/opt/mesosphere/etc/overlay/config/agent.json"
16.                 }
17.               ]
18.           }
19.         ]
20.      }
21.   ]
22. }

其次需要載入CNI isolator，這個在MESOS_ISOLATION這個環境變數裡面已經配置了。

最後還需要navstar服務來實現跨節點之間的IP互訪問

每個mesos-agent的機器上都有opt/mesosphere/packages/navstar--589afdaef03114a17576ee648ae433a052f7a4b9/，都會執行一個navstar程式。

每個機器上都會建立網路卡d-dcos，如果Docker容器使用CNI獲取IP的容器都Attach到這個網路卡上，而非docker0上。

每個機器上都會建立網路卡m-dcos，如果mesos容器使用CNI獲取IP的容器都Attach到這個網路卡上。

每臺機器的d-dcos和m-dcos的網段都不同。

每臺機器都會建立一個vtep1024的網路卡，作為VTEP，背後是vxlan。

每臺機器都會建立預設的路由表，從本節點連線到其他的節點預設走vtep1024這個網路卡。

1. 9.0.0.0/24 via 44.128.0.1 dev vtep1024
2. 9.0.1.0/24 via 44.128.0.2 dev vtep1024
3. 9.0.3.0/24 via 44.128.0.4 dev vtep1024

對DC/OS的網路的配置在/opt/mesosphere/etc/dcos/network/cni路徑下

 

為了試驗這兩個新的功能，我們首先建立一個使用CNI的Mesos容器，但是啟動的是Docker的Image nginx

1. {
2.    "id":"nginxmesos",
3.    "cmd":"env; ip -o addr; sleep 3600",
4.    "cpus":0.10,
5.    "mem":512,
6.    "instances":1,
7.    "ipAddress":{
8.       "networkName":"dcos"
9.    },
10.    "container":{
11.       "type":"MESOS",
12.       "docker":{
13.          "network":"USER",
14.          "image":"nginx",
15.          "portMappings":[
16.             {
17.                 "host_port": 0,
18.                 "container_port": 80,
19.                 "protocol": "tcp"
20.             }
21.          ]
22.       }
23.    }
24. }

在日誌裡面，列印出來容器的IP地址是m-dcos網段的。

 

然後我們再啟動一個使用CNI的Docker容器

1. {
2.    "id":"nginxmesos1",
3.    "cmd":"env; ip -o addr; sleep 3600",
4.    "cpus":0.10,
5.    "mem":512,
6.    "instances":1,
7.    "ipAddress":{
8.       "networkName":"dcos"
9.    },
10.    "container":{
11.       "type":"DOCKER",
12.       "docker":{
13.          "network":"USER",
14.          "image":"nginx",
15.          "portMappings":[
16.             {
17.                 "host_port": 0,
18.                 "container_port": 80,
19.                 "protocol": "tcp"
20.             }
21.          ]
22.       }
23.    }
24. }

從日誌我們看出，配置的IP是d-dcos網段的，而非docker0網段的。

 

從Mesos上我們看出這兩個容器是在兩個節點上的

 

登入Docker的容器，ping另外一個CNI的mesos的IP是沒有問題的。

1. ip-10-0-1-78 cni # docker ps
2. CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3. e7908deb3017 nginx "/bin/sh -c 'env; ip " 28 minutes ago Up 28 minutes 80/tcp, 443/tcp mesos-b3fbe6d9-236a-4856-a986-9babbba9c02c-S2.e3c96fa7-b5ff-4af6-9099-bbed399c7c37
4. a992929fb0d1 nginx "nginx -g 'daemon off" 6 hours ago Up 6 hours 443/tcp, 0.0.0.0:4989->80/tcp mesos-b3fbe6d9-236a-4856-a986-9babbba9c02c-S2.fca41f8d-816c-49cd-9b19-ba059b95e885
5. 8032756dd66e nginx "nginx -g 'daemon off" 6 hours ago Up 6 hours 443/tcp, 0.0.0.0:27003->80/tcp mesos-b3fbe6d9-236a-4856-a986-9babbba9c02c-S2.c0fdd3db-6f17-41d3-ab05-6f2d4d0bfa13
6. ip-10-0-1-78 cni # docker exec -it e7908deb3017 bash
7. root@e7908deb3017:/# ip addr
8. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
9.     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
10.     inet 127.0.0.1/8 scope host lo
11.        valid_lft forever preferred_lft forever
12.     inet6 ::1/128 scope host
13.        valid_lft forever preferred_lft forever
14. 51: eth0@if52: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1420 qdisc noqueue state UP group default
15.     link/ether 02:42:09:00:03:82 brd ff:ff:ff:ff:ff:ff
16.     inet 9.0.3.130/25 scope global eth0
17.        valid_lft forever preferred_lft forever
18.     inet6 fe80::42:9ff:fe00:382/64 scope link
19.        valid_lft forever preferred_lft forever
20. root@e7908deb3017:/# ping 9.0.2.13
21. PING 9.0.2.13 (9.0.2.13): 56 data bytes
22. 64 bytes from 9.0.2.13: icmp_seq=0 ttl=62 time=0.709 ms
23. 64 bytes from 9.0.2.13: icmp_seq=1 ttl=62 time=0.535 ms

【參考資料】

1、DC/OS首頁、文件和下載 - 資料中心作業系統 - 開源中國社群 http://www.oschina.net/p/dcos

2、DC/OS很難理解嗎？ http://geek.csdn.net/news/detail/190111

3、DC/OS、電信行業、亞信_【VerisOS】 http://www.a-site.cn/article/300140.html

4、科學網—如何搭建DC/OS系統的框架私有伺服器 - 李銘軒的博文 http://blog.sciencenet.cn/blog-50618-1008633.html

5、彈性服務平臺DC/OS—概覽 https://baijiahao.baidu.com/s?id=1567763885994830

6、DCOS領域誕生一個100%開源的企業級Data Open DC/OS前世今生 -http://www.010lm.com/redian/2016/0430/1819984.html

7、深入解析DC/OS 1.8 – 高可靠的微服務及大資料管理平臺 - popsuper1982 - 部落格園 http://www.cnblogs.com/popsuper1982/p/5930827.html