計算機環(huán)境下的自適應資源監(jiān)測模型設(shè)計

董桂平

(黑龍江省無線電監(jiān)測站，黑龍江 哈爾濱150001)

監(jiān)測是保證計算機平臺高效工作的基礎(chǔ)，隨著計算機的快速發(fā)展，越來越多的應用部署到云中，勢必對系統(tǒng)的穩(wěn)定性、健壯性和系統(tǒng)性能提出更高的要求。而有效的資源管理方案能保障系統(tǒng)的正常運行，因此對數(shù)據(jù)中心的資源進行高效的管理變得尤為重要。資源監(jiān)測是數(shù)據(jù)管理的重要組成部分，有效的監(jiān)測能為數(shù)據(jù)中心的管理和維護提供可靠依據(jù)。建立計算機環(huán)境下的資源監(jiān)測模型，該模型能夠根據(jù)系統(tǒng)資源負載的變化，自適應地獲取和公布系統(tǒng)的資源信息和負載情況。

1 計算機系統(tǒng)常見故障分析及處理

由于微機監(jiān)測系統(tǒng)缺乏維護，致使運行狀態(tài)不佳時而發(fā)生故障給安全生產(chǎn)工作帶來諸多不便。

1.1 解調(diào)器發(fā)出連續(xù)的響聲

這種響聲是電子設(shè)備運行不正常所發(fā)出的響聲，通信網(wǎng)絡(luò)的通道進行數(shù)據(jù)傳輸時，將故障范圍鎖定在調(diào)制解調(diào)器部分。應檢查網(wǎng)絡(luò)通道是否被斷開或占用或被嚴重干擾。

1.2 圖畫面靜止不更新

計算機操縱臺顯示器畫面靜止不動，鼠標可以進行相關(guān)操作但系統(tǒng)不能更新操作信息。 故障出現(xiàn)在DMIS 分機的運行狀態(tài)上，應該確認微機監(jiān)測站機的網(wǎng)卡與DMIS 機柜內(nèi)的集線器相連接的網(wǎng)線是否接插良好。

1.3 通信信號不更新

監(jiān)測信息停止，無法進行實時更新。通過CAN 通信傳輸至相應的采集分機傳輸至開關(guān)量CPU 板進行數(shù)據(jù)處理，要檢查CAN 通信的采集分機電源和CPU 板工作是否正常。

1.4 工作正常而不通信

系統(tǒng)工作正常但現(xiàn)場采集各項數(shù)據(jù)顯示為空白。應先查看各采集機工作是否正常，采集機插板有故障應應檢查至通信頭的和至通信頭的是否斷線或者查看通信頭與工控機插接是否良好。

2 資源監(jiān)測的原則

2.1 監(jiān)測結(jié)果必須準確

資源監(jiān)測模塊是計算機平臺數(shù)據(jù)管理的基礎(chǔ)功能模塊。借鑒現(xiàn)有的資源監(jiān)測方法，采用基于過濾窗口的異常上報算法，有效降低了異常告警帶來的通信開銷。

監(jiān)測結(jié)果不正確會導致嚴重后果。一個錯誤的狀態(tài)告警常常會導致不必要且昂貴的通信開銷，漏過一個狀態(tài)告警會使?jié)撛诘挠脩粢驗樾阅懿缓枚艞夁@個應用。所以要求資源監(jiān)測必須傳遞正確的監(jiān)測結(jié)果。

2.2 監(jiān)測數(shù)據(jù)傳輸?shù)男室?/h3>

資源監(jiān)測相關(guān)的通信消耗應盡可能小。由于監(jiān)測通信會消耗帶寬和CPU，而服務器通常只能有分配有限的資源用于監(jiān)測，因此，資源監(jiān)測要盡力做到最小化通信消耗，避免增加不必要的資源消耗。

2.3 資源監(jiān)測勢必對系統(tǒng)的穩(wěn)定性、健壯性和系統(tǒng)性能提出更高的要求

有效的資源管理方案能夠保障系統(tǒng)的正常運行，對數(shù)據(jù)中心的資源進行高效管理是數(shù)據(jù)管理的重要組成部分，有效的監(jiān)測可以為計算環(huán)境下的資源監(jiān)測模型，通過監(jiān)測各節(jié)點對監(jiān)測信息實現(xiàn)集中管理，建立分布式的資源和負載監(jiān)控框架，通過本地監(jiān)測系統(tǒng)搜集系統(tǒng)中各個節(jié)點的資源狀況和負載情況，資源監(jiān)測必須傳遞正確的監(jiān)測結(jié)果

2.4 監(jiān)測采用直觀的資源監(jiān)測方法

通常情況下，監(jiān)測主節(jié)點周期性地向各個節(jié)點獲取其動態(tài)的資源和狀態(tài)監(jiān)測數(shù)據(jù)，被監(jiān)測節(jié)點只有在接收到主節(jié)點的請求后才會將自身的監(jiān)測數(shù)據(jù)發(fā)送給主節(jié)點。管理節(jié)點接收到告警信息，在短期內(nèi)出現(xiàn)的峰值簡單地表明了運行系統(tǒng)的動態(tài)性，采用了一種基于過濾窗口的自適應監(jiān)測方法，減少相關(guān)的通信消耗問題。在保證監(jiān)測準確性的基礎(chǔ)上能夠有效減少發(fā)送告警帶來的通信消耗，自適應的監(jiān)測方法周期性地向系統(tǒng)中的各個節(jié)點進行整合，選取三臺服務器作為被監(jiān)測節(jié)點，通過頻率獲取該節(jié)點的CPU 使用率，將采集到的數(shù)據(jù)發(fā)送給監(jiān)測主節(jié)點。需要綜合考慮采集頻率和閾值大小，根據(jù)被監(jiān)測節(jié)點的敏感度需求來設(shè)置。

3 資源監(jiān)測策略

3.1 建立不同的模型

3.1.1 采用分層的模型，系統(tǒng)中的功能實體所處的層級和每一層包含的實體是有區(qū)別的。為了保證IAAS 系統(tǒng)的正常運行，需要對系統(tǒng)中的每個功能實體進行監(jiān)測管理。資源監(jiān)測主要監(jiān)控系統(tǒng)中各個節(jié)點的資源狀態(tài)信息，當監(jiān)測數(shù)據(jù)超過閾值時，發(fā)出異常告警。在設(shè)計資源監(jiān)測系統(tǒng)的時候，盡可能使其能通過簡單方便的設(shè)置來實現(xiàn)不同層級的功能實體的監(jiān)測需求。減少各個層級之間監(jiān)測數(shù)據(jù)傳輸?shù)耐ㄐ畔模赃_到降低狀態(tài)異常告警帶來的通信開銷的目的。

3.1.2 資源監(jiān)測模型。計算環(huán)境下的資源監(jiān)測可以分為push 和pull兩種模式。push 模式的實時性較好，但系統(tǒng)有一定負載。pull 模式實時性較差，傳輸量小，容易浪費系統(tǒng)。

3.1.3 通用連接框架.它是網(wǎng)絡(luò)通信的基本要求，利用網(wǎng)絡(luò)可以使客戶端和服務器端進行配合，實現(xiàn)復雜的應用。根據(jù)需要在簡表中擴充連接框架來對特定協(xié)議提供支持。應用程序通過WinSock API 設(shè)計通信程序，WinSock 利用網(wǎng)絡(luò)通信協(xié)議和操作系統(tǒng)調(diào)用完成實際的通信工作。每個進程的進程空間里都有一個套接字描述符表。一些可選包，組成了J2ME 的基本運行環(huán)境，運行于設(shè)備的主機操作系統(tǒng)之上，利用相似設(shè)備的類似功能。同時，配置在層體系結(jié)構(gòu)中起到了承上啟下的作用，它定義了所支持的Java 編程語言特征。面向?qū)ο缶幊陶Z言的強大能力，Java 編程語言使得應用程序的開發(fā)更加有效。

3.2 監(jiān)測策略

資源監(jiān)測策略是一種直觀的資源監(jiān)測方法。通常情況下，監(jiān)測主節(jié)點周期性地向各個節(jié)點獲取其動態(tài)的資源和狀態(tài)監(jiān)測數(shù)據(jù)，被監(jiān)測節(jié)點只有在接收到主節(jié)點的請求后才會將自身的監(jiān)測數(shù)據(jù)發(fā)送給主節(jié)點。但是，當某個節(jié)點的CPU、內(nèi)存或負載等狀態(tài)超出其設(shè)定的相應閾值時，該節(jié)點就會主動向主節(jié)點發(fā)送一個告警信息。通常情況下是采用自適應監(jiān)測方法。使用Baseline 策略的資源監(jiān)測方法，系統(tǒng)中的告警消息會帶來管理節(jié)點的帶寬和CPU 嚴重消耗，從而影響系統(tǒng)的可擴展性。因此，適用于計算環(huán)境下的資源監(jiān)測方法必須考慮減少相關(guān)的通信消耗問題。在保證監(jiān)測準確性的基礎(chǔ)上能夠有效減少發(fā)送告警帶來的通信消耗。同時也可以利用VM Monitor 模塊，則在其監(jiān)測值超過預先設(shè)定的閾值時，基于過濾窗口策略決定是否將自身的監(jiān)測信息主動推送給Cluster Monitor 模塊，采用了基于過濾窗口的異常上報算法，在保證監(jiān)測準確性的基礎(chǔ)上有效降低了異常告警帶來的通信開銷。實驗表明自適應的資源監(jiān)測機制的性能明顯優(yōu)于baseline 方法。

［1］王德文.基于云計算的電力數(shù)據(jù)中心基礎(chǔ)架構(gòu)及其關(guān)鍵技術(shù)[J].電力系統(tǒng)自動化,2012(11).

［2］張棋勝.云計算平臺監(jiān)控系統(tǒng)的研究與應用[D].北京交通大學,2011.

［3］王德文,宋亞奇,朱永利.基于云計算的智能電網(wǎng)信息平臺[J].電力系統(tǒng)自動化,2010(22).