http://www.ithome.com.tw/itadm/article.php?c=37768
從Oracle 10g探索資料庫網格運算(1)你Grid了嗎？
| 從Oracle 10g探索資料庫網格運算(1)你Grid了嗎？ |
| 文/ iThome (記者) 2006-06-20 |
| 由網格（Grid）的觀念出發，或許透過網路，我們可以輕易地將資料庫中的資料轉移到其他的主機中提供資料庫的服務。 |
| 杜奕鋒╱艾群科技技術顧問，崑山科技大學業界講師。 Oracle在2004年以後，對於新發表的產品都會加上一個「g」，而過去是加上i－Internet，例如：Database 8i/9i、Application Server 9i，最為明顯即是資料庫與應用伺服的版本命名，在版本10以後，都稱為10g，究竟「g」代表的是什麼呢？ 什麼是網格運算？ 1997年，美國加州柏克萊大學的天文實驗室發起了一項有趣的科學研究計畫：SETI（Search For Extraterrestrial Intelligence），想要分析天文望遠鏡所接收的無線電訊號，從中探索是否隱含外星生物的傳遞訊息。由於所收集的無線電訊號量十分龐大，必須同時 建置好幾臺超級電腦，才有能力分析所擷取到的微弱外太空訊號，然而柏克萊天文實驗室在當時，並沒有足夠的經費來投入這個計畫。於是他們想到了一個替代方 案，號召全世界的個人電腦使用者，參與這個計畫： 每個人只要在電腦中下載並安裝一個SETI@home的螢幕保護程式，當電腦處於閒置狀態的時候，SETI@home程式即伴隨著螢幕保護程式 執行而啟動，此時從柏克萊大學天文實驗室中的伺服器，即會透過網路傳送一些天文訊號資料至SETI@home的程式中，進行運算及分析，完成分析與運算 後，再由網路傳送回天文實驗室中的伺服器。 在資料分析的期間，如果個人電腦的使用者重新回到工作崗位上時，SETI@home程式即會隨著螢幕保護程式的停止而結束 ，並暫停目前的運算分析動作，一直到下次SETI@home再隨著螢幕保護程式被啟動才會再繼續分析。 這樣透過網路達到「分散運算需求到多臺主機」的做法，我們即稱為「網格運算（Grid Computing）」。柏克萊天文實驗室成功地號召了二百萬臺以上的電腦在使用者閒暇之餘，進行天文無線資訊的分析。由於分析的動作是在電腦閒置的時候 才進行，因此這樣的作法並不會造成任何使用上的不便。但就柏克萊天文實驗室而言，這二百萬臺的個人電腦整體所提供的總運算能力，可以媲美數臺超級電腦所達 成的運算能力。 Oracle的網格運算 「找出閒置的IT剩餘資源即時回收，並透過網路再利用於其他需要IT資源的地方，以增加IT運算資源的使用率，減少IT成本的支出」，這樣一個IT資源循環、再利用的做法就是「網格運算」吸引人的地方。 只要將閒置的系統資源及負載過重系統找出來，就可以解決這樣的問題嗎？其實問題的難度並不是在找到閒置的系統資源，而在於找到資源後，這些系統資 源如何平順、且即時地轉移透過網路轉移給其他負載過重的系統，轉移是否會造成服務停止的時間（Service Down Time）？停機多久？停機多少次？資源的轉移是否夠「即時」？（轉移越即時，越能夠面對突如其來的過重負載），而這樣的轉移是否會產生資料需要同步的問 題？  在Oracle 的觀念中，一個服務（Service）就是一個可轉移的基本單位，以OC4J（Oracle Application Server Containers for J2EE）的服務為例，OC4J的同步資料及Metadata可記錄在Oracle所規畫的儲存庫（Respository）中。儲存庫可分為檔案形態及 資料庫形態兩種：後者以Oracle資料庫來儲存OC4J的同步資料，前者則以減少硬體成本支出為考量，直接以檔案形式儲存資料在OC4J Server中。如 圖一所示，當使用中的OC4J負載過重時，系統管理者只需要直接將其他有剩餘資源的OC4J，註冊到這一組OC4J的儲存庫中，新的OC4J即可「即時」分散原本OC4J的負載，不會產生停機時間。 力求達到「No Down-Time」與即時轉移，即構成了整個網格環境是否成功的關鍵因素。不過其中最難處理的是資料庫資源的轉移，尤其資料庫的停機往往會迫使企業內部大部分IT服務中斷，甚至會造成企業運作的癱瘓。 由網格的觀念出發，或許透過網路，我們可以輕易地將資料庫中的資料轉移到其他的主機中提供資料庫的服務，但要考慮的問題，是這樣的轉移需要多少時間？對於 大型的資料庫而言，這更是一種挑戰。當資料轉移後，同步的時間差，是否對系統產生不良影響？或者能否直接讓提供資料庫服務的所有主機 （Instance），同時讀取一組資料庫檔案（Database Files）？ 以系統叢集實現網格運算 為了避免上述的問題，因此在網格的環境下，對於資料庫的持續維運，我們會建議採用RAC（Real Application Cluster）的技術。  如 圖二 所 示，讓兩臺不同伺服器上的資料庫Instance，實體上都是儲存並讀取儲存媒體中的同一個資料庫（單一組資料庫系統及資料檔案），以保障資料來源及資料 儲存的一致性；當系統使用新增、修改、或刪除等DML指令後，為了避免資料內容的不一致，資料庫系統還要提供主動彼此溝通協調的機制，讓所有的 Instance自動且主動即時地將自身所更改或新增的資料，通知其他的Instance，使不同的Instance緩衝記憶體中共同資料內容，維持一致 性。因為不同的Instance中，緩衝記憶體所暫儲的資料不一定相同，所以理論上資料庫系統只針對共同擁有的資料進行內容的同步。  當原本提供服務的資料庫負載過重的時候，如 圖三所示，系統管理者即可動態地再加入1臺資料庫主機（Host3）以解決負載過重的問題。 「Grid Control」不等於網格運算 Oracle有一個「Enterprise Manager 10g Grid Control」產品，是不是使用了產品，就可以完成Grid的建置呢？ 事實上，Grid Control 並不等同於Grid Computing， Grid Control是工具，可以協助管理者管理及監督所有Oracle產品的運作情況，找出閒置的IT剩餘資源，並即時地利用在其他需要IT資源的地方，但是 單單這項產品，是沒有辦法完成企業的網格建置。 |
圖一：在Grid的環境下，將OC4J伺服器轉移。
圖二：Oracle的RAC架構讓多臺不同伺服器的資料庫，存取單一資料庫檔案，以維持資料的一致性。
圖三：在RAC的架構下，當原有的資料庫負載過重時，即時再加入1臺資料庫主機（Host3），即可分散負荷。
--
萬歲！您的郵件已被捨棄。一封垃圾郵件也沒有！
--
萬歲！您的郵件已被捨棄。一封垃圾郵件也沒有！
沒有留言:
張貼留言