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