本發明涉及計算機技術領域，特別涉及一種處理集群故障的方法及一種管理節點。

背景技術：

集群一般由管理節點和計算節點組成，計算節點承載計算任務的主體，包括大量的cpu核數，內存及IO帶寬等。在集群長期穩定計算過程中，計算節點時刻運行各種各樣的任務來完成計算工作。

現有的集群中，當計算節點發生故障時，需要通過專用的設備與計算節點進行故障檢測，當檢測出故障時，通過人工對計算節點的故障進行處理。

通過上述描述可見，現有技術中對計算節點的故障的處理比較復雜。

技術實現要素：

本發明實施例提供了一種處理集群故障的方法及一種管理節點，能夠更加簡單的處理集群故障。

一方面，本發明實施例提供了一種處理集群故障的方法，包括：

S1：預先在集群的管理節點上部署用于作業調度的主服務，在所述集群的每個計算節點上部署與所述主服務相匹配的子服務；

S2：所述管理節點利用所述主服務檢測當前計算節點的子服務是否發生故障，如果是，則執行步驟S3；

S3：所述管理節點重啟當前計算節點的子服務；

S4：所述管理節點利用所述主服務檢測當前計算節點的故障是否已修復，如果否，則執行步驟S5；

S5：所述管理節點重啟當前計算節點。

進一步地，所述S3，包括：

所述管理節點登錄當前計算節點，重啟當前計算節點的子服務。

進一步地，所述S3，包括：所述管理節點通過系統層向當前計算節點發送重啟子服務的第一重啟命令，利用所述第一重啟命令重啟當前計算節點的子服務。

進一步地，還包括：

預先在所述管理節點和每個計算節點上部署IPMI(Intelligent Platform Management Interface，智能平臺管理接口)，建立所述管理節點的IPMI與每個計算節點的IPMI的連接；

所述S5包括：

所述管理節點通過IPMI向當前計算節點的IPMI發送第二重啟命令，利用所述第二重啟命令重啟當前計算節點。

進一步地，所述S2中的所述管理節點利用所述主服務檢測當前計算節點的子服務是否發生故障，包括：

所述管理節點利用所述主服務確定當前計算節點的子服務的狀態，在當前計算節點的子服務的狀態為down狀態或offline狀態時，確定當前計算節點的子服務發生故障。

另一方面，本發明實施例提供了一種管理節點，包括：

第一主服務模塊、子服務重啟模塊、第二主服務模塊、節點重啟模塊；

所述第一主服務模塊，用于利用部署在所述管理節點上的用于作業調度的主服務檢測當前計算節點的與所述主服務相匹配的子服務是否發生故障，如果是，則觸發所述子服務重啟模塊；

所述子服務重啟模塊，用于重啟當前計算節點的子服務，觸發所述第二主服務模塊；

所述第二主服務模塊，用于利用所述主服務檢測當前計算節點的故障是否已修復，如果否，則觸發所述節點重啟模塊；

所述節點重啟模塊，用于重啟當前計算節點。

進一步地，所述子服務重啟模塊，用于登錄當前計算節點，重啟當前計算節點的子服務。

進一步地，所述子服務重啟模塊，用于通過系統層向當前計算節點發送重啟子服務的第一重啟命令，利用所述第一重啟命令重啟當前計算節點的子服務。

進一步地，所述節點重啟模塊，用于通過部署在管理節點上的智能平臺管理接口IPMI向當前計算節點的IPMI發送第二重啟命令，利用所述第二重啟命令重啟當前計算節點，其中，所述管理節點的IPMI與當前計算節點的IPMI的連接。

進一步地，所述第一主服務模塊，用于利用所述主服務確定當前計算節點的子服務的狀態，在當前計算節點的子服務的狀態為down狀態或offline狀態時，確定當前計算節點的子服務發生故障。

在本發明實施例中，管理節點可以通過主服務自動的檢測計算節點的子服務是否發生故障，當檢測到計算節點的子服務發生故障時，通過重啟計算節點的子服務來進行修復，當重啟子服務后，還是無法修復該故障時，通過重啟計算節點進行修復，對計算節點的故障的處理可以通過管理節點自動完成，無需人工參與，更加簡單的處理集群故障。

附圖說明

為了更清楚地說明本發明實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖是本發明的一些實施例，對于本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。

圖1是本發明一實施例提供的一種處理集群故障的方法的流程圖；

圖2是本發明一實施例提供的另一種處理集群故障的方法的流程圖；

圖3是本發明一實施例提供的一種管理節點的示意圖。

具體實施方式

為使本發明實施例的目的、技術方案和優點更加清楚，下面將結合本發明實施例中的附圖，對本發明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例是本發明一部分實施例，而不是全部的實施例，基于本發明中的實施例，本領域普通技術人員在沒有做出創造性勞動的前提下所獲得的所有其他實施例，都屬于本發明保護的范圍。

如圖1所示，本發明實施例提供了一種處理集群故障的方法，該方法可以包括以下步驟：

S1：預先在集群的管理節點上部署用于作業調度的主服務，在所述集群的每個計算節點上部署與所述主服務相匹配的子服務；

S2：所述管理節點利用所述主服務檢測當前計算節點的子服務是否發生故障，如果是，則執行步驟S3；

S3：所述管理節點重啟當前計算節點的子服務；

S4：所述管理節點利用所述主服務檢測當前計算節點的故障是否已修復，如果否，則執行步驟S5；

S5：所述管理節點重啟當前計算節點。

在本發明實施例中，管理節點可以通過主服務自動的檢測計算節點的子服務是否發生故障，當檢測到計算節點的子服務發生故障時，通過重啟計算節點的子服務來進行修復，當重啟子服務后，還是無法修復該故障時，通過重啟計算節點進行修復，對計算節點的故障的處理可以通過管理節點自動完成，無需人工參與，更加簡單的處理集群故障。

在本發明一實施例中，所述S3，包括：所述管理節點登錄當前計算節點，重啟當前計算節點的子服務。

在本發明一實施例中，所述S3，包括：所述管理節點通過系統層向當前計算節點發送重啟子服務的第一重啟命令，利用所述第一重啟命令重啟當前計算節點的子服務。

在管理節點和計算節點上，主服務和子服務屬于二者在應用層的連接，二者還有在系統層的連接，當應用層連接故障時，可以通過系統層來進行交互。在本實施例中，管理節點通過系統層向當前計算節點的系統發送第一重啟命令，使得當前計算節點重啟子服務。

在系統層之下還有硬件層之間的連接，下面的IPMI就屬于硬件層。

在本發明一實施例中，還包括：預先在所述管理節點和每個計算節點上部署IPMI，建立所述管理節點的IPMI與每個計算節點的IPMI的連接；

所述S5包括：所述管理節點通過IPMI向當前計算節點的IPMI發送第二重啟命令，利用所述第二重啟命令重啟當前計算節點。

在本實施例中，管理節點和計算節點通過各自的IPMI建立了IPMI網絡，通過該IPMI網絡可以在硬件層進行交互。當重啟當前計算節點的子服務已經無法解決該故障時，可以通過IPMI網絡來重啟當前計算節點進行修復。

如果重啟當前計算節點也無法修復該故障，管理節點可以獲取當前計算節點的系統日志，方便維護人員使用該系統日志對當前計算節點進行修復，并可以發出報警信號，通知維護人員及時維護。

在本發明一實施例中，所述S2中的所述管理節點利用所述主服務檢測當前計算節點的子服務是否發生故障，包括：

所述管理節點利用所述主服務確定當前計算節點的子服務的狀態，在當前計算節點的子服務的狀態為down狀態或offline狀態時，確定當前計算節點的子服務發生故障。

在本實施例中，通過當前計算節點的子服務的狀態來判斷當前計算節點的子服務是否發生故障。當子服務的狀態為down狀態或offline狀態時，當前計算節點的子服務已經無法與管理節點的主服務進行交互了，管理節點無法為當前計算節點分配任務。

當子服務的狀態為offline狀態時，可用“pbs-c節點名”來子服務恢復正常，也就是使子服務上線。舉例來說，當前計算節點的節點名為001，當前計算節點的子服務的狀態為offline狀態，管理節點向當前計算節點發送“pbs-c 001”命令，使得當前計算節點的子服務上線。

本發明實施例提供的方法可以通過檢測腳本來實現，具體地，管理節點打開自動計劃任務，可以通過crond服務來實現，在該服務中配置管理節點按照一定頻次執行檢測腳本。這里的一定頻次可以是一周一次或一天一次，這樣不會占用管理節點過多的資源。

另外，在本發明一實施例中，可以通過以下方式來確定當前計算節點是否發生故障：管理節點利用主服務向當前計算節點的子服務發送檢測信號，判斷是否接收到當前計算節點的子服務對檢測信號的響應信號，如果是，則確定當前計算節點的子服務沒有發生故障，否則，確定當前計算節點的子服務發生故障。

在發明實施例中，集群可以是windows集群，也可以是linux集群。下面以linux集群為例，在該集群中，管理節點和每個計算節點上都部署有torque，通過torque可以是作業調度，管理節點上主服務為server服務，每個計算節點上的子服務為mom服務。

如圖2所示，本發明實施例提供了一種處理集群故障的方法，該方法可以包括以下步驟：

步驟201：預先在集群的管理節點上部署server服務，在集群的每個計算節點上部署與server服務相匹配的mom服務。

具體地，在管理節點安裝pbs的server端，在計算節點安裝pbs的mom端，server服務通過server端實現，mom服務通過mom端實現。server服務與mom服務進行交互，采集mom服務各個節點的服務狀態，比如pbsnodes能查看所有節點的狀態。

步驟202：預先在管理節點和每個計算節點上部署IPMI，建立管理節點的IPMI與每個計算節點的IPMI的連接。

具體地，管理節點與每個計算節點之前通過各自的IPMI構成IPMI網絡，通過IPMI網絡進行交互。在管理節點和每個計算節點上配置IPMI遠程控制程式，可以在管理節點上通過IPMI網絡來重啟計算節點。

步驟203：管理節點利用server服務確定當前計算節點的mom服務的狀態是否是down狀態或offline狀態，如果是，則執行步驟204。

具體地，如果當前計算節點的mom服務的狀態是down狀態或offline狀態，則說明mom服務無法與server服務進行交互，管理節點無法對當前計算節點進行作業調度，確定當前計算節點的mom服務發生故障。如果當前計算節點的mom服務的狀態不是down狀態且不是offline狀態，確定當前計算節點的mom服務沒有發生故障，結束當前流程，或者等待下一個周期執行步驟203。

步驟204：管理節點登錄當前計算節點，重啟當前計算節點的mom服務。

具體地，雖然在應用層上管理節點無法通過server服務與當前計算節點進行交互，但是，在系統層上，管理節點可以登錄到當前計算節點，對當前計算節點進行操作，也就是重啟當前計算節點的mom服務。

另外，管理節點還可以通過系統層向當前計算節點發送重啟mom服務的命令，使得當前計算節點根據該命令重啟mom服務。

步驟205：管理節點利用server服務確定當前計算節點的mom服務的狀態是否是down狀態或offline狀態，如果是，則執行步驟206。

在重啟當前計算節點的mom服務后，再次對當前計算節點的mom服務的狀態進行檢查，來確定該故障是已修復，如果當前計算節點的mom服務的狀態仍然是down狀態或offline狀態，說明該故障已修復，否則，說明該故障沒有修復，需要采取后續措施進行修復。

步驟206：管理節點通過IPMI向當前計算節點的IPMI發送第二重啟命令，利用第二重啟命令重啟當前計算節點。

具體地，管理節點在硬件層通過IPMI網絡與當前計算節點進行交互，通過硬件層直接重啟當前計算節點，以對故障進行修復。

通過該步驟可以在當前計算節點因故障發生宕機時，重啟當前計算節點進行修復。

在步驟206之后，還可以包括：

管理節點利用server服務確定當前計算節點的mom服務的狀態是否是down狀態或offline狀態，如果是，則獲取當前計算節點的系統日志，發出報警信號。

通過該步驟可以在無法自我修復時，向維護人員提供系統日志，幫助維護人員更加方便的進行修復。

另外，在管理節點上部署了主服務，并在每個計算節點上部署了從服務之后，可以手動驗證集群的作業調度功能是否正常，抓取節點信息功能是否正常，驗證均正常后，可以執行本發明實施例提供的方法，這樣可以避免由于作業調度功能異常導致本發明實施例的方法失敗。

本發明實施例設計簡便，可以用于含有作業調度系統的linux計算集群系統在出現某個或某幾個計算節點因不可控制因素導致的宕機或服務不正常時，能夠通過自動執行任務進行自檢測自修復，將故障分類并予以簡單恢復，不能恢復時記錄日志便于維護人員維護。

本發明實施例中，能實現在無人值守的情況下對集群的故障進行監管和初步恢復，對于嚴重故障可進行記錄收集系統日志以便維護人員分析。

本發明實施例簡單明了，易于操作，管理節點安裝的作業調度軟件是整個架設的基礎，自任務判斷流程是架設的核心，運行時間不建議過頻，集群中存在其他角色類型的節點依舊適用。最終目的是保證集群在無人時刻監管職守時，能自行監控恢復故障上線，最大限度提高資源利用率及計算效率，保障集群的穩定運行。

如圖3所示，本發明實施例提供的一種管理節點，包括：

第一主服務模塊301、子服務重啟模塊302、第二主服務模塊303、節點重啟模塊304；

所述第一主服務模塊301，用于利用部署在所述管理節點上的用于作業調度的主服務檢測當前計算節點的與所述主服務相匹配的子服務是否發生故障，如果是，則觸發所述子服務重啟模塊302；

所述子服務重啟模塊302，用于重啟當前計算節點的子服務，觸發所述第二主服務模塊303；

所述第二主服務模塊303，用于利用所述主服務檢測當前計算節點的故障是否已修復，如果否，則觸發所述節點重啟模塊304；

所述節點重啟模塊304，用于重啟當前計算節點。

在本發明一實施例中，所述子服務重啟模塊，用于登錄當前計算節點，重啟當前計算節點的子服務。

在本發明一實施例中，所述子服務重啟模塊，用于通過系統層向當前計算節點發送重啟子服務的第一重啟命令，利用所述第一重啟命令重啟當前計算節點的子服務。

在本發明一實施例中，還包括：

所述節點重啟模塊，用于通過部署在管理節點上的IPMI向當前計算節點的IPMI發送第二重啟命令，利用所述第二重啟命令重啟當前計算節點，其中，所述管理節點的IPMI與當前計算節點的IPMI的連接。

在本發明一實施例中，所述第一主服務模塊，用于利用所述主服務確定當前計算節點的子服務的狀態，在當前計算節點的子服務的狀態為down狀態或offline狀態時，確定當前計算節點的子服務發生故障。

上述裝置內的各單元之間的信息交互、執行過程等內容，由于與本發明方法實施例基于同一構思，具體內容可參見本發明方法實施例中的敘述，此處不再贅述。

本發明各個實施例至少具有如下有益效果：

1、在本發明實施例中，管理節點可以通過主服務自動的檢測計算節點的子服務是否發生故障，當檢測到計算節點的子服務發生故障時，通過重啟計算節點的子服務來進行修復，當重啟子服務后，還是無法修復該故障時，通過重啟計算節點進行修復，對計算節點的故障的處理可以通過管理節點自動完成，無需人工參與，更加簡單的處理集群故障。

2、本發明實施例簡單明了，易于操作，能夠保證集群在無人時刻監管職守時，能自行監控恢復計算節點的故障，最大限度提高集群的資源利用率及計算效率，保障集群的穩定運行。

需要說明的是，在本文中，諸如第一和第二之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。而且，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個······”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同因素。

本領域普通技術人員可以理解：實現上述方法實施例的全部或部分步驟可以通過程序指令相關的硬件來完成，前述的程序可以存儲在計算機可讀取的存儲介質中，該程序在執行時，執行包括上述方法實施例的步驟；而前述的存儲介質包括：ROM、RAM、磁碟或者光盤等各種可以存儲程序代碼的介質中。

最后需要說明的是：以上所述僅為本發明的較佳實施例，僅用于說明本發明的技術方案，并非用于限定本發明的保護范圍。凡在本發明的精神和原則之內所做的任何修改、等同替換、改進等，均包含在本發明的保護范圍內。