Mesos在Qunar的應用
大家好，我是來自Qunar OpsDev團隊的工程師徐磊。今天與大家分享下Mesos在我們團隊內部的應用。
我們是在今年的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這塊，我們使用了兩個框架：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：持久化剝離在集群外部，Mesos0.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：本地容器是啥。。。我沒太理解這個含義
Q：做這么個平臺用多大規模的團隊開發的？用了多久？
A：開始2個人，最多的時候5個人，現在保持在4個人。從5月份到現在一點一點測試，擴容慢慢堆出來的。
Q：鏡像存儲單機應該是不行的，你們是怎么管理鏡像的？
A：鏡像放swift里了
Q：docker采用host方式，是什么考慮或者限制，效果怎么樣
A：平臺本身就是大吞吐量的，bridge模式性能測試都偏低，就選擇了host模式跑了。
Q：mesos的調度算法是怎樣的？有沒有做容器的高可用？
A：雙層調度，底層offer一個資源列表給framework，framework根據cpu和mem去列表中過濾，選中合適的slave部署，framework層的調度可以隨意實現。Marathon已經幫忙做了高可用。
Q：如何在mesos棧的各級上實現容錯和資源的分配？
A：沒太明白問題，能在詳細點描述么？
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值得試一下。