系統架構與功能

本研究系統分成三大部分 Web Component、MPI Component 與 Store Component，

如圖 3.1 所示。其中 Web Component 與 MPI Component 可各自獨立，也可設置於不 同主機。如果以 Component-based 角度與 MVP 架構的定義，Model 為服務、View 為 UserInterface 與 Presenter 為資料流控制中樞來解釋，Web Component 可以視作 View、MPI Component 像是 Presenter 的資料流控制，而 Open MPI 即是 Model 處理 服務。此部分為各主要結構設計的功能與敘述，詳細引入 Design Pattern 設計實作 於下一節開始說明。

圖 3.1 系統架構圖

Web Component 主要的功能為提供使用者監控與管理介面，提供一般網頁介面 與行動裝置網頁介面，使用者可自行擴充服務功能與修改。或是利用提供的與 MPI

Server 通訊的 MPI Client Library 開發其他 Web 網站來使用論文中的 MPI Server 建 立連結。網頁與行動裝置網頁利用 RESTful 機制與 Web Service 資料交流。使用者 也可直接使用 RESTful 機制向 Web Service 索取 MPI Server 的資訊，但只限於基本 資訊的取得，此時 Web Service 便會利用 MPI Client Library 向 MPI Server 要求資料。

但 Web Component 不會儲存使用者帳號與資料，必頇將需求傳送至 MPI Server 階 段時才會做權限驗證，再把資料回傳 Web Component，如圖 3.2 循序圖，故 Web Component 可以看作使用者操作整個系統的入口點。當採用 RESTful 提交需求需傳 送一組使用者帳號密碼，無傳送使用者帳號密碼或帳號密碼錯誤時，Web Service 的流程設計直接將 MPI Server 返回的 JSON 格式資料往使用者傳遞，如圖 3.3 為一 個取得叢集中所有電腦清單的請求，但無傳送帳號與密碼，返回夾帶錯誤訊息的 JSON 格 式 資 料 。 正 確 取 得 清 單 的 URL 例 子 如 http://address/Node/list&user=user&password=password/show，其中 Node 為服務名稱，

list&user=user&password=password 代表傳遞的參數，最後的 show 為服務內的 Method。

圖 3.2 Web Service 循序圖

圖 3.3 RESTful 要求資料, 帳號密碼錯誤

MPI Component 包含了 MPI Server、MPI Manager、Task、MPI Dispatch Module、

Log System 和 Record System。此部分各結構資料傳輸皆是以命名為 Package 的 Map<String,Object>資料結構，圖 3.4，構透過 getter 與 setter 引入 Guarded Suspension Design Patter 的特性設計，確保在多執行緒的設計下資料的正確性。

圖 3.4 Package 資料結構

MPI Server 以 ServerSocket 設計負責與 MPI Client API 的通訊建立，當接受的 是一 MPI 程式任務的需求，則交由 Task 負責，將 Package 置放於此；如果是查詢 狀態需求，如查詢 MPI 任務執行狀態等，則交由 MPI Manager 負責，與置放 Package，

故依照接受的需求不同，Package 會置放於不同實體。

圖 3.5 是 MPI Server 接受連線需求後的流程圖，Task 專一處理有關 MPI 程式執 行的需求，然後調用 MPI Dispatch Module 內的子系統功能完成 MPI 啟動叢集內電 腦的分派、啟動命令建立、資料轉換、啟動 Open MPI 與執行完成前後對 Package 內 Data 欄位的外部客製程序執行，最後交給 User History Component 建立結果儲存 與執行紀錄。其中執行外部客製程序的子功能系統為 Customer Before Runner 與

Customer After Runner，提供引用本系統的開發者可以自行在不重新編譯整個系統 的前提下加入額外對 Package 處理的程序，詳細設計方法在後續章節說明。

MPI Manager 除在 MPI Server 啟動後持續監測本身系統狀態與叢集內電腦的狀 態外，也負責由 MPI Server 取得資訊查詢要求的處理。其中監測本身系統狀態是一 Observer Design Pattern 的實現，監測對象包含所有連線與 Task Queue 等。查詢要 求分成三類關於 Log 資料查詢、MPI 執行結果或紀錄查詢與系統運作的狀態查詢。

Log 類包含歷史叢集電腦運作紀錄查詢、Task 執行任務紀錄查詢與歷史運作效能紀 錄查詢等。

如 Open MPI 程式執行結果需要產出檔案，可藉由引入 Record System Library 提供的 Method 建立檔案，不讓開發者自行建立檔案的原因為建立的檔案頇由論文 系統 MPI Server 統一管理，在 Record System 初始化時會藉由傳入的 Package 取得 系統定義資料，其中包含此提交 MPI 程式啟動使用者的本次任務存放檔案的位址，

建立的檔案由亂數命名存放，並寫入位址與檔名在回傳的 Package 中，MPI 程式執 行完成後，回傳 Package，並由 Store Component 紀錄，便於後續查詢取得檔案。

在 MPI Component 各個系統執行建立都會透過 Spring Framework 的 AOP 機制 寫入 Log，Log System 便是提供 Method 建立 Log 檔，Log 檔依照系統功能結構不 同可分為紀錄 MPI Server 運作資料的 MPIServer.log，包含各個 Class 與 Method 被 執行時的紀錄、連線建立與錯誤訊息的紀錄等；紀錄 User 連線資料的 MPIUser.log，

包含使用者帳號、提交的需求為何、需求的 Package 與連線佔用時間等；紀錄叢集 內 Node 電腦的狀態的 MPINodes.log，包含 MPI Manager 定時偵測每個 Node 的狀 態與系統資料；紀錄 Task 執行需求的 MPITask.log，包含每次 Task 被調用的資料及 Package、執行失敗任務紀錄與 Task 需求執行總時間等。Log 檔設定為 Rolling File 狀態，單一檔案最大為 512KB，當單一檔案超過限度便再產生另一個 log 檔，原檔 案檔名稱增加日期間格。其好處為當 MPI Manager 查詢 log 檔時可降低開啟檔案時 間，增加查詢效率。

圖 3.5 MPI Component 接收需求處理流程圖

Store Component 除包含程式系統外還泛指儲存資料路徑的資料夾與檔案，其功 能為儲存每一個使用者的使用紀錄，包含資料查詢紀錄、MPI 程式啟動紀錄與每個 MPI 任務執行結果紀錄。與 Log System 不同在於儲存的格式、型態與詳細的程度，

Store Component 為每一個使用者建立一資料夾，資料夾內還包含儲存執行任務紀錄 的 user_MPITask 、 儲 存 執 行 結 果 檔 案 的 user_MPIResult 與 提 交 所 有 要 求 的 user_History 資料夾。依照日期為每次 MPI 程式執行任務在 user_MPITask 建立不同 的紀錄檔，紀錄檔內在包含當次紀錄產生於 user_MPIResult 資料夾內的執行結果檔，

是一對多關係，如圖 3.6，執行結果檔內存放的是 MPI 程式執行完成後回傳的 Package 內 Data 欄位資料轉換為 byte 的文字儲存，而紀錄檔存放的為 JASON 轉換 為文字儲存，並以換行符代表每一筆數。為何不使用資料庫儲存，因希望本系統是 一輕量級結構，故預設使用此檔案儲存型態，系統也提供轉為資料庫儲存的設定，

引用本系統的開發者可自行調整設定啟用資料庫儲存。

圖 3.6 執行結果檔案儲存結構對應關係