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节点可能成为瓶颈的分析（摘自http://www.db2china.net/club/thread-18384-2-1.html）：
    确实在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的特性如下(http://www.db2china.net/club/thread-18689-1-2.html):
- 更好的性能伸缩：通过增加/减少数据库成员可以获取良好的性能伸缩，能持续扩展到超过 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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/18922393/viewspace-708090/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/18922393/viewspace-708090/