SRB與Data Grid

啥是Data Grid，啥又是SRB？ 這個問題其實也在我的心中困擾很久，由於我自己差不多到了這個階段，該是時候弄清楚並且真正提出解決問題的方案了。有一個前提必須提醒大家瞭解一個想法，Grid這件東西，我個人認為比起研究或是虛幻的夢想或者要解決100％的問題，實際地解決60～80％的人認為的問題，就能夠有貢獻了。而過去的經驗裡，很多事情都讓我體認到，眾多的計畫裡，提出眾多的想法，僅只能夠被歸類在「研究」，就像我聽許多老師說，「這就是做研究嘛」一樣。實際上一個東西是不是能夠被拿來做量產，終究還是該關心的問題。這並不是否定各位前輩們的辛苦研究精神，在不可能裡尋找可能是很累人的。只是對我個人而言，我希望經研究作為是一個過程，而不是做了三四年都還在研究階段。 很可惜的是，在我這幾年參與的計畫裡，「研究」還是佔了最主要的目的，而並不是「使用」。這是讓我深感SRB就是一個這樣研究型的middleware，許多的設計是在告訴大家「可能」，但並不是為了要拿來使用而設計。卻實在看過一些文獻後，對於SRB在Machanism Abstraction上的貢獻我覺得相當佩服，對於眾多的儲存媒體，要能夠囊括不是一件簡單的事。但仔細思考，究竟Data Grid希望為大家解決啥問題，會發現路更是長遠。光是metadata abstraction或是machanism abstarction，也不見得能夠解決幾個重要的問題。 以下我透過一些問題來帶入Data Grid的需要：

問題

為啥大家需要分散式的儲存？

我個人覺得這是因為硬碟真的太多，看看這個新聞吧

http://www.weblink.com.tw/main/action/getNews.do?did=200611000105&action=getNews

PMR大家都知道，更何況這還是2006年的新聞。一旦東西多了，整合地使用便是一種趨勢。 同樣的問題也發生在網路傳輸上，大家的網路變快了，所以不再是依賴高效能伺服器，而能夠整合大家的頻寬也是最好。這個部分，主要是透過P2P技術來達成。我想應用大家閒置的CPU，無用的硬碟空間，閒置的網路，不管在何時一直都是重要的焦點。

為啥大家需要「應用領域中介資料」(Application Metadata)？

現在各種領域都有專門的人才，這個造成兩件決定性的事，一個是這些人通常都不可能用通用的領域知識互相溝通，二是既然不能溝通，更別說有什麼可能共通的「協定」。因此，以往很多人志再開發一些能夠通用的協定，多半是不符合領域需求。當然另一點我所知，背後的許多商業競爭也是問題。沒有協定，無法共通，對使用者並不見得是最好的。但反過來說，如果能夠輕易地定義自己的領域資料，或是領域語言(DSL, Domain Specific Language)，加上這個DSL如果很簡單地可以轉換為XML，不管是誰都能夠有些創意能夠開拓自己的方向，並且也能夠想要交換資料的時候就交換。 但Data Grid必須做一件事情，將這些不同領域的數位中介資料都要能夠讀出，並建立索引。

為啥會產生大量資料？

由於探測的技術越來越進步，加上電腦硬體的等級在這10幾年間成長幅度太大。與其用一兩台電腦算上百萬年，不如螞蟻雄兵地用大家的電腦。Computing Grid就是要進行這樣的運算，而Data Grid就是要存著這些運算時進出的資料。

為了這些理由，我相信很需要所謂Data Grid技術的存在。

現在的SRB

接著我就SRB的操作經驗讓大家瞭解一些情況。以下會透過我放在google docs的投影片來說明。



Neutrality指的是「中立」，意思是說不能夠決定性地使用任何一種特定的方式或技術來完成特定的功能。而在程式實做上，通常會給予許多的Interface(介面)來完成這個目標。但在設計上，一個系統是否能夠真正達到這樣的彈性，不僅要考慮這些Programming Interface，包括通訊協定，甚至使用者介面的設計，都得考慮進去，有些狀況得為了效率捨棄彈性，而有些時候反之亦然。我相信這是prototype與production軟體之間使用性的差異。

Mechanism

建置與部署

先討論的是SRB提出的Federation觀念(投影片14~20頁)，圖片展示各個獨立的SRB Server，如何互動，然後再將檔案傳輸給使用者。而能讓SRB運作的最基本元素，在投影片21頁，包括Client，SRB Server(Storage Node)，MCAT Server(SRB Server+MCAT DB)。意思是說，如果管理者要安裝一套SRB系統，至少必須有一個MCAT資料庫與及一個連到此資料庫的SRB Server。此外可以的話，最好要有另一個SRB Server並掛上一個儲存裝置。因為MCAT本身也具有任何SRB Server的功能，以及單一簽入(Single Sign On)，當你連到任何一台SRB Server的時候，也就表示登入到整個SRB系統。由於SRB的單一簽入的功能，是採用委派(Delegation)的方法，在通過認證後，無論任何使用者進行什麼動作，皆會委派給Proxy User(或稱做Ticket User)。目前這個Proxy User，可以是任何一個你所建立的SysAdmin帳號。

這個部分也影響到其安裝與設定，當你建置一個SRB系統，大概會是以下動作：

1. 在MCAT Server機器上，安裝資料庫系統。可以是DB2,Oracle,PostgreSQL,MySQL


2. 將SRB的MCAT功能啟用並編譯(如果你要啟用GSI也是必須這個時候就決定)。


3. 將SQL指令匯入至資料庫系統。


4. 使用ingest系列指令新建立Zone及SysAdmin(在那之前，你必須要用「內建帳號」加上「環境變數」方法登入)


5. 確認啟動SRB的帳號(假設是srb)可以透過ODBC連到資料庫系統，並且編輯MdasConfig，輸入資料庫連線參數。


6. 在srb這個帳號的家目錄(~srb)下新增.srb目錄，並且編輯.MdavEnv及.MdasAuth檔案，將剛剛建立的SysAdmin帳號(就是Proxy User)連線參數填入。


7. 啟動並確認data/log/下的記錄檔內容是否正確，有錯誤的話就排除

而其他的SRB Server，在編譯的時候不用啟用MCAT，也不用做第4，5步。但在第6步後，要編輯mcatHost設定檔，將內容填入MCAT Server的hostname。請注意，在你建置的同時，DNS或IP等網路設定都要先確認好，一旦Domain Name對應錯誤，導致連線失敗，可能會很難發現錯誤並除錯。

詳情請參考

http://kiwi.csie.chu.edu.tw/blog/archives/122

如果只是單純學術研究用，部署(Deployment) 不是一個最優先的考量。可是對於實際運作情況，對管理員而言多餘冗長的安裝或管理動作，是會影響部署進度的。我認為Globus在這一點自從3版之後就有很大的改進，可是SRB在這一點卻相當地糟糕。儘管SRB有附上一個輔助Oracle的自動安裝script，但實際上對於各種情況不見得真正管用。

此外，對於一個必須要安裝Database才能運作的MCAT Server，如果要大量部署成特定的架構(M/S或Hierachical)就相當的困難，這個問題也違反了以下要討論的Metadata機制中立特性。

管理

參考投影片第22頁，當你登入到一個SRB系統的時候，我們會稱做你登入到一個SRB Zone。Zone為SRB最上層的管理單位，形同於一個組織或是一個計畫。而他的下一層是Domain，可以看做一個部門或是一個子單位。 最後則是基本的使用者與群組。就現階段而言，這些管理單位的階層結構與Metadata的階層結構是毫無關連的。換句話說，如果一個Zone有過多的Metadata，往往需要視情況將這些Metadata分散給下層管理單位(就如同DNS一樣而構成階層式的資料結構)，但SRB無法簡單地做到這一點。

要管理所有的Zone,Domain,Group,Account，必須透過指令及java GUI管理工具來進行，這個部分SRB提供了還算不錯的使用度。不過這個部分要注意到，管理並非是單純的CRUD，一旦GUI只是按照指令來設計，便失去GUI的意義。指令介面比較適合做精細的單位動作，例如移動一些檔案，修改某個檔案的Metadata。但使用GUI的目的，有些時候是得大量而快速地處理這些東西，否則就不需要GUI了。

儲存

SRB對於儲存機制中立的作法相當地令人稱讚。傳統性的儲存設備包括Windows/Linux File System，Tape，Hierarchical Storage等都可以相容，而非傳統的儲存媒體如Database，FTP/HTTP File System等，也都盡力地支援了。 但這些支援的背後，並未注意到幾個問題。

• 傳統和非傳統儲存媒體間，還是存在著是否可能斷線這樣決定性的不同。在LAN上面或許可以，可是一旦網路不是絕對穩定，或是在WAN上面，那肯定會因為斷線造成檔案的操作緩慢或失敗。


• 非傳統儲存由於不見得都是為了進行IO動作而設計，因此一旦速 度上有差異，就需要有效的快取設計。SRB本身沒有任何的快取設計，因此對於任何媒體的緩慢皆會造成整體的影響。


• SRB Server本身持有許多重要的角色，各儲存媒體間的資料移動，必須靠著SRB的Metadata與傳輸速度來達到整體的效能。Metadata的問題在下段討論，但傳輸方面，SRB只做到了點對點的Multi-Section Transfer(在SRB裡為Server/Client Initiated Parallel Transfer)。實際上在分散式的環境，多對一的Parallel Taansfer是必須的，而實際上這也才是一般所認為的平行傳輸。

一個儲存的主機被定義為Location，而儲存媒體被定義為Resource，任何的Physical Resource必須建立在一個Location上。一個SRB系統裡至少要一個Physical Resource，才能明確地傳輸檔案。管理員也可以建立Logical Resource，這個表示多個Physical Resource的集合，當檔案實際進行儲存時，SRB會自動從其中選擇一個，而不需要使用者顧慮要存到哪。實際上挑選的Policy不明，而官方對於這個作法提出的解釋，是希望能夠將resource群組化。要進行儲存的管理，SRB提供了Java,Windows,Web三種管理工具。

Replica管理

Replica(覆寫)管理在DataGrid上一直是一個重要的議題，Replica的意思形同於Copy，因此也產生了管理及同步問題。SRB確實有提供Replicate的功能，也可以透過一個指令在不同的replica之間同步。不過並未提供管理的功能，也因此一般情況下管理者必須自行執行Sreplicate來操作。如果要達到自動化，管理者必須自行撰寫replica meneger，或是設計一些預設的policy。

Metadata

SRB在Metadata上的努力，基本上算是可擴充的這個方向。資料庫的設計，除了一些模糊索引的機制，讓人不要輕易的破解之外，多半是在處理Metadata及ACL。達成的就是任何一個檔案都可以任意修改其Metadata。在Federation的第三個動作(投影片15,16)，其實可以看見Metadata的處理是第一個最重要的動作。實際上Client程式或是使用者，在瀏覽目錄，看檔案名稱，狀態，可能絕大多數的動作都是在讀取Metadata。但問題在於：

1. SRB並未有任何的Metadata快取，就現階段也並無階層化的架構來分散式地處理Maeatada。


2. 除了所支援的DBMS以外，並無法改變任何Metadata儲存的方式。也就是他的Metadata中立也不是完整的，而是綁在資料庫上，其傳輸協定也綁在自行撰寫的binary protocol上。目前任何一個Metadata動作，都必須透過SRB Client Query <->Binary Data(因為要透過Socket)<-> SRB Server(MDAS) <-> DBMS來完成。一旦使用者想要儲存在SRB尚未支援的metadata儲存方法上(如xml)，就顯得無法擴充。


3. 此外儘管SRB支援多種不同的Metadata Service(MCAT Server)的串接方式，例如 P2P或Master/Slave。其難以安裝的MCAT，無法造成使用者能夠實做多種架構，而來提升容錯度。

對於一個以 Metadata為核心，而需要資料庫的系統而言，有幾點值得討論：

• 既然任何節點查詢Metadata並不是透過網路來直接對資料庫查詢，那是否需要網路型的資料庫系統？


• 既然建立索引及搜尋為最常見工作，是否該採用已經最佳化建立索引並搜尋的資料庫系統？


• 既然Metadata大多數時候是直接讀取，是否該將這些Metadata快取成最後要輸出的格式，而減少資料庫讀取及跑程式轉換格式的時間？

Security

SRB支援三種安全機制，一個是內建最簡單的加密，稱做encrypt1。另一個是GSI，這個使用方式提供很高度的整合性。如果安裝好Globus，並且已經建立好Server,User憑證等相關安全性資料，那SRB就可以直接引入GSI函式庫來編譯，最後就能夠不用設定太多東西，啟用了憑證proxy後就可以連線。另一點是在這種情況下，也能夠透過GSI進行cross zone的資料通訊。

儘管支援了GSI，但是卻只支援Globus 3.0的版本，而與現在Globus推行的4.0是很難搭配的。

Policy

很可惜的是，SRB對於Policy的貢獻並不多，一直到下一代的iRODS才能夠提供給使用者進行一些scripting方式的修改。而我們並不清楚提供這樣子的功能對SRB本身會是多大的系統負擔。

要構成Policy中立，不單是提供良好的API給使用者能夠自行撰寫並override原本的策略，預設的策略也是相當必要。

設計考量

這些問題加上一些經典的文獻，我歸納出幾點重要性：

Mechanism

資料的存在性的控制，必須是基本的動作。

也就是說如果一個data grid middleware如果需要人工去探知資料的內容還在不在，那後面的所有動作都無法完成。Data grid必須克服這個問題，告訴使用者某個檔案的內容是否還在網路上，或是如果不在，便應該要通知使用者該如何處理，或是進行不阻礙使用者觀感的例外處理。另一點重要的是，Data grid必須能夠主動地維持某資料的內容在網路上，直到使用者確認刪除。不是透過使用者的使用態度來配合，而是在軟硬體架構上當初就該如此搭配設計。台灣的學術網路環境，並不見得各學校都是很穩定，維護人員也不見得有一定的素質來想辦法讓機器7x24不斷線。因此某一個資料的實體，自己該去哪，必須讓「它自己」來思考。同樣的這個資料的metadata也應該是如此。

儲存媒體的考量。

由於Storage Abstraction的關係，必須是全天下的都要可以。但一個計畫不可能把時間都花在這裡，一定是最常見的File System如NTFS及EXT2/3，也就是Windows及Linux這兩的作業系統必須完全相容。但至於是某要支援非傳統的儲存媒體，如光碟片，或 是資料庫，則必須在儲存媒體上也有Metadata，才能讓資料在思考要去哪的時候能夠決定。

Metadata

索引也必須是分散的。

Web本身是一個龐大的分散式資料庫，而Google就是其索引，各位也知道拜孤狗大神有要技巧，才能心想事成，Data Grid上可不能這樣。Data Grid並沒有那樣龐大的範圍，也沒有複雜的網頁或語意要解析，對於metadata而言，大多都是以key-value構成的配對。Metadata的索引，Metadata Catalog(MCAT)，除了要是階層式的，當然也應該是分散式的。這個方面，DNS的查詢架構就足以解決這個問題，剩下的就是如何利用P2P建立一 個可以尋找哪裡有MCAT的網路。

在這裡要提及P2P Grid的基本觀念。以往的作法，可能是把Grid協定改成P2P化，或是反過來修改P2P的服務提供方式，讓他看起來有點像Grid。可是在這裡的P2P DataGrid只會將P2P應用在建立各種類型的索引網路上，包括MCAT網路及Resource網路。當然P2P的通訊將會是這些網路節點的基本功能。

Metadata及其資料的輸出入並需要可以套用任何可能的Domain Specific Model。

不管平台再怎樣好，使用者最後的目的還是在使用這個平台把資料從任意地點輸入，然後從任意地點搜尋並輸出。前面提到的存在性與分散式索引，已 經解決任意地點的問題。可是輸出入還是大問題，這個部分我也再加緊尋找各種不同的想法中。目前最原始的方向，還是對開發人員提供類似SQL的語法，對於開發人員來說，Data Grid應該要是像資料庫一樣可以CRUD。這個部分，透過Ruby on rails的activerecord pattern，已經給了我很好的參考。

Security

資料的權限受到控管，動作也該被稽核。通常資料的擁有人(owner)與資料的實體存放位置絕對不會相同，因此也只有當初加密這個資料的人能解 開，或是被這個擁有人的上層管理單位委託解開才行。所有資料的寫入或讀取動作應該被紀錄，而相關的人員也該被通知，此為稽核。為了防止過度的運算資源浪費，也應該要提供其他的安全策略，而也應該要可以繼承。既然受到稽核，對於管理者而言，資料的分佈，狀態也應該要是隨時可以取得。此外，該與GSI整合到怎樣的程度，也是問題。

Lightweight

輕量化的設計。

由於上述這些考量，整體設計就勢必如一般的P2P軟體一樣是分散式的，而透過索引來達成實際的搜尋與整體資訊的取得。使用者的運算資源應該盡量地集中在提供所引這個部分，而不是跑程式來進行IO的轉換。

參考資料

http://www.ibm.com/developerworks/cn/grid/gr-srb/