Mesos在去哪兒網的應用

Mesos在Qunar DevOps團隊內部的應用。

平臺介紹

我們是在今年的5月份開始調研并嘗試使用Mesos，第一個試點就是我們的日志平臺，我們將日志分析全部托管在Mesos平臺上。日志平臺面向業務線開發、測試、運營人員，方便定位、追溯線上問題和運營報表。

這個是我們平臺的結構概覽。

日志分析我們使用ELK（Elasticsearch、Logstash、Kibana），這三個應該說是目前非常常見的工具了。而且方案成熟， 文檔豐富，社區活躍（以上幾點可以作為開源選型的重要參考點）。稍微定制了下Kibana和Logstash，主要是為了接入公司的監控和認證體系。

日志的入口有很多，如kernel、mail、cron、dmesg等日志通過rsyslog收集。業務日志通過flume收集，容器日志則使用mozilla的heka和fluentd收集。

這里稍稍給heka和fluentd打個廣告，兩者配合收集Mesos平臺內的容器日志非常方便，可以直接利用MESOS_TASK_ID區分容器（此環境變量由Mesos啟動容器時注入）。而且我們也有打算用heka替換logstash。

Mesos技術棧

下面主要分享一下Mesos這塊，我們使用了兩個框架：Marathon和Chronos，另外自己開發了一個監控框架Universe。

先說Marathon，eventSubscriptions是個好功能，通過它的httpcallback可以有很多玩法，群里經常提到的bamboo就是利用這個功能做的。利用好這個功能，做容器監控就非常簡單了。

接著是Marathon的重啟（更新），推薦設置一下minimumHealthCapacity，這樣可以減少重啟（更新）時的資源占用，防止同時PUT多個應用時耗光集群資源。

服務發現，Marathon提供了servicerouter.py導出haproxy配置，或者是bamboo，但是我們現在沒有使用這兩個。 而是按協議分成了兩部分，HTTP協議的服務是使用OpenResty開發了一個插件，動態加載Marathon（Mesos）內的應用信息，外部訪問的 時候proxy_pass到Mesos集群內的一個應用，支持upstream的配置。

非HTTP的應用，比如集群內部的statsd的UDP消息，我們就直接用Mesos DNS + 固定端口來做了。隨即端口的應用依賴entrypoint拉取域名+端口動態替換。

帶有UNIQUE attribute的應用，官方目前還無法做到自動擴容，從我們的使用情況來看，基于UNIQUE方式發布的應用全部是基礎服務，比如statsd、 heka（收集本機的Docker日志）、cAdvisor（監控容器）等，集群新加機器的時候Marathon不會自動scale UNIQUE實例的數量，這塊功能社區正在考慮加進去。我們自己寫了一個daemon，專門用來監控UNIQUE的服務，發現有新機器就自動scale， 省的自己上去點了。

另外一個問題，資源碎片化，Marathon只是個框架，關注點也不在這里。Mesos的UI里雖然有統計，但是很難反應真實的情況，于是我們就自己寫了 一個Mesos的框架，專門來計算資源碎片和真實的余量，模擬發布情況，這樣我們發布新應用或者擴容的時候，就知道集群內真實的資源余量能否支持本次發 布，這些數據會抄送一份給我們的監控/報警系統。Chronos我們主要是跑一些定時清理和監控的腳本。

Docker這塊，我們沒有做什么改動，網絡都使用host模式。Docker的監控和日志上面也提到了，我們用的是cAdvisor和heka，很好很強大，美中不足的是cAdvisor接入我們自己的監控系統要做定制。

我們也搗鼓了一個Docker SSH Proxy，可能是我們更習慣用虛擬機的緣故吧，有時候還是喜歡進入到容器里去干點啥的（其實業務線對這個需求更強烈），就是第一張圖里的octopus，模擬docker exec -it的工作原理，對接Mesos和Marathon抓取容器信息。這樣開發人員在自己機器上就能SSH到容器內部debug了，也省去了申請機器賬號的時間了。

應用方案

接著說說我們的日志平臺。這個平臺的日志解析部分全部跑在Mesos上，平臺自身與業務線整合度比較深，對接了一些內部系統，主要是為了考慮兼容性和業務線資源復用的問題，我盡量省略與內部系統關聯的部分，畢竟這塊不是通用性的。

平臺目前跑了有600+的容器，網絡是Docker自帶的host模式，每天給業務線處理51億+日志，延時控制在60～100ms以內。

最先遇到的問題是鏡像，是把鏡像做成代碼庫，還是一個運行環境？或者更極端點，做一個通用的base image？結合Logstash、heka、statsd等應用特點后，我們發現運行環境更適合，這些應用變化最大的經常是配置文件。所以我們先剝離配 置文件到GitLab，版本控制交給GitLab，鏡像啟動后再根據tag拉取。

另外，Logstash的監控比較少，能用的也就一個metrics filter，寫Ruby代碼調試不太方便。索性就直接改了Logstash源碼，加了一些監控項進去，主要是監控兩個Queue的狀態，順便也監控了下EPS和解析延時。

Kafka的partition lag統計跑在了Chronos上，配合我們每個機房專門用來引流的Logstash，監控業務線日志的流量變得輕松多了。

容器監控最開始是自己開發的，從Mesos的接口里獲取的數據，后來發現hostname：UNIQUE的應用Mesos經常取不到數據，就轉而使用 cAdvisor了，對于Mesos/Marathon發布的應用，cAdvisor需要通過libcontainer讀取容器的config.json 文件，獲取ENV列表，拿到MESOS_TASK_ID和MARATHON_APP_ID，根據這兩個值做聚合后再發到statsd里（上面提到的定制思 路）。

發布這塊我們圍繞這Jenkins做了一個串接。業務線的開發同學寫filter并提交到GitLab，打tag就發布了。發布的時候會根據集群 規劃替換input和output，并驗證配置，發布到線上。本地也提供了一個sandbox，模擬線上的環境給開發人員debug自己的filter 用。

同時發布過程中我們還會做一些小動作，比如Kibana索引的自動創建，Dashboard的導入導出，盡最大可能減少業務線配置Kibana的時間。每 個應用都會啟動獨立的Kibana實例，這樣不同業務線間的ACL也省略了，簡單粗暴，方便管理。沒人使用的時候自動回收Kibana容器，有訪問了再重 新發一個。

除了ELK，我們也在嘗試Storm on Mesos，感覺這個坑還挺多的，正在努力的趟坑中。掃清后再與大家一起交流。

今天的內容就到這里，感謝大家。

Q&A

Q：Mesos和Yarn的區別在哪里？

A：Mesos的主要目標就是去幫助管理不同框架（或者應用棧）間的集群資源。比如說，有一個業務需要在同一個物理集群上同時運 行Hadoop，Storm及Spark。這種情況下，現有的調度器是無法完成跨框架間的如此細粒度的資源共享的。Hadoop的YARN調度器是一個中 央調度器，它可以允許多個框架運行在一個集群里。但是，要使用框架特定的算法或者調度策略的話就變得很難了，因為多個框架間只有一種調度算法。比如 說，MPI使用的是組調度算法，而Spark用的是延遲調度。它們兩個同時運行在一個集群上會導致供求關系的沖突。還有一個辦法就是將集群物理拆分成多個 小的集群，然后將不同的框架獨立地運行在這些小集群上。再有一個方法就是為每個框架分配一組虛擬機。正如Regola和Ducom所說的，虛擬化被認為是 一個性能瓶頸，尤其是在高性能計算（HPC）系統中。這正是Mesos適合的場景——它允許用戶跨框架來管理集群資源。


Mesos是一個雙層調度器。在第一層中，Mesos將一定的資源提供（以容器的形式）給對應的框架。框架在第二層接收到資源后，會運行自己 的調度算法來將任務分配到Mesos所提供的這些資源上。和Hadoop YARN的這種中央調度器相比，或許它在集群資源使用方面并不是那么高效。但是它帶來了靈活性——比如說，多個框架實例可以運行在一個集群里。這是現有的 這些調度器都無法實現的。就算是Hadoop YARN也只是盡量爭取在同一個集群上支持類似MPI這樣的第三方框架而已。更重要的是，隨著新框架的誕生，比如說Samza最近就被LinkedIn開 源出來了——有了Mesos這些新框架可以試驗性地部署到現有的集群上，和其它的框架和平共處。

Q：基礎架構里面，數據持久化怎么做的？使用是么架構的存儲？

A：持久化剝離在集群外部，Mesos 0.23提供了持久化的支持，但是沒敢上到生產環境中。

Q：Storm on Mesos，快可用了嗎？是否跟Spark on Mesos做過比較？

A：Storm on Mesos的代碼在GitHub可以找到，說實話只是基礎功能，許多資源的控制和attributes的東西都沒有做，而且我們的測試發現storm on mesos的消息ack特別慢。不建議直接拿來就跑。

Q：發布用的業務鏡像是怎么制作的，平臺有相關功能支持嗎？還是用戶手工做好上傳？

A：Jenkins build的鏡像，可以用Jenkins on Mesos這個框架，安裝Docker和mesos插件就可以開始用了。

Q：做這么個平臺用多大規模的團隊開發的？用了多久？

A：開始2個人，最多的時候5個人，現在保持在4個人。從5月份到現在一點一點測試，擴容慢慢堆出來的。

Q：鏡像存儲單機應該是不行的，你們是怎么管理鏡像的？

A：鏡像放swift里了。

Q：Docker采用host方式，是什么考慮或者限制，效果怎么樣？

A：平臺本身就是大吞吐量的，bridge模式性能測試都偏低，就選擇了host模式跑了。

Q：Mesos的調度算法是怎樣的？有沒有做容器的高可用？

A：雙層調度，底層offer一個資源列表給framework，framework根據CPU和內存去列表中過濾，選中合適的slave部署，framework層的調度可以隨意實現。Marathon已經幫忙做了高可用。

Q：使用效果如何？600容器部在多少臺機器上，CPU和內存使用率多少？有什么提升資源使用率的策略嗎？

A：效果達到預想了，600臺分部在了混合集群上，有VM和實體機，全部折算的話大概30臺左右吧，目前資源還有富余，主要是預留buffer。不推薦跑虛擬機，Mesos的資源分配就是一刀切，即使沒用也算的，所以虛擬機利用率會很低。

Q：mesos在哪一層面實施了paxos投票？

A：leader的選舉，mesos其實是兩套選舉，即使zk掛了mesos master也可以自己選舉leader。

Q：為什么選擇heka，而不是fluend，然后logstash有什么問題？

A：fluent和heka我們都在用，都是收容器日志，heka可以從容器的ENV里讀更多東西出來。換logstash主要看重了heka的監控，資源占用和處理速度。

Q：會涉及數據卷的遷移嗎，有什么好解決方案？

A：目前平臺里沒有持久化的東西。這塊不敢說用什么合適，我們也沒開始嘗試。

Q：鏡像做成代碼庫和運行環境具體是什么意思，為什么運行環境方式合適？

A：鏡像具體做成什么樣要根據自己的應用來判斷，我們用的logstash、statsd什么的，都是配置文件描述流程的，所以我們選擇了運行環境的方式。

Q：鏡方式像做成代碼庫和運行環境具體是什么意思？

A：代碼庫就是說你把你工程的代碼，配置什么的都全部打成一個鏡像。 運行環境就是有一些bin或者Java、PHP這些工具的，啟動后才下載代碼，配置。

Q：你們會不會遇到跨機房的MesOS問題啊，如果跨機房，怎么辦？

A：有跨機房的情況，我們機房間有logstash專門轉發日志流量，統一管控。

Q：比如數據庫初始化的腳本，做在鏡像里合適還是有其他方式比較好？

A：db的數據文件其實挺難脫離外層的應用單獨說的，因為有業務線代碼引起的schema變更，最好先解決db ci的問題，然后再考慮數據何時加載，可以映射上對應schema的時候，db文件可以先從swift等共享存儲直接下載到本地使用，或者用腳本重新初始 化也可以，我們的快速rebuild環境正在試驗。業務線還不敢這么來。

Q：用運行環境方式，容器啟動后再拉代碼和配置，不符合Docker設計鏡像的初衷吧，怎么做到一處打包到處運行，鏡像不是完整可執行的？

A：主要是代碼庫版本和鏡像的tag如何映射，為了簡單點可以考慮啟動后下載代碼，如果代碼已經編譯好放到了共享存儲里直接下載代碼包也可以。我們目前沒有考慮過把代碼庫版本和鏡像tag映射這個問題。

Q：Mesos資源統計會出現與實際不符，你們的解決思路是什么？

A：要看是什么資源了，Mesos的劃資源的格子屬于一刀切的方式，即使你沒用滿也會被歸入已使用的資源里，如果從這個角度看， 實際運行的資源和Mesos內上報的資源確實不一致，但是考慮到計算資源的周期性，突發性，還是推薦以Mesos上報的資源為準。我們自己跑在Mesos 上的監控framework本身也是這么做的。

Q：cAdvisor好像只能監控單機容器情況，那對于集群的容器監控，使用ca怎么處理呢？

A：我們目前是cAdvisor聚合好以后發給我們的公司的監控平臺，由監控平臺統一處理。最新版已經merge了許多storage-driver了，statsd值得試一下。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上內容根據2015年9月15日晚微信群分享內容整理。分享人 徐磊，現任職于去哪兒網OpsDev團隊，曾任職于紅帽HSS部門。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。

來自：http://dockone.io/article/675