RAC与双机热备的区别.docx

RAC与双机热备的区别。

       在 Cluster ( 集群 ) 多机系统平台上，常用的高可用性技术有两种：双机热备份和 RAC 并行服务器。这两种方式采用的机制不同，实现的效果也不同。

1、双机热备份方式
        在双机热备份方式下，数据库系统平时只能在一台服务器(例如服务器 A)上运行，另一台服务器无法直接访问数据库，自然也无法进行负载分担。当服务器 A 由于故障失效时，由相应的操作系统软件控制，将服务器 A 管理的存储设备 ( 如硬盘 ) 转交给服务器 B 控制，同时在服务器B 上启动另一个数据库进程，管理数据库。这种切换并启动新的数据库核心的过程一般需要几十秒到几分钟。
       这种方式的主要缺点在于：
· 由于需要重新启动数据库核心进程，无法保证数据库系统连续不间断地运行；
· 在系统切换的过程中，客户端与服务器之间的数据库连接会中断，需要重新进行数据库的连接和登录工作；
· 由于数据库系统只能在一台服务器上运行，另一台服务器无法分担系统的负载，实际上造成了客户投资的浪费。在有些系统中，为了解决双机负载分担的问题，将应用系统人为分割为两个数据库系统，分别在两台服务器上运行。这种方式在一定程度上解决了负载分担的问题，但给系统管理、统计分析等业务处理带来了很多额外的复杂性

2、RAC方式
        在并行服务器方式下，两台 ( 或多台 ) 服务器上各自运行一个数据库核心进程，但共同管理、操作一个数据库。客户端无论连接到哪个服务器都可以在数据库中进行操作。当服务器 A 由于故障失效时，数据库系统本身并未停止工作，连接在服务器 B 上的客户端还可以继续进行正常工作。同时，服务器 B 上也不需要再启动新的数据库服务器进程，因此也没有“切换时间”。对于一些特殊应用中严格要求前端应用不能中断的情况， Oracle 并行服务器还提供了一种“预连接 (pre-connect) ”方式，以这种方式连接的客户端当服务器端发生故障时，客户端与数据库服务器的连接不会中断，会被 Oracle 并行服务器软件自动转接到还在正常工作的其它服务器上，不需要重新输入用户名及口令。
        同样有许多操作系统平台支持并行服务器方式的高可用性方案，例如 HP MC Service Guard OPS Edition 等。
        与双机热备份方式相比， Oracle Real Application Cluster 并行服务器方式有以下优点：
· 各服务器共享一个数据库，在正常运行时可以进行负载分担，无需考虑应用数据的人为分割
· 并行服务器方式对应用完全透明，在应用程序设计和开发的过程中也不需要进行特殊编程，简化了开发的复杂程度，同时今后系统扩展也无需修改应用程序
· 不需要重新启动数据库核心进程，缩短了故障造成的停机时间

3、RAC 的好处
        具有 Cache Fusion 体系结构的 Oracle Real Application Clusters 为企业应用开发提供了以下好处：
· 应用系统灵活和毫不费力的伸缩性；应用用户可以登录到单独的虚拟高性能集群服务器。向数据库添加节点非常容易，并且当需要添加处理器节点或者业务需求变化时，不用手工对数据进行分区。对于所有的应用即时提供集群的可伸缩性－－不用修改应用程序。
· 较之传统集群数据库体系结构的高可用性解决方案；该体系结构为客户提供了几乎连续的数据访问，使硬件和软件故障导致的业务中断最小化。系统具备对多个节点失败的容错能力，使部件失败屏蔽开最终用户。
· 单独的管理实体；为了进行所有管理操作，在集群中保持一个单独的系统映像。 DBA 一次性地进行安装、配置、备份、升级以及监控等功能，然后 Oracle 将管理功能自动分配到适宜的节点。这意味着 DBA 只管理着一个 虚拟服务器。
· Cache Fusion 保存了所有 Oracle 客户在他们应用中学习和开发 Oracle 的投资。所有单节点数据库功能都保留下来，并且应用程序使用相同标准的 Oracle 接口连接到数据库上。

可伸缩性
        基于 RAC 应用的用户或者中间层应用服务器客户，可以通过虚拟数据库服务名连接到数据库上。 Oracle 在集群中多个节点之间自动平衡用户负载。不同节点上的 Real Application Clusters 数据库实例预订所有数据库服务或者部分子集数据库服务。这使得 DBA 高度灵活地选定，连接到特定数据库服务的特定应用程序客户是否可以连接到某些或者全部的数据库节点。虽然每一个节点有一个不同的物理 IP 地址时，应用客户仍可以在一个逻辑数据库服务名的水平上进行连接。因此客户端对于不相关的事情如多服务器的多个地址可以毫不关心。随着业务的增长，应用系统可以从容地增加处理能力。 Cache Fusion 体系结构直接地利用新节点的 CPU 和内存资源。 DBA 无需用手工对数据重新分区。这个优点是这种体系结构的副产品，因为有透明度的数据存取是 Cache Fusion 的一项基本功能。 Cache Fusion 体系机构自动适应快速变化的应用需求及随之而来的工作负荷的改变。 DBA 也不必因为工作负荷变化而对数据进行手工的重新分区。 Real Application Clusters 通过动态地重新分配数据库资源，从而在节点之间用最小化的磁盘 I/O 和低的延迟通信来优化利用集群系统资源。这使得 Real Application Clusters 可以从容实现增加的应用吞吐量和优化的响应时间。

高可用性
        Real Application Clusters 提供了真正的高可用性解决方案，关键的突破是在大多数数据库恢复期间能提供完整的数据库访问。这使得 Real Application Clusters 成为应用所要求的 24x7 可用性的最佳平台。
        Real Application Clusters 在高可用性上在三个关键领域胜出：
· 提供了数据库恢复期间的数据块访问
· 透明的失效转移对最终用户屏蔽了系统失效
· N-1 节点失效的容错能力
        只要有一个数据库节点幸存， Real Application Clusters 就能够提供完全的数据库访问和相对不间断的操作。

可管理性
        Real Application Clusters 实现了真正意义上的一个单系统访问数据库，它提供了从任何节点到所有磁盘设备和远程高速缓存进行无缝数据访问的能力。此单系统映像延伸到所有数据库管理操作。安装、配置、备份、升级以及监控等操作只需进行一次，然后会自动发布到集群中所有节点上去。各种 Oracle 工具（如 Oracle Universal Installer 、 Database Configuration Assistant 以及 Recovery Manager ）将发现集群数据块中所有不同的节点并以它们为目标分配给想得到的任务。通过为特定的管理操作选择多个目标节点，管理任务在数据库集群中多个节点上执行。这为应用系统管理其环境带来了极大的可伸缩性上的经济实惠。例如，向数据库集群添加一个节点只会增加最小的管理任务。这样， Real Application Clusters 支持在线商务应用和决策支持之类的应用，并且为数据访问和管理提供了单一的虚拟高性能服务器。

总结

1、对于硬件来说基本上一样，共享存储、光纤线（也有还用SCSI线的）、多台小型机（可以做多节点的相互热备，也可以做多节点的RAC）、光纤交换机（如果是用光纤卡的话）；但做RAC，在主机之间，最好使用高带宽网络交换机（虽然不用也可以做成），硬件成本相差不大。
2、软件呢，差别可不小如果是双机热备，必须买操作系统级的双机管理软件；如果是RAC，目前还是建议购买双机管理软件（尽管10g的crs+asm可以摆脱双机软件了，但ASM目前实在太难伺候了），当然还得买RAC license。
3、日常维护。RAC要求的技术含量更高，也应该更勤快。最关键的是得买Oracle服务，否则遇到有些问题（bug），你就比单机还不高可用了。
4、优缺点。这个，看看RAC的官方论述吧。如果能用好，确实是很有好处的。目前我们的40多个客户的使用情况来看，RAC确实大大降低了他们的downtime，另一方面可以说就是提高了生产力。

另，为什么RAC比双机热备切换快很多？

我们先分析双机热备切换的步骤：假设A机是主机，B机是备机。当A机发生故障时，集群软件通知B机接管数据库。接管过程如下：
1. B机接管数据库文件所在的磁盘, 花费时间为T1（算在B机接管数据库文件所在的磁盘这部分时间内了，因为总是需要从A umount，然后在B上mount的。）
2. B机启动数据库实例，花费时间为T2
3. B机的数据库实例mount数据库文件，花费时间为T3
4. B机的数据库实例open数据库文件，完成数据库重启，花费时间为T4
5. 应用重新连接上B机的数据库实例，花费时间为T5

所以切换时间T=T1+T2+T3+T4+T5 (可能还有其它一些可以忽略不计的时间)。以上切换时间的计算是从集群软件断定A机已经停机开始计算，之前的时间不计。

1. 如果数据库文件所在的磁盘已经是共享文件系统，而且事先B机已经mount该文件系统，那么T1=0, 否则T1可能需要十几秒到2分钟。
2. T2一般比较快，如果Oracle SGA区比较大，时间会稍长一点，一般1~2分钟。
3. T3视数据文件的数量而定，如果数据文件比较多，那么这个时间也会比较长，一般2~5分钟。这个时间和磁盘的速度也有关系。
4. 如果切换是属于计划停机切换，那么数据库一般是正常 shutdown的，重新open时不需要做恢复工作，这个时间可能会很快，例如1分钟之内；但是如果是由于故障停机切换，那么数据库重新open的时候需要做大量的恢复(instance recovery)工作，所以T4有可能从1分钟到10分钟，甚至更长。这个时间和磁盘的速度也有关系。
5. 如果应用原来也跑在A机上，那么切换以后，还要重启应用，这个时间就比较长。如果应用部署在独立的应用服务器，例如C机上，那么一般需要等数据库服务器IP地址浮动到B机，Oracle监听器重启以后，应用才能重新连接到数据库服务器。这个时间可能需要1分钟到5分钟，重启应用的时间也可能更长。

所以双机热备下切换时间最少T=0+1+2+1+1=5分钟，这是非常理想的情况下；按照经验，至少需要10分钟。也可能是T=22+5+10+5=24分钟，甚至更长，视数据库需要恢复的时间。

再看RAC的情况
1. 一定是共享磁盘，不需要再mount磁盘。T1=0
2. B机的实例平时已经Open，所以T2=0, T3=0, T4=0
3. 如果应用原来只跑在A机上，那么为缩短停机时间，可以事先可以在B机上把应用启动；A机故障以后只要使用B机的应用即可。没有停顿。如果应用部署在独立的应用服务器上，例如C机，甚至还有D机时，原来连接B机的应用正常工作，没有停顿时间；原来连接在A机上的应用重新连接数据库，这个部分应用可能的中断时间很短，一般在几秒钟到1分钟之内。

所以RAC环境下切换时间最少T=0+0+0+0+0.1=0.1分钟。也可能T=0+0+0+0+1=1分钟，但不会长很多。

如果有人不能理解这过于技术的描述，那么记住以下的比喻：
双机热备相当于火车头坏了，停下来换一个火车头；而RAC相当于有多个火车头，即使一个不工作了，也不需要停下了。