Oracle Real Application Clusters (RAC) 详细介绍
引言
在当今数据驱动的世界中,企业对数据库系统的可用性、可伸缩性和性能有着极高的要求。传统的单实例数据库架构面临着单点故障的风险,一旦数据库服务器出现问题,整个业务系统可能瘫痪,造成巨大的经济损失。同时,随着业务的增长,单台服务器的处理能力也可能无法满足日益增长的负载需求。
为了解决这些挑战,数据库供应商纷纷推出了高可用性和可伸缩性解决方案。Oracle Real Application Clusters (RAC) 就是 Oracle 公司提供的一项核心技术,它允许在多个互相独立的服务器(节点)上运行单个 Oracle 数据库,从而提供强大的高可用性和可伸缩性。本文将深入探讨 Oracle RAC 的核心概念、架构、工作原理、组件、优势、挑战以及管理等方面,为您呈现一个全面的 RAC 图景。
什么是 Oracle RAC?
Oracle Real Application Clusters (RAC) 是 Oracle Database 的一项特性,它将单个数据库部署在由多个物理服务器(节点)组成的集群上。这些节点共享同一组数据库文件(数据文件、控制文件、联机日志文件等),但每个节点都运行着自己的 Oracle 数据库实例。
简单来说,RAC 不是部署多个独立的数据库,而是部署一个数据库的多个“副本”(实例),这些副本同时运行在不同的服务器上,共同提供对这个单一数据库的访问。当用户或应用程序连接到 RAC 数据库时,它们实际上是连接到集群中的某个实例。
RAC 的核心目标是:
- 高可用性 (High Availability – HA): 当集群中的某个节点或实例发生故障时,其他正常运行的节点可以立即接管其工作负载,用户连接可以透明地切换到其他可用实例,从而最大限度地减少停机时间。
- 可伸缩性 (Scalability): 随着业务负载的增加,可以通过向集群添加新的服务器节点来扩展数据库的处理能力,而无需对应用程序进行大规模修改。RAC 允许数据库的总处理能力随着节点的增加而线性或接近线性增长。
RAC 的核心概念与架构
Oracle RAC 基于共享磁盘架构 (Shared-Disk Architecture)。这意味着集群中的所有节点都可以同时访问同一个共享存储上的数据库文件。这与共享无架构 (Shared-Nothing Architecture) 形成对比,在共享无架构中,每个节点拥有自己独立的数据和存储,节点之间通过网络进行数据交换。
在 RAC 架构中,有几个关键的概念和组成部分:
- 数据库 (Database): 这是一个逻辑概念,包含了一组物理文件(数据文件、控制文件、日志文件等)。在 RAC 环境中,所有实例共享这一组文件。
- 实例 (Instance): 这是一个物理概念,包含了 Oracle 数据库的内存结构 (SGA – System Global Area) 和后台进程 (Background Processes)。在 RAC 集群中,每个节点上都运行着一个独立的数据库实例。这些实例都有自己的 SGA 和后台进程集,但它们访问的是同一个数据库文件集。
- 节点 (Node): 组成 RAC 集群的物理或虚拟机服务器。每个节点通常运行一个 Oracle 数据库实例。
- 共享存储 (Shared Storage): 所有 RAC 节点都能访问的外部存储设备,用于存放数据库文件。这通常通过光纤通道 (Fibre Channel)、iSCSI 或网络附加存储 (NAS) 实现。为了高性能和高可用性,通常推荐使用 Oracle Automatic Storage Management (ASM) 作为共享存储的管理层。
- 集群互连 (Cluster Interconnect): RAC 节点之间用于内部通信的私有高速网络。这是 RAC 正常工作的关键,用于实例之间的缓存数据块传输(Cache Fusion)、锁管理、心跳信号等。互连网络的性能(带宽和延迟)直接影响 RAC 的性能和可伸缩性。
- 集群软件 (Clusterware): 管理整个集群的基础设施软件。Oracle 提供了自己的集群软件,称为 Oracle Clusterware(在 11g R2 及以后版本中整合到 Grid Infrastructure 中)。其主要功能包括:
- 节点成员管理:维护集群中哪些节点是活跃的。
- 资源管理:管理集群中的各种资源,如数据库实例、监听器 (Listener)、ASM 实例、IP 地址等,确保它们在高可用性模式下运行。
- 故障检测与切换:监控节点、实例和资源的健康状况,当检测到故障时,自动重启资源或将其切换到其他健康节点上。
- 心跳机制:节点通过互连网络和共享存储交换心跳信息,判断其他节点的健康状态。
RAC 的核心工作原理:Cache Fusion
Cache Fusion 是 Oracle RAC 的核心技术,它使得多个实例能够高效地、并发地读写共享存储上的同一个数据块,同时维护数据的一致性。
在单实例数据库中,当一个进程需要访问一个数据块时,它会首先检查 SGA 中的数据库缓冲区缓存 (Database Buffer Cache)。如果块不在缓存中(Cache Miss),它会从磁盘读取到缓存中。如果需要修改块,会在缓存中进行修改,并在稍后写回磁盘。
在 RAC 环境中,情况变得复杂。假设实例 A 需要修改数据块 X,而实例 B 同时需要读取数据块 X。如果实例 A 已经在其缓冲区缓存中修改了块 X 但尚未写入磁盘,那么实例 B 直接从磁盘读取到的块 X 将是旧的、不一致的数据。
Cache Fusion 解决了这个问题。它允许数据块在集群中的实例之间直接传输,而无需先写到磁盘再由另一个实例从磁盘读回。其工作流程大致如下:
- 全局资源目录 (Global Resource Directory – GRD): GRD 是 Cache Fusion 的核心组件,它分布在所有 RAC 节点的 SGA 中,由全局缓存服务 (GCS – Global Cache Service) 和全局锁服务 (GES – Global Enqueue Service) 共同维护。GRD 记录了集群中每个数据块的状态、位置以及哪些实例持有该块的副本。
- 请求数据块: 当一个实例(例如实例 B)需要访问一个数据块(例如块 X)时,它首先在自己的缓冲区缓存中查找。
- 检查 GRD: 如果块不在本地缓存中,实例 B 会向 GCS/GES 发送请求。GCS/GES 检查 GRD,确定块 X 当前的状态(例如,是被某个实例独占修改中,还是被多个实例共享读取中,或者在磁盘上是最新的)。
- 块传输 (Cache Fusion):
- 如果块 X 当前被另一个实例(例如实例 A)独占修改且尚未写入磁盘,GCS/GES 会通知实例 A 将该块发送给实例 B。实例 A 会将修改后的块(可能还包括相关的重做信息)通过高速的集群互连网络直接传输给实例 B。
- 如果块 X 当前被多个实例共享读取,GCS/GES 会通知这些实例降级其块状态,并允许实例 B 也获取一个共享副本。
- 如果块 X 在任何实例的缓存中都不是最新或独占状态,GCS/GES 会指示实例 B 从共享存储中读取。
- 状态管理: GCS/GES 根据请求和块的传输更新 GRD 中块的状态。例如,如果实例 A 将独占持有的块 X 传输给实例 B,GCS/GES 可能会记录实例 A 现在对块 X 持有共享状态,实例 B 也持有共享状态,或者如果实例 B 请求的是独占访问,则可能需要更复杂的协调过程(实例 A 必须放弃对块 X 的持有或降级其状态)。
- 一致性维护: 在 Cache Fusion 过程中,Oracle RAC 使用复杂的锁和一致性协议(如基于两阶段提交的分布式锁管理)来确保即使多个实例同时读写同一个块,数据视图也是一致的。这比传统的分布式锁系统更高效,因为它避免了频繁的磁盘 I/O。
Cache Fusion 极大地提高了 RAC 的性能,因为它减少了对共享存储的频繁读写,尤其是在热点数据块(频繁访问的数据块)上。数据块直接在内存中通过高速互连网络传输,速度远超磁盘 I/O。互连网络的性能是 Cache Fusion 效率的关键,低延迟和高带宽的网络能显著提升 RAC 的整体性能。
RAC 的关键组件详解
除了上述核心概念,还有一些重要的组件构成了 RAC 环境:
-
Oracle Clusterware (GI): Oracle Clusterware 是 RAC 的基础,从 11g R2 开始,它与 ASM 一起打包在 Oracle Grid Infrastructure (GI) 安装中。GI 必须先于数据库软件安装。
- 投票磁盘 (Voting Disk): 存储集群节点成员信息。它是所有节点都能访问的共享文件,用于确定哪些节点是集群的有效成员(仲裁机制)。如果网络出现分区,投票磁盘用于解决“脑裂” (Split-Brain) 问题,确保只有一个子集被认为是活动的集群。投票磁盘需要有奇数个副本,或者使用一个额外的仲裁磁盘来达到多数仲裁。
- OCR (Oracle Cluster Registry): 存储集群配置信息,包括集群节点列表、资源(数据库、实例、监听器、服务、VIP等)的定义和状态、依赖关系等。OCR 是集群资源管理的关键。它也存储在共享存储上,需要冗余备份。
- CSS (Cluster Synchronization Services): 提供集群成员管理、节点健康监控和故障检测服务。
- CRS (Cluster Ready Services): 管理集群中的资源(数据库实例、监听器、服务、VIP等),并在检测到资源故障时执行重启或切换操作。
- CTSS (Cluster Time Synchronization Service): 确保集群中所有节点的时间同步,这对于分布式系统的一致性非常重要。
- EVM (Event Management): 发布集群资源状态变化的事件。
-
Oracle Automatic Storage Management (ASM): 虽然 RAC 可以使用操作系统的集群文件系统或裸设备,但 Oracle 强烈推荐并优化使用 ASM。ASM 是一个卷管理器和文件系统,专门为 Oracle 数据库文件设计。
- 磁盘组 (Disk Group): ASM 将一组物理磁盘抽象为一个或多个磁盘组。
- 条带化 (Striping): 将数据条带化(分散)到磁盘组中的所有磁盘上,提高 I/O 性能。
- 镜像 (Mirroring): 提供数据冗余(二路镜像或三路镜像),提高可用性,防止磁盘故障。ASM 的镜像是在文件级别进行的,比操作系统的 RAID 更灵活。
- 动态重平衡 (Dynamic Rebalancing): 当添加或删除磁盘时,ASM 会自动在后台重新分布数据,而不会中断数据库操作。
- 简化管理: 为 RAC 提供统一的、高性能的、易于管理的共享存储解决方案。
-
网络配置: RAC 需要至少两个独立的网络:
- 公共网络 (Public Network): 用于客户端和应用程序连接到数据库。每个节点通常有一个公共 IP 地址。
- 私有网络 (Private Network / Interconnect): 用于 RAC 节点之间进行 Cache Fusion 通信、心跳信号和内部消息交换。这是 RAC 的生命线,必须是高速、低延迟、私有的网络。通常使用 InfiniBand 或高速以太网(10GbE 或更高)。
- SCAN Listener (Single Client Access Name Listener): 从 11gR2 开始引入。SCAN 是一个或多个 DNS 名称,解析到一个或多个 IP 地址(SCAN IP)。客户端通过 SCAN 连接,SCAN Listener 运行在集群中的某个节点上,负责将客户端连接重定向到负载最低的实例监听器。这极大地简化了客户端连接配置,并提供了客户端负载均衡和连接失败切换。
RAC 的优势
使用 Oracle RAC 带来了多方面的显著优势:
-
高可用性 (HA):
- 节点故障保护: 当一个节点(及其上的实例)发生故障时,Oracle Clusterware 会检测到故障,并自动将受影响的资源(如 VIP 和服务)切换到其他健康节点上。应用程序可以利用 TAF (Transparent Application Failover) 或 FAN (Fast Application Notification) 特性,使客户端连接在故障发生后自动重新连接到其他可用实例,对用户影响最小。
- 实例故障保护: 类似于节点故障,单个实例的崩溃不会导致整个数据库停机。
- 计划内维护的可用性: 可以在不停机的情况下对单个节点进行维护(如操作系统补丁、硬件升级),通过滚动地停止和启动每个节点,保证数据库持续可用。
- 应用服务的高可用: 可以创建服务 (Services),并与特定的实例或节点相关联,或者在所有实例上运行。服务可以进行故障切换和负载均衡。
-
可伸缩性 (Scalability):
- 读写可伸缩: RAC 允许多个实例同时处理读写请求。对于 OLTP (Online Transaction Processing) 工作负载,通过增加节点可以显著提高事务吞吐量。
- 线性或接近线性扩展: 在理想情况下(工作负载分布均匀,互连网络高效),RAC 的处理能力可以随着节点数量的增加而近似线性增长。
- 应对高峰负载: 可以根据需要动态地启动或停止实例,或者在不同时间段将工作负载导向特定的实例。
-
负载均衡 (Load Balancing):
- RAC 提供了多种负载均衡机制,可以将客户端连接和会话分布到集群中的各个实例上,避免单个实例成为性能瓶颈。
- 客户端负载均衡: 通过连接串配置(如多个地址列表)或使用 SCAN。
- 服务器端负载均衡: 监听器根据实例的负载情况(如CPU利用率、活动会话数)将新的连接请求导向最合适的实例。
-
灵活性:
- 可以根据工作负载需求灵活地启动或停止集群中的特定实例。
- 支持滚动升级,可以在不中断数据库服务的情况下对 Oracle 软件或 Clusterware 进行升级。
-
资源利用率: 在高可用性模式下,所有节点都可以同时参与处理工作负载,而不是像传统主备模式那样,备库资源通常处于闲置状态(直到切换)。
RAC 的挑战与考量
尽管 RAC 提供了强大的功能,但它也带来了一些挑战和额外的考量:
- 成本: RAC 需要更多的硬件(多台服务器、高速互连网络、共享存储),以及额外的 Oracle RAC 软件许可费用。部署和维护的复杂性也可能导致更高的管理成本。
- 复杂性: RAC 环境的安装、配置、管理和故障排除比单实例数据库复杂得多。需要专业的 DBA 知识和经验。
- 管理与监控: 需要监控集群中的所有节点、实例、共享存储、互连网络以及集群软件的状态。需要专门的工具和脚本来管理集群资源。
- 性能调优: RAC 的性能调优比单实例更复杂。需要考虑 Cache Fusion 效率、互连网络延迟、块争用(Block Contention)、全局资源等待等因素。不合理的应用设计或 SQL 语句可能导致频繁的块传输和锁等待,反而降低性能。
- 应用兼容性: 虽然大多数应用程序可以在 RAC 上运行,但为了充分利用 RAC 的高可用性和负载均衡特性,应用程序需要采用适当的连接管理(如连接池)、错误处理(如处理连接断开和重连)以及使用服务进行连接。对于一些批处理或序列化任务,可能需要特定的设计来避免跨实例的冲突。
- 互连网络的重要性: 互连网络是 RAC 的生命线。任何互连网络的问题(延迟、带宽不足、不稳定)都会严重影响 Cache Fusion 的效率,导致性能下降甚至集群不稳定。
- 存储共享的挑战: 确保共享存储的高可用性和性能至关重要。存储故障可能影响整个集群。
RAC 的管理与监控
管理和监控 RAC 环境需要一套特定的工具和方法:
- 命令行工具:
crsctl
: 管理 Oracle Clusterware 资源(启动/停止/检查资源状态、管理 voting disk/OCR)。srvctl
: 管理 Oracle 数据库相关的集群资源(启动/停止/检查数据库、实例、监听器、服务、ASM 实例)。
- SQL*Plus: 连接到集群中的每个实例进行常规的数据库管理和监控。
- V$ 视图: 有许多特定的 V$ 视图用于监控 RAC 相关的性能和状态信息,例如:
V$ACTIVE_INSTANCES
: 显示当前活动的实例信息。V$GCSTATS
,V$CACHE_TRANSFER
: 监控 Cache Fusion 活动和互连网络性能。V$GES_STATISTICS
,V$ENQUEUE_STATISTICS
: 监控全局锁和排队情况。V$CLUSTER_INTERCONNECTS
: 显示互连网络信息。V$ASM_*
: 监控 ASM 实例和磁盘组的状态和性能。
- Oracle Enterprise Manager (OEM) / Oracle Cloud Control: 提供图形界面来集中管理和监控 RAC 集群、数据库、ASM 以及相关的中间件。这是管理复杂 RAC 环境的首选工具。
- Grid Infrastructure Management Repository (GIMR): 从 12c 开始,GIMR 是一个存储 Grid Infrastructure 监控数据的数据库,用于更高级的集群诊断和分析。
- 操作系统工具: 监控每个节点的 CPU、内存、网络(尤其是互连网络流量)、磁盘 I/O 等。
RAC 的常见用例
Oracle RAC 通常用于对可用性和可伸缩性要求极高的关键业务系统:
- 在线事务处理 (OLTP) 系统: 银行、金融、电商、电信等行业的核心交易系统,需要处理高并发的读写事务,且不能中断。
- 大型企业资源规划 (ERP) 系统: SAP、Oracle E-Business Suite 等,需要高可用性和随着用户数增加的可伸缩性。
- 高流量网站和应用后台数据库: 需要承受大量的并发访问和数据操作。
- 需要进行滚动维护而不能长时间停机的数据库环境。
RAC 的发展与演进
Oracle RAC 经历了多年的发展和完善,从最初的 OPS (Oracle Parallel Server) 演变而来,不断引入新的特性来提升性能、可用性和易管理性:
- Oracle 9i RAC: 引入了 Cache Fusion,标志着 RAC 走向成熟。
- Oracle 10g RAC: 引入了 Oracle Clusterware,使其成为 RAC 的必备组件,不再依赖第三方集群软件。引入了 ASM。
- Oracle 11gR2 RAC: 将 Clusterware 和 ASM 合并为 Grid Infrastructure。引入了 SCAN Listener,极大地简化了客户端连接。引入了 RAC One Node,提供单节点 RAC 的高可用性(类似于故障切换),但资源利用率不如全 RAC。
- Oracle 12c 及更高版本: 引入了 Flex Cluster(用于大规模部署)、Flex ASM、读写分离特性、更高级的资源管理和服务管理功能,以及与云环境的集成等。
总结
Oracle Real Application Clusters (RAC) 是 Oracle Database 针对企业级应用提供的旗舰高可用性和可伸缩性解决方案。它通过允许多个数据库实例在共享存储上同时运行,利用核心的 Cache Fusion 技术实现高效的数据共享和一致性维护。RAC 极大地提高了数据库的可用性,能够在节点或实例故障时自动切换,并支持在线滚动维护。同时,它提供了横向扩展能力,允许通过增加节点来应对不断增长的工作负载。
然而,RAC 的强大功能也伴随着更高的成本和显著的复杂性。部署、配置、管理和性能调优都需要专业的知识和经验。高速的互连网络是 RAC 性能的基石,而共享存储的高可用性和性能也至关重要。
对于那些业务连续性要求极高、需要处理高并发事务并期望未来能够平滑扩展的企业来说,Oracle RAC 是一个非常有价值的选择。理解其核心原理、关键组件和管理方法,是成功部署和运维高性能、高可用 RAC 环境的关键。
希望本文为您提供了 Oracle RAC 的全面且详细的介绍。