時代老是在進步的，這老是得益於新的生產技術的出現，咱們老是有太多的問題須要解決，對於技術人員來講，當一項新的技術的出現並解決了困擾已久的問題的時候，這無疑是最激動人心的，它不只把咱們從落後的生產過程當中解放出來，更重要的是，它能使生產力更大化、成本更小化。如更好的資源利用和更少的停機時間。本文主要談談oracle rac中的一項新技術革新，即oracle rac one node。在分析過程當中，會引用一些舊有技術作對比，如VM，FAILOVER和實例遷移等前端
Oracle Real ApplicationClusters One Node 是 Oracle Database 11g 第 2 版企業版的一個新選件。它對服務器虛擬化的諸多優點加以改進，並將這些優點擴展到物理服務器環境中運行的數據庫。它容許在集羣中的數據庫以單實例的方式運行在一個節點上。對於計劃和非機劃的停機能提供更有效地保護。咱們老是但願業務可以持續的運行、系統能獲得更可能的保護、升級和遷移的代價最小化，而新技術是否須要被採用，須要具體分析它的技術革新性。node
傳統的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的框架圖：oracle
從圖上咱們看出，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上。各個數據庫使用共享存儲。app
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的各個節點的數據緩衝區經過高速、低延遲的內部網絡進行數據塊的傳輸。
在一個應用環境當中，全部的服務器使用和管理同一個數據庫，目的是爲了分散每一臺服務器的工做量，硬件上至少須要兩臺以上的服務器，並且還須要一個共享存儲設備。同時還須要兩類軟件，一個是集羣軟件，另一個就是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自動完成，亦可依據預先配置，選擇回覆動做爲半自動或不恢復。
u 主從方式（非對稱方式）
工做原理：主機工做，備機處於監控準備情況；當主機宕機時，備機接管主機的一切工做，待主機恢復正常後，按使用者的設定以自動或手動方式將服務切換到主機上運行，數據的一致性經過共享存儲系統解決。
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掉後，須要在另一臺主機啓動數據庫，須要有一個啓動過程，所以不能到到一個真正的高可用性解決方案；
u 因爲rac one node基本也是在一個局域網內部署，所以，不能實現災備，做爲一個災難恢復（DR）解決方案; Data guard 是比較好的解決方案。
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，限制每臺數據庫服務器上可使用的內核數量。
若是一臺服務器出現故障，使用集羣容錯轉移切換到集羣中的空閒服務器(您的第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中，性能纔會獲得提高。