TWI685740B

TWI685740B - 運用於資料中心的機櫃異常狀態的遠端排除方法(一)

Info

Publication number: TWI685740B
Application number: TW107147662A
Authority: TW
Inventors: 林韋成; 辛柏陞; 林政翰
Original assignee: 營邦企業股份有限公司
Priority date: 2018-12-28
Filing date: 2018-12-28
Publication date: 2020-02-21
Also published as: TW202026882A

Abstract

一種運用於資料中心的機櫃異常狀態的遠端排除方法，由機櫃伺服器管理系統定時於遠端取得一個機櫃內的機櫃管理控制器以及基板管理控制器的各項資訊，並且記錄管理者通過機櫃伺服器管理系統所進行的各項操作行為。機櫃伺服器管理系統對上述資訊以及操作行為進行分析，以判斷機櫃內的機櫃管理控制器或基板管理控制器是否處於預設的多種關注狀態的其中之一。若判斷任一機櫃管理控制器或基板管理控制器已處於異常狀態但尚未失去連線，則機櫃伺服器管理系統自動實施遠端恢復機制，以解除機櫃管理控制器或基板管理控制器的異常狀態。

Description

運用於資料中心的機櫃異常狀態的遠端排除方法(一)

本發明涉及資料中心，尤其涉及對資料中心中的機櫃的異常狀態的分析與排除的方法。

一般來說，一個資料中心通常會透過智慧型平台管理介面(Intelligent Platform Management Interface,IPMI)對資料中心內的機櫃、端點伺服器等設備的機櫃管理控制器(Rack Management Controller,RMC)及基板管理控制器(Baseboard Management Controller,BMC)進行遠端管理。

不論使用何種方式進行遠端管理，只要任一機櫃或端點伺服器的RMC或BMC出現異常，管理者就會收到許多警告信件。然而，管理者一般難以通過這些警告信件在第一時間直接得知狀態的真正問題點，往往需要隨著時間不斷推進，直到收到數百封警告信件並且與設備失去連線後，才能確定所述RMC、BMC發生了異常。

更甚者，即使部分的管理平台從不同的監控管道收集到錯誤訊息，並且進行彙整後提交故障評估報告給管理者，但這樣的監控方式仍然需要由管理者進行最後的判斷，並且決定處理方式。然而，只要有人為因素的介入，就無法全然避免誤判的可能。

有鑑於此，本領域確實需要發展一套新穎的系統與方法，可針對處於異常狀態的RMC及BMC自動實施遠端修復機制，藉此強化資料中心的監控能力，使得機櫃管理能夠高度自動化，同時減少人為判定所間接流失的時間，並且避免人為誤判。

本發明的主要目的，在於提供一種運用於資料中心的機櫃異常狀態的遠端排除方法，可以在判斷機櫃管理控制器或基板管理控制器已處於異常狀態但尚未失去連線時，直接於遠端自動解除所述異常狀態。

為了達成上述的目的，本發明的方法是由一機櫃伺服器管理系統定時於遠端取得一個機櫃內的一機櫃管理控制器以及多個基板管理控制器的各項資訊，並且記錄管理者通過該機櫃伺服器管理系統所進行的各項操作行為。該機櫃伺服器管理系統對上述資訊以及操作行為進行分析，以判斷該機櫃內的該機櫃管理控制器或各該基板管理控制器是否處於預設的多種關注狀態的其中之一。

若判斷任一機櫃管理控制器或基板管理控制器已處於異常狀態但尚未失去連線，則該機櫃伺服器管理系統自動實施一遠端恢復機制，以從遠端自動解除該機櫃管理控制器或該基板管理控制器的異常狀態。

相對於相關技術，本發明的方法由與機櫃連線的機櫃伺服器管理系統來進行分析並自動實施遠端恢復機制，無需等待管理者對於異常狀態的人為判定，可大幅降低管理成本，亦使得機櫃的監控無需人為干涉，也不受距離與時間的影響。

1‧‧‧資料中心

2‧‧‧機櫃

21‧‧‧機櫃管理控制器

211、221‧‧‧網路介面控制器

22‧‧‧基板管理控制器

220‧‧‧端點伺服器

23‧‧‧內部網路交換機

24‧‧‧內部硬體線路

3‧‧‧機櫃伺服器管理系統

31‧‧‧資料庫

4‧‧‧公共網路交換機

S11~S15、S21~S28‧‧‧搜集步驟

S31~S39‧‧‧分析與排除步驟

S41~S47、S51~S58、S61~S66、S71~S80‧‧‧排除步驟

圖1為本發明的資料中心的示意圖。

圖2為本發明的機櫃的方塊圖的第一具體實施例。

圖3A為本發明的資料搜集流程圖的第一具體實施例。

圖3B為本發明的資料搜集流程圖的第二具體實施例。

圖4為本發明的分析與排除流程圖的第一具體實施例。

圖5為本發明的第一類關注狀態排除流程圖的第一具體實施例。

圖6為本發明的第一類關注狀態排除流程圖的第二具體實施例。

圖7為本發明的第二類關注狀態排除流程圖的第一具體實施例。

圖8為本發明的第三類關注狀態排除流程圖的第一具體實施例。

茲就本發明之一較佳實施例，配合圖式，詳細說明如後。

本發明揭露了一種機櫃異常狀態的遠端排除方法(下面將於說明書中簡稱為排除方法)，所述排除方法主要運用於資料中心內，以協助管理者自動監控、分析並且排除資料中心內的異常狀態。

參閱圖1，為本發明的資料中心的示意圖。如圖1所示，本發明所述的資料中心1主要具有複數機櫃2，以及由遠端與複數機櫃2連線的機櫃伺服器管理系統3(下面簡稱為管理系統3)。所述管理系統3可設置於資料中心1的內部或外部，並且經由網路連接公共網路交換機4，再經由公共網路交換機4連接資料中心1內的複數機櫃2。

本發明的管理系統3可實時監控資料中心1內的複數機櫃2、獲取複數機櫃2的各項資訊、並且對這些資訊進行分析。當發現任一機櫃2發生異常狀態或即將發生異常狀態時，本發明的管理系統3可自動實施對應的處理機制以進行狀況排除。藉此，本發明可以在完全不需要人為介入、大幅降低人為誤判並且提升處理速度的前提下，對機櫃2已發生的異常狀態進行排除，或對可能即將發生的異常狀態進行預防。

於一實施例中，所述管理系統3可為個人電腦或雲端伺服器，內部具有一或多個中央處理單元(圖未標示)。管理系統3被啟動後，可通過公共網路交機4連接至資料中心1內的複數機櫃2，並可藉由一或多個中央處理單元執行特定的應用程式與演算法，以實現對這些機櫃2的監控、資料分析及異常狀態排除。

所述管理系統3還具有資料庫31，用以暫存或永久保存從資料中心1內的複數機櫃2所獲得的各項資訊。於圖1的實施例中，所述資料庫31是內建於管理系統3。於其他實施例中，管理系統3亦可從外部連接一或多個資料庫31，不加以限定。

參閱圖2，為本發明的機櫃的方塊圖的第一具體實施例。圖2的實施例中以資料中心1內的單一台機櫃2連接至所述管理系統3為例，進行說明，然而資料中心1係可依實際所需設置多台的機櫃2，而不以圖2所示者為限。

如圖2所示，本發明的機櫃2內主要包括至少一個機櫃管理控制器(Rack Management Controller,RMC)21，以及與RMC21連接的多台端點伺服器220，其中各個端點伺服器220分別具備至少一個基板管理控制器(Baseboard Management Controller,BMC)22。

所述RMC21為一種嵌入式系統，設置於機櫃2內，透過各式硬體線路協助處理機櫃2的內部硬體設備(降溫風扇，各式感測器或電源供應器等等設備)的所有對外通訊，並與機櫃2內的所有端點伺服器220的BMC22進行溝通。所述BMC22也為嵌入式系統，設置於端點伺服器220中並協助處理端點伺服器220的內部硬體設備(各式感測器等等設備)的所有對外通訊。

本實施例中，RMC21通過內部硬體線路24連接機櫃2內的所有端點伺服器220的BMC22，藉由與各個BMC22溝通來控制各個端點伺服器220並且獲取所需資訊。本實施例中，所述端點伺服器可例如為直立式伺服器(Tower Model Server)或刀鋒伺服器(Blade Server)等，但不加以限定。

如圖2所示，設置在機櫃2內的每一個端點伺服器220分別具有一個固定的位置號碼(如圖2中的#1、#2、#n等)，當端點伺服器220或是BMC22對外的網路功能失效時，RMC21可通過內部硬體線路24連接至機櫃2內的指定位置(如上述的#1、#2、#n)，進而與該指定位置上的端點伺服器220及BMC22溝通。如此一來，即使端點伺服器220或是BMC22失去網路連線，機櫃2仍可藉由RMC21來進行監控、管理各個BMC22並且排除各個BMC22的異常狀況。

另，本發明的RMC21內設置有網路介面控制器(Network Interface Controller,NIC)211，各個BMC22內亦分別設置有網路介面控制器221。RMC21通過NIC211連接機櫃2內部的內部網路交換機23，各個BMC22分別通過各自的NIC221連接所述內部網路交換機23。機櫃2通過內部網路交換機23連接公共網路交換機4，並且藉由公共網路交換機4與所述管理系統3建立網路連線。如此一來，管理系統3可經由網路遠程訪問資料中心1內的機櫃2，藉此查詢並獲取機櫃2內的所有RMC21及BMC22的各項資訊，並且儲存於資料庫31內。

本發明的主要技術特徵在於，管理系統3可經由網路定時訪問機櫃2，並獲取機櫃2內所有RMC21及BMC22的各項資訊(例如狀態資料、事件日誌(event log)、系統資源使用率、端點伺服器220內部感測器的感測數值等等)，藉由這些資訊來主動分析RMC21及BMC22是否發生異常狀態，或即將發生異常狀態。當管理系統3經分析後認為有必要時，即可主動於遠端實施對應的機制，以於遠端直接排除RMC21及/或BMC22的異常狀態，或是預先避免RMC21及/或BMC22進入所述異常狀態。

本發明的技術方案可以在完全不需人為介入的情況下進行異常狀態的處理，大幅降低了人為誤判的可能，並且可令機櫃2的監控達到高度自動化。

續請參閱圖3A，為本發明的資料搜集流程圖的第一具體實施例。

如圖3A所示，若管理者欲對資料中心1內的機櫃2進行監控，則管理者可直接啟動遠端的管理系統3(步驟S11)。當管理系統3被啟動後，即會主動遠程訪問資料中心1中的機櫃2(以圖2中的單一個機櫃2為例)內的RMC21及所有BMC22(步驟S12)。並且，管理系統3藉由遠程訪問來取得機櫃2中的RMC21及所有BMC22的各項資訊(步驟S13)，再將所取得的資訊儲存於本地端的資料中31中(步驟S14)。

具體地，本實施例中，管理系統3是在啟動後定時主動訪問機櫃2，也就是將步驟S12、S13、S14的訪問動作、資訊取得動作及儲存動作視為啟動後的例行程序(routine)。於執行上述routine時，持續判斷管理系統3是否關閉(步驟S15)，並且於管理系統3關閉前持續執行上述步驟S12至步驟S14，以持續對機櫃2內的RMC21與BMC22進行監控。

參閱圖3B，為本發明的資料搜集流程圖的第二具體實施例。

本實施例中，當管理者啟動了所述管理系統3後(步驟S21)，管理系統3可以提供一個操作介面(步驟S22)。通過這個操作介面，管理者可以登入管理系統3，並且藉由管理系統3來於遠端對資料中心1中的各個機櫃2進行資訊監控以及控制。本實施例中，所述操作介面可為一個實體介面或網頁(Web)介面，不加以限定。

在提供了所述操作介面後，管理系統3持續判斷是否通過操作介面接受了由管理者所進行的操作(步驟S23)。若確實接受到管理者的操作，則管理系統3依據管理者的操作行為，從遠端對機櫃2以及機櫃2內的RMC21及BMC22實施對應的遠端管理(步驟S24)。接著，管理系統3可記錄管理者的上述操作行為(步驟S25)，並且，還可取得並記錄管理系統3、機櫃2、各端點伺服器220以及RMC21、BMC22因為所述遠端管理而產生的反饋、系統參數及執行數據等反饋資訊(步驟S26)。最後，管理系統3同樣將所述操作行為及反饋資訊儲存於資料庫31中(步驟S27)，以利於後續對於異常狀態的分析動作。

相同地，本實施例的管理系統3會將步驟S22至步驟S27的動作視為啟動後的routine。於執行上述routine時，持續判斷管理系統3是否關閉(步驟S28)，並且於管理系統3關閉前持續執行上述步驟S22至步驟S27，以持續監控並分析管理者所實施的操作行為對機櫃2內的RMC21與BMC22所造成的影響。

續請參閱圖4，為本發明的分析與排除流程圖的第一具體實施例。

如圖4所示，本實施例中管理系統3會定時存取資料庫31(步驟S31)，並且從資料庫31中取得機櫃2中的RMC21及BMC22各項資訊、管理者的操作行為、以及各項反饋資訊(步驟S32)，並且加以進行分析。藉由上述資料，管理系統3可以分析出機櫃2內的RMC21及各個BMC22是否處於預設的多種關注狀態的其中之一(步驟S33)。

於一實施例中，所述管理系統3可以實時地取得機櫃2中的RMC21與BMC22的各項資訊、實時地從操作介面取得管理者的操作行為，並且據以進行分析。於另一實施例中，管理系統3可藉由圖3A的步驟S14及圖3B的步驟S27定時將上述資料儲存至資料庫31中，並且定時從資料庫31中讀取上述資料以進行分析，不加以限定。

於一實施例中，上述RMC21及BMC22的各項資訊，可例如為狀態資料(如目前處於工作模式或更新模式、IP位址、MAC位址、子網路遮罩、閘道器IP位址、IPMI session數量等)、事件日誌(event log)等，而上述操作行為可例如為管理者針對特定機櫃2、端點伺服器220或RMC21、BMC22所實行的資料查詢作業、更新作業、重置作業等，但不加以限定。通過上述資料，管理系統3可以藉由執行對應演算法而分析出機櫃2中目前是否具有需要即時救援的RMC21或BMC22。

於圖4的實施例中，管理系統3主要可預設至少三個種類的關注狀態，包括第一類關注狀態、第二類關注狀態及第三類關注狀態，其中這三類的關注狀態分別對應至RMC21/BMC22不同的異常狀況，並且分別需要由管理系統3於遠端直接實施不同的機制來加以排除或加以預防。

如圖4所示，若管理系統3依據上述資料(主要依據狀態資料、事件日誌及管理者的操作行為)進行分析後發現有任一RMC21或BMC22已處於異常狀態，但尚未與管理系統3失去連線，則會認定這個RMC21或BMC22是處於所述第一類關注狀態(步驟S34)。當發現任一RMC21、BMC22處於第一類關注狀態時，管理系統3可自動對處於第一類關注狀態的RMC21、BMC22實施遠端恢復機制，以遠程解除RMC21或BMC22的異常狀態(步驟S37)。

若管理系統3依據上述資料(主要依據RMC21與BMC22狀態資料)進行分析後發現有任一RMC21或BMC22與管理系統3的連線正常，但判斷可能即將出現異常狀態，則會認定這個RMC21或BMC22是處於所述第二類關注狀態(步驟S35)。當發現任一RMC21、BMC22處於第二類關注狀態時，管理系統3可自動對處於第二類關注狀態的RMC21、BMC22實施遠端服務重啟機制，以遠程避免RMC21或BMC22進入可能的異常狀態(步驟S38)。

若管理系統3依據上述資料(主要依據狀態資料、管理者的操作行為以及各項反饋資訊)進行分析後發現有任一BMC22已失去了網路連線(即，管理系統3無法遠程直接訪問這個BMC22)，則會認定這個BMC22是處於所述第三類關注狀態(步驟S36)。當發現任一BMC22處於第三類關注狀態時，管理系統3可自動對處於第三類關注狀態的BMC22實施遠端救援機制，以遠程排除BMC22失去連線的狀態，並且使BMC22的網路連線恢復正常(步驟S39)。

下面段落討論所述第一類關注狀態。

由於部分的RMC21/BMC22不具備基本輸入輸出系統(Basic Input/Output System,BIOS)，因此需要通過外部伺服器所提供的網路時間協定 (Network Time Protocol,NTP)服務，或是硬體時鐘晶片提供的實時時鐘(Real-time Clock,RTC)服務來設定時間，以與其他設備達到時間同步。

如上所述，若在RMC21或BMC22的時間同步程序尚未完成前發生了系統事件，則雖然該系統事件仍然會被記錄在RMC21、BMC22的事件日誌中，但該系統事件的時間欄位將無法記錄正確的事件發生時間，而只會記錄例如“Pre-init”的字樣。若沒有正確的事件發生時間，則管理者無法將事件日誌做為所述系統事件的參考指標，這樣將會導致判斷錯誤。除此之外，若所述RMC21、BMC22需要進行重置(Reset)作業，也可能會造成上述系統事件的事件發生時間記錄錯誤或異常的情況。

參閱圖5，為本發明的第一類關注狀態排除流程圖的第一具體實施例。本實施例中，所述管理系統3會定時存取資料庫31(步驟S41)，以由資料庫31中取得機櫃2內的RMC21及BMC22的狀態資料及事件日誌，並且判斷RMC21及BMC22的狀態變化(步驟S42)。

本實施例中，管理系統3主要是判斷所獲得的事件日誌中，是否有任一系統事件的事件發生時間不明或錯誤(步驟S43)。若所述事件日誌中的所有系統事件皆記錄了正確的事件發生時間，則管理系統3不主動實施任何動作。

若經分析後，管理系統3發現任一RMC21或BMC22具有時間不明或錯誤的系統事件，則管理系統3會將該RMC21或BMC22視為處於所述第一類關注狀態(步驟S44)，即，認定這個RMC21或BMC22處於異常狀態，但尚未失去網路連線。

於一實施例中，管理系統3主要可於所述事件日誌中的任一系統事件的事件發生時間被記錄為“Pre-init”或類似字樣時(即，無法正確說明系統事件的發生時間)，判斷所述系統事件的事件發生時間不明或錯誤。於另一實施例中，管理系統3主要可以在從事件日誌中發現任一RMC21或BMC22具有事件發生時間不明的系統事件，並且從狀態資料中發現這個RMC21或BMC22尚未完成時間同步程序或是需要進行重置作業時，判斷所述系統事件的事件發生時間不明或錯誤。

當管理系統3於步驟S44中認定一個RMC21或BMC22處於第一類關注狀態後，管理系統3首先取得本次存取事件日誌的時間戳記(步驟S45)，將這個時間戳記做為所述系統事件的備位時間識別資訊，並儲存於資料庫31中(步驟S46)。於一實施例中，管理系統3是將本次存取資料庫31以讀取所述事件日誌的時間做為上述時間戳記。於另一實施例中，管理系統3是將本次遠程訪問機櫃2並從RMC21、BMC22取得所述事件日誌的時間做為上述時間戳記，但不加以限定。

舉例來說，所述事件日誌的原始內容可例如下表所示：

若管理系統3在2018年12月22日的下午11時32分23秒時存取了所述事件日誌，並發現事件二的事件發生時間有誤，則管理系統3可以主動為事件二產生所述備位時間識別資訊，並且修改事件日誌的內容或是產生新的事件日誌。新的事件日誌可例如下表所示：

當管理者通過所述操作介面登入管理系統3，並且於管理系統3中查詢所述事件日誌時，管理系統3即可如上表所示，顯示所述備位時間識別資訊以做為事件二的事件發生時間。如此一來，即使RMC21或BMC22在時間同步未完成前發生一個系統事件，管理系統3仍可為該系統事件設定一個可供識別的備位時間，以利管理系統3以及管理者於對該系統事件的解讀，並藉此強化遠端恢復的效果。

步驟S46後，管理系統3可進一步通過網路發出控制指令(例如第一控制指令)至處於第一類關注狀態的RMC21或BMC22，以對具有時間錯誤的異常狀態的RMC21或BMC22執行時間校正程序(步驟S47)。於一實施例中，所述時間校正程序是控制RMC21或BMC22藉由NTP服務進行時間校正。於另一實施例中，所述時間校正程序是強制RMC21或BMC22進行重置作業，但不加以限定。

下面段落繼續說明其他可能發生的第一類關注狀態。

由於資料中心1內部的機櫃2數量眾多，當管理者有更新的需求時，實難以通過人工方式逐台進行更新。因此，當管理者要對機櫃2內的RMC21、BMC22實施更新作業時(例如韌體更新)，係可對管理系統3進行操作，以通過管理系統3的相關程式碼來發送更新指令以及最新版本的韌體，藉此於遠端同時更新資料中心1內的多個機櫃2的RMC21及BMC22。

若於更新過程中遇到網路壅塞或網路訊號不穩定造成網路連線中斷等問題，使得部分RMC21、BMC22無法依循正常的更新流程完成更新作業，就有可能造成更新作業失敗。然而，部分RMC21、BMC22在更新作業失敗後僅會造成系統無法正常運作，但並未失去網路連線(例如進入更新模式後無法恢復為工作模式)，此時就需要由管理系統3於遠端介入以進行異常狀況排除。

參閱圖6，為本發明的第一類關注狀態排除流程圖的第二具體實施例。本實施例中，管理系統3同樣定時存取資料庫31(步驟S51)，以由資料庫31中取得機櫃2內的RMC21及BMC22的狀態資料及事件日誌，同時取得管理者通過操作介面所實施的操作行為，並且判斷RMC21及BMC22的狀態變化(步驟S52)。

本實施例中，管理系統3首先可對RMC21及BMC22的狀態資料以及事件日誌進行分析，以判斷是否有任一RMC21、BMC22的更新作業已逾時或發生錯誤(步驟S54)，並且判斷所述更新作業逾時或發生錯誤的RMC21或BMC22的網路連線是否正常(步驟S55)。若管理系統3在分析後發現有任一RMC21或BMC22的更新作業逾時或發生錯誤但網路連線仍然正常，則可將這個RMC21或BMC22視為處於所述第一類關注狀態(步驟S56)，即，處於異常狀態，但尚未失去連線。

更具體地，於上述步驟S52後，管理系統3可先依據所述操作行為來判斷管理者是否曾對機櫃2中的RMC21及/或BMC22實施了更新作業(步驟S53)。並且，於確定了管理者曾經實施了更新作業後，管理系統3再接續執行步驟S54以及步驟S55，以判斷這些RMC21、BMC22的更新作業是否逾時或發生錯誤，以及網路連線是否正常。

所述RMC21、BMC22在接受了管理者實施的更新作業後，將會自動進入更新模式。此時，RMC21、BMC22會在狀態資料中設定已進入更新模式的標記(flag)。當周邊設備與RMC21、BMC22溝通並且讀到更新模式的標記時，就會自動停止與這個RMC21、BMC22的互動。因此，只要RMC21、BMC22更新作業失敗而無法離開更新模式，這個RMC21、BMC22就無法正常運作。當管理系統3發現任一RMC21、BMC22接受了更新作業、更新作業已逾時或發生錯誤、但是尚未失去網路連線時，就可認定這個RMC21、BMC22處於所述第一關注狀態。

步驟S56後，管理系統3可進一步通過網路發出控制指令(例如第二控制指令)至處於第一類關注狀態的RMC21或BMC22，以強制更新作業失敗的RMC21或BMC22離開所述更新模式(步驟S57)。

如上所述，在本實施例所指的更新作業失敗情況下(即，無法離開更新模式)，所述RMC21、BMC22仍可接收並處理相關的指令，只是周邊設備在讀到更新模式的標記(flag)時就會自動停止與RMC21、BMC22的互動。本實施例中，管理系統3已判斷所述RMC21、BMC22發生異常狀態，因此會無視於上述標記，而藉由控制指令的發出來強制RMC21、BMC22離開更新模式。

步驟S57後，管理系統3還可進一步通過網路發出另一控制指令(例如第三控制指令)至已離開更新模式的RMC21或BMC22，以強制RMC21或BMC22進行重置作業，或是再次實施所述更新作業(步驟S58)。藉此，管理系統3可以確保RMC21、BMC22已恢復正常運作，並且韌體或軟體處於更新完成的最新版本。

下面段落接著討論所述第二類關注狀態。

本發明中的RMC21、BMC22為一種嵌入式系統(Embbeded System)，因此即使機櫃2內的端點伺服器220未開機，管理系統3仍可藉由與RMC21、BMC22的溝通來實現遠程開機、遠程關機、查看設備狀態等遠程管理功能。

一般來說，管理者在實施遠程管理程序時，可在管理系統3上使用智慧平台管理介面(Intelligent Platform Management Interface,IPMI)工具程式來通過網路發送IPMI指令，藉此與機櫃2內的RMC21、BMC22溝通。於使用IPMI工具程式的情況下，每一道IPMI指令的發送都需與目的地的RMC21、BMC22建立一個IPMI會話期間(session)，藉此才能與目的地的RMC21、BMC22進行溝通。具體地，在IPMI session建立完成後，管理系統3才能透過網路與RMC21、BMC22以及機櫃2、端點伺服器220的底層硬體設備溝通，進而取得所述指令的執行結果(例如取得韌體版本、端點伺服器220內的所有感測器的感測數值等)。

惟，嵌入式系統本身的運算資源是相當有限的，除了運作所需的基本資源消耗外，與RMC21的溝通、與BMC22的溝通以及回覆資料中心1內的各式監控系統等動作皆會進一步消耗嵌入式系統的運算資源。

再者，當管理者通過管理系統3對各個RMC21、BMC22實施遠端管理程序時，也需消耗RMC21、BMC22的運算資源，最明顯的就是令RMC21、BMC22的IPMI session數量大幅增加，使得RMC21、BMC22出現回應不及或是請求超時(timeout)的現象。此時，雖然所述RMC21、BMC22尚未發生異常狀態，但可能需要由管理系統3於遠端介入以避免RMC21、BMC22將來發生異常狀態而影響機櫃2的運作。

參閱圖7，為本發明的第二類關注狀態排除流程圖的第一具體實施例。本實施例中，所述管理系統3同樣會定時存取資料庫31(步驟S61)，以由資料庫31中取得機櫃2內的RMC21及BMC22的狀態資料，並且判斷RMC21及BMC22的狀態變化(步驟S62)。於一實施例中，管理系統3在步驟S62中主要是取得RMC21及各個BMC22目前的IPMI session總數。於另一實施例中，管理系統3在步驟S62中同時取得RMC21及各個BMC22目前的系統資源使用率。

步驟S63後，管理系統3判斷是否有任一RMC21、BMC22的IPMI session總數高於第一門檻值(步驟S63)，並且於任一RMC21、BMC22的IPMI session總數高於第一門檻值時，認定這個RMC21、BMC22處於所述第二關注狀態(步驟S65)，即，RMC21或BMC22的連線正常，但判斷可能即將出現異常狀態。

值得一提的是，若管理系統3於步驟S62中同時取得了RMC21及各個BMC22的系統資源使用率，則管理系統3可同時判斷是否有任一RMC21、BMC22的系統資源使用率高於第二門檻值(步驟S64)。於此情境下，管理系統3會認定目前的IPMI session總數高於第一門檻值，並且系統資源使用率高於第二門檻值的RMC21或BMC22處於所述第二關注狀態。

於一實施例中，所述系統資源使用率為RMC21、BMC22的中央處理單元或記憶體的使用率。於另一實施例中，所述系統資源使用率為RMC21、BMC22內部主要用來提供各項服務(如超文本傳輸協議(HyperText Transfer Protocol,HTTP)服務或IPMI服務等)所使用的系統資源的使用率，但不加以限定。

當管理系統3認定一個RMC21或BMC22處於第二類關注狀態後，管理系統3可進一步通過網路發出控制指令(例如第四控制指令)至處於第二類關注狀態的RMC21或BMC22，以令所述RMC21或BMC22重啟IPMI服務(步驟S66)。藉此，RMC21、BMC22可將目前累積的IPMI session清空，以避免異常狀態的發生。

於一實施例中，所述第四控制指令為重置指令，管理系統3是通過網路發出重置指令至處於第二類關注狀態的RMC21或BMC22，以強制RMC21或BMC22進行重置作業。如此一來，重置後的RMC21、BMC22即可直接重啟IPMI服務。惟，上述僅為本發明的其中一個具體實施例，但不以上述為限。

通過上述技術方案，管理系統3可以經由分析提早發現RMC21或BMC22可能即將發生異常狀態，因此可主動於遠端實施服務重啟機制，以避免RMC21或BMC22真的發生異常狀態而影響機櫃2的運作。

下面段落接著討論所述第三類關注狀態。

如前文中所述，本發明的管理系統3主要是通過網路與資料中心1內的機櫃2中的RMC21、BMC22進行溝通，並且管理者也是通過網路對這些RMC21、BMC22實施遠程管理程序。因此，當機櫃2中的BMC22失去網路連線時，管理系統3將無法與BMC22進行溝通，管理者也無法對BMC22進行管理。於本實施例中，BMC22失去網路連線的異常狀況，可能是因為IP位址設定錯誤所引起的。

一般來說，機櫃2內的BMC22可能被設定成使用動態IP位址(即，BMC22的網路模式被設定為動態IP模式)或靜態IP位址(即，BMC22的網路模式被設定為靜態IP模式)。若BMC22的網路模式為動態IP模式，則可由資料中心1內的動態主機設定協定(Dynamic Host Configuration Protocol,DHCP)伺服器(圖未標示)來主動配發一組動態IP位址給BMC22使用。若BMC22的網路模式為靜態IP模式，則管理者可通過管理系統3的操作介面來自行為BMC22設定一組靜態IP位址。

要對BMC22實施網路設定作業以設定一組可用的靜態IP位址，管理者需經由管理系統3下達至少四道指令給BMC22(即，需建立四個IPMI session)，包括：(1)設定BMC22的網路模式為靜態IP模式；(2)設定靜態IP位址；(3)設定子網路遮罩(netmask)；(4)設定閘道器(Gateway)IP位址。

如上所述，若管理者設定的靜態IP位址錯誤(例如與DHCP伺服器所配發的多組動態IP位址的其中之一重覆)，或是閘道器IP位址設定錯誤，則在多個子網域共存的環境，或是需要透過閘道器才能溝通的環境下，所述BMC22將無法與管理系統3連線。對於管理系統3來說，雖然這個BMC22所屬的端點伺服器220仍然存在，但因為管理系統3失去了與這個BMC22間的連線，因此將無法對這個BMC22(及其所屬的端點伺服器220)進行管理。此時，管理系統3可能需要於遠端介入以令BMC22恢復網路連線。

參閱圖8，為本發明的第三類關注狀態排除流程圖的第一具體實施例。本實施例中，所述管理系統3會定時存取資料庫31(步驟S71)，以由資料庫31中取得機櫃2內的各個BMC22的狀態資料、管理者通過管理系統3實施的操作行為、以及管理系統3基於所述操作行為所獲得的各項反饋資訊，並且判斷BMC22的狀態變化(步驟S72)。

於一實施例中，管理系統3在步驟S72中取得的狀態資料至少包括各個BMC22的網路模式(靜態IP模式或動態IP模式)、目前使用的靜態IP位址、子網路遮罩及閘道器IP位址等，不加以限定。並且，管理系統3在步驟S72中取得的反饋資訊主要包括所述操作行為實施時，管理系統3、機櫃2及各個端點伺服器220(以及各個BMC22)基於這個操作行為所產生的反饋、系統參數及執行數據等資料，但不加以限定。

步驟S72後，管理系統3首先依據所述狀態資料以及反饋資訊判斷機櫃2中是否有任一BMC22失去了與管理系統3間的連線(步驟S73)，並且，依據所述操作行為判斷管理者是否剛剛為機櫃2中的任一BMC22實施了網路設定作業(步驟S74)。若經分析後發現管理者剛剛對某一BMC22實施了網路設定作業，並且這個BMC22在網路設定作業後即失去連線，則管理系統3即可將這個BMC22視為處於所述第三類關注狀態(步驟S75)，即，BMC22已失去連線。

值得一提的是，於前述步驟S73中，管理系統3主要可於任一BMC22的網路模式被設定為靜態IP模式，並且這個BMC22的靜態IP位址與DHCP伺服器所配發的多組動態IP位址的其中之一重覆時，判斷這個BMC22失去網路連線(已經失去連線，或可能失去連線)。

另，於前述步驟S73中，管理系統3還可於任一BMC22的網路模式被設定為靜態IP模式，並且這個BMC22的閘道器IP位址設定錯誤時，判斷這個BMC22失去網路連線(已經失去連線，或可能失去連線)。惟，上述僅為本發明的部分具體實施範例，但不應以上述為限。

於步驟S75後，管理系統3已可認定某一BMC22處於所述第三類關注狀態，接著，管理系統3判斷在資料中心1中主要負責這個BMC22的RMC21為何(步驟S76)，並且控制這個RMC21通過機櫃2的內部硬體線路24檢查所述BMC22所屬的端點伺服器220(步驟S77)，以確認這個端點伺服器220是否存在(步驟S78)。

如圖2所示，一個機櫃2內的RMC21主要可通過內部硬體線路24實體連接機櫃2中的所有端點伺服器220中的BMC22，因此，即使BMC22 失去網路連線，同一個機櫃2內的RMC21仍可通過內部硬體線路24來與BMC22進行溝通。

若於上述步驟S78中判斷所述端點伺服器220不存在(例如已被抽離機櫃2，或已經損壞)，則管理系統3對應發出警示訊號(步驟S79)。於一實施例中，管理系統3可通過操作介面發出警示訊號(例如文字、燈光或聲響)，以對管理者進行警示。於另一實施例中，管理系統3可通過網路發送警示訊號(例如簡訊、電子郵件或通訊軟體)給管理者，以達到警示作用。

若於上述步驟S78中判斷所述端點伺服器220仍然存在，則管理系統3控制所述RMC21通過內部硬體線路24發送一組IPMI指令至所述BMC22，以令BMC22恢復網路連線(步驟S80)。於一實施例中，管理系統3可通過RMC21將IPMI指令發送至所述BMC22，以重新設定所述BMC22的靜態IP位址，或是重新設定所述BMC22的閘道器IP位址，藉此令BMC22恢復與管理系統3間的連線。

通過上述技術方案，管理系統3可以在BMC22失去連線後主動於遠端對BMC22實施救援機制，以令BMC22恢復網路連線。

本發明的方法可由管理系統3自動搜集所需資訊並對所有RMC21及BMC22的狀態進行分析，同時於任一RMC21、BMC22處於多種關注狀態之一時自動實施對應機制以排除異常狀態。如此一來，本發明的技術方案可大幅降低管理成本，亦使得資料中心1的監控無需人為干涉，也不受距離與時間的影響。

以上所述僅為本發明之較佳具體實例，非因此即侷限本發明之專利範圍，故舉凡運用本發明內容所為之等效變化，均同理皆包含於本發明之範圍內，合予陳明。

S31~S39‧‧‧分析與排除步驟

Claims

一種機櫃異常狀態的遠端排除方法，運用於具有一機櫃及由遠端與該機櫃連接的一機櫃伺服器管理系統的一資料中心，其中該機櫃具有一機櫃管理控制器(Rack Management Controller,RMC)及複數端點伺服器，各該端點伺服器分別具有一基板管理控制器(Baseboard Management Controller,BMC)，該遠端排除方法包括：a)該機櫃伺服器管理系統定時存取一資料庫以取得該RMC及各該BMC的狀態資料及事件日誌(event log)，以及一管理者通過該機櫃伺服器管理系統對該機櫃所執行的操作行為；b)依據該狀態資料、該事件日誌及該操作行為判斷該RMC及各該BMC的其中之一是否處於預設的多種關注狀態的其中之一；及c)於判斷任一RMC或BMC處於該多種關注狀態中的一第一類關注狀態時，該機櫃伺服器管理系統自動對處於該第一類關注狀態的該RMC或該BMC實施一遠端恢復機制，以解除該RMC或該BMC的異常狀態，其中該第一類關注狀態指該RMC或該BMC已處於該異常狀態，但尚未與該機櫃伺服器管理系統失去連線；其中該步驟b)是判斷該事件日誌中是否有任一事件的事件發生時間錯誤，並且於任一RMC或BMC的任一事件的事件發生時間錯誤時，視為該RMC或該BMC處於該第一類關注狀態，其中該機櫃伺服器管理系統於該事件日誌中的任一事件的事件發生時間為pre-init時，判斷該事件的事件發生時間錯誤。
如請求項1所述的機櫃異常狀態的遠端排除方法，其中更包括下列步驟：a01)該機櫃伺服器管理系統啟動；a02)該步驟a01)後，該機櫃伺服器管理系統定時主動遠程訪問該機櫃內的該RMC及各該BMC；a03)取得該RMC及各該BMC的該狀態資料及該事件日誌；a04)將該狀態資料及該事件日誌儲存至該資料庫；及a05)於該機櫃伺服器管理系統關閉前持續執行該步驟a02)至該步驟a04)。
如請求項1所述的機櫃異常狀態的遠端排除方法，其中更包括下列步驟：a11)該機櫃伺服器管理系統啟動；a12)該步驟a11)後，該機櫃伺服器管理系統提供一操作介面；a13)於通過該操作介面接受該管理者的該操作行為時，依據該操作行為的內容對該RMC及各該BMC實施一遠端管理程序；a14)取得該遠端管理程序對應的反饋資訊；a15)將該操作行為及該反饋資訊儲存至該資料庫；及a16)於該機櫃伺服器管理系統關閉前持續執行該步驟a12)至該步驟a15)。
如請求項1所述的機櫃異常狀態的遠端排除方法，其中該步驟c)包括下列步驟：c11)於判斷任一RMC或BMC處於該第一類關注狀態時，取得該機櫃伺服器管理系統本次存取該事件日誌的一時間戳記；及 c12)將該時間戳記做為該事件的一備位時間識別資訊並儲存於該資料庫中；其中，當該管理者通過一操作介面於該機櫃伺服器管理系統中查詢該事件日誌時，該機櫃伺服器管理系統顯示該備位時間識別資訊以做為該事件的該事件發生時間。
如請求項4所述的機櫃異常狀態的遠端排除方法，其中該步驟c)更包括下列步驟：c13)該機櫃伺服器管理系統發出一第一控制指令至處於該第一類關注狀態的該RMC或該BMC，以對該RMC或該BMC執行一時間校正程序。
如請求項5所述的機櫃異常狀態的遠端排除方法，其中該時間校正程序是通過網路時間協定(Network Time Protocol,NTP)校正該RMC或該BMC的時間，或強制該RMC或該BMC進行重置作業。
如請求項1所述的機櫃異常狀態的遠端排除方法，其中該步驟b)包括下列步驟：b1)依據該操作行為判斷該管理者是否對該RMC及各該BMC實施了一更新作業，其中該RMC及各該BMC於接受該更新作業的操作時自動進入一更新模式；b2)依據該狀態資料或該事件日誌判斷該RMC及各該BMC的該更新作業是否逾時或發生錯誤；b3)依據該狀態資料判斷該RMC及各該BMC的網路連線是否正常；及b4)於任一RMC或BMC執行了該更新作業、該更新作業逾時或發生錯誤、並且該網路連線正常時，視為該RMC或該BMC處於該第一類關注狀態。
如請求項7所述的機櫃異常狀態的遠端排除方法，其中該步驟c)包括下列步驟：c21)該機櫃伺服器管理系統發出一第二指令至處於該第一類關注狀態的該RMC或該BMC，以強制該RMC或該BMC離開該更新模式；及c22)該步驟c21)後，該機櫃伺服器管理系統發出一第三指令至處於該RMC或該BMC，以強制該RMC或該BMC進行重置作業或再次實施該更新作業。