多場景云資源池監控技術和方案研究

劉 寒，張 奎，趙以爽，康 凱（.中訊郵電咨詢設計院有限公司鄭州分公司，河南鄭州 450007；.中國聯合網絡通信集團有限公司，北京 00033）

0 前言

隨著云計算技術不斷演進，市場蓬勃發展，針對不同業務場景，各公司推出差異化云計算產品，如大數據云、行業云、通用IT 云和通信云等。各個云資源池安全穩定運行是業務發展的基本條件，在出現故障時能及時處理，在性能達到瓶頸時能及時擴容，同時云資源池資源利用率是重要的運營衡量標準，這些都需要云池監控數據的支撐和分析，監控方式的差異、數據采集的效果以及對監控數據的展現都會影響故障處理和數據分析的效率和準確性。因此，針對多業務場景云資源池的監控數據采集方式和統一展現的研究是非常重要且有意義的。

1 不同方式采集云資源數據的原理與差異

隨著云計算技術的演進，云計算涉及的功能組件也越來越多，這些功能組件可能是不同團隊使用不同編程語言開發實現的，同時云計算的分布式架構涉及到的物理計算、網絡、存儲設備可能有成千上萬臺，橫跨多個不同數據中心。

隨著業務的發展，云資源池規模還在不斷擴大，資源池上承載的業務類型和容量也在不斷地增加。業務的頻繁調整使資源池也需要頻繁調整。這就帶一系列的問題：如何判斷故障產生原因？如何界定故障所影響的范圍？如何分析性能使用情況？如何確定容量使用情況從而進行后期建設規劃？

解決上述問題需要監控數據進行支撐，目前主流監控方式分為帶內監控和帶外監控。

1.1 云資源池帶內監控原理

監控數據與業務數據在同一物理通道上傳輸，即為帶內監控。帶內監控是目前的主流監控方式，分布式探針監控系統則是帶內監控中常見的監控系統，其系統的主要功能模塊有展示模塊、采集模塊、發送模塊、收集模塊和存儲模塊。

采集模塊將收集到的監控信息通過發送模塊傳遞至收集模塊，收集模塊進行存儲，最終由前端展示模塊進行展示和查詢，流程如圖1所示。

圖1 分布式探針監控流程圖

除上述流程外，對于帶內監控還有以下幾點基本技術要求。

a）帶內探針系統的性能消耗：探針組件的影響應當做到足夠小，本身探針在采集監控數據時會消耗主機性能，所以需要對數據采集的方式和頻率周期進行配置優化，以保證業務的正常運行。在一些高度敏感和易受環境波動影響的云計算組件或業務組件中，即使輕微損耗波動也會對系統造成可見影響，會迫使維護團隊關閉或刪除探針軟件。

b）監控的侵入性：監控組件作為云計算組件的一部分，應盡可能少入侵或不入侵其他組件或承載業務系統，同時作為業務使用方不需要知道或發現監控探針的存在。

c）可擴展性：一個完備的監控系統必須支持分布式部署，具有良好的可擴展性。

d）數據分析：數據分析系統必須盡快分析采集到的監控數據，并且分析的維度也要盡可能的多。監控系統需要盡快反饋信息，這樣就可以對生產環境下的故障或異常現象及時響應。

1.2 云資源池帶外監控原理

監控系統通過單獨的物理鏈路對已使用管理接口聯網的物理設備采集監控數據，這種監控方式被稱為帶外監控，帶外監控除了能采集到硬件設備的配置信息、部分性能信息和健康狀態外，在帶內網絡故障或主機操作系統故障，導致SSH、VNC等通過帶內方式連接無法使用時，可以通過帶外通路遠程登錄帶外管理模塊，查看、控制設備狀態，處理故障等。

目前業界都是通過適配的接口協議對硬件設備進行監控和管理，主流的協議有IPMI 協議（Intellgent Platform Management Interface）、Redfish 協議、MCTP 協議（Management Component Transport Protocol）、帶外管理標準協議（Desktop and mobile Architecture for Sys?tem Hardware）等。

監控系統通過帶外管理接口不僅可以獲得設備資產信息，還可以通過SNMP 接口監聽方式對設備硬件告警進行監控。相較帶內監控方式，帶外管理接口獲取的硬件告警信息更加詳細，故障點更為精確。

1.3 帶內、帶外監控的差異

如表1 所示，帶內、帶外監控定位不同，帶內監控主要獲取操作系統層級以上的監控數據，而帶外監控主要獲取資產信息和硬件監控信息，因此帶內、帶外監控并不是二選一，而是1+1 互補的關系。云資源池同時具備帶內、帶外監控的情況下，采集到的監控數據會更加全面，故障定位會更加迅速，數據分析也更加全面。

表1 帶內帶外監控差異

2 不同云池場景采集方案

根據所承載業務不同，云資源分為多種產品，如承載IT 系統的IT 云、承載大數據業務的大數據云、承載網絡能力虛擬化的通信云等，不同類型的云也需要不同的云資源監控方案，以下列舉2 類典型場景的監控方式。

2.1 IT/大數據云資源監控

目前行業內IT 云資源池常用的監控手段是帶內監控為主，帶外監控為輔的監控方案。現在主流的帶內監控產品有很多，如zabbix、Prometheus、Span等。通過帶內監控對主機操作系統、網絡設備性能等進行監控，可以采集主機資源實時利用情況、操作系統健康狀態等，同時通過帶外管理接口采集硬件的資產信息、健康狀態以及設備的功耗、進風口溫度等信息，同時也可以通過端口監聽的方式獲取設備的故障告警信息。

以Prometheus 監控為例，如圖2 所示，Prometheus從主機上部署的2種exporter 獲取監控數據，帶內監控通過部署在主機操作系統上的Node-exporter 獲取操作系統數據，帶外監控則通過IPMI-exporter 獲取帶外管理接口中的數據，另外由于Prometheus 并沒有傳遞告警信息的能力，帶外告警是IPMI接口發出硬件告警信息并推送至kafka進行存儲轉發，帶內告警則是由匯聚節點通過帶內監控數據計算出告警并推送至kafka進行存儲轉發。

圖2 IT云監控架構示意圖

2.2 通信云資源監控

通信云即為承載運營商網絡能力虛擬化（NFV）能力的云資源，由于運營商業務的特殊性，通信業務對云資源的可靠性、可用性和安全性有著極高的要求。由于通信業務的極致可靠性要求，一般第三方監控軟件探針的安全性和性能在未長時間全方位驗證測試的情況下，是不允許部署在業務運行的虛擬機和宿主機上的，因此IT云監控方案不易套用在通信云上。

根據業務特性，通信云監控分為小閉環和大閉環。如圖3所示，單個資源池建議采用小閉環，資源池擁有二級平臺對自身進行管理、監控、故障維護處理等能力的邏輯閉環，監控范圍涵蓋帶內帶外所有網絡；多DC 多資源池建議形成大閉環，由一級平臺向小閉環的二級平臺采集資源池的監控、告警等信息，一級平臺建設數據采集層，制定統一資源模型以消除不同廠家間北向上報的數據差異，各資源池間打通鏈路形成分布式的運維能力，在上層構建智能化的數據分析能力平臺，增強運維能力，提高故障處理效率。

圖3 通信云一級監控架構示意圖

3 多場景多方案采集統一展示

為了消除不同云資源之間的差異，實現一點看全、全局監控，運營商需要在用戶側建設一個統一的云資源監控門戶對不同類型云資源進行匯總和分類展示，提高可視化能力，提供多種場景的運維管理窗口，同時對不同角色的用戶設置不同的展示窗口和瀏覽范圍。

不同云資源監控數據格式不同，無法合理進行統一展示，這種情況就需要制定各云資源上報數據格式的統一規范，對各類數據進行規范化要求，對通用和核心關鍵指標進行集中展示，而對各類型業務云資源差異化的指標則可以分不同場景窗口進行分類展示。

4 結束語

本文通過分析云資源監控的特點，總結了帶內和帶外監控的各自特點，深入研究云資源池的監控方式，并給出2類典型業務場景的監控方案，為不同業務云資源池監控提供重要參考，從而有效提高云資源池運維能力。