叢集手冊/叢集監控

叢集監控

本章的主題是叢集監控，這是一個非常多功能的主題。有大量的軟體可用於監控分散式系統。然而，很難找到一個專案能夠為所有需求提供解決方案。這些需求中可能包括以高效的方式從高效能叢集中收集儘可能多的關於“工作節點”利用率的指標。在這種情況下，效率並非毫無意義的廣告詞 - 它非常重要。沒有人願意忍受負載不均衡，僅僅是因為收集了一些用於建立圖表的資料，高效能計算在這方面的優先順序非常明確。另一個必要條件可能是觀察某些不能超過特定閾值的事物。這些事物可能是用於冷卻 CPU 等裝置的冷卻水的溫度，或者硬碟驅動器上分配的空間。理想情況下，監控軟體應該能夠在值超過閾值時啟動應對措施。在本課程中，將在虛擬機器叢集上安裝兩種不同的監控解決方案。首先，測試了廣為使用的 Nagios 的分支 Icinga。之後，使用 Ganglia。這兩種解決方案都是開源的，並且在它們提供的功能方面有很大的不同。

圖 4.1 提供了所用叢集（虛擬機器）和所用軟體的概述。所有節點都使用最新的 Ubuntu LTS^[1] 版本。在 Ganglia 的情況下，軟體版本為 3.5，是最新的版本，因此是從原始碼編譯的。對於 Icinga，使用版本 1.8.4。

Icinga

Icinga^[2] 是一個開源監控解決方案。它是 Nagios 的一個分支，並保持向後相容性。因此，所有 Nagios 外掛也可以與 Icinga 一起使用。Ubuntu 12.04 中官方 Ubuntu 儲存庫提供的版本是 1.6.1。要獲得更當前的版本，將使用個人軟體包檔案 (PPA) 提供的軟體包。^[3]

安裝

由於提供了 PPA，安裝非常簡單。只遇到一個小的麻煩。官方指南 </ref> 建議使用 Ubuntu 的軟體包安裝 Icinga，如下所示

清單 4.1 建議在 Ubuntu 上安裝 Icinga 的軟體包順序。

apt-get install icinga icinga-doc icinga-idoutils postgresql libdbd-pgsql postgresql-client 不幸的是，這失敗了，因為 icinga-idoutils 的軟體包安裝需要一個工作的資料庫（PostgreSQL 或 MySQL）。因此，必須更改軟體包的順序，或者只在 Icinga 之前安裝 PostgreSQL。

配置

安裝 Icinga 後，提供的 Web 介面立即可以訪問（使用埠轉發訪問虛擬機器）。預設情況下，一些外掛被啟用以監控安裝了 Icinga 的主機。

圖 4.2 顯示了主節點上這些外掛的服務狀態詳細資訊。讓 Icinga 監控遠端主機（工作節點）需要更多的配置。檢視 Icinga 配置資料夾發現如何配置主節點以顯示圖 [fig:default_plugins] 中的資訊。資訊分為兩部分：主機識別和服務規範。主機識別包括 host_name、address 和 alias。服務由 host_name、service_description 和 check_command 指定。check_command 接受 Nagios 外掛或自定義外掛，這些外掛必須在另一個 Icinga 配置檔案中配置：commands.cfg。

圖 4.3 顯示了修改後的預設配置檔案中用於主節點的一些重要部分。可以看出，主機和服務部分都以 use 語句開頭，它代表將要使用的模板。Icinga 附帶一個用於主機和服務的預設（通用）模板，這對我們來說已經足夠了。

現在出現了一個問題：如何實現圖 4.4 中所示的設定。我們希望使用 Icinga 監控我們的工作節點。為此，Icinga 提供了兩種不同的方法，它們以相同的方式工作，但使用不同的技術。無論哪種情況，主節點上執行的 Icinga 都定期向工作節點請求資料。另一種方法是，Icinga 只監聽資料，工作節點自己啟動通訊。這兩種不同的方法是 SSH^[4] 和 NRPE。^[5] 手冊中比較了這兩種方法，並推薦使用 NRPE，代價是配置工作量增加。NRPE 導致的 CPU 開銷更少，而 SSH 另一方面幾乎可以在每臺 Linux 機器上使用，因此不需要配置。對於我們的目的，減少 CPU 開銷是一個優勢，因此使用 NRPE。接下來的部分將介紹如何配置 Icinga 以使用 NRPE 監控遠端主機。

主節點

為了使用 NRPE，必須在主節點上安裝額外的軟體。軟體包 nagios-nrpe-plugin 為 Icinga 提供了使用 NRPE 從遠端主機收集資料的可能性。不幸的是，該軟體包是 Nagios 的一部分，因此在安裝時，整個 Nagios 專案應該作為依賴項安裝。幸運的是，使用 apt-get 的選項 –no-install-recommends，我們可以跳過這些軟體包的安裝。現在安裝的軟體包提供了一個新的 check_command，它可以在為新主機定義服務時使用：check_nrpe。該命令可用於在主機部分指定的遠端主機上執行 Nagios 外掛或自定義命令。如圖 [fig:flo_ahc_icinga_components] 所示，我們希望能夠檢查“gmond”（下一個監控解決方案 Ganglia 的守護程序），以及兩個 NFS 資料夾（/opt 和 /home）是否已正確掛載。為此，我們建立一個新的配置檔案 /etc/icinga/objects，在本例中為 worker1.cfg，並將圖 [fig:host_service_config] 中所示的主機部分更改為所需工作節點的主機名和 IP。服務部分中的 check_command 必須按以下方式使用

清單 4.2 工作節點配置檔案中的 NRPE 檢查命令。

check_command check_nrpe_1arg!check-nfs-opt NRPE 命令接受一個引數（因此為 _1arg）：將在主機部分指定的遠端主機上執行的命令。在本例中，該命令為 check-nfs-opt，它不是 Nagios 外掛軟體包的一部分，而是一個自定義 shell 指令碼。接下來的部分將描述在 check-nfs-opt 工作之前必須在遠端主機上進行的必要配置。

工作節點

工作節點上也必須安裝額外的軟體。為了能夠響應來自主節點的 NRPE 命令，必須安裝軟體包 nagios-nrpe-server。該軟體包提供 Nagios 外掛和一個響應來自主節點的 NRPE 請求的服務。我們不會使用 Nagios 外掛，而是編寫三個基本的 shell 指令碼，以確保（如圖 [fig:flo_ahc_icinga_components] 所示）

Ganglia 的 gmond 服務正在執行。
\opt 和 \home 都已使用來自主節點的 NFS 正確掛載。

在我們定義這些命令之前，必須允許主節點連線到我們的工作節點

清單 4.3 將主節點的 IP 地址新增到 /etc/nagios/nrpe.cfg。

allowed_hosts=127.0.0.1,!\colorbox{light-gray}{10.0.1.100}! 之後我們可以編輯檔案 /etc/nagios/nrpe_local.cfg 併為這三個指令碼新增別名和路徑。這些命令將在指定別名下對主節點可用。

清單 4.4 向 /etc/nagios/nrpe_local.cfg 新增自定義命令

command[check-gmond-worker]=/opt/check-gmond.sh command[check-nfs-home]=/opt/check-nfs-home.sh command[check-nfs-opt]=/opt/check-nfs-opt.sh 這是在工作節點上需要做的所有事情。可以使用主節點上的一個簡單命令來檢查是否已正確設定，如清單 [lst:nrpe_check] 所示。

清單 4.5 使用 check_nrpe 檢查 NRPE 是否已正確設定。

ehmke@master:/etc/icinga/objects$ /usr/lib/nagios/plugins/check_nrpe -H 10.0.1.2 CHECK_NRPE: Error - Could not complete SSL handshake. 不幸的是，在我們的例子中，需要一些額外的步驟，因為上述命令從每個工作節點返回錯誤。在工作節點上開啟（並再次關閉）除錯模式後（/etc/nagios/nrpe.cfg 中的 debug=1），該命令返回 NRPE 版本，並且一切按預期工作。這是一種奇怪的行為，尤其是在必須對每個工作節點執行時。

清單 4.6 check_nrpe 成功！。

ehmke@master:/etc/icinga/objects$ /usr/lib/nagios/plugins/check_nrpe -H 10.0.1.2 NRPE v2.12

用法

圖 4.5 顯示了所有主機的服務狀態詳細資訊。我們的自定義命令都按預期工作。如果情況並非如此，它們將顯示為 ido2db 程序。該服務的狀況至關重要，這一點一目瞭然。Icinga 外掛 API^[6] 允許 4 種不同的返回狀態。

OK
WARNING
CRITICAL
UNKNOWN

除了返回程式碼之外，還可以返回一些文字輸出。在我們的例子中，我們只返回“一切正常！”。檢查 ido2db 程序的外掛使用該文字輸出為關鍵服務狀態提供一個原因，這是相當直觀的。

Ganglia

Ganglia 是一個開源的分散式監控系統，專門為高效能計算而設計。它依賴於 RRDTool 進行資料儲存和視覺化，並且在所有主要發行版中都可用。最新版本添加了一些有趣的功能，因此我們沒有使用官方 Ubuntu 儲存庫提供的舊版本。

安裝

Ganglia 的安裝非常簡單。我們下載了 Ganglia^[7] 和 RRDTool^[8] 的最新軟體包，RRDTool 用於生成漂亮的圖表。RRDTool 本身也需要安裝 libconfuse。在編譯（沒有設定特殊的配置標誌）和安裝之後，我們必須將 RRDTool 整合到環境中，以便 Ganglia 可以使用它。這通常意味著調整環境變數 PATH 和 LD_LIBRARY_PATH。出於個人喜好，我們選擇了另一種解決方案，如清單 [lst:rrd_env] 所示。

清單 4.7 將 RRDTool 整合到環境中。

echo '/opt/rrdtool-1.4.7/lib' >> /etc/ld.so.conf.d/rrdtool.conf ldconfig ln -s /opt/rrdtool-1.4.7/bin/rrdtool /usr/bin/rrdtool Ganglia 還需要 libconfuse 和 libapr。兩者也必須安裝在工作節點上。在配置期間，指定 –with-gmetad 很重要。

清單 4.8 安裝 Ganglia。

./configure --with-librrd=/opt/rrdtool-1.4.7 --with-gmetad --prefix=/opt/ganglia-3.5.0 make sudo make install

配置

Ganglia 由兩個主要元件組成：gmond 和 gmetad。Gmond 是一個監控守護程序，它必須在每個要監控的節點上執行。Gmetad 是一個守護程序，它輪詢其他 gmond 守護程序並將它們的資料儲存在 rrd 資料庫中，然後這些資料庫用於在 Ganglia Web 介面中視覺化資料。目標是按照圖 [fig:flo_ahc_ganglia_components] 所示配置 Ganglia。主節點執行兩個 gmond 守護程序，一個專門用於收集來自主節點的資料，另一個用於收集來自工作節點上執行的 gmond 守護程序的資料。我們在 /opt 中安裝了 Ganglia，該目錄透過 NFS 安裝在每個工作節點上。為了在主節點和工作節點上啟動 gmond 和 gmetad 程序，使用了初始化指令碼。問題是，下載的 tar 包中沒有提供合適的初始化指令碼。我們最初的想法是從 Ubuntu 儲存庫中提取（較舊）軟體包的初始化指令碼。該初始化指令碼不能按預期工作。重新啟動和停止 gmond 服務會導致主節點出現問題，因為那裡正在執行 2 個 gmond 程序。它們不是透過服務的 pid 來被殺死的，而是透過名稱來殺死的，這顯然不是一個好主意。我們試圖手動更改行為，但不幸的是，這不起作用。在 gmond 程序啟動後，初始化系統會讀取啟動服務的 pid 並將其儲存在 gmond.pid 檔案中。問題是，gmond 程序在啟動後會變成守護程序並更改執行使用者（從 root 更改為 nobody）。這些操作也會更改 pid，這意味著 .pid 檔案不再有效，停止和重新啟動服務將無法工作。經過大量的嘗試和錯誤，我們在最新的（尚未釋出的）Ubuntu 版本 13.04 中找到一個有效的 upstart（Ubuntu 使用的新初始化系統）指令碼。在該指令碼中，我們只需要調整服務名稱並確保在啟動服務之前 NFS 分割槽已掛載（start on (mounted MOUNTPOINT=/opt and runlevel [2345])）。出於某種神奇的原因，這種設定即使在主節點上也適用於兩個 gmond 程序。

主節點

我們首先配置 gmetad 守護程序。我們指定了兩個資料來源：“基礎設施”（主節點）和“叢集節點”（工作節點）。Gmetad 從主節點上執行的兩個 gmond 程序中收集這些資料來源的資料。為了防止衝突，兩者都在不同的埠上接受連線：8649（基礎設施）和 8650（叢集節點）。我們還調整了網格名稱和儲存 rrd 資料庫的目錄。

清單 4.9 gmetad.conf 中的有趣部分。

data_source "Infrastructure" localhost:8649 data_source "Cluster Nodes" localhost:8650 gridname "AHC Cluster" rrd_rootdir "/opt/ganglia/rrds" 下一步是配置主節點上的 gmond 程序：gmond_master 和 gmond_collector。由於 gmond_master 程序不與其他 gmond 通訊，因此不需要進行通訊配置。我們只需要指定一個 tcp_accept_channel，gmond 在該通道上響應 gmetad 的查詢。此外，可以為主機、叢集和所有者指定名稱，並提供位置（例如特定的機架）。

清單 4.10 gmond_master.conf 的配置。

tcp_accept_channel {
    port = 8649
}

gmond_collector 程序需要與四個 gmond_worker 程序進行通訊。Ganglia 中存在兩種不同的通訊方法：單播和組播。我們選擇了單播，設定起來很簡單。gmond_collector 程序還必須接受來自 gmetad 程序的查詢，因此我們指定了另一個 tcp_accept_channel。在指定的 udp_recv_channel 上，gmond_collector 等待來自 gmond_worker 程序的資料。

清單 4.11 gmond_collector.conf 的配置。

tcp_accept_channel {
    port = 8650
}
udp_recv_channel {
    port = 8666
}

工作節點

gmond_worker 程序既不監聽其他 gmond 程序，也不接受來自 gmetad 守護程序的查詢。因此，配置檔案中唯一有趣的部分是該 gmond 守護程序的傳送機制。

清單 4.12 gmond_worker.conf 的配置。

udp_send_channel {
    host = master
    port = 8666
    ttl = 1
}

用法

Ganglia 預設情況下已經收集和可視化了有關 CPU、記憶體、網路和儲存的資料。還可以使用自定義外掛擴充套件監控功能。收集到的資料可以在許多隻有單個數據源的小圖表中檢視，或者在更大的聚合“報告”中檢視。

ganglia 的首頁顯示了整個網格和“子叢集”的許多聚合報告。圖 4.7 顯示了該首頁，從該頁面可以導航到單獨的子叢集以及特定的節點。該頁面上的報告還顯示了一些有趣的細節。例如，主節點每 5 分鐘會有一些出站網路流量。預設情況下，所有報告都會顯示過去一小時的資料，但也可以顯示過去 2/4 小時、一週、一個月或一年的資料。

圖形聚合

一個特別有趣的功能是自定義圖形聚合。假設有一個報告可以視覺化所有（例如 10 個）可用節點的 CPU 使用率。如果你執行一個需要其中四個節點的作業，你可能對另外 6 個節點的資料不感興趣。使用 Ganglia，你可以建立一個自定義報告，該報告只匹配你使用正則表示式指定的節點。

如果這還不夠，還可以建立完全自定義的聚合圖形，你可以在其中指定使用的指標、軸限制和標籤、圖形型別（線或堆疊）和節點。在圖 [fig:graph_aggregation] 中，我們指定了這樣的一個圖形。我們選擇了一個自定義標題，將 Y 軸標籤設定為百分比，將軸下限和上限設定為 0 和 100，並將系統 CPU 使用率設定為指標。也可以選擇多個指標，只要組合有意義即可。

參考資料

↑ 長期支援
↑ https://www.icinga.org/
↑ https://launchpad.net/ formorer/+archive/icinga
↑ 安全外殼
↑ Nagios 遠端外掛執行器
↑ http://docs.icinga.org/latest/en/pluginapi.html
↑ http://ganglia.sourceforge.net/
↑ http://oss.oetiker.ch/rrdtool/

[1] 長期支援

[2] ttps://www.icinga.org/

[3] ttps://launchpad.net/ formorer/+archive/icinga

[4] 安全外殼

[5] Nagios 遠端外掛執行器

[6] ttp://docs.icinga.org/latest/en/pluginapi.html

[7] ttp://ganglia.sourceforge.net/

[8] ttp://oss.oetiker.ch/rrdtool/

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]