高效能Linux叢集管理監控之道(轉)

高效能Linux叢集管理監控之道(轉)[@more@]監控是叢集管理的核心任務。監控資料可用於排程任務、負載平衡、向管理員報告軟硬體故障，並廣泛地控制系統使用情況。監控資訊必須在不影響叢集效能的情況下獲得。本文將討論使用/proc檔案系統和Java來獲得監控資料的方法。

Java在Linux叢集中的應用

Java技術為叢集管理開發者提供了許多解決問題的辦法。Java是動態、靈活、可移植的，這些不尋常的特徵使得它成為了在異構網路及平臺上構造叢集管理的理想基礎。

Java具有廣泛的例程庫，很容易處理IP協議，如TCP、UDP，並可在multi-homed主機上進行網路程式設計，用它建立網路連線比用C或C＋＋更容易。透過Java本地介面（JNI），執行在Java 虛擬機器（JVM）內的Java程式碼能夠與用其它語言編寫的應用及庫檔案相互操作並彙編。

在構造叢集監控和管理時，Java早已是一個可選的語言。然而，Java語言通常只被用於系統的前端或叢集主機部分，而將用C 語言編寫的守護程式安裝在叢集結點上。儘管Java程式設計語言提供了許多優點，但是，對於高效能叢集監控，Java能夠有效地替換執行在每個結點上的C 語言守護程式嗎？這將是本文討論的重點。

高效能監控

監控Linux叢集工具傳統上以秒為測量頻率來提供有限量的資料。而高效能叢集監控被定義為“以intrasecond為測量頻率，從結點有效地採集資料的能力”。當涉及較大叢集時，監控軟體的低效率問題就變得更加嚴重，這是因為所執行的應用軟體必須互相協調或共享全域性資源。

在一個結點上的阻隔衝突（Interference）能影響其它結點上作業的執行。例如，一個MPI作用需要與所有參與的結點同步。一種解決辦法是收集少量的資料，並以小頻率傳輸。然而，如果是高效能監控，這種解決辦法是不可接受的，因為有較重利用率的叢集應該被頻繁持續地監控。本地作業排程器必須能夠基於資源使用情況做快速決策。管理員經常希望收到緊急事件的立即通知，並希望觀察到歷史趨勢資料，如果叢集不能被頻繁持續地監控，那麼這些要求是不可能實現的。因此，必須採取一些措施，如使用更有效的演算法、增加傳輸的並行性、提高傳輸協議及資料格式的效率、減少冗餘等。

在跟蹤執行中的資源使用情況時，壓縮Profiling應用有助於除錯程式或最佳化程式。對一個給定的應用而言，像儲存器、網路、CPU這樣動態資源的使用可能快速地改變著，為了能夠觀察應用是怎樣使用這些資源的，一種可能的辦法是使用高頻率的監控。

即使使用者對高頻率監控沒有興趣，如果演算法是有效的，不管監控頻率是多少，它也將消費很少的資源。在異構叢集中這種效率將更重要，使用者的作業可以被分散到較快的及較慢的結點上，慢的結點需要全部CPU來跟上較快的結點並與之同步。一個監控程式花費在較慢結點上的CPU時間是作業的關鍵路徑。

監控階段

叢集監控主要消耗CPU週期與網路頻寬這兩個重要資源。然而，資源消費問題與這兩個資源是根本不同的。CPU利用問題對結點而言是完全本地化的問題，可透過建立有效的收集與合併演算法來解決。網路頻寬是共享資源，是規模問題，可以透過最小化網路上傳輸的資料量來解決。

為了解決這兩個問題，我們將叢集監控分為三個階段：收集、合併、傳輸。收集階段負責從作業系統裝載資料、分析資料值，並儲存資料。合併階段負責將來自多個資料來源的資料合在一起，決定資料值是否改變並過濾它們。傳輸階段負責壓縮並傳輸資料。本文集中討論Linux叢集監控的收集階段。

1．收集階段

Linux有幾種方法來進行系統統計，每種方法都各有其優缺點。

◆ 使用現有的工具

標準及非標準工具能執行一個或多個收集、合併及傳輸階段，如rstatd或SNMP工具，然而標準的rstat後臺程式提供的資訊是有限的，速度慢而且效率低。

◆ 核心模組

幾個系統監控工程利用核心模組來存取監控資料。一般情況下，這是很有效的收集系統資料的方法。然而這種方法存在的問題是，當主核心源內有其它改變時，必須保持程式碼一致性。一個核心模組可能與使用者想使用的其它核心模組相沖突。此外，在使用監控系統之前，使用者必須獲得或申請模組。

◆ /proc虛擬檔案系統

/proc 虛擬檔案系統是一個較快的、高效率執行系統監控的方法。使用/proc的主要缺點是必須保持程式碼分析與/proc 檔案格式改變的同步。事實表明，Linux核心的改變比/proc 檔案格式的改變要更頻繁，所以，用/proc虛擬檔案系統比用核心模組存在的問題要少。

◆ 混合系統

某些監控系統採用混合方式，用核心模組收集資料，用/proc虛擬檔案系統作為資料介面。

2．合併階段

合併階段的實現可以在結點上、叢集管理的主機上，或者分佈在兩者上。考慮到效率，我們只採用在結點上的合併。原因在於結點是監控資料的收集器與提供者。兩個或多個同時的資料請求不會引起兩次作業系統呼叫來收集資料，而是將第一次請求獲得的資料快取，並可以提供給第二次請求呼叫。這種方法減少了作業系統的負擔，提高了監控系統的響應性。合併階段也可以用於將多個資料來源的資料以相互獨立的收集速率結合，因為並不是所有的資料都以同樣的速度改變，或者需要以同樣的速率收集。

使用在結點層上合併的另一個原因是，減少了包括傳輸在內的資訊量。許多/proc檔案既包含動態資料也包含靜態資料。刪除最近一次傳輸後沒有改變的值，一個結點傳送的資料量可以大大地減少。合併不僅除去了不經常改變的動態值的傳輸，也解決了從不改變的靜態值的傳輸。

3.傳輸階段

監控資料幾乎總是按一個層次結構組織起來。傳輸階段的任務就是將層次資料進行有效的編碼，形成一種能高效傳輸的資料格式。Java擁有的檔案格式是儲存層次資料的有效方法，並且用提供的Java APIs很容易完成。S-Expressions已經被認為是傳輸這種資料的另一個有效的方法。

關於傳輸監控資料普遍討論的問題是，資料應該按二進位制編碼還是按文字格式編碼。二進位制資料更容易壓縮，因此也能更有效地傳輸。但是，當採用/proc檔案系統時，監控資料通常以人們易讀的格式儲存。在傳輸之前，將資料轉換為二進位制格式將需要更多的處理資源與時間。以文字格式保留收集的資料，結點資源能被用於更多非監控性的相關工作。

採用文字格式的資料將提供如下額外的益處：

◆ 平臺獨立性

當監控異構叢集時，機器之間資料位元組指令的配置不是永遠相同的。文字格式的使用在程式碼方面解決了這個問題，而且體系結構獨立不會影響更多的處理需求。

◆ 易讀的格式

文字資料能以人們易讀的格式進行組織。如果需要的話，這種特徵能容易地進行程式除錯或允許使用者觀看資料流。

◆ 有效壓縮

數值資料的文字表示由來自10個位元組集中的字元組成，而不是二進位制下的256個位元組集。它們產生的數字及模式的相對頻率允許有效地使用基於壓縮演算法的字典及熵（平均資訊量）。

/proc虛擬檔案系統

/proc虛擬檔案系統（也叫procfs）是Unix作業系統所使用的虛擬檔案系統的Linux實現，包括Sun Solaris、LinuxBSD。在/proc開始時，它以一個標準檔案系統出現，幷包含與正在執行的程式IDs同樣名字的檔案。然而，在/proc中的檔案不佔用磁碟空間，它們存在於工作儲存器（記憶體）中。/proc最初的目的是便於程式資訊的存取，但是現在，在Linux中，它可被核心的每一部分使用來報告某些事情。

在/proc檔案系統提供的成百上千的值當中，我們將集中考慮叢集監控所需的最小集，它們包括：

◆ /proc/loadavg：包含系統負載平均值；

◆ /proc/meminfo：包含儲存管理統計量；

◆ /proc/net/dev：包含網路卡度量；

◆ /proc/stat：包含核心統計量；

◆ /proc/uptime：包含總的系統正常工作時間及空閒時間。

每個檔案提供的值的數量是不同的。這些檔案的完整有效值列表如下。

◆ /proc/loadavg提供以下資料：

1秒鐘平均負載；

5秒鐘平均負載；

15秒鐘平均負載；

總作業數；

正在執行的作業總數。


◆ /proc/meminfo提供的儲存器資訊包括：

活動儲存器；

不活動儲存器；

緩衝儲存器；

高速緩衝儲存器；

總的自由儲存器；

總的高位儲存器；

自由高位儲存器；

總的低位儲存器；

自由低位儲存器；

共享儲存器；

交換儲存器；

交換高速緩衝儲存器；

交換自由儲存器；

總儲存器。

◆ /proc/net/dev中包括每個網路卡的如下資料：

接收到的位元組；

接收到的壓縮位元組；

收到的誤碼數；

收到的漏失誤碼；

收到的FIFO誤碼；

收到的幀誤碼；

收到的多播誤碼；

收到的總包數；

已傳輸的位元組；

已傳輸的壓縮位元組；

傳輸誤碼總數；

傳輸載波誤碼；

傳輸衝突誤碼；

傳輸漏失誤碼；

傳輸FIFO誤碼；

傳輸的總包數。


◆ /proc/stat提供：

引導時間；

上下文切換數量；

中斷總量；

進頁面總數；

出頁面總數；

程式總數；

換入總數；

換出總數；

合計CPU空閒時間；

合計CPU nice時間；

合計CPU系統時間；

合計CPU使用者時間。

同時提供對每個CPU的:

單個CPU空閒時間；

單個CPU nice時間；

單個CPU系統時間；

單個CPU使用者時間。

以及對每個磁碟驅動器的如下資料：

單個磁碟塊讀；

單個磁碟塊寫；

單個磁碟I/O總數；

單個磁碟I/O讀；

單個磁碟I/O寫。


◆ /proc/uptime中包括：

系統總工作時間；

系統總空閒時間。

值得注意的是，每次某個/proc被讀時，一個控制程式碼函式都被核心或特有模組呼叫,來產生資料。資料在執行中產生，不管是讀一個字元還是一個大的字塊，整個檔案都將被重建。這對效率是至關重要的一點，因為使用/proc的任何系統監控器將吞下整個檔案，而不是一點一點地處理它。

Java提供了豐富的檔案I/O類集，包括基於類的流、基於類的塊裝置，以及J2SDK 1.4提供的新的I/O庫。實驗表明，一般而言，對基本的塊讀寫檔案操作，用RandomAccessFile類進行I/O是最佳的。例如，塊讀檔案操作如下：

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

//以讀方式開啟檔案

mFile.read( mBuffer ); //讀檔案塊


結論

本文討論瞭如何將Java語言有效地用於Linux叢集結點上的高效能監控。在程式設計中，要注意以下方面：

◆ 採用/proc檔案系統；

◆ 以塊形式讀/proc檔案，而不是以行或字元形式；

◆ 在讀檔案期間保持檔案開啟；

◆ 消除不必要的資料轉換；

◆ 在結點上合併資料；

◆ 以壓縮形式傳輸資料；

◆ 注意與效能問題相關的語言或庫。

對高效能監控而言，核心模組不是必要條件，這點很重要，因為它在Linux版本和分類之間提供了很大程度的可移植性，在監控器實現語言上有很多的選擇。但是，/proc檔案系統的效能卻很依賴核心程式碼的效率，因此，適當地理解有關的機制將對以任何語言編寫的監控器效能有非常大的影響。