Oracle数据库HA架构方案介绍（转）

转自：http://www.open-open.com/lib/view/open1405523988328.html

 

摘要:Oracle数据库在各类应用系统中负责存储平台所有的用户数据，数据库的可靠性及安全性直接影响平台的安全运行，目前采用的Oracle Replication方式来实现的数据库高可靠性已经显示出了弊端，本文介绍并分析了目前比较流行的几种数据库高可用性的架构：Oracle Replication、Oracle Rac、Oracle 主机HA等，希望给大家一个参考。

 

1 什么是高可用性（High  Availability）

 

高可用（HA）性有两种不同的含义，在广义环境中是指整个系统的高可用性，在狭义方面一般指主机、服务的冗余，如主机HA、应用程序的HA等，无论那种情况，高可用性都可以包含如下一些方面：

 

Ø 系统失败或崩溃

 

Ø 应用层或者中间层错误

 

Ø 网络失败

 

Ø 介质失败：指一些存放数据的媒体介质故障

 

Ø 人为错误

 

Ø 系统的容灾备份

 

Ø 计划内的维护或者重启

 

可见，高可用性不仅包含了系统本身故障、应用层的故障、网络故障、认为操作的错误等，还包含数据的冗余、容灾及计划的维护时间等，也就是说一个真正的高可用环境，不仅能避免系统本身的问题，还应该能防止天灾、人祸，并且有一个可靠的系统升级及计划维护操作。

 

本文探讨的Oracle  数据库层面的高可用性，不可避免也会涉及到一些主机、存储、操作系统方面的高可用性，因为要实现Oracle服务的连续性保障是离不开硬件层面的支持 的。随着Oracle技术的发展（Oralce  8i/9i/10g/11g），高可用性越来越完善、越来越可靠，本文介绍了四种Oracle  高可用性的相关产品，并通过其实现方式和性能的比较得到在现在和未来的Vas2000系统中更适合的数据库高可用性方案：

 

Ø Oracle Parallel Server/Oracle Real Application Cluster（Oracle  Rac）

 

Ø Oracle Standby Database/Oracle Data Guard

 

Ø Oracle Advanced Replication/Oracle Stream

 

Ø Oracle Server HA

 

2 Oracle并行数据库OPS/RAC

 

OPS 从Oracle 8i开始提供，从Oracle 9i开始成为RAC，并且随着高性能PC SERVER的普及，Oracle  Rac也成为Oracle高可用性产品最流行的一种架构，Oracle  Rac通过组织多个服务器的Cluster来获得更大的计算处理能力和故障处理能力的集群。

 

2.1 Oracle RAC架构介绍

 

RAC通过不同的节点（node）使用一个（一般是一个）或者多个Oracle实例（Instance）与一个数据库（Database）连接，该 数据库存放于多个节点的公用存储（Share  Storage）上，通过高速缓存合并技术使得集群中的每个节点可以通过高速集群互联高效的同步其内存高速缓存，从而最大限度地减低磁盘IO，并且自动 并行处理及均匀分布负载，当其中一个节点发生故障时可以自动容错和恢复能力来实现节点的故障切换（Failover），从而保证数据库7X24小时的高可 用性，下图1  是以两个节点为例来简单介绍一个RAC架构的软、硬件结构：

 

 

 

 

 

 

  图1 Oracle RAC结构图

 

在上图的结构中采用了2节点（node）的RAC，通过共享的存储介质使两个节点同时访问Database，在实际的工作环境中共享存储一般通过存 储网络（SAN）提供，应用层服务器通过连接RAC的VIP（Virtual  IP）负载均衡的连接到任何一个节点提供服务，当其中的任何一个节点发生故障时，另一个正常的节点可以自动接管其服务，对于应用来说不需要做任何切换， 只需通过VIP的自动跳转来实现失败节点的切换，在故障切换时Oracle会自动恢复故障节点中的事物，以便使整个数据库处于一致状态，整个切换过程一般 持续1~5分钟，具体取决于应用环境的压力大小和复杂程度。

 

Oracle RAC除了硬件的组成外，还需要Oracle的软件组件来支持，主要包含如下5个层次的软件环境：

 

Ø CRS：Oracle  10g以上版本的Cluster软件，管理整个RAC环境，包括VIP、监听、ASM、DB等，除了Oracle自己的Cluster软件外，目前也有 很多第三方的Cluster软件可用，比如：Sun  Cluster、Lifekeeper、Leagto等，可以根据具体部署环境的要求来选择

 

Ø RAC：Oracle的Cluster支持组件

 

Ø Listener：监听与Oracle网络

 

Ø ASM  Inst：ASM的实例，提供存储管理，使得存储空间之间可以提供给Cluster数据库使用，在很多OS上如果使用了第三方的Cluster软件则必须采用第三方的存储管理软件（LVM），如IBM的HACMP、Veritas的VCS等

 

DB Inst：这里是RAC环境的最上层，DB层，数据库就运行在该层

 

2.2 Oracle RAC特点

 

1)    单一的Cluster环境

 

  从Oracle  10g开始推出的CRS软件与ASM存储管理设置，可以完全脱离第三方的Cluster软件而在各个平台上安装使用，从而不但降低了RAC环境的成本，也使安装、维护更加简单

 

2)    实现Oracle的持续服务和负载均衡

 

通过VIP访问RAC，当一个节点发生故障时这个VIP会转移到其他节点上，从而保证应用的不间断服务，同时CRS也可以对访问RAC的服务负载均衡的分布到环境中的每个node上。RAC环境也是一个可伸缩的环境，在不影响当前业务的条件下，可以方便的增加和删除节点。

 

3)    在线补丁升级

 

RAC系统支持补丁滚动方式的升级，当补丁应用大一个节点上时其他节点可以正常的运行提供服务，同时根据补丁产生的编号，将不定标记为是否是否作为滚动升级来安装，如果需要滚动升级则可以在不影响提供服务的前提下自动应用到每个节点。

 

4)    需要与其他容灾组件配合完成存储的备份

 

 RAC的Data file、Control file、Redo  log等都存放到共享的存储上，RAC只具备主机、应用的保护和负载均衡，并不具备容灾的功能，如共享磁盘设备损坏或者不可预料的损失将导致RAC环境 的不可使用，所以RAC一般要与其他的容灾组件配合使用来保证数据的安全，一般依靠RAID、LV镜像、活Data  Gua来实现数据的冗余。

 

3 Oracle备用数据库Standby/Data Guard

 

Standby database/Data  Guard是Oracle退出的另一种高可用性数据库方案，在主要和备用节点之间通过日志同步来保证数据同步，备用节点作为主节点的备份，可以实现快速 的切换与灾难性恢复。从Oralce  9i开始，Standby数据库更名为数据库保护（Data Guard）

 

3.1  Oracle Data Guar结构介绍

 

Data  Guard一般包括两套数据库环境，一台主要数据库，一台备用数据库，与RAC不同的是，以一般情况下只有一个节点处于活动状态，所有应用都连接到主服 务器上，只有当主服务器发送故障时才考虑切换到备用服务器。备用服务器一般不提供读写的操作，只有当需要时才提供只读的操作，或者当主站点出现故障时经过 切换操作才变为主数据库，提供正常的读写操作，由于存在Active/Standby两套主机、存储环境，所以较RAC多了数据保护盒容灾的功能，图2为 Data  Guard的结构图：

 

 

 

图2 Oracle Data Guard结构图

 

 

 

在以上结构中，主备数据库各一套，在实际的应用环境中可以根据环境的不同配置多套主、备用数据库。物理Standby其实是采用备份与恢复的原理实 现的，在主、备数据库之间，采用Standby的日志传送方式，归档日志活联机日志通过网络传送到备用端，所以可以把Standby看做是一个正在不停恢 复中的数据库，因为主数据库一直在运行，所以备用数据库一直处于应用日志状态，或者等待下一个日志应用。因为Standby的主数据库与备用数据库是两个 独立的数据库，基本上没有太大的联系，所以该体系结构远没有RAC那么复杂，只要两个数据库直接网络相通就可以。从Oracle  9i开始，既可以传送归档日志也可以传送联机日志，根据传送日志的不同分别由ARCH和LGWR进程来处理，但由于传送联机日志需要实时的同步，所以要 求在备用数据库建立对应的日志文件（Standby  log），并且可能会对LGWR进程造成一定的影响，所以从Oracle  10g以后默认采用归档日志传送，这种方式不需要额外的配置，只需要简单的修改Standby数据库的归档路径即可。

 

3.2 Oracle Data Guard特点

 

1)  可以实现数据库主机及存储的完全冗余保护，该冗余甚至可以跨地域做成容灾保护，是Oracle主推的容灾产品。在Standby中主用数据库必须运行在归档模式下，以保证备用节点的数据一致性，因此该特性并不适合数据仓库。

 

2)  Standby主节点对OS的环境要求较高，一般要必须是相同或者相近的OS环境，并且对数据库版本也有特定的要求，不能实现跨数据库版本的备份。

 

3)  不能自动的故障切换，如果主站点损坏要切换到备用站点，则需要在切换前完全同步主站点当前的联机日志，否则会发生切换后数据丢失的现象。

 

4 Oracle高级复制与流

 

Advanced  Replication/Streams的设计目的是更灵活的实现数据分布，这种技术可以讲一个数据库中的表、用户（Schema）、表空间 （Tablespace）或者整个数据库复制到另一数据库上中，甚至是双向的同步，Oracle  9iR2开始实现这种方式更倾向于Streams技术，Advanced  Replication是基于内部触发器的技术，而Streams采用挖掘日志的方式，对系统的压力大大的减小。

 

4.1 Streams结构介绍

 

在Oracle 9iR2之前，如果想实现数据库的复制，除了备用数据库（Standby Database）和高级复制（Advanced  Replication）等技术外，没有其他号的办法，而Standby Database主要应用于容灾，是这个数据库的完全复制，而Advanced  Replication配置相对复杂，并且对性能影响比较大，因此在应用上都有弊端，Oracle在9iR2版开始推出Streams技术，它与 Standby备份数据库技术内部运行机制非常相似，都是捕获主数据库的日志然后传送到目标机器上应用日志而恢复，图3是Streams技术的结构图：

 

 

图3Streams结构图

 

 

 

虽然与Standby一样都是捕获主机的日志后进行数据同步，但Streams技术却比Standby具体很多优点：

 

Ø 支持部分复制，可以只复制一个表、一个用户或者一个表空间，这个是Standby无法实现的

 

Ø 支持一个数据库内部复制也可以跨数据库复制甚至跨数据库产品（从数据库到非Oracle数据库之间的复制

 

Ø 支持双向复制，而Standby备用数据库除了能提供查询外在备用状态下是不支持写操作的

 

 Streams技术通过高级队列（Advanced Queuing）、日志挖掘（Logminer）、和作业调度（Job  Schedule）等技术，来实现集捕获、传输、共享的数据共享通道。Streams  Replication的处理过程主要分为三个阶段，包括：捕获（Capture）、传播（Propagate）与应用（Apply），下面我们具体介 绍这三个阶段的工作原理：

 

Ø    捕获：根据站点定义的捕获规则（Rules），将符合捕获的事物及操作（DML、DL）从数据库的联机日志或者归档日志中解析出来，变成逻辑改变记录LCR(Logical  Change Records)

 

Ø    传播：主要是网络传播过程，作为Job  Queues进行调度，它负责将消息队列中的LCRs传送到目标队列中，它提供了“一对多”、“多对一”、“一对一”的传播方式，还支持不同环境中的传播

 

应用：负责从目标站点消息队列提前LCRs，并且根据Streams  Replication目标站点定义的规则（Rules）解析出一句提交的事物，然后按照以来关系与执行顺序来组织好这些事物分配给应用进程应用这些事物。

 

4.2 Oracle Streams特点

 

1)    Oracle  Streams最大的特点就是灵活，可以跨平台对单独表、用户、表空间或者整个数据库进行复制，而复制的压力更小，基本对数据库造成额外的压力，这也是对Advanced  Replication更加先进的体现

 

2)    Streams可以实现双向复制和多源复制，灵活的跟进应用特点定义复制的方式

 

3)    可以实现数据库主机、存储的完全容易备份，大大提高了系统的可用性、扩展性和安全性

 

4)    Streams技术虽然得到了很大的完善，但该技术缺少像RAC、Data  Guard技术那样在高可用环境下的验证，所以目前对该技术的认知度还有待提高

 

5 数据库主机HA

 

Oracle主机HA（Server HA）属于我们开始说的狭义意义上的HA，它是基于OS的技术，采用OS支持的Cluster  Soft来保证主机的冗余保护，当主机或者网络发生故障时来实现自动保护切换，它和RAC一样使用共享存储来保证数据的一致性

 

5.1主机HA结构介绍

 

主机HA技术出现的比较早，技术也比较成熟，现在市场上也有很多优秀的支持各种OS的Cluster  Soft，所以主机HA技术应用非常广泛，而且主机HA的集群技术与数据库的版本、特性无关，在不同的数据库版本甚至不同的数据库上都可以实现主机的 HA，它与RAC的工作模式有所不同，RAC主要工作在双机双工的末实现，而主机HA则工作在双机热备或者双机互备的模式下，同时RAC是居于数据库而完 成的高可用性，而主机HA是基于OS完成的主机高可用性来保证数据库的高可用性，图4为主机HA的结构图：

 

 

图4 主机HA结构图

 

主机HA技术是一个或者多个主机共享一台备用主机的集群技术，所以它能解决主机故障包括OS故障、主机网卡故障、单个主机的网络故障等，通过 Cluster软件将两台或者多台数据库主机绑定一个服务IP，所有的Data  file、Contr File、Redo log等都存放于共享的存储上，主机HA集群通过一个服务IP对外提供服务，通过HA  Soft软件的管理集群中的各个主机运行在Active/Standby方式下，当其中一台主机发送故障时，HA  Soft软件会自动的检测到故障并且将提供服务的IP切换到正常的主机上提供服务，从而保证了数据库服务的连续性和故障的自动切换。现在支持主机HA的 Cluster软件有很多种，只要的有：Veritas的VCS，IBM的HACMP，HP的ServiceGuard，SUN的Sun  Cluster等。

 

5.2主机HA特点

 

1)    主机HA的最大优点就是可以解决服务器的单点故障，Database所有的文件都建立在共享存储上，存储的冗余需要依赖其他技术（RAID、LVS等）来实现

 

2)    主机HA的技术简单成熟，所以在实际的应用中被广使用，但对主机资源的浪费比较严重，基本上要保证对等的资源处于等待状态

 

6 Oracle高可用性架构举例

 

Oracle数据库的稳定与安全关乎整个平台的稳定与安全，下图描述的体系结构是实现Oracle高可靠性的一种不错的架构，数据库采用了 RAC+ASM+STANDBY的结构体系，应用层采用Oracle自己的Application  Server。用户通过负载均衡设备访问不同的Oracle应用服务器，而应用服务器通过自动负载均衡及Failover特性访问当前的主数据库。

 

当主站点出现故障的时候，Data  guard可以手工或者是自动切换到备用端，应用服务器的访问也将自动被切换到备用站点，以保证系统的最大可用性与业务连续性。

 

 

 

 

7 总结

 

以上我们介绍了当今世界上流行的Oracle  高可用性的架构方案，但对于我们现实的工作中，随业务的不断发展，根据硬件的投入与产出的比例，平台到底适合哪种数据库的高可用性方案比较合适呢？我认 为可以根据平台业务、硬件配置的不同选择不同的数据库高可用性方案，从而既极大的发挥了平台中硬件设备的性能同时也保证了数据的冗余，主要可依据现网数据 库主机的配置和对数据库访问的并发需求来选择，具体如下：

 

1) 现网两台数据库主机配置相当并且数据库并发访问量较大

 

对于这种平台由于数据库访问量相对较大，并且数据库主机的硬件配置相当，建议采用Oracle Advanced  Replication/Streams的架构来实现数据库的高可用性，这样两台数据库服务器都作为主用服务器提供服务，在保证了并发数的同时又保证数 据的冗余备份。

 

2)   现网数据库主机性能较低但需要支持大量的并发访问

 

对于这种平台建议采用Oracle  RAC的架构方案，该方案可以使多台连接的PC组成一个支持大量访问的集群，并且可以灵活的增加、删除集群中的节点来实现平台的平滑扩容和升级，但需要相应的存储、容灾方案的配合。

 

3) 现网只有一台数据库主机并且该主机基本满足平台需求

对于这种平台建议采用备用数据的方案（Standby/Data Guard），一台性能不错的主机作为主数据库，增加一条档次较低的主机（pc  server）作为备用数据库，备用数据库只做主用数据库的冗余，不提供读写操作，在主用数据库发生故障时可以临时启用备用数据库提供服务。

 

	RAC（集群）	Standby（备份）	Streams（复制）	Server HA（集群Soft）
	多个Oracle实例（Instance）与一个数据库（Database）连接。数据库存放于多个节点的公用存储（Share  Storage）上，通过高速缓存合并技术使得集群中的每个节点可以通过高速集群互联高效的同步其内存高速缓存。	采用Standby的日志传送方式，归档日志活联机日志通过网络传送到备用端，所以可以把Standby看做是一个正在不停恢 复中的数据库。	与Standby一样都是捕获主机的日志后进行数据同步。支持部分复制；支持跨数据库复制甚至跨数据库产品； 支持双向复制。	多个主机共享一台备用主机的集群技术。通过 Cluster软件将两台或者多台数据库主机绑定一个服务IP，通过HA  Soft软件的管理集群中的各个主机运行在Active/Standby方式下。
负载均衡	支持	不支持	依赖于客户端？	支持
故障切换	自动	手动	依赖于客户端？	自动
容灾恢复	依赖于外部组件	支持	支持	依赖于外部组件