Oracle RAC vs DB2 PureScale

透過在架構、實現方式等方面對RAC和PureScale進行比較，供參考。

   Oracle RAC                         DB2 PureScale
目標定位         擴充套件性、高可用性                   擴充套件性、高可用性（DB2明確定位為OLTP系統，OLAP推薦DB2 DPF）
儲存             共享儲存(ASM,叢集檔案系統,裸裝置)  共享儲存(叢集檔案系統)
鎖/快取管理      分散式鎖管理技術和分散式快取架構   集中化的鎖管理和全域性共享緩衝池架構
節點             每個資源有master節點,所有節點對等  存在Coupling Facility(CF)節點與成員節點
可能擴充套件瓶頸     採用Cachefusion，節點間頻寬        CF節點的處理能力      
可靠性           所有節點對等，可靠性高             即使採用雙CF節點，相較而言可靠性較低
硬體特殊要求                                        Infiniband(卡,交換機)的RDMA技術,成本高,特定平臺
軟體要求         Oracle clusterware                 IBM powerHA pureScale
網路要求         2個乙太網卡(3ip,有一個vip)         1個乙太網卡(1 ip),1個Infiniband網路卡(1 ip)

注:
*1，關於Infiniband的RDMA技術:
   purescale也可以部署在TCP/IP網路，但效能受影響較大，可用於模擬/測試
*2，關於CF節點可能成為瓶頸的分析（摘自）：
    確實在db2 pureSCale的架構中Primary CF只有一個，當節點數增加的時候CF會不會成為瓶頸是很多使用者心裡的疑慮。 其實使用者大可以放心， 在這裡說明一下關於CF的瓶頸問題。一個系統的瓶頸無非是記憶體，CPU，網路，DISK IO這四大方面。
  (1) 對於CPU,CF僅僅作為 Global lock management（GLM）和global bufferpool management（GPM）,並不參與任何真正的使用者請求，所以CPU幾乎不可能成為瓶頸。
  (2) 對於記憶體，因為只有member更改過的資料才會被寫入到CF中的global bufferpool中，而大部分節點還是在自己的bufferpool中快取自己的資料，因此CF的global bufferpool 中只會儲存一部分資料。 並且一個典型的OLTP應用，全庫的資料一般也就在幾百G左右，經常要改動的資料可能更小，現在伺服器上幾百G甚至上T的記憶體已經不是什麼稀罕事情，而且記憶體幾乎是最便宜的配件。 DB2 pureScale專為OLTP應用量身打造，因此CF的記憶體成為瓶頸可能性是非常小的。
  (3)至於DISK,對於CF來說就更不會成為瓶頸了。 因為其一，pureScale是基於share disk架構的， 所有的member和CF都是共享儲存，如果disk成為瓶頸，那肯定是整個cluster的儲存成為瓶頸，而不可能僅僅是CF;其二， CF僅僅用於GLM和GPM，根本就不從disk上直接讀取資料。
  (4)至於網路，先談IP網，CF的IP網路只負責和叢集中的其他節點做管理通訊以滿足叢集軟體管理上的需求，根本不會由來自應用端的請求，因此CF的IP網路永遠不可能成為瓶頸。
    再談InfiniBand網路, CF和Member之間的資料通訊主要透過IB網路。當節點數量增加，TPS增加的時候，CF和member之間的IB頻寬是否足夠使用者最為關注的焦點。 其實大可不必擔心，首先現在IB卡的傳輸速度是40Gb, 是萬兆網的4倍。 其次，CF節點支援多塊IB卡，也就是說即使真的出現了CF上一個IB卡不夠用的問題，也可以透過給CF增加額外的IB卡來解決。所以IB網路成為瓶頸的可能性也不大

*3 DB2的支持者認為puresacle優於RAC的特性如下():
- 更好的效能伸縮：透過增加/減少資料庫成員可以獲取良好的效能伸縮，能持續擴充套件到超過 100 位成員（DB2 利用基於InfiniBand的 Remote Direct Memory Access (RDMA) 直接對遠端伺服器的記憶體執行寫操作）
- 更高的應用透明性：pureScale 多個成員對應用程式透明，無需應用或資料庫分割槽也能獲得良好效能擴充套件
- 更高的持續可用性：交付不中斷的資料訪問，確保效能一致；當資料庫成員出現故障時，只有動態資料仍然保持為鎖定，直到成員恢復完成。在此期間，其他成員能正常處理交易（RAC節點故障時會凍結所以IO，導致恢復時間過長並影響其他節點）
- 故障恢復時，pureScale是記憶體恢復（RAC是日誌恢復），所以pureScale恢復時間比RAC短很多。

集中鎖和緩衝池管理的應用為 DB2 pureScale 提供了其他同類市場產品所無法比擬的可伸縮和可用性優勢。為了更加詳細地探究這種差異化，我們將將DB2 pureScale 與 Oracle RAC 與之進行比較：
- 可用性比較：
    在 Oracle RAC 中，每個資料頁（在 Oracle 術語中稱作資料塊）都由叢集中的一個例項來管控。Oracle 採用分散式的鎖機制，因此叢集中的每個例項都需要負責管理和批准對它所管理頁的鎖請求。當某個節點出現故障時，故障節點所管理的資料頁會立即變為孤立的，直到RAC 會透過重新分配流程將這些孤立頁面的管控權分配給叢集中健康的節點。在 Global Resource Directory (GRD) 重新配置的過程中，對頁面(page)的任何讀取和鎖請求都會立即被凍結。應用可以繼續在健康的節點上處理，但這時它們不能執行任何 I/O 操作或請求任何新鎖。這會造成許多應用出現凍結。
    RAC 節點恢復流程的第二步是鎖定所有需要恢復的資料頁面。這項任務必須在 GRD 凍結被釋放之前完成。如果某個例項在獲得適當的頁級鎖之前被允許讀取磁碟中的頁面，則故障例項的更新操作可能會丟失。恢復例項將一遍讀取故障例項的重做日誌檔案，並鎖定任何需要恢復的頁面。這可能需要大量隨機的 I/O 操作，因為日誌檔案乃至需要恢復的頁都可能不在任何健康節點的記憶體中。
僅當恢復例項執行了所有這些 I/O 操作並鎖定適當的頁之後，GRD 凍結才會被釋放，停滯的應用才能繼續執行。根據故障節點在出現故障時正在進行的工作量，這一過程可能會花費幾十秒到幾分鐘不等的時間。
相比之下，DB2 pureScale 環境則不需要在叢集中進行全域性凍結。CF 在任何成員出現故障時始終知道哪些頁面需要恢復。如果某個成員出現故障，叢集中的所有其他成員可以繼續處理事務和執行 I/O 操作。只有對需要恢復的頁面的訪問請求會在故障成員的恢復流程完成之前被阻塞。
- 可伸縮性比較
    DB2 pureScale透過InfiniBand並利用Remote Direct Memory Access (RDMA)直接對遠端伺服器的記憶體執行寫操作。雖然Oracle也可以將InfiniBand應用於Oracle RAC叢集，但是 Oracle 沒有利用 RDMA技術，這意味著 Oracle 通訊將使用速度較慢的套接字協議，並且需要一些開銷較大的 CPU 中斷，從而影響叢集效率。
    支援 RDMA 訪問的集中鎖定和全域性緩衝池為DB2 pureScale帶來高可伸縮性，在讀寫比例為80:20的12個成員節點的測試中，DB2 pureScale的效能擴充套件超過90%。Oracle RAC 採用分散式鎖，這會增加開銷並降低可伸縮性。實際上，4個節點以上的RAC應用並不多，因為其無法透過增加節點而達到更好的效能擴充套件。
- 應用透明性比較
   支援 RDMA 訪問的集中鎖定和全域性緩衝池為DB2 pureScale 同時帶來高應用透明性，而不會讓應用叢集感知到。使用DB2 pureScale不需要透過應用或資料分割槽來實現可伸縮性；增加或減少成員節點也無需對應用進行修改，這極大地降低了管理和應用開發成本。
    Oracle RAC 最佳實踐建議中包括： a) 每個頁面使用較少的行（避免熱頁面）b) 透過資料庫分割槽來避免熱頁面 c) 透過應用分割槽來獲取一定水平的可伸縮性。所有這些都會造成管理和開發成本增加。

*4,DB2 pureScale 對於網路和伺服器的要求和最低機器的配置
    支援pureScale的伺服器包括IBM POWER6 550 (8204-E8A), POWER6 595 (9119-FHA), POWER7 750 (8233-E8B), POWER7 755 (8236-E8C), POWER7 770 (9117-MMB), POWER7 780 (9179-MHB)。
    這些伺服器上必須至少安裝一塊Ethernet卡和一塊InfiniBand卡（以後版本會支援萬兆網，不一定要使用InfiniBanc）。不同的伺服器對應不同的InfiniBand，如POWER6 550 (8204-E8A)對應InfiniBand的FC是5609；POWER6 595 (9119-FHA)對應InfiniBand的FC是1816。
    另外，還需要對應的InfiniBand的連線和InfiniBand Switch。
    pureScale推薦使用2臺伺服器（或LPAR)作CF，至少2臺伺服器（或LPAR)作成員節點。當然，您應該根據實際業務負載增加伺服器。

最低配置：
- 2臺IBM POWER6? 550 Express (8204-E8A) server
- Disk Storage：Any disk storage supported by IBM General Parallel File System (GPFS)
- Disk connection method：Direct SAN connection
- Network：一Ethernet Network和一InfiniBand network
- InfiniBand Network switches:IBM 7874-024
- Operating system: AIX6.1 TL 3 only. With SP2 or higher
- uDAPL level 6.1.0.1 or higher
- OpenSSH level 4.5.0.5302 or higher
- XL C/C++ Runtime level is 9.0.0.8 or higher
- Storage：
- Local disk space on each host: 6.5 GB
- Shared disk space：
- Tiebreaker disk: 25 MB
- Shared file system: 100 GB recommended