通訊、Cluster Peer、與資料儲存

HTTP 是一個非常完善設計的檔案通訊協定，而透過一些擴充如 WebDAV，使 得 HTTP 比 FTP 還要能夠有檔案的中介資料及實體資料傳輸的能力。儘管 HTTP 並 不是 Stateful，但我們依然能夠加上 Cookie 及 Session 來完成一些需要狀態的動作，

例如我們自行定義的通訊流程。此外 HTTP 很多核心的觀念都建立在其 Server 裡，

最有名的例子為 Apache HTTP Server，使得檔案的部分傳輸相當地簡單，因此平行 傳輸的問題只剩一半。另一個好處是，如果需要加密的傳輸，只需要把 URL 從 http 改為 https 即可。

在資料格式定址(Data Format Addressing)的方法上，近來也有一個針對 HTTP 通 訊及 Web 應用相當熱門的名詞稱做 REST。REST 原意為 Representational State Transfer，表示同樣的 URL(Resource)，利用 HTTP Accept Header，能夠做到讓 Server 傳回不同型態的資料。例如 http://www.someone.com/login，對於 HTML 要求，便傳 回人看得懂的網頁；而對於程式的 XML 要求，便傳回 XML 結果。我們將利用這種 特性，將一系列的 URL 設計為簡易的 Web API，使得整個程式框架更容易實做。所 以，我們就可以將 URL 視作整個網路內資料的定址及選擇通訊資料格式的方式。

對於 P2P 連線及平行傳輸，在前述的中介資料索引小節中，我們提到了整個 P2P 機制是透過 Chord 這個分散式雜湊表來完成。透過這機制，取得了任何資料的來源 清單後，便可以透過 HTTP 的資料分斷機制，進行平行化的傳輸。任何資料進行平 行傳輸後，會再次計算 checksum，確保資料傳輸沒有問題。

針對大量部署及管理的問題，管理者不僅要從虛擬檔案系統看整個資料格網內 的資料，也必頇隨時掌握實體機器的狀態。但以往管理者遇到的問題是，很難快速

9

地在資料格網中建立或刪除節點，加入新的硬碟，或是在任何機器有狀況的時候進 行處理，此外像是 CPU，記憶體，硬碟空間的監控都很重要。這個困難點是因為，

很多實體機器不見得都是該管理者有全部權限，或是可以立即進行操作，此外如果 一次要對 20 台進行硬碟的安裝可能就很困難。

為了解決這個問題，管理者必頇安裝 Cluster Peer(CP)元件。CP 實際上是一種為 了管理而存在的 Peer。而構成的 Cluster Overlay，除了擁有 MP 的所有功能以外，預 設會認定實體機器是在同一個或是鄰近網段下運作，藉此調整其快取機制，並更提 高輸出率，而不是容錯率。所有屬於 CP 的 SP，會被視作一個 Storage Pool，而不是 單獨的儲存節點。為了達到這個需求，我們也會建議管理者提升網路的等級，來加 快整體的運作時間。

安裝 CP，使用者可以透過 SSH(必頇提供機器 root 密碼)，或是事先安裝好 SP 軟體來達成半自動或全自動的部署。部署完後的 SP，將會自動地加入 CP。CP 除了 能夠當作這一群 SP 的 MP 以外，也能夠透過叢集指令對每個 SP 的硬碟進行管理。

圖四描繪上述 CP 提供自動部署機制。舉例來說，如果需要新增儲存節點，如同安裝 的時候一樣，提供 SSH 密碼，或是在新主機上安裝 SP，都能夠讓 CP 將其自動地納 入管理。

另外，叢集指令及叢集指令介面(Clustered Shell)是 CP 提供的特殊功能，允許管 理者執行一道指令便能夠在指定或是所有的節點上執行。在未安裝 SP 軟體的情況 下，預設會需要提供主機的 root 密碼，以透過 SSH 連線。叢集指令使得大量管理成 為可能，例如一次格式化所有主機的新硬碟，並將其掛載上指定目錄。這個需要管 理者事先規劃好使用同樣類型的 OS，來防止任何問題。這些節點也可以分做群組，

使得不同類型 OS 或主機都可以應用在同一個 CP 上。

10

Storage Pool 2 Storage Pool 1

Cluster Peer

Clustered Command Clustered Command

圖四 Cluster Peer 提供自動部署機制

將大量的 SP 視作為磁碟快取的作法，對提高資料格網效率與擴充性有很大幫 助。這正符合一些用到大量硬碟空間的計畫需求。

在資料儲存的策略方面，我們選擇的主流的 OS，其 Native IO API 作為預設儲 存實體檔案的驅動方式。也因此目前只支援 Linux 與 Windows。我們保留了可以方 便撰寫 Extension 的框架，期待更多使用者能夠參與開發。

透過前述定址的方式，任何在資料格網上的檔案將會照著邏輯位置(Logical Location)來服務，也就是在虛擬儲存空間上的位置。而其虛擬的儲存位置，僅會以 簡單的雜湊來區隔檔案，而儲存在使用者或是系統指定的目錄裡。雜湊的目的，只 需要確認一個目錄的檔案個數上限不會超過檔案系統所能承受的即可。

我們針對現行的檔案系統如 NTFS 及 EXT3，透過 Windows 或是 Unix 都會有的 原生 IO 指令來使用。並且設計儲存驅動的程式介面，讓任何人都可以透過撰寫外掛 的方式，來驅動自己所需要的儲存設備，如特殊的階層式檔案系統。此外，針對常 見的備份式儲存，如磁帶，以及可移除式儲存如 USB 碟與光碟，也都有支援。這些 非傳統的儲存介面帶來的挑戰是，利用檔案快取來讓使用者還是能夠存取到。也因 此後面會有提到利用 Cluster Peer(CP)及 SP 在近端網路建立大量磁碟快取(Disk Pool) 的作法，圖五所示。而另外一點令人關切的問題是，不同 Domain 的資料，或是不同 使用者擁有的資料，是不會能夠被其他人看見。

針對很多學術計畫所需要的大量硬碟空間，透過上述部署機制，減少很多不必 要的管理時間。然而，同性質的機器，除了能夠當作儲存，使用其 CPU 的資源也是 相當重要。舉例如果有個計畫的成果會產生大量的感測器資料，不僅容量大，而且

11

數量多，例如 30 萬個檔案。這 30 萬個檔案，如果要能夠擷取其中介資料，再利用 單台電腦匯入到資料庫裡建立索引，進行查詢，可以說是相當緩慢。儘管資料格網 附有中介資料匯入的方法，但只也只侷限在從一個用戶端進行匯入。

IOManager Native IO

Module

Disks

Tapes, CDROMs

RemovableIO Module

Disk Pools

Non-Conventional Storage Module

Network Filesystems, Databases

圖五 資料格網之異質性儲存整合介面

3.

我 們 針 對 此 建 立 了 大 量 中 介 資 料 處 理 的 機 制 ， 主 要 是 透 過 Google 提 出 的 MapReduce 資料平行處理框架。我們修改 MapReduce 架構，來套用在我們的資料格網 系統上。根據 MapReduce 架構，任何資料首先必頇平均地散佈在各個 SP 上，這個我 們 就 透 過 原 本 資 料 格 網 既 有 的 傳 輸 機 制 。 接 著 使 用 者 必 頇 根 據 程 式 介 面 撰 寫 Mapping，以及 Reducing 的程序，而與用戶端直接匯入的不同是，必頇自行撰寫 Reducing 的程式碼，而非由系統負責處理。而實際的 Mapping 及 Reducing 程序進行完 後，資料就會直接合併為 CP 所管理的中介資料，這樣的程序會持續進行直到中介資 料都合併至所有的 MP 為止。圖六顯示上述 MapReduce 資料平行處理框架。

在與 Globus GSI 整合的部份，使用 CP 的管理者，絕大多數都是因為計畫上需要 與 Globus 整合，或是透過 Globus 來整合儲存與運算。我們的資料格網系統，也必頇 相容於這個要求。但其實 Globus 的通訊，是透過 GSI (Globus Security Infrastructure)，

這個元件使得所有通訊都必頇透過 GSI SSL 加密。也因此任何的節點都要有主機憑 證，而要進行連接的使用者也要有使用者憑證。由於這種使用情境並不適合一般單純 想要使用儲存的使用者，所以我們將這個功能分離至 CP 中。

12

與 Globus 整合後，所有節點間的通訊都必頇經過 GSI SSL，免不了加重了 CPU 負擔，也因此上述 CP 與 SP 的硬體要求就相當重要。然而好處是，除了確保計畫資料 絕對可以儲存在透過憑證授權的機器，資料格網的資料也都可以透過原先 Globus 支援 的方式來傳送。例如在沒有 Globus 的情況下，我們是使用未加密的 HTTP 傳送檔案，

而使用了 Globus 之後，任何檔案傳送就變成使用 GridFTP。而叢集指令也會使用 globus-job-run 的方式處理。對於原本在 Globus 上的應用方式，例如執行平行程式之 前，原本都是使用 GridFTP 每個節點來散佈，在我們的設計架構下，也可以呼叫資料 格網 API，或是叢集指令來進行快速的散佈。

M ap p in g R ed u ci n g

Grouped SP Metadata

CP Metadata 圖六 MapReduce 資料平行處理框架

對於資料格網管理者而言，資料格網往往都具備一個重要的元件稱為虛擬檔案 系統，有了這個元件，任何使用者可以以管理單台電腦同樣的觀念來管理資料格網 理的檔案。以往針對虛擬檔案系統的管理方式，一直都是相當繁重而浪費時間的，

絕大部分都是因為浪費在使用者介面與系統通訊來來回回地。SRB 在 3 版後，不管 是 Web 介面，還是視窗介面，都實做出來了，但卻還是很難讓使用者感受到資料 格網是可以管理大量檔案的。問題也是在於操作順暢度，以及系統針對中介資料如 何處理。透過前述的中介資料快取，解決了很多順暢度的問題，因此要達成如檔案 總管般拖拉檔案相當地簡單。基本的檔案管理動作，如複製，更名，移動，會直接 對應到資料格網的 API。而比較複雜的動作，像是讓檔案在節點間移動，我們也會 採取較視覺化的作法。而另一些基本元素的管理，如使用者，也是將其模擬成如同 檔案般的觀念，使得管理者可以以同樣的觀念處理所有的工作。

13

對於資料格網開發者而言，對於資料格網上的資料，開發者必頇透過 API，對 檔案進行很有效率的 CRUD(新增，取回，修改，刪除)。也因此在後面提到的開發 框架中，我們會說明使用 ActiveRecord 這個資料存取設計樣式，來設計我們的資料 格網 API。ActiveRecord 這個設計樣式，主要是將任何的永久式資料儲存(如資料庫，

或是 Directory Service)，裡面的單一資料，利用物件導向的觀念，將其欄位對應成 程式裡物件的屬性。套用在資料格網上，例如查詢的時候，就可以取回其中介資料，

以及檔案存取點的 URL。同樣地，當任何屬性修改的時候，透過呼叫儲存成員函式，

就可以直接存回 MP。

對於一般使用者而言，由於 P2P 資料格網的特性，使得透過資料格網來共享檔 案成為可能。我們也設計了使用者專用的 P2P 共享介面，並讓使用者在操作資料格 網的時候，也可以輕鬆地決定是否要公開分享檔案。在 P2P 社群中，共享的檔案可 以輕易地利用中介資料加上標籤，並且透過前述中介資料的索引功能，加強搜尋的 準確性。此外，這個虛擬社群也間接地解決了假檔的問題，在 P2P 領域的許多論文 都有不同的作法。而我們是利用資料格網的中介資料，讓檔案的使用度，使用者對 於共享檔案的熱門度，直接反映在中介資料上。並利用社交網路(Social Network)的 觀念，讓使用者在系統提供的虛擬社群上共享檔案，使得假檔率降到最低。

從應用程式的觀點，以往在資料格網上，任何應用程式如果要存取資料，都必 頇重新利用用戶端函式庫來撰寫，而通常存取資料這工作，在應用程式上都是相當 底層，重新撰寫通常會有一定難度。為了使得任何可能的應用程式可以透過既有的 單一介面存取到虛擬檔案系統裡的資料，我們也提供了虛擬檔案系統對作業系統的 存取介面。這個作法目前儘管只能夠運行在 Linux 及 Windows，卻可以讓多數舊有 的應用程式也可以享受資料格網的好處。這樣的應用程式如 FTP Server，或 HTTP Server 都可以在資料格網上使用。

4.

對資料格網的使用者管理來說，所需要的是不同階層的權限來進行管理。以往 的資料格網遇到的問題是，針對不同情境所需要的 ACL 條件，例如群組能夠做什 麼，或是特定的管理階層能夠做什麼，無法提供預設的策略，也無法讓管理員能夠 輕易地修改為自己管理上的需要。

在權限控管清單這樣的機制中(ACL Policy)，如果要做到越精確，系統負載就會