開始使用
疑難排解
建議變更
PDF
BeeGFS HA叢集疑難排解。
總覽
本節將說明如何調查及疑難排解在操作BeeGFS HA叢集時可能發生的各種故障和其他情況。
疑難排解指南
正在調查意外的容錯移轉
當節點被意外隔離、其服務移至另一個節點時、第一步應該是查看叢集是否在底部顯示任何資源故障 pcs status。通常、如果成功完成隔離並在另一個節點上重新啟動資源、則不會出現任何情況。
一般而言、下一步是使用來搜尋整個系統記錄 journalctl 在其餘任一檔案節點上（所有節點上的心臟起搏器記錄都會同步）。如果您知道故障發生的時間、可以在故障發生前立即開始搜尋（建議至少提前10分鐘）：
journalctl --since "<YYYY-MM-DD HH:MM:SS>"下列各節顯示您可以在記錄中加入的一般文字、以進一步縮小調查範圍。
調查/解決的步驟
步驟1：檢查BeeGFS監視器是否偵測到故障：
如果容錯移轉是由BeeGFS監控器觸發、您應該會看到錯誤（如果沒有、請繼續下一步）。
journalctl --since "<YYYY-MM-DD HH:MM:SS>" | grep -i unexpected
[...]
Jul 01 15:51:03 ictad22h01 pacemaker-schedulerd[9246]: warning: Unexpected result (error: BeeGFS service is not active!) was recorded for monitor of meta_08-monitor on ictad22h02 at Jul 1 15:51:03 2022在此例中、BeeGFS服務meta_08因為某些原因而停止。若要繼續進行疑難排解、我們應該開機ictad22h02並檢閱服務記錄、網址為 /var/log/beegfs-meta-meta_08_tgt_0801.log。例如、BeeGFS服務可能因為內部問題或節點問題而發生應用程式錯誤。
|
不同於來自心臟起搏器的記錄、BeeGFS服務的記錄不會分散到叢集中的所有節點。若要調查這些故障類型、必須從發生故障的原始節點取得記錄。 |
監視器可能回報的問題包括：
-
無法存取目標！
-
說明：表示無法存取區塊磁碟區。
-
疑難排解：
-
如果服務也無法在替代檔案節點上啟動、請確認區塊節點正常運作。
-
請檢查是否有任何實體問題、以免從此檔案節點存取區塊節點、例如發生故障的InfiniBand介面卡或纜線。
-
-
-
無法連線到網路！
-
說明：用戶端用來連線至此BeeGFS服務的介面卡均未連線。
-
疑難排解：
-
如果有多個/所有檔案節點受到影響、請檢查網路上是否有故障用於連接BeeGFS用戶端和檔案系統。
-
請檢查是否有任何實體問題、例如會使此檔案節點無法存取用戶端、例如發生故障的InfiniBand介面卡或纜線。
-
-
-
BeeGFS服務未啟用！
-
說明：BeeGFS服務意外停止。
-
疑難排解：
-
在報告錯誤的檔案節點上、檢查受影響BeeGFS服務的記錄、以查看是否報告當機。如果發生這種情況、請利用NetApp支援開啟案例、以便調查當機事件。
-
如果BeeGFS記錄中沒有報告錯誤、請檢查日誌記錄、查看系統是否記錄服務停止的原因。在某些情況下、BeeGFS服務可能沒有機會在程序終止之前記錄任何訊息（例如有人執行）
kill -9 <PID>）。
-
-
步驟2：檢查節點是否意外離開叢集
如果節點發生災難性硬體故障（例如主機板當機）、或發生核心異常或類似軟體問題、BeeGFS監視器將不會報告錯誤。請改為尋找主機名稱、您應該會看到來自心臟起搏器的訊息、指出節點意外遺失：
journalctl --since "<YYYY-MM-DD HH:MM:SS>" | grep -i <HOSTNAME>
[...]
Jul 01 16:18:01 ictad22h01 pacemaker-attrd[9245]: notice: Node ictad22h02 state is now lost
Jul 01 16:18:01 ictad22h01 pacemaker-controld[9247]: warning: Stonith/shutdown of node ictad22h02 was not expected步驟3：驗證起搏器是否能夠隔離節點
在所有情況下、您都應該看到心臟起搏器試圖將節點隔離、以驗證它實際上是否離線（確切的訊息可能會因隔離原因而異）：
Jul 01 16:18:02 ictad22h01 pacemaker-schedulerd[9246]: warning: Cluster node ictad22h02 will be fenced: peer is no longer part of the cluster
Jul 01 16:18:02 ictad22h01 pacemaker-schedulerd[9246]: warning: Node ictad22h02 is unclean
Jul 01 16:18:02 ictad22h01 pacemaker-schedulerd[9246]: warning: Scheduling Node ictad22h02 for STONITH如果隔離動作成功完成、您會看到如下訊息：
Jul 01 16:18:14 ictad22h01 pacemaker-fenced[9243]: notice: Operation 'off' [2214070] (call 27 from pacemaker-controld.9247) for host 'ictad22h02' with device 'fence_redfish_2' returned: 0 (OK)
Jul 01 16:18:14 ictad22h01 pacemaker-fenced[9243]: notice: Operation 'off' targeting ictad22h02 on ictad22h01 for pacemaker-controld.9247@ictad22h01.786df3a1: OK
Jul 01 16:18:14 ictad22h01 pacemaker-controld[9247]: notice: Peer ictad22h02 was terminated (off) by ictad22h01 on behalf of pacemaker-controld.9247: OK如果隔離動作因為某種原因而失敗、BeeGFS服務將無法在另一個節點上重新啟動、以避免資料毀損的風險。如果隔離設備（PDU或BMC）無法存取或設定錯誤、則這是需要個別調查的問題。
處理失敗的資源動作（可在PCS狀態的底部找到）
如果執行BeeGFS服務所需的資源失敗、BeeGFS監視器會觸發容錯移轉。如果發生這種情況、可能不會在底部列出「失敗的資源動作」 pcs status 您應該參考如何操作的步驟 "非計畫性容錯移轉之後的容錯回復"。
否則、通常只會有兩種情況出現「失敗的資源動作」。
調查/解決的步驟
案例1：使用隔離代理程式偵測到暫時性或永久性問題、然後重新啟動或移至其他節點。
有些屏障代理程式比其他代理程式更可靠、而且每個代理程式都會實作自己的監控方法、以確保屏障設備已就緒。尤其是RedfISH屏障代理程式已被視為回報失敗的資源動作、例如下列動作、即使它仍會顯示為「已啟動」：
* fence_redfish_2_monitor_60000 on ictad22h01 'not running' (7): call=2248, status='complete', exitreason='', last-rc-change='2022-07-26 08:12:59 -05:00', queued=0ms, exec=0ms回報特定節點上失敗資源動作的隔離代理程式、預期不會觸發該節點上執行BeeGFS服務的容錯移轉。只需在相同或不同的節點上自動重新啟動即可。
解決步驟：
-
如果隔離代理程式持續拒絕在所有或一部分節點上執行、請檢查這些節點是否能夠連線至隔離代理程式、並確認隔離代理程式已在「Ansible」（可隔離）資源清冊中正確設定。
-
例如、如果RedfISH（BMC）屏障代理程式與負責隔離的節點相同、而且OS管理和BMC IP位於同一個實體介面上、則某些網路交換器組態將不允許兩個介面之間進行通訊（以防止網路迴圈）。根據預設、HA叢集會嘗試避免在其負責隔離的節點上放置隔離代理程式、但在某些情況/組態中可能會發生這種情況。
-
-
一旦所有問題都解決（或問題似乎是暫時性的）、請執行
pcs resource cleanup以重設失敗的資源動作。
案例2：BeeGFS監視器偵測到問題並觸發容錯移轉、但由於某些原因、資源無法在次要節點上啟動。
如果啟用了隔離功能、且資源未被封鎖、無法在原始節點上停止（請參閱「待命（故障時）」的疑難排解一節）、最可能的原因包括在次要節點上啟動資源時發生問題、因為：
-
次要節點已離線。
-
實體或邏輯組態問題使次要實體無法存取做為BeeGFS目標的區塊磁碟區。
解決步驟：
-
針對失敗資源動作中的每個項目：
-
確認失敗的資源動作是啟動作業。
-
根據指示的資源和故障資源動作中指定的節點：
-
尋找並修正任何會使節點無法啟動指定資源的外部問題。例如、如果BeeGFS IP位址（浮動IP）無法啟動、請確認至少有一個必要的介面已連線/連線、並連接至正確的網路交換器。如果BeeGFS目標（區塊裝置/ E系列磁碟區）故障、請驗證與後端區塊節點的實體連線是否如預期連接、並驗證區塊節點是否正常。
-
-
如果沒有明顯的外部問題、而且您想找出造成此事件的根本原因、建議您先向NetApp支援部門提出案例進行調查、然後再繼續進行、因為下列步驟可能會使根本原因分析（RCA）變得具有挑戰性/不可能。
-
-
解決任何外部問題之後：
-
從Ansible inventory.yml檔案中註解任何無法運作的節點、然後重新執行完整的可執行教戰手冊、以確保所有邏輯組態都已在次要節點上正確設定。
-
附註：當節點正常運作且您已準備好容錯回復時、請別忘了取消註釋這些節點、然後重新執行教戰手冊。
-
-
或者、您也可以嘗試手動恢復叢集：
-
使用下列方法將任何離線節點重新連線：
pcs cluster start <HOSTNAME> -
使用下列方法清除所有失敗的資源動作：
pcs resource cleanup -
執行PCS狀態、並驗證所有服務是否如預期啟動。
-
如有需要、請執行
pcs resource relocate run可將資源移回其首選節點（如果可用）。
-
-
常見問題
BeeGFS服務不會在要求時進行容錯移轉或容錯回復
可能的問題： The pcs resource relocate 執行命令已執行、但從未成功完成。
*如何檢查：*執行 pcs constraint --full 並使用ID檢查任何位置限制 pcs-relocate-<RESOURCE>。
*如何解決：*執行 pcs resource relocate clear 然後重新執行 pcs constraint --full 以驗證是否移除額外的限制。
當隔離功能停用時、PC狀態中的一個節點會顯示「待命（故障時）」
*可能的問題：*起搏器無法成功確認故障節點上的所有資源均已停止。
如何解決：
-
執行
pcs status並檢查是否有任何未「啟動」的資源、或是在輸出底部顯示錯誤、並解決任何問題。 -
可使節點恢復聯機運行
pcs resource cleanup --node=<HOSTNAME>。
在發生非預期的容錯移轉之後、啟用隔離功能時、資源會在PCS狀態中顯示「已啟動（故障時）」
*可能的問題：*發生觸發容錯移轉的問題、但心臟起搏器無法驗證節點是否已被隔離。這可能是因為屏障設定錯誤、或屏障代理程式發生問題（例如：PDU已從網路中斷連線）。
如何解決：
-
驗證節點是否確實關機。
如果您指定的節點實際上並未關閉、而是執行叢集服務或資源、則會發生資料毀損/叢集故障。 -
手動確認隔離：
pcs stonith confirm <NODE>
此時、服務應完成容錯移轉、並在另一個正常節點上重新啟動。
常見疑難排解工作
重新啟動個別BeeGFS服務
通常、如果需要重新啟動BeeGFS服務（例如為了協助變更組態）、則應更新「Ansible」（可存取）清單並重新執行播放手冊。在某些情況下、可能需要重新啟動個別服務、以加快疑難排解的速度、例如變更記錄層級、而不需要等待整個方針執行。
|
|
除非在Ansible庫存中也新增任何手動變更、否則下次執行Ansible教戰手冊時將會還原這些變更。 |
選項1：系統d控制的重新啟動
如果BeeGFS服務可能無法以新組態正確重新啟動、請先將叢集置於維護模式、以防止BeeGFS監視器偵測到服務停止、並觸發不想要的容錯移轉：
pcs property set maintenance-mode=true如有需要、請在進行任何服務組態變更 /mnt/<SERVICE_ID>/_config/beegfs-.conf （範例： /mnt/meta_01_tgt_0101/metadata_config/beegfs-meta.conf）然後使用systemd重新啟動：
systemctl restart beegfs-*@<SERVICE_ID>.service範例： systemctl restart beegfs-meta@meta_01_tgt_0101.service
選項2：心律調整器控制的重新啟動
如果您不擔心新的組態可能會導致服務意外停止（例如、只是變更記錄層級）、或是處於維護期間、不擔心停機、您只需重新啟動BeeGFS監控器、即可取得您要重新啟動的服務：
pcs resource restart <SERVICE>-monitor例如、若要重新啟動BeeGFS管理服務： pcs resource restart mgmt-monitor