從Oracle 10g探索資料庫網格(2)靈活運用IT投資，即時支援關鍵業務

杜奕鋒／艾群科技技術顧問，崑山科技大學業界講師。

資料庫是企業儲存資料的地方，當資料庫停止服務的時候，資料庫內所儲存的資料即無法正常的被讀取或儲存，輕則造成存取資料庫的應用程式無法正常的作業，重則導致企業的營運停擺。這樣的情況，影響的層面亦可能波及供應鏈上下游的整合系統，進而間接造成整體作業的延遲。

因此在網格的環境中，我們除了要考慮硬體資源轉換的便利性，更應該考慮服務停擺時間的長短（How much down time?）與次數（How many down times?），如何在沒有停擺的情況下，順利且即時地增減資料庫硬體資源，在不影響既有提供服務的系統的情況下，將硬體從負載較輕的地方，即時轉換到負載較重的地方，就是我們所應該考慮的重點。

早期資料庫利用叢集縮短服務停擺的時間
建置資料庫最基本的規畫上，會採用單一的Instance讀取一個實體的資料庫，但是這樣的做法，在主機無法提供服務時，主機上的Instance也無法正常的運作；此時即使儲存媒體（Storage）內的資料庫檔案（Data Files）是完好無缺的，仍然無法提供服務。

為了解決上述的問題，有些企業採用叢集（Cluster）解決方案，在原有的架構中，多配置一臺待命的主機，當運作中Instance無法提供服務時，自動將待命的主機轉換成運作中的主機，以縮短服務停擺的時間。

叢集除了協助兩臺主機溝通彼此的現況外，還要負責管理以及分配共用資源的使用權，例如理論上每一個時間點，只能有一臺主機可以對共用的儲存媒體進行資料的讀取。為了保障兩臺主機的Cluster Node 1及Cluster Node 2可以即時溝通，一般會以1GB的網路卡來對接，而負責兩臺主機之間溝通的網路連線，我們則稱為Heartbeat。

在網格的環境下，使用功能較為強大的叢集系統，利用複雜設定，的確可以達到某種程度的硬體資源共享，例如多臺資料庫系統共用一臺效能較為強大的主機，做為待命中的資料庫，當某個資料庫系統負載過重時，即時將資料庫系統轉移到這一臺效能較為強大的主機。

由於並不是所有的資料庫系統都是隨時處於極度忙碌的狀態，所以理論上在完善的規畫下，是可以做到硬體資源共享。但這樣子的做法，仍然有幾個缺點：首先，這樣子做法不能避免「Down Time」的產生，每次的轉移都是一次的「Down Time」，對於7×24的資料庫系統而言，這樣做法不被企業接受。

其次，不論如何精細的規畫，在整個IT環境中，至少還是會有一臺主機是處於待命的狀況，待命的主機即是硬體成本的浪費。這樣的做法不夠彈性，也不是真正利用IT環境中剩餘的硬體資源，需要多準備一臺效能強大的主機。況且不論怎麼切換，每個獨立的資料庫系統，都還是只有一臺主機在提供服務，並不符合網格「分散」負載的真義。

RAC提供強大的資料庫服務群組
為了讓多臺的資料庫主機可以針對一個資料庫同時提供服務，以符合網格「匯集協調與分享許多小型伺服器資源，達到大型伺服器的能力」的真諦，Oracle的RAC技術以叢集為基礎，讓多臺資料庫主機可以同時提供服務。如圖一所示，系統管理者可以集合企業內所有閒置的電腦，成為一個強大的資料庫系統服務群組，針對同一個資料庫提供服務。

不過，這個時候Heartbeat所扮演的角色，就不只單純主機之間叢集的溝通，所有主機上的叢集檔案系統（Cluster File System）及Instance內Dirty Block（資料有被異動過的Block）的同步也需要靠Heartbeat達成。

舉例來說，在月初及月中的時候，是企業業務敲單的高峰，因此訂單系統資料庫的負載量在這段時間會升高；到了月底，由於要進行會計過帳，因此會計系統資料庫負載量提高。

如果是跨國性的企業，兩個資料庫系統都必須7×24小時提供各國的分公司服務，那麼並不允許任何停機的發生。在經過數據化的評估後，我們發現：每個月的月初及月中，訂單系統資料庫的負載量，大約是會計系統的3/2倍；在月底就會反過來，會計系統資料庫的負載量，是訂單系統的3/2倍。

因此我們就可以依圖二的方式，規畫企業的資料庫。為了增加主機在使用上的彈性，也為了減少大型主機硬體成本的支出，所以分別針對訂單資料庫系統及會計資料庫系統，規畫了3臺及2臺主機，以因應月初與月中訂單資料庫的負載需求。

到了月底，面對會計資料庫系統負載量的爆增，系統管理者可以在不影響其它訂單資料庫系統主機服務的情況下，如圖三所示，先將Host 3主機內的資料庫Instance服務停止（Shutdown），並從Storage A卸載（Umount），再掛載（Mount）到Storage B，然後調整系統參數將會計資料庫系統的Instance在Hosts3主機啟動（Startup），如此Host 3主機的硬體資源即轉移到會計資料庫系統。

整個轉移的過程，會計資料庫系統不需要任何停機動作。理論上，終端的使用者也不會有任何的感覺（上述的轉移動作看起來雖然很繁瑣，不過在預先設定好的情況下，轉移的過程是可以很「即時」）。

系統平順轉移，有助閒置資源的運用
利用RAC及叢集的技術，資料庫主機即可Non-Down-Time並平順地轉移，利用這樣的做法，我們可以把所有的主機視為企業運算能力的「Pool」，終端的使用者其實並不知道他所執行的運算或命令被分散到幾臺主機執行，也更不會知道整個資料庫系統中，到底被配置了多少主機資源。

而管理者只需隨時監控（或者利用Grid control由系統自動監控）並動態地調整資料庫系統主機的配置數量，便可以不斷地重複利用企業中閒置的資源，以達到網格的真義。

從Oracle 10g探索資料庫網格運算(1)你Grid了嗎？
圖一：RAC技術以叢集為基礎，讓多臺資料庫主機可以同時提供服務。管理者可集合所有閒置的電腦，成為一個強大的資料庫系統服務群組，針對同一個資料庫提供服務。
圖二：一個跨國性的企業，經過數據化的評估後，發現在月初及月中時，訂單系統資料庫的負載量，大約是會計系統的3/2倍。到了月底，會計系統資料庫的負載量是訂單系統的3/2倍。因此，在網格的架構下，針對訂單及會計資料庫系統，分別規畫3臺及2臺主機，以因應月初與月中的負載需求。
圖三：到了月底，面對會計資料庫系統負載的爆增，於網格環境中，可在不影響訂單資料庫系統主機服務（No Down Time）的情況下，平順地將Host 3主機的硬體資源，轉移到會計資料庫系統。轉移的過程，不需要任何的停機動作，終端的使用者也不會有任何的感覺。