當出現奇怪的現象時,使用者可能會搞不清楚狀況,尤其是剛剛開始使用 High Availability 的使用者。不過,您可以借助幾個公用程式來深入瞭解 High Availability 的內部程序。本章推薦了各種解決方案。
疑難排解安裝套件或使叢集上線時所遇到的問題。
設定和管理叢集所需的套件包含於高可用性安裝模式中,隨 High Availability Extension 一起提供。
請檢查 High Availability Extension 是否已在各叢集節點上安裝為 SUSE Linux Enterprise Server 12 的附加產品,以及模式是否已依第 3.3 節「安裝為附加產品」 所述安裝於各機器上。
為了能夠相互通訊,屬於同一叢集的所有節點均需使用相同的 bindnetaddr、mcastaddr 與 mcastport,如第 3.5 節「手動設定叢集 (YaST)」 中所述。
請檢查 /etc/corosync/corosync.conf 中為所有叢集節點設定的通訊通道與選項是否都相同。
若使用加密通訊,請檢查是否所有叢集節點上的 /etc/corosync/authkey 檔案都可使用。
除 nodeid 以外的所有 corosync.conf 設定都必須相同;所有節點上的 authkey 檔案都必須相同。
mcastport 進行通訊嗎?若用於在各叢集節點間通訊的 mcastport 被防火牆阻擋,這些節點將無法相互查看。依照第 3.5 節「手動設定叢集 (YaST)」和第 3.4 節「自動設定叢集 (ha-cluster-bootstrap)」所述使用 YaST 或開機程序檔進行初始設定時,防火牆設定通常會自動進行調整。
若要確保 mcastport 不被防火牆阻擋,請檢查各節點上 /etc/sysconfig/SuSEfirewall2 中的設定。或者,啟動各叢集節點上的 YaST 防火牆模組。按一下 › 之後,將 mcastport 新增至允許的清單,然後確認變更。
通常,啟動 Pacemaker 也會啟動 Corosync 服務。若要檢查這兩個服務是否在執行,請使用以下指令:
root #systemctlstatus pacemaker.service corosync.service
如果它們未在執行,請執行以下指令將其啟動:
root #systemctlstart pacemaker.service
對於 Pacemaker 記錄檔案,請查看 /etc/corosync/corosync.conf 的 logging 區段中的設定。若 Pacemaker 忽略了該處指定的記錄檔案,請查看 Pacemaker 自己的組態檔案 /etc/sysconfig/pacemaker 中的記錄設定。如果該組態檔案中設定了 PCMK_logfile,Pacemaker 將使用此參數定義的路徑。
如果您需要一份顯示所有相關記錄檔案的叢集層級報告,請參閱如何建立一份包含所有叢集節點分析資訊的報告?以瞭解詳細資訊。
除非有錯誤發生,否則 lrmd 精靈不會記錄週期性的監控操作。記錄所有週期性操作會產生太多干擾。因此,該精靈只會每小時記錄一次週期性監控操作。
失敗訊息。能取得詳細資訊嗎? 請將 --verbose 參數新增至您的指令。若多次執行此操作,將產生非常詳細的除錯輸出。請參閱記錄資料 (sudo journalctl -n) 以獲取有用提示。
請使用 crm_mon 指令。以下指令將顯示資源操作歷程 (選項 -o) 和非使用中資源 (-r):
root #crm_mon-o -r
狀態變更時,顯示畫面會重新整理 (若要取消此功能,請按 Ctrl–C)。範例顯示內容如下:
Last updated: Fri Aug 15 10:42:08 2014
Last change: Fri Aug 15 10:32:19 2014
Stack: corosync
Current DC: bob (175704619) - partition with quorum
Version: 1.1.12-ad083a8
2 Nodes configured
3 Resources configured
Online: [ alice bob ]
Full list of resources:
my_ipaddress (ocf::heartbeat:Dummy): Started barett-2
my_filesystem (ocf::heartbeat:Dummy): Stopped
my_webserver (ocf::heartbeat:Dummy): Stopped
Operations:
* Node bob:
my_ipaddress: migration-threshold=3
+ (14) start: rc=0 (ok)
+ (15) monitor: interval=10000ms rc=0 (ok)
* Node alice:http://www.clusterlabs.org/doc/ 上《Pacemaker Explained (Pacemaker 1.1 for Corosync 2.x and crmsh)》(Pacemaker 說明 (適用於 Corosync 2.x 與 crmsh 的 Pacemaker 1.1)) PDF 檔案的「How are OCF Return Codes Interpreted?」(如何解譯 OCF 傳回代碼?) 一節介紹了三種不同的復原類型。
請使用以下指令:
root #crmresource list crm resource cleanup rscid [node]
如果不指定節點,系統會清理所有節點上的資源。如需詳細資訊,請參閱第 6.5.2 節「清理資源」。
使用指令 crm resource list 即可顯示目前資源。
若要使用 ocf-tester 檢查 OCF 程序檔,例如︰
ocf-tester -n ip1 -o ip=YOUR_IP_ADDRESS \ /usr/lib/ocf/resource.d/heartbeat/IPaddr
若需納入多個參數,可以使用多個 -o。執行 crm ra info 代辦,可顯示必需參數和可選參數的清單,指令範例如下︰
root #crmra info ocf:heartbeat:IPaddr
在執行 ocf-tester 之前,請確定該資源不受叢集管理。
如果您的叢集是雙節點叢集,則終止其中一個節點,另一個節點仍不能滿足最低節點數要求。除非您將 no-quorum-policy 內容設定為 ignore,否則任何事情都不會發生。對於雙節點叢集,您需要:
property no-quorum-policy="ignore"
另一種可能是,終止的節點被視為未清理節點。如果是這樣,就必須對它進行圍籬區隔。如果 STONITH 資源無法正常運作或者不存在,則另一個節點將會等待發生圍籬區隔。圍籬區隔逾時值通常設定得很大,因此可能經過很長一段時間後才會發生明顯的問題跡象 (如果最終會出現的話)。
另外還有一種可能,那就是此節點上不允許執行某個資源。這可能是因為之前曾發生了失敗,而此失敗尚未得到「清理」。或者,可能是之前執行了某個管理動作,即新增了分數為負數的位置條件約束。例如,使用 crm resource migrate 指令插入了這樣的位置條件約束。
如果資源不存在位置條件約束,則其投放至的節點 (基本上) 是由系統隨機選擇的。強烈建議您總是為資源指定一個偏好節點。這並不意味著您需要為所有資源指定位置偏好設定。對於一組相關 (並存) 的資源,一個偏好設定就已足夠。節點偏好設定如下所示:
location rsc-prefers-alice rsc 100: alice
啟動 (或啟用) 操作的過程會檢查裝置狀態。如果裝置未就緒,STONITH 資源將無法啟動。
此外,系統會要求 STONITH 外掛程式產生一份主機清單。如果此清單為空,則執行 STONITH 資源將毫無意義,因為這無法關閉任何節點。清單中會過濾掉執行 STONITH 的主機名稱,因為節點不能關閉自身。
如果您想要使用單主機管理裝置 (如無人職守裝置),請確認 STONITH 資源不得在應當圍籬區隔的節點上執行。請使用負無限位置節點偏好設定 (條件約束)。叢集會將 STONITH 資源移至另一個可以啟動該資源的位置,但移動前會向您發出通知。
每個 STONITH 資源必須提供一個主機清單。您可以手動將此清單插入 STONITH 資源組態中,也可以從裝置自身 (例如,從插座名稱) 擷取。這取決於 STONITH 外掛程式的特性。stonithd 使用該清單來確定哪個 STONITH 資源可以圍籬區隔目標節點。僅當目標節點包含在該清單中時,STONITH 資源才會停止 (圍籬區隔) 該節點。
如果 stonithd 在 STONITH 資源執行後所提供的任何主機清單中都找不到該節點,它會詢問其他節點上的 stonithd 例項。如果其他 stonithd 例項的主機清單中也未包含目標節點,則圍籬區隔要求最終會在發出要求的節點上逾時。
如果廣播流量過多,電源管理裝置可能無法回應。請增大監控操作的間隔。假設圍籬區隔在一段時間內只需執行一次 (甚至永遠無需執行),每隔幾小時檢查一次裝置狀態就已足夠。
另外,其中的一些裝置可能拒絕同時與多方通訊。如果叢集嘗試測試狀態時,您將終端機或瀏覽器工作階段保持為開啟狀態,這便可能會產生問題。
請使用 pssh 指令來完成此項任務。如果需要,請安裝 pssh。建立一個檔案 (例如 hosts.txt),將您要造訪的所有 IP 位址或主機名稱都收集在其中。確定您可以使用 ssh 登入 hosts.txt 檔案中所列的每個主機。如果所有工作均已準備妥當,請依照以下範例執行 pssh 並使用 hosts.txt 檔案 (選項 -h) 和互動模式 (選項 -i):
pssh -i -h hosts.txt "ls -l /corosync/*.conf" [1] 08:28:32 [SUCCESS] root@venus.example.com -rw-r--r-- 1 root root 1480 Nov 14 13:37 /etc/corosync/corosync.conf [2] 08:28:32 [SUCCESS] root@192.168.2.102 -rw-r--r-- 1 root root 1480 Nov 14 13:37 /etc/corosync/corosync.conf
若要查看叢集目前的狀態,請使用程式 crm_mon 或 crm status。此時會顯示目前 DC,以及目前節點已知的所有節點與資源。
導致的原因有多種:
請先查看組態檔案 /etc/corosync/corosync.conf。檢查叢集內各節點的多路廣播或單點傳播位址是否相同 (使用關鍵字 mcastaddr 在 interface 區段中尋找)。
檢查防火牆設定。
檢查交換器是否支援多路廣播或單點傳播位址。
檢查節點之間的連線是否中斷。最常見的原因是防火牆設定不正確。這還可能是導致電腦分裂狀況的原因,其中的叢集被分區。
檢查記錄訊息 (sudo journalctl -n) 中是否包含以下行:
Jan 12 09:58:55 alice lrmd: [3487]: info: RA output: [...] ERROR: Could not load ocfs2_stackglue Jan 12 16:04:22 alice modprobe: FATAL: Module ocfs2_stackglue not found.
此案例中缺少了核心模組 ocfs2_stackglue.ko。請根據所安裝的核心安裝套件 ocfs2-kmp-default、ocfs2-kmp-pae 或 ocfs2-kmp-xen。
在 crm 外圍程序中,使用 crm_report 或 hb_report 建立報告。這些工具用於編譯:
整個叢集的記錄檔案
套件狀態
DLM/OCFS2 狀態
系統資訊,
CIB 歷程
磁心傾印報告的剖析結果 (如果已安裝 debuginfo 套件)
通常情況下需要結合以下指令執行 hb_report:
root #crm_report-f 0:00 -n jupiter -n venus
該指令會擷取主機 jupiter 和 venus 中從凌晨 0 點開始的所有資訊,並在目前的目錄中建立一個名為 crm_report-日期.tar.bz2 的 *.tar.bz2 歸檔,例如,crm_report-Wed-03-Mar-2012。如果只需要特定時間範圍的資訊,請使用 -t 選項新增結束時間。
crm_report 工具會嘗試從 CIB 和 peinput 檔案中移除任何敏感性資訊,但它無法做到一切。如果您還有更多敏感性資訊,請提供其他模式。記錄檔案以及 crm_mon、ccm_tool 和 crm_verify 輸出不會被清理。
在以任何方式共享您的資料之前,請先檢查歸檔,並移除您不想公開的所有資訊。
可以使用其他選項自定指令。例如,如果您有一個 Pacemaker 叢集,那麼您肯定想新增 -A 選項。如果您的另一個使用者有權存取該叢集,請使用 -u 選項並指定此使用者 (不同於 root 和 hacluster 使用者)。如果您有一個非標準 SSH 連接埠,請使用 -X 選項新增該連接埠 (例如,如果連接埠為 3479,則使用 -X "-p 3479")。如需瞭解更多選項,請參閱 crm_report 的 man 頁面。
在 crm_report 分析了所有相關記錄檔案並建立了目錄 (或歸檔) 之後,請檢查記錄檔案中是否有大寫的 ERROR 字串。報告的上層目錄中最重要的檔案包括:
analysis.txt
比較檔案,所有節點上都應相同。
crm_mon.txt
包含 crm_mon 指令的輸出。
corosync.txt
包含 Corosync 組態檔案的副本。
description.txt
包含各節點上所有的叢集套件版本。還有一個特定於節點的 sysinfo.txt 檔案。它連結至頂層目錄。
特定於節點的檔案儲存在以節點名稱命名的子目錄中。
如需有關 Linux 上高可用性的其他資訊,包括設定叢集資源及管理和自定高可用性叢集,請參閱 http://clusterlabs.org/wiki/Documentation。