去哪兒網OPS基于Mesos/Docker構建的Elasticsearch容器化私有云

作者：馬文

【編者的話】本次分享主要介紹一下去哪兒網 OPS 團隊利用 Mesos 資源管理平臺和 Docker 容器技術所構建的 Elasticsearch 容器化的私有云。主要有四個部分， 第一個部分主要介紹一個我們當初做這個平臺的背景，和現(xiàn)在的規(guī)模和現(xiàn)狀，第二個部分主要簡單介紹一下整個平臺的技術實現(xiàn)，最后分享是持續(xù)構建方面的工作以及監(jiān)控和報警相關方面的工作。

背景與現(xiàn)狀

2015年底到2016年初的這段時間，公司業(yè)務線對 ES 的需求量暴增，傳統(tǒng)的使用 ES 的方式逐漸顯現(xiàn)出一些弊端，主要有一下幾點的內容：

針對上述所列的幾點弊端，我們最初制定的幾點設計目標如下：

最終，為了達到這幾點目標，我們就設計和開發(fā)了這個平臺。

自從16年3、4月份這個平臺上線以來，工作效率得到了很大改進，主要有以下三個方面：

下面這個圖是統(tǒng)計的過去傳統(tǒng)的使用方式與現(xiàn)在的平臺的方式使用 ES 所帶來的資源利用率的提升：

這個是我們目前的平臺規(guī)模：

整個平臺支持了很多重要系統(tǒng)后端的數據存儲，比如：

技術實現(xiàn)

剛開始做這個平臺的時候，我們主要調研參考了以下三個系統(tǒng)和平臺：

第一個 Elastic Cloud 是 Elastic 官方提供的一個公有云的服務，他能夠提供快速集群構建的能力，也具備自助化配置，快速擴容能力，比較符合我們的預期功能。第二個 Amazon Elasticsearch Service 同樣也是一個公有云服務，能夠提供快速的集群構建能力，自助化配置等等，同樣也為我們提供了極大的參考價值。第三個是一個開源的基于 Mesos 的一個調度框架，他的設計是一個 Framework 代表一個 ES 集群，F(xiàn)ramework 的每一個 Executor 代表一個 ES 節(jié)點，但是也有許多不支持，包括不支持多種角色節(jié)點的配置，不支持自助化的配置，不支持插件的安裝，這與我們的設計初衷是相違背的。結合了上述三個例子，我們設計指定了我們自己的技術方案。

整個平臺基于 Mesos，所有組件以 Docker 容器的形式被 Marathon 調度跑起來，這個是一個整體的結構圖：

我們底層所有的機器都是被同一個 Mesos 來進行統(tǒng)一管理的，Mesos 之上運行著 Marathon 調度框架，值得注意的是，我們有兩層的 Marathon，底層比較大的 Marathon 我們稱之為 Root Marathon，上層包含在 Root Marathon 之中的小的 Marathon 我們稱之為 Sub Marathon，Root Marathon 只負責調度內層的Sub Marathon，內存的 Sub Marathon 才是真正承載著我們每一個 Es Saas 服務。我們所有的組件都是跑在 Docker 容器里面的。

那么我們平臺的資源是怎么分配的呢，這個圖是一個分配的結構圖，可以看到資源是按照 Marathon 分層的這種方式來分配的，Root Marathon 擁有系統(tǒng)所有的資源，Sub Marathon 是資源分配的最小單位，每一個都有它既定的資源，資源結構如此，當然集群間的邏輯隔離也是如此。

Sub Marathon 不僅有他自己的資源，而且我們將它和業(yè)務線做了一一映射，也就是說一個Sub Marathon 唯一的代表一個業(yè)務線，同時它也是承載了業(yè)務線的所有集群。

下面這個圖展示的是 Sub Marathon 內部細節(jié)的結構圖：

一個 Sub Marathon 可以承載多個 ES 集群，每一個 ES 集群有4個重要的組件，分別是：Bamboo，es-master，es-datanode，es2graphite，這4個組件是組成 ES 集群的基礎，他們分別對應著一個 Marathon 的 APP，APP 的 task 是真正的 ES 節(jié)點。 下面這個圖展示了上述4種基礎組件之間的關系：

默認的 ES 有3個 master 節(jié)點和3個 datanode 節(jié)點，他們分為兩個 Marathon APP 獨立運行，他們之間互相的服務發(fā)現(xiàn)是由 Bamboo + HAProxy 這個組件來完成的，這樣他們才能連成一個集群，es2graphite 負責收集 ES 集群指標，它的原理就是調用 ES 內部的接口獲取指標，然后聚合打到后端的 Graphite 上分析展示。pyadvisor 這個組件不是存在每一個集群中的，而是 run 在每一個 mesos slave 上的一個服務，他們負責收集容器維度的指標，聚合之后打到后端 Graphite 上實時展示，下面就是一個具體的 slave 機器上的快照：

每個機器上可以跑多個 ES 節(jié)點，不同的 ES 節(jié)點之間使用端口號來區(qū)別。

在每一個 ES 集群中，起著至關重要作用的就是服務發(fā)現(xiàn)，而這個服務發(fā)現(xiàn)是由 Bamboo + HAProxy 這個組件來完成的。

Bamboo 是一個開源的跑在 Marathon 之上服務發(fā)現(xiàn)的工具，它的原理就是注冊了 Marathon 的 callback 接口接受 Marathon 事件消息時時解析并 reload haproxy。

ES 集群內部服務發(fā)現(xiàn)的配置其實只是用了一句圖中的配置項，這個配置項是 ES 的單播地址，是告訴 ES 節(jié)點去哪個機器的哪個端口找 master 的，我們只是簡單的把他替換成了 Haproxy 的 host 和 port。ES 節(jié)點在起來的時候，Bamboo 檢測到啟動事件，隨即通過 Marathon API 獲取到真實的 Master 的 host 和 port，然后 Reload Haproxy 建立端口轉發(fā)關系，同時，ES Datanode 節(jié)點在起來的時候，就會通過 Haproxy 的前端 host 和 port 經轉發(fā)到真實的 Master 地址上，由此實現(xiàn)了服務發(fā)現(xiàn)的過程。三個 Master 之間也是同樣的道理，他們通過 Haproxy 再“回連”自己。

在數據持久化和可靠性方面我們做了一下幾個方面的工作：

配置和部署

接下來介紹一下我們做的自助配置和持續(xù)構建方面的工作，有關所有的 ES 的配置我們都存在了 GitLab 中，包括一個特殊的 pre-run 文件，這個文件定義了在我們啟動 ES 節(jié)點實例之前我們該做些什么，這個文件是可以修改的，可以由業(yè)務線同學自定義。同時一些其他的配置文件也是存在 GitLab 上的，修改之后，只需要重啟容器即可生效。

同時我們在自助管理方面也做了一些工作，下圖是我們自己做的一個 Web 系統(tǒng)， 用來展示詳細的集群信息和做一些自助化配置方面的工作。

在新集群交付的時候，我們也是直接交付這個 Web 頁面，業(yè)務線同學可以很方便的查到信息，也可以很方便的做一些操作。說到交付，我們在持續(xù)構建方面也做了一些工作。

這個是新的 ES 集群從配置到部署到上線的整個過程，都是基于 Jenkins 來做的，一共有三步，第一步是配置的初始化，這一步中會生成部署過程中所有的配置文件，生成之后直接存儲到 GitLab 中，到了第二步集群部署的時候，我們會按照順序讀取配置，一一的將各個組件提交到 Marathon，最后一步就是 Marathon 調度運行，等全部完成之后，我們一個完整的 ES 集群也就 work 了。

監(jiān)控與報警

最后一部分說一下監(jiān)控和報警，監(jiān)控指標的收集，主要有兩個方式：

下面是指標聚合之后的一個示例：

關于報警，主要有一下幾個方面：

最后，用一張圖來總結一下所有的內容：

從 ES 的建立到銷毀，我們做到了 ES 集群整個生命周期的管理，建立初我們會做容量預估和參數的配置，等到部署的時候，我們有持續(xù)構建部署的工具來做，服務上線之后我們提供了可以自助配置，自助插件的 web 工具，極大的方便了開發(fā)人員，同時也有完備的監(jiān)控和報警。集群下線的時候，統(tǒng)一的回收資源，做一些清理拓補的工作。

生成海報

免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現(xiàn)的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。