網易大數據平臺運維實戰

本文整理自 SACC2021 中國系統架構師大會，是網易金川老師視頻直播的文字版本，他分享的主題是 “網易大數據平臺運維實戰”

各位 SACC 觀衆，大家好，感謝各位參加本次智能運維實踐會場的最後一場分享會。算是壓軸出場吧，也希望本次的分享能給大家帶來一些實用的乾貨，特別是對於有重構服務平臺需求的朋友。 

簡單自我介紹一下，我叫金川，來自網易杭州研究院，目前所在的部門是大數據基礎設施組，負責大數據平臺 SRE 的相關工作。如果在分享過程中有任何問題，大家可以先在評論欄中留言，在事後的 QA 環節會爲大家統一做解答。

我本次的分享的內容包括以下幾個部分：

首先，介紹網易的大數據應用現狀；

其次，說明下網易大數據管控平臺的現狀，內部暫定的名稱是 EasyOps。取使用方便靈活之意；

再者，介紹通用的大數據服務運維框架；

然後，說明基於 Prometheus 套件的通用的大數據監控報警實現；

最後，大數據平臺運維實戰經驗分享。

這裏列舉了目前我們的大數據平臺支撐的互聯網產品矩陣，大頭主要是雲音樂、嚴選這 2 個，同時內部還有其他待孵化的產品線，這裏就不做舉例了。

平臺使用的技術棧底層是 Hadoop 生態系統，大概有 22 多個組件；中臺是網易自研的有數，大概 27 個組件。我們離線集羣分爲 6 個，此外實時集羣也有 2 個主要是運行 sparkstreaming 或 flink 作業。

這裏是我們有數中臺的一些功能模塊，具體的使用的介紹這裏不做展開，有興趣的朋友請關注網易有數公衆號，針對各個模塊都有詳細的文章介紹。

接下來，介紹下我們使用的大數據管控平臺 EasyOps。之所以要重新做一套管控工具，是因爲我們在使用開源的 Ambari 系統來部署和管理大數據平臺時，遇到了的各類問題。新的管控平臺就是要解決這些問題，當然這也是一個逐漸迭代的過程，不會是一蹴而就的事情。

這頁是 EasyOps 管控平臺關於 HDFS 服務的一個實例的詳情頁面，這裏包括了該實例所屬的各類組件和節點。左側是所有的服務列表，右側是服務詳情，上方是關於服務的一個概要報表。

接下來是管控平臺的主機頁面，我們可以看到接入的所有主機，然後是主機支持的若干操作。

這個是主機的詳情頁，這裏可以看到這臺主機上安裝的所有服務和組件，包括主機本身的一些報表。細心的同學可能會看出右圖的監控報表和 NodeExporter 很像，是的，我們監控主機狀態用的就是 Node Exporter，關於監控的實現，我們在後面會進行介紹，這裏暫且不表。

這裏是我們的服務配置頁面，可以支持常規的配置組、變更歷史切換和任意的配置下發功能。

這是我們基於 Grafana 的 Dashboard 大盤，彙總了所有相關服務的監控儀表盤。

接下來爲大家介紹下通用的大數據服務運維框架，具備一些開發資源的團隊可以在短時間內完成一個可用的服務運維平臺，這裏我們會分這麼幾個區塊來給大家介紹。

一個通用的服務運維平臺往往會包括以下操作：

其他服務的特異性操作，譬如 HDFS 數據遷移，HDFS 數據均衡，YARN 的隊列或任務操作等等

以服務安裝流程爲例，說明一下整個流程……

這個通用的運維框架是以 Ansible 技術棧爲基礎，包括以上三個主要的功能模塊。

我們使用 Ansible Runner 目錄結構來組織 Playbooks，基本的結構見上圖，在 playbook 目錄下面是各個組件或服務的運維操作的入口。

在 roles 下以服務名創建目錄，目錄下創建 defaults,tasks,templates,vars 目錄。

defaults：用於存放默認的變量值，必須創建 main.yml 文件，調用 role 時會自動加載

tasks: 所有的任務腳本存放的目錄，必須創建 main.yml，當調用 role 時，會調用 main.yml

templates: 用於存放 templates 模板，生成配置文件

vars: 用於存放動態的變量值，需要 include 對應的變量文件纔會加載

平臺的前端我們使用的技術方案是……

平臺後端的技術棧是……

整個平臺的架構圖如上……

以之前提到的 Ansible 的服務安裝調用邏輯爲例，說明下整個調用流程……

服務的配置管理分爲以上幾個部分：

上圖是 YARN 服務的配置管理，可以看到變更的歷史記錄。

關於配置文件的參數變更，我們有這麼一個場景，需要能支持任意參數的配置透傳。我們定義了一套流程來解決上述問題，上面就是一個調用圖例。

爲什麼要有配置透傳？很簡單，因爲開發懶，不想每次服務版本變更增加配置參數後，還需要進行一次適配。而是按照規範，爲特定的配置文件實現動態配置添加策略。

接下來我們介紹下通用的大數據服務監控報警框架，它基於 Prometheus/Grafana 等組件實現；內部使用的 TSDB 是基於 InfluxDB 改造後的 NTSDB。

所以很明顯，在集羣模式下 Prometheus 服務是我們監控的核心模塊，爲此我們針對分佈式和高可用問題，定製了一套架構，下面是分佈式讀寫實現。

這裏是 Prometheus 的高可用架構，所有采集端的 prometheus 均由 prometheusMonitor 進行監控。當一個 prometheus 無法提供服務時，會先由 watchdog 進行重啓；如果依舊無法提供服務，alarmManager 會進行報警，調用 Ansible 的相關接口，拉取無法提供服務的 prometheus 的完整配置文件，然後在合適的主機上創建新的實例。

上圖是我們的度量採集方案，有些服務自己就暴露了 prometheus 的度量接口，譬如 Neo4j，Grafana，Prometheus 等，這類服務我們直接通過 prometheus 抓取相關監控數據即可。JVM 服務我們使用的是 micrometer 插件（https://micrometer.io/）。

接下來是我們自定義的日誌監控流程，日誌採集可以使用 filebeat，logstash 等已有的組件，但我們有內部的一個 DSAgent 方案。通過日誌採集，流入到 kafka，然後我們會有定製的日誌分析邏輯，譬如分析異常日誌，聚合度量等，消費後的數據會分流至 ES，NTSDB 或者 MySQL 等存儲，用於可視化或者報警平臺邏輯。

我們的報表系統基於 Grafana 定製而成。

報警我們可以直接使用 Grafana 的 Alert 模塊來實現，通過導入定製的 Alert 規則，可以方便對集羣的通用性指標統一添加監控報警。

簡單，易用，方便移植。使用 Grafana 更加通用

除此之外我們參考 Prometheus 的 AlertManger 組件，改造了 Prometheus，用它來實現更靈活的自定義報警邏輯。

接下來我們進入最後一個環節，運維經驗的交流。我這邊會以這麼幾塊內容來說明我們的平臺在演進過程中的問題和思路。

從網絡架構、存算分離、服務上雲等方面來介紹平臺的演進過程，這些方面的演進最終目標還是達成成本優化。最後從系統、服務等方面介紹一些性能優化的改進點

大數據 HADOOP 業務相較於常規業務在流量方面有很大的區別，hadoop 業務因數據分析、離線計算等需求會對東西向的流量有非常大的需求，但是又因其數據存儲功能同時也會存在大量其他業務的數據存儲到 hadoop 服務器中導致南北向的流量也非常大。要滿足這樣的流量模型的需求就需要有一個大收斂比的網絡架構，spine leaf 架構恰好能滿足這點。（使用老架構，解決 ARP 的廣播問題，而且隔離性好）

Spine 類似三層架構中的核心交換機，但形態有所變化：高端口密度高吞吐量的三層交換機替代了大型框式核心交換機，4 臺 spine 設備爲一個 pod 節點，結合 ARP 轉路由使用將網絡的壓力從集中式負載於核心交換機，變成給許多的 leaf 交換機來均衡分擔。

存儲分離在上雲過程中一直有提高，這個對於整體的成本優化有明顯的好處，我們自己內部的評估就是同等存儲和計算規格條件下，使用存儲分離可以節省至少 20% 的成本，同時任務的性能也能得到較大提升。

這裏我們主要使用 HDFS Router/Federation 架構，以及 Yarn 的 Node Label 等特性來實現。

最後說到服務上雲的實踐，這裏是我們雲上實踐的部署架構圖。大數據上雲一般來說最大的困難還是存儲接口的問題，主流的雲存儲方案，包括 s3，obs，oss 等等。

爲了提供統一的底層接入環境，我們引入 Alluxio 來作爲中間層來屏蔽底層的存儲細節，從而上層的計算框架和平臺只需要做稍微的參數適配來實現通用的雲上部署邏輯。

最後說到性能優化，我這裏不會說到一些具體的細節，概要的來說，我們可以參考以上的幾個原則來進行優化。

最後是本次的 QA 環節，大家有沒有問題？上面的二維碼是網易有數的公衆號，我們會定期發佈網易大數據的相關技術文章和產品介紹，感興趣的朋友可以關注一下。

今天的分享就到這裏，非常感謝大家的聆聽。謝謝大家！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Fgo1B7sCFEaKLVsz9HOKOA