彈性整合Apache Mesos與Apache Kafka框架

weixin_33766168發表於2017-09-29
本文講的是彈性整合Apache Mesos與Apache Kafka框架【編者的話】本文由Mesosphere公司的Derrick Harries和Kafka專案程式碼提交者Joe Stein合作撰寫,介紹瞭如何將Mesos與Kafka整合以簡化海量流資料的管理和配置工作。

KafkaMesos是非常知名和成功的Apache專案,它們每個都獲得了大型社群的支援,還有ConfluentMesosphere這樣的公司各自圍著它們構築生態系統。最近,兩家公司合作使Kafka成為Mesosphere資料中心處理系統(DCOS)的首批認證服務。 

流資料無處不在並持續增長——監控公司IT基礎設施的應用程式產生的指標資料流、零售行業訂單和物流產生的資料流、物流網裝置產生的活動資料流、金融公司的股票行情自動收錄器產生的資料流等等。這些越來越需要可以大規模實時處理所有這些流資料的基礎設施平臺並使其可用於公司資料中心裡的各種應用程式。

鑑於Kafka獨特的實時移動大量資料的能力,使得它特別適合管理流資料,許多組織使用Kafka增強實時資料監測、分析、安全、欺詐檢測和流處理能力。Kafka在公司的資料中心整合各種系統時也起著關鍵作用。Apache Mesos抽象了資料中心資源,從而使其易於部署和管理分散式應用程式和系統。這篇文章介紹瞭如何在Mesos上執行Kafka叢集來簡化管理大規模流資料的任務。

Apache Kafka的快速概述:

A_QUICK_OVERVIEW_OF_APACHE_KAFKA.png

Kafka是一個分散式、高吞吐量、低延遲的釋出-訂閱型別的訊息系統。自從2011年開源以來,Kafka已經在業內得到了廣泛採用,比如在LinkedIn、Netflix、Uber這樣的網際網路公司還有像Cisco和高盛這樣的傳統行業公司。在這些公司中Kafka被用來構築關鍵資料的主幹管道,每天實時移動的訊息有數千億條之多。

Apache Mesos:一分鐘內0到60

Apache Mesos是一個叢集管理平臺,可以對分散式應用程式或者框架提供高效的資源隔離和共享功能,它位於應用程式層和作業系統之間,使得其易於在大規模叢集環境中有效部署和管理各種應用。

下圖是Mesos架構的快速概述,其由Masters、Slaves和框架組成。
APACHE_MESOS-_0_TO_60_IN_A_MINUTE.png

Mesos Master

Mesos Master負責處理Slave節點和框架間的資源通訊,在任何情況下都只能有一個Master作為領導在執行,在Master崩潰的情況下通常至少有一個備用機制來處理故障轉移(在代理模式下備用機制就是把資料傳輸到Master上)。Master負責為任務分配資源(在排程器和Slave節點之間),管理狀態還有維持高可用等等。

Mesos Slave

Mesos Slave在其服務執行節點啟動本地程式,這些程式是由執行器在Linux容器中啟動的,Linux容器是這些程式的父容器,除了容器自身的程式之外。

Mesos框架

框架接收來自Master提供的Slave節點的資源(比如CPU和記憶體),框架由以下兩個部分組成:
  1. 排程器
    排程器提供瞭如何管理框架內任務做什麼的基礎功能,其負責管理Slave節點執行成功和失敗間的狀態、任務失敗、內部應用程式配置和故障、對外通訊等等。
  2. 執行器
    執行器在伺服器上執行應用程式程式碼,在容器內部其他的程式也可以同樣啟動,這取決於應用程式本身的配置。通常情況下,執行器在伺服器上執行的業務邏輯程式碼可以通過“Thin Lay”與Master互動。

讀者可以在這兒閱讀到更多的有關Mesos架構方面的資訊。

Marathon

Marathon是一個Mesos框架,便於啟動任何可長時間執行的應用程式,從而不需要為特定的應用定製開發框架。Marathon自動提供了很多在叢集環境中執行應用需要的特性,比如高可用性、節點約束、應用健康檢查、指令碼語言API和服務發現、一個易於使用的Web使用者介面。然而Marathon框架的簡潔也帶來了在伸縮性和定製化方面的損失,應用程式沒有規定應該如何按照一定的約束來分配資源,例如資料保護或資料關聯性分析。

首先,我們開始在Marathon上執行Kafka,但實際上我們將會遇到了如下一系列問題。

第一,Marathon不是為了管理有狀態服務而設計的,在有失敗發生或者一個簡單的服務重啟的場景下,Marathon會隨機的在任何符合服務定義約束的資源上重啟服務,這樣對於有狀態服務是不適合的,因為這樣的話需要很高的操作代價來將本地狀態遷移到新的服務上。Kafka類似於其它各種儲存系統一樣都需要在本地磁碟上維護它自己的資料。在Marathon上執行Kafka意味著在Kafka Broker上的一個簡單的重啟操作將會遷移每個Broker到不同的伺服器上,使得Broker需要從剩餘的Broker複製所有它自己的資料。因為通常Kafka儲存了大量的資料,這可能意味著會產生不必要的TB級資料的複製操作。使用者希望如果一個Broker發生了重啟,Kafka Broker叢集可以等待直至重啟操作完成,如果發生了嚴重的錯誤,仍然可以移走該Broker。

第二,Marathon不允許使用者選擇性地對從屬於這些程式子集的應用狀態進行負載均衡。在Kafka上,可以進行叢集擴充套件,使用者可以選擇性地從剩餘的叢集節點遷移一些分割槽資料到最新重啟的Broker上。目前的Kafka叢集擴充套件操作還得通過管理介面手動進行。在叢集中啟動新的Broker不會分配任何資料,使用者必須選擇性地從剩餘的叢集節點遷移一些分割槽資料到新啟動的Broker上,同時Kafka不支援限額,所以遷移分割槽資料的操作必須仔細地分階段完成,避免網路飽和和Kafka叢集內部的複製流量。Marathon沒有提供鉤子來允許應用程式執行特定的業務邏輯來進行故障檢測以及處出來流程。

鑑於如上提到的這些缺點,我們決定尋求將Kafka和Mesos整合在一起的框架方法。

在Mesos上執行Kafka:框架

下圖是Kafka Mesos框架的各種元件工作流程圖:
THE_FRAMEWORK_APPROACH.png

Kafka Mesos排程器:

排程器為Kafka叢集提供了操作自動化功能,任何版本的Kafka都可以通過排程器執行在Mesos上,由排程器決定任務是否失敗、是否需要管理和叢集伸縮,調取器的狀態由ZooKeeper來維護,同時可以通過Restful API來進行配置和其它任務管理。

排程器在Marathon上執行,這樣如果排程器程式被殺死,Marathon可以在另外一個Mesos Slave節點上啟動新的排程器。

Kafka Mesos執行器

執行器作為排程器的中間人與Kafka Broker叢集互動,執行器尋找Kafka的二進位制發行tgz壓縮包,然後執行相關的程式碼,這樣就不僅允許使用者執行不同版本的Kafka,還可以給Kafka打補丁,然後通過已配置的自動化部署平臺執行模擬測試。

讓我們開始:在Apache Mesos上安裝Apache Kafka

如果你想親自動手,這裡是Kafka Mesos框架的快速入門:

開啟兩個終端視窗,進入從git clone的目錄後檢查kafka-mesos.proterties檔案,確保排程器已經配置在你的叢集上。

在第一個終端視窗執行:
git clone https://github.com/mesos/kafka mesosKafka
cd mesosKafka
./gradlew jar
./kafka-mesos.sh scheduler

在第二個終端視窗執行:
./kafka-mesos.sh add 1000..1002 --cpus 0.01 --heap 128 --mem 256
./kafka-mesos.sh start 1000..1002
./kafka-mesos.sh status

到了這一步你就會有三個Kafka Broker在執行了,更多的命令如下:
./kafka-mesos.sh help
You can also get help for each command
./kafka-mesos.sh help <cmd>

管理Kafka Mesos框架

除了CLI命令列方式外,Kafka Mesos框架排程器還提供了Restful API來進行管理配置。

Restful API:

為了獲知Mesos Kafka排程器執行在哪臺機器上,使用者需要查詢如下的Marathon API介面:
curl -X GET -H "Content-type: application/json" -H "Accept: application/json" http://localhost:8080/v2/tasks

REST_API.png

Restful API提供了與CLI命令列方式相同的所有特性,呈現為如下的格式:
/api/brokers/<cli command>/id={broker.id}&<k>=<v>

新增一個Broker:
“http://localhost:7000/api/brokers/add?id=0&cpus=8&mem=43008"

啟動Broker:
“http://localhost:7000/api/brokers/start?id=0"

查詢Broker的執行狀態:
curl "http://localhost:7000/api/brokers/status"

已有的Kafka工具、訊息生產者和消費者

已有的Kafka工具、訊息生產者和消費者都可以工作在Kafka Mesos框架上,工作方式跟之前沒有執行在Mesos上一樣,使用者可以通過CLI或者Restful API發現其它Kafka Broker。

當為了高可用性在Marathon上執行框架排程器時,首先要從Marathon API中尋找排程器的主機地址和埠,然後呼叫排程器查詢Kafka Broker。Mesos DNS也可以用來給Broker分配靜態DNS名稱。一旦使用者連線上了Broker,非常棒!

接下來會發生的

Kafka Mesos框架和DCOS前途無量,我們獲得了很多關於接下來如何以及繼續發展的反饋和想法。這兒有一些目前正在討論的如何改進整合的特性,不過沒有按照一定的順序羅列,其中的大部分特性我們正在將其新增到Apache Kafka專案中:
  • 繼續支援新的Kafka和Mesos特性,修正bug。
  • 將Kafka命令(比如kafka-topic等)整合到框架排程器中,這樣可以通過CLI或者Restful API來使用。
  • 支援叢集的自動伸縮(包括自動重新分配Kafka分割槽),這樣可以在已知的流量低谷期之外充分利用Broker的資源(CPU、記憶體等等)。
  • 機架感知分割槽,改善容錯能力。
  • 提供鉤子程式這樣訊息生產者和消費者也可以從排程器啟動,並通過叢集管理。
  • 按照負載和流量自動重新分割槽。

在接下來的時間裡,很多公司都期待著為它們增長的資料做更多的工作。單一整體集中式部署資料庫的時代一去不復返了,現在很多公司正在擴充套件新的專業分散式系統來處理海量資料,但是它們迫切需要減少部署和管理硬體資源工作的複雜度,從而避免淪為IT基礎設施的奴隸的風險。不僅Kafka會成為公司資料管道設施的核心,使得資料可以流向多種多樣的系統,而且由於像Kafka這樣的大資料技術將會繼續迅猛發展,所以像Mesos這樣的叢集管理系統也會日益重要。

原文連結:Making Apache Kafka Elastic With Apache Mesos (翻譯:胡震) 

=========================================================
譯者介紹
胡震, 曾任網際網路金融創業公司首席架構師&CTO,現在平安金融科技中心架構組負責技術管理和架構設計工作。

原文釋出時間為:2015-09-04
本文作者:國會山上的貓TuxHu 
本文來自雲棲社群合作伙伴DockerOne,瞭解相關資訊可以關注DockerOne。
原文標題:彈性整合Apache Mesos與Apache Kafka框架

相關文章