監(jiān)控是集群管理的核心任務(wù)監(jiān)控?cái)?shù)據(jù)可用于調(diào)度任務(wù)負(fù)載平衡向管理員報(bào)告軟硬件故障并廣泛地控制系統(tǒng)使用情況監(jiān)控信息必須在不影響集群性能的情況下獲得本文將討論使用/proc文件系統(tǒng)和Java來獲得監(jiān)控?cái)?shù)據(jù)的方法

Java在Linux集群中的應(yīng)用

Java技術(shù)為集群管理開發(fā)者提供了許多解決問題的辦法Java是動態(tài)靈活可移植的這些不尋常的特征使得它成為了在異構(gòu)網(wǎng)絡(luò)及平臺上構(gòu)造集群管理的理想基礎(chǔ)

Java具有廣泛的例程庫很容易處理IP協(xié)議如TCPUDP并可在multihomed主機(jī)上進(jìn)行網(wǎng)絡(luò)程序設(shè)計(jì)用它創(chuàng)建網(wǎng)絡(luò)連接比用C或C++更容易通過Java本地接口(JNI)運(yùn)行在Java 虛擬機(jī)(JVM)內(nèi)的Java代碼能夠與用其它語言編寫的應(yīng)用及庫文件相互操作并匯編

在構(gòu)造集群監(jiān)控和管理時(shí)Java早已是一個可選的語言然而Java語言通常只被用于系統(tǒng)的前端或集群主機(jī)部分而將用C 語言編寫的守護(hù)進(jìn)程安裝在集群結(jié)點(diǎn)上盡管Java程序設(shè)計(jì)語言提供了許多優(yōu)點(diǎn)但是對于高性能集群監(jiān)控Java能夠有效地替換運(yùn)行在每個結(jié)點(diǎn)上的C 語言守護(hù)進(jìn)程嗎?這將是本文討論的重點(diǎn)

高性能監(jiān)控

監(jiān)控Linux集群工具傳統(tǒng)上以秒為測量頻率來提供有限量的數(shù)據(jù)而高性能集群監(jiān)控被定義為“以intrasecond為測量頻率從結(jié)點(diǎn)有效地采集數(shù)據(jù)的能力”當(dāng)涉及較大集群時(shí)監(jiān)控軟件的低效率問題就變得更加嚴(yán)重這是因?yàn)樗\(yùn)行的應(yīng)用軟件必須互相協(xié)調(diào)或共享全局資源

在一個結(jié)點(diǎn)上的阻隔沖突(Interference)能影響其它結(jié)點(diǎn)上作業(yè)的運(yùn)行例如一個MPI作用需要與所有參與的結(jié)點(diǎn)同步一種解決辦法是收集少量的數(shù)據(jù)并以小頻率傳輸然而如果是高性能監(jiān)控這種解決辦法是不可接受的因?yàn)橛休^重利用率的集群應(yīng)該被頻繁持續(xù)地監(jiān)控本地作業(yè)調(diào)度器必須能夠基于資源使用情況做快速決策管理員經(jīng)常希望收到緊急事件的立即通知并希望觀察到歷史趨勢數(shù)據(jù)如果集群不能被頻繁持續(xù)地監(jiān)控那么這些要求是不可能實(shí)現(xiàn)的因此必須采取一些措施如使用更有效的算法增加傳輸?shù)牟⑿行蕴岣邆鬏攨f(xié)議及數(shù)據(jù)格式的效率減少冗余等

在跟蹤運(yùn)行中的資源使用情況時(shí)壓縮Profiling應(yīng)用有助于調(diào)試程序或優(yōu)化程序?qū)σ粋€給定的應(yīng)用而言像存儲器網(wǎng)絡(luò)CPU這樣動態(tài)資源的使用可能快速地改變著為了能夠觀察應(yīng)用是怎樣使用這些資源的一種可能的辦法是使用高頻率的監(jiān)控

即使用戶對高頻率監(jiān)控沒有興趣如果算法是有效的不管監(jiān)控頻率是多少它也將消費(fèi)很少的資源在異構(gòu)集群中這種效率將更重要用戶的作業(yè)可以被分散到較快的及較慢的結(jié)點(diǎn)上慢的結(jié)點(diǎn)需要全部CPU來跟上較快的結(jié)點(diǎn)并與之同步一個監(jiān)控程序花費(fèi)在較慢結(jié)點(diǎn)上的CPU時(shí)間是作業(yè)的關(guān)鍵路徑

監(jiān)控階段

集群監(jiān)控主要消耗CPU周期與網(wǎng)絡(luò)帶寬這兩個重要資源然而資源消費(fèi)問題與這兩個資源是根本不同的CPU利用問題對結(jié)點(diǎn)而言是完全本地化的問題可通過創(chuàng)建有效的收集與合并算法來解決網(wǎng)絡(luò)帶寬是共享資源是規(guī)模問題可以通過最小化網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量來解決

為了解決這兩個問題我們將集群監(jiān)控分為三個階段收集合并傳輸收集階段負(fù)責(zé)從操作系統(tǒng)裝載數(shù)據(jù)分析數(shù)據(jù)值并存儲數(shù)據(jù)合并階段負(fù)責(zé)將來自多個數(shù)據(jù)源的數(shù)據(jù)合在一起決定數(shù)據(jù)值是否改變并過濾它們傳輸階段負(fù)責(zé)壓縮并傳輸數(shù)據(jù)本文集中討論Linux集群監(jiān)控的收集階段

收集階段

Linux有幾種方法來進(jìn)行系統(tǒng)統(tǒng)計(jì)每種方法都各有其優(yōu)缺點(diǎn)

◆ 使用現(xiàn)有的工具

標(biāo)準(zhǔn)及非標(biāo)準(zhǔn)工具能執(zhí)行一個或多個收集合并及傳輸階段如rstatd或SNMP工具然而標(biāo)準(zhǔn)的rstat后臺程序提供的信息是有限的速度慢而且效率低

◆ 內(nèi)核模塊

幾個系統(tǒng)監(jiān)控工程利用內(nèi)核模塊來存取監(jiān)控?cái)?shù)據(jù)一般情況下這是很有效的收集系統(tǒng)數(shù)據(jù)的方法然而這種方法存在的問題是當(dāng)主內(nèi)核源內(nèi)有其它改變時(shí)必須保持代碼一致性一個內(nèi)核模塊可能與用戶想使用的其它內(nèi)核模塊相沖突此外在使用監(jiān)控系統(tǒng)之前用戶必須獲得或申請模塊

◆ /proc虛擬文件系統(tǒng)

/proc 虛擬文件系統(tǒng)是一個較快的高效率執(zhí)行系統(tǒng)監(jiān)控的方法使用/proc的主要缺點(diǎn)是必須保持代碼分析與/proc 文件格式改變的同步事實(shí)表明Linux內(nèi)核的改變比/proc 文件格式的改變要更頻繁所以用/proc虛擬文件系統(tǒng)比用內(nèi)核模塊存在的問題要少

◆ 混合系統(tǒng)

某些監(jiān)控系統(tǒng)采用混合方式用內(nèi)核模塊收集數(shù)據(jù)用/proc虛擬文件系統(tǒng)作為數(shù)據(jù)接口

合并階段

合并階段的實(shí)現(xiàn)可以在結(jié)點(diǎn)上集群管理的主機(jī)上或者分布在兩者上考慮到效率我們只采用在結(jié)點(diǎn)上的合并原因在于結(jié)點(diǎn)是監(jiān)控?cái)?shù)據(jù)的收集器與提供者兩個或多個同時(shí)的數(shù)據(jù)請求不會引起兩次操作系統(tǒng)調(diào)用來收集數(shù)據(jù)而是將第一次請求獲得的數(shù)據(jù)緩存并可以提供給第二次請求調(diào)用這種方法減少了操作系統(tǒng)的負(fù)擔(dān)提高了監(jiān)控系統(tǒng)的響應(yīng)性合并階段也可以用于將多個數(shù)據(jù)源的數(shù)據(jù)以相互獨(dú)立的收集速率結(jié)合因?yàn)椴⒉皇撬械臄?shù)據(jù)都以同樣的速度改變或者需要以同樣的速率收集

使用在結(jié)點(diǎn)層上合并的另一個原因是減少了包括傳輸在內(nèi)的信息量許多/proc文件既包含動態(tài)數(shù)據(jù)也包含靜態(tài)數(shù)據(jù)刪除最近一次傳輸后沒有改變的值一個結(jié)點(diǎn)發(fā)送的數(shù)據(jù)量可以大大地減少合并不僅除去了不經(jīng)常改變的動態(tài)值的傳輸也解決了從不改變的靜態(tài)值的傳輸

傳輸階段

監(jiān)控?cái)?shù)據(jù)幾乎總是按一個層次結(jié)構(gòu)組織起來傳輸階段的任務(wù)就是將層次數(shù)據(jù)進(jìn)行有效的編碼形成一種能高效傳輸?shù)臄?shù)據(jù)格式Java擁有的文件格式是存儲層次數(shù)據(jù)的有效方法并且用提供的Java APIs很容易完成SExpressions已經(jīng)被認(rèn)為是傳輸這種數(shù)據(jù)的另一個有效的方法

關(guān)于傳輸監(jiān)控?cái)?shù)據(jù)普遍討論的問題是數(shù)據(jù)應(yīng)該按二進(jìn)制編碼還是按文本格式編碼二進(jìn)制數(shù)據(jù)更容易壓縮因此也能更有效地傳輸?shù)钱?dāng)采用/proc文件系統(tǒng)時(shí)監(jiān)控?cái)?shù)據(jù)通常以人們易讀的格式存儲在傳輸之前將數(shù)據(jù)轉(zhuǎn)換為二進(jìn)制格式將需要更多的處理資源與時(shí)間以文本格式保留收集的數(shù)據(jù)結(jié)點(diǎn)資源能被用于更多非監(jiān)控性的相關(guān)工作

采用文本格式的數(shù)據(jù)將提供如下額外的益處

◆ 平臺獨(dú)立性

當(dāng)監(jiān)控異構(gòu)集群時(shí)機(jī)器之間數(shù)據(jù)字節(jié)指令的配置不是永遠(yuǎn)相同的文本格式的使用在代碼方面解決了這個問題而且體系結(jié)構(gòu)獨(dú)立不會影響更多的處理需求

◆ 易讀的格式

文本數(shù)據(jù)能以人們易讀的格式進(jìn)行組織如果需要的話這種特征能容易地進(jìn)行程序調(diào)試或允許用戶觀看數(shù)據(jù)流[!--empirenews.page--]

◆ 有效壓縮

數(shù)值數(shù)據(jù)的文本表示由來自個字節(jié)集中的字符組成而不是二進(jìn)制下的個字節(jié)集它們產(chǎn)生的數(shù)字及模式的相對頻率允許有效地使用基于壓縮算法的字典及熵(平均信息量)

/proc虛擬文件系統(tǒng)

/proc虛擬文件系統(tǒng)(也叫procfs)是Unix操作系統(tǒng)所使用的虛擬文件系統(tǒng)的Linux實(shí)現(xiàn)包括Sun SolarisLinuxBSD在/proc開始時(shí)它以一個標(biāo)準(zhǔn)文件系統(tǒng)出現(xiàn)并包含與正在運(yùn)行的進(jìn)程IDs同樣名字的文件然而在/proc中的文件不占用磁盤空間它們存在于工作存儲器(內(nèi)存)中/proc最初的目的是便于進(jìn)程信息的存取但是現(xiàn)在在Linux中它可被內(nèi)核的每一部分使用來報(bào)告某些事情

在/proc文件系統(tǒng)提供的成百上千的值當(dāng)中我們將集中考慮集群監(jiān)控所需的最小集它們包括

◆ /proc/loadavg包含系統(tǒng)負(fù)載平均值;

◆ /proc/meminfo包含存儲管理統(tǒng)計(jì)量;

◆ /proc/net/dev包含網(wǎng)卡度量;

◆ /proc/stat包含內(nèi)核統(tǒng)計(jì)量;

◆ /proc/uptime包含總的系統(tǒng)正常工作時(shí)間及空閑時(shí)間

每個文件提供的值的數(shù)量是不同的這些文件的完整有效值列表如下

◆ /proc/loadavg提供以下數(shù)據(jù)

秒鐘平均負(fù)載;

秒鐘平均負(fù)載;

秒鐘平均負(fù)載;

總作業(yè)數(shù);

正在運(yùn)行的作業(yè)總數(shù)

◆ /proc/meminfo提供的存儲器信息包括

活動存儲器;

不活動存儲器;

緩沖存儲器;

高速緩沖存儲器;

總的自由存儲器;

總的高位存儲器;

自由高位存儲器;

總的低位存儲器;

自由低位存儲器;

共享存儲器;

交換存儲器;

交換高速緩沖存儲器;

交換自由存儲器;

總存儲器

◆ /proc/net/dev中包括每個網(wǎng)卡的如下數(shù)據(jù)

接收到的字節(jié);

接收到的壓縮字節(jié);

收到的誤碼數(shù);

收到的漏失誤碼;

收到的FIFO誤碼;

收到的幀誤碼;

收到的多播誤碼;

收到的總包數(shù);

已傳輸?shù)淖止?jié);

已傳輸?shù)膲嚎s字節(jié);

傳輸誤碼總數(shù);

傳輸載波誤碼;

傳輸沖突誤碼;

傳輸漏失誤碼;

傳輸FIFO誤碼;

傳輸?shù)目偘鼣?shù)

◆ /proc/stat提供

引導(dǎo)時(shí)間;

上下文切換數(shù)量;

中斷總量;

進(jìn)頁面總數(shù);

出頁面總數(shù);

進(jìn)程總數(shù);

換入總數(shù);

換出總數(shù);

合計(jì)CPU空閑時(shí)間;

合計(jì)CPU nice時(shí)間;

合計(jì)CPU系統(tǒng)時(shí)間;

合計(jì)CPU用戶時(shí)間

同時(shí)提供對每個CPU的:

單個CPU空閑時(shí)間;

單個CPU nice時(shí)間;

單個CPU系統(tǒng)時(shí)間;

單個CPU用戶時(shí)間

以及對每個磁盤驅(qū)動器的如下數(shù)據(jù)

單個磁盤塊讀;

單個磁盤塊寫;

單個磁盤I/O總數(shù);

單個磁盤I/O讀;

單個磁盤I/O寫

◆ /proc/uptime中包括

系統(tǒng)總工作時(shí)間;

系統(tǒng)總空閑時(shí)間

值得注意的是每次某個/proc被讀時(shí)一個句柄函數(shù)都被內(nèi)核或特有模塊調(diào)用來產(chǎn)生數(shù)據(jù)數(shù)據(jù)在運(yùn)行中產(chǎn)生不管是讀一個字符還是一個大的字塊整個文件都將被重建這對效率是至關(guān)重要的一點(diǎn)因?yàn)槭褂?proc的任何系統(tǒng)監(jiān)控器將吞下整個文件而不是一點(diǎn)一點(diǎn)地處理它

Java提供了豐富的文件I/O類集包括基于類的流基于類的塊設(shè)備以及JSDK 提供的新的I/O庫實(shí)驗(yàn)表明一般而言對基本的塊讀寫文件操作用RandomAccessFile類進(jìn)行I/O是最佳的例如塊讀文件操作如下

mFile = new RandomAccessFile( "/proc/meminfo" "r" );

//以讀方式打開文件

mFileread( mBuffer ); //讀文件塊

結(jié)論

本文討論了如何將Java語言有效地用于Linux集群結(jié)點(diǎn)上的高性能監(jiān)控在程序設(shè)計(jì)中要注意以下方面

◆ 采用/proc文件系統(tǒng);

◆ 以塊形式讀/proc文件而不是以行或字符形式;

◆ 在讀文件期間保持文件打開;

◆ 消除不必要的數(shù)據(jù)轉(zhuǎn)換;

◆ 在結(jié)點(diǎn)上合并數(shù)據(jù);

◆ 以壓縮形式傳輸數(shù)據(jù);

◆ 注意與性能問題相關(guān)的語言或庫

對高性能監(jiān)控而言內(nèi)核模塊不是必要條件這點(diǎn)很重要因?yàn)樗贚inux版本和分類之間提供了很大程度的可移植性在監(jiān)控器實(shí)現(xiàn)語言上有很多的選擇但是/proc文件系統(tǒng)的性能卻很依賴內(nèi)核代碼的效率因此適當(dāng)?shù)乩斫庥嘘P(guān)的機(jī)制將對以任何語言編寫的監(jiān)控器性能有非常大的影響。