1. 程式人生 > >ORACLE RAC ONE NODE技術介紹

ORACLE RAC ONE NODE技術介紹

1.  概述

       時代總是在進步的,這總是得益於新的生產技術的出現,我們總是有太多的問題需要解決,對於技術人員來說,當一項新的技術的出現並解決了困擾已久的問題的時候,這無疑是最激動人心的,它不僅把我們從落後的生產過程中解放出來,更重要的是,它能使生產力更大化、成本更小化。如更好的資源利用和更少的停機時間。本文主要談談oracle rac中的一項新技術革新,即oracle rac one node。在分析過程中,會引用一些舊有技術做對比,如VM,FAILOVER和例項遷移等

Oracle Real ApplicationClusters One Node 是 Oracle Database 11g 第 2 版企業版的一個新選件。它對伺服器虛擬化的諸多優勢加以改進,並將這些優勢擴充套件到物理伺服器環境中執行的資料庫。它允許在叢集中的資料庫以單例項的方式執行在一個節點上。對於計劃和非機劃的停機能提供更有效地保護。我們總是希望業務能夠持續的執行、系統能得到更可能的保護、升級和遷移的代價最小化,而新技術是否需要被採用,需要具體分析它的技術革新性。

2.  分析

傳統的Oracle RAC被用於多伺服器架構體系,此體系中,RAC的許多分開的例項分置於不同的伺服器。這就防止了伺服器非計劃故障,因為透明應用程式故障切換(TAF)會重定向到另一個伺服器。但是在Oracle 11g第二版中有一個新的被稱為“RAC One Node”的特性,它主張將RAC的多個例項執行在一臺群集的伺服器上。它有一個快速的“例項重定向(instance relocation)”的特性,來防止突發的伺服器故障。

Oracle RAC One Node提供的是一種cold failover 方案。假設在2個節點的rac one node上,例項只在其中一個節點執行,另一個節點就作為cold standby存在。 如果例項faild,那麼RAC ONE Node 檢測到後,首先會在相同的節點嘗試restart。如果當前節點出現問題,或者例項不能restart,那麼instance 會被relocated 到standby 的節點上去。Relocated的過程是自動實現的,不需要downtime 和人工的介入。Relocated 使用的是Omotion,使用Omotion 可以對例項進行migration 和 relocation。

簡單的來說,RAC ONE NODE 也是基於多節點來實現,多節點之間也是需要安裝clusterware,多節點形成一個single cluster,而例項只在其中一個節點上執行。當出現問題時通過Omotion技術將例項轉移到single cluster中的其他節點上行。當然也可以手工使用omotion來進行轉移,從而實現零停機的升級和打補丁等操作。

RAC One Node是11.2的新特性, 是RAC資料庫中的一個例項執行在GRID叢集中,並且可以實現failover。

這個功能有些類似於我們以前俗稱的"HA資料庫" <HA - high availability>, "HA資料庫"是利用其他廠商的叢集軟體來管理Oracle單機資料庫,實現資料庫的高可用。而RAC One Node是通過ORACLE 叢集軟體(GRID)來管理資料庫,實現資料庫可以在叢集中節點上切換(failover/relocate),達到資料庫高可用的特點。RAC One Node是完全由Oracle提供的一整套高可用的解決方案。

在11.2之前,為了實現資料庫的高可用<俗稱"HA資料庫">,通常的做法是將單機資料庫部署在其他廠商叢集環境中(比如 HP MC/SG, IBM HACMP 等)管理,來實現資料庫的高可用。即單機資料庫執行在主節點上,當主節點需要維護或者異常中斷的情況下,通過廠商叢集軟體將服務IP資源組和資料檔案資源組切換(failover)到備節點,將資料庫在備用節點重新啟動。這個過程我們一般稱為cold failover,因為資料庫在切換的過程中是先shutdown再open。

這裡一個RAC ONE NODE的框架圖:

從圖上我們看出,rac one node,有3個物理主機,Server A、ServerB、Server C,這3個物理主機組成一個single cluster,在3個主機上,可以有5個不同的single instance的database,DB1和DB2host在Server A上,DB3 host在Server B上,DB 4和DB 5host在Server C上。各個資料庫使用共享儲存。

RAC,全稱realapplication clusters,譯為“實時應用叢集”,是Oracle新版資料庫中採用的一項新技術,是高可用性的一種,也是Oracle資料庫支援網格計算環境的核心技術。

RAC提供的優缺點:

優點:

Oracle RAC主要支援Oracle9i、10g、11g版本,可以支援24 x 7 有效的資料庫應用系統,在低成本伺服器上構建高可用性資料庫系統,並且自由部署應用,無需修改程式碼。在OracleRAC環境下,Oracle整合提供了叢集軟體和儲存管理軟體,為使用者降低了應用成本。當應用規模需要擴充時,使用者可以按需擴充套件系統,以保證系統的效能。

節點負載均衡;

提供高可用:故障容錯和無縫切換功能,將硬體和軟體錯誤造成的影響最小化;

通過並行執行技術提高事務響應時間----通常用於資料分析系統;

通過橫向擴充套件提高每秒交易數和連線數----通常對於聯機事務系統;

節約硬體成本,可以用多個廉價PC伺服器代替昂貴的小型機或大型機,同時節約相應維護成本;

可擴充套件性好,可以方便新增刪除節點,擴充套件硬體資源。

缺點:

相對單機,管理更復雜,要求更高;

在系統規劃設計較差時效能甚至不如單節點;

可能會增加軟體成本(如果使用高配置的pc伺服器,Oracle一般按照CPU個數收費)。

在Oracle9i之前,RAC的名稱是OPS (Oracle parallel Server)。RAC 與 OPS 之間的一個較大區別是,RAC採用了Cache Fusion(快取記憶體合併)技術。在 OPS 中,節點間的資料請求需要先將資料寫入磁碟,然後發出請求的節點才可以讀取該資料。使用Cache fusion時,RAC的各個節點的資料緩衝區通過高速、低延遲的內部網路進行資料塊的傳輸。

RAC中的特點

在一個應用環境當中,所有的伺服器使用和管理同一個資料庫,目的是為了分散每一臺伺服器的工作量,硬體上至少需要兩臺以上的伺服器,而且還需要一個共享儲存裝置。同時還需要兩類軟體,一個是叢集軟體,另外一個就是Oracle資料庫中的RAC元件。同時所有伺服器上的OS都應該是同一類OS,根據負載均衡的配置策略,當一個客戶端傳送請求到某一臺服務的listener後,這臺伺服器根據我們的負載均衡策略,會把請求傳送給本機的RAC元件處理也可能會發送給另外一臺伺服器的RAC元件處理,處理完請求後,RAC會通過叢集軟體來訪問我們的共享儲存裝置.

邏輯結構上看,每一個參加叢集的節點有一個獨立的instance(資料庫例項),這些instance訪問同一個資料庫。節點之間通過叢集軟體的通訊層(communicationlayer)來進行通訊。同時為了減少IO的消耗,存在了一個全域性快取服務,因此每一個數據庫的instance,都保留了一份相同的資料庫cacheI

每一個節點的instance都有自己的SGA

每一個節點的instance都有自己的background process

每一個節點的instance都有自己的redo logs

每一個節點的instance都有自己的undo表空間

所有節點都共享一份datafiles和controlfiles

計算機的高可用性

計算機系統的可靠性用平均無故障時間(MTTF)來度量,即計算機系統平均能夠正常執行多長時間,才發生一次故障。系統的可靠性越高,平均無故障時間越長。可維護性用平均維修時間(MTTR)來度量,即系統發生故障後維修和重新恢復正常執行平均花費的時間。系統的可維護性越好,平均維修時間越短。計算機系統的可用性定義為:MTTF/(MTTF+MTTR) * 100%。由此可見,計算機系統的可用性定義為系統保持正常執行時間的百分比。

負載均衡伺服器的高可用性

為了遮蔽負載均衡伺服器的失效,需要建立一個備份機。主伺服器和備份機上都執行High Availability監控程式,通過傳送諸如“I am alive”這樣的資訊來監控對方的執行狀況。當備份機不能在一定的時間內收到這樣的資訊時,它就接管主伺服器的服務IP並繼續提供服務;當備份管理器又從主管理器收到“I am alive”這樣的資訊時,它就釋放服務IP地址,這樣的主管理器就開始再次進行叢集管理的工作了。為在主伺服器失效的情況下系統能正常工作,我們在主、備份機之間實現負載集群系統配置資訊的同步與備份,保持二者系統的基本一致。

HA的容錯備援運作過程

自動偵測(Auto-Detect)階段由主機上的軟體通過冗餘偵測線,經由複雜的監聽程式。邏輯判斷,來相互偵測對方執行的情況,所檢查的專案有:主機硬體(CPU和周邊)、主機網路、主機作業系統、資料庫引擎及其它應用程式、主機與磁碟陣列連線。為確保偵測的正確性,而防止錯誤的判斷,可設定安全偵測時間,包括偵測時間間隔,偵測次數以調整安全係數,並且由主機的冗餘通訊連線,將所彙集的訊息記錄下來,以供維護參考。

自動切換(Auto-Switch)階段 某一主機如果確認對方故障,則正常主機除繼續進行原來的任務,還將依據各種容錯備援模式接管預先設定的備援作業程式,並進行後續的程式及服務。

自動恢復(Auto-Recovery)階段在正常主機代替故障主機工作後,故障主機可離線進行修復工作。在故障主機修復後,透過冗餘通訊線與原正常主機連線,自動切換回修復完成的主機上。整個恢復過程完成由EDI-HA自動完成,亦可依據預先配置,選擇回覆動作為半自動或不恢復。

HA工作方式

u  主從方式(非對稱方式)

工作原理:主機工作,備機處於監控準備狀況;當主機宕機時,備機接管主機的一切工作,待主機恢復正常後,按使用者的設定以自動或手動方式將服務切換到主機上執行,資料的一致性通過共享儲存系統解決。

u  雙機雙工方式(互備互援)

工作原理:兩臺主機同時執行各自的服務工作且相互監測情況,當任一臺主機宕機時,另一臺主機立即接管它的一切工作,保證工作實時,應用服務系統的關鍵資料存放在共享儲存系統中。

叢集工作方式(多伺服器互備方式)

工作原理:多臺主機一起工作,各自執行一個或幾個服務,各為服務定義一個或多個備用主機,當某個主機故障時,執行在其上的服務就可以被其它主機接管。

Oracle RAC One node 有如下優點:

u  不需要第三方的ha軟體,通過oracle grid軟體控制了高可用,內建叢集高可用性故障轉移

u  當為資料庫打patch單例項資料庫滾動升級

u  例項的主動遷移和故障切換

u  跨伺服器的例項動態遷移

u  線上升級到RAC

u  RAC的廉價版

u  為同一個主機上的各個資料庫Caging不同比例的CPU

RAC one node的滾動升級是非常有用的功能,使用該特性,可以實現零停機的進行升級。

RAC one node不適用如下環境:

u  由於之啟動一個例項,因此不能實現多臺主機同時使用,達到應用負載平衡,只能在多臺主機部署多個數據庫,人為把應用分開到多臺伺服器;

u  由於當一個節點down掉後,需要在另外一臺主機啟動資料庫,需要有一個啟動過程,因此不能到到一個真正的高可用性解決方案;

2.6.RAC和 RAC One Node 的區別

u   Rac one node 是RAC資料庫中的一個例項執行在GRID叢集中,它與標準 Oracle RAC 的主要區別在於 Oracle RAC One Node 資料庫通常僅在一個例項上處於活動狀態。RAC One Node 使用“例項重定向(instance relocation)”的特性, 當一個例項失敗時, RAC One Node 在另一個節點重啟失敗的例項, 在另一個伺服器通過重新掛在磁碟和使用pfile/spfile重啟例項;rac是在兩個節點同時執行,當一個節點出現問題,前端應用直接通過客戶端切換到另外節點。

u  資源消耗,rac one node是在一個節點執行,另外一個節點資源不是用,和作業系統ha基本相似,Rac資料庫是多個節點同時執行一個數據庫,由於多個節點同時執行一個數據庫,因此,會出現內部資料傳輸,如果應用開發有問題,或部署有問題,那麼,雖然是兩個節點,但是承壓能力不能達到預期目的,並且如果應用設計不好,那麼使用rac後效能優於內部資料傳輸,會降低很多。

u   rac是執行多個例項,但是對應同一個資料庫,而Rac one node也可以在多個節點執行不同的資料庫例項來充分利用資源,但是多個例項分別對應不同的資料庫,不是對應同一個庫,這樣可以分別部署不同應用,硬體資源也得到了充分利用,也減少了內部通訊資源,效能得到了提升。

u  資源控制,如果在同一個rac叢集中建立了兩個庫,那麼每臺伺服器就要存在兩個例項,這兩個例項無法單獨控制資源使用,例如cpu等,但是rac one node如果在一臺機器上配置兩個庫,那麼每個庫可以單獨控制資源使用。

u   Rac是資料庫在多個節點啟動多個例項,但是例項名稱不一樣,rac one node是在一個節點啟動一個例項,當本節點例項出現問題,oracle 通過11g oracle restart技術,在這個例項在另外一臺機器自動起來。

u  如果當前資料庫不能滿足資源要求的時候,Oracle Rac 可以線上新增節點,但是Oracle RAC One Node轉成Oracle RAC之前,不能新增其他的例項。

u   RAC one node每個處理器需要的費用會比RAC 的每個處理器要便宜點,對於2個節點的rac one node,只需要買一個節點的授權即可

u   Rac 是在多臺機器同時執行一個庫,壓力能夠分擔到不同主機,而rac one node只能在一臺機器訪問一個庫。壓力只能在一臺主機,只有當這臺主機出現問題,才切換到其他主機。

作業系統ha和racone node不同.Rac one node 可以線上轉換成rac,但是作業系統ha軟體只能實現主備的,不能轉換成rac。

作業系統ha需要單獨安裝作業系統ha軟體,軟體是主備方式,必須先關閉主資料庫,才可以切換到備用資料庫。

Rac one node通過grid控制切換,作業系統ha通過作業系統曾資源控制。

在GRID環境中可以建立多個RAC One Node資料庫,分別執行在不同的節點上,增強了硬體的利用率

RAC One Node配置全部採用oracle產品,管理維護和故障排除也變的更加簡單

如果當前執行節點需要維護(OS 打patch等)或者伺服器資源不足等等,可以手動切換資料庫(relocate)到備用伺服器,採用online database relocation,可以減少業務中斷時間(應用需要配置TAF)

作業系統ha只提供網路,主機故障切換,但是rac one node提供伺服器級別和資料庫級別——雙重級別的failover。

作業系統ha,當一個節點出現問題,那麼需要在失敗節點進行關閉資料庫,umount檔案系統,varyoffvg等等操作,如果是由於網路出現問題,資料庫正在執行很大事物,那麼很可能無法切換過去;但是rac one node技術是通過oracle restart技術,由於儲存使用asm,在安裝完軟體後,所有節點的asm是啟動的,只不過資料庫只在一個節點啟動,因此不需要varyonvg,mount檔案系統等等操作,當檢測到主節點down,備用節點直接啟動資料庫,減少了切換時間。

如果一個節點超負荷執行,或是需要停機維護,那麼Rac onenode可以通過命令線上切換到另外節點(srvctl relocate database -d hadb -n),執行relocate 命令後,GRID agent首先在節點2啟動資料庫例項2,當例項2啟動完(reconfigure結束),agent才開始停止例項1,這個與我前面提到的RAC One Node是online relocation是一致的,但是作業系統ha,如果進行手工切換,那麼和出現問題切換基本一樣,都需要把資料庫down,然後在另外一邊啟動。這樣down掉時間會延長。

根據技術實現原理看,rac one node技術是在不使用作業系統ha,全部使用oracle技術實現的一個主備系統,只不過切換速度比作業系統ha會快很多。

一個RAC One Node的使用案例。比方說,將許多中小型資料庫整合到幾臺(N臺)伺服器上:這些資料庫可能執行著關鍵任務,它們都很小並可以輕鬆地在單個節點上執行,因此它們並不需要RAC的可擴充套件性,但它們確實需要RAC提供的高可用性和靈活性。您可以建立一個N或N+1個節點的叢集,然後可以在叢集上建立您所需要個數的單節點RAC資料庫(在這個例子上是N個)。您還可以使用11.2提供的新特性InstanceCaging,限制每臺數據庫伺服器上可以使用的核心數量。

3.1. 叢集故障轉移Cluster Failover

如果一臺伺服器出現故障,使用叢集容錯轉移切換到叢集中的空閒伺服器(您的第N+1臺或一臺額外的伺服器),Oracle RAC One Node 通過無人值守的叢集故障切換同時響應伺服器故障和資料庫故障,可以重新定位受影響的資料庫服務。

下面是 Oracle RAC One Node 故障切換的一個圖形描述。

在上面的情形中,伺服器 B 發生故障,之前執行在伺服器 B 上的資料庫例項 DB3 在伺服器C 上啟動。

Oracle RAC One Node 與 Oracle Clusterware整合,後者監視資料庫的執行情況並確保資料庫服務的可用性。出現故障時,Oracle RAC One Node 將檢測故障,然後重啟發生故障的資料庫或者切換到另一臺伺服器。與 HP、IBM 和 Symantec 等供應商提供的其他第三方冷故障切換解決方案相比,它同樣也實現了冷切換功能,只是在整合度上,完全由一家產品實現,這使得資源間依賴性檢查變得非常緊密。例如ASM例項和資料庫例項之前的依存關係。

從前面列出的特性可以看出,當執行在一個節點的時候,oraclerac one node是oracle rac的“縮版”,因而它的價格也相對降低,比較適用以下情況:

開發環境和正式環境要一樣是RAC,但硬體投入要最小化。

最開始只有一臺伺服器,但根據業務量,會不斷地擴充例項節點。

在某些情況下,我們必須限制例項的cpu資源利用,甚至需要動態改變這種配置。如果應用系統對資源的需求增長很快,需要更多的硬體資源,我們可以通過oracle rac one node方式聯機升級到oracle rac。傳統的技術必須要重建成rac,這需要停機時間。

如果需要把資料庫切換到另外一個擁有更好資源的伺服器上,在oraclerac one node技術上是no downtime的。而傳統的方式,我們不得不花費時間遷移資料庫。

另外,當我們需要資料庫所在伺服器進行計劃維護的時候,如打作業系統補丁、新增硬體裝置等,通常的做法需要把資料庫例項和資料遷移走,甚至需要一份可靠的備份,整個過程需要一定的時間。如果把資料庫安裝成oracle rac one node模式,它可以使用srvctl命令進行例項遷移。我們終於使cold-failover跨入了真正聯機維護的時代。

傳統的資料庫架構中,如果把資料或例項遷移到其他伺服器上,客戶端不得不等待遷移完成,並重新配置連線地址。oracle rac one node和oracle rac一樣,能夠使用簡單客戶端訪問名(SCAN),這樣,客戶端應用程式無需重配連線池,就能直接訪問資料庫,這個過程對於應用來說,是透明的。這個和第三方的叢集軟體的VIP功能是相同的。

如果升級到oracle rac one node,不中斷服務遷移例項將成為可能。接下來的分析,將引用VM進行對比。

Oracle RAC One Node 的Omotion特性允許在不中斷服務的情況下將一個正在執行的例項從一臺伺服器遷移到另一臺伺服器。

下面是 Oracle RAC One Node Omotion特性的一個圖形描述。

Omotion特性可以將資料庫從繁忙的伺服器遷移到具有剩餘容量的伺服器,從而提供與 VM 相同的負載平衡優勢。Omotion利用 Oracle Real Application Clusters 同時執行服務於一個數據庫的多個例項。在上圖中,伺服器 A 上的 DB2 RAC One Node 資料庫遷移到伺服器 B。Oracle RAC One Node 在伺服器 B 上啟動另一個 DB2 例項,很短一段時間內,Oracle RAC One Node 將以主動-主動配置模式執行。當連線完成了在伺服器 A 上的事務後,它們就被遷移到伺服器 B 上的例項。一旦所有連線都完成遷移,伺服器 A 上的例項就關閉,遷移隨之完成。

即使當系統以峰值容量執行時,Omotion也無需停止環境。而 VM 為了將中高資料庫負載從一臺伺服器移至另一臺伺服器,一般需要停止環境。停機意味著損失。

遷移 VM 時,VM 必須將它在整個網路中的完整記憶體狀態映象到目標主機,以便再現該虛擬機器的狀態。如果正在處理的資料庫負載很高且資料庫快取中快取塊的變化較快,那麼記憶體映象功能很難跟上變化的速度。因此,成功進行記憶體映象的唯一途徑很可能變為:首先停止源 VM,接著映象記憶體,最後切換到已遷移的 VM。有了Omotion,負載很高的例項不再成為問題,因為遷移期間的工作實際上被拆分到兩臺伺服器上。因此,Oracle RAC One Node 可以輕鬆地將更高的負載遷移到另一臺伺服器上。

Omotion能夠在不同代處理器的伺服器之間移動。VM 遷移要求處理器必須是相同的 — 兩個處理器都是 Intel 或 AMD 還不夠。兩個Intel(或 AMD)處理器還必須具有完全相同的指令集。Omotion支援遷移到新處理器(如 Nehalem),甚至支援在不同供應商的處理器(Intel 和 AMD)之間進行遷移。

RAC One Node 提供了卓越的擴充套件能力,並且不會造成服務中斷。通過將資料庫例項移至一臺更大的伺服器,VM 可以增加供資料庫例項使用的 CPU 的數量。然而,為使增加的 CPU 生效,VM 需要重啟作業系統。另外,許多 VM 解決方案對 VM 的大小有限制,這種限制對資料庫伺服器來說太小了。使用 RAC One Node,資料庫可以自動適應更大的伺服器並可利用額外的 CPU — 無需重啟。此外,對 RAC One Node 沒有 CPU 限制。

ASM的自動管理特性確實令人嚮往,我們很多時候在對儲存進行維護的時候,不再需要停機了,這點很重要。而第三方叢集軟體並不支援儲存虛擬化,如HACMP,HP SERVICEGUARD。

Oracle RAC One Node 通過一個稱為自動儲存管理 (ASM) 的特性提供儲存虛擬化。ASM 對呈現給資料庫的所有儲存都進行虛擬化,使儲存的管理和調優實現自動化,並且無縫地處理由於磁碟故障或磁碟新增/刪除事件導致的儲存重新配置。

ASM的儲存池能提高儲存利用率。使用該特性,執行 Oracle RAC One Node 的單個伺服器(或叢集)上的所有資料庫將共享一個儲存池。由於 ASM 確保了所有裝置的 IO 始終是平衡的(即避免熱點),因此資料庫磁碟 IO 始終處於調整中。對空閒磁碟空間進行集中管理而不是將它們分散在多個本地儲存池中。

當使用asm的時候,由於asm會自動那個進行io均衡,也就是把存放在asm中的所有disk進行條帶,那麼如果存放在asm中的磁碟如果是在同一個raid,那麼效能就會變差,在同一個raid中的磁碟如果數量越多,那麼io次數會越多,io效能就會越慢,因此,在同一個asm dg中的磁碟要保證在不同的raid中,效能才會得到提升。