在数据库高可用架构的演进历程中,共享存储集群被公认为核心生产环境中最优秀的解决方案。它允许多个数据库节点同时访问同一份数据,实现负载均衡与故障自动切换,兼具高可用与高吞吐。在这一领域,Oracle RAC集群毋庸置疑是共享存储集群的事实标准。而达梦DSC(Data Shared Cluster)集群 ,作为国产数据库阵营中全球第二家掌握数据共享存储核心技术的企业级产品,同样有着优秀的性能以及共享存储的核心技术。本文将围绕两款产品,从集群基本结构与核心组件进行对比,帮助大家深入理解两款共享存储集群。
在正式对比之前,有必要先厘清一个基本概念:什么是共享存储集群?
区别于主备集群“多份数据靠日志追平”的架构思路,共享存储集群的核心理念是“多个实例共享同一份数据”——所有数据库实例并发访问同一套数据文件、控制文件,每个节点拥有独立的CPU、内存和进程,但核心数据库文件位于共享存储之上。这种架构带来的直接收益是:任何一个节点故障,其他节点可立即接管服务,无需等待日志重演或数据同步。
Oracle RAC与达梦DSC,正是这一技术路线在全球与国内最具代表性的两大产品。
Oracle RAC的前身是Oracle 7时代推出的OPS(Oracle Parallel Server)。OPS虽然实现了多实例并行访问共享数据库,但采用了一种低效的“磁盘心跳”模式:当一个实例需要修改某个数据块时,必须先将该数据块写入磁盘,再由其他实例从磁盘读取——频繁的磁盘I/O严重制约了性能。
为此,Oracle引入了Cache Fusion高速缓存融合技术,高速缓存融合技术使得RAC集群中的节点可以通过高速集群互联高效地同步其内存缓存,从而最大限度地低降低磁盘 I/O,高速缓存最重要的优势在于它能够使集群中所有节点的磁盘共享对所有数据的访问,通过集群私有网络完成节点间的数据传递。这一创新的本质是用网络带宽替代磁盘I/O:数据共享不再经过磁盘这一慢速介质,而是在内存层面直接完成。
Oracle RAC集群架构如下图所示:
DMDSC 集群是一个多实例、单数据库的系统。多个数据库实例可以同时访问、修改同一个数据库的数据。用户可以登录集群中的任意一个数据库实例,获得完整的数据库服务。数据文件、控制文件在集群系统中只有一份,不论有几个节点,这些节点都平等地使用这些文件,这些文件保存在共享存储上。每个节点有自己独立的联机日志和归档日志,联机日志和归档日志都需要保存在共享存储上。
与Oracle引入的Cache Fusion技术类似,DMDSC也通过缓存交换(Buffer Swap)技术来实现高性能,节点间的数据页尽可能通过网络传递,避免通过磁盘的写入、再读出方式在节点间传递数据,从而减少数据库的 IO 等待时间,提升系统的响应速度。两技术的实现原理,将在后续章节中详细对比。
DMDSC集群的结构图如下图所示。
Oracle RAC和达梦DSC,在核心设计架构上具有相似之处,都遵循着多实例 + 共享存储 + 缓存融合/交换 + 全局锁管理的这一技术特点,但二者在核心组件上却大不相同,接下来将介绍对比二者的核心组件。
集群控制服务是整个共享存储集群的“大脑”——负责节点的生命周期管理、故障检测与恢复、集群资源的统一编排。
CRS是RAC的集群基础设施层,它是一套独立于数据库软件的集群管理解决方案,需要单独安装GI软件包。
CRS的核心进程是CRSD(Cluster Resource Service Daemon) ,它管理着集群中所有被定义为“资源”的对象——包括数据库实例、监听器、VIP地址、服务以及应用程序进程。CRSD基于存储在OCR中的资源配置信息,执行资源的启动、停止、监控和故障转移操作。当某个资源状态发生变化时,CRSD会生成相应的事件,触发自动恢复流程。
但是CRSD只管理集群资源,并不参与节点存活状态的判断,CRS还包含CSSD进程,其负责维护集群节点成员关系,通过Voting Disk实现节点间的心跳通信与仲裁。总的来说CRS根据CSS提供的节点成员信息,决定在哪些节点上启动或停止哪些资源。如果CSS报告某个节点故障,CRS会将该节点上的资源自动迁移到其他健康节点
CRS的特别之处在于他是独立的一套集群管理软件,他不仅可用于管理RAC集群,还提供了一组高可用性API,可以用来构建一般应用程序的高可用集群。
CRS主要进程服务CRSD和CSSD的关系如下图所示:
达梦集群同步服务(Dameng Cluster Synchronization Services,简称DMCSS)是DMDSC集群的控制服务。与Oracle CRS不同,DMCSS并不是一个独立的软件层,而是与数据库实例紧密集成的服务组件——使用DMDSC集群或DMASM集群都必须配置DMCSS服务。
在DMDSC集群中,DMCSS既承担资源管理的功能,也承担节点管理的功能,每个节点都需要运行一个DMCSS服务,这些DMCSS服务自身也构成一个集群。DMCSS集群中存在两种角色:
控制节点(Control Node) :负责监控和管理整个DMASM集群和DMDSC集群
普通节点(Normal Node) :不参与集群管理,仅作为候选,当控制节点故障时被选举为新的控制节点。
DMCSS的核心功能包括:写入心跳信息、选举DMCSS控制节点、选取DMASM/DMDSC控制节点、管理被监控对象的启动流程、集群状态监控、节点故障处理、节点重加入等。
具体结构如下图:
DMCSS的工作基于VOTE磁盘——每个被监控对象(DMASMSVR、DMSERVER、DMCSS)定时向VOTE磁盘写入心跳信息,DMCSS控制节点定时读取这些信息,检查状态变化并触发相应处理流程。
Oracle CRS+CSS 与达梦 DMCSS 在目标上高度一致——均负责节点成员管理、资源编排和故障恢复。但实现路径截然不同:Oracle 将集群管理独立为 Grid Infrastructure 软件层,CSS 与 CRSD 分工明确,CSS 管心跳与成员关系,CRSD 管资源生命周期,分层解耦,且可服务于非数据库应用;达梦则将所有控制功能集成于 DMCSS 服务中,同一进程既承担节点心跳监控(通过 VOTE 盘),又负责资源启停和集群选举,且引入控制节点/普通节点角色以实现集中管控。
集群配置存储相当于集群的“注册表”——记录着集群中所有资源的配置信息和运行状态。
OCR是Oracle Clusterware的核心配置文件,用于存储和管理Oracle Clusterware所控制的所有组件的信息,包括Oracle RAC数据库、监听器、VIP地址、服务以及各类应用程序。OCR以键值对(key-value pairs) 的形式在树形结构中存储配置信息,OCR必须存放在所有节点均可访问的共享存储上。Oracle官方推荐将OCR存储在ASM磁盘组中。
OCR 的内容非常的重要,所有对 OCR 的操作必须确保OCR 内容完整性,所以在 ORACLE Clusterware 运行过程中,并不是所有结点都能操作 OCR Disk.在每个节点的内存中都有一份 OCR 内容的拷贝,这份拷贝叫作 OCR Cache。每个结点都有一个 OCR Process来读写 OCR Cache,但只有一个节点的 OCR process 能读写 OCR Disk 中的内容,这个节点叫作 OCR Master 结点。这个节点的 OCR process 负责更新本地和其他结点的 OCR Cache 内容。所有需要OCR 内容的其他进程,比如OCSSD,EVM等都叫作Client Process,这些进程不会直接访问OCR Cache,而是像 OCR Process发送请求,借助 OCR Process获得内容,如果想要修改 OCR 内容,也要由该节点的 OCR Process像 Master node 的 OCR process 提交申请,由 Master OCR Process 完成物理读写,并同步所有节点 OCR Cache 中的内容。
在Oracle 11.2中,还引入了一个新文件——OLR(Oracle Local Registry,本地注册表) ,存放在每个节点的本地存储上,用于存储仅与该节点相关的配置信息。
DM 集群注册表(DM Clusterware Registry,简称 DCR)磁盘专门用于存储 DCR 文件。DCR 文件记录了存储、维护集群配置的详细信息。整个集群环境共享 DCR 磁盘信息,包括集群(DMDSC、DMASM、DMCSS)资源、实例名、监听端口、集群中故障节点信息等。在一个集群环境中只能配置一个 DCR 磁盘。
存储方式:DM8目前仅支持保存在 DMASM 文件系统管辖范围之外的共享存储上,而Oracle OCR可存储在ASM或集群文件系统上。
数量限制:一个DMDSC集群环境中只能配置一个DCR磁盘,而OCR可以配置多个。
冗余与高可用:两者都提供冗余机制来防止单点故障,但实现方式不同。
达梦DCR:在非镜像环境下,一个集群只能配置一个DCR磁盘。其冗余能力依赖于DMASM镜像功能。在镜像环境下,DCR的信息会同步写入专用的 DCRV磁盘组 中,以此实现数据冗余。
Oracle OCR:Oracle推荐并支持配置最多5个OCR副本(即多副本机制)。这些副本可以存放在不同的物理存储上。单个OCR的损坏不会影响集群的正常运行,且可以在线进行替换和恢复。
存储管理层负责将底层的物理磁盘抽象为统一的存储空间,供数据库实例高效读写。
ASM是Oracle数据库10g引入的一项创新技术,它提供了一个专为Oracle数据库文件设计的集群卷管理器与文件系统的垂直整合方案。在ASM出现之前,Oracle数据库通常需要依赖第三方的卷管理器和文件系统来管理存储。ASM将这两层功能直接整合到Oracle内核中,使DBA能够直接管理磁盘组,而无需与系统管理员或存储管理员反复协调存储配置。
ASM提供了以下核心能力:
条带化:将数据库文件均匀分布到所有可用磁盘上,在免去手动I/O调优的同时优化性能。ASM以分配单元(Allocation Unit,AU) 为基本单位,将文件的AU在所有磁盘间平均分配,实现I/O的自动均衡。
镜像冗余:提供数据冗余保护,支持外部冗余(External,依赖外部存储) 、正常冗余(Normal,双副本) 和高冗余(High,三副本) 三种级别。与操作系统级别的磁盘镜像不同,ASM是在文件级别实现的镜像,同一个磁盘组内可以为不同文件配置不同的冗余策略,灵活性更高。
动态扩展:支持在线增加或删除磁盘,无需关闭数据库。添加或删除磁盘后,ASM会自动重新分布文件内容以实现负载均衡,这一过程称为自动重新平衡(Automatic Rebalance) 。
大文件支持:天生支持大文件,消除了传统文件系统的文件大小限制。
绕过操作系统缓存:ASM文件系统不使用操作系统缓存,支持直接I/O和异步I/O。Oracle数据库在识别到以“+”开头的ASM文件时,会直接调用ASM的代码层处理I/O,而非依赖操作系统的文件系统I/O,从而获得更可控的I/O性能。
同时ASM不仅适用于RAC环境,也同样适用于单实例数据库。
DM 自动存储管理器(DM Auto Storage Manager,简称 DMASM)是一个专用的分布式文件系统。
DMDSC 如果直接使用块设备作为共享存储来存放数据库文件,会因为块设备本身的诸多功能限制,造成 DMDSC 集群在使用、维护上并不是那么灵活方便。为了克服块设备的这些使用限制,DM 专门设计了一款分布式文件系统 DMASM,来管理块设备的磁盘和文件。DMASM 的出现为 DMDSC 灵活管理和使用块设备提供了完美的解决方案。
ASM的磁盘与文件管理是由DMASMCMD 将物理磁盘格式化后,变成可识别、可管理的 ASM 磁盘,再通过 ASM 磁盘组将一个或者多个 ASM 磁盘整合成一个整体提供文件服务。ASM 磁盘格式化以后,会逻辑划分为若干簇(Extent),簇是管理 ASM 磁盘的基本单位,ASM 文件的最小分配单位也是簇。
DMASM的核心能力包括:
分布式管理:支持多台机器并发访问ASM磁盘和文件,提供全局并发控制
磁盘组管理:支持创建和删除磁盘组,将块设备格式化为DMASM格式;一个磁盘组可包含多个ASM磁盘,支持在线增加实现动态扩展
文件管理:支持创建、删除、截断、动态扩展文件;文件可跨多个磁盘存储,大小不再受限于单盘
镜像与条带化:支持镜像存储和条带化存储功能
管理工具:提供DMASMTOOL工具,支持类Linux的文件操作命令;另有DMASMCMD命令行工具
高性能I/O:数据库进程绕过操作系统直接读写磁盘,提升I/O效率
簇映射表:DMASM使用簇映射表来维护ASM文件与物理磁盘地址的映射关系,在访问ASM文件时根据文件号、文件偏移量快速获取对应的物理地址。
一个部署了DMASM的DMDSC集群的结构图如下图所示:
Oracle ASM与DMASM在大体功能上比较相同,最大的一个不同是Oracle ASM本身不是文件系统,需配合 ACFS(ASM Cluster File System)提供文件系统功能,而DMASM 直接提供 DMASM 文件系统,支持创建目录、读写文件。
至此,本文完成了对达梦DMDSC集群与Oracle RAC集群在集群架构和核心组件两个层面的横向对比。
回顾前文,我们可以看到:在设计理念上,通过对比可以发现DSC的设计理念是把集群组件一体化集成,有更简洁的部署。而在RAC中追求分层解耦,每一层组件都是独立的一套软件。
在顶层设计上,二者遵循了相同的技术范式——多实例 + 共享存储 + 缓存融合/交换 + 全局锁管理——这并非巧合,而是共享存储集群这一技术路线的最优解。达梦DSC在设计之初就明确对标Oracle RAC的架构蓝图,从集群控制到配置存储,从存储管理到缓存机制,每一层都能找到与RAC对应的功能组件。从这个意义上说,DSC已经完成了“从0到1”的架构搭建,具备了与RAC平等对话的基础。
https://eco.dameng.com
文章
阅读量
获赞
