標籤:os io 資料 ar 問題 cti 工作 資料庫
瀏覽了一下Oracle官方的網頁以及非官方的ppt,簡單瞭解了一下Oracle提供的高可用方案。
1. RAC
RAC, Real Application Clusters
多個Oracle伺服器組成一個共用的Cache,而這些Oracle伺服器共用一個基於網路的儲存。這個系統可以容忍單機/或是多機失敗。
不過系統內部的多個節點需要高速網路互連,基本上也就是要全部東西放在在一個機房內,或者說一個資料中心內。如果機房出故障,比如網路不通,那就壞了。所以僅僅用RAC還是滿足不了一般互連網公司的重要業務的需要,重要業務需要多機房來容忍單個機房的事故。
2. Data Guard.
Data Guard這個方案就適合多機房的。某機房一個production的資料庫,另外其他機房部署standby的資料庫。Standby資料庫分物理的和邏輯的。物理的standby資料庫主要用於production失敗後做切換。而邏輯的standby資料庫則在平時可以分擔production資料庫的讀負載。
3. MAA
MAA(Maximum Availability Architecture)其實不是獨立的第三種,而是前面兩種的結合,來提供最高的可用性。每個機房內部署RAC叢集,多個機房間用Data Guard同步。
Oracle+Fusionio+Dataguard的高可用方案
傳統的Oracle的高可用方案必須基於共用存放裝置,不管是雙機主備模式,還是Oracle RAC,資料庫必須放在共用的SAN儲存上,通過HA或叢集軟體實現高可用。Oracle DataGuard是很好的容災軟體,但是作為HA解決方案,功能有很多局限性,比如資料丟失,應用透明切換,只能讀無法寫(11g)等等,目前都沒有非常好的解決方案。
自從固態儲存技術出現後,單機的IO能力大幅度提升,比如採用PCIE介面的fusionio卡,單塊卡就可以提供數萬IOPS的能力,單機的IO能力已經超過了傳統的磁碟儲存。但是,一直困擾我們的是,如何解決無共用儲存環境下Oracle資料庫的高可用問題?我們團隊設計了一種架構,提供簡單可靠的高可用功能。
雖然在Oracle的立場上,總是建議客戶能夠更好地規劃自己的應用,在有其它Server Load Balancer方法的時候,盡量不要依賴於Oracle的Load Balance方法,但是往往在給客戶配置完Oracle RAC資料庫以後,客戶都會要求要測試Server Load Balancer(Load Balance)和TAF(Transparent Application Failover),並且將這兩個測試作為RAC是否安裝成功的標準。
這是一件很無奈的事情,像把旁枝末節看作了主要功能,甚至有些買櫝還珠的感覺,但是畢竟這是客戶,更瞭解Oracle Load Balance(後文用LB表示),才可以更好滿足客戶需求。
RAC的負載平衡主要是指新會話串連到RAC資料庫時,如何判定這個新的串連要連到哪個節點進行工作。在RAC中,負載平衡分為兩種,一種是基於用戶端串連的,另外一種是基於伺服器端的。用戶端的負載平衡配置相對簡單,只需要在tnsnames.ora中添加LOAD_BALANCE=ON這麼一個選項即可。
實現負載平衡(Load Balance)是Oracle RAC最重要的特性之一,主要是把負載平均分配到叢集中的各個節點,以提高系統的整體吞吐能力。
通常情況下有兩種方式來實現負載平衡
一個是基於用戶端串連的負載平衡
用戶端的負載平衡主要是通過為tnsnames.ora增加load_balance=yes條目來實現
如果未開啟load_balance=yes時,Oracle Net會根據地址清單按順序來選擇一個進行串連,直到串連成功為止。 如果第一個host主機串連失敗,在有多個地址的情形下,接下來選擇第二個地址串連,依此類推,直到串連成功為止。當開啟了load_balance=yes時,則Oracle Net會從多個地址中隨機地選擇一個地址進行串連,直到串連成功為止。注意,此串連方式僅根據地址清單隨機播放,並不考慮到各個執行個體上當前真正串連數量的多少,也即是沒有考慮各個節點真實的串連負載情況
二是基於伺服器端監聽器(Listener)收集到的資訊來將新的串連請求分配到串連數較少執行個體上的實現方式。
Oracle RAC伺服器端的負載平衡是根據RAC中各節點的串連負荷數情況,將新的串連請求分配到負荷最小的節點上去。當資料庫處於運行時,RAC中各節點的PMON進程每3秒會將各自節點的串連負荷數更新到service_register。而對於節點中任意監聽器故障或監聽器意外失敗時,PMON進程會每1秒鐘檢查當前節點上的監聽是否重啟,以獲得最新的負載資訊來及時調整負載平衡。