TWI709083B

TWI709083B - 主機設備集中管理系統及其方法

Info

Publication number: TWI709083B
Application number: TW108111521A
Authority: TW
Inventors: 顏士傑
Original assignee: 中華電信股份有限公司
Priority date: 2019-04-01
Filing date: 2019-04-01
Publication date: 2020-11-01
Also published as: TW202038089A

Abstract

本發明揭露一種主機設備集中管理系統，其包括複數主機與一管理伺服器。複數主機係組成至少一群組，且管理伺服器包括一操作主控模組與一核心管理模組。操作主控模組係管理複數主機所組成之群組及對群組下達命令，而核心管理模組係管理主機之檔案同步流程或異常還原指令。同時，各主機中設置有一主機代理模組之代理程式，俾透過代理模組之代理程式將主機連線至管理伺服器以進行資料交換或任務索取。另外，本發明亦揭露一種主機設備集中管理方法。

Description

主機設備集中管理系統及其方法

本發明係關於一種主機設備管理技術，特別是指一種主機設備集中管理系統及其方法。

為了成本與效能的考量，超級電腦的架構逐漸朝向多台小型電腦協同運算的架構演進。管理者(如系統管理者)亦由管理一台大型電腦轉變為管理大量的小型電腦，且每台小型電腦都有獨立的帳號權限，並有各種不同套件的設定與更新管理需求、防火牆規則、儲存空間的監控與調整，對於管理者而言，管理工作的負荷是與主機之數量呈正比的。因此，集中化的主機管理是必要的機制，但集中的管理系統可能成為駭客關注的焦點，若遭滲透則可能進一步擴散到整個管理系統。

又，傳統的主機管理必須由管理者手動連線至主機，以指令的方式執行管理行為，後期也有發展出圖形使用者介面(Graphical User Interface；GUI)之網頁管理模式，但都是單機模式。對於管理者而言，多台主機還是必須一台一台進行處理，而針對雲化與大數據等需大量主機進行協同運算之應用系統，主機管理所耗費之人力將與主機之數量呈線性關係。

再者，常見之遠端主機管理方式多使用SSH/RSH等遠端(remote)shell協定對遠端之主機下指令以進行管理，故防火牆必須開通由管理伺服器(如中央管控伺服器)到主機之遠端shell的相關協定。因此，當管理伺服器遭到駭客滲透時，駭客有可能透過開通之防火牆規則連線至遠端之主機，此時對所有主機均有遭到滲透與破壞的風險。

另外，目前市面上常見的管理工具有Ansible、SaltStack、Chef、Puppet等幾種。Ansible與SaltStack較為類似，可直接透過CLI(command-line interface；命令列介面)向主機發出命令控制，亦可透過YAML(Yet Another Markup Language；又另一標記語言)進行命令處理，包括安裝套件或開關服務等。以功能面而言，Ansible與SaltStack比較適合做一次性的工作，例如系統部屬、發布應用或套件更新等。Chef則與Puppet較為類似，為Infrastructure as Code(基礎設施即代碼)的組態管理工具。Chef較以開發者的角度來檢視系統狀態，主要仰賴Git結構來描述任務應該如何配置到系統上。而Puppet則較以管理者的角度來做系統配置管理，以manifest檔案定義資源，描述系統架構需求以進行系統配置。惟，上述管理工具大多需搭配使用者自定的腳本，且使用者須依據自身需求定義腳本來處理較為複雜的情況。

因此，如何提供一種新穎或創新的主機設備集中管理系統及其方法，實已成為本領域技術人員之一大研究課題。

本發明提供一種新穎或創新的主機設備集中管理系統及其方法，可以例如管理大量主機(受管控主機)或有效提升管理系統之效率。

本發明之主機設備集中管理系統包括：複數主機，係組成至少一群組；以及一管理伺服器，係集中管理複數主機，該管理伺服器包括一操作主控模組及一核心管理模組。操作主控模組管理複數主機所組成之群組及對複數主機所組成之群組下達命令，且核心管理模組管理主機之檔案同步流程或異常還原指令。同時，各主機中設置有一主機代理模組之代理程式，俾透過主機代理模組之代理程式將主機連線至管理伺服器以進行資料交換或任務索取。

本發明之主機設備集中管理方法包括：將複數主機組成至少一群組，且各主機中設置有一主機代理模組之代理程式；由包括一操作主控模組與一核心管理模組之管理伺服器集中管理複數主機，其中，管理伺服器之操作主控模組管理複數主機所組成之群組及對複數主機所組成之群組下達命令，且管理伺服器之核心管理模組管理主機之檔案同步流程或異常還原指令；以及透過主機代理模組之代理程式將主機連線至管理伺服器以進行資料交換或任務索取。

為讓本發明之上述特徵和優點能更明顯易懂，下文特舉實施例，並配合所附圖式作詳細說明。在以下描述內容中將部分闡述本發明之額外特徵及優點，且此等特徵及優點將部分自所述描述內容可得而知，或可藉由對本發明之實踐習得。本發明之特徵及優點借助於在申請專利範圍中特別指出的模組及組合來認識到並達到。應理解，前文一般描述與以下詳細描述兩者均僅為例示性及解釋性的，且不欲約束本發明所欲主張之範圍。

1‧‧‧主機設備集中管理系統

10‧‧‧管理伺服器

11‧‧‧操作主控模組

111‧‧‧主控台

12‧‧‧核心管理模組

13‧‧‧命令代碼表

14‧‧‧資料庫

20‧‧‧受管控主機

21‧‧‧主機代理模組

22‧‧‧代理程式

23‧‧‧同步程式

A01至A09、B01至B13、C01至C08‧‧‧步驟

D01至D06、E01至E14、F01至F13‧‧‧步驟

G01至G13、H01至E08、I01至F08‧‧‧步驟

J01至J20、K01至K14‧‧‧步驟

第1圖為本發明之主機設備集中管理系統的架構示意圖；第2圖為本發明之主機設備集中管理方法的群組管理流程示意圖；第3圖為本發明之主機設備集中管理方法的帳號管理流程示意圖；第4圖為本發明之主機設備集中管理方法的命令管理流程示意圖；第5A圖至第5B圖為本發明之主機設備集中管理方法的命令派送流程示意圖；第6圖為本發明之主機設備集中管理方法的同步管理流程示意圖；第7圖為本發明之主機設備集中管理方法的檔案同步流程示意圖；第8A圖至第8C圖為本發明之主機設備集中管理方法的一實施例流程示意圖；以及第9圖為本發明之主機設備集中管理方法的另一實施例流程示意圖。

以下藉由特定的具體實施形態說明本發明之實施方式，熟悉此技術之人士可由本說明書所揭示之內容了解本發明之其他優點與功效，亦可因而藉由其他不同的具體等同實施形態加以施行或應用。

請參閱第1圖，係為本發明之主機設備集中管理系統1的架構示意圖。同時，此主機設備集中管理系統1之主要技術內容如下，其餘技術內容如同第2圖至第9圖之詳細說明。

如第1圖所示，主機設備集中管理系統1至少包括一管理伺服器10與複數受管控主機20。管理伺服器10可集中管理複數受管控主機20，並包括一具有主控台111之操作主控模組11、一核心管理模組12、一命令代碼表13與一資料庫14。複數受管控主機20可組成至少一群組(主機群組)，且各受管控主機20中設置或植入有一主機代理模組(或客端代理模組)21之代理程式22與同步程式23。管理伺服器10之操作主控模組11可管理複數受管控主機20所組成之群組及對複數受管控主機20所組成之群組下達命令，而管理伺服器10之核心管理模組12可管理受管控主機20之檔案同步流程或異常還原指令，且透過主機代理模組21之代理程式22可將受管控主機20主動連線至管理伺服器10以進行資料交換或任務索取。

上述管理伺服器10可為管控伺服器、中央伺服器、中央管控伺服器等，受管控主機20可為主機設備、列管主機、列管伺服器、作業系統主機等，而下述管理者可為系統管理者、伺服器管理者等，但不以此為限。

操作主控模組11係用以提供使用者與後端互通之中介，並提供實際與受管控主機20進行操作管理之主控台111(平台)，以透過主控台111操作管理受管控主機20。而且，操作主控模組11可包括使用者之身分認證與授權、各種設定內容管理與系統管理UI(user interface；使用者介面)等。

申言之，操作主控模組11可包括(1)提供使用者認證與授權功能；(2)管理使用者之帳號；(3)管理複數受管控主機20所組成之群組(主機群組)；(4)對各群組(主機群組)下達命令；以及(5)管理命令代碼表13，且每一命令代碼包括命令執行指令、命令確認指令、命令成功指令及命令失敗指令等四組命令。

核心管理模組12係用以處理使用者之管理需求，並組合與派送命令至受管控主機20，且核心管理模組12可包括群組管理邏輯、命令管理、排程管理與RESTful(Representational State Transfer；表現層狀態轉換)API(application programming interface；應用程式介面)等。

申言之，核心管理模組12可包括(1)儲存受管控主機20之待執行命令；(2)儲存受管控主機20之待同步檔案；(3)管理各受管控主機20之檔案同步流程、狀態檢查指令或異常還原指令；(4)提供加密的RESTful API(表現層狀態轉換應用程式介面)以供主機代理模組21呼叫；以及(5)定期依據排程送出命令。

主機代理模組21係用以操作或管理受管控主機20之代理平台，負責接收與轉譯系統管理之相關命令，再加以執行及回報執行結果予該管理伺服器10，俾達到跨平台之需求。主機代理模組21亦可蒐集系統服務與模組執行狀態，並同步檔案之異動情形。而且，主機代理模組21可相容於Linux系統、IBM AIX(Advanced Interactive executive；先進互動執行)系統等常見UNIX系統。再者，受管控主機20可透過主機代理模組21之代理程式22與管理伺服器10之核心管理模組12進行溝通，以進行系統管理之作業。

申言之，主機代理模組21可包括(1)定期從管理伺服器10之核心管理模組12取得待執行命令與待同步檔案；(2)轉譯待執行命令為受管控主機20之可執行命令；(3)執行命令與確認命令、邏輯判斷之成功指令與失敗指令；(4)向核心管理模組12回報執行結果；(5)定期確認系統服務狀態未異常變動，若有變動則發出告警；(6)定期確認同步檔案未經人工修改，若經修改則發出告警；(7)向核心管理模組12定期回報模組健康狀態；(8)透過同步程式進行同步檔案之同步作業；以及(9)透過同步程式處理同步檔案之狀態檢查與異常還原作業。

本發明可提供管理者一個較為穩定的環境，於新的主機(受管控主機20)加入時能自動調整，使主機(受管控主機20)符合管理者需求之環境狀態，當有系統變更需求時亦能對大批主機(受管控主機20)進行異動作業，適合作為日常維護與確保系統運行狀態之工具。

管理伺服器10可以管理大量的主機(受管控主機20)，亦可管理一或多種不同作業系統的主機(受管控主機20)。同時，主機代理模組21之代理程式22可透過RESTful API(表現層狀態轉換應用程式介面)與管理伺服器10進行溝通及資訊之傳輸，且資訊之傳輸過程中可藉由加密演算法例如SSL(Secure Sockets Layer；安全通訊端層)對資訊予以加密，避免資訊遭到竊聽。

本發明採用於受管控主機20中設置或植入主機代理模組21之代理程式22的方法，俾透過代理程式22由受管控主機20主動向管理伺服器10回報資訊或索取任務以進行系統管理，亦即受管控主機20可透過主機代理模組21之代理程式22主動與管理伺服器10進行溝通，以避免駭客透過開放之防火牆規則進行滲透與破壞。因此，防火牆只須開放由受管控主機20主動連線至管理伺服器10，而不開放由管理伺服器10主動連線至受管控主機20，以避免駭客或有心人士透過管理伺服器10向受管控主機20進行連線與攻擊之行為。

本發明除可搭配管理工具之Ansible腳本(playbook)外，亦提供依照命令結果執行不同指令的邏輯判斷式命令。而且，本發明之主機代理模組21(同步程式23)亦提供切換測試或異常還原的流程，可以在使用者不需依據自身需求自行撰寫腳本的情況下達到同步檔案或異動錯誤還原的機制。

第2圖為本發明之主機設備集中管理方法的群組管理流程示意圖，第3圖為本發明之主機設備集中管理方法的帳號管理流程示意圖，第4圖為本發明之主機設備集中管理方法的命令管理流程示意圖，第5A圖至第5B圖為本發明之主機設備集中管理方法的命令派送流程示意圖，第6圖為本發明之主機設備集中管理方法的同步管理流程示意圖，第7圖為本發明之主機設備集中管理方法的檔案同步流程示意圖。同時，本發明之主機設備集中管理方法的主要技術內容如下列第2圖至第9圖之詳細說明，其餘技術內容如同第1圖之主機設備集中管理系統1的詳細說明，於此不再重覆敘述。

本發明之主機設備集中管理方法可包括：將第1圖所示之複數受管控主機20組成至少一群組，且各受管控主機20中設置或植入有一主機代理模組21之代理程式22；由包括一操作主控模組11與一核心管理模組12之管理伺服器10集中管理複數受管控主機20，其中，管理伺服器10之操作主控模組11管理複數受管控主機20所組成之群組及對複數受管控主機20所組成之群組下達命令，且管理伺服器10之核心管理模組12 管理受管控主機20之檔案同步流程或異常還原指令；以及透過主機代理模組21之代理程式22將受管控主機20主動連線至管理伺服器10以進行資料交換或任務索取。

本發明之主機設備集中管理方法中，在業務流程方面可分為[1]群組管理、[2]帳號管理、[3]命令派送、[4]檔案同步等四個流程，茲分別敘述如下。

[1]群組管理：群組為一個對應到多台主機(受管控主機20)的虛擬連結，在命令派送與設定同步的部分可將群組視為第1圖之受管控主機20來選取，實際運行時會依據該群組所對應的主機列表進行展開，將實際上之命令派送到所有選取與展開之群組(主機群組)。管理者可透過定義不同群組，以針對不同類別或區域的主機(受管控主機20)進行批次管理。

群組管理流程：當進入管理伺服器10之群組管理模式時，管理伺服器10會列出使用者目前擁有之群組列表，以供使用者依據群組列表選擇新增、重新命名或編輯群組內容。新增是定義一組內容為空的群組，重新命名是針對現有之群組進行重新命名之動作。編輯群組內容是針對該群組所對應之主機列表進行管理之行為，亦包括新增與刪除兩種動作，使用者可自由編輯該群組所對應的主機列表。

舉例而言，在第2圖之步驟A01至步驟A09之群組管理流程中，第1圖之管理伺服器10可顯示使用者現有之群組列表(見步驟A01)，以供使用者新增、命名或編輯群組內容(見步驟A02)。在新增時，使用者輸入需新增之群組名稱(見步驟A03)。在重新命名時，使用者輸入新群組名稱(見步驟A04)。在編輯群組內容時，管理伺服器10顯示使用者所選取之群組列表(見步驟A05)，以供使用者選擇新增或刪除(見步驟A06)；在新增時，管理伺服器10顯示可新增之主機列表(見步驟A07)，以供使用者新增選定之主機(見步驟A08)；以及在刪除時，使用者刪除被選定之主機(見步驟A09)。

[2]帳號管理：在傳統的帳號管理中，各台伺服器(主機)都有自身的帳號權限列表，管理者(如伺服器管理者)必須連線至個別伺服器(主機)以進行帳號管理操作。為提升操作方便性與彈性，本發明設計了完整的帳號管理流程，使用者可透過第1圖所示管理伺服器10之操作主控模組11進行帳號管理，且管理伺服器10之核心管理模組12可透過主機代理模組21將帳號管理之命令佈署到各受管控主機20(個別伺服器)上。

帳號管理流程：當進入管理伺服器10之帳號管理模式時，第1圖之管理伺服器10會列出使用者所選取之受管控主機20(伺服器)上現有的帳號列表，以供使用者依據帳號列表選擇新增或異動現有之帳號。在使用者填入必要之帳號屬性後，第1圖之核心管理模組12可組合出所需之命令代碼，並將命令代碼傳送至受管控主機20之主機代理模組21以解譯出所需之具體指令予以執行，再由主機代理模組21將執行結果回報至管理伺服器10之操作主控模組11(主控台111)予以呈現。

舉例而言，在第3圖之步驟B01至步驟B13之帳號管理流程中，第1圖之管理伺服器10可對使用者進行認證以讓使用者登入系統(見步驟B01)，並顯示受管控主機20之列表(見步驟B02)以供使用者選取受管控主機20(見步驟B03)，再顯示受管控主機20之帳號列表(見步驟B04)以供使用者新增或異動帳號(見步驟B05)。在新增時，管理伺服器10顯示新增帳號所需填寫之表格(見步驟B06)。在異動時，管理伺服器10顯示該帳號目前的屬性與狀態(見步驟B07)。使用者在填寫帳號之表格完畢後(見步驟B08)、或在填寫帳號之屬性與狀態完畢後(見步驟B09)，核心管理模組12可組合出所需之命令代碼(見步驟B10)，並將命令代碼傳送至受管控主機20之主機代理模組21(見步驟B11)，以由主機代理模組21接收、解譯與執行所需之具體指令(見步驟B12)，再顯示新增或異動後之帳號列表於操作主控模組11之主控台111(見步驟B13)。

[3]命令派送：為了避免實際上執行之命令遭到竊聽與竄改的可能，本發明摒棄於管理端組合好指令，再透過網路傳送到受管控主機20進行執行之方法。例如，本發明可改由定義第1圖之命令代碼表13，並將命令代碼表13以同步設定檔案之方式傳送到受管控主機20，當使用者要傳送命令時，管理伺服器10可依據命令代碼表13將實際指令轉換為代碼，再將代碼加上所需要或相關之至少一參數後，傳送至受管控主機20以進行解譯與執行。同時，命令管理可分為(A)命令管理流程與(B)命令派送流程兩種。

(A)命令管理流程：當進入管理伺服器10之命令管理模式時，第1圖之管理伺服器10會列出使用者之命令列表，以供使用者依據命令列表選擇新增、重新命名或編輯命令內容。新增是定義一組內容為空的命令，重新命名是賦予該命令一個較為容易識別之名稱。編輯命令內容是定義該命令具體的指令的內容，具體的指令可為單一指令、Shell指令碼(Shell script)或Ansible腳本，除了指令外亦可輸入選用的執行後檢查指令、成功指令或失敗指令，使用者可在不撰寫複雜Shell指令碼與Ansible 腳本的情況下也能做到條件判斷式指令的能力。同時，Ansible腳本可支援檢查點機制，若Ansible腳本執行失敗重送時，可跳至前次失敗的部分接續執行，以避免重複執行的情況。在完成編輯後，管理伺服器10可依據命令列表產生命令代碼表13，並將命令代碼表13交由檔案同步功能同步到受管控主機20上。

舉例而言，在第4圖之步驟C01至步驟C08之命令管理流程中，第1圖之管理伺服器10可顯示現有之命令列表(見步驟C01)，以供使用者選擇新增、重新命名或編輯命令內容(見步驟C02)。在新增時，使用者輸入需新增之命令名稱(見步驟C03)。在重新命名時，使用者輸入新命令名稱(見步驟C04)。在編輯命令內容時，管理伺服器10顯示與提供編輯命令內容(見步驟C05)，以供使用者輸入或上傳命令內容(見步驟C06)，且命令內容中具體的指令可為單一指令、Shell指令碼或Ansible腳本。然後，管理伺服器10會依據此命令列表產生命令代碼表13(見步驟C07)，並將命令代碼表13交由檔案同步功能同步到受管控主機20上(見步驟C08)。

(B)命令派送流程：派送命令時須先檢查第1圖之管理伺服器10之命令代碼表13是否有此命令，並將命令轉換為代碼，再將代碼加上需要或相關之至少一參數後，傳送至管理伺服器10之派送區以等待受管控主機20前來收取命令。受管控主機20可定時前來派送區索取命令(命令條)，再將命令依據命令代碼表13轉換回實際指令，單一指令與Shell指令碼皆可直接執行。而且，受管控主機20可依據需求執行檢查指令，再依據執行結果決定要執行成功指令或失敗指令，以簡單達到條件判斷的功能(例如執行校時，若失敗則重啟ntp服務)。Ansible腳本可透過Ansible工具執行，先確認是否為執行失敗重送的情況，若為失敗重送則從上次的失敗點開始接續執行；反之，若非失敗重送則從頭開始運行。若Ansible腳本經執行失敗，則記錄失敗點，以供後續重作使用。然後，將執行結果打包回傳送至管理伺服器10(管理端)。當管理伺服器10(管理端)確認此命令完成後，即可提供執行結果供使用者查看。

舉例而言，在第5A圖之步驟D01至步驟D06之命令派送流程中，第1圖之管理伺服器10先選定派送之命令(見步驟D01)，並檢查命令代碼表13是否有此命令(見步驟D02)？若否(無此命令)，則表示命令錯誤(見步驟D03)；若是(有此命令)，則管理伺服器10取得命令代碼加上必要之參數後打包送往派送區(見步驟D04)。接著，管理伺服器10判斷命令是否執行完成(見步驟D05)？若已經執行完成，則管理伺服器10註記命令完成紀錄執行結果以供備查(見步驟D06)；反之，若尚未執行完成，則管理伺服器10繼續判斷命令是否執行完成(見步驟D05)。

又，在第5B圖之步驟E01至步驟E14之命令派送流程中，係接續第5A圖之步驟D04。由第1圖之受管控主機20先定時前來管理伺服器10之派送區收取命令(見步驟E01)，並檢查管理伺服器10之命令代碼表13是否有此命令(見步驟E02)？若否(無此命令)，則受管控主機20回報命令代碼不存在(見步驟E03)予管理伺服器10。反之，若是(有此命令)，則受管控主機20判斷命令之種類為何(見步驟E04)？若命令之種類為單一指令或Shell指令碼，則受管控主機20需依據命令執行及可選地執行檢查命令(見步驟E05)。接著，受管控主機20判斷是否已檢查成功(見步驟E06)？若檢查有異常，則受管控主機20可選地執行檢查失敗指令(見步驟 E07)；反之，若檢查成功，則受管控主機20可選地執行檢查成功指令(見步驟E08)，再回傳執行結果予管理伺服器10(見步驟E14)。

在上述步驟E04中，若命令之種類為Ansible腳本，則受管控主機20判斷是否為失敗重送(見步驟E09)？若是(為失敗重送)，則受管控主機20呼叫Ansible工具由前次失敗點開始執行腳本(見步驟E10)；反之，若否(非失敗重送)，則受管控主機20呼叫Ansible工具從頭執行腳本。若執行成功(見步驟E12)，則受管控主機20回傳執行結果予管理伺服器10(見步驟E14)；反之，若執行有異常，則受管控主機20儲存失敗點(見步驟E12)，並回傳執行結果予管理伺服器10(見步驟E14)。

[4]檔案同步：係為一個自動化管理第1圖之受管控主機20的機制，用以確保群組之所有受管控主機20能擁有相同之檔案。當特定檔案有異動需求時，透過此機制自動同步到所有受管控主機20上，搭配檔案異動前後自動執行之命令、檢查與還原指令，可確保設定檔案異動後仍可正常提供服務。同時，檔案同步可分為(A)同步管理流程與(B)檔案同步流程兩種。

(A)同步管理流程：當進入管理伺服器10之同步管理模式時，第1圖之管理伺服器10將顯示使用者目前擁有之同步規則，以供使用者依據同步規則新增或刪除相關規則、或者異動規則之內容，且異動規則之內容分為異動檔案與異動命令兩種。在異動檔案時，使用者須上傳或編輯檔案內容，在編輯完成檔案內容後，管理伺服器10將計算檔案之MD5(Message-Digest algorithm；訊息摘要演算法)，並將檔案內容與MD5一併儲存於資料庫14中。又，異動命令包括異動前指令、異動後指令、異動後確認指令與異常還原指令，使用者可分別編輯這些異動命令，以確保檔案異動時可成功異動。

舉例而言，在第6圖之步驟F01至步驟F13之同步管理流程中，第1圖之管理伺服器10可顯示現有之同步規則(見步驟F01)，以供使用者新增、刪除或異動規則(見步驟F02)。在新增規則時，使用者可輸入新規則之名稱(見步驟F03)，以新增內容為空值之同步規則(見步驟F04)。在刪除規則時，管理伺服器10可顯示刪除之規則與關聯之設備(受管理主機20)以供使用者確認是否刪除(見步驟F05)，再顯示被刪除之規則與關聯之設備(見步驟F06)。在異動規則時，管理伺服器10可顯示異動規則之內容(見步驟F07)，以供使用者選擇異動項目(見步驟F08)為異動檔案或異動命令。在異動檔案時，使用者可上傳或編輯檔案(見步驟F09)，並將所產生檔案之MD5(訊息摘要演算法)一併儲存於管理伺服器10之資料庫14中(見步驟F10)。在異動命令時，使用者可編輯異動前指令與異動後指令(見步驟F11)，亦可進一步編輯異動後確認指令與異常還原指令(見步驟F12)。在異動完畢後，即完成異動(見步驟F13)。

(B)檔案同步流程：第1圖之受管控主機20可定時向管理伺服器10索取同步規則之資訊，再依照同步規則比對受管控主機20中本地檔案之MD5與規則之差異(即兩者是否不同)。若有不同表示需要進行同步作業，此時受管控主機20會開始下載異動檔案及同時備份原始檔案，並在下載完成後先執行異動前指令(如先停止服務)。接著，受管控主機20使用下載檔案來還原檔案，並執行異動後指令(如啟動服務)，再執行異動後檢查指令。若檢查失敗，則表示可能此同步後的檔案有問題，故需將檔案還原，受管控主機20可先執行異動還原指令(如重啟服務)，再回報此檔案異動失敗。若檢查成功，則表示此檔案異動成功，受管控主機20可繼續確認，直到完成所有檔案異動的作業。

舉例而言，在第7圖之步驟G01至步驟G13之檔案同步流程中，第1圖之受管控主機20先向管理伺服器10索取同步流程規則之資訊(見步驟G01)，並比對受管控主機20中本地檔案之MD5與規則之差異(見步驟G02)。若比對結果(見步驟G03)為相同，則受管控主機20繼續檢查下一個檔案(見步驟G04)；又，若完成比對為全部相同，則表示檔案同步完成(見步驟G05)。反之，若比對結果為不同，則受管控主機20下載異動檔案及備份原始檔案(見步驟G06)，並執行異動前指令(見步驟G07)，且將目標檔案異動為主機(受管控主機20)上之內容(見步驟G08)，再執行異動後指令與檢查指令(見步驟G09)，然後判斷是否檢查成功(見步驟G10)。若檢查成功，則受管控主機20刪除原始檔案備份(見步驟G11)；反之，若檢查失敗，則受管控主機20使用備份檔案還原異動檔案並執行異動還原指令(見步驟G12)，再回報檔案同步失敗(見步驟G13)。

第8A圖至第8C圖為本發明之主機設備集中管理方法的一實施例流程示意圖。在本實施例中，使用者可登入第1圖之管理網站(管理伺服器10)之主控台111，針對所有受管控主機20派送ntpq -p命令以檢查系統校時之情況，並設定台北與高雄兩地設備(受管控主機20)使用不同的校時伺服器來設定/etc/ntp.conf校時設定檔以互相同步及套用。同時，假設不同的校時伺服器(受管控主機20)中，主機X1、主機X2為台北群組，主機Y1、主機Y2為高雄群組，且主機X1、主機X2、主機Y1、主機Y2 均為受管控主機20。

在第8A圖之步驟H01至步驟H02中，使用者先登入第1圖之管理網站(管理伺服器10)之主控台111，以透過主控台111選擇及進入管理伺服器10之命令派送模式。在第8A圖之步驟H03至步驟H05中，使用者於命令選單選取派送命令「ntpq -p」以查詢校時之情況，並選取或將目標設定為所有設備(受管控主機20)，再送出命令。在第8A圖之步驟H06至步驟H08中，使用者等待派送命令完成，並分別檢查各個設備(受管控主機20)的執行情況與結果(即查看命令執行結果與紀錄)，再回到主控台111。

在第8B圖之步驟I01至步驟I03中，使用者回到或再次登入管理網站(管理伺服器10)之主控台111，以透過主控台111選擇群組管理模式，並建立及分別命名「台北」與「高雄」兩個群組。在第8B圖之步驟I04至步驟I08中，使用者選擇編輯「台北」群組內容以增加主機X1與主機X2到「台北」群組，並編輯「高雄」群組內容以增加主機Y1與主機Y2到「高雄」群組，再回到主控台111。

在第8C圖之步驟J01至步驟J02中，使用者再次登入第1圖之管理網站(管理伺服器10)之主控台111，以透過主控台111選擇同步管理模式。在第8C圖之步驟J03中，使用者新增兩個同步設定(即建立台北校時與高雄校時兩個同步設定)，以分別命名為「台北校時設定」與「高雄校時設定」。

在第8C圖之步驟J04至步驟J06中，使用者編輯「台北校時設定」的同步內容，以將目標目錄設定為/etc/ntp.conf，且檔案內容為 ntp的設定(即上傳與編輯校時設定ntp.conf)，並指定校時伺服器(受管控主機20)為台北的校時伺服器。在第8C圖之步驟J07至步驟J10中，使用者依序設定「台北校時設定」之異動前指令為「service ntpd stop」，設定「台北校時設定」之異動後指令為「service ntpd start」，設定「台北校時設定」之異動後確認指令為「service ntpd status」，以及設定「台北校時設定」之異動還原指令為「service ntpd restart」。在第8C圖之步驟J11中，使用者設定「台北校時設定」的目標為「台北群組」。

仿照上述步驟J04至步驟J11，在第8C圖之步驟J12至步驟J14中，使用者編輯「高雄校時設定」的同步內容，以將目標目錄設定為/etc/ntp.conf，且檔案內容為ntp的設定(即上傳與編輯校時設定ntp.conf)，並指定校時伺服器為高雄的校時伺服器。在第8C圖之步驟J15至步驟J18中，使用者依序設定「高雄校時設定」之異動前指令為「service ntpd stop」，設定「高雄校時設定」之異動後指令為「service ntpd start」，設定「高雄校時設定」之異動後確認指令為「service ntpd status」，以及設定「高雄校時設定」之異動還原指令為「service ntpd restart」。在第8C圖之步驟J19中，使用者設定「高雄校時設定」的目標為「高雄群組」。最後，在第8C圖之步驟J20中，使用者分別觀察「台北校時設定」與「高雄校時設定」兩者的同步情況及結果。

第9圖為本發明之主機設備集中管理方法的另一實施例流程示意圖，請一併參閱第1圖。同時，假設上述第8A圖至第8C圖之情境下，「高雄校時設定」的檔案內容錯誤，其相關運作流程如下(以主機Y1為例)。

在第9圖之步驟K01至步驟K02中，主機Y1(受管控主機 20)定時向第1圖之管理伺服器10索取同步清單以處理高雄校時項目。在第9圖之步驟K03中，依據同步清單之內容，針對「高雄校時設定」須計算主機Y1上的/etc/ntp.conf的MD5值。

在第9圖之步驟K04中，主機Y1發現MD5值與同步清單所記載之「高雄校時設定」的MD5內容不符，故需進行檔案同步作業。在第9圖之步驟K05中，主機Y1(受管控主機20)向管理伺服器10之核心管理模組12要求下載「高雄校時設定」之檔案內容。在第9圖之步驟K06中，主機Y1備份/etc/ntp.conf至「/tmp/高雄校時設定_ntp.conf」。

在第9圖之步驟K07中，主機Y1執行異動前指令「service ntpd stop」，以關閉ntp服務。在第9圖之步驟K08中，主機Y1使用「高雄校時設定」的下載檔案(檔案內容)以覆蓋/etc/ntp.conf。

在第9圖之步驟K09中，主機Y1執行異動後指令「service ntpd start」，以啟動ntp服務。在第9圖之步驟K10至步驟K11中，主機Y1執行異動後檢查指令「service ntpd status」，檢查發現ntp服務異常，即ntp服務無法啟動(啟動失敗)。在第9圖之步驟K12中，主機Y1使用備份檔案「/tmp/高雄校時設定_ntp.conf」覆蓋/etc/ntp.conf。

在第9圖之步驟K13中，主機Y1執行異動還原指令「service ntpd restart」，以重新啟動ntp服務。在第9圖之步驟K14中，主機Y1回報「高雄校時設定」之同步失敗及回傳具體紀錄(Log)予管理伺服器10以供備查。

綜上，本發明之主機設備集中管理系統及其方法可至少具有下列特色、優點或技術功效。

一、本發明提供管理者(如系統管理者)方便與快速的管理大量主機(受管控主機)之機制，能有效提升管理系統之效率。

二、本發明包括設定與檔案同步、群組化與批次管理、主控台之機制，能提供管理者方便與簡潔的進行多台主機(受管控主機)之管理，進而降低管理人力之需求。

三、本發明可於主機(受管控主機)中植入代理程式，俾透過代理程式由主機(受管控主機)連線至管理伺服器以進行資料交換或任務索取，從而降低駭客透過防火牆之開通規則進行滲透破壞之行為。

四、本發明之防火牆規則只開放由主機(受管控主機)連線至管理伺服器，而不開放由管理伺服器連線至主機(受管控主機)，故即使管理伺服器遭到駭客滲透，駭客也無法連線至主機(受管控主機)進行滲透與破壞。反之，若主機(受管控主機)先遭到駭客滲透，駭客最多也只能連至管理伺服器進行破壞，故本發明可有效隔離遭駭客滲透之區域，降低整體主機(受管控主機)的風險。

五、本發明可能應用之產業例如為資訊軟體產業，且可能應用之產品例如為網路應用程式的相關系統平台。

上述實施形態僅例示性說明本發明之原理、特點及其功效，並非用以限制本發明之可實施範疇，任何熟習此項技藝之人士均可在不違背本發明之精神及範疇下，對上述實施形態進行修飾與改變。任何運用本發明所揭示內容而完成之等效改變及修飾，均仍應為申請專利範圍所涵蓋。因此，本發明之權利保護範圍，應如申請專利範圍所列。