去哪兒網(wǎng)OPS基于Mesos/Docker構(gòu)建的Elasticsearch容器化私有云

作者：馬文

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

背景與現(xiàn)狀

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

針對(duì)上述所列的幾點(diǎn)弊端，我們最初制定的幾點(diǎn)設(shè)計(jì)目標(biāo)如下：

最終，為了達(dá)到這幾點(diǎn)目標(biāo)，我們就設(shè)計(jì)和開(kāi)發(fā)了這個(gè)平臺(tái)。

自從16年3、4月份這個(gè)平臺(tái)上線以來(lái)，工作效率得到了很大改進(jìn)，主要有以下三個(gè)方面：

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

這個(gè)是我們目前的平臺(tái)規(guī)模：

整個(gè)平臺(tái)支持了很多重要系統(tǒng)后端的數(shù)據(jù)存儲(chǔ)，比如：

技術(shù)實(shí)現(xiàn)

剛開(kāi)始做這個(gè)平臺(tái)的時(shí)候，我們主要調(diào)研參考了以下三個(gè)系統(tǒng)和平臺(tái)：

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

整個(gè)平臺(tái)基于 Mesos，所有組件以 Docker 容器的形式被 Marathon 調(diào)度跑起來(lái)，這個(gè)是一個(gè)整體的結(jié)構(gòu)圖：

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

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

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

下面這個(gè)圖展示的是 Sub Marathon 內(nèi)部細(xì)節(jié)的結(jié)構(gòu)圖：

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

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

每個(gè)機(jī)器上可以跑多個(gè) ES 節(jié)點(diǎn)，不同的 ES 節(jié)點(diǎn)之間使用端口號(hào)來(lái)區(qū)別。

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

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

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

在數(shù)據(jù)持久化和可靠性方面我們做了一下幾個(gè)方面的工作：

配置和部署

接下來(lái)介紹一下我們做的自助配置和持續(xù)構(gòu)建方面的工作，有關(guān)所有的 ES 的配置我們都存在了 GitLab 中，包括一個(gè)特殊的 pre-run 文件，這個(gè)文件定義了在我們啟動(dòng) ES 節(jié)點(diǎn)實(shí)例之前我們?cè)撟鲂┦裁?，這個(gè)文件是可以修改的，可以由業(yè)務(wù)線同學(xué)自定義。同時(shí)一些其他的配置文件也是存在 GitLab 上的，修改之后，只需要重啟容器即可生效。

同時(shí)我們?cè)谧灾芾矸矫嬉沧隽艘恍┕ぷ?，下圖是我們自己做的一個(gè) Web 系統(tǒng)， 用來(lái)展示詳細(xì)的集群信息和做一些自助化配置方面的工作。

在新集群交付的時(shí)候，我們也是直接交付這個(gè) Web 頁(yè)面，業(yè)務(wù)線同學(xué)可以很方便的查到信息，也可以很方便的做一些操作。說(shuō)到交付，我們?cè)诔掷m(xù)構(gòu)建方面也做了一些工作。

這個(gè)是新的 ES 集群從配置到部署到上線的整個(gè)過(guò)程，都是基于 Jenkins 來(lái)做的，一共有三步，第一步是配置的初始化，這一步中會(huì)生成部署過(guò)程中所有的配置文件，生成之后直接存儲(chǔ)到 GitLab 中，到了第二步集群部署的時(shí)候，我們會(huì)按照順序讀取配置，一一的將各個(gè)組件提交到 Marathon，最后一步就是 Marathon 調(diào)度運(yùn)行，等全部完成之后，我們一個(gè)完整的 ES 集群也就 work 了。

監(jiān)控與報(bào)警

最后一部分說(shuō)一下監(jiān)控和報(bào)警，監(jiān)控指標(biāo)的收集，主要有兩個(gè)方式：

下面是指標(biāo)聚合之后的一個(gè)示例：

關(guān)于報(bào)警，主要有一下幾個(gè)方面：

最后，用一張圖來(lái)總結(jié)一下所有的內(nèi)容：

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

生成海報(bào)

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